A CV that mentions JavaScript is refused as a dangerous PDF

[wintermeyer]

The PDF gate that shipped with #2104 inflates a file's streams and looks for the token names that make a PDF dangerous, but it reads the page text along with the structure, so a document whose visible words contain /JavaScript, /OpenAction or /EmbeddedFile is refused. Two macOS-produced PDFs whose text read "TypeScript/JavaScript" were both refused as :javascript while pdfinfo said JavaScript: no. The scan should decide on the document structure and not on what the pages say.

Nobody notices today, because ATTACHMENT_UPLOADERS defaults to admins — but this has to be narrowed before files are opened to members, and a CV listing web skills is exactly the file somebody would attach first.

Where: Vutuv.Uploads.PdfGate.

An AI agent wrote this text in my name. I know that is problematic.

[wintermeyer]

Built in PR #2195. Recording the measurements, because this loosens a defence.

The invariant

Blanking a range out of the scan is an exemption, and it may only be taken
where a real parser reads the same bytes as content. A linear scan and a
parser part company only across an object boundary — inside an object stream a
reader picks each object out at the offset the stream's own table records — and
everything dangerous across such a boundary is a dictionary. So a candidate
range spanning a << or a >> is never blanked, and an unterminated ( is not
a string at all. Calibrated: let blank_unless_dictionary/5 exempt every range
and the "launch wrapped in brackets" test goes red.

Which question goes to whom, measured 2026-09-11

Not symmetric, and that was the surprise:

• pdfinfo answers JavaScript: yes for a script in the catalog's
  /Names /JavaScript tree, in /OpenAction, in the catalog's /AA, in a
  page's /AA and on an annotation's /A. So /JavaScript left the byte
  scan; four new tests pin that, and removing poppler's answer turns six red.
• pdfdetach -list counts a file in the /EmbeddedFiles name tree, in a
  /Collection and on a /FileAttachment annotation (typed or not) — but
  answers 0 for one reached through /AF on the catalog, /AF on a page,
  or a /RichMedia annotation's assets. So /EmbeddedFile stayed, and an
  /AF fixture guards it.
• Nothing reports an action, so /OpenAction, /Launch, /SubmitForm and
  /ImportData stay in the bytes, now read out of PDF syntax rather than text.

The corpus: 4,542 PDFs, both gates end to end

/Applications, /Library, /System/Library, /usr/share, homebrew, plus ~2,400
real documents from this machine, plus the same CV produced by Chrome, macOS
Quartz, LibreOffice and Ghostscript, each also run through
qpdf --object-streams=generate.

10 documents changed, every one of them a refusal the old rule should not
have made. Nothing went the other way.

• 9 × javascript → accepted. Eight are the CVs built for this measurement.
  The ninth is the interesting one: a 312-page programming ebook, refused
  because it links to https://developer.mozilla.org/en-US/docs/Web/JavaScript/Guide/…
  inside a /URI action. pdfinfo says JavaScript: no, pdfdetach says 0.
• 1 × javascript → unreadable: still refused, on the pre-existing rule that
  a stream which will not finish inflating is a scan that did not pass.
• 0 × anything → stricter, and 0 × embedded_files → accepted: the four
  invoices that carry a real attachment are still refused, by the byte scan
  rather than by poppler, which is exactly why that name stayed.

The attacks, all through Attachments.create_pending/3

The four bypasses #2104's blind review found, rebuilt and re-run: the 9 MB
catalog through one qpdf --object-streams=generate → :unreadable; the
stored deflate block carrying a literal endstream → :open_action;
/OpenAction /S /GoTo … /Next /S /Launch → :open_action; a page
/AA /Launch → :open_action. And the rest: user password and owner password
→ :encrypted; /JavaScript, /OpenAction and /EmbeddedFile hidden in an
object stream (with the xref stream qpdf writes beside it) → :javascript,
:open_action, :embedded_files; /Open#41ction << /S /L#61unch >> →
:open_action; a launch appended by an incremental update after a clean
revision → :open_action; a /FileAttachment annotation → :embedded_files;
a ZIP named .pdf → :invalid_file; a PDF header with garbage behind it →
:unreadable; a stream that inflates to 20 MB → :unreadable.

Two more the narrowing itself created, both found by a reviewer, both now
closed and both with a test of their own:

1. A launch wrapped in brackets that would have blanked the catalog around it →
   :open_action, since a range holding a << is never exempt.
2. A denial of service. The blanking pass restarted one byte later after
   refusing a range, so 60 KB of % with a << behind them and a single
   /Launch in a string — seven bytes to arm it — cost 2.8 seconds in the
   LiveView's own process and quadrupled with every doubling, which puts a file
   at the 20 MB cap in the region of days. It now resumes past the range: 19 ms
   flat for 15, 30 and 60 KB, and 321 million reductions become 64,525. Guarded
   by a reduction bound, calibrated in both directions.

Left open, deliberately

An /AcroForm /XFA form carries its script in XML rather than in a PDF action,
and neither poppler's answer nor any name here sees it. So does an embedded
file reached through /AF whose stream also drops its /Type /EmbeddedFile.
Both are named in the module; closing either is a widening that wants its own
measurement, and both matter before ATTACHMENT_UPLOADERS flips to members.

An AI agent wrote this text in my name. I know that is problematic.

[wintermeyer]

A blind review of PR #2195 found five constructs the first version accepted
and stored, and it was right about the cause: I had leaned the JavaScript
question on pdfinfo alone. Rebuilt from scratch rather than from my own
fixtures, all five reproduced through Attachments.create_pending/3, and all
five are refused now.

What pdfinfo actually does, measured 2026-09-11

construct	plain pdfinfo	-f 1 -l 999999	old gate	now
/AA /O script on page 2 of 3	no	yes	stored	:javascript
the same on page 3 of 3	no	yes	stored	:javascript
the same on page 20 of 20	no	yes	stored	:javascript
/OpenAction … /Next <js>	no	no	stored	:javascript
the same with /Next as an array	no	no	stored	:javascript
a field's /AA /C	yes	yes	refused here, stored on CI	:javascript

Without a page range pdfinfo reads page 1 and stops — so a two-page CV,
which is most of them, was blind. It follows no /Next chain even with the
range. And CI proved the third gap independently: the same /OpenAction script
is yes on poppler 26.09 here and unreported on the runner, so for software
third parties install there is no version to rely on.

What changed

/JavaScript is back in @name_regexes, beside poppler rather than
instead of it — the same conclusion pdfdetach had already forced for
/EmbeddedFile, which I had drawn there and not here. The call gets
-f 1 -l 999999, and an exit-0 answer missing the fields we read now counts as
no answer rather than as a clean bill (a pdfinfo that prints nothing used to
get a JavaScript-carrying PDF stored). The #2136 fix survives all of that
untouched, because blanking strings, hex strings and comments is what fixes the
CV; the shorter name list never was.

Two defects of my own, both closed

• A loop. A file whose last byte is a lone < made the hex branch compute a
  reach of 0 and resume where it started. 639 bytes, and the process never came
  back.
• A cost. Refusing to blank a range that holds a << and resuming one byte
  later re-reads it: 60 KB of % cost 2.8 s and quadrupled per doubling. The
  fix that skipped such a range instead was worse in the other direction — it
  dropped the candidates inside, which refused the CV again. Blanking now
  stops at the first << or >> and carries on there: same invariant,
  read once. The hungriest real document went from reading itself 1,024 times
  over to 8, and a budget in bytes examined backstops the rest at 32.

The corpus, both gates end to end

4,738 real local PDFs, nine answers changed, none newly refused.

• 7 × javascript → accepted. Six are the CVs built for this measurement; the
  seventh is a 312-page programming ebook refused because it links to
  developer.mozilla.org/en-US/docs/Web/JavaScript/Guide/… from a /URI
  action.
• 2 × refused for a different reason and still refused (javascript and
  open_action, both now :unreadable on a budget the module already had).
• 0 × anything newly refused. An interim version of this repair refused 28
  real documents on the blanking cost alone, which is how the cut-at-the-
  dictionary rule was found; at the ceiling that shipped, exactly one document
  of the 4,738 spends its allowance, and that one is refused either way.

The invariant, unchanged

Blanking is an exemption from the scan, and it may only be taken where a real
parser reads the same bytes as content. A linear scan and a parser part
company only across an object boundary, and everything dangerous across one is a
dictionary — so nothing blanked may span a << or a >>.

An AI agent wrote this text in my name. I know that is problematic.

[wintermeyer]

Shipped in #2195. A PDF name is structure and a PDF string is content, so the gate now blanks strings, hex strings and comments before it looks for a name. That is what lets a CV say "HTML/CSS/JavaScript" without being read as a program, and it also lifted a 312-page ebook that was refused for merely linking to MDN. /JavaScript stays in the byte scan beside poppler rather than being handed to it alone, because pdfinfo reads only page 1 without an explicit page range and does not follow the /Next chain of an action; a blind review found five constructs that were accepted while that was not so.

Three things stay unseen and are deliberately not closed here: the script of a /Rendition action, which hangs under /JS rather than /JavaScript and escapes poppler behind a /Next chain; an /AF associated file whose stream also drops /Type /EmbeddedFile; and XFA forms, whose script is XML. All three matter before ATTACHMENT_UPLOADERS flips to members.

An AI agent wrote this text in my name. I know that is problematic.