Parser inventory

Every engine module that turns attacker-controlled bytes or text into structure, with the bounds it actually declares, the test that covers it, and whether the fuzz harness reaches it.

"Attacker-controlled" here means one of four sources:

• a file the user picked (upload, share target, drag-and-drop, file input),
• an asset fetched over host.net or read back out of storage,
• a URL param, because URL mode is first-class and every link is public,
• a stream nested inside one of those, for example an ICC profile inside a JPEG, a CMap inside a PDF content stream, or an XML part inside a .pptx zip.

Two things this page deliberately does not do. It does not list the engine's format writers as attack surface. engine/src/tiff.ts, apng.ts, webp-anim.ts, emf.ts, eps.ts, dxf.ts, hdr.ts, pptx.ts, pdfx.ts, zip-crypto.ts and pdf-crypto-r6.ts are byte emitters that consume engine-internal IR, pixel buffers, or already-encoded frames from the shell, so a hostile file never reaches them (see "Writers, not parsers" below). And it does not restate the shell's own gates: the web shell caps upload size and inflates zips before the engine sees a part map, and those caps live in shells/web/src/bridge/, not here.

Fuzz coverage is the registered target list in tests/fuzz/targets.ts (ALL_TARGETS, at the end of the file). There are nineteen: c2pa-verify, cbor, media-sniff, pdf-map, x509, file-metadata, strip-metadata, video-meta, data-import, pptx-read, pptx-patch, pptx-bridge, icc, der-read, c2pa-extract, c2pa-containers, url-pack, wav and depth-hint. tests/fuzz-regression.test.ts replays the seven saved regression inputs in tests/fuzz/regressions/ and runs a few hundred seeded mutations per target inside the normal npm test glob; node tests/fuzz/run.ts is the standalone soak.

The parsers

Writers, not parsers

Listing these as attack surface would overstate the problem. Each consumes engine-internal IR or already-encoded bytes the shell produced, not a file a stranger sent.

The standard to follow

engine/src/pptx-read.ts is the module to copy when you add a parser. Its caps block sits at lines 156 to 167, immediately after the public types and before the first walker, so a reviewer meets the bounds before the code they bound:

// ─── hardening caps ──────────────────────────────────────────────────────────

const MAX_PART_BYTES = 24 * 1024 * 1024; // skip parsing a part bigger than this
const MAX_PART_CHARS = 16 * 1024 * 1024;
const MAX_SLIDES = 2000;
const MAX_NODES_PER_SLIDE = 8000;
const MAX_GROUP_DEPTH = 16;
const MAX_PARAS = 4000;
const MAX_RUNS_PER_PARA = 4000;
const MAX_TABLE_ROWS = 2000;
const MAX_TABLE_COLS = 512;
const MAX_TEXT_LEN = 200_000; // per run/cell text clamp
const MAX_DFS_VISITS = 200_000; // bound any descendant search
const MAX_COORD = 1e11; // EMU magnitude clamp (slide width is ~1.2e7)

Four properties make this the exemplar rather than merely a long list.

The threat model is written down. The module header carries a SECURITY section that names it: "a hostile zip is the threat model, same as PDF". It then states the consequences as commitments, not hopes: every part is size-capped before parsing, slide, node, paragraph, run and table counts are capped, group-shape recursion is depth-capped, and "a malformed or hostile part NEVER throws, we return what parsed and skip the rest".

Every cap has a unit and a real-world comparison. MAX_COORD = 1e11 carries // EMU magnitude clamp (slide width is ~1.2e7), which tells the next reader the cap sits four orders of magnitude above anything legitimate. A number with no comparison point is a number nobody can safely change later.

It says what it delegates. "XML entity-expansion (billion-laughs) is the injected parser's responsibility, but we additionally bound every DFS by a visited-node counter so a pathologically deep/wide tree can't hang us." Naming the boundary is what lets a reviewer check the other side of it, and adding the counter anyway is defence in depth for the case where a shell injects a parser without those protections.

The contract is one sentence and it is testable. Never throw, return what parsed. tests/pptx-read.test.ts asserts it, and the pptx-read fuzz target asserts it against mutated real decks.

engine/src/icc.ts is the same discipline applied to a harder format, and its caps block header is worth borrowing verbatim: "Every one of these bounds something a hostile file declares", followed by the largest value each cap was measured against across forty real profiles.

Known gaps

