PatchTheCVEUpgrade or downgrade? What to do when a CVE has no fix yet
Most advisories say "upgrade to version X". Sometimes there is no fixed version yet. Here is how to decide.
1. A fixed release exists: upgrade
This is always the first choice. Read the release notes for breaking changes and test before production.
2. No fix, but older releases are unaffected: consider a downgrade
Some flaws only exist in recent versions, for example a backdoor added in one release. If the advisory lists the first affected version, the release before it is not affected.
Downgrade only when all of these are true:
- The vendor or distribution confirms the older version is unaffected.
- It is not a core system package such as glibc, openssl, the kernel, systemd or sudo. Downgrading those can break the whole system.
- The older version has no worse known vulnerabilities.
- You have tested the downgrade on a non-production host.
Hold the package so an automatic update does not move it forward, and remove the hold once a fixed release ships.
3. Neither works: mitigate
- Disable the affected feature or module in configuration.
- Restrict network access with a firewall or security group.
- Put a WAF or reverse proxy in front of the service.
- Remove the software if it is not needed.
- Monitor logs for exploitation attempts.
Each CVE page on this site shows which of the three applies, with the commands. Related: backports and fixed versions.
FAQ
Is it safe to downgrade a package to avoid a vulnerability?
Only when the older version is confirmed unaffected, the package is not a core system component and you have tested it. Otherwise prefer the vendor fix or a mitigation.
What can I do if there is no patch for a CVE?
Disable the vulnerable feature, restrict network access, add a WAF or proxy, or remove the software, and monitor for exploitation until a fix is released.