In March 2022, a vulnerability was discovered in the Apache POI library, specifically in the poi-scratchpad module. This vulnerability—CVE-2022-26336—might not sound scary at first (“just” an Out of Memory exception), but in the right situation, it can take down whole servers. Since Apache POI is a popular choice for dealing with Microsoft files in Java, this bug could affect a lot of Java web apps and services, especially those that let users upload or parse TNEF (Transport Neutral Encapsulation Format) files—often used by Outlook or Exchange.

Let's break down what this CVE means, how the exploit works, and what you can do to fix it.

What Is CVE-2022-26336?

A vulnerability in Apache POI's HMEF (Horrible Microsoft Exchange Format) package in the poi-scratchpad module (up to version 5.2.) allows attackers to craft a TNEF file that causes an Out of Memory (OOM) error during parsing.

It sounds harmless, but if an application lets users upload TNEF files and then parses them with POI, an attacker could send a single malicious file, causing the server to run out of memory and either crash or become unstable.

Reference:  
- CVE Details on NIST  
- Official Apache POI Issue  

Real-World Example

Suppose you have a Java web service where users can upload Outlook meeting invitations or winmail.dat files, and you use Apache POI's HMEF support to parse them.

Original (vulnerable) code

import org.apache.poi.hmef.HMEFMessage;

public class TnefParser {
    public void parseTnef(File tnefFile) throws IOException {
        try (FileInputStream fis = new FileInputStream(tnefFile)) {
            HMEFMessage message = new HMEFMessage(fis);
            // do something with the message...
        }
    }
}

If a user uploads a specifically crafted TNEF file, the call to new HMEFMessage(fis) could cause your server to consume all heap memory, resulting in an OutOfMemoryError and potentially taking down your whole app.

How Does The Exploit Work?

Attackers exploit the fact that the HMEF parser in old versions of Apache POI doesn’t enforce reasonable limits on sizes when creating Java objects or reading data from TNEF files. As a result, a file can claim to contain a massive amount of data (or deeply nested data), and POI tries to process it all—eventually running out of memory.

Exploit snippet (not full malicious file, but general process)

# This is a conceptual demonstration - not an actual TNEF parser
# The idea: create a TNEF file with very large length fields
def create_malicious_tnef():
    tnef_magic = b'\x78\x9f\x3e\x22'
    attributes_count = 10000000  # Large number to force many allocations
    tnef_data = tnef_magic
    tnef_data += attributes_count.to_bytes(4, 'little')
    tnef_data += b'A' * 100  # Minimal data, the count field is what breaks it
    with open('malicious_winmail.dat', 'wb') as f:
        f.write(tnef_data)

If you upload a file like this, the Apache POI HMEF parser tries to process millions of attributes, causing memory exhaustion.

Any Java application using Apache POI (poi-scratchpad) to process TNEF files

- Any app or web service letting users upload, receive, or process winmail.dat or TNEF from untrusted sources
- Especially risky for SaaS/email parsing/back-end systems with low resource limits

How Can I Fix It?

The patch for CVE-2022-26336 was released in poi-scratchpad version 5.2.1. The fix enforces stricter bounds and sanity checks when parsing TNEF data.

How to fix

1. Update your Maven/Gradle dependency:

org.apache.poi
      poi-scratchpad
      5.2.1

Double-check for leftovers:

Some apps “shade” dependencies or keep old JARs hanging around—make sure to delete all old versions.

If you must support older versions:

Before parsing TNEF files, check their size. Reject unusually large files (for instance, anything beyond a few megabytes), or run parsing in a sandboxed process/service so it can't take down your main app.

How To Test for the Vulnerability

You can test if your system is vulnerable by uploading a large/malformed TNEF file to your service. If the service crashes or freezes with an OOM error, you’re likely vulnerable.

Reference exploit

POC on GitHub

Conclusion

CVE-2022-26336 is a classic “denial of service” vulnerability—small sin, big effect. A simple file upload can take down your entire Java service if you use Apache POI scrathpad for TNEF. The fix is easy: upgrade to poi-scratchpad version 5.2.1 or later.

If your app parses Outlook/TNEF files from anyone other than yourself, you must patch this bug ASAP.

Original References

- CVE-2022-26336 NVD Page
- Apache POI Official GitHub Fix
- POI Release Notes

Need support? Visit Apache POI Homepage for guidance and updates.

Timeline

Published on: 03/04/2022 16:15:00 UTC
Last modified on: 03/22/2022 19:16:00 UTC