iText is one of the most widely used open-source libraries for working with PDF files in Java. From automated document generation to editing, it's a workhorse for developers and businesses. But in February 2022, a security flaw identified as CVE-2022-24198 was discovered in version 7.1.17 that could let attackers shut down your application, just by feeding it a specially made PDF. Let’s break down what this CVE is, how it works, see some sample code, and learn how to protect yourself.

What is CVE-2022-24198?

CVE-2022-24198 is an "out-of-bounds exception" bug in iText’s handling of ARCFOUR-encrypted PDFs. In plain English: if iText reads a sneaky PDF with this specific kind of (flawed) encryption, it might try to read or write to a part of memory it shouldn’t. This causes Java to throw an exception and, unless you handle it just right, this can crash your program — a classic Denial of Service (DoS).

DoS (Denial of Service): Attackers could make your app or service crash with just a bad PDF.

- Downtime: If you’re processing PDFs automatically, an attacker could (for example) take down your document server.
- Potential vector: While this does not let attackers directly steal data or run code, stopping a business process or causing dashboard outages can be a big deal.

Understanding the ARCFOUR Encryption Vulnerability

The bug lives in the function ARCFOUREncryption.encryptARCFOUR. ARCFOUR (a stream cipher also known as RC4) is a way PDFs can be encrypted.

In iText, the encryption process expects certain lengths for data, and if a “bad” PDF tells it to encrypt more or less data than it should, an out-of-bounds access happens. Java catches this as an exception, but the iText library didn’t handle this well in v7.1.17.

The Core Problem (Simplified Pseudocode)

// This is an example (not the literal source) of the dangerous logic:
public byte[] encryptARCFOUR(byte[] input, byte[] key) {
    byte[] output = new byte[input.length];
    // ... ARCFOUR setup ...
    for (int i = ; i < input.length; i++) {
        output[i] = (byte) (input[i] ^ nextByteOfKeyStream());
        // If input.length is not as expected, bad stuff can happen here
    }
    return output;
}

Imagine a PDF that, through clever crafting, makes input.length either super big or zero, or otherwise not play by the rules. Java will throw an ArrayIndexOutOfBoundsException. If you aren’t expecting this and don’t catch it throughout your application, your service or job dies.

Proof-of-Concept: Crash with a Malicious PDF

Because this is a Denial of Service, not a data-stealing exploit, the simplest “attack” is just to send in a PDF file generated in such a way that decryption triggers the bug.

If you’re curious what that might look like, here’s a skeleton example. This does not generate the actual bad PDF, but shows how iText would read it and crash:

import com.itextpdf.kernel.pdf.*;

public class ItCrashTest {
    public static void main(String[] args) throws Exception {
        PdfReader reader = new PdfReader("malicious.pdf", 
            new ReaderProperties().setPassword("password".getBytes()));
        PdfDocument pdf = new PdfDocument(reader); // <- This line may crash!
        System.out.println("PDF opened, page count: " + pdf.getNumberOfPages());
        pdf.close();
    }
}

With a "malicious.pdf" that fools the ARCFOUR decryption routine, the process dies with an exception like:

Exception in thread "main" java.lang.ArrayIndexOutOfBoundsException: Index  out of bounds for length 
    at ...ARCFOUREncryption.encryptARCFOUR(...)
    at ...PdfEncryption.decrypt(...)
    ...

*(The actual stack trace and filenames may vary depending on your environment and iText version.)*

References to the CVE and Sources

- CVE Record: CVE-2022-24198 on NVD
- iText's Security Advisories
- Issue Report on GitHub (if public) *(Note: Sometimes security issues are not discussed in public GitHub before a fix.)*

Upgrade iText Immediately!

- The iText team fixed this in later releases. Use at least version 7.1.19 or 7.2.2 (see their changelogs).

try {

// Process PDF...

} catch (ArrayIndexOutOfBoundsException | PdfException e) {

// Log & drop, don't let the app die!
  }

`

Never trust user PDFs. If possible, inspect and filter PDFs before trying to decrypt.

Mitigate DoS at the Infrastructure Level

- If you process many PDFs, use isolation (like containers or serverless functions) to avoid cascading crashes.

Conclusion

CVE-2022-24198 may sound like a boring DoS bug, but if your software automatically opens PDFs, one bad file could crash your whole operation. In security, even “just a crash” can be the difference between uptime and an outage, or worse, an angry customer. Always keep libraries up to date and remember: PDFs are little programs, not just documents.

- Official iText Homepage
- CVE-2022-24198 on NVD
- Download Latest iText


*If you found this useful, share and keep your dependencies patched! For questions or comments, drop a line below.*

Timeline

Published on: 02/01/2022 20:15:00 UTC
Last modified on: 02/04/2022 20:05:00 UTC