Researchers discover Log4j-like errors in the H2 database console

The effect of the JNDI error is mitigated by the fact that vulnerable behavior is disabled by default

Researchers discover Log4j-like errors in the H2 database console

A vulnerability with the same root cause as the notorious log4j errors have been fixed in the console of the very popular Java SQL database, H2 Database Engine.

As with the latest ‘Log4Shell’ exploits, unauthorized attackers can obtain remote code execution (RCE) because the console accepts arbitrary Java naming and directory interface (JNDI) storage URLs.

The bug (CVE-2021-42392) “allows loading of custom classes from remote servers through JNDI”, according to a GitHub safety advice published by the H2 maintainers on January 5th.

RECOMMENDED Researcher discovers 70 web cache poisoning vulnerabilities and brings in $ 40,000 in bug bounty rewards

The vulnerability justified the suspicions of the security researchers who found it – that the widespread use of JNDI suggested “there are several packages that are affected by the same root cause as Log4Shell”, according to a blog posts published yesterday (January 6) by Andrey Polkovnychenko and Shachar Menashe of the cyber security firm JFrog.

With nearly 7,000 artifact dependencies, the H2 is one of the most popular open source Maven packages.

Worrying, given “the recent trend of supply chain attacks aimed at developers, ”said Polkovnychenko and Menashe, who had observed many H2-dependent developer tools that revealed the H2 console.

Safe by default

The pair described the error as “extremely critical” if H2 consoles are exposed to a LAN, or worse, WAN.

However, the threat is significantly reduced by the fact that the H2 console is secure in its default setting, listening only to local host connections (although remote connections are easy to activate, the researchers note).

Moreover RCE will typically only affect the server processing the initial request, and many vendors running the H2 database may not delay the H2 console.

Nevertheless, JFrog recommends that all H2 users upgrade to the latest version, whether they use the H2 console directly or not.

This is because there are other attack vectors – the researchers also found H2 Shell tools and authentication-dependent SQL vectors – even though they are “context-dependent and less likely to be exposed to remote attackers”.

Restriction of JNDI URLs

Vulnerable H2 versions range from 1.1.100 to 2.0.204 inclusive.

The researchers praised the H2 maintainers for fixing the bug immediately in version 2.0.206, released on January 5th.

Similar to the Log4j fix, the patch restricts JNDI URLs to use the local one Java protocol only, which blocks remote LDAP / RMI requests.

Follow the latest Log4J vulnerability news and analysis

Regardless of patching, “it’s a dangerous setting that should be avoided,” warns the H2 adviser.

However, if the H2B Conslet Servlet is installed on a web server, users can add a security restriction that only allows specific users to access the console page.

“As far as we know, CVE-2021-42392 is the first JNDI-related unauthenticated RCE vulnerability that has been released since Log4Shell, but we assume it will not be the last,” said Polkovnychenko and Menashe.

As such, JFrog continues to search for similar bugs.

JNDI injection was also used before Log4Shell by Taiwanese researcher Orange Tsai, who compromised internal Facebook systems in 2020 via a vulnerability in the mobile device management platform MobileIron.

YOU MAY ALSO LIKE Java RMI services are often vulnerable to SSRF attacks – research

Follow us on Google News

Disclaimers for

All the information on this website – – is published in good faith and for general information purposes only. does not make any warranties about the completeness, reliability, and accuracy of this information. Any action you take upon the information you find on this website (, is strictly at your own risk. will not be liable for any losses and/or damages in connection with the use of our website.

Give a Comment