A real case study in hyperlink injection and SSTI & two vulnerabilities hiding in plain sight

I almost didn’t report them.

I was so convinced both bugs were duplicates that I sat on the findings for a few hours before finally writing the PoC. That hesitation would have cost me a Hall of Fame entry and a BBC swag T-shirt.

The lesson hit harder than the bugs themselves.

The Setup: Chasing a Name on a Wall

I’d been passively eyeing the BBC’s vulnerability disclosure program for a while. Not because of the money — it’s a VDP, there’s no monetary reward — but because of the Hall of Fame.

Getting your name on a company’s security acknowledgment page means something in this field. It’s credibility you can’t fake. So one afternoon I opened my terminal, pointed subfinder at a BBC domain, and started the recon that led to two findings I still think about.

Out of the list that came back, two subdomains looked interesting enough to investigate. I’ll refer to them as xyz.bbc.com and abc.bbc.com I won't disclose the exact URLs as a courtesy to the BBC security team.

What happened next is what I want to walk you through.

Bug #1: Hyperlink Injection in a Contact Form

The first target had a Contact Us page. Standard stuff — organisation name, country, contact name, email, phone, enquiry type, message.

I started where I always start: the basics. I sprayed some XSS payloads across every input field. Nothing fired. The application handled them cleanly.

So I stepped back and thought about what else these fields could do.

Hyperlink injection is boring. That’s exactly why it works.

Most hunters skip it. It doesn’t look like a “real” vulnerability. It doesn’t pop an alert box or dump a database. But what it does do is allow an attacker to inject arbitrary URLs into emails that the application sends on behalf of a trusted brand — in this case, the BBC.

I replaced the input values across multiple fields with http://evil.com and submitted the form.

A few seconds later, a confirmation email arrived.

Every injected URL had rendered as a live, clickable hyperlink in the email body — sent from an official BBC domain. The email confirmed: Organisation name, contact name, phone number, and message — all containing my URL, all hyperlinked.

Think about what that means in practice. A phishing campaign delivered from a trusted BBC sender address, carrying attacker-controlled links, to anyone who submits that form. No technical sophistication required to weaponize it.

I documented the full reproduction steps, attached the screenshots, and moved to the second subdomain.

Bug #2: Server-Side Template Injection via Registration Email

The second subdomain had a registration flow. You sign up, provide a name and email, and receive a welcome email.

That welcome email was the attack surface.

SSTI — Server-Side Template Injection — is one of those vulnerabilities that looks impossible until it isn’t.

The idea is simple: if the application takes user-supplied input and renders it inside a template engine without sanitisation, math expressions like {{7*7}} get evaluated, not printed. Instead of seeing {{7*7}} in the output, you see 49.

I created a new account. For the first name I entered {{50*100}}. For the last name I entered {{7*7}}.

Then I waited for the verification email.

The subject line read: Welcome, 5000

The template engine had evaluated {{50*100}} as 5000 and rendered it directly into the email. The application was passing unsanitised user input into a live template context.

That’s not just an injection bug — that’s a direct path to Remote Code Execution in many template engines, depending on the sandbox configuration and the engine in use. I kept the PoC clean and within the scope of confirming vulnerability, then wrote up the report.

What Happened After the Reports

Both findings went to BBC’s Vulnerability Disclosure Programme.

Within a few days, I received confirmation from their security team. Both vulnerabilities were valid. Neither was a duplicate — the thing I’d been most worried about.

Shortly after, I got an email telling me I’d been added to the BBC VDP Hall of Fame.

Then the T-shirt arrived.

I’m not going to pretend a T-shirt is the point. But it represented something: a globally recognised media organisation looked at a PoC I wrote and said, “This was legitimate. This mattered.”

That’s the actual reward.

The Reframe: The Bugs You Skip Are the Ones That Get You In

Here’s the thing I didn’t expect.

I went into that session expecting to find something complex — a chained SSRF, a broken auth flow, a misconfigured API endpoint. The kind of finding that reads well in a writeup and impresses other hunters.

Instead, I found two textbook bugs that most intermediate hunters would have dismissed in the first five minutes.

Hyperlink injection is not glamorous. SSTI via a registration email is not novel. But they were there, unpatched, on subdomains of one of the most-visited media properties on the internet.

The hunters chasing complex chains missed them. I almost missed them too.

The bug bounty meta is obsessed with difficulty. But programme triage teams don’t care how hard your bug was to find. They care whether it represents a real risk to real users.

Boring vulnerabilities get fixed. Boring vulnerabilities get you on walls.

What You Can Take From This

If you’re hunting right now, here are three things worth applying immediately:

Don’t skip the contact forms. Every input field that feeds an email is a hyperlink injection surface. Test every one.

Registration flows are template surfaces. Any email that uses your name is rendering it somewhere. Inject {{7*7}} into your first name. If the email comes back with 49 in it, you have SSTI.

Report what you find, not what you’re proud of. I almost sat on these because they felt too simple. That instinct will cost you findings. Submit the boring PoC. Let the triage team decide severity.

The Hall of Fame doesn’t ask how long it took you.

If this was useful, follow — I post writeups on real-world findings, recon methodology, and what actually works in bug bounty programmes.

What’s the simplest bug you’ve ever found that turned out to be valid? Drop it in the comments — I read every one.