Report the flaw privately through the project's security channel first, with a small reproducible case. Then offer a minimal patch on a clean branch from upstream's latest code, not from your fork's main. Do not open a public pull request for an unfixed vulnerability before upstream agrees on timing.
Why upstream the fix at all
Every patch you carry is a cost you pay at every sync. A fix upstream removes that cost and protects everyone else who uses the project. It also removes the risk that your private fix differs from the one upstream eventually ships, which leaves you with a confusing conflict later.
Step 1: check how to report
Look for a security policy file, a security contact or a private reporting form. GitHub documents that anyone can privately report a vulnerability to the maintainers of a repository where private reporting is enabled, and that owners of public repositories can turn it on. If there is no private route, find a maintainer contact before you post anything public. See what to do when a vendor has no security contact.
Step 2: write a minimal report
Include the affected version, a short description, steps or a test that shows the problem, and the impact in plain words. Say you have a patch ready. Keep exploit detail to what is needed to reproduce.
Step 3: prepare a clean patch
Your fork has local commits upstream does not want. Create a fresh topic branch from upstream's current main, and apply only the fix, for example by cherry-picking it. Then run the project's tests and add a test for the bug.
git fetch upstream
git switch -c fix-archive-traversal upstream/main
git cherry-pick FIX_COMMIT
Rewrite the commit message to follow the project's style, and strip your internal ticket links.
Step 4: wait for the project's timeline
Let the maintainers say when a public pull request is fine, usually once a release or advisory is ready. If they do not reply, follow up politely and respect any coordinated disclosure window the project states. See researcher follow up when a vendor does not reply.
Step 5: clean up your fork
When upstream releases the fix, sync, drop your carried patch and update your provenance notes. Record the upstream commit that replaced it.
What can go wrong
| Problem | Avoidance |
|---|---|
| Public pull request exposes the flaw early | Report privately first |
| Patch includes unrelated fork changes | Use a topic branch from upstream |
| Maintainers want a different design | Offer to adapt, keep your carried patch meanwhile |
| No response for months | Escalate through the documented route, consider coordinated disclosure rules |
| Project is archived | You may need to keep the fork. See what an archived upstream means for your fork |
Where Safeguard fits
Safeguard's dependency scanning can show which components you depend on, which tells you whose security channels to watch, and you can scan your own projects free at gold.safeguard.sh/scan.
Quick check
Can I open a public pull request with the fix right away?
Not for an unfixed vulnerability. Report privately and follow the project's timing, since a public patch can reveal the flaw before users can update.
Why branch from upstream and not from my fork?
Your fork contains local commits upstream does not want. A clean branch carries only the fix.
Sources
Last reviewed: 19 October 2026.
