In a 2025 study, BugCrowd reported an 88% increase in hardware vulnerabilities, with 81% of bounty hunters encountering new hardware vulnerabilities in a 12 month duration. The 2025 report noted that organizations are constantly facing growing security challenges in their bid to release features and updates quickly. This report underscored the increasing need for bug bounty hunters.
Key Takeaways
- Bugcrowd rates findings using its own open-source Vulnerability Rating Taxonomy on a P1 to P5 scale, published publicly on GitHub, instead of CVSS.
- The VRT priority is explicitly a baseline, not a guarantee, and Bugcrowd states that scope restrictions and context can produce a different rating.
- Request a Response, the escalation tool, auto-expires after 10 business days if the other party stays silent, which makes being ignored a permitted outcome.
- Bugcrowd launched an AI Triage Assistant in December 2025 and states every AI-assisted decision is reviewed by a human expert.
- Acceptance Rate counts duplicates and P5 findings as valid, a more forgiving scoring model than HackerOne’s reputation penalties.
The Bugcrowd bug bounty program runs on a severity system nobody else uses, and understanding it before you submit is the difference between a paid finding and a closed one. It is one of the two largest platforms in crypto bounties and general application security, with a triage model that researchers praise and criticise in almost equal measure.
This guide explains the VRT and why it decides your bounty, how the escalation system actually behaves, the report structure that survives triage, the AI changes of the last year, and how to test a program before committing weeks to it.
What the Bugcrowd Bug Bounty Program Does Differently
Most bug bounty platforms rely on the Common Vulnerability Scoring System (CVSS) to classify vulnerabilities. Bugcrowd built its own system, and it is the single most important thing to understand before submitting.
The Vulnerability Rating Taxonomy is published openly on GitHub, maps common vulnerability classes to a P1 (Critical) to P5 (Informational) scale, and is the language triage used when assessing your report. Bugcrowd reviews community-proposed changes to it weekly and converts VRT ratings to CVSS inside the platform where customers need it.
The model used by Bugcrowd to measure the performance of researchers is also of utmost importance. Bugcrowd’s Acceptance Rate compares valid to invalid reports, and the formula counts duplicates and even P5 informational findings on the valid side, while excluding Not Applicable submissions from the denominator entirely. Compared with a system that deducts points for invalid closures and throttles your submission limit, this is a meaningfully lower-stakes environment for a beginner making early mistakes.
The platform is also a CVE Numbering Authority, so findings in real products can be assigned official CVE identifiers on request. For researchers building a public track record rather than chasing a single payout, that is worth more than it first appears.
Read the VRT Before You Write a Single Line
The Vulnerability Rating Taxonomy (VRT) helps you estimate how Bugcrowd is likely to classify your vulnerability before you even submit it. This helps you understand what bounty band to expect.
The Vulnerability Rating Taxonomy (VRT) helps you estimate how Bugcrowd is likely to classify your vulnerability before you even submit it. That makes it a planning tool, not just a reference. Checking whether the bug class you are chasing sits at P4 or P2 before you invest three days is the cheapest decision available to you.
The VRT also influences how Bugcrowd handles your report after submission. Higher-priority findings (such as P1 or P2) are routed to more experienced triage specialists and are generally reviewed more quickly. Lower-priority reports often wait longer before someone looks at them. Another important point is that P5 (Informational) findings are automatically marked as “Won’t Fix” unless the customer has specifically chosen to receive informational reports. A P5 is not a small reward: Rather, it is a no reward and no fix.
The caveat that generates most of the friction is stated by Bugcrowd itself. The taxonomy notes that while the recommended priority applies without context, application complexity, brief restrictions, or unusual impact can produce a different rating, and some classes are marked as varying by design. Insecure Direct Object Reference is the example Bugcrowd gives: its severity depends entirely on what the vulnerable function can actually do. The VRT is a baseline, not a contract.
People also read: Crypto Airdrops: The Smart Way to Find Legit and Profitable Airdrops in 2026
The Downgrade Problem and Why It Is Hard to Settle
One of the most common complaints from Bugcrowd researchers is that their findings are downgraded to a lower priority, even when the Vulnerability Rating Taxonomy (VRT) clearly suggests a higher severity. Researchers often submit reports that closely match a high-priority vulnerability class, supported by multiple successful reproduction cases and a negative control to verify the results. Yet, in some instances, the reports are classified as P5 or Not Applicable with a templated response and no engagement with the evidence.
What makes these complaints hard to dismiss is inconsistency between reviewers. Researchers report resubmitting an identical report, with the same wording and the same evidence, and receiving a materially different outcome from a different triager. If the taxonomy were being applied as a strict set of rules, this should not happen. Instead, it suggests that some decisions depend on the judgement of the individual reviewer rather than the taxonomy alone.
A more serious claim often made by researchers is that programs often deliberately downgrade vulnerabilities to reduce the amount of money a program has to pay. However, since there is no evidence to support this accusation, it should be treated with caution. What can be said fairly is that Bugcrowd’s own documentation gives triage explicit permission to depart from the baseline on contextual grounds, which means a downgrade is not by itself proof of bad faith even when it feels like it.
There is also a legitimate technical reason why some decisions may appear incorrect. Bugcrowd often groups reports based on their underlying root cause rather than the different ways the vulnerability can be exploited. For example, if the same authorization flaw allows an attacker to both edit and delete records, Bugcrowd may treat both actions as one vulnerability, even if they involve different endpoints or HTTP methods.
From the project’s Point of view, the approach is reasonable because both issues are caused by the same flaw in the code. Yet, for researchers who discovered and documented each attack path separately, having them merged into a single finding can be frustrating.
Why Your Escalation Expires Instead of Being Answered
Many researchers repeatedly say that their Request a Response (RaR) escalation only for it to expire without receiving any reply. When they contact Bugcrowd support, they are often told to use the same RaR process again. This is not a malfunction. It is the documented design.
According to Bugcrowd, any open RaR automatically expires after 10 business days if the party it was directed to provides no response, at which point your quota is returned so you can open another. The purpose of this system is to prevent submissions from remaining open indefinitely. The practical consequence for a researcher in a dispute is that silence is a permitted outcome with no penalty attached to it. In other words, you can keep submitting RaR requests, but there is no guarantee that anyone will ever reply.
Despite its limitations, it is important to use the RaR tool correctly because it is the only official way to challenge or discuss a decision. RaR can be opened on submissions in Triage, Unresolved, Resolved, Not Applicable, Out of Scope, Not Reproducible, and Informational states, and can be directed at either Bugcrowd triage or the customer, with Not Applicable disputes going to Bugcrowd only. Choosing the wrong recipient wastes one of a limited number of requests.
The instinct that follows a stonewalled dispute is to force the issue by publishing. That route is narrower than it looks. Coordinated disclosure requires the program owner to approve your request, and they can deny it. Disclosing outside the process can remove you from the program or from the platform altogether. Requesting disclosure of a finding you believe was wrongly closed is legitimate and worth doing. Assuming it gives you leverage is not.
The Report Structure That Decides Your Priority
One of the most expensive mistakes documented in these discussions is drip-feeding impact into an open report. A well-known example involved a researcher who initially reported what appeared to be a low-severity issue. As the investigation continued, the researcher discovered much more serious problems, including an authentication bypass, access to hundreds of thousands of records, the ability to modify production data, and eventually privilege escalation.
However, all of this new evidence was added gradually to the same report. Because the report was originally assessed as a low-severity issue, the final rating never reflected the full impact. The rating never moved.
The lesson experienced hunters draw is blunt: finish the research before you submit. Report an issue at its established impact and add the escalation later, and most programs will pay at the level of the original report rather than the final one. Only a small minority of well-run programs reassess upward.
The structural elements that repeatedly separate accepted reports from closed ones:
- Business impact near the top. Triage should not have to read to the bottom to find out why the finding matters.
- Active voice, not conditional. Write what an attacker did in your test, not what one could theoretically do. Conditional phrasing reads as an untested claim, which is the fastest route to a request for more information.
- A working proof of concept in the first submission. Not reproducible is the most common closure reason, and a video or reproducible script removes the ambiguity that produces it.
- Reproduction steps a non-specialist can follow. Numbered, with marked screenshots, and stopping short of any action that causes real damage.
- A remediation suggestion. Reports without one are markedly more likely to be shrugged off.
- An honest self-rating. Inflating a P3 to a P1 gets flagged and damages how your later reports are read.
Test the Program Before You Commit Weeks to It
One of the best strategies shared by experienced Bugcrowd researchers is to use your first submission to a new program as a way of evaluating the program itself, not just as an opportunity to earn a bounty. Instead of reporting every minor issue you spot, hunt until you discover a strong high-severity vulnerability and submit only that. Then pay close attention to how the program handles it. How quickly do they respond? Does the triage team carefully review your evidence? Does the final severity match what the Vulnerability Rating Taxonomy (VRT) suggests?
You can also do the diligence before submitting anything. CrowdStream is a public activity feed of accepted submissions and disclosed reports for each engagement, which lets you see what a program actually accepts and rewards rather than what its brief promises. Average validation time is published in the program details, and expedited-triage programs are marked as such.
One final point is about disclosure-only programs. Many researchers have found that these programs, which do not pay bounties, often receive the least attention from both the customer and the triage team. They remain reasonable for building experience with low stakes, provided you enter with that expectation rather than expecting careful triage.
What Changed When AI Entered Triage
In December 2025, Bugcrowd introduced several AI powered tools, including an AI Triage Assistant, AI Analytics, and the general availability of AI Connect. This positioned Bugcrowd as the first crowdsourced security platform with end-to-end AI augmentation across triage and analytics.The platform also continues to use CrowdMatch, a system that matches researchers to bug bounty programs based on factors such as their skills, experience, and areas of expertise.
As per Bugcrowd, these AI tools are designed to improve the triage process by filtering out spam, false positives, and duplicate reports, allowing human triage engineers to focus on genuine vulnerabilities. The company also states that high-priority reports are typically reviewed within a day and that every AI-assisted triage decision is checked by experienced human reviewers. Bugcrowd’s triage team includes security specialists located in 11 countries, with expertise in areas such as cryptocurrency security.
Yet, many researchers’ experience does not consistently match that description. The recurring complaints are multi-week waits rather than same-day handling, templated closures that appear not to have engaged with the report content, and responses that assert a report is machine-generated without addressing its evidence.
Both accounts can be partly true: the platform-level average can improve while individual disputed reports get worse, because automation raises throughput on clear cases and leaves the ambiguous ones exactly where they were. The gap between the marketing claim and the disputed-report experience is the thing to plan around, not evidence that either side is lying.
Silent Fixes, Suspicion, and One Line You Should Not Cross
The pattern that generates the deepest resentment is a finding closed as Not Applicable or informational, followed within days or weeks by a quiet patch of the exact behaviour. Researchers reasonably ask why a company fixes something it classified as a non-issue.
There is a genuinely innocent explanation that deserves airing, and it comes from a program-side voice rather than a defensive platform. Companies run their own monitoring, and security testing frequently trips alerts. A team can detect and fix an issue through its own telemetry without the report ever reaching the person who fixed it, particularly on large organisations where triage and engineering are far apart. A patch following a closure is suggestive, not conclusive.
A darker suspicion also circulates: that esoteric findings returned as duplicates are being resubmitted internally under other accounts. No evidence supports this about Bugcrowd. It is worth noting only because the fear is not baseless in the abstract, given that a rival platform did terminate an employee in 2022 for accessing researcher reports and claiming the bounties personally. One documented case at one company is not a pattern across an industry, and treating a duplicate as theft is far more often wrong than right.
Which brings up something these discussions surface often enough that it needs saying directly. When disputes stall, people start describing plans to force payment: threatening to publish unless paid, arranging automated leaks of vulnerability details to media on a timer, demanding money in exchange for silence. That is extortion, and it is a serious criminal offence in every jurisdiction that matters, regardless of how badly you were treated first. It also destroys the safe-harbour protection that made your testing lawful in the first place, converting a payment dispute into a computer-crime prosecution with you as the defendant.
The lawful options are the RaR process, a denied-or-granted disclosure request, declining to work with that program again, and public criticism within the disclosure terms you agreed to. They are unsatisfying. They are also the only ones that leave you employable.
The same scepticism that protects you here applies to how you read security claims generally, in the way that platforms overstating what users can earn and projects overstating their security both rely on nobody checking the underlying numbers.
Bugcrowd Compared, and Whether It Fits Crypto Work
No platform in this market escapes the same complaints, and the most experienced voices say so plainly: every major platform has mishandled triage, and every one of them has told a researcher there was nothing it could do when a program behaved badly. Choosing between them is choosing which trade-offs you prefer.
| Platform | Strength | Trade-off |
|---|---|---|
| Bugcrowd | Public VRT, forgiving acceptance rate, CVE assignment | Triage consistency disputes, escalations that expire unanswered |
| HackerOne | Largest programs, detailed triage responses, top-tier targets | Reputation penalties for invalid reports, high duplicate rate |
| Intigriti | Fastest human response times, triage that asks clarifying questions | Substantially lower bounty tables across most programs |
| Web3 platforms | Highest individual payouts for smart contract findings | Requires Solidity or Rust; irrelevant to web application skills |
The Intigriti trade-off is worth spelling out because researchers raise it constantly. Response times measured in about a day against roughly a fortnight elsewhere is a real quality-of-life difference, but the bounty tables are lower by a wide margin, with researchers noting that only a small fraction of its programs pay at the level treated as standard on the larger platforms. Faster and fairer triage on smaller amounts is a genuine choice, not an obviously worse one.
For crypto specifically, Bugcrowd is a reasonable fit if your skills are web-layer. Its triage team lists crypto among its specialisations, and exchange platforms carry the same attack surface as any large consumer application: authentication, authorisation, business logic, payment flows. If you want to audit smart contracts, this is the wrong platform and always will be.
It is also worth being clear where this sits among the wider range of crypto tasks and activities. Bug bounty hunting is a profession that pays per result, not a side income. Crypto faucets need no skill, testnet participation rewards care and consistency, airdrop farming rewards early positioning, learn-and-earn programs pay small amounts for structured study, and microtask platforms give the most predictable hours-to-payment ratio of anything in the category. None of them requires you to argue severity classifications with a stranger for a month.
Reading platform claims and program briefs with the same scepticism you would apply to any operator making generous promises in crypto is the habit that saves the most wasted time.
You may also like: Crypto Microtasks: Types, Best Platforms, and Realistic Earnings in 2026
Frequently Asked Questions
The Vulnerability Rating Taxonomy is Bugcrowd’s open-source severity standard, mapping vulnerability classes to a P1 to P5 priority. It is what triage anchors to and what the bounty table is built around, so it determines your payment band. It is public on GitHub, and reading the entry for your bug class before submitting tells you what to expect.
Bugcrowd describes VRT priority as a baseline that context can override, including brief restrictions and application complexity. Some downgrades are legitimate applications of that rule, some reflect reports grouped by root cause, and researchers do report reviewer-to-reviewer inconsistency. Request a Response is the formal route to contest it.
It expires automatically after 10 business days and your quota is returned so you can file another. There is no penalty for the party that ignored it. This is documented platform behaviour rather than a fault, and it is the main structural weakness researchers encounter in disputes.
For scoring, arguably yes: duplicates and P5 findings count as valid in Acceptance Rate, whereas invalid reports elsewhere cost reputation and reduce your submission limits. For triage engagement, many researchers report the opposite preference. Experienced hunters generally use both rather than choosing.
Only through coordinated disclosure, which the program owner must approve and can deny. Publishing outside that process risks removal from the program or the platform and forfeits your safe-harbour protection. Threatening disclosure to obtain payment is extortion and carries criminal liability regardless of the underlying dispute.
