H2 database console remote code execution (CVE-2021-42392)

In the same week that Log4Shell reshaped how the industry thinks about ubiquitous open-source dependencies, a strikingly similar flaw surfaced in the H2 database engine's web console and JDBC URL handling. Tracked as CVE-2021-42392, the vulnerability allows an unauthenticated or low-privileged attacker who can reach the H2 Console, TCP server, or a JDBC connection string to achieve remote code execution (RCE) by pointing H2's internal javax.naming.InitialContext.lookup() call at an attacker-controlled JNDI endpoint — the exact same gadget class that made Log4Shell so devastating. Because H2 ships as an embedded database inside countless Java applications, dev tools, and CI/test harnesses, the practical blast radius extends well beyond anyone who deliberately installed "H2" as a product.

What Went Wrong

H2's org.h2.util.JdbcUtils.getConnection() method resolves database drivers and data sources by name, and — mirroring the pattern later found fatal in Log4j — it happily performs a JNDI lookup on attacker-supplied input without validating the target scheme or the class being deserialized. If an attacker can control the JDBC URL, the "Driver" field on the H2 Console login page, or a data source name passed into H2's TCP server, they can supply a reference to a remote ldap:// or rmi:// server. That remote server returns a serialized Java object or a reference to a remote class, which the JVM hosting H2 then loads and instantiates — resulting in arbitrary code execution in the context of the application process.

This is materially different from a typical SQL injection or authentication bypass: no valid database credentials are strictly required if the console or TCP listener is reachable and accepts attacker-influenced connection parameters. In many real-world deployments, the H2 Console is left enabled for "just this one debugging session" and forgotten, or a Spring Boot application ships with spring.h2.console.enabled=true in a configuration profile that leaks into production.

Affected Versions and Components

• H2 Database Engine: all versions prior to 2.0.206 are vulnerable.
• H2 Console (org.h2.tools.Console): the web-based admin console is the most commonly exposed attack surface, particularly when bound to 0.0.0.0 or exposed through a reverse proxy for convenience during development.
• H2 TCP Server: instances running with the TCP listener enabled (-tcp, -tcpAllowOthers) are exploitable even without the web console.
• Applications embedding H2 as a transitive dependency: Spring Boot projects (via spring-boot-starter-data-jpa + com.h2database:h2), numerous CI/test frameworks, low-code platforms, and vendor products that bundle H2 for local persistence or in-memory testing can all inherit this flaw without the application team ever directly depending on H2 at the top level. This is the category most likely to be missed in a manual dependency audit and is exactly why the vulnerability generated broad concern industry-wide following Log4Shell.

The fix was shipped in H2 2.0.206 (released December 10, 2021), which restricts the classes and schemes that JdbcUtils will resolve through JNDI, closing off the arbitrary-class-loading path.

CVSS, EPSS, and KEV Context

• CVSS v3.1: NVD lists a base score of 9.8 (Critical) — AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H — reflecting a network-exploitable, no-privilege, no-interaction path to full compromise of confidentiality, integrity, and availability. Some vendor advisories score it more conservatively (closer to 7.5–8.1) since practical exploitation depends on the console, TCP server, or an attacker-influenced JDBC URL being reachable — a real but common precondition given how often H2 is exposed in non-production and shadow-IT environments.
• EPSS: Given the vulnerability's Log4Shell-adjacent gadget chain and the volume of security research and public proof-of-concept exploitation published in December 2021, EPSS scoring for CVE-2021-42392 has historically sat in the higher percentile bands relative to the broader CVE population, indicating meaningfully elevated real-world exploitation likelihood compared to a typical CVE. Security teams should treat EPSS as a supporting prioritization signal here, not a substitute for checking actual exposure.
• CISA KEV: As of this writing, CVE-2021-42392 does not appear on CISA's Known Exploited Vulnerabilities catalog. Absence from KEV should not be read as low risk — KEV tracks confirmed exploitation in the wild with federal reporting obligations, and plenty of high-impact, actively-abused flaws in internal tooling and dev infrastructure never generate the telemetry needed for KEV inclusion. Given the JNDI gadget's kinship with Log4Shell and the ease of weaponization, we recommend treating this as Critical-priority regardless of KEV status.

