TL;DR
I'm certainly no security engineer, but the rush I felt finding my first vulnerability in a piece of software just might convince me to become one. I went into it expecting to find something, but certainly not a CVSS 10 – hell I didn't even know what I uncovered was that serious until I accidentally clicked on something. Figuring out what to do next, especially whilst not wanting to cause harm to the startup's chance of surviving is something that I won't forget quickly.
Disclaimer
The Maple team have sent me written consent agreeing to this article going live, and also have offered to pay me a bounty for my efforts. I wish them the best of luck with their work.
What happened?
I recently was promoted to Senior Engineer at work and with the grind of submitting a promo packet being over, I have been looking to broaden my horizons.
After having shipped my own set of mobile apps before with considerable scope (Think booking system, messaging, deeplinking, notifications etc), I know how hard it can be to get security right. There was always a fine line that I had to tread between keeping the rate of feature delivery fast and not compromising the stability or integrity of the production app. Doing this solo added even more pressure to my plate.
I happened to be browsing the internet when I came across Maple (@maplesocialclub), a new dating app that had launched in Sydney. It certainly had popped up out of nowhere (and seemed to have amassed attention quickly); thus my attention was piqued – firstly in seeing exactly how they built their app but also whether or not there were any cut corners in order to make the shipping date.
For me, I've been very happy to make the most of features like Row Level Security (RLS) in Supabase and other similar batteries-included features in the variety of startups and projects I have worked on. This is in part due to the ability for me to focus on delivering features whilst ensuring some sensible level of security. I feel I can sleep at night knowing that I understand how the data I am responsible for storing is made secure. Even so, I have empathy for what it is like working to a tight deadline – and the corners that have to be cut.
So, riding the high of being promoted and my ever pressing need to keep pushing myself, the opportunity to pen test Maple happened to converge at the opportune time for me.
The first (lesser) vulnerability
After finishing work on a Tuesday I jumped right in and installed the iOS app on my phone.
Upon startup, a normal user encounters a flow that guides the user to sign in or create a new account. When creating an account, they are prompted to authenticate with their phone number and provide details such as their name, sexuality, and profile pictures. Their interests are also recorded, just like other dating apps.
Without having a jailbroken iPhone (and the app not being out yet on Android), I downloaded ipatool and managed to grab a copy of the latest version of Maple. IPA files are really just .zip files in disguise, so whipping out the trusty unzip maple.ipa was enough.
Nice! inside the Payload folder is really what we want here (the rest is just metadata) – Maple.app (yes, an app inside an app).
Scanning the contents, a few items immediately caught my eye: Info.plist, main.jsbundle, and several Expo*.bundle files, confirming to me that they were shipping with the React Native Expo framework.
The first thing I was interested in was seeing the Info.plist file, given that it might contain some more info on how the app functions. At this point, I was just interested in seeing their stack!
Oh wow! They have a few URL schemas that they've registered! This allows for deeplinking – the ability for an app to craft a URL that stores some data and can open directly in the app – like opening a Spotify URL and the app opening rather than your internet browser.
These take special care to set up. There are specific endpoints that need to be registered and paths that need to be handled. I wonder what will happen if I just create a malformed URL:
datewithmaple://1Let's just create that in my Apple Notes app, tap on it, and….
Video showing the deep link vulnerability in action
I can see an error screen with their entire sitemap – to be clear, this is something that a normal user should never be able to see, but it alone is not a tremendous deal1. At this point it is possible to see all of the pages and components that make up the app itself.
I tried clicking into some of these components, and was pleased to find that some were protected by the same waitlist screen that normally appears after sign in/up. On the other hand, that's really just winning by default – if the waitlist wasn't there, it would be possible to navigate to any page I wanted. There were other screens that I could access that weren't protected by the waitlist (under different routes).
Whilst some components were just uninteresting debug screens, one crucial finding emerged: I could freely navigate back to the sign-in/up screens even though I was already authenticated and past the waitlist. This wasn't supposed to happen in the normal app flow.
Therein lies the first vulnerability. I found a way to pollute their database with as many users as I wanted. I verified this by seeing their waitlist count drop on the default home screen.
Alright, let's check the CVSS scale for this one.
Not bad for a first go, 7.1! I can, over the network with low complexity and being signed in, pollute their database and thus affect the quality of their matches. Maybe if I did this for long enough I could take their database down (unlikely).
That was fun, but I felt that there might be a bit more we can do. Before proceeding, I reached out to the CEO and told them what was happening. They said that their CTO would get in touch with me soon – and to their credit, they did within the next hour.
The second (critical) vulnerability
Right, so let's revisit where we were at. We have basic access to the files of the app, and we know that the app has been built with Expo.
That main.jsbundle looks interesting – after a quick chat with Amp, I realise that it contains all of the JavaScript code for running the app, just compiled and obfuscated.
Researching online, I found out about hbctool – we can use this to decompile the code to Hermes byte code and have a poke around at various things.
Nice! We have the assembly code for the app in instruction.hasm and some metadata. With the amount of effort involved in learning how to sight read hermes byte code, I decided to just go straight for the strings of the app. With this, we can start doing some basic grep'ing for interesting entries. From this, I found a hardcoded access token for PostHog. Alright, not bad. Something that was particularly of interest were two AWS endpoints that looked peculiar.
Hmm, these look like AWS API Gateway endpoints. Maybe Maple is using AWS as their backend? It was getting late so I decided to spin up a new project in Amp (ampcode.com) and go to town:
Given these two endpoints, can you create a python script that attempts to figure out what endpoints are available to be hit?
Amp did its thing and generated a bunch of different potential endpoints. After a bit of back and forth, I had some output. As I scrolled, reading it all, I saw a bunch of 404s. Nothing much interesting to see.
I recoiled at the next few lines of output for /user/create:
Wait, was that an unprotected endpoint that just gave me exactly the output I needed in order to call it? Let me try that again but with the fields…
Oh man.
So I had successfully created a user through the unprotected API endpoint. I wanted to record all this down, so I decided to paste the URL into my notes. In a hurry, I accidentally clicked on it, which proceeded to open in my browser and returned all of the user's information without any authentication.
The user info of the profile I made (with ID: user) returned without authentication
This meant I could not only create users, but also fetch any user's data by simply knowing their user ID – all without any authentication whatsoever. This is really really bad.
The impact was staggering: I could create, overwrite or read any user data I wanted, including phone numbers, sexuality, and images of their profile. I could bring down Maple's systems by DDOS or by simply creating loads of garbage user data, disrupting the in-app experience for other users. Most critically, I had complete access to all user data across the entire platform without any authentication whatsoever.
I immediately stopped what I was doing and texted the CTO that I was now in direct contact with. They were very supportive in my efforts and late into that night and following morning worked to patch all issues I found.
Again, let's plug this into the CVSS calculator and see what we get for this one.
CVSS 3.0 Scoring Breakdown
Attack Vector (AV)
Network (N)Exploitable remotely over the internet through unprotected AWS API Gateway endpoints. Maple's API was directly accessible without any intermediary protection.
Attack Complexity (AC)
Low (L)Exploitation required only basic HTTP requests. The vulnerability was discoverable through simple decompilation of the app (using hbctool) and observation of error messages that revealed required fields.
Privileges Required (PR)
None (N)No authentication, tokens, or credentials were required to exploit the API endpoints. Anyone could make direct calls to user data without signing in.
User Interaction (UI)
None (N)Exploitation was fully automated without requiring any actions from victims or app users.
Scope (S)
Changed (C)The vulnerability in the API endpoint protection impacted the entire user database and potentially other system components.
Confidentiality (C)
High (H)Complete exposure of all user data including highly sensitive information such as sexuality, phone numbers, birth dates, location data, and profile pictures. This included special category personal data with higher protection requirements than standard PII.
Integrity (I)
High (H)Complete loss of data integrity; attacker could create users with arbitrary IDs (including overwriting existing users), manipulate waitlist status, and modify any user profile information.
Availability (A)
High (H)Potential for complete service disruption by polluting the database with garbage data, adding fake users, and manipulating waitlist counts that were displayed in the app's interface.
In conclusion…
A few crucial points:
- 1
Take security seriously, but have empathy. Startups are the time to move fast, but this circumstance was very clearly an honest mistake.
- 2
This can happen to anyone at any level of the tech stack. The recent Next.js middleware vulnerability (https://nextjs.org/blog/cve-2025-29927) proves that even the most widely used frameworks can have critical security flaws hiding in plain sight. Interestingly, there's been a surge of app and dating app security discoveries in the age of AI - see these HN discussions on similar vulnerabilities: here and here.
- 3
I genuinely enjoyed the pen testing process – being the one who takes things apart rather than puts them together.
Responsible Resolution
I'm grateful that the Maple team responded professionally, working through the night to patch the issues I discovered.
sitemap.xml files exist for websites that traditionally describe the layout of pages on a website. Though not malicious by themselves, they do allow you to understand more about a website's structure. Zuckerberg used this in the early days of facebook to trawl university student lists.