CVE-2022-41853 is a vulnerability in HyperSQL DataBase (hsqldb), a widely used lightweight Java SQL database engine. The issue arises from unsafe reflection practices, specifically the use of externally controlled input to select classes or code to execute. In versions prior to 2.7.1, when applications use java.sql.Statement or java.sql.PreparedStatement interfaces in hsqldb to process untrusted input, an attacker can exploit this flaw to invoke any static method of any Java class available in the classpath. This can lead to remote code execution (RCE), allowing an attacker to execute arbitrary code on the host system. The root cause is that by default, hsqldb permits unrestricted access to static methods of all classes, which is unsafe when input is not properly sanitized or restricted. The vulnerability is mitigated in version 2.7.1 by changing the default behavior: all classes are blocked except those in java.lang.Math, and access to other classes must be explicitly enabled via the system property "hsqldb.method_class_names". Users can also manually restrict accessible classes by setting this property to a whitelist of allowed classes, e.g., System.setProperty("hsqldb.method_class_names", "abc") or via the Java command line argument -Dhsqldb.method_class_names="abc". No known exploits are currently reported in the wild. The vulnerability is categorized under CWE-470 (Use of Externally-Controlled Input to Select Classes or Code, also known as Unsafe Reflection). This vulnerability can be triggered remotely if the database processes untrusted input through SQL statements without proper validation or sanitization, making it a significant risk in environments where hsqldb is exposed to untrusted users or external networks.

For European organizations, the impact of this vulnerability can be substantial, especially for those relying on hsqldb in web applications, embedded systems, or internal tools that process external or user-supplied SQL queries. Successful exploitation could lead to remote code execution, compromising the confidentiality, integrity, and availability of affected systems. Attackers could execute arbitrary commands, potentially leading to data theft, data manipulation, service disruption, or pivoting within the network. This is particularly critical for sectors with sensitive data such as finance, healthcare, and government agencies. Given that hsqldb is often embedded in Java applications, the attack surface includes any Java-based service or application using vulnerable versions. The vulnerability's exploitation does not require authentication if the database is exposed to untrusted input, increasing risk. However, the absence of known exploits in the wild suggests that exploitation may require specific conditions or knowledge, but the potential impact remains high if exploited.

1. Upgrade to hsqldb version 2.7.1 or later immediately, as this version restricts class access by default and mitigates the vulnerability. 2. If upgrading is not immediately possible, configure the system property "hsqldb.method_class_names" to explicitly whitelist only the necessary classes required by the application, minimizing the attack surface. Avoid allowing broad or default access. 3. Implement strict input validation and sanitization on all SQL statements processed by hsqldb, especially those constructed from user input, to prevent injection of malicious payloads. 4. Restrict network access to hsqldb instances, ensuring they are not exposed directly to untrusted networks or users. Use firewalls, VPNs, or application gateways to limit access. 5. Monitor logs for unusual or unauthorized SQL statements or method invocations that could indicate exploitation attempts. 6. Conduct security reviews and code audits of applications using hsqldb to identify unsafe usage patterns of java.sql.Statement or java.sql.PreparedStatement interfaces. 7. Employ runtime application self-protection (RASP) or Java security managers to limit the capabilities of the Java process running hsqldb, reducing the impact of potential code execution.