CVE-2026-88391: Northstar H2 Console Exposed with Default Credentials Enables RCE

Overview

Northstar (dromara/northstar) is a Java-based, open-source quantitative trading platform offering historical replay, strategy development, simulated trading, and live trading. Deployments of Northstar 9.1.1 and earlier ship with the H2 database console enabled, but the application's authentication interceptor is scoped only to /northstar/** paths. The /h2-console endpoint falls completely outside that scope, so it is reachable by anyone who can route a request to the server, and the embedded H2 database still uses the default sa account with an empty password.

Because the H2 Console allows arbitrary SQL execution against a live database connection, and H2 supports defining custom Java-backed functions via CREATE ALIAS (as well as remote script execution via RUNSCRIPT FROM), an attacker who reaches the console can go straight from "no credentials" to full command execution on the host. NVD scores this issue 9.8 (Critical) under CVSS 3.1 — the maximum practical severity for a network-exploitable, unauthenticated, zero-interaction flaw with complete impact on confidentiality, integrity, and availability. In plain terms: if /h2-console is reachable over the network, the host running Northstar should be considered fully compromised.

Technical Details

How It Works

Northstar's web layer applies its login/session check through an interceptor registered against the /northstar/** path pattern. The embedded H2 Console servlet, however, is mounted at /h2-console, which does not match that pattern — so requests to it skip the interceptor and reach H2 directly with no session or credential check at the application layer.

H2 itself still expects a database login, but Northstar leaves the embedded database on its out-of-the-box default: username sa with an empty password. An attacker can request /h2-console, get redirected to H2's own login page, and authenticate with sa / (empty) against the local database URL — no secrets need to be guessed or brute-forced.

Once inside the console, the attacker has a full SQL interface against the live database. H2 supports CREATE ALIAS, which lets a user register an arbitrary static Java method as a callable SQL function — including simple wrappers around Runtime.getRuntime().exec() — so the attacker can define a function like SHELLEXEC(cmd) and then invoke it (CALL SHELLEXEC('whoami')) to run OS commands directly. H2's RUNSCRIPT FROM 'http://...' capability offers an alternative path, pulling and executing a remote SQL script (which can itself contain a trigger or alias that shells out) from an attacker-controlled server. Either technique turns console access into full remote code execution on the host running Northstar.

Impact Assessment

Who Is At Risk

• Any Northstar deployment (9.1.1 or earlier) where the application's HTTP port is reachable from an untrusted network — including the public internet, a shared VPC, or any LAN segment the attacker can reach
• Deployments that rely solely on the application's own login screen for perimeter security, unaware that /h2-console bypasses it
• Trading infrastructure where this host also holds account configuration, API keys, or credentials for brokers/exchanges, since RCE on the host exposes everything else stored or reachable from it

Potential Attack Chains

1. Attacker scans or otherwise discovers a Northstar instance and requests /h2-console, finding it accessible without hitting the application's login redirect.
2. Attacker submits the H2 login form with sa and an empty password against the local database URL, obtaining an authenticated H2 Console session.
3. Attacker issues CREATE ALIAS to register a Java method that wraps Runtime.getRuntime().exec() (or uses RUNSCRIPT FROM to pull a malicious script from an attacker-controlled server).
4. Attacker calls the newly created alias/function with an arbitrary OS command, confirming code execution (e.g., whoami, id).
5. Attacker escalates from command execution to a full foothold: dropping a reverse shell or persistence mechanism, harvesting local secrets (trading API keys, broker credentials, environment variables), and pivoting further into the network.

Mitigation

Immediate Actions

• Disable the H2 Console in production entirely (do not expose a database admin console on a production web server). In Spring-based applications this is typically a spring.h2.console.enabled=false property or equivalent configuration flag — confirm the exact setting against the Northstar configuration files.
• If the console must remain enabled for development, restrict it to localhost/loopback only and never bind it to a network-reachable interface.
• Change the embedded H2 database credentials away from the sa / empty-password default, and set a strong password even for local-only access.
• Place the Northstar host behind a firewall or security group that blocks inbound access to the application port from untrusted networks until the console is confirmed disabled.
• Track the upstream dromara/northstar repository and release notes for a fix, since no patched version has been published as of this writing; apply it as soon as it becomes available.

Detection Opportunities

• Review web server / reverse proxy access logs for requests to /h2-console, /h2-console/login.do, or /h2-console/query.do — any hit from outside expected admin/dev IP ranges should be treated as a likely compromise attempt.
• Alert on outbound connections or child processes spawned by the Northstar Java process that don't match its normal behavior (e.g., shells, curl/wget, reverse-shell binaries), since post-exploitation here runs as the application's own process.
• Monitor for unexpected CREATE ALIAS statements or new H2 database objects if query-level auditing is available.
• Check for unfamiliar outbound requests to third-party hosts immediately following H2 Console activity, which would indicate a RUNSCRIPT FROM remote-script attack.

Defence-in-Depth

• Never expose database administration consoles (H2, phpMyAdmin, Adminer, etc.) on the same network path as the public application — segment them behind a separate, authenticated management plane.
• Apply least-privilege network rules so the Northstar host only accepts inbound traffic on the ports it actually needs to serve.
• Rotate any credentials (broker/exchange API keys, trading secrets) that may have been stored on or accessible from a Northstar host that was ever network-reachable with this configuration.
• Treat default credentials on any embedded or bundled service (databases, caches, admin panels) as a standing risk during deployment reviews, not just for H2.

Discovery & Disclosure

CVE-2026-88391 was published via NVD on 2026-10-05. A technical write-up and proof-of-concept demonstrating the exploitation chain was published on GitHub by user fangtang7; no formal discoverer credit, vendor advisory, or dedicated GHSA identifier for this specific CVE was found via public search as of this writing — treat that attribution as unconfirmed beyond the public write-up itself. There is no confirmed CISA Known Exploited Vulnerabilities (KEV) listing for this CVE, and no additional public proof-of-concept beyond the write-up referenced above has been confirmed as of publication.

References

• NVD — CVE-2026-88391
• Northstar H2 Console RCE — technical write-up and PoC (fangtang7/CVE)
• dromara/northstar — upstream repository
• OffSeq Threat Radar — CVE-2026-88391