OWASP Foundation

Report a security issue

OWASP runs hundreds of open source projects and the websites that support a global community. If you have found a weakness in one of them, this page tells you where to send it and what we will do with it.

Report an issue Disclosure program What happens next Advisories Project leaders Contact

Choose the right path

A useful report reaches the people who can fix it. Use the path that matches what you found. When in doubt, submit through the VDP rather than posting in public.

OWASP websites and services

Issues in Foundation-operated sites, community platforms, and related infrastructure should go through the Vulnerability Disclosure Program. The Bugcrowd brief is the source of truth for what is currently in scope.

Use the VDP

OWASP open source projects

Start with the project repository. If it has a SECURITY.md file or GitHub private vulnerability reporting, follow those instructions. If it does not, submit through the VDP so we can route the report to the project leaders.

Browse projects→

Training and deliberately insecure apps

Projects such as Juice Shop and WebGoat are built to contain vulnerabilities for learning. Do not report those intended flaws. Do report problems in the project’s own packaging, release process, documentation site, or maintainer tooling.

See how we handle reports→

What to include

Incomplete reports slow everyone down. A short, reproducible write-up is more useful than a long theory.

1The affected site, service, repository, or project, including a URL or version where you can.
2A clear description of the issue and why it matters.
3Steps another person can follow to reproduce it.
4What an attacker could do if the issue is real.
5Whether the finding is already public, and any related CVE or advisory.

Please do not

Open a public issue or pull request that describes an unfixed vulnerability.
Run denial-of-service tests, spam, or automated scanning that overwhelms a service.
Access, copy, or change data that is not yours.
Report missing security headers, version banners, or similar low-signal findings unless the VDP brief explicitly asks for them.

Vulnerability Disclosure Program

One private intake for OWASP

The OWASP VDP is how we invite researchers to tell us about weaknesses in Foundation systems and, where the brief allows, related community assets. It exists so reports are tracked, routed, and handled without the researcher having to guess who to email.

Submissions are made through Bugcrowd so both sides have a record of the report.
It is a disclosure program. There is no bounty table on this page; check the live brief for any recognition that may apply.
Only test assets the brief lists as in scope. If a target is not named there, assume it is out of scope until we say otherwise.

Submit a report

Create a Bugcrowd account if you do not have one, read the OWASP engagement brief, then file the report there. That is the channel we monitor.

Open the Bugcrowd brief

Questions about the brief itself can go to Bugcrowd support. Questions about OWASP process that are not a vulnerability report can go to security@owasp.org.

After you report

Foundation staff do not patch every project themselves. They make sure the right maintainers see the report, and they help when a fix needs to be coordinated or announced.

01
Send it privately
Use the VDP, or the project’s documented private channel. Do not open a public GitHub issue, post on Slack, or discuss the finding on social media while it is still unfixed.
02
We triage and route
Foundation staff review incoming reports and send valid issues to the people who can fix them: operations for Foundation systems, project leaders for open source code.
03
A fix is prepared
The owners confirm impact, ship a patch or configuration change, and agree when it is safe to talk about the issue in public.
04
Users are told
When people who rely on the software have a way to update, the project publishes an advisory or release note. Reporters who want credit are named unless they ask otherwise.

If you are a researcher

Stay inside the scope and rules published on the VDP brief.
Avoid testing that degrades service, destroys data, or touches other people’s accounts.
Do not demand payment, threaten disclosure, or use social engineering against staff or community members.
Keep the report confidential until we have coordinated public disclosure.

What OWASP will do

Good-faith research that follows the VDP terms will not be treated as a hostile act.
We will keep reporters informed as a report moves from intake to fix to disclosure.
We will credit researchers who want to be named when an advisory is published.
The Bugcrowd engagement brief governs rewards, scope, and safe-harbor language for VDP submissions.

How OWASP approaches its own security

The Foundation’s job is to make it easier for volunteers to run trustworthy projects, and to give researchers a straight path when something still goes wrong.

Coordinated disclosure

We give maintainers time to fix real issues before details are made public, and we work with reporters on timing.

Project security hygiene

Project leaders are asked to keep repositories, secrets, and release artifacts in good order, and to document how they want reports delivered.

Education as defense

OWASP’s public projects, guides, and training exist so builders and defenders can find and fix weaknesses before they reach production.

Clear public advisories

When a fix is ready, projects should say what was wrong, who is affected, and what to do next—without hiding behind silence.

Advisories and known issues

OWASP does not keep a single Foundation-wide catalogue of every project vulnerability. Fixes and write-ups live with the project that ships the code.

Look for GitHub Security Advisories, release notes, and CHANGELOG entries on the repository you use. If you depend on an OWASP tool or standard, watch that project—not this page—for updates.

A useful advisory says

Which product and versions are affected.
Which versions contain the fix.
What an attacker can do, in plain language.
Any workaround if you cannot update immediately.
A CVE identifier when one has been assigned.

Find a project→

If you lead an OWASP project

Researchers should not have to hunt for a contact. A short, public security policy saves everyone time and keeps sensitive details off the issue tracker.

Publish a SECURITY.md file that says how to report issues privately.
Turn on GitHub private vulnerability reporting where the project lives on GitHub.
Never ask people to file security bugs as public issues.
Tell users which versions are affected, which versions contain the fix, and any temporary workarounds.
Ask Foundation staff if you need help requesting a CVE or coordinating disclosure across several projects.

Talk to us

For vulnerabilities, use the VDP. Email is for process questions, not for attaching exploit details that belong in Bugcrowd.

Report via Bugcrowd security@owasp.org

This page is for security issues in OWASP’s own work. Product vulnerabilities in software that is not an OWASP project should be reported to that vendor. Chapter-run sites and third-party services are only in scope when the VDP brief says they are.