Accidental RCE: How I Found a Working Exploit in a Live CTF (and It Wasn’t Even the Challenge)

On 19/6/2026, riffhack.biterra.co hosted an online CTF. The event had two types of challenges, what I'll call normal and RIFFHACK challenges. Normal challenges were what you'd expect: web, reverse engineering, crypto, and so on. This blog is about the other kind.

A Strange Setup

The RIFFHACK challenges were all hosted on a single shared instance, with 18 flags to find across it. That design choice stood out to me immediately, for a couple of reasons.

The login page had no rate limiting. In theory, that meant I could have username/password sprayed the site to enumerate other CTF players. On top of that, the site was intentionally vulnerable to XSS as part of the challenge design, which meant, in theory, a malicious actor could have used that combination to hijack other players' sessions, take over their browsers, or worse. I didn't do any of that, it's purely a "this architecture made me uneasy" observation, but it set the tone for how I approached everything that followed.

Finding the Notes Endpoint

I got to work on the actual RIFFHACK challenges and eventually landed on a notes endpoint that looked vulnerable. I started probing it for XSS. There was some filtering in place, but it was a weak WAF, easy to push against. While poking at the edges of what the endpoint would accept, I noticed it was running on React + Next.js, and the implementation looked outdated.

That was enough to make me curious about what else might be exposed.

From XSS Hunting to RCE

With the stack identified, I shifted my focus from the intended XSS angle to looking for the most critical vulnerability I could find, something that would let me check for or even achieve full RCE. That search led me to CVE-2025–55182, a known Remote Code Execution vulnerability. I pulled down a public exploit tool for it, NextRce, pointed it at the target, and, somewhat to my surprise, it worked.

I immediately checked the env file and found out this

I had access to all the flags on the site. I immediately contacted the admins because it is definitely unintentional. The admins were very nice and they said they have solved the issue.

The thing is is that they only changed the flag directory:

I contacted them again and they couldn't solve it. I thought they could have just disable/restrict Server Actions on any route that doesn't strictly need them or run a WAF rule specifically for Next-Action header anomalies, not just generic payload-keyword blocking (their weak WAF only filtering known bad strings is exactly what let UTF‑16LE-style encoding bypass it.)

Linkedin: https://www.linkedin.com/in/bassel-younes-092519397/