Daily BugForge Challenge: Cheesy Does it (SQL)
- 404Yeti here.
Today we’re stepping into another BugForge challenge, this time carving open Cheesy Does It. What looked like an ordinary login portal turned out to be sitting on a brittle foundation. Under a little pressure, it cracked fast.
This challenge revolves around a classic failure: SQL injection in the login flow. Nothing fancy. No exotic exploit chain. Just an application trusting input it never should have believed.
Step 1 make an account
For this exercise, creating an account was not strictly necessary.
Still, it is a good habit.
When working through labs like this, I like to register a normal user first whenever possible. It helps establish a baseline for how the application behaves, what requests are generated, and what normal authentication is supposed to look like before we start applying pressure.
That baseline matters. Weak security often reveals itself in the difference between what the app is supposed to do and what it actually allows.
Step 2 Inspect the login request
he next move was to examine the login functionality closely, especially the API request handling the authentication process.
This is where the trail usually begins.
Whenever a login form submits data, I want to know:
- what parameters are being sent
- how the request is structured
- whether the backend appears to trust raw user input
- whether there are signs of poor filtering or weak validation
If the application is passing user-controlled input directly into a database query without proper sanitization or parameterized statements, the login portal becomes more than a form. It becomes an entry point.
Step 3. Test the login portal
Send the request to replay to manipulate the request
After capturing the login request, I sent it to Replay to manipulate the input and test how the backend handled unexpected payloads.
This is where the facade broke.
In the password field, I inserted the following payload:
'OR 1=1--
So we can see the request was successful and we got the flag and see all of admins' PII
Proof of concept
To validate the impact, I used the manipulated login flow as a working proof of concept.
The result was direct access to the admin account.
At that point, this was no longer just a suspicious response or partial bypass. The weakness had become a full authentication failure with real impact. A low-effort input manipulation led to unauthorized access and exposure of sensitive data.
That is the kind of flaw attackers love: simple to execute, easy to repeat, and devastating when left unguarded.
CVSS Score
I would score this as Critical if this behavior existed in a real production application, because it can lead to:
- authentication bypass
- unauthorized access to privileged accounts
- exposure of sensitive user data
- potential full compromise depending on admin capabilities
A reasonable estimate would often fall around:
CVSS v3.1: 9.8 Critical
CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:HWhy this is important
SQL injection is old, but old does not mean harmless.
Flaws like this still show up because developers continue to trust input too early, validate too late, or fail to use parameterized queries. And when the weakness sits inside authentication logic, the impact becomes immediate.
This is not just about logging into the wrong account in a lab.
In a real environment, this kind of failure can lead to:
- admin account takeover
- exposure of customer or employee records
- privilege escalation
- lateral movement into other application functions
- reputational damage and compliance risk
Attackers do not need an advanced toolkit when the front door opens because the query was built carelessly.
Final Thoughts
Cheesy Does It was a clean reminder that some of the most dangerous flaws are also the oldest.
No elaborate exploit chain. No stealthy post-exploitation. Just one brittle login flow, one unsafe query, and one application willing to trust the wrong thing.
Bad security leaves footprints.
This one left them all over the login page.
— 404Yeti