Clojure
Monthly
SQL injection can result in HoneySQL (Clojure; Maven/Clojars coordinate com.github.seancorfield/honeysql) versions 2.0.0 through 2.7.1391 when an application calls `keyword` or `symbol` on untrusted input to build DSL entities and the rendered SQL string is then executed unchanged by a JDBC driver, because several formatters emit those entity names without applying the library's existing suspicious-character check. The CVSS vector is AV:N/AC:L/PR:N/UI:N (unauthenticated, network-reachable), and the impact is bounded by the privileges of the database connection that runs the generated statement; applications that never route arbitrary data through `keyword`/`symbol` entity construction are not exploitable even on vulnerable versions. No public exploit code was identified at time of analysis, and the maintainer-designated fix is release 2.7.1392, with a vuln.today decision label of act_now reflecting the 9.8 severity score and CWE-89 classification.
Server-side request forgery in Metabase through 0.63.18 lets an attacker bypass GeoJSON URL validation by saving a custom GeoJSON entry that points at the unspecified address 0.0.0.0, which resolves to loopback and causes the Metabase server to fetch from services bound to localhost and return their responses to the caller. Note a conflict in the source data: vendor scoring (CVSS 4.0 with PR:H) requires high-privileged, authenticated access to persist the malicious GeoJSON entry, while the CVE description asserts that the triggered read is returned to unauthenticated callers - the authentication bar for triggering and reading should be verified against the vendor advisory. Publicly available exploit code exists (VulnCheck advisory and a public write-up), there is no CISA KEV listing indicating confirmed active exploitation at time of analysis, and impact is confidentiality-only, since only response data is exposed with no integrity or availability effect.
SQL injection can result in HoneySQL (Clojure; Maven/Clojars coordinate com.github.seancorfield/honeysql) versions 2.0.0 through 2.7.1391 when an application calls `keyword` or `symbol` on untrusted input to build DSL entities and the rendered SQL string is then executed unchanged by a JDBC driver, because several formatters emit those entity names without applying the library's existing suspicious-character check. The CVSS vector is AV:N/AC:L/PR:N/UI:N (unauthenticated, network-reachable), and the impact is bounded by the privileges of the database connection that runs the generated statement; applications that never route arbitrary data through `keyword`/`symbol` entity construction are not exploitable even on vulnerable versions. No public exploit code was identified at time of analysis, and the maintainer-designated fix is release 2.7.1392, with a vuln.today decision label of act_now reflecting the 9.8 severity score and CWE-89 classification.
Server-side request forgery in Metabase through 0.63.18 lets an attacker bypass GeoJSON URL validation by saving a custom GeoJSON entry that points at the unspecified address 0.0.0.0, which resolves to loopback and causes the Metabase server to fetch from services bound to localhost and return their responses to the caller. Note a conflict in the source data: vendor scoring (CVSS 4.0 with PR:H) requires high-privileged, authenticated access to persist the malicious GeoJSON entry, while the CVE description asserts that the triggered read is returned to unauthenticated callers - the authentication bar for triggering and reading should be verified against the vendor advisory. Publicly available exploit code exists (VulnCheck advisory and a public write-up), there is no CISA KEV listing indicating confirmed active exploitation at time of analysis, and impact is confidentiality-only, since only response data is exposed with no integrity or availability effect.