Yes. Semantic versioning has no exception for security. If a fix changes public behavior in a backward incompatible way, such as turning on certificate checks or rejecting a previously accepted input, it needs a major version. Ship it, explain it clearly, and where possible also offer a compatible patch.
What the spec says
The Semantic Versioning specification says the patch number must be incremented only if backward compatible bug fixes are introduced, and defines a bug fix as an internal change that fixes incorrect behavior. A major version must be incremented if any backward incompatible changes are introduced to the public API. Nothing in the text carves out vulnerabilities. A released version's contents must never be modified, so any change, including a fix, goes out as a new version.
The same specification says that when you deprecate functionality you should update documentation and release a minor version containing the deprecation, with at least one such minor release before removal in a major release.
The three kinds of security fix
| Type of fix | Example | Version bump |
|---|---|---|
| Internal correction, same behavior for valid use | Bounds check added in a parser | Patch |
| New safe option, old behavior kept | Add a strict mode flag, off by default | Minor |
| Changed default or removed unsafe behavior | Verification now on by default, unsafe option removed | Major |
The hard case is the third row. Changing a default is the most effective fix, because most users never read the settings, but it is also the one most likely to break callers.
Steps to ship a breaking security fix
- Write down exactly what changes for a caller. If you cannot describe it in two sentences, the change is probably bigger than you think.
- Look for a two step path. Release a minor version that adds the safe behavior behind an option and logs a warning when the unsafe path is used. Then flip the default in the next major.
- If the issue is severe and active, do both at once: publish the major version with the safe default and a patch for the latest minor of the previous major that closes the hole in the least disruptive way. Say which versions are fixed in the advisory.
- Write the changelog entry with the word security, the affected versions, the fixed versions, and the exact steps to adapt. The changelog guidance has a format.
- Provide an escape hatch only if you must, name it so its risk is obvious, and log a warning each time it is used.
- Tell customers through every channel you have, because a major bump gets deferred by default.
Common arguments, answered
"We do not want to bump the major for a fix." Customers who pin a range such as the current major will never receive a breaking fix, so the cost of hiding it is that the hole stays open for them. A major bump with a loud advisory is more honest than a breaking patch that causes outages.
"Security is urgent, so semver does not apply." Semver is what lets automated updaters decide what is safe to apply without human review. A breaking patch trains customers to distrust patch updates, which slows every future fix. See also what customers expect from patch updates.
Quick check
Can I change a default in a minor release?
If the new default can break working callers, the specification points to a major version. Add the safe behavior as an option in a minor first.
Do old versions need a fix too?
If they are within your support policy, yes. State in the advisory which versions are fixed.
Safeguard's autonomous remediation can open fix pull requests for customers, off by default and with every category on Manual, and its policies and gates keep risky upgrades visible. See it in the free scan.
Sources
Last reviewed: 19 October 2026.
