How I landed on NRK's Hall of fame!

Back in March was when I decided I would start doing some Bug Bounty Hunting. I was recommended by my friend, Oliver to take a look there to get starting.

During which I had just finished an Ethical Hacking course, but little did I realize how real Penetration testing is different from the university-course. The methodology was very handy to know. But the tools and expectations was very different.

I spent approximately a week looking at NRK's public-facing infrastructure. NRK is Norway's national broadcasting corporation. They run a responsible disclosure program, so I figured I'd poke around and see what turned up.

What turned up was seven vulnerabilities in one of their submission platforms, two of them critical. NRK acknowledged the findings, fixed everything, and added me to their Hall of Fame.

NRK HoF 2026

The target

NRK has an internal submission platform running on a beta subdomain. It's a Next.js application that handles public submissions: news tips, program sign-ups, content contributions across NRK's various departments. Think of it as the front door for anyone who wants to send something to NRK, whether that's a story lead for NRK Nyheter or a sign-up for Debatten.

I started by just browsing the site and watching the network traffic. That's where things got interesting fast.

Unauthenticated access to production storage

The first thing I noticed was an API endpoint at /api/storage. I hit it with a simple GET request, no cookies, no auth headers, nothing.

curl -s https://[redacted].nrk.no/api/storage

It returned a fully valid Azure Shared Access Signature (SAS) URL pointing at NRK's production blob storage container. The token had write permissions and a two-hour expiry. Every time you called the endpoint, you got a fresh one. No rate limiting.

That means anyone on the internet could upload arbitrary files directly to NRK's production storage. Malware, illegal content, multi-gigabyte junk to fill up the quota, whatever you want. And the endpoint was completely open with no session or authentication check at all.

Injecting submissions into the production pipeline

While mapping the API, I found /api/schema accepted unauthenticated POST requests too. This endpoint feeds directly into NRK's Signiant media distribution pipeline.

The schema data I needed to craft a valid submission was sitting right there in the page source. The Next.js application was server-side rendering all 75 schemas (including inactive and internal ones) into the __NEXT_DATA__ block on the front page. That gave me every field name, every destination code, every schema ID I needed.

I built a minimal proof of concept, sent a single clearly-marked test submission to one of the schemas, and it went through. No auth check, no validation that the sender was legitimate. 55 of the 75 active schemas were accessible this way, including ones for NRK Nyheter, regional offices, and program sign-ups.

An attacker could flood NRK's newsrooms with fake tips, impersonate legitimate contributors, or combine this with the storage vulnerability to inject attacker-controlled media files into the editorial workflow. It didnt validate file types either, so I could in theory insert a reverse shell, ransomware or any other malicious files and scripts.

Data leaking from the SSR response

That __NEXT_DATA__ block on the front page was a finding on its own. Beyond the schema configuration data, it was also serving up:

All of this loaded on every unauthenticated page visit. A GDPR issue on top of being an information disclosure goldmine that made the other findings easier to exploit.

IDOR on contract texts

Those MongoDB ObjectIds for contracts from the SSR data? The /api/contract/{id} endpoint returned full contract text for any ID you gave it, again without authentication. I confirmed three unique contracts were accessible, including NRK's general usage rights and privacy policies for specific programs.

The contracts themselves turned out to be general legal text, nothing particularly sensitive. But the endpoint had zero access control, so if NRK ever stored more sensitive agreements in the same system, they'd be exposed too.

The smaller stuff

Three more findings rounded out the report:

Exposed Sentry DSN - The error monitoring DSN was hardcoded in the client-side JavaScript bundle. With it, anyone could send fake error events into NRK's Sentry instance, polluting their logs and making real debugging harder.

Debug page in production - A Sentry onboarding page at /sentry_sample_error was accessible and returning 200 OK. Development tooling that shouldn't be reachable in production.

Wildcard postMessage origin - The iframe embedding script for the submission forms used "*" as the target origin in all postMessage calls. Any page embedding a form could listen in on form events, including field names, values, and submission status. A third-party site could silently capture what users typed into NRK's forms.

The timeline

I reported everything to NRK on March 18, 2026. They were responsive, acknowledged the issues, and worked through the fixes. The whole experience was straightforward and professional.

NRK doesn't run a paid bounty program, but they do maintain a Hall of Fame for researchers who report valid vulnerabilities. Getting listed there felt pretty good, especially given the severity of what I found and considering it was my first time doing a real penetration test.