Open Source Bug Bounty Paused: What to Do

When an open source project pauses its bug bounty program, you should first check the project’s official communication channels for the stated reason and timeline, then decide whether to continue reporting vulnerabilities through the project’s standard disclosure process or hold off until the program resumes. A pause usually means the maintainers are overwhelmed, restructuring, or out of funding, and it does not necessarily mean they stop accepting vulnerability reports — it just means they are not paying for them. The right move depends on why the program paused, how the project handles security reports, and what you hope to get out of your research.

Why Bug Bounty Programs Get Paused

Open source bug bounty programs are often run on a shoestring. They may be funded by a one-time grant, a corporate sponsor, or a platform like HackerOne or Bugcrowd that waives fees for critical projects. When that money runs out, or when the maintainers realize they cannot triage the influx of reports, they pause the program rather than cancel it entirely. Common reasons include:

• Funding exhaustion — the bounty pool is empty and no new sponsor has stepped in.
• Maintainer burnout — the team is spending more time triaging low-quality reports than fixing real bugs.
• Process overhaul — they are switching platforms, changing reward tiers, or rewriting their disclosure policy.
• Security audit in progress — they want to clear the queue before accepting new reports.

For example, the popular web framework Django has periodically paused its bounty program when the security team needed to catch up on backlog, and the Linux kernel’s bug bounty (run by the Linux Foundation) has been paused and restarted multiple times due to funding cycles. In most cases, the pause is temporary, but it can last months or even years.

How Bug Bounty Programs Normally Work

In a typical open source bug bounty, a researcher finds a vulnerability, writes a clear report with reproduction steps, and submits it through a designated channel — often a private email address, a security contact on the project’s website, or a platform like HackerOne. The maintainers triage the report, confirm the bug, and assign a severity score (usually based on CVSS). If the bug is valid and in scope, the researcher receives a monetary reward that scales with severity — from a few hundred dollars for a low-severity issue to tens of thousands for a critical remote code execution. The project also gets a public acknowledgment (a “hall of fame� listing) and often a CVE identifier.

When the program is paused, the reward money is gone, but the reporting channel usually stays open. The project still wants to know about vulnerabilities — they just cannot pay for them. Some projects explicitly say “we still accept reports, but we won’t pay bounties until further notice.� Others close the channel entirely and ask you to wait.

Immediate Steps to Take After a Pause

Here is a practical checklist for what to do the moment you see a “bounty program paused� announcement:

1. Read the announcement carefully. Look for a reason, a timeline, and any instructions about where to send reports in the meantime.
2. Check the project’s security policy. Most open source projects have a SECURITY.md file in their repository that explains how to report vulnerabilities confidentially. That policy usually remains in effect even when the bounty is paused.
3. Decide whether to report anyway. If you have already found a real vulnerability, the responsible thing is to report it through the standard channel, even without a bounty. The project will likely still fix it and credit you.
4. If you were mid-submission, ask the maintainers whether your existing report is still being processed and whether it will be eligible for a reward once the program resumes.
5. If you were planning to start a new hunt, consider whether the project’s scope and rules have changed. Some projects narrow the scope during a pause to focus on critical issues only.

Should You Keep Reporting During the Pause?

This is the central question, and the answer depends on your goals. If you are a hobbyist who cares about the project’s security, by all means keep reporting — the maintainers need your help now more than ever, and the goodwill can lead to a future paid role or a permanent spot in the acknowledgments. If you are a professional security researcher who relies on bounties for income, a pause is a strong signal to shift your time to projects with active programs. You can also use the pause as an opportunity to build a relationship with the maintainers: offer to help triage reports, write fixes, or improve their security documentation. That often leads to a paid contract or a full-time job.

One nuance: some projects pause the bounty but still pay for “critical� vulnerabilities on a case-by-case basis. If you find a truly severe bug (e.g., remote code execution, SQL injection, authentication bypass), it is worth asking whether they can make an exception. The worst they can say is no.

How to Choose Another Bug Bounty Program

