CVE-2022-47111 - 7-Zip 22.01 and the XZ File Parsing Error Explained

The popular 7-Zip archiver (version 22.01) was hit with a subtle vulnerability in its handling of certain invalid .xz files. Assigned as CVE-2022-47111, this flaw isn’t a remote code execution bombshell, but it highlights important lessons about data validation and error reporting in file archiving tools.

In this long form post, we'll break down what went wrong in 7-Zip's XZ parser, include code snippets to demonstrate the issue, walk through exploitation details, and round up links to original advisories and patches. All explained in direct, simple terms for everyone!

What Is CVE-2022-47111?

At its heart, the CVE-2022-47111 bug is this:
7-Zip version 22.01 does not produce an error if an XZ file has block flags with reserved bits set to non-zero. It should, but it doesn't.

- Normally, certain bits in the XZ block headers are _reserved for future use_ and must always be zero in valid files.

Potential for incorrect processing or belief in a file’s integrity when it's actually corrupt.

- Could hide corrupted data, analytics errors, or even future attack vectors if a deeper parser bug exists.

Later versions of 7-Zip fixed this, so only 22.01 and _some earlier_ releases are affected.

XZ Files & Block Flags: What Should Happen?

An XZ file is made up of a stream of blocks. Each block has a small header which encodes flags. Some of these bits are reserved—if you look at the XZ specification, you'll find:

> The bits 4–7 (high nibble) of the block flags are reserved and must be set to zero. If a program finds a nonzero value, it must treat the file as invalid.

7-Zip 22.01 ignored violations of this rule.
Instead, it should have flagged such files as broken.

Code Snippet: Checking Block Flags

Let’s look at a generic check, inspired by the XZ specification:

// Example in C: Checking reserved bits (4–7) are zero
uint8_t blockFlags = read_byte(xz_header_stream); // Read block flags byte

if ((blockFlags & xF) != ) {
    printf("Error: Reserved bits set in block flags!\n");
    return ERR_CORRUPT_FILE;
}

Exploitation Details

This isn’t a remote code execution bug. There’s no buffer overflow or crash as reported.

Craft an XZ file with reserved bits set in the flag byte.

- xz-utils source code lets you build or edit XZ files manually.

Open with 7-Zip 22.01.

- 7-Zip will happily unpack it with _no error_ — so for testing, add an extra note or corruption in the data too.

Proof-Of-Concept: Malformed XZ Block Flag

Suppose you have an XZ archive, and at offset N you find the block flags byte. Change to xF1 (instead of the valid x01):

... [valid xz headers] ...
Block Flags: xF1  // Invalid — high nibble is not zero!
... [rest of file] ...

The bug was reported in late 2022.

- Official CVE registration at NVD
- Patch committed in 7-Zip codebase:

References

- XZ File Format Specs
- CVE-2022-47111 at NVD
- 7-Zip Official Website
- 7-Zip Patch Thread
- xz-utils Source

Re-verify any important XZ archives with up-to-date tools.

- In scripting/automation, avoid or flag 7-Zip 22.01 when extracting XZ files.

Takeaway

CVE-2022-47111 underlines how “small” validation mistakes can cause headaches. While this isn’t a critical security hole, it’s a reminder:
When specifications reserve bits for future use, always check them!
You never know when a little validation could save you from bigger problems later.

Timeline

Published on: 04/19/2025 21:15:45 UTC
Last modified on: 04/21/2025 14:23:45 UTC