Summary
HoneySQL can generate SQL containing attacker-controlled syntax when applications convert untrusted input into keyword or symbol entities for the DSL. If the resulting SQL is executed unchanged through JDBC, an attacker may alter database queries, with the consequences depending on the database account's privileges.
HoneySQL can generate SQL containing attacker-controlled syntax when applications convert untrusted input into keyword or symbol entities for the DSL. If the resulting SQL is executed unchanged through JDBC, an attacker may alter database queries, with the consequences depending on the database account's privileges.
Affected context
The vulnerability can occur in applications using affected HoneySQL releases that:
- Pass user-controlled or otherwise arbitrary data into the HoneySQL DSL
- Convert that data into Clojure
keywordorsymbolvalues - Use formatters that do not consistently apply suspicious-character checks to generated entity names
- Execute the generated SQL without an additional trusted validation or parameterization layer
Risk is greatest when generated statements are sent directly to JDBC and the database connection has broad privileges.
The vulnerability can occur in applications using affected HoneySQL releases that:
- Pass user-controlled or otherwise arbitrary data into the HoneySQL DSL
- Convert that data into Clojure
keywordorsymbolvalues - Use formatters that do not consistently apply suspicious-character checks to generated entity names
- Execute the generated SQL without an additional trusted validation or parameterization layer
Risk is greatest when generated statements are sent directly to JDBC and the database connection has broad privileges.
Exploit preconditions
- Attack surface: Application code that builds SQL through HoneySQL's DSL
- Required access: Ability to influence data later converted into a HoneySQL
keywordorsymbol - Trigger point: Formatting the DSL structure and executing the resulting SQL through JDBC
- Why exploitation is possible: Attacker-controlled entity names can enter generated SQL without consistent suspicious-character checks, allowing SQL syntax to be altered when the statement is executed unchanged
- Attack surface: Application code that builds SQL through HoneySQL's DSL
- Required access: Ability to influence data later converted into a HoneySQL
keywordorsymbol - Trigger point: Formatting the DSL structure and executing the resulting SQL through JDBC
- Why exploitation is possible: Attacker-controlled entity names can enter generated SQL without consistent suspicious-character checks, allowing SQL syntax to be altered when the statement is executed unchanged
Why this happens
The underlying flaw is insufficient separation between untrusted data and SQL syntax during DSL formatting. Certain formatter paths allow attacker-influenced names represented as Clojure keyword or symbol values to become SQL fragments without consistently applying the available suspicious-character validation.
This maps to CWE-89: Improper Neutralization of Special Elements used in an SQL Command, because input is incorporated into a generated SQL statement in a way that can preserve or introduce database-interpreted syntax.
The underlying flaw is insufficient separation between untrusted data and SQL syntax during DSL formatting. Certain formatter paths allow attacker-influenced names represented as Clojure keyword or symbol values to become SQL fragments without consistently applying the available suspicious-character validation.
This maps to CWE-89: Improper Neutralization of Special Elements used in an SQL Command, because input is incorporated into a generated SQL statement in a way that can preserve or introduce database-interpreted syntax.
Potential impact
- Unauthorized reading of database records
- Modification or deletion of application data
- Bypass of query conditions or authorization logic enforced in SQL
- Execution of database-specific administrative actions, where permitted
- Exposure of credentials, personal data, or other sensitive information
- Broader application compromise if the database account has excessive privileges
- Unauthorized reading of database records
- Modification or deletion of application data
- Bypass of query conditions or authorization logic enforced in SQL
- Execution of database-specific administrative actions, where permitted
- Exposure of credentials, personal data, or other sensitive information
- Broader application compromise if the database account has excessive privileges
General mitigation guidance
Mitigation generally focuses on preventing untrusted values from becoming SQL identifiers or syntax.
Common defensive patterns include:
- Validating input before constructing HoneySQL
keywordorsymbolentities - Using allowlisted mappings from external values to trusted database identifiers
- Preferencing parameterized query values rather than dynamically concatenated SQL fragments
- Applying consistent identifier validation across every formatter path
- Treating generated SQL as untrusted until it has passed structural and policy checks
- Limiting database accounts to the minimum permissions required by the application
- Separating read and write credentials where practical and restricting administrative capabilities
Mitigation generally focuses on preventing untrusted values from becoming SQL identifiers or syntax.
Common defensive patterns include:
- Validating input before constructing HoneySQL
keywordorsymbolentities - Using allowlisted mappings from external values to trusted database identifiers
- Preferencing parameterized query values rather than dynamically concatenated SQL fragments
- Applying consistent identifier validation across every formatter path
- Treating generated SQL as untrusted until it has passed structural and policy checks
- Limiting database accounts to the minimum permissions required by the application
- Separating read and write credentials where practical and restricting administrative capabilities
How teams detect issues like this
Organizations can look for this weakness through:
- Static analysis rules that flag user input flowing into HoneySQL
keywordorsymbolconstructors - Code review checks for dynamic identifiers, raw SQL execution, and unchanged formatter output sent to JDBC
- Tests using unexpected identifier characters to verify rejection and safe handling
- Runtime monitoring for unusual query structure, privilege-sensitive statements, or unexpected database access
- Policy enforcement that requires allowlisted identifiers and parameterized values for database operations
Automated code review and data-flow analysis tools may help identify tainted input reaching SQL-generation and execution boundaries.
Organizations can look for this weakness through:
- Static analysis rules that flag user input flowing into HoneySQL
keywordorsymbolconstructors - Code review checks for dynamic identifiers, raw SQL execution, and unchanged formatter output sent to JDBC
- Tests using unexpected identifier characters to verify rejection and safe handling
- Runtime monitoring for unusual query structure, privilege-sensitive statements, or unexpected database access
- Policy enforcement that requires allowlisted identifiers and parameterized values for database operations
Automated code review and data-flow analysis tools may help identify tainted input reaching SQL-generation and execution boundaries.
