A security fix that keeps your public interface compatible should ship as a patch release, for example 4.2.1 after 4.2.0. If the fix forces a breaking change, it needs a new major version. Never reuse a version number, because a released version must not be modified.
What the spec says
The Semantic Versioning 2.0 text defines three bumps. MAJOR is for backward incompatible changes to the public API. MINOR is for backward compatible new functionality, or when you deprecate public functionality. PATCH is for backward compatible bug fixes, meaning internal changes that correct incorrect behavior. It also says that once a version is released, its contents must not be modified, and any change must be a new version.
A vulnerability is incorrect behavior, so the default is a patch bump. That matters for self-hosted customers because many have change rules that let patch releases through quickly and send minor or major releases to a longer review.
Decision table
| Situation | Bump | Example |
|---|---|---|
| Fix is internal, interface unchanged | Patch | 4.2.0 to 4.2.1 |
| Fix needs a new optional setting, old behavior kept | Minor | 4.2.1 to 4.3.0 |
| Fix removes or changes an unsafe default that scripts relied on | Major, or minor with a clear note if you document the risk | 4.3.0 to 5.0.0 |
| You published the wrong build by mistake | New patch, never overwrite | 4.2.1 to 4.2.2 |
The third row is the hard one. Tightening an insecure default is often the right fix, yet it can break an automation. Say so in the release notes, and offer a setting that restores the old behavior for a limited time if you can do so safely.
Steps for a security release
- Fix on the oldest supported branch first, then forward port. Customers on older lines need the patch too.
- Choose the bump from the table, not from how urgent the fix feels.
- Tag the release and publish artifacts once. If something is wrong, issue a new version.
- Mark the entry as a security change in the changelog and link the advisory.
- Tell customers which versions are affected and which version contains the fix, in the same words in the notes and the advisory.
What not to do
Do not hide a security fix inside a large minor release without saying so. Customers cannot judge urgency, and scanners that read advisories need a clear fixed version. Do not skip numbers or invent a fourth segment to signal urgency. Put urgency in the advisory text.
Try it yourself
Click through it at your own pace, or open it full screen. Look at how a fixed version is presented next to the affected one.
If you want a second look at what you ship, Safeguard can generate and scan an SBOM and run dependency scanning with reachability analysis, and you can try the free scan.
Quick check
Is a security fix ever a minor release?
Yes, when the fix adds backward compatible functionality, such as a new setting. Say clearly in the notes that it also fixes a vulnerability.
Can I replace a bad build under the same number?
No. The spec says a released version must not be modified. Publish a new patch version.
Sources
Last reviewed: 19 October 2026.
