Critical H2 database vulnerability similar to Log4Shell disclosed

All H2 users should upgrade to the newest version 2.0.206 which is patched for the flaw

Researchers at software company JFrog have uncovered a new vulnerability affecting H2 database consoles that could allow threat actors to achieve remote code execution (RCE) in applications and software in a manner similar to the infamous Log4Shell bug.

In a blog post, JFrog researchers Andrey Polkovnychenko and Shachar Menashe said the security vulnerability, tracked as CVE-2021-42392, has the same root cause as the Log4Shell vulnerability in Apache Log4j (JNDI remote class loading), although it should not be as widespread as Log4Shell.

H2 is a Java-based open-source relational database management system that may be incorporated in applications or run in a client-server mode. It's popular among developers because of its lightweight in-memory capabilities that eliminate the need to keep data on disk. H2 is used as a data storage solution for various projects from web platforms like Spring Boot and IoT platforms such as ThingWorks.

According to the Maven Repository, the H2 database engine has almost 7,000 artifacts dependencies.

The Log4jShell bug, which was uncovered last month and is tracked as CVE-2021-44228, exists in the Apache Log4j Java logging library. Researchers described it as a highly dangerous, widespread and easy to exploit bug which could allow attackers to execute malicious code on Java applications. The vulnerability is triggered when a specially crafted string provided by the attacker through a variety of different input vectors is parsed and processed by the vulnerable Log4j component.

According to JFrog researchers, the H2 weakness is caused by JNDI remote class loading, making it similar to Log4Shell in that it permits numerous code paths in the H2 database framework to pass unfiltered attacker-controlled URLs to the javax.naming.Context.lookup function. This enables remote codebase loading, also known as RCE or Java code injection.

If H2 consoles are exposed to a LAN, or worse, a WAN, the issue becomes "very severe," the researchers said.

However, the vulnerability is mitigated significantly by the fact that the H2 console is secure by default, and listens only to localhost connections.

"H2 Console doesn't accept remote connections by default. If remote access was enabled explicitly and some protection method (such as security constraint) wasn't set, an intruder can load own custom class and execute its code in a process with H2 Console (H2 Server process or a web server with H2 Console servlet)," the H2 advisory says.

Furthermore, the vulnerability is mitigated by the fact that typically the server that processes the initial request (the H2 console) will be the server that gets impacted with RCE.

"This is less severe compared to Log4Shell since the vulnerable servers should be easier to find," according to the researchers.

The researchers also state that while vendors may be running the H2 database, they may not be running the H2 console, meaning some attack vectors will not be as readily exploitable as those found in Log4Shell.

Versions 1.1.100 through 2.0.204 of the H2 database are affected by the issue, which was fixed in version 2.0.206 released on 5 January 2022.

JFrog researchers recommend that all H2 users upgrade to the newest version whether they directly use the H2 console or not, in order to avoid possible exploitation of CVE-2021-42392.