VAERS Archive Forensics Report

Prepared: 2026-05-12
Working directory: /home/datapage/Documents/VAERS/Downloads
Examiner: Claude Code (claude-sonnet-4-6)
Methodology: Full CRC integrity verification via Python zipfile.testzip() (reads and decompresses every byte, verifies stored CRC-32), supplemented by binary-level structural inspection, SHA-256 hashing, ZIP local-header scanning, and filesystem metadata analysis.

1. Executive Summary

Bottom line: 342 of 344 archives are structurally and cryptographically intact. Two archives are irrecoverably corrupt (missing End-of-Central-Directory records — both already labeled BROKEN). The circumstances of these two files are consistent with interrupted downloads but deliberate truncation cannot be excluded and is discussed in Section 4.

2. Collection Overview

Date range and cadence

Earliest snapshot: 2003-12-31
Latest snapshot: 2026-04-24 (labeled as 2026-04-24)

Archive structure evolution

• 2003–2008 (3 entries/archive): Single-year format — each archive contains only that calendar year's three CSVs (DATA, SYMPTOMS, VAX).
• 2009–present (63–114 entries/archive): Cumulative format — each archive contains all data from VAERS inception (~1990) through the snapshot date, organized by calendar year. Entry count grows by 3 per year added (one CSV trio per year).

3. Integrity Results — All Files

3.1 Files Passing Full CRC Verification (342)

All 342 files listed below passed zipfile.testzip() with no CRC errors on any member.

4. Corrupt Archives — Detailed Findings

4.1 VAERS2016-02-14BROKEN.zip

Technical failure mode: The file terminates mid-stream within the compressed deflate block for 2012VAERSDATA.csv. The End-of-Central-Directory record, which ZIP tools require to parse the archive, is missing because the file was never written to disk completely.

4.2 VAERS2022-02-25BROKEN.zip

Technical failure mode: The file terminates with no EOCD record. Notably, the entry order within the partial archive is non-sequential across years — this reflects the internal ordering of the source archive, not corruption. The partial file contains roughly the first 21% of a 530 MB archive.

4.3 Forensic Assessment: Benign Failure vs. Deliberate Tampering

Both BROKEN files are unreadable by standard tools. However, the forensic record is ambiguous and deliberate tampering cannot be excluded.

Evidence supporting benign interrupted download

1. Timestamp ordering: Both BROKEN files were written to disk before their respective good copies. BROKEN-2016 preceded the good copy by 94 seconds; BROKEN-2022 preceded it by 31 minutes. This is the expected pattern for: partial download → renamed BROKEN → successful re-download.

2. Truncation mid-deflate-stream: Both files end within an active DEFLATE compressed block, not at a logical CSV or ZIP entry boundary. Network interruptions produce exactly this pattern; deliberate truncation typically aligns to a meaningful boundary.

3. Good copies present and intact: Both dates have complete, CRC-verified good copies. An adversary trying to suppress data would not typically preserve and store a complete, valid copy alongside the damaged one.

4. Naming convention: The BROKEN suffix in the filename indicates the collector was aware of and documented the problem — normal practice for a thorough archivist.

Evidence that cannot rule out deliberate tampering

1. Coherent internal structure: Both files contain valid, syntactically correct ZIP local-file headers throughout — they are not random or zero-filled data. A sophisticated actor who wished to truncate these files would produce exactly this result.

2. Politically sensitive dataset: VAERS data is publicly significant vaccine safety surveillance data. Selective corruption or suppression of historical snapshots is a conceivable adversarial objective.

3. Disproportionate truncation of BROKEN-2022: At only 21.1% complete (111 MB of 530 MB), this file is missing a large proportion of 2022 data — the period of peak COVID-19 vaccine reporting volume. The near-complete earlier years' data that is present may be less contentious than what is missing.

4. Asymmetric truncation points: BROKEN-2016 is truncated at ~2012 boundary; BROKEN-2022 at ~21% through the file. If both were failed downloads started at the same time under the same conditions, one would expect more similar completion ratios. The disparity (60% vs. 21%) is explainable by different file sizes and download speeds, but is worth noting.

5. No independent chain-of-custody hash: Without SHA-256 hashes published by the original VAERS data source at time of download, there is no way to verify whether the good copies themselves have been tampered with — only that they are internally self-consistent.

Assessment: The balance of evidence favors benign interrupted downloads. The timestamp record is the strongest indicator. However, given the sensitivity of this data and the lack of authoritative source hashes, the files should not be treated as definitively non-tampered. Cross-verification against an independent copy (e.g., another party who archived the same dates) would resolve the ambiguity.

5. Special Cases

5.1 VAERS2025-04-25PRERELEASE.zip

The PRERELEASE copy is byte-for-byte identical to the release copy. This is consistent with a pre-release data snapshot being published without modification. Both copies are redundant; only one is needed. No integrity concerns.

5.2 Missing Year: 2005

No archive for calendar year 2005 exists in this collection. The collection jumps directly from VAERS2004-12-30.zip to VAERS2006-12-30.zip. This is a collection gap, not corruption — it reflects that no 2005 VAERS snapshot was downloaded (or that CDC VAERS did not publish a separate 2005 archive in the format used here).

5.3 Collection Gaps (Missing Months)

The following months have no corresponding archive where surrounding months are present:

These gaps are collection gaps (no download for those months) and do not indicate data corruption. Since each archive is cumulative (all data from 1990 to snapshot date), adjacent monthly archives can be used to reconstruct what the missing months would have contained.

5.4 VAERS2022-02-25.zip — Anomalous Size

VAERS2022-02-25.zip (555,657,049 bytes) is noticeably larger than the archives immediately surrounding it:

• VAERS2022-02-18.zip: 527,437,059 bytes
• VAERS2022-02-25.zip: 555,657,049 bytes (+28.2 MB jump)
• VAERS2022-03-04.zip: 538,476,282 bytes (actually smaller)

This 28 MB spike followed by a drop is unusual. A possible explanation is a large batch of reports being added and then corrected/redacted the following week — a known VAERS data management pattern. The file passes full CRC verification; this is a data content observation, not a corruption finding. However, this snapshot warrants attention if row-level data analysis reveals unexpectedly large or anomalous report volumes.

6. Summary Table

7. Recommendations

1. Delete or archive the BROKEN files. They cannot be opened by any standard tool. The complete, CRC-verified counterparts are present. If you wish to preserve audit history, move the BROKEN files to a separate quarantine/ directory and document their SHA-256 hashes.

2. Obtain and verify source hashes. If CDC VAERS published SHA-256 or MD5 checksums alongside the original downloads, verify the good copies against those hashes. This is the only way to confirm the good copies themselves were not tampered with in transit or at rest.

3. Seek an independent copy for the BROKEN dates. To definitively resolve whether the data for 2016-02-14 and 2022-02-25 is authentic, obtain the same snapshots from an independent archiver (e.g., the Wayback Machine or a researcher who collected VAERS data independently) and compare SHA-256 hashes.

4. Investigate the 2022-02-25 size anomaly. The 28 MB spike in VAERS2022-02-25.zip relative to the week before and after warrants row-level review to determine what reports were added and whether any were subsequently removed in the following week's release.

5. Remove the PRERELEASE duplicate. VAERS2025-04-25PRERELEASE.zip is byte-identical to VAERS2025-04-25.zip. Keeping both occupies 570 MB without additional value.

6. Download the missing 2005 archive if one exists from the source, to fill the only missing calendar year in the collection.

Report generated 2026-05-12. All integrity checks performed locally; no archive contents were extracted to disk.