Kahu Labs Research
How systems actually fail.
Field notes from Kahu Labs' security work. Each piece takes one real failure we found in an authorized assessment and explains the idea behind it: the assumption that broke, why the obvious defense missed it, and how to build the control correctly. Details are anonymized; the engineering is not.
Notes
11 publishedAn identifier is not proof of ownership
The same access-control bug keeps returning under different names. It comes from treating the act of naming an object, or holding an identity, as permission to use it.
The trust boundary hidden inside generated links
When your software builds a URL out of user-influenced input and then sends it under your own name, it has quietly moved a security boundary into a string.
Your secrets are in the browser
The most common critical finding in our work is not exotic. It is a production key shipped inside front-end code, where anyone with a browser can read it.
Why input validation is the wrong mental model for injection
SQL injection, path traversal, and template-injection code execution look like three different bugs. They share one root cause, and it is not a missing filter.
The request failed. The work didn't.
Two of the most serious server-side flaws we have found came from work that kept running after the request that started it had already returned an error.
What a password change must actually do
Changing a password is not a form submission. It is a revocation event, and a system that leaves old sessions alive after it has not really changed the password at all.
Verification is an access-control primitive
Email confirmation and the default role a new account receives look like onboarding details. They are access-control decisions, and getting them wrong hands out identity or privilege for free.
Old problems, new surface: security in AI systems
The AI features we test fail in familiar ways first. Before the model-specific risks, they miss authorization, expose internal endpoints, and trust their own inputs.
Two moderate assumptions, one serious path
The highest-impact findings are rarely a single dramatic bug. They are two or three reasonable local decisions that meet at a seam nobody owned.
Rate limiting is a business-logic control
Rate limiting gets treated as a defense against brute force and little else. In practice it protects workflows, and the workflows it protects are not obvious from a single request.
Authenticating the interface is not authenticating the system
A login screen protects a login screen. When the API behind it will answer without the same checks, the gate is on the door and the wall has a hole.