Timeline

• December 9, 2021 — CVE-2021-44228 (Log4Shell) is publicly disclosed, triggering an industry-wide hunt for similar JNDI-lookup patterns across the Java ecosystem.
• December 10, 2021 — H2 maintainers ship version 2.0.206, patching the JNDI-based class-loading path in JdbcUtils.getConnection() — a remarkably fast turnaround directly attributable to Log4Shell-driven scrutiny of JNDI usage in widely embedded libraries.
• Mid-to-late December 2021 — Security researchers publish technical write-ups and proof-of-concept exploits demonstrating RCE via the H2 Console login form and TCP server, drawing direct parallels to Log4Shell's exploitation mechanics.
• December 30, 2021 — CVE-2021-42392 is formally published in the National Vulnerability Database with a Critical severity rating.
• Early 2022 onward — Downstream vendors and frameworks that bundle H2 (Spring Boot ecosystem projects, low-code platforms, CI tooling, various enterprise appliances with embedded admin databases) begin issuing their own advisories and patched releases as they update their pinned H2 versions.

Remediation Steps

1. Upgrade H2 to 2.0.206 or later immediately. This is the single highest-leverage action; confirm the fixed version across every application, service, and test harness that pulls in com.h2database:h2, including transitive dependencies pulled in by frameworks or vendor products.
2. Disable the H2 Console in any environment beyond isolated local development. For Spring Boot applications, explicitly set spring.h2.console.enabled=false in production and staging profiles rather than relying on a default. Remove or comment out org.h2.tools.Console servlet registrations in bespoke deployments.
3. Never bind the console or TCP server to 0.0.0.0 or a public interface. If a console is genuinely needed for a shared debugging environment, restrict it to webAllowOthers=false, place it behind VPN/bastion access, and require strong authentication rather than default or blank credentials.
4. Disable the TCP server (-tcp) and -tcpAllowOthers unless there is a documented business need, and if required, restrict access via firewall rules and mutual TLS rather than network-layer trust alone.
5. Audit and sanitize any code path that constructs JDBC URLs or data source names from user input. Even on a patched H2 version, treating connection strings as trusted-only input is a durable defense-in-depth practice.
6. Generate or refresh your SBOM to identify every transitive path to H2, including dependencies of dependencies inside vendor-shipped JARs, container base images, and CI tooling — this is the category of exposure manual reviews reliably miss.
7. Add egress monitoring and blocking for outbound LDAP/RMI traffic from application tiers that have no legitimate reason to initiate such connections, as a compensating control against this and future JNDI-style gadget chains.
8. Review logs retroactively for suspicious JDBC URL parameters or console login attempts referencing ldap://, rmi://, or unfamiliar driver class names dating back to December 2021, in case exploitation predates detection.

How Safeguard Helps

CVE-2021-42392 is a textbook case of a Critical vulnerability hiding several layers deep in a transitive dependency tree — exactly the blind spot Safeguard is built to close. Our SBOM generation and ingestion pipeline surfaces every path by which H2 enters your environment, including nested dependencies inside vendor JARs and bundled frameworks that traditional manual audits routinely miss. From there, Safeguard's reachability analysis determines whether the vulnerable JdbcUtils.getConnection() code path is actually invoked in your compiled application or container image — separating services that genuinely need urgent patching from those where the H2 jar is present but functionally dormant, so your team isn't triaging noise. Griffin AI correlates that reachability signal with exposure context (is the console reachable, is the TCP listener open, is the JDBC URL attacker-influenced) to produce a prioritized, explainable risk score rather than a flat CVSS number. When remediation is confirmed necessary, Safeguard can open an auto-fix pull request bumping H2 to 2.0.206 (or later) directly in the affected manifest, cutting the time from detection to a merged fix from days to minutes.