QR Code Security: How Quishing Works and How Ṣọ Catches It Before You Scan
What Is Quishing and Why Is It Growing So Fast?
Quishing is QR code phishing. An attacker embeds a malicious URL inside a QR code, drops the code into an email, a printed flyer, a parking meter sticker, or an office lobby poster, and waits for the target to scan it with a phone. The QR code routes the user to a credential-harvesting page, a malware download, or a fraudulent payment portal. According to Cisco Talos and multiple vendor threat reports tracked through 2024, quishing attempts roughly doubled year over year as attackers shifted from link-based phishing to image-based phishing. The reason is structural: QR codes bypass nearly every defense built for the last two decades of email security.
This post breaks down the technical anatomy of a quishing attack, why traditional email filters fail to catch it, and the specific architecture Ṣọ uses to scan every QR code in your inbox before you scan it yourself. The architecture matters because how a security tool inspects QR codes determines whether the privacy guarantees of the broader product still hold when the inspection happens.
How Does a Quishing Attack Actually Work?
A quishing attack succeeds because of a specific gap between how email security tools work and how QR codes are designed.
Step 1: The attacker generates a QR code that encodes a malicious URL. QR codes are just compact representations of text. Any URL, however long, can be encoded into a QR code in seconds using free online tools. The malicious URL typically points to a credential-harvesting page that mimics a legitimate brand (Microsoft 365 login, DocuSign, payroll portal, banking site).
Step 2: The QR code gets embedded in an email as an image. The email body might say "Scan to view your invoice," "Scan to verify your account," or "Scan to access the secure document." The QR code itself is a PNG, JPG, or SVG image inside the email. There is no hyperlink in the email body. The destination URL exists only inside the image.
Step 3: Traditional email filters scan the email and find nothing. Standard email security tools were built to scan links and attachments. They look for suspicious URLs in the body, expand shortened links, check attachments against malware signatures, and parse text for phishing patterns. The QR code is none of those things. It is an image, and inside the image is a URL that no link scanner ever sees.
Step 4: The user opens the email on their phone. This is the critical handoff. The user sees the QR code. They reach for their phone, open the camera app, and scan. The phone's camera decodes the QR code and offers to open the URL.
Step 5: The user is now off corporate infrastructure. Once the URL is on the phone screen, the user is operating outside the email security perimeter entirely. The phone's browser opens the malicious page. Credentials get harvested. Malware gets downloaded. The attacker wins.
The handoff from corporate device to personal phone is the entire point of the attack. It is also the reason QR phishing has grown so fast: every additional minute of mobile-first work makes the attack vector more valuable.
Why Do Traditional Email Security Tools Miss QR Phishing?
Three structural reasons explain the failure mode.
Email security tools scan text and links, not images. Most filters use URL inspection (expanding links, checking destinations against threat feeds), text pattern matching (looking for phishing language), and attachment scanning (signature checks against known malware). A QR code is rendered as an image. The URL inside it never appears as text in the email body. The link scanner has nothing to scan.
OCR-based image scanning is rare in email security. Some advanced tools attempt to extract text from images using optical character recognition. QR codes are not text. They are binary patterns that require dedicated decoders to convert into URLs. Most email security pipelines do not include QR decoding because the volume of QR codes in legitimate email was historically too low to justify the compute cost.
The decode step happens after the email reaches the user. Even when an email security tool does include QR decoding, the typical implementation happens at the gateway level, on the vendor's servers, before the email reaches the user. By the time a user opens the email on their phone, any verdict from the gateway has already been applied. The phone scan still happens regardless of the verdict, because the QR code is just an image to the phone camera.
The combination means most email security tools, even modern ones, treat QR codes as inert image content. The user becomes the decoder. The user becomes the security checkpoint. That is exactly the wrong place for a security checkpoint to live.
How Does Ṣọ's QR Scanner Work?
When an email arrives in your inbox, the Ṣọ extension reads the email through your existing mail provider session. The full email content (including any embedded images) is sent to Ṣọ-owned infrastructure over HTTPS/TLS for analysis. On Ṣọ servers, the analysis includes a QR decoding step alongside the standard header, content, link, and attachment checks.
Step 1: Image extraction. Embedded images in the email body are extracted as part of the standard analysis pipeline.
Step 2: QR detection and decoding. Each image is checked for QR code patterns. If a QR code is detected, it gets decoded into the URL or text it encodes. This decode happens server-side, in seconds.
Step 3: URL inspection on the decoded destination. The decoded URL gets the same threat analysis as any link in the email body. Domain intelligence checks against threat feeds. Lookalike domain detection. Newly-registered domain flags. Redirect chain tracing. Known phishing pattern matching.
Step 4: Verdict returned to your device. If the QR code points to a known phishing destination, a credential-harvesting page, or a recently-registered suspicious domain, the email gets flagged. The verdict appears in your inbox UI before you have a chance to scan the code with your phone.
Step 5: The QR data is deleted. The extracted image, the decoded URL, the analysis records, and the email itself are all removed from Ṣọ infrastructure within seconds of the verdict returning. No logs of QR content or decoded URLs are retained on Ṣọ servers.
This is the core architectural commitment that makes the QR scanner worth using: every QR code in your inbox gets inspected, the inspection happens before you scan, and nothing about the inspection is retained on Ṣọ infrastructure once it's done.
What Does the Architecture Actually Guarantee?
This is a Dedicated Post on the Zero Server Retention pillar, so the QR scanner is a useful concrete example to walk through what that pillar actually means.
What goes to Ṣọ servers during QR analysis: The full email, including the QR code image, is sent to Ṣọ infrastructure over HTTPS/TLS. The image gets decoded server-side. The decoded URL gets checked against threat intelligence. All of this happens on Ṣọ servers, not on your device.
What stays on Ṣọ servers after QR analysis: Nothing. The email content, the QR code image, the decoded URL, and the analysis verdict are all removed from Ṣọ infrastructure within seconds of the verdict returning to your device. No logs are written that contain the QR content or the decoded URL.
What's in the verdict: The verdict that comes back to your device contains the threat classification (clean, suspicious, phishing, credential harvest, etc.) and a brief explanation of why. The decoded URL itself is included in the verdict so you can see what the QR code would have routed to. Once the verdict is on your device, your local app stores it as long as you want it. Ṣọ infrastructure does not.
What's never used: Decoded QR codes, the URLs they contain, and the email contexts they appeared in are not used to train Ṣọ's detection models. We do not aggregate QR threat data across customers in a way that links specific QR codes to specific customer inboxes. Threat patterns inform our public threat intelligence feeds in aggregated, anonymized form only when they are part of large-scale campaigns observed across the wider internet, not from individual customer inboxes.
This is what Zero Server Retention actually means in practice. The data exists on our infrastructure for the seconds of analysis. It does not exist there afterward.
How Can You Verify This Yourself?
Two parts of the architecture are verifiable directly from your device.
The transit is verifiable. Open your browser's developer tools and watch the network tab while Ṣọ is running. You will see HTTPS calls going to Ṣọ servers when an email arrives. You will see the email content (including QR code images) being transmitted. You will see the verdict come back. The transit is observable.
The retention claim relies on architectural enforcement. The deletion-after-processing commitment, the no-logs commitment, and the no-training commitment are not directly verifiable from your browser. They depend on the absence of certain code and tools on the server side. A third-party security audit is on our roadmap and will document those commitments externally.
This is the same trust model that governs Apple's Private Cloud Compute, Anthropic's Zero Data Retention API tier, and Signal's contact discovery. Server-side processing with verifiable transit and architecturally enforced retention guarantees. It is a real privacy guarantee, just one that requires audit-level verification for full confirmation.
What QR Threat Patterns Should You Know About?
Five quishing patterns account for most successful attacks based on threat reporting through 2024.
The Microsoft 365 verification page. Email subject suggests an account verification or security alert. QR code routes to a Microsoft-branded login page on a lookalike domain (login-microsoft365.com instead of login.microsoftonline.com). Credential harvest happens on the spoofed page.
The DocuSign or Adobe Sign document. Email claims a document is waiting for signature. QR code routes to a credential-harvest page mimicking the document signing service. The "signature" page asks for the user's email login.
The parking meter or invoice sticker. Physical QR code placed on a parking meter, invoice, or restaurant table tent. The code routes to a fraudulent payment processor. The user enters card details thinking they are paying a legitimate invoice.
The office lobby visitor signup. QR code printed and posted in a corporate lobby, claiming to be a visitor check-in. The code harvests credentials or installs an MDM profile that gives the attacker persistent access to the device.
The shipping notification. Email claims a package delivery requires action. QR code routes to a fraudulent shipping portal that harvests credit card details under the framing of a "redelivery fee."
Each pattern shares the same operational structure: image-based delivery, off-perimeter scanning, URL on a phone screen, credential or payment harvest. The defense in every case is detection at the email level before the user reaches for their phone.
Why Mobile-First Work Makes This Worse
Quishing is growing because of a structural shift in how people work, not because of clever technical innovation.
More email is read on phones. According to multiple email client analytics reports, mobile email reading now accounts for over 60 percent of total email opens for most consumer-facing organizations. Business email is closer to 50/50 mobile/desktop, but trending mobile.
The handoff is invisible. A user reading email on a desktop sees a QR code and might pause before reaching for their phone. A user reading email on a phone is already on the device that scans the QR code. The handoff is one tap away.
Phone cameras are designed for instant action. Most modern phone cameras detect QR codes automatically and offer to open the URL with a single tap. The friction between "I see a QR code" and "I am on a malicious website" is sometimes less than two seconds.
The combination means quishing benefits from every workflow shift toward mobile-first work. The trend is unlikely to reverse, which means the defense has to live at the email level, before the user makes the tap.
What Should Small Organizations Do Beyond QR Scanning?
The Ṣọ QR scanner catches threats at the email layer. Three additional defenses operate at the human and device layer and are worth implementing alongside.
Train the team to never scan unverified QR codes. This is a behavioral rule, not a technical one. Treat any QR code received via email, especially one requesting login or payment, as suspicious by default. Require out-of-band verification before scanning, the same way the BEC verification protocol requires verification before wire transfers.
Disable automatic QR code opening on phones where possible. Most phone cameras can be configured to require a manual tap to open URLs from QR codes. The default is auto-open. Switching to manual tap adds a verification step the user can use to inspect the URL before opening.
For high-risk roles, route email to a desktop-first review for QR-containing messages. Finance teams, executives, and anyone handling sensitive credentials should treat QR codes in email as desktop-first. Open the email on a laptop. Inspect the QR code visually. Use the Ṣọ verdict. Only scan with the phone if all three layers clear.
These are not substitutes for technical detection. They are additional layers that operate at the moment of human decision, where most actual phishing decisions get made.
Frequently Asked Questions About Ṣọ's QR Scanner
Does Ṣọ scan QR codes in attachments as well as in the email body?
Yes. The image extraction step covers both inline images in the email body and image attachments. PDF attachments containing QR codes are also extracted and scanned.
What happens if the QR code points to a legitimate URL I do want to visit?
The verdict tells you what the QR code routes to. If the destination is legitimate (a known calendar invite, a known event ticketing service, a known internal portal), the verdict will mark it clean and you can scan with confidence.
Does Ṣọ block me from scanning a malicious QR code?
No. Ṣọ marks the email as containing a malicious QR code. The phone scan itself happens outside Ṣọ's perimeter, on your phone's camera. The defense is informational: by the time you reach for your phone, you already know the QR code routes somewhere malicious. The decision not to scan is yours.
Does the QR scanner work on attachments larger than email scanning normally allows?
Standard email size limits apply. PDFs and image attachments within typical email size limits are scanned. Very large attachments may require a manual scan via the Ṣọ desktop app.
Can I see what the QR code decoded to?
Yes. The verdict includes the decoded URL so you can verify it visually before scanning with your phone. This is an honest audit trail: even if the QR scanner says "clean," you can see exactly what URL was checked.
What about printed QR codes I encounter offline?
The Ṣọ scanner only handles QR codes that appear in your email or in supported channels. Printed QR codes you encounter in physical spaces (parking meters, restaurant menus, lobby signs) are not in our perimeter. The behavioral rule applies: treat unfamiliar physical QR codes with the same caution as unfamiliar email QR codes.
Executive Summary: TL;DR
Quishing is QR code phishing. Attackers embed malicious URLs in QR code images inside emails, exploiting the gap between traditional email filters (which scan text and links) and how QR codes work (the URL is inside an image). When a user scans the code with their phone, they hand off from corporate infrastructure to a personal device, and the attacker wins.
Ṣọ's QR scanner closes the gap. Embedded QR codes get extracted and decoded server-side as part of the standard email analysis pipeline. The decoded URL gets checked against threat intelligence the same way any link would. A verdict returns to the user's device with the threat classification and the decoded URL. The QR data, the email, and the analysis records are all removed from Ṣọ infrastructure within seconds.
This is the Zero Server Retention pillar in practice. Email content, including QR codes, exists on Ṣọ servers for the duration of analysis (seconds), and then it is gone. No logs. No retention. No training on QR data.
If your organization handles email on mobile devices and any of your team members are likely to scan a QR code without thinking, QR phishing protection at the email layer is the highest-leverage defense available. The Ṣọ scanner is one option. Behavioral rules around QR scanning, combined with desktop-first review for high-risk roles, are the additional layers that make the technical defense durable.
Sources: Cisco Talos QR Phishing Trend Reports 2024; Verizon 2024 Data Breach Investigations Report; FBI Internet Crime Complaint Center 2024 Annual Report; Proofpoint Q1 2026 Threat Landscape Review; Apple Private Cloud Compute technical documentation.
iOS: apps.apple.com/us/app/so-mail/id6756896070 Android: play.google.com/store/apps/details?id=com.app.somail
Encrypted in transit. Processed in seconds. Deleted immediately.