JetBrains Exposed EUVD-2026-96025

Exploitation requires a downstream application that (1) uses JetBrains Exposed before version 1.5.1 and (2) passes attacker-controllable, unescaped string values into one of the specific affected SQL functions that fail to escape string arguments. This is the concrete prerequisite stated by the advisory ('via unescaped string arguments of several SQL functions'). The key limiting factor is that the flaw is not triggerable against the library in isolation: an application must actually route untrusted input into the vulnerable function calls, so apps that only pass literals or use parameterized/escaped paths are not exposed. Unauthenticated reach (per PR:N) depends on the hosting application exposing the vulnerable code path without authentication; the exact function names are not provided, so developers must audit their Exposed usage to confirm applicability.

The input CVSS 3.1 vector (AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H, base 9.8) describes an unauthenticated, network-reachable SQL injection (CWE-89) with full confidentiality, integrity, and availability impact - a worst-case nominal score. However, the signals are incomplete and partly in tension with the description. No EPSS probability was provided, the CVE is NOT on the CISA KEV list, and no public proof-of-concept is indicated, so exploitation status is: no public exploit identified at time of analysis. Critically, Exposed is a Kotlin SQL library/ORM, not a standalone network service: the 9.8 severity is only realized when a downstream application passes untrusted input to the specific affected SQL functions without escaping. The PR:N/AV:N scoring reflects the end attacker (typically an unauthenticated web user hitting a vulnerable app endpoint) rather than any inherent remote listener in the library itself. This is therefore a real and serious priority for teams that build on Exposed and use the affected functions with user-controlled strings, but the absence of KEV/EPSS/POC signals, combined with the conditional 'developer-must-have-used-the-vulnerable-API' nature of library SQLi, argues against assuming widespread opportunistic exploitation. Treat as high-priority-to-patch rather than confirmed-under-attack.

A web application built on JetBrains Exposed (before 1.5.1) passes user-supplied input into one of the affected SQL functions that does not escape string arguments. An unauthenticated attacker submits a crafted value through a normal request field, which is concatenated into the generated SQL and alters the query, allowing data exfiltration or manipulation. No public exploit code has been identified, so exploitation would currently require an attacker to craft their own payload against a known-vulnerable usage.