Engineering a Zero-Trust Document Upload Pipeline: Implementing ClamAV and Content Disarm &…

When architecting a platform that requires users to upload documents — such as verification proofs, certifications, or transcripts — file ingestion instantly becomes one of your largest security liabilities.

During the initial design phase of a background verification and resume-building feature, the baseline implementation seemed straightforward: accept the file stream from the client, perform size and MIME-type validation, and persist the asset directly to an object storage bucket like Cloudflare R2.

However, conducting a rigorous threat modeling exercise reveals a critical vulnerability in this naive workflow. Because these uploaded documents are explicitly designed to be reviewed by third parties — specifically corporate recruiters and hiring managers — the platform inherently acts as a high-trust vector. If a malicious actor uploads a weaponized PDF or an image embedded with an exploit payload, the platform blindly caches and serves that threat. The moment a downstream reviewer downloads and executes that file, the corporate network is compromised.

To solve this, I moved away from passive file acceptance and engineered a zero-trust ingestion pipeline that combines active signature scanning with binary structural reconstruction.

The Threat Model: Weaponized Attachments and Downstream Execution

Traditional security validation relies heavily on checking file extensions and matching Magic Bytes (the initial signature bytes of a file format). While this prevents accidental malformed uploads, it does nothing to stop sophisticated attacks:

Polyglot Files: Files crafted to validly execute as two different file types (e.g., a valid GIF header wrapped around a malicious payload that triggers when parsed by an unpatched library).
Embedded Exploits: PDFs containing embedded malicious JavaScript, macro-enabled workflows, or zero-day execution scripts targeting vulnerabilities in PDF viewer applications (e.g., Adobe Reader or native browser parsers).
Metadata Exploits: Malicious strings embedded within EXIF metadata fields designed to trigger buffer overflows or command injection inside image processing libraries.

Relying on Cloudflare R2's data security isn't enough; object storage guarantees durability and transport encryption, not object sterility. I needed an active pipeline to neutralize threats before they reached storage.

Phase 1: In-Memory Signature Isolation via ClamAV

The first design constraint was simple: no untrusted file could touch permanent block storage or the host filesystem prior to verification.

I reconfigured the upload infrastructure to receive incoming chunks directly into an isolated temporary memory buffer. Before any application logic parses the file structure, the memory buffer stream is forwarded directly to a ClamAV daemon via a dedicated UNIX socket.

[Incoming Payload] ──> [Isolated Memory Buffer] ──> [ClamAV Daemon Socket]
                                                            │
                                                   ┌────────┴────────┐
                                            [Malware Found]   [Clear]
                                                   │                 │
                                                   ▼                 ▼
                                            (Abort Request)   [CDR Processing]

[Incoming Payload] ──> [Isolated Memory Buffer] ──> [ClamAV Daemon Socket]
                                                            │
                                                   ┌────────┴────────┐
                                            [Malware Found]   [Clear]
                                                   │                 │
                                                   ▼                 ▼
                                            (Abort Request)   [CDR Processing]

ClamAV acts as a highly efficient frontline filter. It scans the raw binary content against millions of known malware signatures, macro patterns, and script injections. If a signature matches, the transaction is immediately aborted, the buffer is purged from volatile memory, and the request is terminated with a 400 Bad Request.

While effective at catching automated, known threats, signature-based detection is inherently reactive. It leaves the system entirely vulnerable to zero-day exploits or highly targeted obfuscation techniques that have not yet been cataloged by threat intelligence databases.

Phase 2: Content Disarm and Reconstruction (CDR)

To achieve a true zero-trust posture, I shifted my architectural philosophy from detection to reconstruction. Instead of validating if the user's file is safe, the application acts on a basic premise: the incoming file structure is entirely untrusted and will be destroyed.

Rather than over-engineering application-level parsing workers to manually deconstruct binary streams, I implemented a lean Content Disarm and Reconstruction (CDR) workflow leveraging a server-side document interpreter utility. The engine isolates the raw visual layout data and completely rebuilds the container from scratch.

1. Binary Distillation and Flattening

Once the file clears ClamAV, the server-side interpreter ingests the untrusted PDF stream. It parses only the core visual layers and text structures required to render the document. Any active content components — such as embedded dynamic forms, hidden action hooks, or malicious JavaScript execution nodes — are completely ignored by the processing engine since they do not map to static visual elements.

2. Elimination of the Attack Surface

Because the distillation engine strictly processes the rendering elements, hidden trailing bytes, malformed object streams, and malicious structural anomalies are bypassed entirely. They fail to compile into the new stream and are dropped in the transient memory space of the original discarded container. As a secondary benefit, structural metadata leaks are neutralized automatically.

3. Sterilized Reconstruction for R2 Storage

The interpreter outputs a completely fresh, server-authored PDF container (standardized as a flattened, immutable document).

[Untrusted PDF Stream] ──> [System Interpreter Engine] ──> [Reconstructed PDF] ──> [Cloudflare R2 Bucket]

[Untrusted PDF Stream] ──> [System Interpreter Engine] ──> [Reconstructed PDF] ──> [Cloudflare R2 Bucket]

The file that ultimately arrives in Cloudflare R2 contains zero bytes of the original structural container submitted by the user. It is a sterile, server-generated asset featuring clean headers, normalized object structures, and zero executable capability.

Infrastructure Resilient by Design

By introducing a streamlined CDR translation layer behind ClamAV, I eliminated reliance on guessing whether an exploit exists. If an attacker uploads a highly sophisticated zero-day PDF exploit that slips past ClamAV's signature analysis, the vulnerability fails to survive the distillation process. It is treated as non-conforming structural noise, stripped out, and destroyed during reconstruction.

When a recruiter eventually hits the endpoint to download an applicant's background proof, they pull a safe, server-generated asset from R2. The upload pipeline effectively guarantees that the application can scale its document processing capabilities without ever acting as an accidental distribution network for malware.

Closing Thoughts

Security is rarely about finding the perfect tool it's about making the right architectural decisions. Building this pipeline was a reminder that a little paranoia, when applied thoughtfully, goes a long way.

Contents