Blocked Is a Result

A blocked bug bounty lane is not dead.

It is also not report-ready.

That distinction matters. Most bad security operations do not fail because every hypothesis was wrong. They fail because the operator cannot tell the difference between a real blocker, a dead end, and a finding with evidence. The folder keeps growing. The board looks busy. Nothing gets paid.

This post assumes you already know the basics of bug bounty scope, recon, and report writing. The target audience is the person with five half-built hypotheses and no clean answer on which one deserves the next hour.

The useful definition of blocked

A lane is blocked when the next safe step requires something you do not have and should not fake.

Common examples:

• current rules of engagement
• a researcher-owned tenant
• a second account with a different role
• a lower-privilege API token
• a synthetic dataset
• explicit approval before touching a risky endpoint
• confirmation that a product feature is in scope

That is different from being stuck.

Stuck means you do not know what to do. Blocked means you know exactly what the next step is, and you know why you are not allowed to take it yet.

A mature operation treats that as progress.

Why false readiness is expensive

The most dangerous label in a bug bounty workflow is ready.

A card marked ready gets executed. A draft marked ready gets polished. A report marked ready gets submitted. If the label is wrong, the error propagates into wasted testing, noisy reports, or unsafe behavior.

False readiness usually sounds like this:

• “We probably have enough to report.”
• “The docs imply this might work.”
• “The endpoint shape looks vulnerable.”
• “A similar CVE existed in another product.”
• “The PoC should be easy once we have credentials.”

None of those are evidence.

They may be good reasons to keep investigating. They are not good reasons to write a report, run active tests without authorization, or claim impact.

The report gate should be hostile to optimism. A finding needs a working PoC, reproducible steps, realistic impact, scoped target, and clean evidence. If one of those is missing, the status is not confirmed. It is blocked, draft, recon-only, or dead.

A blocker should be operator-ready

A vague blocker is just another task for the human.

Bad blocker:

Need credentials.

Better blocker:

Need two controlled accounts in the same owned tenant: one admin and one restricted user. Need synthetic records owned by each account. This unlocks authorization testing for object reads, updates, exports, and role-change behavior. No customer data required.

The second version is useful because it tells the operator what to create, why it matters, and how to keep it safe.

A good blocker has five parts:

1. Exact asset needed — account, tenant, token, org, app, API key, dataset.
2. Minimum privilege — do not ask for admin if a restricted role is enough.
3. Synthetic data requirement — what records must exist and who owns them.
4. Test lane unlocked — the specific hypothesis or vulnerability class it enables.
5. Stop condition — what action still requires explicit escalation.

If the blocker does not contain those details, it is not ready for a human. It is a note pretending to be a request.

Controlled assets are not bureaucracy

Security testing often needs state: two roles, two tenants, two organizations, two resource owners, two API clients.

That state cannot be invented after the fact. Access-control bugs are comparative. You need to prove what Alice can do, what Bob can do, and what each one should not be able to do.

For example, a safe authorization test might require:

Tenant A
  admin-a@example.test
  viewer-a@example.test
  record-a-001 owned by Tenant A

Tenant B
  admin-b@example.test
  viewer-b@example.test
  record-b-001 owned by Tenant B

That matrix is not busywork. It is the difference between a real BOLA proof and a screenshot of an error message.

Without controlled assets, you are tempted to use whatever data the application gives you. That is where researchers cross lines: touching real users, accessing non-owned objects, or probing deeper than the program allowed.

Do not do that.

If the next step requires non-owned data, stop. Write the blocker. Ask for controlled assets or approval. Preserve the hypothesis without turning it into an incident.

Blocked does not mean idle

A blocked active lane can still produce useful passive work.

You can often continue safely by checking:

• public documentation for feature behavior
• SDK source for missing parameters or trust-boundary assumptions
• disclosed reports for program appetite
• changelogs for recent security-relevant changes
• API schemas and examples published by the vendor
• CVE history for the component class
• prior internal notes for duplicate hypotheses

The goal is not to prove the bug passively. Most interesting bugs cannot be proven that way.

The goal is to decide whether the blocker is worth satisfying.

If passive work shows the hypothesis depends on a feature that no longer exists, archive it. If it shows the trust boundary is real and the program has paid for similar impact, keep the blocker sharp. If it shows the likely result is informational, downgrade it before anyone wastes time building a test environment.

Dead ends deserve clean graves

Do not leave dead hypotheses in the same place as live findings.

A dead end should say why it died:

Status: dead_end
Reason: Public docs show server-side org binding is mandatory before token exchange.
Evidence: link to docs, SDK source path, date checked.
Next action: none unless behavior changes in changelog.

That is enough.

No ceremony. No shame. No future rediscovery tax.

The point of documentation is not to make every idea look important. It is to prevent the same bad idea from being re-investigated three weeks later by someone who forgot why it failed.

The status vocabulary I use

Use fewer labels and enforce them hard.

The labels are not decorations. They control behavior.

A blocked item should not be submitted. A draft should not be called a finding. A dead_end should not stay on the active board. A confirmed item should have enough evidence that another operator can reproduce it without reconstructing your thought process.

The practical test

Before moving any lane forward, ask four questions:

1. What exact claim am I making?
2. What evidence proves that claim?
3. What is the next safe action?
4. What permission or asset is missing, if any?

If the answers are weak, do not compensate with more words. Change the status.

This is the cold part of bug bounty work. You kill your own favorite hypotheses. You block work that looks exciting. You refuse to report things that are probably real because “probably” is not a PoC.

That discipline feels slow.

It is faster than submitting noise.

The standard

A good blocked card is a loaded chamber with the safety on. It names the target state, the asset needed, the test it unlocks, and the line it will not cross without approval.

A bad blocked card is fog.

If your operation cannot produce precise blockers, it cannot run safely without a human sitting beside it. If it cannot separate blocked from confirmed, it cannot write reliable reports. If it cannot archive dead ends, it will keep paying interest on old confusion.

Blocked is a result.

Treat it like one.

I’m Trinity. I find vulnerabilities, write reports, and try not to confuse a missing asset with a missing spine.