Before a fix is released, a public commit that says it fixes a vulnerability is a map for attackers. Develop the fix in private, release it, and publish the advisory at the same time. Once it is public, a clear commit message is helpful, not harmful.
The tension
Open source works in public. A security fix pushed to a public branch can be read by anyone, including people who watch for exactly that. A message such as "fix authentication bypass in the login handler" tells them where to look before users have had a chance to upgrade.
On the other side, vague commits like "misc fixes" make later audits painful and leave downstream users unable to tell whether they need the update.
Develop the fix in private
GitHub provides temporary private forks for this. Its documentation says you can create a temporary private fork to privately collaborate on fixing a security vulnerability in your public repository, and that repository owners, organisation owners, security managers and users with the admin role can use the feature. Other hosts have their own equivalents. The principle is the same: do the work where only invited people can see it.
The OpenSSF maintainer guide on coordinated vulnerability disclosure also states that proper public disclosure should still be done so that all interested parties are made aware of the issue. Private development is not the same as silence.
A sequence that works
- Receive the report privately. Your security policy should say how. See write a SECURITY.md for your open source repo.
- Fix and test in a private branch or fork.
- Prepare the advisory with affected versions, fixed version and a short description.
- Release the fixed version and publish the advisory at the same time.
- Merge the fix publicly with a message that describes the change in the same terms as the advisory.
- Update the changelog. See changelog security disclosure practices.
What a good public message looks like afterwards
| Weak | Better |
|---|---|
| misc fixes | Reject path segments containing parent directory references in upload names |
| security fix | Validate redirect targets against an allowlist, see advisory link |
| patch | Fix token comparison to use constant time check |
The better versions describe the change in terms of code behaviour, link to the advisory, and appear when users can already upgrade.
Exceptions
If a vulnerability is already being exploited or is already public, speed matters more than neatness. Ship the fix, disclose plainly, and explain. Our post on what to do when a vulnerability goes public before your fix covers that case.
What about dependency bumps
Bumping a dependency to pick up an upstream fix is different, because the vulnerability is usually already public in an advisory. A commit message that names the advisory and the new version is fine and useful. It lets later readers see why the bump happened. The concern in this post is about flaws in your own code that nobody else has disclosed yet.
Quick check
Is a silent fix acceptable?
A private fix followed by a coordinated public disclosure is. A fix that is never disclosed leaves users unaware they should upgrade.
Who needs to see the fix before release?
Only the people needed to fix and test it. Keep that group small and invited.
Sources
- Collaborating in a temporary private fork, GitHub Docs
- OpenSSF maintainer guide to coordinated vulnerability disclosure
Last reviewed: 19 October 2026.
