CVE-2022-38236

What it actually does

Global buffer overflow in Lexer::getObj(Object*) at /xpdf/Lexer.cc allows out-of-bounds memory reads/writes during PDF tokenization and object parsing.

Why it matters to the business

Attackers may gain code execution on endpoints that use xpdf to open malicious PDFs, enabling data theft, ransomware deployment, or persistence on developer and document-processing systems.

How an attack unfolds

An attacker crafts a PDF containing malformed tokens that overflow the global buffer inside Lexer::getObj. The file is delivered via email or web download; when the victim opens it with xpdf the overflow occurs and is used to redirect control flow to attacker-supplied shellcode.

How to fix it

Upgrade xpdf to a build that includes commit ffaf11c or a later patched release. Where no fixed package is published, replace xpdf with a maintained PDF viewer and disable xpdf in automated document pipelines.

How to confirm the fix worked

Confirm the installed xpdf binary is built from source after ffaf11c; run regression test suites containing the original crashing input; verify absence of the vulnerable Lexer.cc path via static analysis.

Typical attack path

1. Generate malicious PDF that triggers Lexer::getObj overflow
2. Host or send the PDF to the target
3. Victim opens the file with xpdf (local UI action)
4. Overflow corrupts memory and executes payload

How to detect it

Monitor process crash logs and core dumps for xpdf segfaults or SIGABRT while parsing PDFs; inspect file-access telemetry for unexpected PDF files opened by xpdf shortly before anomalous process behavior.

What your security team should do

• Remove or replace xpdf on all endpoints until a fixed build is deployed
• Block execution of xpdf via application allow-listing where feasible
• Add PDF sandboxing or conversion steps before any xpdf usage