Kahu Labs Research
How systems actually fail.
Field notes from Kahu Labs' security work. Each piece takes one real failure, either one we found in an authorized assessment or one another organization disclosed in a public incident report, and explains how it happened and what to check. Findings from our assessments are anonymized. Public incidents are read from the published record, with each claim labeled by its source.
/how they got in
1 publishedPublic incidents, read from the organization's own disclosures and the investigation reports it published, with what other teams can check.
Notes
13 publishedHow they got in: Bitget, September 2026
Bitget says an attacker moved about $387.5 million out of part of its hot and warm wallets on September 25, 2026 (UTC+8), by sending fraudulent withdrawal commands to its own wallet system. A plain reading of the two preliminary reports, where they differ, and what other exchanges can check.
Where India's smart-camera apps point: a client-side infrastructure study
We mapped the backend hosts that 27 camera apps sold in India reference. Which infrastructure those hosts resolve to has little to do with whose name is on the box.
An 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.