Text-Only QR Codes: How They Bypass Email Security

Text-rendered QR codes bypass email security tools that rely on image scanning or remote image blocking. The reason is structural: a QR code built from HTML markup has no image object for a filter to find.

Kaspersky documented this attack variant in mid-2026 as an active threat. Security teams that assume an email with no images is safe from quishing are working from an incomplete threat model.

Why image-based QR scanning catches the old attacks

A standard quishing attack puts a QR code image in the email. The detection pipeline looks like this:

1. The secure email gateway extracts the image from the attachment or embedded content
2. A QR decoder reads the pixel grid and pulls out the URL
3. The gateway evaluates that URL against reputation lists, redirect chains, and known-bad domains
4. The message is blocked or let through based on what the gateway finds

This works. Image-based QR scanning is table stakes for any decent email filter now, and it is why plain image quishing does not perform like it used to.

The problem is that the whole pipeline depends on finding an image object. If there is no image, the pipeline never runs.

Image blocking is not a quishing fix

Most email clients block remote images by default. Security teams often treat this as a partial answer to quishing: if the QR image never loads, the user cannot scan it.

That logic holds for image-based QR codes. It does not hold for markup-based QR codes.

A QR built from HTML table cells or Unicode block characters renders as a visible grid regardless of image blocking settings. The email client paints it from markup, the same way it paints bold text or a table. There is no remote image to block.

A user with images turned off sees a perfectly readable QR code in a desktop email client and scans it with their phone. The phone camera sees a valid QR. The link opens. The attack lands.

What text-rendered QR codes actually are

A QR code is a grid of black and white squares. Nothing in the QR spec says those squares have to come from a bitmap file.

You can draw the same grid with half-block characters in a monospace font. You can build it with an HTML table where each cell is explicitly colored black or white. The email client renders the grid from markup. The recipient's phone camera sees a valid QR and scans it normally.

To the mail filter, the message is text and layout instructions. There is no picture to extract, no QR decoder pipeline to run, and nothing for OCR to key off. The category error is the whole trick. It is not clever cryptography. It is a detection gap built into how a lot of email scanning is architected.

The engineering problem is harder than it looks

Building a markup QR that actually renders and scans in real email clients is the harder part. Three reproducible bugs showed up when testing this against production inboxes.

Bug one: font-glyph stretching on Gmail mobile.
Drawing the QR with Unicode block characters in a monospace font works on Outlook desktop and Gmail web. It fails on Gmail mobile, which applies its own font boosting and auto-scaling. The grid renders non-square and unreadable. This is why font-glyph QR art is fragile in production, even though it is a direct copy of the in-the-wild technique.

Bug two: Gmail silently clips messages over 102KB.
The fix is an HTML table with one cell per module. A typical QR is over a thousand modules, which produces roughly 230KB of markup with per-cell style attributes. Gmail silently truncates messages over about 102KB. The table arrives garbled and the QR does not render. This is not a CSS issue. The grid matrix itself is structurally correct. The problem is payload size.

Bug three: Outlook dark mode repaints white cells grey.
Even with explicit color attributes on every white cell, Outlook's automatic dark mode recoloring overrides them. The fix is a dark-mode-specific color override targeting the attributes Outlook stamps at render time. Confirmed working on Outlook desktop.

The version that shipped uses an HTML table with colspan-based run-length compression, merging consecutive same-color cells in each row to cut the payload from roughly 230KB down to 50-65KB. That passes Gmail's clip threshold and renders correctly in Gmail, Outlook, and most mobile clients.

What defenders should do

Do not treat "no image" as "no QR."
Detection that renders the full message to a headless browser and screenshots the visual output catches a QR code no matter how it was drawn. Detection that only extracts and decodes image objects does not. If your SEG does not support visual rendering-based QR detection, that is a gap worth documenting and requesting from your vendor.

Blocking remote images is not a quishing fix.
It suppresses image-based codes, which is worth having. It does nothing against markup-rendered codes. Your security awareness training should reflect this gap. Users who know to not scan QR codes from images will still scan ones they see rendered in the email body.

Evaluate the final destination URL, not just QR content.
URL scanning at the gateway should evaluate the actual destination after all redirects, not just the QR-encoded string. Attackers increasingly use redirect chains through legitimate URL shorteners. A gateway that checks only the QR payload misses chains that resolve to malicious domains after the first hop.

Map your threat model to your actual controls.
If your SEG only does image extraction and QR decoding, your team should know that markup-rendered QR codes are not in scope for that control. Threat modeling that assumes image scanning covers all QR codes is missing a real attack path.

Reduce your domain's spoofability.
Most QR phishing campaigns impersonate known brands. Even if your gateway misses a markup-rendered QR, a strict DMARC policy makes it harder for attackers to impersonate your brand in the first place. DMARCFlow aggregate reports help your team spot authentication anomalies that may indicate an attacker is probing your domain's DMARC configuration before running a larger campaign. Catching that probe early matters.

FAQ

Can secure email gateways detect text-rendered QR codes?
Some can, if they support visual rendering-based detection that screenshots the message. Most SEG pipelines that only extract and decode image objects do not catch markup-based QR codes. Check with your vendor whether your current SEG has visual rendering-based scanning.

Do QR scanning apps detect malicious URLs after the scan?
Some do. Many QR scanner apps are just camera apps with a decode feature and do not evaluate the destination URL at all. The security posture of the scan depends entirely on the app, not on the email gateway.

Does email image blocking stop text-rendered QR codes?
No. Image blocking suppresses image-based QR codes because the image never loads. A markup-rendered QR shows up regardless of image blocking settings.

Is this technique new?
The specific text-rendered approach was documented by Kaspersky in mid-2026 as an in-the-wild attack variant. The underlying concept of building a QR from non-image primitives has been discussed in security research communities for years.

Does DMARC prevent QR phishing attacks?
DMARC prevents attackers from spoofing your domain in email headers. Most QR phishing campaigns impersonate known brands, so DMARC enforcement reduces brand-impersonation phishing volume. It does not prevent attackers from using their own domains in QR phishing campaigns.