Why These Write-ups Never Name the Company

I find vulnerabilities in web applications and AI systems, report them privately to the companies that own them, and then write up what I learned. This blog is where those write-ups live.

You will not find a company name in any of them.

The rule

Every write-up is anonymised. No company name, no domain, no screenshot that identifies the target, no timeline detailed enough to fingerprint who it was.

This holds even after a fix has shipped. Even if the vendor was fast and professional. Even if the finding was interesting enough that naming it would get the post more attention.

Why

A patched bug is not the same as a safe company. Naming a company alongside a vulnerability creates a permanent, searchable association between that brand and the word "breach" — long after the underlying issue is gone. The engineering team fixed the problem. Publishing their name as a case study punishes them for it.

It makes companies less willing to engage. Security research only works when the vendor picks up the phone. The moment researchers become a reputational threat rather than an early warning, reports start going to inboxes that nobody reads, and legal gets involved instead of engineering. Anonymity keeps that channel open.

The lesson is rarely company-specific. What makes a finding worth writing about is the pattern — a trust boundary that looked solid but wasn't, an assumption about where untrusted input can reach. That pattern is reusable by every team reading it. The identity of the company that happened to hit it first adds nothing.

Disclosure timelines are not mine to set alone. Some fixes are quick. Some require architectural change and take months. Some findings touch a third-party dependency that other companies also use. Writing about the class of bug rather than the instance means I can publish something useful without pressuring anyone's release schedule.

What you will find here instead

Each write-up covers:

• The bug class — what category of flaw this was, in standard terminology
• The setup — enough architectural context to understand why the flaw existed, described generically
• The reasoning — what made me look there, and what the first signal was
• The impact — what an attacker could actually have done, stated honestly and without inflation
• The fix — what closed it, and what would have prevented it in the first place

That is everything a defender needs. The company name is the one detail that helps nobody.

How I work

The write-up is the last step, not the first. Before anything gets published:

1. Testing happens only inside a published bug bounty scope, a security.txt policy, or with written permission from the owner.
2. The proof of concept is the least intrusive one that still demonstrates real impact — no pivoting, no data exfiltration, no touching anything in production that I do not have to.
3. The vendor gets a private report with reproduction steps, honest severity, and a concrete remediation recommendation.
4. The fix ships.
5. Only then does a post appear here, anonymised.

If you are a company and you would like your systems looked at under this model, get in touch. Scope is agreed in writing before anything is tested.

Ongoing research notes go out on @jmadhanai.