Introducing QR Jacking: When Your Branded QR Codes Aren’t Yours

I hijacked hundreds of companies' branded QR code domains this summer. Every QR code pointed to a real corporate domain… but every destination was mine.

This isn't the kind of attack where someone slaps a fake QR sticker on a sign. This leverages a company's own branded QR subdomain against them, through a platform-level misconfiguration that lets anyone claim it. I've confirmed the vulnerability on multiple QR SaaS providers, starting with QR Tiger.

I'm calling this vulnerability class QR Jacking.

What This Looks Like in the Real World

You're at a conference. You scan a QR code on a sponsor's booth. The same kind you've scanned a hundred times. Your phone shows the URL: qr.legitimate-company.com. Looks right, so you tap it.

You land on a login page. You enter your credentials. You've just been phished. You had zero reason to suspect it, because the QR code was real, the domain was real, and the company put it there themselves.

I recorded the full attack as a proof of concept: scanning a real company's physical QR code, watching the phone confirm a legitimate corporate domain, tapping through, and landing on my phishing page.

Embedded content

So how does this actually work?

The Root Cause

The root cause is a pattern I've found across the QR code SaaS ecosystem: platforms that let customers use their own branded domains for QR codes, but verify ownership by checking for a DNS record… and nothing else. No secondary challenge. No email confirmation. No proof of control. Just a DNS entry and a green light.

This means anyone can claim someone else's domain on these platforms so long as the subdomain is orphaned.

Responsible disclosures are in progress with additional vendors, and I'll be publishing those findings as each disclosure closes. This post focuses on the first: QR Tiger.

How It Works: QR Tiger as a Case Study

QR Tiger is a popular QR code management platform that advertises Fortune 500 companies among its customers. They offer a feature called "Own Short Domain" that lets businesses use a branded subdomain like qr.yourcompany.com instead of QR Tiger's default short URLs.

Setup is simple: the company creates a DNS record pointing qr.yourcompany.com to QR Tiger's infrastructure, then registers that subdomain in QR Tiger's dashboard. QR Tiger checks that the DNS record exists and activates the domain.

That's the entire verification. Anyone with a QR Tiger account can claim any unclaimed domain that points to QR Tiger's infrastructure, including abandoned subdomains belonging to Fortune 500 companies.

Proof of Concept

Here's the full takeover, step by step:

Embedded content

1. Find the target. A DNS lookup on qr.<target>.com reveals a CNAME pointing to QR Tiger's infrastructure (qr1.be).

$ dig qr.target.com +short
qr1.be.                   # CNAME → QR Tiger
159.89.52.226             # A-record (QR Tiger's server)

$ dig qr.target.com +short
qr1.be.                   # CNAME → QR Tiger
159.89.52.226             # A-record (QR Tiger's server)

2. Confirm it's unclaimed. Navigate to the subdomain in a browser. If it returns "Forbidden" — no one has claimed it on QR Tiger's platform yet. It's takeover-ready.

3. Claim it. In QR Tiger's dashboard: Settings → Own Short Domain. Enter the subdomain. Click save. No ownership verification. No confirmation sent to the domain owner. Done.

4. Set the trap. Generate a Dynamic QR code and point it at an attacker-controlled URL — in my case, https://castlingsecurity.com/poc (my security research domain).

5. Hijack complete. Navigate to qr.<target>.com. The company's branded subdomain now redirects to the attacker's page.

The entire takeover takes under a minute. No exploitation of the target's infrastructure. No access to their DNS. No interaction with the company at all. Just a QR Tiger account. 🐯

Why This Hits Different

Subdomain takeover is a well-known vulnerability class. Dangling DNS records pointing to deprovisioned cloud services — S3 buckets, Heroku apps, Azure instances — have been documented for years. QR Jacking is different because it adds a physical dimension that fundamentally changes the threat model:

Physical trust. People are trained to be suspicious of links in emails. They are not suspicious of QR codes printed on the products they just bought, posted in the lobby of their office, or printed on the badge they're wearing at a conference.

Domain trust. The URL reads qr.legitimate-company.com. Even users who check URLs before clicking see nothing wrong.

No patch available. Physical QR codes on shipped packaging, printed signage, and distributed materials can't be recalled with a software update. They're in the wild indefinitely.

Zero visibility. The attacker controls the destination through the QR platform's dashboard. The company has no logs, no alerts, no indication that their branded domain is now serving attacker content.

Scale

I built a scanning tool called QR Tiger King (source releasing shortly on GitHub) that checks for this pattern across public top-domain lists — the Tranco Top 1M, Forbes Global 2000, Fortune 500, Inc. 5000.

The results: Hundreds of companies with vulnerable subdomains across manufacturing, healthcare, financial services, and tech. Not obscure brands. Names you use and would recognize immediately.

I prioritized disclosure to companies in healthcare and financial services first. A vulnerable hospital domain is a different conversation than one on a SaaS company.

Why Traditional Scanners Miss This

Classic subdomain takeover tools like subjack and nuclei look for HTTP response fingerprints — S3's "NoSuchBucket," Heroku's "No such app." QR Tiger and other QR providers are architected differently. A dangling subdomain returns a generic "Forbidden" page that looks like any other 403.

The signal is in DNS, not HTTP. That's why QR Tiger King uses a combination of dig queries with web probes.

The Fix

For QR Tiger (and other QR SaaS platforms): Implement domain ownership verification. DNS TXT challenge, email verification, file-based proof — pick one. Every major SaaS platform that supports custom domains does this. A CNAME alone is not proof of ownership.

For companies: Audit your DNS. Look for qr.* subdomains with records pointing to third-party QR platforms. If the record exists and nobody on your team owns that integration, remove it today.

QR Tiger Disclosure Timeline

Five months later, QR Tiger has not remediated the vulnerability.

What's Next

This is Part 1. QR Tiger isn't the only platform affected — responsible disclosures with additional vendors are in progress. Future posts will cover those platforms as each disclosure closes, along with a broader look at verification patterns across the QR SaaS ecosystem.

I'll also be releasing the full QR Tiger King source code in the coming weeks so security teams can scan their own infrastructure.

If you're a QR platform vendor reading this: check your custom-domain flow. If it's CNAME-only, you have the same problem.

Follow me on LinkedIn to catch the next one.