Treat an unrequested security pull request as two separate questions: is the problem real, and is the patch right. Verify the claim yourself first, review the diff as you would any outside change, keep your CI secrets out of reach, and reply politely whatever you decide.
Start with the claim, not the code
Many unrequested pull requests say something like "fixes a vulnerability" with little detail. Before reading the patch, ask what the author says is wrong, where, and how it can be triggered.
Try to reproduce the problem on a clean checkout, in a throwaway environment with no credentials. If you cannot reproduce it, say so in the thread and ask for a proof of concept. A real finding usually survives that question.
Decide how public the conversation should be
A pull request is public. If the issue is genuine and exploitable, a public patch hands attackers a map before users can upgrade. If that is a risk, ask the author to stop discussing details in the open, close the pull request, and move the work to a private channel. GitHub documents a temporary private fork for fixing a vulnerability in a public repository, created from a draft security advisory, and says integrations including CI cannot access those forks.
Your SECURITY.md should say where private reports go, so people know before they open a public pull request. See what to put in a security policy.
Review the diff as an outside change
| Question | Why it matters |
|---|---|
| Does it touch only what the description says? | Scope creep hides unrelated edits |
| Does it add a dependency or change a version range? | New packages are new trust |
| Does it edit workflows, scripts, or release config? | Those run with your credentials |
| Does it add a test that fails before and passes after? | The best evidence the fix works |
| Is the author history plausible? | Not proof, but context |
For a pull request from a fork, check how your workflows are triggered. Some triggers give fork code access to secrets. For safe patterns, see pull_request_target risks for open source maintainers.
Reply, even if the answer is no
A short, kind reply keeps the door open for the next, better report. A template that works:
Thanks for looking at this. I could not reproduce the issue on the
current main branch (steps I tried are below). If you have a proof of
concept, please send it through our private reporting channel in
SECURITY.md and I will look again. Closing for now.
If someone floods you with low quality pull requests, GitHub lets repository admins set a temporary interaction limit for 24 hours, 3 days, 1 week, 1 month, or 6 months, restricting who can comment or open pull requests. You can also block a user or report abuse. Use those sparingly and keep the tone polite in public.
Credit and disclosure
If the fix is real and you accept it, decide on credit before release and ask the reporter how they would like to be named. If it deserves an advisory, publish one once a fixed version exists. See request a CVE as a maintainer with GitHub advisories.
Where Safeguard fits
Safeguard's dependency scanning can show whether the package a pull request touches has known vulnerabilities, and the free scan at https://gold.safeguard.sh/scan needs no setup. It will not judge a hand-written patch, so your own review stays the deciding step.
Quick check
Do I have to merge a security pull request that is technically correct?
No. You own the project. Merge when the change is correct, in scope, and fits your design, and say why when it does not.
Is it rude to close a pull request without merging?
No, as long as the reply is courteous and explains the reason.
Sources
- Collaborating in a temporary private fork, GitHub Docs
- Limiting interactions in your repository, GitHub Docs
- Blocking a user from your personal account, GitHub Docs
Last reviewed: 19 October 2026.
