This content originally appeared on HackerNoon and was authored by Offgrid Security
Been a while. We were busy hacking. Ethically, of course.
Over the last few months, we’ve been building Kira: an AI security agent that reviews code the way a security researcher does. Not by matching patterns or blindly flagging sinks, but by reasoning about exploitability. What assumptions does the system make? Where do trust boundaries shift? Which components interact in ways nobody modeled? And sometimes more importantly: which findings are technically real, but operationally irrelevant?
We started with benchmarks. Then we pointed Kira at real production systems.
That’s when a pattern became impossible to ignore.
Most security tooling still analyzes software the way applications looked five years ago: isolated files, isolated vulnerabilities, isolated sinks.
But modern vulnerabilities rarely live inside a single component anymore.
They emerge in the seams between otherwise correct systems.
The sanitizer works. The middleware works. The webhook handler works. The ORM works. The auth layer works.
The exploit appears when all of them interact.
These are the failure patterns we keep seeing across real codebases that had already passed static analysis, manual review, and sometimes multiple security audits.
\
The Seam Is the Vulnerability
Sanitization Boundary Collapse
One SaaS platform imported JSON from a government GIS endpoint into an internal database.
The pipeline applied two sanitization layers:
- SQL escaping before query construction
- Shell escaping before execution
Individually, both implementations were correct.
Both passed review.
But the SQL query string was later embedded inside a Bash command. Inside Bash double quotes, constructs like `...` and $() still execute. Neither sanitizer accounted for shell interpolation semantics in that context.
The payload flowed cleanly through both sanitizers and executed as shell code before it ever reached the database.
Result: remote code execution on a machine containing production database credentials in .env.local.
Nobody reviewing any single layer would have caught it.
Because no individual component was broken.
The composition was.
Blast Radius Blindness
The endpoint looked harmless:
GET /api/health
No authentication. No rate limiting. Dynamic rendering is forced on every request.
The codebase already had a perfectly functional rate limiter applied elsewhere. Nobody attached it here because “it’s just a health check.”
What engineers missed was the shared dependency graph behind the endpoint.
That same database connection pool also powered:
- payment processor webhooks
- SMS delivery
- accounting integrations
Flood the health endpoint, exhaust the pool, and suddenly, payment confirmations begin failing. Retries pile up. Accounting pipelines stall. Revenue-critical workflows degrade because of an endpoint nobody considered sensitive.
Every individual fact was mundane.
The attack only became visible when the system was analyzed as a connected graph instead of isolated files.
Kira traced shared resource contention across code paths that had never appeared in the same pull request.
Calibration Is a Security Feature
One finding involved a third-party Python library vulnerable to path traversal.
Classic sink:
path = os.path.join(base_dir, api_key)
Most scanners classified it as HIGH severity.
Kira explicitly downgraded it.
Why?
Because api_key was typically sourced from static developer configuration, not attacker-controlled input. Exploitation required an application pattern that was technically possible but operationally uncommon.
The vulnerability was real.
The practical blast radius was narrow.
That distinction matters.
Security tooling that screams HIGH severity on every path traversal eventually destroys its own signal quality. Engineers stop trusting it. Important findings drown in alert fatigue.
Sometimes intelligence means saying:
“This is a real bug. It’s just not your biggest fire.”
\ Most tooling still cannot do that.
Impact Inversion
A stablecoin remittance backend contained five hardcoded secrets.
Static analysis flagged them and focused on an admin endpoint that supposedly leaked credentials in an HTTP response.
It didn’t.
An engineer manually tested the endpoint, saw a normal payload, and closed the ticket.
But buried in source control was the JWT signing key for the entire platform.
Anyone with repository access could forge administrative tokens in a few lines of Python.
From there:
- fake KYC approvals
- fabricated settlements
- unauthorized bank payouts
The scanner detected the credential.
It completely misunderstood the impact.
Kira rejected the original framing, identified the JWT signing key as the critical issue, and reconstructed the full attack chain across multiple systems.
Detection is easy.
Knowing which finding actually matters is the hard part.
Authorization Evaporation
This one was subtle.
An organization admin endpoint validated organization_id in middleware before allowing bulk user updates.
The middleware was correct.
But organization_id was not declared in the Pydantic request model.
Pydantic silently dropped the field during parsing.
The handler never saw it.
The authorization boundary enforced upstream effectively evaporated before the write operation occurred.
At the same time, user_role flowed through an update helper without any privilege escalation checks.
The result:
A single API request allowed an org admin to promote arbitrary users across every tenant on the platform to proxy admin.
Not just within their own organization.
Across all organizations.
Every layer independently appeared correct:
- middleware logic
- request parsing
- handler implementation
The failure emerged from incompatible assumptions between frameworks.
Traditional static analysis does not reason about semantic framework behavior deeply enough to catch bugs like this. Most tools do not understand that undeclared Pydantic fields disappear silently, much less connect that behavior to an upstream authorization guarantee.
These are the kinds of vulnerabilities that survive for years precisely because every individual component passes review.
\
Compositional Vulnerabilities
One of these bugs came from an open-source security agent released by a well-known vendor.
Another from a lightweight LLM proxy widely deployed in production.
Others came from popular open-source infrastructure software.
All had passed static analysis.
All had passed manual review.
Most were already running in production environments.
What Kira consistently performs best at is the category where traditional pattern matching fundamentally breaks down:
- incorrect impact framing
- vulnerabilities between correct components
- blast radius propagation across unrelated files
- framework semantic mismatches
- protocol logic failures with no clear ownership boundary
We’ve started referring to these as compositional vulnerabilities.
Not broken components.
Broken assumptions between components.
That distinction matters because modern software increasingly behaves like interconnected infrastructure, not isolated applications. Security tooling built for single-file reasoning struggles in systems where exploitability emerges from interaction effects.
Of course, reasoning-heavy systems have their own failure modes too.
Kira still gets things wrong.
There are false positives. There are entire bug classes where deterministic analysis still outperforms AI reasoning. There are situations where confidence exceeds correctness.
We’re documenting those next.
Because understanding where AI security systems fail is becoming just as important as understanding where they succeed.
If you’re a security researcher and want to test Kira on real code, reach out.
And if you’ve seen vulnerabilities your tooling completely missed, drop them in the comments.
This content originally appeared on HackerNoon and was authored by Offgrid Security
Offgrid Security | Sciencx (2026-05-12T11:09:14+00:00) 1970 exploitable findings later.. Retrieved from https://www.scien.cx/2026/05/12/1970-exploitable-findings-later/
Please log in to upload a file.
There are no updates yet.
Click the Upload button above to add an update.