QR code phishing, or "quishing," has been climbing for a while. The pitch is simple for an attacker: put a QR code in front of a target on a desktop, and they tend to scan it with a phone. The link opens on a device that is often less monitored, outside the corporate browser, and away from endpoint controls. The QR itself also hides the destination until the moment of scan. Defenses adapted on two fronts. Secure Email Gateways (SEGs) started scanning image attachments and embedded images, decoding any QR they found, and following the link to judge it. Email clients hardened too: most now block remote images by default and wait for the user to click "show images." That combination closed a lot of the easy quishing. A code the gateway can decode gets caught, and a code that arrives as a blocked remote image may never even display for the target to scan. So attackers changed the shape of the code. In research reported in mid-2026, Kaspersky described a variant that is getting real traction: build the QR code out of text characters and markup directly in the email body, with no image object at all. There is no attachment to open, no embedded picture to decode, and nothing for an image-based or optical-character-recognition (OCR) scanner to key off. Because it is markup and not a remote image, an inbox with images turned off still paints it. The message shows a perfectly scannable QR to the human reading it, image-blocking and all. The short version: An image-based QR gives a filter something to decode and can be suppressed by an inbox that blocks remote images. A QR assembled from markup does neither. It renders as a normal grid even with images disabled, and there is no image object anywhere in the message for image or OCR scanning to catch. The PhishU Framework now ships this as a second QR mode, so authorized assessments can test whether it lands. Why an Image-Based QR Is Catchable When a QR arrives as an attachment or an embedded image, a modern SEG has a clear job. It extracts the image, runs QR decoding, pulls out the URL, and evaluates it against reputation, redirect chains, and known-bad lists. It can also OCR the picture to spot brand logos or login-form language rendered as an image. None of this is exotic anymore. It is table stakes for a good email filter, and it is the reason plain image quishing does not perform like it used to. The weak point is the assumption underneath it. That whole pipeline starts by finding an image. If there is no image, the pipeline never runs. There is a second, more familiar control that leans on the same assumption. Most email clients block remote images by default and only load them when the user clicks "show images." Security teams often treat that setting as a partial answer to quishing, on the theory that a QR delivered as a remote image simply will not display. Against an image-based QR, that mostly holds. Against a QR drawn from markup, it does nothing, because there is no remote image to block. The grid is part of the message layout and paints immediately. What a Text-Rendered QR Actually Is A QR code is just a grid of black and white squares. Nothing says those squares have to come from a bitmap. You can draw the same grid with block characters in a monospace font, or with a table where every cell is colored black or white. The email client paints the grid from the 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, so the decode-and-evaluate pipeline has nothing to work on. That is the entire trick. It is not clever cryptography. It is a category error in how a lot of email scanning is built. A text-rendered QR shown in a laptop inbox and scanned from a phone. There is no image object anywhere in the message, but the code reads normally. Reproducing It in the PhishU Framework The PhishU Framework already had image-based quishing: a toolbar button in the email template editor drops a QR placeholder, and at send time the platform swaps it for a live QR pointing at the recipient's own tracking link. That is the standard, proven path, and it stays. The new work adds a second button next to it, "Insert QR (Text)." Pick it, and at send time the Framework builds the QR as an HTML table of individually colored cells instead of an image. No <img> tag. No attachment. No embedded bitmap anywhere in the message. Each recipient still gets a unique tracked destination, so click-through, engagement, and reporting all work exactly like every other technique in the platform. The operator picks a mode from a dropdown. The plumbing is handled. The email template editor's QR toolbar dropdown. The new "Insert QR (Text)" option sits next to the existing image-based QR, so the operator picks a render mode and the Framework handles the rest at send time. Being precise about the implementation matters here, because it is a point of technical honesty. PhishU's version...