← home

AI Audit Finds IDOR Vulnerability in Hermes-Agent, Similar to Lovable

April 14, 2026

Two AI platforms. One week. The same authorization failure.

Ten days before the Lovable breach went public, I pointed a frontier model at hermes-agent by Nous Research — an open-source AI agent framework, 383,000 lines of Python, 849 files — and asked it to audit authorization boundaries.

2 minutes 12 seconds later: 7 findings. 5 confirmed real. The highest severity: an IDOR on the response store, flagged 45 seconds into the audit.

Authentication present. Authorization absent. Any authenticated client could read any other client's conversation history — including tool call results containing file contents and credentials. 15+ endpoint handlers in a single 2,600-line file. The middleware validated the token. It never validated the scope.

Then on April 20, a researcher disclosed the exact same vulnerability class in Lovable — a platform used by employees at NVIDIA, Microsoft, Uber, and Spotify.

Five API calls from a free account. Full source trees. Database credentials. AI chat histories. Real names, real companies, real LinkedIn profiles from a Danish nonprofit's database. Not test data. Real people who had no idea.

The pattern is identical in both:

  • The system checks who you are
  • It never checks what you should be allowed to access
  • Change one identifier in the API call — get someone else's data
IDOR. The #1 API security risk in the OWASP Top 10. Well-documented for seven years. Trivially preventable.

What makes the Lovable case worse: the HackerOne report was filed March 3. Lovable triaged it. Then they patched new projects and left every existing project exposed. Same API, same endpoint, same session — one returns 403, the other returns 200 with the full source tree. 48 days later, nothing changed.

I re-verified our hermes-agent findings against the latest main branch today.

The codebase has grown 31% since the audit — 501,000 lines of Python. All five vulnerabilities still present. The response store still has no owner field. The _check_auth function still only validates the token — never the scope. Active development continued around the bugs without touching them.

Same pattern as Lovable. Development continues. Authorization gaps survive.

The question I keep coming back to: what would it take for an IDOR to not matter?

We found this pattern in 2 minutes with an AI audit. A researcher exploited it in 5 API calls. A HackerOne report sat triaged for 48 days. We re-verified 12 days later — the codebase grew 31% and none of the findings were fixed.

Every system will have bugs. The question isn't whether you have an IDOR. It's what gets exposed when you do.

If the answer is "one agent's delegated conversation history" — you have an architecture. If the answer is "source code, database credentials, and every conversation every user ever had with every agent" — you have a liability.

Same Bug. Different Architecture. Different Blast Radius.
The bug is the same. The damage is an architecture decision.

The Lovable breach didn't have to be this bad. It was this bad because nothing between the bug and the data was designed to contain it.