A week ago (July 9), GitLab lost $760 million in market value over authorization bugs. Two weeks ago (early July), 64 million McDonald's job applications leaked through a simple IDOR.
These aren't isolated incidents. They're symptoms of a crisis nobody's talking about.
We've been tracking authorization vulnerabilities across the industry. In our analysis of 1000 web application repositories, 73% of codebases examined contained authorization flaws - forgotten ownership checks, missing access controls, IDORs waiting to be exploited. Not in legacy code. In modern applications at companies you use every day.
The State of Authorization Security in 2025
Remember 2005? SQL injection was everywhere. Every pentest ended with a dumped database. Then frameworks evolved, parameterized queries became standard, and SQLi dropped from #1 to #3 in the OWASP Top 10. Bobby Tables became a meme, not the epidemic it once was.
Twenty years later, we're watching history repeat itself with authorization bugs.
OWASP's latest data shows 94% of applications have broken access control, making it the #1 security risk.
Since July 2024, we've been tracking authorization vulnerabilities across the industry through our ongoing security research. The results paint a disturbing picture:
Our Public Vulnerability Disclosures: - Authorization/Access Control Flaws: 53% of critical vulnerabilities - Traditional SAST Detection Rate: Near zero - Time to Find Manually: 2-4 hours per endpoint - Time to Find with LLMs: Minutes Our Broader Codebase Analysis: - Codebases with Authorization Issues: 73% (n=1000 web applications)
This isn't a tooling problem. It's a fundamental mismatch between how we build software and how we secure it.
Recent Authorization Failures in Production
The pattern is consistent across companies of all sizes:
- Multiple authorization bypasses (CVE-2025-4972, CVE-2025-6168, CVE-2025-3396)
- Users could bypass group-level restrictions on invitations and forking
- High-severity 2FA bypass (CVE-2025-0605)
- Stock price: -9.3% ($760M gone in 48 hours)
- Job portal accepted
123456:123456as valid credentials PUT /api/lead/cem-xhrendpoint exposed candidate data vialead_idparameter- Test applicant ID was ~64,185,742 - decrementing revealed other applicants' PII
- Result: 64 million job applications exposed
- Spyware company gets a taste of their own medicine
/getScreen.php?device={id}- no auth whatsoever- Result: 17TB of victim screenshots leaked
Assam Power Distribution, 2024:
- Endpoint:
/fetchConsumer?mobile_no={number} - 5.17 million electricity customers exposed
- Found by a security researcher on a lazy Sunday
Here's a sample of what we've discovered over the past year (many more remain under responsible disclosure):
| Date | Project | Vulnerability | Impact |
|---|---|---|---|
| Jan 22, 2025 | SuperAGI | File download endpoint with no ownership check | Any authenticated user could download ANY file in the system |
| Sep 2, 2024 | RAGFlow | 8 separate IDOR vulnerabilities | Delete anyone's conversations, access private knowledge bases, remove API keys |
| Sep 20, 2024 | Monaco (Hulu) | Unauthorized Redis access | Access to ALL Redis clusters administered by Monaco |
| Sep 3, 2024 | E2nest (Netflix) | Path traversal in model loading | Arbitrary file read via config manipulation |
| Oct 1, 2024 | LogAI (Salesforce) | Directory traversal via log paths | Access to sensitive system files |
Every single one of these boiled down to the same pattern:
# What they wrote: def get_resource(id): return Resource.query.get(id) # What they needed: def get_resource(id, user): return Resource.query.filter_by(id=id, owner_id=user.id).first_or_404()
One. Freaking. Line.
The McDonald's Incident: A Perfect Case Study
The McDonald's McHire breach (early July 2025) perfectly illustrates the problem:
- The Setup: Job application portal, millions of users
- The Bug:
PUT /api/lead/cem-xhrwithlead_idparameter - no ownership validation - The Auth: Hardcoded
123456:123456(yes, really) - The Discovery: Test applicant had ID ~64,185,742. Decrementing revealed other applicants' PII
- The Impact: 64 million applications exposed
The exploit was trivial:
for lead_id in range(64185742, 0, -1): data = requests.put("/api/lead/cem-xhr", json={"lead_id": lead_id}, auth=("123456", "123456")) save_to_db(data.json())
But here's the kicker: McDonald's probably ran security scans. They might have even had pentests. But nobody thought to ask: "What happens if I change this number?"
The Game Just Changed
For twenty years, finding authorization bugs required manual testing. Every endpoint, every parameter, checked by hand. It didn't scale.
Something shifted in 2024. Security researchers started feeding code to LLMs with a simple prompt: "Find places where user A can access user B's data."
The results were shocking.
Traditional SAST tools pattern-match. They can find SQL injection because it has a signature: user input + string concatenation. But they can't understand that get_document(id) should check ownership because that requires understanding intent.
LLMs can. They read code like a developer thinks about it. They understand that a function called download_file_by_id probably needs authorization. They can trace through middleware, understand business logic, and spot the missing checks.
Our research from 2024 showed LLMs could find complex logic bugs that traditional tools miss. Here are some examples from our year-long study:
SuperAGI (reported January 22, 2025): The file download endpoint accepted any file ID without checking ownership. Any authenticated user could iterate through IDs and download arbitrary files.
RAGFlow (discovered September 2024): Eight separate authorization failures in one codebase. Users could delete other users' conversations, access private knowledge bases, remove API keys - all through simple ID manipulation.
Monaco/Hulu (discovered September 2024): Exposed Redis access allowed any authenticated user to interact with all Redis clusters managed by the system.
The pattern was always the same: developers assumed the frontend would hide unauthorized options. They didn't.
Why 2025 Is the Breaking Point
Three trends are converging to create a perfect storm:
1. API-First Architecture
Modern apps expose hundreds of endpoints. Each one needs explicit authorization. Miss one, and you're breached. The attack surface has exploded.
2. Microservice Boundaries
Services trust each other by default. When Service A calls Service B, does B verify the request? Usually not. Each service boundary is a potential IDOR.
3. AI Can Now Find These at Scale
What used to take weeks of manual testing now takes hours. Both defenders and attackers have this capability. The race is on.
The McDonald's breach wasn't sophisticated. Someone noticed an endpoint, tried decrementing a lead_id parameter, and discovered access to 64 million records. But here's what should keep you up at night: an AI could have found that bug in minutes, along with hundreds more across thousands of applications.
The Path Forward
The industry solved SQL injection through framework defaults and cultural change. Authorization bugs require the same systematic approach:
Architecture patterns that work:
- Row-level security at the database layer
- Centralized authorization services (like Google's Zanzibar)
- Default-deny middleware that requires explicit grants
- Immutable, cryptographically secure identifiers
Cultural shifts needed:
- Treat every endpoint as hostile by default
- Include authorization testing in CI/CD pipelines
- Make ownership checks impossible to forget through framework design
- Assume attackers have AI-powered scanners (because they do) - if a vulnerability exists, it's not a matter of if but when it will be found and exploited
The simple fix that nobody implements:
# This should be enforced by your framework @require_ownership # Not optional def get_resource(id, current_user): return Resource.get_for_user(id, current_user)
Until these become standard practice, we're one curious researcher away from the next 64-million-record breach.
What Happens Next
The tools to find these bugs at scale now exist. LLMs can spot missing authorization checks with surprising accuracy. The question isn't whether these vulnerabilities will be found - it's who finds them first.
If history is any guide, we're about to see a wave of authorization-related breaches that will dwarf anything we've seen before. The McDonald's incident won't be the largest IDOR breach of 2025. It might not even make the top ten.
The only defense is to assume some endpoint in your application is vulnerable until you have proven otherwise. Because statistically, something probably is.
Appendix: The Numbers Behind the Crisis
Our Research Findings:
- 73% of 1000 web application codebases we analyzed had authorization vulnerabilities
- 53% of critical vulnerabilities in our public disclosures were authorization flaws
Industry Context:
- OWASP reports 94% of applications have some form of broken access control
- Average time to manually find first issue (from our testing): 2-4 hours
- Average time for LLM (ZeroPath) to identify and fix: ~40 minutes depending on the size of the codebase
For a detailed breakdown of our vulnerability discoveries and methodology, see our comprehensive analysis of 20+ zero-days found with AI.
The shift from manual to AI-assisted vulnerability discovery represents the most significant change in application security since the introduction of SAST tools. Whether this leads to more secure software or just more efficient exploitation remains to be seen.