← PONEGLYPH SECURITY Our Research

XSS Chronicles: How I Stumbled Upon a Critical API Key Leak

Assalamu alaykum,

XSS Chronicles: How I Stumbled Upon a Critical API Key Leak

Assalamu alaykum,

Note: This was generated by AI Agent

A Glitch in the Matrix

Bug hunting is a mix of patience, curiosity, and a sprinkle of luck. One moment, you’re staring at a dashboard, wondering if there’s anything interesting to poke at, and the next, you’ve got an API key leak staring right back at you. This is the story of how a seemingly harmless input field turned into a high-severity XSS vulnerability with direct access to sensitive developer keys.

The Discovery

While exploring the developer portal of [REDACTED], I noticed something peculiar. When editing an application, there was a field called project_url that didn’t seem to be properly sanitized. Usually, XSS payloads get filtered out or encoded, but in this case, the field accepted raw JavaScript without any resistance. My curiosity was piqued.

Additionally, I discovered that there was a character limit and a filter that blocked alert() and spaces in input fields. This meant I had to get creative with the payload format.

Even more alarming, I found that I could add a victim to my group without any verification. This weakness allowed me to trap an unsuspecting developer into a compromised group where the XSS payload could target them directly.

So, I crafted the following payload to bypass these restrictions:

https://t.co/?l=<script>eval(decodeURIComponent('const%20y=%20new%20XMLHttpRequest();y.onreadystatechange=function(){console.log(this.responseText);};y.open("GET","https://developer.redacted.com/groups");y.send();'))</script>

When inserted into the project_url field, this payload successfully bypassed filters and executed, making it possible to extract sensitive information from authenticated user sessions.

Weaponizing the XSS

To make this vulnerability actually useful (for an attacker, that is), I needed three things:

  1. A victim — Someone who would unknowingly trigger the payload.
  2. A way to force them into my attack setup — The ability to add victims to my group without their approval made this effortless.
  3. Sensitive data — Something valuable that could be extracted via JavaScript.

After some digging, I realized that developers’ API keys were accessible from the portal. This meant I could craft an attack chain where visiting a simple URL could leak a victim’s API key in the background. Here’s how:

1️⃣ Setting the Trap

  • Create a developer account and register an application.
  • Note down the application ID (APP_ID).
  • Create a group and silently add a victim’s account (must be a developer) without their verification.

2️⃣ Planting the Payload

In the Product URL field, I inserted the script mentioned above, ensuring it complied with the input constraints.

3️⃣ Executing the Attack

Once the setup was complete, all I needed was for the victim to visit this crafted URL:

https://[REDACTED]/submit-verification/APP_ID

When they did, the script executed, stealing their API key in the background. Total compromise.

Impact

This wasn’t just any XSS — it was an authenticated attack that directly exposed high-privilege API keys. An attacker could:

  • Take over a victim’s developer account.
  • Abuse API keys to interact with backend services.
  • Potentially escalate the attack to a full account takeover.
  • Exploit the unverified group addition mechanism to increase attack success rate.

The severity? High (7.4/10).

The Fix & Takeaways

I responsibly disclosed the issue to [REDACTED], and after a back-and-forth, they patched it by enforcing proper input sanitization and restricting script execution in user-controlled fields. They also added verification for group invitations, preventing attackers from silently enrolling victims into malicious setups. A well-earned bounty followed, but more importantly, the vulnerability was fixed before it could be exploited in the wild.

Lessons Learned

  • Never trust user input — Every single input field should be treated as a potential attack vector.
  • Authenticated XSS is still dangerous — Many people overlook XSS that requires authentication, but this case proves how devastating it can be.
  • Group invitation mechanisms must require explicit verification — Allowing silent additions creates unnecessary security risks.
  • Bug bounty persistence pays off — Sometimes, a tiny detail (like an unsanitized input field) can lead to a major security risk.

Final Thoughts

Bug bounty hunting is full of surprises. Sometimes, the most impactful bugs come from the simplest mistakes. This XSS vulnerability started as a basic test and turned into a full-fledged API key leak, aided by an overlooked group invitation weakness.

If you’re into security research, always be curious, always test beyond the obvious, and most importantly — always report responsibly.

Stay safe & happy hunting!

May allah grant our people in gaza victory and peace