BobDaHacker

That's a different thing. RTMP ingest endpoints aren't behind the same API layer, they're just open media endpoints that accept a connection if you have the stream key. The stream key was right there in the URL. There's no JWT involved in pushing video to an RTMP ingest, it's just connect and publish.

I am not much of a football gal myself, so I didn't know they were a shitty org.

Also, I am not much of a football gal myself, so I didn't know they were a shitty org.

As much as I like being butt fucked, I dont wanna go to prison :3

Yeah I used Claude as a writing assistant for the initial draft. I'm autistic and long-form writing isn't my strong suit, getting a 4000 word blog post to flow well is genuinely hard for me. But I do edit it pretty heavily after, the voice and the jokes and the structure are mine, the AI just helps me get a baseline down so I'm not staring at a blank page. The research, the screenshots, the disclosure, that's all me. I've been doing this stuff for years.

Good question! So RTMP doesn't really have a clean way to handle two publishers on the same stream key. What would actually happen is the two streams fighting for the ingest endpoint, so the output would glitch between the two sources. Like if I pushed Subway Surfers gameplay it'd be flickering between the actual match and Subway Surfers with the audio cutting back and forth. You're right that a live director would catch it pretty fast but even a few seconds of that on air during a World Cup match is not great.

Yeah I see this type of crap often honestly, especially at big companies.

I blocked my network traffic before clicking it cuz I've seen a lot of things without confirmation pop-ups. At least there was a confirmation pop-up.

Registered on FIFA's public Agent Platform with my ID, got added to their Microsoft Entra tenant, and found the Angular app only checked roles client-side. The backend APIs served everything: RTMP ingest URLs and stream keys for every live World Cup 2026 camera feed across all five angles. Confirmed live in VLC. An attacker could have pushed arbitrary video to the ingest endpoints and replaced broadcast feeds on TV worldwide. Write access to match stats, commentator notes, and the live score system was also exposed.

Burger King

Yes. I really hope this teaches them a lesson and they fix it before 4chan acts but that problem won't happen. Also If I would have stayed quiet and not informed the public that the app doesnt care about your privacy, a databreach was bound to happen at some point, because they are just leaving holes for bad guys to discover.

I do want people's privacy to be protected, this app has been insecure since day one, and they obviously don't care, it's been 9 months. I posted about it since they obviously didnt give a shit, because this will now hopefully force them to actually fix it.

Instead of fixing these issues they have been implement "ai matchmaking" like that is more important.

And these fixes aren't that hard either. Its not rocket science.

My goal is not to get hired, my goal is to hold them responsible and hopefully make them fucking fix it.

I hate companies that don't give a rats ass about their users security and waste time making ai shit instead of fixing their problems cuz they dont care.

You absolutely nailed it. As the researcher who found these vulns, I can confirm the over-engineering is real.

They literally had internal user IDs (ofId) already implemented and working, but kept the email-based JIDs for "legacy support." The entire XMPP system could have used these internal IDs from day one.

The "14 months to fix" claim was even more ridiculous when you realize the fix was just... using the IDs they already had. No architectural changes needed. They even admitted they had a 1-month fix ready but chose not to deploy it.

Your microservice translation layer guess is scary accurate - that's essentially what their "v2" endpoints were trying to do. They created new HTTP endpoints that used internal JIDs instead of email-based ones, but the XMPP layer still exposed everything, making the whole effort pointless.

The best part? After going public, they implemented the "impossible" fix in 48 hours. Turns out you don't need 14 months when the Internet is watching.

Hi HN, I'm the researcher who found these vulnerabilities. Happy to answer questions.

A few clarifications on the technical side:

The XMPP issue wasn't just about JIDs containing emails - it was that their roster sync actively linked internal IDs to real email JIDs. Even their "v2" endpoints that tried to hide emails were useless because the XMPP layer still exposed everything.

Regarding the "14 months to fix" claim - they actually had the fix ready (they admitted they could do it in 1 month) but chose not to deploy it for "legacy support." The fix they implemented after public pressure was exactly what I suggested months ago: just use the internal IDs they already had.

The most frustrating part was discovering other researchers reported these exact bugs in 2022 and 2023. Lovense told them it was "fixed" while paying them peanuts ($350 vs the $3000 they paid me for the same bugs).

Also, to address the over-engineering comment by chmod775 - you're spot on. They had internal user IDs (ofId) the whole time but maintained this complex dual system. The "architectural complexity" was self-inflicted.