Just Blast 0day

I am @abraxas_null. I have stopped sending the bugs that matter into a bounty queue. The day I confirm one, I write the analysis and I release a PoC. Both go up together. The link goes on X. That is what blast means. I am writing it down because I do not want to be the only one doing it.

If you are holding a serious bug in a portal that has not read it, take it out. Write the analysis. Release the PoC. Post the link the day you are done. There is no list, no crew, and nothing to apply to. Call it a movement if you want a word for other people doing it in public. Joining is publishing your own.

What the inbox is now

A vendor security mailbox used to be a person who could read. It is a filter in front of a backlog, and the backlog is mostly machine output.

Models made bug reports cheap to produce and expensive to believe. The same week a real issue lands, so do hundreds of reports that look like reports: a summary, a severity, a request, and a trace the model invented or a scanner already sent twice. Triage did what overloaded triage does. Templates. Auto-replies. A status of received that means nobody has looked. A human, sometimes, after the week in which looking would have mattered. Interaction is minimal because interaction does not scale against slop, and the slop is not slowing down.

I do not blame an analyst for failing to read the four-hundredth PDF of the day. I blame the process for still pretending that PDF is how a critical bug in a revenue platform should arrive. The pipe built for a careful email cannot sort a firehose, and it treats the firehose and the real report as the same object. That is the sewer. Not the existence of bounties. The fact that the serious report dies in the same bucket as the generated one.

If your real report is in that bucket, you are not waiting on a process. You are waiting on a filter that was not built to notice you.

Scooped on their clock

The failure that ended my patience is not the size of the check. It is the race.

I send the report. I wait, because that is the rule. Triage has not started. Someone else finds the same bug, discloses it, and the advisory ships with their name on it. My ticket is still open. This has happened more than once recently. I am not going to name those bugs here. A name would be a second disclosure, and the point is not a particular vendor. The point is the race condition.

Independent rediscovery is normal once a bug is real and the product is widely deployed. You do not get to assume you are the only person looking. You certainly do not get to assume it after models made looking cheaper. The only variable the researcher controls is how long the report sits in a state called received. A queue measured in weeks hands the finding to the next person. You lose the credit. You lose whatever bounty was going to be offered. The people running the software did not get a faster patch. The researcher who followed the process lost to the researcher who did not.

That is not an edge case anymore. It is what the wait is for. If your ticket is still marked received while an advisory goes out under someone else's name, you have already seen it. Politeness did not buy the customers a faster patch. It bought the next researcher your bug.

A tip, not a price

The payout was designed for a different bug.

A missing header, a self-XSS, a CSRF on a settings page: the tables still describe that world, and some of those reports should still be filed. An unauthenticated issue in a product that bills customers is a different object. Used quietly, the downside is revenue, access, and whatever sits behind the login. Filed through the program, the upside is a few thousand dollars, a long silence, and a clause about not being difficult. I will say the line the way I have said it in private. A $5,000 bounty for a million-dollar exploit is not a negotiation. It is a decision not to buy the report.

People adapt. Some of them stop filing and sell the same report into places I am not going to describe, name, or help anyone find. I am not interested in the romance attached to that, and this note is not a door to it. I am describing the off-ramp the process built. When the legitimate price is a tip and the legitimate timeline is a coin flip against the next researcher, the dark market is what you get if the only other option is silence. Automated research makes more of those leftovers. The dilemma does not get smaller from here.

There is a third exit. Do not take the tip. Do not sell the report. Publish it. If you are already unwilling to do the first two, you are who this note is for.

The polite door

There is a civilized version of this complaint. It is worth saying plainly, because someone will offer it to you as the responsible compromise, and it is still the wrong fix.

