Quishing is phishing that hides its payload inside a QR code instead of a clickable link. That single design choice is why it slips past most email security: your gateway scans text and URLs, but a QR code is an image, so there is nothing for the link scanner to read until a phone camera decodes it.
The attack works because of where the scan happens. The malicious email lands on a managed work laptop, but the user reaches for a personal phone to scan the code. The moment they do, the session leaves the corporate perimeter and runs over mobile data or home Wi-Fi, out of reach of the firewall and endpoint controls you have spent years configuring. This guide explains how quishing evades email security, why the off-network scan is the real problem, and what actually stops it.
What is quishing?
Quishing, also called QR code phishing, is a phishing technique that embeds a malicious link inside a QR code rather than a visible URL. The victim scans the code with a phone camera, which opens a fraudulent page that harvests credentials or session tokens. Because the payload is an image, it bypasses email filters built to inspect text and hyperlinks.
The victim journey follows a predictable sequence:
- An email arrives with a QR code, often inside a PDF attachment, framed as an MFA reset, a voicemail, or an HR document.
- The user scans the code with a personal phone, because a QR code cannot be clicked on a desktop screen.
- The phone connects over mobile data or home Wi-Fi, outside every perimeter control the organisation runs.
- The scanned link opens a fake login page that captures the password and, increasingly, the live session cookie after the user passes MFA.
Why email security misses QR code payloads
Traditional email security reads text. A secure email gateway checks the sender reputation, validates SPF, DKIM and DMARC, and extracts URLs from the HTML body to test them against reputation databases or detonate them in a sandbox. A QR code defeats all of that, because at the moment the message passes the gateway, the malicious link does not exist as text. It exists as a pattern of pixels that only becomes a URL once a camera decodes it.
Vendors responded by adding optical character recognition and image parsing, so filters can render an image, find a QR code, and decode the URL inside. It helps, but attackers adapted faster than the detection matured. According to Microsoft Threat Intelligence, QR code phishing rose 146% across the first quarter of 2026, climbing from roughly 7.6 million blocked threats in January to 18.7 million in March. Microsoft also reported that PDF attachments grew from around 65% to 70% of quishing volume over the same period, with inline email QR codes spiking 336% in a single month.
Three evasion techniques explain why image scanning is not a complete answer. Attackers build QR codes out of HTML table cells and text characters, so there is no image file for an OCR engine to find. They split a single code into separate image fragments that look harmless in isolation and only assemble on the user’s screen through CSS. And they nest a malicious code inside or around a legitimate one, creating decoding ambiguity that makes an automated scanner extract the safe URL while the phone camera reads the malicious one. Each technique exploits the same gap: the email gateway and the phone camera do not see the same thing.
The mobile and off-network problem
Here is the part most defences quietly assume away. They are built for a click that happens on a managed device, inside the network. Quishing breaks that assumption by design, because the scan moves the whole transaction onto a phone that your controls never touch.
When an employee scans a code on their PC screen with a personal phone, the phone makes its DNS lookups and HTTPS connections over 4G, 5G or residential Wi-Fi. None of that traffic passes the on-premise firewall, the internal DNS filter or the local proxy. The perimeter is simply not in the path. Many of these phones are unmanaged personal devices with no mobile device management and no endpoint agent, so there is nothing on the device to inspect the session either.
Endpoint protection fails here even when the phone is managed, because no malicious file is downloaded or executed. The attack is entirely browser-based. It runs through an adversary-in-the-middle reverse proxy that sits between the victim and the real service, often Microsoft 365, relays the login in real time, and steals the session cookie after the user approves MFA. With that cookie, the attacker replays the authenticated session from their own machine. The password held. The MFA prompt was approved. The account is still compromised. This is the same proxy-based technique covered in our guide to how AiTM phishing bypasses MFA, applied through a QR code instead of a link.
Because endpoint and perimeter controls have no grip on this transaction, the defence has to move to the layers the phone still has to traverse: DNS resolution and the web request itself.
What actually stops quishing
No single control stops the scan itself, so a workable defence splits into two jobs: prevention that reduces the chance the code is ever scanned, and containment that blocks the malicious destination after a scan happens. The honest position is that prevention always leaks, so containment is what saves you on the day someone scans.
Prevention works on the email and the user. Advanced mail filtering with OCR and visual reconstruction can render attachments, reassemble split images, and decode ASCII-built codes before delivery, then detonate the decoded URL in a sandbox. Phishing-resistant MFA based on FIDO2 or passkeys is the strongest identity-level control, because the credential is cryptographically bound to the real domain and a proxy on a lookalike domain cannot use it. Awareness training closes part of the gap by teaching people to preview a URL before opening it and to distrust unsolicited QR codes in HR or IT requests. None of these is complete on its own.
Containment works on the connection the phone makes. When the browser tries to resolve the malicious domain, DNS filtering can refuse to return an address for newly registered or uncategorised domains, which is exactly the profile of the disposable domains quishing campaigns rely on. If the lookup resolves, a secure web gateway can inspect the outbound request, apply domain reputation and certificate checks, and block known reverse-proxy frameworks before the login page ever loads. And if an attacker still manages to steal a token, conditional access tied to device posture keeps that cookie worthless from an unmanaged machine.
| Defence layer | What it catches | Stage |
|---|---|---|
| Mail filtering with OCR and sandboxing | QR codes in images and PDFs, decoded malicious URLs | Prevention |
| Phishing-resistant MFA (FIDO2, passkeys) | Credential and token theft on lookalike domains | Prevention |
| Awareness training | User behaviour before the scan | Prevention |
| DNS filtering | Resolution of new or uncategorised malicious domains | Containment |
| Secure web gateway inspection | Malicious destinations and reverse-proxy pages | Containment |
| Conditional access and device posture | Replay of stolen tokens from unmanaged devices | Containment |
This is where the off-network problem turns from a weakness into a design requirement. A web-layer and DNS-layer net catches the malicious destination even when the user scans on a phone you do not control, provided that phone’s traffic is routed through the platform. Jimber delivers both as part of a single cloud-managed platform. Its secure web gateway inspects outbound web traffic and blocks malicious and uncategorised destinations, while its DNS filtering for mid-market teams refuses resolution for the disposable domains these campaigns spin up. Routed through a mobile client, those same controls extend to the phone, which is the one place the scan can be caught. None of this stops the user pointing a camera at a code, but it stops the page from loading once they do.
What European compliance frameworks expect
Quishing sits squarely inside the obligations European mid-market organisations already carry. The point is less about a named rule and more about the evidence an auditor wants to see that you control phishing as an entry vector.
Phishing is the dominant way attackers get in. ENISA’s 2025 Threat Landscape attributes around 60% of successful network intrusions in the EU to phishing and social engineering, and notes that more than 80% of phishing campaigns now use AI assistance. Under the NIS2 directive, essential and important entities must take proportionate risk-management measures under Article 21, and ignoring a vector responsible for most breaches is hard to defend. In Belgium, the CCB’s CyberFundamentals framework operationalises this, and the CCB has reported that its Basic level blocks 82% of real attacks, Important 94%, and Essential 100%. Strong access control and multi-factor authentication are named controls within those levels, which maps directly onto the quishing defences above.
Frequently asked questions
What is the difference between quishing, smishing and vishing?
The difference is the channel. Quishing hides a malicious link inside a QR code, usually in an email or on a physical sticker. Smishing uses text or messaging app links. Vishing uses a phone call where the attacker impersonates a bank or IT support to extract credentials.
Can a phone be hacked just by scanning a QR code?
No, not on a modern, patched phone. Scanning only decodes the link and shows a preview. The compromise happens after the user opens the page and acts on it, by entering a password, approving an MFA prompt, or authorising a malicious app. The scan alone does not install anything.
Why do spam filters not block QR codes in emails?
Email gateways inspect text and HTML links. A QR code carries its link as an image or inside a PDF, so without optical character recognition the filter sees only a harmless graphic. Attackers also build codes from HTML and text characters, which leaves no image for a scanner to find.
Does MFA stop quishing?
Standard MFA does not stop the advanced version. Quishing increasingly leads to an adversary-in-the-middle proxy that relays the login and steals the session cookie after the MFA prompt is approved. Only phishing-resistant MFA such as FIDO2 or passkeys, combined with device-posture checks, reliably breaks that chain.
What should we do if an employee scanned a malicious QR code?
Act on the session first. Revoke the user’s active sessions and tokens to neutralise cookie replay, force a password change, and check the account for any newly registered MFA methods or recovery options the attacker may have added. Inspect the device, and if it qualifies as an incident under NIS2, follow your reporting timeline.
Is quishing only an email problem?
No. Quishing also appears in the physical world, where attackers paste fraudulent QR stickers over legitimate ones on parking meters, EV chargers, payment terminals and restaurant menus. The mechanism is the same: a scan leads to a fake payment or login page that harvests data.
Quishing is hard to prevent and easy to underestimate, precisely because the scan happens where your usual controls cannot reach. The practical answer is to assume some codes will be scanned and make sure the malicious destination cannot load when they are. If you want to see how DNS filtering and secure web gateway inspection close that gap for your mobile and off-network users, book a Jimber demo and we will walk the attack chain against your own environment.
