Create a draft repository security advisory, then start a temporary private fork from it. Work on the fix and open pull requests inside the fork, then merge them together from the advisory and publish. Plan for limits: CI does not run there, and pull requests cannot be merged one at a time.
What it is
According to GitHub's documentation, a temporary private fork is a private copy of a public repository, created from a repository security advisory so maintainers can fix a vulnerability without exposing it. You must create a draft security advisory first.
Steps
- Open the draft advisory from the repository's Security and quality tab, under Advisories.
- At the bottom of the form, click Start a temporary private fork. The fork is named after the repository plus the advisory ID, with the repository name truncated to 80 characters. It can also be created through the REST API.
- Add collaborators. Advisory admins can add people who then access the fork.
- Commit the fix, on GitHub or locally. Anyone with write permission on the advisory can commit and open pull requests from the fork.
- Test the fix yourself, because of the limits below.
- Merge from the advisory, add credits and a fix version, then publish.
Limits to plan around
| Limit | What it means for you |
|---|---|
| CI and other integrations cannot access the fork | Run tests locally or in a private environment |
| Status checks do not run on pull requests there | Do not rely on green checks |
| Individual pull requests cannot be merged | Admins merge all open pull requests together |
| Every open pull request must be mergeable | Resolve conflicts first |
| Branch protection of the target branch is not enforced during this merge | Review carefully by hand |
| Only one pull request can target the main branch | Combine main branch changes into one |
These are from GitHub's documentation, so check it for updates.
Practical advice
Because automated checks do not run, write a short manual test plan and have a second person review the diff. Run your full test suite locally against the fork's branch. Keep the change small. For several supported release lines, use separate pull requests for each branch, remembering the rule on main.
Choose commit messages and pull request titles that are neutral. Once the advisory is published and the fork is deleted, the fix lands in the public repository, and its history is readable.
After you publish
GitHub's publishing page says the temporary private fork for the advisory is deleted, and Dependabot alerts your users. Add a fix version before publishing, because otherwise alerts do not point users to a safe version.
Try it yourself
The fix available now demo shows what happens on the consumer side when a patched version appears. Click through it to see why an accurate fixed version field matters.
Click through it at your own pace, or open it full screen.
Quick check
Can anyone see the fork?
Only people you add to the advisory as collaborators can access it.
Does it replace testing?
No. Without CI in the fork, you carry more of the testing yourself.
Safeguard's policies and gates can check a release for known vulnerable dependencies before it ships. The free scan is at gold.safeguard.sh/scan.
Sources
Last reviewed: 19 October 2026.
