D3-FCDC File Content Decompression Checking: Bounding and Testing Compressed Content Safely

Compressed and encoded sections are where file parsers do their most complex work, so a file that claims to hold valid compressed data but does not, or that expands far beyond its size, is both a malformation signal and a denial of service risk. MITRE D3FEND names this countermeasure File Content Decompression Checking (D3-FCDC) and defines it as "Checking if compressed or encoded data sections can be successfully decompressed or decoded", adding that this can be followed by further analysis with semantic knowledge. It sits under the Isolate tactic as a child of File Format Verification (D3-FFV), which is itself under Content Validation. D3FEND's description is brief: some formats, such as JPEG, include encoded or compressed sections, and the technique verifies that those sections are present and decode correctly according to the specification. This card turns that into practice for upload pipelines, mail and file gateways and scanning engines, and covers how to verify the checks and where they fall short. The wider family is covered in D3-FFV File Format Verification and D3-CV Content Validation.

Key takeaways

• Two questions, not one. Does the compressed or encoded section decode cleanly, and does it decode within agreed size, count, depth and time limits? D3FEND defines the first; the second is what keeps the check itself safe.
• Check before you trust declared sizes. OWASP ASVS 5.0 requirement V5.2.3 asks applications to check compressed files against a maximum uncompressed size and a maximum number of files before uncompressing them, but header values can lie, so enforce the limits during decompression as well.
• The decoder is attack surface. The NCSC import pattern warns about malformed compressed content that targets decompression code, so run decoding in a constrained, up-to-date component.
• A clean decode is not a clean file. A valid archive can hold malicious members; FCDC proves structure, not intent, and must be followed by content analysis.
• Limit hits are events. A file that exceeds a decompression limit or fails to decode should be blocked or quarantined and logged, not silently passed through unscanned.

D3-FCDC at a glance

How it works

Both D3FEND references come from digital forensics, where the question is whether a run of bytes is a real, intact file. Garfinkel's paper describes validators that run cheap checks first (header and footer bytes), then container structure checks, then decompression. Its JPEG validator decodes the Huffman-coded image data, and its ZIP validator checks the central directory records and then tests the compressed data. The same staged logic applies to security filtering:

1. Locate the compressed or encoded sections the format specification says must exist: archive members, PDF object streams, image scan data.
2. Read declared sizes (compressed and uncompressed size per member, member count) and reject anything over policy before decoding.
3. Decode under limits: stop when output bytes, member count, nesting depth or elapsed time cross a threshold, whatever the header claimed.
4. Treat decode errors as findings: CRC failures, truncated streams and invalid symbols mean the file is corrupt or crafted.
5. Pass the decoded content on for semantic analysis, the "further analysis with semantic knowledge" in D3FEND's definition, such as malware scanning or D3-FCOA File Content Analysis.

The resource side is a recognised weakness class: CWE-409, Improper Handling of Highly Compressed Data (Data Amplification), describes a product that does not handle compressed input "with a very high compression ratio that produces a large output". The NCSC Safely Importing Data pattern adds that nested content should be unpacked and verified at each level and that "limits should be placed on the amount of nesting and recursion allowed".

ATT&CK techniques D3FEND relates to D3-FCDC

Relationship type: inferred only. D3FEND has no direct ATT&CK mapping for D3-FCDC. Its page shows a long "inferred, experimental" list derived through the File artefact family it shares with Content Validation (D3FEND 1.6.0, checked November 2026). Because the inference is that broad, the list says more about files in general than about decompression; the summary below groups it, and the full table is on the D3-CV Content Validation card. Each ID was checked against ATT&CK v20.

D3FEND still lists some IDs that ATT&CK v20 has revoked; the table shows the successors: Plist Modification is now T1647, DLL Side-Loading is folded into T1574.001, Clear Linux or Mac System Logs is now T1685.006, and Impair Command History Logging is now T1690. D3FEND also lists Launchd, which ATT&CK v20 marks deprecated with no successor, so it is left out.

Where decompression checking genuinely bites (NHI Mgmt Group view): malicious attachments and uploads delivered inside archives (T1566.001, T1204.002), where a malformed or oversized archive is either a scanner evasion attempt or a resource attack, and archived collected data (T1560) that a data loss control must be able to open to inspect. See the T1027 Obfuscated Files or Information Defensive Guide.

Where it is implemented

