A newly discovered vulnerability in H2 database consoles could allow remote code execution, similarly to the recently rampant Log4j “Log4Shell” vulnerability.

H2 is an open-source relational database management system written in Java. It can be embedded in Java applications or run in client-server mode. H2 is popular as a lightweight in-memory solution that does not require data to be stored on disk. It’s used on platforms such as Spring Noot and ThingWorks.

Uncovered Jan. 6 by researchers at JFrog Inc., the critical vulnerability, formally named CVE-2021-42392, has the same root cause as Log4Shell, an issue with JNDI remote class loading. The similarity is that the vulnerability allows several code paths in the H2 database framework to pass unfiltered URLs to a lookup function. That allows for Java code injection of remote code execution.

There are a number of attack vectors that could be used to exploit the vulnerability, the most severe being through the H2 console. A hacker could add a malicious URL with an accompanying driver to undertake unauthenticated remote code execution on the login form, which allows for driver and URL fields to be filled in. Other potential attack vectors included the H2 Shell tool and SQL stored procedures.

Although the vulnerability is classed as critical, the researchers noted that several conditions and configurations must be present for H2 to be at risk. Users of H2, particularly those where the H2 console is exposed by LAN or WAN, should update the H2 database to 2.0.206 immediately.

“While this vulnerability also utilizes remote JNDI class loading, it requires access that is not available with the default configuration of the H2 Database,” Matthew Warner, co-founder and chief technology officer of automated threat detection and response firm Blumira Inc., told SiliconANGLE. “Log4j was unique in that any number of attack-manipulated strings, from headers to URL paths, could result in exploitation of the victim depending on how the application was set up to utilize logging with Log4j. In this case, the H2 Database Console must be purposefully exposed to the internet by changing the configuration to not only listen on localhost.”

Jake Williams, co-founder and CTO at incident response company BreachQuest Inc., noted that this vulnerability won’t be the last one discovered that’s related to Log4j.

“JNDI, the root cause of the Log4Shell vulnerability, is used extensively in Java programs and frameworks,” Williams said. “In this case, it’s unlikely that this will cause widespread damage, though vulnerability managers should be ready to patch other newly discovered JNDI vulnerabilities as they are disclosed.”

Image: JFrog