CVE-2026-63231

CVE-2026-63231 is being classified as a post-authentication SQL injection with an 8.1 CVSS score. That rating badly understates the actual impact. The vulnerability gave an attacker one valid credential and returned the keys to every account in the system. The root cause is architectural, not merely injection-related. The application stored active JWT tokens in a SQL database that application queries could reach. Once an attacker used the SQL injection as an error-based oracle to extract those tokens, they had horizontal movement to every user session — no additional credentials needed. The authentication gate that was supposed to contain the blast radius became irrelevant the moment the database layer became readable through the injection. This matters because CVSS treats the authentication requirement as a scope constraint, discounting post-auth vulnerabilities. But when post-auth access to one endpoint cascaded into full credential compromise across all users, the 'authenticated attacker' framing collapsed entirely. The CVSS vector doesn't capture this second-order effect. The compounding failure is that the application also returned raw database error content to the user layer — indicating inadequate error sanitization beyond the injection point itself. That's a second misconfiguration layered on top of the first. For defenders: patch the SQL injection, obviously. But the more important question is whether your session management architecture stores active tokens in any database that application queries can reach. Tokens should live in memory, encrypted at-rest with separate key management, or in a data store wholly isolated from the application's query path. If your ORM or framework defaults to persisting JWTs in a relational database, treat that as an architectural smell worth refactoring — because the next injection vector is already being built.

Reviewed through automated stages and approved by a human before publication.