This is a master key left inside a side door that most buildings never open
CVE-2026-5189 is a hard-coded credential flaw in an internal Nexus Repository Manager database component affecting Sonatype Nexus Repository Manager 3.0.0 through 3.70.5. If an attacker can reach the OrientDB binary listener, they can authenticate with the embedded credential, gain read/write access to the internal database, and from there execute OS commands as the Nexus process user. The crucial catch is deployment reality: Sonatype says exploitation requires nexus.orient.binaryListenerEnabled=true, and that listener is *not enabled by default* in standalone installs.
In practice, this is not a blanket internet-RCE across all Nexus 3 servers. The vendor/CNA now publishes a CVSS v4 9.2 critical baseline, but that score overstates fleet-wide exposure because the vulnerable path only exists in explicitly enabled binary-listener deployments or legacy HA-C mode with nexus.clustered=true. That narrowing friction keeps this out of CRITICAL for most enterprises, but it still lands at HIGH because Nexus sits in the software supply chain and compromise can poison builds, secrets, and artifacts.
4 steps from start to impact.
Find a reachable Nexus host and binary listener
nmap or equivalent network scanning. The web UI alone is not enough; the exploitation path depends on direct network reachability to the database listener rather than normal HTTP auth flows.- Target runs Nexus Repository Manager 3.0.0 through 3.70.5
- Attacker has network reachability to the OrientDB binary listener
- The listener is enabled via non-default config or legacy HA-C mode
- Standalone Nexus deployments do not enable the listener by default
- Current supported HA architecture does not auto-enable this listener
- Many enterprises bind backend service ports to internal networks only
Log in with the embedded credential
- Hard-coded credential remains present in the vulnerable build
- Binary protocol access is not filtered by firewall or local ACLs
- There was no public proof-of-concept located in the reviewed sources
- Binary protocol exploitation is less commodity than a simple HTTP request
Abuse internal DB access for code execution
- Successful database access through the vulnerable component
- Attacker can perform the vendor-described follow-on actions inside the internal database context
- Execution lands as the Nexus process user, not automatically root or SYSTEM
- Containerized or hardened deployments may constrain host-level post-exploitation
Monetize the repo server foothold
- Nexus instance is integrated into CI/CD, artifact promotion, or internal package distribution
- Attacker maintains enough access to modify or exfiltrate repository-controlled content
- Artifact signing, immutable promotion controls, and downstream verification can reduce blast radius
- Some organizations use Nexus only as a cache, limiting direct write impact
The supporting signals.
| Baseline reality check | Despite the prompt stating there is no vendor score, NVD now shows a Sonatype CNA CVSS v4 score of 9.2 / CRITICAL for this CVE, published on 2026-04-15 and visible in NVD's current record. |
|---|---|
| In-the-wild status | No public exploitation evidence located in the reviewed authoritative sources, and the CVE is not listed in CISA KEV as of the current catalog review. |
| Public PoC status | No public GitHub PoC or detailed exploit write-up found in reviewed searches. That lowers opportunistic abuse, but the advisory is specific enough that private exploit development is plausible. |
| EPSS | 0.00036 (~0.036% 30-day probability, from the user-supplied intel), which is very low and consistent with the narrow exposure requirement. |
| KEV status | Not KEV-listed; no CISA due date applies. |
| CVSS vector | Sonatype CNA vector in NVD: CVSS:4.0/AV:N/AC:L/AT:P/PR:N/UI:N/VC:H/VI:H/VA:H/SC:N/SI:N/SA:N. The key nuance is AT:P: exploitation depends on a prerequisite deployment condition, namely the enabled binary listener. |
| Affected scope | Affected versions are 3.0.0 through 3.70.5, but only when the OrientDB binary listener is enabled. Sonatype explicitly says default standalone deployments and the current supported HA architecture are not affected. |
| Fixed version | Fixed in 3.71.0. Important operational footnote: 3.71.0 and later do not support OrientDB, so some estates face a migration step rather than a trivial in-place patch. |
| Exposure reality | Nexus is widely deployed and strategically important — Sonatype says it is trusted by millions, including 70% of the Fortune 100 — but the *specific vulnerable service* should be a minority exposure because it is non-default and tied to legacy HA-C or explicit opt-in. That exposure judgment is an inference from vendor deployment guidance. |
| Disclosure and credit | Disclosed 2026-04-15 and credited by Sonatype to Shreyas Chavhan via the vendor bug bounty program. |
noisgate verdict.
The decisive factor is that the exploit path only exists when a non-default internal database listener is reachable, which sharply narrows the exposed population compared with a typical unauthenticated network RCE. It still stays in HIGH because a Nexus server is a supply-chain control point, so successful compromise can ripple far beyond one host.
Why this verdict
- Major downward pressure: non-default prerequisite — the vulnerable OrientDB binary listener is not enabled in default standalone deployments, so this is not a broad all-host Nexus 3 emergency.
- Additional downward pressure: legacy architecture bias — Sonatype says legacy HA-C mode with
nexus.clustered=trueis affected, while the current supported HA architecture is not. That implies a meaningful chunk of modern enterprise deployments are outside the blast radius. - Upward pressure: supply-chain position — if exploited, the target is not a random app server; it is the artifact repository that feeds builds and deployments. Even execution as the Nexus process user can have outsized organizational impact.
Why not higher?
This misses CRITICAL because exploitation depends on a specific deployment state that many organizations simply do not have: the binary listener must be enabled and reachable. There is also no reviewed evidence of active exploitation, no KEV listing, and no public commodity PoC located, all of which reduce immediate fleet-wide emergency pressure.
Why not lower?
This stays above MEDIUM because the technical outcome is still severe: unauthenticated network access can become database compromise and OS command execution. And unlike a low-value internal service, Nexus often sits on the software supply chain path, so one successful hit can cascade into artifact tampering, secret exposure, and downstream compromise.
What to do — in priority order.
- Disable the binary listener — Remove
nexus.orient.binaryListenerEnabled=trueanywhere it is not strictly required. This directly breaks the exploit chain and, for a HIGH verdict, should be completed within 30 days. - Block backend listener reachability — Restrict the OrientDB listener to localhost or a tightly controlled management segment using host firewall and network ACLs; do not rely on HTTP-layer controls. Treat this as the fastest compensating control and deploy it within 30 days.
- Eliminate legacy HA-C exposure — If you still run legacy HA-C with
nexus.clustered=true, prioritize moving off that architecture because Sonatype explicitly identifies it as affected. For this HIGH verdict, put that migration path in motion within 30 days even if full remediation takes longer. - Increase host telemetry on Nexus — Ensure EDR, process creation logging, and repository audit retention are enabled on Nexus servers so you can catch command execution and repository tampering if someone reaches the host before patching. Deploy this coverage within 30 days on all exposed instances.
- A WAF does not meaningfully help if the attacker uses the non-HTTP OrientDB binary listener rather than the web UI.
- MFA on the Nexus UI is irrelevant to the hard-coded backend credential path because the exploit does not depend on interactive web login.
- Rotating normal Nexus user passwords or tokens does not remove the embedded vulnerable credential in the affected component.
Crowdsourced verification payload.
Run this on the target Nexus host or from an admin workstation with filesystem access to the Nexus install and data directories. Invoke it as python3 check_cve_2026_5189.py --app-dir /opt/sonatype/nexus --data-dir /nexus-data (Windows example: py check_cve_2026_5189.py --app-dir C:\Sonatype\Nexus --data-dir C:\nexus-data). No root/admin is required if you can read the Nexus installation and nexus.properties file.
#!/usr/bin/env python3
# Check Sonatype Nexus Repository Manager for CVE-2026-5189 exposure
# Exit codes: 0=PATCHED, 1=VULNERABLE, 2=UNKNOWN
import argparse
import os
import re
import sys
from pathlib import Path
VERSION_RE = re.compile(r'nexus-base-(\d+\.\d+\.\d+(?:-\d+)?)\.jar$')
PROPS_RE = re.compile(r'^\s*([^#][^=\s]+)\s*=\s*(.*?)\s*$')
def parse_args():
p = argparse.ArgumentParser(description='Check CVE-2026-5189 exposure for Sonatype Nexus Repository Manager')
p.add_argument('--app-dir', required=True, help='Nexus application/install directory')
p.add_argument('--data-dir', required=True, help='Nexus data directory containing etc/nexus.properties')
return p.parse_args()
def parse_version(ver):
# Supports formats like 3.70.5 or 3.70.5-01
m = re.match(r'^(\d+)\.(\d+)\.(\d+)(?:-(\d+))?$', ver)
if not m:
return None
major, minor, patch, build = m.groups()
return (int(major), int(minor), int(patch), int(build or 0))
def version_leq(v1, v2):
return v1 <= v2
def version_gte(v1, v2):
return v1 >= v2
def find_version(app_dir: Path):
candidates = []
for root, _, files in os.walk(app_dir):
for name in files:
m = VERSION_RE.search(name)
if m:
ver = m.group(1)
pv = parse_version(ver)
if pv:
candidates.append((pv, ver, str(Path(root) / name)))
if not candidates:
return None, None
candidates.sort(reverse=True)
return candidates[0][1], candidates[0][2]
def load_properties(props_path: Path):
props = {}
if not props_path.exists():
return None
try:
with props_path.open('r', encoding='utf-8', errors='ignore') as f:
for line in f:
m = PROPS_RE.match(line)
if m:
k, v = m.groups()
props[k.strip()] = v.strip()
except Exception:
return None
return props
def truthy(val):
return str(val).strip().lower() in ('true', '1', 'yes', 'on')
def main():
args = parse_args()
app_dir = Path(args.app_dir)
data_dir = Path(args.data_dir)
props_path = data_dir / 'etc' / 'nexus.properties'
version_str, version_src = find_version(app_dir)
props = load_properties(props_path)
if version_str is None:
print('UNKNOWN: could not determine Nexus version from app directory')
sys.exit(2)
pv = parse_version(version_str)
if pv is None:
print(f'UNKNOWN: unrecognized version format: {version_str}')
sys.exit(2)
vulnerable_max = parse_version('3.70.5')
fixed_min = parse_version('3.71.0')
if props is None:
print(f'UNKNOWN: could not read properties file: {props_path}')
sys.exit(2)
binary_listener = truthy(props.get('nexus.orient.binaryListenerEnabled', 'false'))
legacy_clustered = truthy(props.get('nexus.clustered', 'false'))
# Advisory says default standalone/current supported HA are not affected.
# Vulnerable if version <= 3.70.5 and vulnerable listener path is enabled.
if version_leq(pv, vulnerable_max) and (binary_listener or legacy_clustered):
reason = []
if binary_listener:
reason.append('nexus.orient.binaryListenerEnabled=true')
if legacy_clustered:
reason.append('nexus.clustered=true (legacy HA-C indicator)')
print(f'VULNERABLE: Nexus {version_str} at {version_src}; trigger(s): ' + ', '.join(reason))
sys.exit(1)
if version_gte(pv, fixed_min):
print(f'PATCHED: Nexus {version_str} at {version_src} is at or above 3.71.0')
sys.exit(0)
# Older vulnerable-version software but config does not expose the vulnerable path.
print(f'PATCHED: Nexus {version_str} is in affected version range, but vulnerable listener settings were not found in {props_path}')
sys.exit(0)
if __name__ == '__main__':
main()
If you remember one thing.
nexus.properties for nexus.orient.binaryListenerEnabled=true or legacy HA-C indicators; for this HIGH verdict, the noisgate mitigation SLA is within 30 days to disable or firewall that listener wherever present, and the noisgate remediation SLA is within 180 days to move affected systems to 3.71.0+ with the required database/runtime migration work planned and executed.Sources
What defenders are saying.
Crowdsourced verification outputs.
Results submitted by users who ran the verification payload against their environment.