Two for Two: Sylvester Jusu's High-Severity Auth Bypass Wins Him Premium Access to the AfricaHackon Dojo

One strong report earns a researcher a reputation. Two in the same month earns them a habit. HackerSavanna researcher Sylvester Jusu (@Debiansl) is back in the spotlight, this time for a High-severity authentication bypass against HackerSavanna's own production environment, and the reward matches the impact.

The reward

Courtesy of Cyber Guard Africa and AfricaHackon, Sylvester has been granted premium access to the AfricaHackon Dojo (dojo.africahackon.com), the hands-on offensive security training range where the region's sharpest researchers go to keep their skills current between engagements. It's a fitting reward for a finding that was itself a lesson in what happens when authentication is enforced in the wrong place.

The finding

Sylvester's report, now remediated and disclosed on SavannaHub, centered on a deceptively simple problem: HackerSavanna's Firebase Web API key was discoverable in the site's client-side source code, and the backend didn't do enough independent verification of what that key was then used to do.

To be clear on the nuance here, since it matters: Firebase API keys are designed to be public. They identify a project, they don't authenticate a privileged caller, and Google's own documentation says as much. The actual vulnerability was never "the key leaked." It was what an attacker could accomplish by calling Firebase's authentication endpoints directly with that key, entirely bypassing the application's own signup flow and its intended safeguards:

• Creating accounts with trivially weak passwords, with no server-side password strength enforcement standing in the way.
• Receiving a fully valid session token without ever verifying an email address, and using that token to access authenticated functionality regardless.
• Pulling full account metadata back out through Firebase's account lookup endpoint using nothing but the token issued in the previous step.

Put together, this meant an unauthenticated attacker could mint an arbitrary number of valid, working accounts on the platform in seconds, each one sitting on an unverified email and a password that wouldn't survive a moment's worth of brute-force guessing, all without ever touching HackerSavanna's own signup page. That's not a client-side inconvenience. That's the authentication boundary itself failing to hold.

What we did about it

The security team confirmed the reproduction exactly as reported, using Sylvester's documented request sequence against Firebase's Identity Toolkit endpoints, then closed the gap by enforcing the missing checks server-side rather than trusting the client-side flow alone: password strength requirements and email verification status are now independently validated on the backend before an account is treated as fully authenticated, regardless of how the underlying Firebase token was obtained. The finding has since been disclosed publicly with technical detail on SavannaHub.

Why this matters

Client-side controls are a UX layer, not a security boundary, and this report is as clean a demonstration of that principle as HackerSavanna's own VDP has seen. Every check enforced only in the browser is a check an attacker with a terminal and Sylvester's report doesn't have to satisfy at all. This class of bug is common precisely because it's easy to miss: the signup form looks secure, works correctly for every real user, and gives no visible sign that the actual enforcement is missing one layer down.

Congratulations to Sylvester Jusu on another well-earned recognition, and welcome to the Dojo. Two disclosed findings in, we're paying close attention to what comes next.

Read the full disclosed report on SavannaHub.