Defaults above are as stated in the ClamAV clamd.conf.sample file, checked November 2026. The limit names and defaults are product specific; the principle, a budget for bytes, files, depth and time, applies to any engine.

Implementation steps

1. Inventory every place untrusted compressed content is opened: upload endpoints, mail gateways, file transfer, document preview, search indexing and backup ingest. Each is a decompression point.
2. Set a budget per point. Maximum uncompressed size, member count, nesting depth and decode time, written into the upload or gateway specification (ASVS V5.1.1 asks for documented maximum size "including unpacked size").
3. Enforce during decoding, counting real output bytes rather than trusting header sizes, and stop at the first limit hit.
4. Decide the failure action. Fail closed: block or quarantine files that fail to decode or exceed limits, and turn on alerting for limit hits (for ClamAV, AlertExceedsMax) so they are not silently passed unscanned.
5. Isolate the decoder. Run decompression in a separate, low-privilege process or container with memory and disk quotas, kept patched.
6. Pilot in log-only mode. Record limit hits and decode errors for two to four weeks to size the budgets against real business files before blocking.
7. Roll back by budget, not by switch. If a limit blocks legitimate files, raise that one limit for that one path; do not disable the check.

How to verify it works

• Test corpus: keep a small, harmless test set: a truncated archive, an archive with a bad CRC, an archive nested beyond your depth limit, an archive with more members than allowed, and a highly compressed file that expands past the size budget. Each must be rejected or quarantined with the right reason.
• Header lie test: include an archive whose declared uncompressed size is small but whose real output is large; this proves limits are enforced on output, not on headers.
• Path test: include members with absolute paths or ".." components and confirm nothing is written outside the target directory.
• Resource watch: during tests, confirm memory, disk and CPU on the decoding host stay within quota and that no worker hangs.

Limits, bypasses and failure patterns

• Trusting the header: checking the declared uncompressed size and then decoding without a running byte count lets a crafted archive exceed the budget.
• Fail open on limits: scanners that stop at a limit and report the file as clean let attackers pad or nest payloads past the limit. Alert on limit hits.
• Checking the outer layer only: nested archives and documents inside archives need the same checks at each level, as the NCSC pattern describes.
• Encrypted archives: a password-protected archive cannot be decoded by the gateway at all. Decide a policy (block, quarantine, or hold for release) and record it.
• Decoder vulnerabilities: the check runs the code attackers target. An unpatched or unsandboxed decoder turns the control into the entry point.
• Taking success as safety: a cleanly decoded archive can still contain a malicious executable or macro; FCDC must be followed by scanning or disarm.

Framework mapping

Related countermeasures

• File Internal Structure Verification (D3-FISV): checks the container structure around the compressed data. See D3-FISV File Internal Structure Verification.
• File Magic Byte Verification (D3-FMBV): the cheap first-stage check. See D3-FMBV File Magic Byte Verification.
• Content Format Conversion (D3-CFC): rebuilds decoded content in a safer form. See D3-CFC Content Format Conversion.
• Content Quarantine (D3-CQ): where files that fail the check should go. See D3-CQ Content Quarantine.

Practitioner checklist

• List every point where untrusted compressed content is decoded.
• Document a size, file count, depth and time budget for each point.
• Enforce limits on real output bytes, not declared header sizes.
• Fail closed and alert on decode errors and limit hits.
• Reject absolute paths, ".." components and symlinks in archive members.
• Run decoders in a patched, low-privilege, resource-limited process.
• Set and record a policy for encrypted archives.
• Run the test corpus on every release of the pipeline.

Standards and references

• MITRE D3FEND: File Content Decompression Checking (D3-FCDC)
• MITRE CWE: CWE-409 Improper Handling of Highly Compressed Data (Data Amplification)
• OWASP: Application Security Verification Standard 5.0 (V5 File Handling)
• NCSC: Pattern: Safely Importing Data
• OWASP: File Upload Cheat Sheet
• Digital Investigation: Garfinkel, Carving Contiguous and Fragmented Files with Fast Object Validation
• Python documentation: zipfile, Decompression pitfalls
• ClamAV: clamd.conf.sample scan limits

Related NHI Mgmt Group resources: D3-FFV File Format Verification · D3-CV Content Validation · Secure File Upload Handling Guide · File Upload Security Guide · MITRE D3FEND Guide