QR code phishing is a document problem

Seven in ten QR code phishing attacks arrived as a PDF attachment by March 2026.

The figure is Microsoft Threat Intelligence's, from its review of the first quarter of 2026. Over that quarter QR code phishing grew from 7.6 million attacks in January to 18.7 million in March, a 146% rise, while PDF attachments carried 65% of those attacks in January and 70% by March. ESET's telemetry for the first half of the year puts machine-readable codes in roughly 11% of the phishing email it detected, which is a different measure of the same direction of travel.

Most commentary treats this as an email filtering story. The delivery method says otherwise. When seven in ten of these attacks travel inside a document, the question stops being what your mail filter recognises and becomes what your organisation allows a document to contain.

The link that is not a link

A secure email gateway does a specific and well-understood job. It finds the links in a message, expands the shortened ones, rewrites them so clicks can be checked at the moment they happen, and tests each destination against reputation data. On text-borne phishing this works, which is exactly why the technique moved.

Encode the destination as a machine-readable image and the gateway's link extraction has nothing to extract. There is no URL in the message body. There is an attachment, and inside the attachment, an image, and inside the image, a pattern of light and dark squares that becomes a destination only when something with a camera decodes it.

Nothing has evaded a control. The control was asked a question about links and answered it accurately: there are none.

Nothing is wrong with the file

The next layer examines the attachment. Detection engines, whether signature based, heuristic or machine learning, are looking for something wrong with the file: a malformed object, an unexpected stream, a macro, an exploit shaped at a parser, a structure that does not match what the format permits.

A PDF carrying a QR code presents none of that. The image is a legitimate image. The PDF is a legitimate PDF. It would pass a specification conformance check because it conforms to the specification. There is no payload to find, no code to run, and no anomaly to score.

This is worth sitting with, because it is the uncomfortable part. Detection has a ceiling, and the ceiling is usually described as the gap between known and unknown threats. Here the ceiling is lower and stranger. The file is not an unknown threat. It is not a threat at all, in the terms detection uses. It is a document containing a picture, and the attack lives entirely in what a human does with the picture afterwards.

What rebuild does, and what it does not

Deterministic Content Disarm and Reconstruction is the control we argue for most often, so it deserves the same precision as the others rather than a free pass.

Rebuild decomposes a file into its constituent parts, validates each against the manufacturer's published specification, and manufactures a new file from that intermediate representation. Macros, scripts, OLE objects and other active content do not survive the process. Against file-borne code this is decisive, and it does not depend on recognising the threat first.

A QR code is not active content. It is image data, and image data survives a rebuild, correctly: a control that discarded every image would also discard your letterhead, your signatures, your diagrams and your scanned invoices, and would be switched off inside a quarter. Fidelity is not a nice-to-have in a file security control. It is the reason the control is still running in six months.

So three layers pass the document, and each of them is behaving as designed.

The lever that does exist

What changes the outcome is not a better verdict. It is an instruction.

Rebuild engines take policy: an element a policy disallows causes the document to be rejected outright rather than delivered. That turns "may a document arriving from outside this organisation carry a machine-readable code" into a written rule, applied identically to every inbound file, instead of a judgement made under time pressure by whoever happens to open it.

For most organisations the honest answer is that the question has never been put. The rule does not exist, so the default is permissive, and the default was never chosen by anybody.

The number underneath the number

There is a second figure in the same Microsoft report that rewards a slow read.

Over the same quarter, payload-bearing attacks fell from 19% of attacks in January to 13% in February and March. Taken alone, that is a reassuring sentence. Fewer malicious attachments are arriving.

Set it beside the first figure and it says something else. The attachments did not stop arriving; seven in ten of the QR attacks were attachments. What changed is what they carry. An attachment carrying executable code counts as a payload. An attachment carrying an image that encodes a destination does not. The cargo changed, the measurement followed it, and the chart went down.

One metric improved. The exposure moved sideways. Any file security programme reporting on attachment payload volume is currently reporting a real number that answers a question nobody asked.

Where the journey actually ends

The last stage explains why controls at the perimeter cannot finish this.

A person sees the code in a document on a work machine and lifts a personal phone to scan it. The phone is on a mobile network, outside the corporate proxy, outside the endpoint agent, outside the DNS filtering, and very often outside any device management. The credential page renders on a small screen where the address bar is truncated by design.

It is also a device conditioned by ordinary life to treat scanning as routine, for restaurant menus, parking meters, event check-ins and payments. The behaviour the attack depends on is behaviour that the last five years have deliberately taught everybody.

A control at the end of that chain does not exist. The chain leaves your estate two steps before the end.

The APAC reading

Regional obligations are written in terms of malware and malicious content. MAS Technology Risk Management expects malware protection across the estate; the Cybersecurity Code of Practice for CII operators expects layered controls on content crossing the boundary; the Essential Eight is organised around application control, macro configuration and the hardening of software that handles untrusted content from the internet.

None of those instruments is a poor fit, and none of them is obviously engaged by a document containing a legitimate image. That is the gap worth naming. An assessor asking how inbound documents are controlled will accept an answer about macro stripping and malware scanning, and both answers are true, and neither touches this delivery method.

The organisations that will answer well are the ones that can show the policy line: what elements an inbound document may contain, who set that, and what happens to a file that breaches it.

The question worth asking

If the file handling policy has your name on it, the question this week is not whether your gateway catches QR phishing. It mostly cannot, and neither can anybody else's.

The question is whether anyone in your organisation has ever decided what an inbound document is allowed to contain, whether that decision is written down, and whether the controls that read every one of those documents have been told about it.

An unasked question still has an answer. It is just not one anybody chose.

For the MAS and CSA expectations in their published context, see our Singapore compliance page; for the Essential Eight and ISM, the Australia compliance page.