Break it.Prove it.Fix it.

The user-controlled q query parameter is concatenated into a raw SQL string in the users search handler. A crafted payload (' OR 1=1 --) returns the full users table, including hashed passwords and email addresses. Confirmed against the staging database with a benign probe.

An unauthenticated attacker can dump the entire users table, including email and password_hash columns. The same SQL context allows arbitrary reads across any table the application role can SELECT from: billing rows, session tokens and audit logs are all reachable from this single endpoint. The string is handed to db.execute() on the simple query protocol, which accepts stacked statements, so the same parameter can write or drop as easily as it reads.

The vulnerable handler concatenates req.query.q directly into the SQL string:

export async function searchUsers(req: express.Request) {

  const q = req.query.q;

  // FIXME: parameterize

  const sql = `SELECT * FROM users

    WHERE email ILIKE '%${q}%' ORDER BY created_at DESC LIMIT 50`;

  return db.execute(sql);

}

1. 1.Send a probe with a tautology payload. No session is required. The route is not behind authentication:

GET /api/v1/users?q=' OR 1=1 -- HTTP/2
Host: staging.acme.io

2. 2.The endpoint answers 200 with the whole table, hashes included:

HTTP/2 200 OK
content-type: application/json
 
{"total":1284,"users":[{
  "id": "usr_8c21", "email": "[email protected]",
  "password_hash": "$2b$10$Qw8xR1u…"
}, …]}

The trailing -- comments out the rest of that line, so ORDER BY and LIMIT 50 never apply: the same request without the payload returns 50 rows.