CVE-2026-24811 is a critical (CVSS 9.8) pointer arithmetic flaw in the zlib code distributed with the ROOT data analysis framework, in inffast.c. Only builds before 6.36.00 that use the built-in zlib are affected. Check with root-config, and upgrade to a fixed ROOT release.
What's affected
The ROOT project's statement names two flaws in its bundled zlib, CVE-2026-24811 in inffast.c and CVE-2026-24812 in inftrees.c. A maliciously crafted .root file or compressed data packet could trigger them during decompression, and might lead to a buffer overflow and then to service user privileges, but not root privileges. The project says a proof of concept is still pending.
Most users are not affected. You are affected only if you use a release older than 6.36.00 and compiled it with the built-in zlib option. Releases 6.36.00 and newer are not affected, and neither are older builds that use an external zlib, which is the default.
The project advises upgrading to a supported release: 6.32.22, 6.30.10, 6.28/14, 6.26/16 or 6.26/18 as its page lists them, or any release of the 6.36 or 6.38 series. Check ROOT's page for the latest patch of your series.
How to check if you're exposed
ROOT gives a one command check for releases older than 6.36.00:
root-config --features | grep builtin_zlib
If nothing is printed, your build does not use the built-in zlib and is not affected. If it prints a match, you are using the bundled copy. Check analysis containers and shared installs on compute clusters too.
For a quick look at your own dependencies, Safeguard's free in-browser dependency scan at https://gold.safeguard.sh/scan checks them against known CVEs in your browser.
What to do now
- Run the root-config check on every ROOT install older than 6.36.00.
- If it shows builtin_zlib, upgrade to the latest patch of your supported series, or to 6.36 or later.
- Alternatively, rebuild with the built-in zlib option off, so ROOT uses the system library.
- Treat .root files and compressed data from outside your collaboration as untrusted.
- Keep the system zlib patched too.
Why it matters
The record lists CWE-119, CWE-125, CWE-20 and CWE-787, which together describe memory handling errors from unchecked input. The ROOT blog describes a pointer arithmetic error. The same family of problem affected zlib itself, and bundled copies lag behind upstream.
This is a clear case of context changing risk. A 9.8 score covers every use of the code, but the project's own analysis says the exposed set is small. A quick feature check tells you which side you are on. The CVE is not in CISA's Known Exploited Vulnerabilities catalog.
What the ROOT statement teaches about context
The ROOT project handled this disclosure in a way worth copying. Instead of a bare advisory, it published a statement that says who is affected, who is not, and how to tell the difference with one command. That turned a critical score into a short checklist.
The key fact is that the flaws live in a copy of zlib that ROOT can bundle, and that the bundled copy is used only when a build opts in. The default build uses the system's zlib. The root-config check shown earlier in this post tells you which one you have, for releases older than 6.36.00. No output means the bundled copy is not in play.
Bundled copies are a quiet supply chain risk
Many projects ship a copy of a common library inside their own source tree. zlib is one of the most copied. When the upstream project fixes a bug, the bundled copy does not change until the maintainers merge the fix. The ROOT pull request for this CVE says the same: the code was cloned from zlib and did not receive the upstream patch. The AzerothCore flaw covered in a separate post shows the same pattern in another project.
For you, that means dependency lists miss these copies. A lockfile will not show zlib inside a framework. To find them, look at the build options of what you install, at the third party directories in source packages, and at software bills of materials that record bundled components. A software composition scan that can read container images and build outputs finds more than one that reads only manifests.
A practical order of work
First, run the check on every ROOT install, including shared installs on analysis clusters and inside containers. Second, for each install with the built-in zlib, upgrade to the patch release the ROOT page lists for that series, or to 6.36 or later. Third, where you control the build, switch off the built-in option so that the system zlib is used, and keep the system library patched.
Fourth, treat data files from outside your collaboration as untrusted input. Decompression code is a classic place for memory errors, and the ROOT statement describes a crafted file as the trigger. Do not open files from unknown sources on machines that hold credentials.
Last, note what the project did not say. It says a proof of concept is pending and that the expected result is service user privileges, not root. Both statements are about today, and they can change, so look at the page again before you decide to wait.
Try it yourself
Click through it at your own pace, or open it full screen.
Quick check
Am I affected if I use ROOT 6.36.00 or newer?
No. The ROOT project says releases 6.36.00 and newer are not affected.
Does it give root privileges?
The project says the likely result is service user privileges, not root privileges.
Sources
Last reviewed: 19 October 2026.
