QR phishing, or quishing: how to spot an unsafe QR code

The important question is what the code asks you to do

Quishing is phishing delivered through a QR code. The pattern can move a person from a sign, parcel, email or screen to a deceptive page or request. The danger is not that every unfamiliar pattern is malicious. It is that a routine-looking shortcut can make an unexpected password, payment or installation request feel like part of an ordinary task. Slow down at that request, even if the camera recognized the code immediately.

Consider an illustrative restaurant example: a card promises a menu, but the destination asks for banking credentials before showing any food. That mismatch deserves an independent check, not another attempt to make the scan work. Legitimate businesses may use external service providers, so a different domain is a reason to verify context rather than automatic proof of fraud. The menu setup guide shows what responsible publishers can do to reduce those surprises.

Look at the situation before looking at the screen

Did you expect this code, and do you know who placed it? A code on a public sticker can be replaced or covered. An unexpected message can supply a plausible story about a delivery, account problem or urgent payment. Pressure to act immediately is a reason to step back and verify the request through another route. A printed logo, a familiar color scheme or a professional-looking email is not enough to establish the sender's identity.

For a physical sign, look for added layers or a label that differs from the surrounding material. Ask the operator if the code is theirs when practical, and avoid handling equipment you do not own. For an email or message, do not use contact details supplied only inside the suspicious request to authenticate that same request. Open an already trusted app, bookmark or independently obtained contact channel instead.

Read the address, but understand the limit of a preview

If your device offers a URL preview, inspect it before proceeding. Look at the actual hostname, not only a familiar word in a path or the page title. In a fictional address such as venue.example.attacker.example, seeing venue near the start does not make it the venue.example website. Treat confusing spellings, unexplained names and requests to ignore security warnings as reasons to verify independently. Do not turn a simplified example into a universal rule for parsing every country's domain structure.

A QR preview may show a redirect address rather than the final website. That is normal for dynamic services, but the intermediary name cannot approve everything that follows. The dynamic QR guide explains that route. Check the final page before entering information. HTTPS protects a connection; it does not establish that a page is honest about the organization it represents. Familiar artwork and a plausible address should be considered alongside the actual request.

Recognize three requests worth stopping for

First, an unrelated password prompt. If a QR supposedly shows a public notice but asks you to sign into an important account, leave the page and use that account's normal trusted entry point. Second, an unexpected payment or request for financial information. Verify the amount, purpose and receiving organization independently before proceeding. Do not let a queue, a countdown or an intimidating message replace that check.

Third, a request to install software, grant unusual permissions or move the conversation to an unverified support agent. A publisher should be able to explain why its task requires those steps. Do not install a supposed QR helper merely because the destination tells you to. Where a genuine service has a particular app requirement, obtain and verify that information through its established channels rather than accepting a new requirement from an unknown page.

You have scanned it: choose the next step by what happened

Recognizing a code, opening a page, submitting credentials and installing software are different events. Do not assume information has definitely been stolen just because a camera displayed a link, but do not assume an opened page is harmless either. Stop interacting with a suspicious destination. Record the public context or a safe screenshot if appropriate, without including passwords, financial details or private management links in a report.

If you entered an account password, use the organization's independently verified recovery or security process and consider other accounts where that password was reused. If financial information or a payment was involved, contact the institution through a trusted channel promptly. If software was installed or this is a work device, use the relevant device-support or security team's instructions. The appropriate sequence depends on what actually happened; this article cannot diagnose a device or promise an outcome.

Report the public code without sharing another secret

For a QRSwivo code, the public identifier and a clear description of the concern help the operator locate the record. An abuse report is queued for review and does not automatically disable the code. If the suspicious material is a replacement sticker pointing somewhere else, tell the physical venue as well: blocking your legitimate QR record will not remove a different sign. Do not keep visiting a suspected page to investigate it for the report.

Publishers have another responsibility: protecting the credential that can change the destination. A guest editing link is not the same as the public link and must not be printed or shared with general visitors. The publisher security guide covers inventories, handovers and response planning. A dynamic code's destination can change later, so a previous safe visit is not a permanent guarantee about the next one.

A pause you can explain to someone else

You do not need to prove that a code is malicious before choosing a different route. I expected a menu, but this page wants an unrelated login is a sufficient reason to stop and ask. If you publish codes, make that judgment easier: state the task clearly, keep the destination consistent with it, and offer a readable alternative or a real contact method. The generator makes a connection; your publishing choices must explain why someone should use it.

• Was the request expected, and can its publisher be verified independently?
• Does the address and final task fit the sign or message?
• Is it asking for passwords, payment, installation or more information than expected?
• Can you use a trusted app, bookmark, known address or staff member instead?
• If you already supplied information, have you contacted the appropriate verified support channel?

References & further reading

• FTC: scammers hiding harmful links in QR codes
• NCSC: QR codes and phishing risks
• FTC: recognizing and responding to phishing