If you decide to redirect your efforts, look for programs that are actively paying and have a good reputation. Here are the factors to weigh:

• Scope clarity — the program should clearly list which assets are in scope and which are out of scope.
• Reward consistency — check public disclosure reports to see if they actually pay the advertised amounts.
• Response time — a program that takes months to reply is not worth your time.
• Researcher treatment — look for programs that are known for fair triage and no “bounty huntingâ€� legal threats.
• Community size — a large, active community means more bugs are found quickly, but also more competition.

Platforms like HackerOne and Bugcrowd list thousands of programs, but many are invite-only. For open source specifically, the GitHub Security Lab runs a bug bounty for a curated set of projects, and the EU-FOSSA program has funded bounties for open source software used by EU institutions. You can also check the project’s own website — many maintainers announce bounties on their blog or mailing list.

Common Problems When a Program Is Paused

Researchers often run into the same issues when a program pauses:

• Unclear communication — the project forgets to update its security policy, so researchers are unsure if reports are still accepted.
• Lost reports — a report submitted just before the pause may sit in a queue for months without any response.
• Scope creep — during a pause, maintainers may quietly change what they consider a valid vulnerability, rejecting reports that would have been accepted before.
• No reward for past work — if you submitted a valid bug before the pause but the payout was pending, you may never receive it if the program is canceled entirely.

To protect yourself, keep a copy of your report and any correspondence. If the project goes silent, you can always publish your findings after a reasonable disclosure period (usually 90 days, but check the project’s policy). Responsible disclosure is not the same as a bounty program — you can still get a CVE and public credit even if you never get paid.

Alternatives to Paid Bounties

If you want to contribute to open source security without a bounty, there are several rewarding paths. You can join the project’s security mailing list and help triage reports, write security tests, or audit code for specific vulnerability classes (e.g., memory safety in C, injection in SQL). Many projects have a “security champions� program where volunteers get early access to fixes and direct contact with maintainers. You can also start your own security blog or write a detailed analysis of a recent CVE — that builds your reputation and can lead to paid consulting work. Another option is to participate in Google’s OSS-Fuzz, which pays small bounties for fixing bugs found by fuzzing, even if the main project’s bounty is paused.

Frequently Asked Questions

Will I still get a CVE if the bounty is paused?

Yes. CVE assignment is handled by the project’s security team or a CVE Numbering Authority (CNA), and it is independent of any bounty payment. If you report a valid vulnerability and the maintainers confirm it, they will typically issue a CVE and credit you in the advisory, whether or not you receive money.

Can I publish my finding if the project is unresponsive?

You can, but you should follow responsible disclosure practices. Wait at least 90 days from your initial report (or whatever the project’s policy states) before going public. If the project has not responded at all, you may want to reach out to a security mailing list like oss-security to coordinate disclosure and get a CVE.

Is it legal to keep testing a project after the bounty is paused?

Generally yes, if you are testing the project’s own infrastructure or code in a test environment. However, if the project’s terms of service or bug bounty policy explicitly prohibit testing during a pause, you should respect that. Always stay within the scope defined by the project’s security policy, and never test against production systems without permission.

How long do pauses usually last?

It varies widely. Some pauses last a few weeks while the team reorganizes; others last years if funding does not return. The best way to know is to watch the project’s blog, Twitter, or GitHub issues. If the pause is due to funding, it may end when a new sponsor steps in.

Should I ask for a bounty after the program resumes?

If you submitted a report during the pause and the program later resumes, it is reasonable to ask whether your report qualifies for a retroactive reward. Some projects honor that; most do not. The polite approach is to ask once, politely, and accept whatever they decide.

What if I find a critical bug during the pause?

Report it immediately through the project’s security contact, even if the bounty is paused. A critical vulnerability that is actively exploited is worth more than money — it is a chance to protect thousands of users. You can also mention that you are reporting despite the pause, and ask if they can make an exception for critical issues.

Related

• Evaluate AI-Generated Code Fixes Before Merging
• AI-Generated Database Queries: Read-Only Access
• AI Hyperscalers’ Storytelling Problem Explained