Verified against ALL_TARGETS in tests/fuzz/targets.ts and against each module's own source. An earlier pass over this ground over-counted, because it treated the format writers as parsers.

Genuine parsers with no fuzz target, and no named allocation bounds of their own. These are the ones worth attention first.

• engine/src/der-read.ts is the highest-value gap on this list. It is the shared TLV walker for every certificate and signature path, its own header says "DER inputs here come straight out of attacker-controlled files", it has no test file of its own, and it has no registered target. It is exercised only indirectly, through x509 and c2pa-verify. Its bounds are per-read checks rather than named constants, which is defensible for a TLV walker, but the absence of a tests/der-read.test.ts is not.
• engine/src/brand-import.ts accepts a .penpot project's unzipped entries and declares no caps at all. A pathological set count or a token document with thousands of sets is bounded only by the caller.
• engine/src/svg-path.ts has a sound structural argument for safety, a linear tokenizer with no declared-length field, but no cap on emitted segment count and no fuzz target, despite taking d strings from URL params.
• engine/src/zzfxm.ts renders whatever ZzfxSong it is given. midi.ts caps the MIDI path correctly, but nothing caps a song object arriving by another route.

Parsers with declared bounds but no fuzz target. Lower risk, still uncovered by the mutation harness: url-pack.ts, seal.ts, svg-colors.ts, svg-custgeom.ts, midi.ts, wav.ts, png-unfilter.ts, pdf-svg.ts, pdf-artwork.ts, pdf-text.ts, pdf-redaction.ts. Of these, url-pack.ts and wav.ts are the best candidates to add next: url-pack because its input is a public URL param and its threat is a decompression bomb, wav because it is a full container walker with a single cap.

Missing test files. der-read.ts, c2pa-extract.ts and c2pa-containers.ts have no same-name test. The latter two are covered in aggregate by the C2PA suites, which is not the same as having their own failure cases pinned. der-read.ts has neither its own test nor a target.

Named but unbounded. pdf-map.ts caps array nesting and CMap ranges but not the total node count it emits. pdf-artwork.ts compensates with MAX_NODES = 4000 for its own consumption, and pdf-svg.ts caps per-node path length, so no current consumer is unbounded. A new consumer of interpretPdfPage would be, and would have to bring its own cap.

Adding a new parser

Four requirements. All four, before the module lands.

1. *Declare named MAX_ constants in one block, near the top, before the walkers.** One constant per thing a hostile input can declare: byte length, element or record count, nesting depth, coordinate magnitude, text length. Each gets a comment with its unit and the largest legitimate value you measured. Never inline a bare number into a loop bound. If a bound is genuinely structural rather than numeric, say so in the header the way svg-path.ts and der-read.ts do, and explain why.

1. Bounds-check before reading, not after. The invariant der-read.ts states is the one to internalise: check a multi-byte length head before consuming its bytes, because an out-of-range Uint8Array read yields undefined, undefined NaN-poisons the arithmetic, and a NaN comparison makes the guard that follows silently false. That is how a truncated TLV gets accepted.

1. Pick a contract, state it in the header, and honour it everywhere. There are three legitimate contracts in this codebase and the choice follows from what the caller does with the answer.

• Best-effort reader, never throws, returns null or a partial result. The house contract, named after png-unfilter.ts and stated most fully in icc.ts and file-metadata.ts. Correct when a failure means "we could not read this", and the UI degrades gracefully.
• Throws promptly on malformed input. der-read.ts and the CBOR decoder in c2pa-extract.ts. Correct when a silent mis-parse would be worse than an error, which is the case for anything feeding a cryptographic check.
• Fails closed by throwing. strip-metadata.ts. Correct when returning the input unchanged would be presented to a user as a safety guarantee. A privacy or security control must never fail open.

1. Add a same-name test file and register a fuzz target. tests/<module>.test.ts covers the truncation, garbage and cap-tripping cases by hand. Then add a FuzzTarget to tests/fuzz/targets.ts with a small seed corpus of valid inputs, built where possible from the engine's own writer so the seeds are real container layouts, an invoke() that does not swallow errors (the runner classifies a thrown validation error as the desired behaviour, and a hang or allocation blow-up as a finding), and an entry in ALL_TARGETS. Note the entry-point comment convention at the top of that file, which records exactly which function each target hits. Any input a discovery run finds goes into tests/fuzz/regressions/ as a .bin, named for the module and the failure, and tests/fuzz-regression.test.ts will replay it on every npm test from then on.