Why Most Email Gateways Miss Phishing PDFs That Use /OpenAction to Launch Attacker URLs

When a PDF lands in your inbox with no malicious JavaScript, no obfuscated macros, and no password-protected content, most email security gateways give it a clean bill of health. That assessment is often wrong. The reason sits in a part of the PDF specification that scanning tools routinely ignore.

The /OpenAction entry is a standard PDF dictionary field that instructs the reader to automatically execute an action when the document opens. In legitimate software it handles things like auto-printing or jumping to a specific page. In attacker tooling it opens a browser to a phishing login page the moment the victim opens the file.

What the attack actually looks like

A typical attack flow:

Attacker crafts a PDF with no malware in the body

The file includes an /OpenAction dictionary with a `/URI` action type pointing to a target like `https://login.example.com.legit-company.com/steal`

The victim opens the PDF - their browser opens to the phishing URL automatically

The email gateway sees a clean PDF and passes it

No sandbox, no link scanning, no warning

The payload is not in the PDF body. It is in the action dictionary. Standard AV scans of the PDF stream will not catch it because there is nothing malicious there - the malicious part is a metadata instruction telling the PDF reader what to do when the file opens.

Why gateways miss this

Email security appliances scan PDFs at the file level. They look for:

• Embedded JavaScript
• Known malicious exploit patterns in the PDF body
• Password-protected content that might hide something
• Suspicious stream objects

Very few products parse the PDF action dictionary. The /OpenAction field has been in the PDF specification since at least PDF 1.2 (the 1990s), but it sits outside the threat-signature scanning model that most email gateways use.

This is not a zero-day. It is a documented feature with a documented abuse pattern, sitting in a gap most security tools have simply not covered.

How detection actually works

Effective detection requires parsing the PDF's action dictionary:

• `/OpenAction` entries with a `/URI` action type
• Any `/AA` (Additional Actions) entries that open URLs on page open or close
• `/GoTo` actions that redirect internally - less dangerous but worth flagging in context

Sandboxing is the most reliable method. Rendering the PDF in a locked-down reader and monitoring outbound connections catches behavior that signature scanning misses. Google Workspace's advanced sandboxing and some commercial threat protection tools do this. Most on-premises email gateways do not.

Link rewriting does not help here. If the visible link in the email body is benign but the /OpenAction target is malicious, rewriting the visible link leaves the hidden action intact. The gateway rewrites what it can see and ignores what it cannot.

What this means for your authentication monitoring

DMARCFlow monitors your sending domain's authentication posture, not your inbound file scanning - so it will not catch a PDF with a malicious /OpenAction before it reaches a user. But if this attack method is being used against your organization, it will surface in your DMARC aggregate reports in a couple of ways. Look for sudden spikes in forwarding volume, or messages from domains that look similar to yours but are not authorized - both are downstream signals that something your gateway missed has reached users. The detection signal is not in the PDF itself but in the authentication failure patterns that follow.

FAQ

Does DMARC help with PDF attacks?

No. DMARC operates at the DNS and email header level, verifying that the sending server is authorized for your domain. It has no visibility into attachment content or PDF action dictionaries.

Are all PDFs with /OpenAction malicious?

No. Legitimate PDFs use /OpenAction for valid purposes. The signal to watch for is /OpenAction pointing to external domains in an unexpected received PDF.

Does my current email gateway scan for /OpenAction?

Likely not. Most mainstream products do not parse PDF action dictionaries. Check with your vendor - some advanced sandboxing products do, but it is not standard in traditional gateway AV scanning.

How do I test if my gateway catches these?

Send yourself a test PDF with an /OpenAction pointing to a harmless URL you control. If the URL fires when you open the file, your gateway is not catching it.

What should I do if my gateway misses these?

Report it as a gap to your vendor. In the meantime, employee training on suspicious PDFs - especially those that auto-open browser tabs - is a practical stopgap