CVE-2024-7868 is a high severity (CVSS 8.2) bug in Xpdf 4.05 and earlier. Invalid header information in a DCT (JPEG) stream leaves a variable uninitialized in the decoder, and a crafted PDF crashes the program. The Xpdf project says the fix is in version 4.06.
What's affected
The CVE-2024-7868 record names Xpdf 4.05 and earlier. The vendor page for the bug says the problem is fixed in Xpdf 4.06. Its wording is "This will be fixed in Xpdf 4.06", so check the Xpdf download page to confirm 4.06 or later is available to you before you plan around it.
The record scores it 8.2 with the vector CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:L/I:N/A:H. That vector assumes a network attack with no user interaction. The vendor page itself describes a segmentation fault from a proof of concept PDF and says nothing about code execution or data theft, so read the high score as mostly about availability, with a low confidentiality component in the vector. The record's KEV flag is false and the Xpdf page does not mention exploitation.
How to check if you're exposed
Xpdf ships as a set of command line tools such as pdftotext, pdftoppm and pdfimages, plus a viewer. To see your version:
pdftotext -v
The tools print their version to standard error. If it says 4.05 or lower, it is in range. Also look for places where Xpdf code is embedded or called as a library or subprocess. Document pipelines that convert uploaded PDFs to text or images are the usual place for this, and they often run unattended.
If you installed Xpdf from a Linux distribution, the package version string may differ from upstream. Check your distributor's security tracker rather than relying on the number alone.
What to do now
- Inventory every use of Xpdf, including viewers on desktops and command line tools in scripts and servers.
- Update to Xpdf 4.06 or later once you have confirmed it is released.
- For services that process PDFs from outside your organization, run the converter in a separate process with a timeout and memory limit, so a crash cannot take the whole service down.
- Make sure a failing conversion is handled as an error and retried carefully, not looped in a way that amplifies a bad file.
- Re-scan after updating to confirm no older copy remains in container images or bundled directories.
Why it matters
The vendor describes the cause precisely. A function called DCTStream::getBlock() was missing a proper check for the case where DCTStream::prepare() failed due to invalid headers. Code then used state that was never set up. That is CWE-457, use of an uninitialized variable, and it is also filed under CWE-908, use of uninitialized resource.
Image decoders are a classic place for this kind of bug because they parse untrusted bytes, and the header is the first thing they read. If the header is bad, every later step must refuse to run. The Xpdf page credits KMFL with finding the issue.
For teams that embed a PDF tool in a pipeline, the practical risk is a denial of service when a hostile file arrives. Treat that as a reason to isolate the converter.
Quick check
What is the fixed version for CVE-2024-7868?
The Xpdf security page says the fix will be in Xpdf 4.06. Verify that release on the Xpdf site before relying on it.
Does the advisory say this allows code execution?
No. The vendor page describes a segmentation fault from reading an invalid address in a proof of concept file. The record's high score comes from its CVSS vector.
Sources
Last reviewed: 19 October 2026.
