Judge each campaign pull request on its merits and ignore the scale. If the fix is correct and in scope, merge it. If not, reply once with your reason and close it. If the flood keeps coming, GitHub's interaction limits give you a temporary pause.
What a campaign looks like
Sometimes a company, a researcher, or a tool vendor runs a script that opens near identical pull requests across a huge number of repositories. The change might bump a package, patch a file, or add a configuration. The motives range from sincere to promotional.
You cannot know the motive from your seat, and you do not need to. The pull request is either good for your project or it is not.
A fair way to decide
Ask five questions, in order:
- Is the underlying problem real for this repository? Check it yourself.
- Is the change small and limited to what it claims?
- Does it add a dependency, a workflow, a badge, or a link to someone's service? Those serve the sender as well as you.
- Does it fit your design and test conventions?
- Would you accept the same change from a trusted contributor?
If the answer to all five is yes, merging is reasonable even though a script opened it. If question 3 or 5 gives pause, decline politely.
Reply once, briefly
You do not owe an essay. A short, neutral message is enough.
Thanks for the suggestion. We reviewed it and are not taking this
change because it adds a workflow we do not use. Closing. If you have
a security report, please use the private channel in SECURITY.md.
Avoid sarcasm, even when the campaign is annoying. Your replies are public, and the next reader may be a first-time contributor judging how welcoming you are.
If it becomes a flood
GitHub's documentation lets repository admins enable temporary interaction limits for 24 hours, 3 days, 1 week, 1 month or 6 months. There are three levels: limit to existing users (blocks accounts under 24 hours old with no prior contributions), limit to prior contributors, or limit to repository collaborators. The limits restrict commenting, opening issues, creating pull requests and reacting. If you own several repositories you can apply a limit across your account or organization.
For repeat offenders, GitHub lets you block a user or report abuse to GitHub Support. The abuse reporting page also lets owners, collaborators and prior contributors report a pull request directly to repository admins. Use these when behavior is clearly spam, not merely unwelcome.
Protect your CI first
Mass pull requests often come from forks. Make sure your workflows do not hand fork code your secrets. See do fork pull requests get your repository secrets and fork pull request workflow approval settings explained.
Where Safeguard fits
If you want to know what a proposed dependency change brings in, the free scan at https://gold.safeguard.sh/scan lists packages and known vulnerabilities for a project. Safeguard has no role in sending campaign pull requests, so this is only a way to check them.
Quick check
Is a campaign pull request more likely to be malicious?
Not necessarily. Most are well meant. Judge the diff and the claim, not the scale.
Can I turn limits off after the flood passes?
Yes. Limits expire after the duration you pick, and you can also remove them early in the repository settings.
Sources
- Limiting interactions in your repository, GitHub Docs
- Blocking a user from your personal account, GitHub Docs
- Reporting abuse or spam, GitHub Docs
Last reviewed: 19 October 2026.