Do not send the rare report to the triage desk. Send it through someone a company already has to answer. A journalist who can put the finding in front of a PR department, which can put it in front of a person allowed to spend money and ship a change. Not a new form. A lane for the report that is not slop: a critical issue, a researcher who has already done this work, a vendor who would rather hear it from a channel their executives read than read it later on a timeline. Above board, and out of the places where the same bug gets sold. The pressure is a story, which is the only pressure some organizations actually feel.

That lane should exist. For a report a bot cannot score, it is a better door than security@. I would use it if it were a door I could open myself, on my clock.

It is not. The journalist has an editor. The company has a lawyer. The lawyer has a quarter. None of them are in the race with the second researcher, and the second researcher is not waiting on the meeting. A side channel is a faster queue. The clock still belongs to someone else. The patch does not ship when the meeting is scheduled. It ships when someone decides the silence is over. Do not sit on your bug while you look for that someone.

Just blast it

This is what I am doing, and it is the part worth copying.

Skip the bounty queue. Publish the analysis and the PoC the same day. Not after a portal ticket ages out. Not after a thread with an auto-responder. Not after a polite introduction has been forwarded twice. The post and the proof are the disclosure. The patch clock starts when they are public, because that is the first moment the vendor no longer owns the calendar.

Responsible disclosure was a bargain. You wait, they patch, then everyone is allowed to talk. The bargain needs a reader on the other side who can tell a critical report from a generated one, answer inside the window before someone else finds the same sink, and pay in proportion to what the bug is. That reader is not who answers the inbox I am talking about. Keeping the bargain with a mailbox that does not read is not a duty. It is a gift of time to a company that already priced the work at the bottom of a table.

Blast is two artifacts, and neither is optional. The analysis is the map: product, version range, the vulnerable condition, the sink, the impact. The PoC is the proof that the map is not a story. It is public, and it demonstrates the bug. A write-up with no repro is another PDF for the pile. A PoC with no write-up is the scanner output that made the sewer.

Mine have a specific address, so the shape is not a mystery. The note lives on this site. The proof lives in a public repo under abraxas. X carries the link, not the whole disclosure. Yours do not have to live here. They have to be public, complete, and up the same day, under your name, somewhere the vendor's customers can open without asking you.

This essay is not a blast. It names no product and it ships no PoC. The next bug of mine that clears the bar goes out as a write-up and a proof, together. Not a riddle, not a teaser, not a promise to share the details with whoever asks nicely. Hold yours to the same rule. A hint is not a disclosure.

What earns it is a short list, and the list does not change because it is your bug instead of mine. The bug is real. You confirmed it. The impact is ugly relative to the payout on offer. The program will not answer, or it will answer with a number that treats the work as a tip. A missing cookie flag does not earn it. A duplicated scanner finding does not earn it. The generated report that filled the sewer does not earn it either. Adding another one is how the queue got this bad. That is not joining. That is feeding the queue you just decided to leave.

The bar is the bug a triage template cannot recognize, because recognizing it would take a person who understands the product and has the authority to act the same week.

A vendor who wants the quiet version already knows the terms. A human, in hours rather than weeks. A reply that shows someone read the report. A payout tied to the revenue and access the bug actually touches, not to a table written for a different decade. Received has to mean read. If a program does that, file the bug. I will. I have not been offered that program. A bot and a $5,000 table are not it. Do not donate the silence to those.

Do the same thing

I am not collecting reports, and I am not a broker for them. Do not send your bug to me. Do not wait until I have published one this week so the idea looks safer.

Confirm it yourself. Write the map to the standard you would want if you had to patch it: product, version range, the vulnerable condition, the sink, the impact. Release a PoC that makes the claim true in public, in a repo under your own name. Post the link the same day. Leave it up. A vendor can patch against a proof. They cannot patch against your patience, and neither can the next person who finds the same sink.

One researcher doing this is a complaint. Researchers doing it on the bugs these queues are failing is how the quiet inbox stops being the price of the work. I am already publishing this way, as @abraxas_null. If the last serious bug you found is still sitting in a portal, take it out and blast it.

Just blast the 0-day.