In March 2012, Egor Homakov performed one of the most famous exploits in application security history: he acquired write rights to Ruby on Rails's GitHub repository and committed directly to its master branch. The commit is still visible for all to see (here). How was Homakov able to do this? He exploited a vulnerability in GitHub's API that allowed him to overwrite arbitrary server-side properties. Specifically, he bound his own SSH key to the profile of another user with commit rights to Ruby on Rails's repository.

Sign in with Google, the signature verifies, and the token is valid. PKCE checks out, the redirect_uri matched exactly, state came back untouched. Textbook flow, start to finish. Then the application runs find_user_by_email(claims.email), and the session goes to whoever controls that address.

Ten of the OAuth and OIDC vulnerability reports we read end that way. In none of them did the protocol fail. It ran perfectly and handed over the account anyway.

Over the past year, bug bounty platforms have reported a dramatic rise in AI-assisted, "slop" vulnerability submissions. Much of the discussion has centered on whether large language models are capable of discovering genuine vulnerabilities or whether they merely generate convincing-looking but ultimately meaningless reports.

A one-sentence message was enough to hijack accounts worth six figures on the resale market. A senior Space Force officer's Instagram account, the dormant Obama-era White House handle, and a six-figure username market all fell to the same three-month-old bug. The headlines called it prompt injection, but is that actually what happened?

In March 2026, Meta rolled out a fully agentic AI support assistant across Facebook and Instagram. This was not a chatbot that simply answers questions, but one with operational privileges, including the ability to act on account recovery requests directly. By February, attackers had already found the gap, and the exploit only needed a sentence.

The assumption baked into most agentic systems is simple: safety lives at the model layer, so that's where you defend. But model and tool layers don't share a threat model, and attackers who know that can walk straight through the gap. The Grok Bankrbot incident made it visceral. Morse-coded prompt injection. $175,000 moved in seconds. The community called it a model-layer problem and moved on. They were half right. In security, what does the other half cost you?

Your API has a bouncer. Very professional. Checks every ID at the door. Unfortunately, once you're inside, you can walk into the kitchen, rearrange everything, and delete someone else's reservation and he's still at the front door, extremely proud of himself.

Most security teams know what BOLA is. Broken Object Level Authorization, the vulnerability where an API doesn't verify that you're allowed to access the specific object you're referencing, not just the endpoint. It has sat at the top of the OWASP API Security Top 10 since 2019. There are guides, courses, and CTF challenges built around it.

And yet we analyzed over 100 validated, publicly disclosed bug bounty reports from HackerOne spanning 2021 to 2026, across 29 organizations including GitHub, GitLab, Shopify, Mozilla, and more, and found something that should give every security team pause.

The way most teams are testing for BOLA doesn't match how BOLA actually shows up in the wild. Here's what the data says.

First, a Quick Note on the Tag Noise​

One number worth flagging: roughly 39% of reports tagged IDOR or Improper Access Control on HackerOne don't describe BOLA under rigorous criteria. Wrong vulnerability class entirely, auth bypass without object reference, business logic on a user's own resources. If your team is using platform tag-counts to estimate BOLA exposure, you're likely overstating the signal significantly. Hence, these were excluded under the prefilter criteria of our research.

Finally, the 84 confirmed, in-scope reports are what everything below is drawn from. The full dataset, classification methodology, and analysis scripts are available on GitHub.

A developer sits down, opens their AI assistant, and asks a completely normal question:

“What are the open issues in my repo?”

Thirty seconds later, their SSH private key is on an attacker's server.

They never clicked a link.

They never ran a script.

They never left their IDE.

In our security research, we identified a command injection flaw in a GitHub MCP server which could enable remote code execution (RCE) on a developer's machine, with no user interaction beyond asking about open issues.

Modern e-commerce platforms increasingly rely on distributed API architectures to power web and mobile applications. But as architectures shift toward interconnected microservices, the most dangerous bugs are found in the way data flows in the applications.

Recently, we conducted a structured security evaluation of a large-scale e-commerce API ecosystem. Rather than focusing on isolated vulnerabilities, the research aims to identify systemic patterns of failure across authentication flows, parameter handling, and microservice interactions.

Our mission: to see if we could break the business rules of a production environment using nothing but an interception proxy and a bit of creative curiosity.