HoneySQL EUVD-2026-114395

Exploitation requires the consuming application to pass user input or other arbitrary data into HoneySQL's DSL by calling keyword or symbol on that data, and the resulting SQL to be executed unchanged by a JDBC driver; the flaw manifests only because some formatters do not apply the existing suspicious-character check to entity names. It is further limited to library versions >= 2.0.0 and < 2.7.1392, and the severity of impact is bounded by the privileges of the database connection running the statement. Applications that never route untrusted data through keyword/symbol entity construction are not exploitable even on vulnerable versions. The maintainer workaround is to validate input before constructing keyword/symbol entities, though the maintainer notes this is tedious and error-prone; upgrading to 2.7.1392 is the designated fix.

The input assigns CVSS 9.8 (AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H) and a vuln.today 'act_now' decision label, both signaling top urgency, and the CWE-89 classification plus GHSA advisory confirm this is a genuine SQL injection weakness. However, these signals must be read against the vulnerability's nature: this is a library-level flaw that only becomes exploitable when the consuming application itself passes user-controlled or otherwise arbitrary data into HoneySQL's DSL by calling keyword or symbol on it - a specific, non-default coding pattern on the application side. The CVSS vector therefore describes the worst-case exploitable application (remote, unauthenticated, full CIA impact), not every deployment of the library. No EPSS score, no CISA KEV listing, and no verified exploit code are present in the input, so there is no evidence of active exploitation or mass scanning; the 9.8/act_now posture is driven by severity and the ease of exploitation in affected apps rather than by observed in-the-wild activity. The maintainer also notes the real impact 'depends on the privileges of the database connection executing the generated statement,' so C/I/A impact in practice scales with DB account privileges. Net: this is a real, high-priority patch for any Clojure application that feeds untrusted data through keyword/symbol into HoneySQL, but the blanket 9.8 overstates risk for applications that never pass arbitrary input into entity names.

An attacker supplies crafted input (for example a column or table name derived from an HTTP parameter) to a Clojure application that converts that input via keyword or symbol into a HoneySQL entity. Because some formatters do not apply the suspicious-character check, the resulting entity name carries SQL metacharacters into the generated SQL string, which a JDBC driver then executes unchanged, yielding SQL injection. No public exploit code is identified in the provided input; the GitHub references are the patch commit and advisory, not a working exploit.