Report privately, never in a public issue. On GitHub, open the repository's Security tab, choose Report a vulnerability, and fill in a summary, details, a proof of concept and an impact statement. If private reporting is off, follow the project's security policy or ask maintainers for a private contact.
Why private first
A public issue tells every reader about a flaw before users can update. Maintainers need time to understand, fix and release. The Open Source Guides even note that keeping communication public is the norm for ordinary contributions, with an explicit exception for security issues and serious conduct problems.
Steps on GitHub
GitHub documents this flow for private vulnerability reporting.
- Go to the repository's main page.
- Click the Security and quality tab. If it is not visible, open the dropdown menu and choose it from there.
- Click Report a vulnerability to open the advisory form.
- If the repository has a security policy, read it, since it appears above the form.
- Fill in the form.
- Optionally mark that you used AI assistance to find or write up the report.
- Submit the report.
- Optionally start a temporary private fork to begin a fix. GitHub states that the maintainer is the one who can merge changes from that fork.
What to include
By default the form asks for a summary, details, a proof of concept and an impact statement. GitHub's guidance is to give enough detail for maintainers to reproduce and assess the issue. A useful report answers:
- Which versions are affected, as far as you can tell?
- What are the exact steps to reproduce?
- What can an attacker do, and under what conditions?
- Do you have a suggested fix?
Keep the proof of concept minimal and safe. Demonstrate the flaw on your own test setup, not on someone else's deployment.
If there is no private channel
If private reporting is not enabled, GitHub says to follow instructions in the repository's security policy, or to create an issue asking maintainers for a preferred security contact. That issue must not contain any detail about the flaw. Say only that you have a security report and want to know where to send it.
After you submit
Expect a human on the other side with limited time. Be patient and professional, answer follow up questions, and do not publish details until the maintainer has had a reasonable chance to fix and release. Our post on responsible disclosure explains the timeline norms.
A short report template
Write four short parts. Summary: one sentence naming the component and the flaw class. Steps: numbered, so a stranger can repeat them on a clean install. Impact: what an attacker gains and what they need first. Suggested fix: optional, one or two sentences. Keep the tone neutral and factual, since maintainers read many reports and often work in spare time. Attach nothing that contains real user data.
Quick check
Can I get a CVE for what I found?
That is decided through the maintainer and the advisory process, not by the reporter alone. Ask in the private thread.
Should I post on social media while waiting?
No. Keep the details private until a fix is released and the maintainer agrees.
Sources
Last reviewed: 19 October 2026.
