CVE-2025-47436 is a heap-based buffer overflow in the C++ library of Apache ORC. A malformed file can make LZO decompression write past the end of a buffer. The record scores it 9.8 (critical). Upgrade to 1.8.9, 1.9.6, 2.0.5 or 2.1.2.
What's affected
The CVE record and the Apache ORC security page agree on the affected range for the ORC C++ library:
- through 1.8.8
- 1.9.0 through 1.9.5
- 2.0.0 through 2.0.4
- 2.1.0 through 2.1.1
The fixed versions are 1.8.9, 1.9.6, 2.0.5 and 2.1.2. The Apache project tracks the work as ORC-1879.
One thing to know about the numbers. The record carries a CVSS score of 9.8, while Apache's own page rates the issue Medium. Both are quoted here so you can weigh them yourself. The vector in the record has no required privileges and no user interaction, which is why the score is high.
The advisory is about the C++ library. It does not say the Java implementation is affected.
How to check if you're exposed
ORC is a file format used by data tools, so the library often arrives inside something else. Look for it in three places.
First, your own builds. If you compile against the ORC C++ library, check the version your build resolves, for example from your package manager or your vendored source tree.
dpkg -l | grep -i orc
brew list --versions apache-orc
Second, software that bundles ORC. Some data engines and language bindings ship their own copy. For those, the vendor's advisory is the source of truth, not the ORC version number you see on disk.
Third, your inputs. Ask where ORC files come from. Files produced inside your own pipeline carry less risk than files from outside parties. The advisory describes specially crafted malformed files, and the risky ones use LZO compression.
A software inventory makes the first two steps quick. The demo below shows how an inventory answers the question of which projects contain a given library.
What to do now
- Find every product and build that links the ORC C++ library.
- Upgrade to 1.8.9, 1.9.6, 2.0.5 or 2.1.2, whichever matches your line.
- For bundled copies, check each vendor for an update and apply it.
- Until you have upgraded, avoid reading ORC files from untrusted sources with affected builds.
- Rebuild and redeploy anything that statically links the library, because replacing the package alone will not update it.
Why it matters
The record maps the flaw to CWE-122, heap-based buffer overflow. According to Apache, the decompressor allocates a 250 byte buffer and then tries to copy 295 bytes into it, because the input buffer boundary is not validated enough during decompression. The result is memory corruption.
Memory corruption bugs in file parsers are serious because the parser runs on data that someone else controls. What an attacker can do next depends on the build and the platform, and the advisory does not describe that. It describes the crash class and the fix, and so does this post.
This CVE is not on the CISA Known Exploited Vulnerabilities list, and the sources do not say it is exploited in the wild.
Try it yourself
Click through it at your own pace, or open it full screen.
Quick check
Is the Java ORC library affected?
The advisory describes the ORC C++ library. It does not list the Java implementation as affected.
Why do the score and the Apache rating differ?
The CVE record scores it 9.8 using a vector with no privileges and no user interaction. Apache rates it Medium on its security page. Use the fixed versions rather than the number to decide.
For a quick look at the libraries in your own manifests, use the free scan at gold.safeguard.sh/scan.
Sources
Last reviewed: 18 October 2026.
