Who fixes vulnerabilities in Linux?
How a vulnerability travels from discovery to a fixed package on your machine, and who does the work along the way.
From discovery to your machine
A security fix passes through several hands before it reaches a server. Knowing the chain helps explain why fixes arrive when they do, and why the same vulnerability can be fixed on one distribution days before another.
1. Someone finds the flaw
Vulnerabilities are found by security researchers, by the project's own developers, by automated testing, and sometimes by attackers first. Responsible researchers report them privately to the project, so a fix can be prepared before the details are public.
2. The upstream project fixes it
The developers of the affected software - OpenSSL, the Linux kernel, a web server - write and test the fix. A CVE identifier is usually assigned at this stage, so everyone downstream can refer to the same issue.
3. Distributions prepare their updates
For serious issues, distributions are often told in advance under an embargo, a short agreed period (usually no more than two weeks) during which the details stay private. Their security teams use that time to build and test fixed packages for every release they support, so updates can be published the moment the vulnerability is announced.
Who does this work depends on the distribution:
- Debian has a volunteer Security Team for current releases and a sponsored LTS team for older ones.
- Ubuntu's fixes come from Canonical's Ubuntu Security Team.
- Rocky Linux and AlmaLinux follow Red Hat's fixes for RHEL and rebuild them for their own releases.
- Fedora's package maintainers push fixes themselves through Fedora's update system.
- Arch mostly ships the new upstream version directly, with a security team keeping track of what's affected.
4. The fix is published
The distribution publishes the fixed packages to its repositories and announces them in a security advisory, listing the CVEs fixed and the versions that fix them. From here on, the details are public - for attackers too.
5. You install it
This is the only step that's up to you, and the one where most of the delay usually happens. A fix sitting in the repository protects nothing until the package is installed and the affected service has been restarted to use it.
Why it matters which release you run
Security teams only prepare fixes for releases that are still supported. Once a release reaches end of life, step 3 simply stops happening for it: new vulnerabilities still get found and published, but no fixed packages follow. See Planning for end of life.