← Back to Feed CACHED · 2026-05-17 09:42:19 · cache_key CVE-2025-29912
CVE-2026-5189 · CWE-798 · Disclosed 2026-04-15

CWE-798: Use of Hard-coded Credentials in Sonatype Nexus Repository Manager versions 3

ASSESSED — NOISGATE V0.5
Vendor
Reassessed
Verdict:
01 · The Real Story

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.

"Dangerous on the hosts that expose it, but the vulnerable listener is non-default and absent from most Nexus 3 deployments."
02 · The Attack Path

4 steps from start to impact.

STEP 01

Find a reachable Nexus host and binary listener

An attacker first identifies Nexus Repository Manager and checks whether the internal OrientDB binary listener is exposed, typically with 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.
Conditions required:
  • 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
Where this breaks in practice:
  • 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
Detection/coverage: External ASM tools will usually see the HTTP service, but may miss this CVE unless they also test the OrientDB listener path. Host config review is more reliable than perimeter-only scanning.
STEP 02

Log in with the embedded credential

Once the binary listener is reachable, the attacker uses a custom exploit, an OrientDB client, or a raw protocol implementation to authenticate with the hard-coded credential. This is the weaponization step that turns a configuration mistake into unauthenticated access to Nexus' internal data store.
Conditions required:
  • Hard-coded credential remains present in the vulnerable build
  • Binary protocol access is not filtered by firewall or local ACLs
Where this breaks in practice:
  • There was no public proof-of-concept located in the reviewed sources
  • Binary protocol exploitation is less commodity than a simple HTTP request
Detection/coverage: NDR or firewall logs may show unexpected connections to the OrientDB listener. Most web-focused WAF telemetry will see nothing.
STEP 03

Abuse internal DB access for code execution

Sonatype states that database compromise can be escalated to arbitrary OS command execution as the Nexus process user. That gives the attacker code execution on a repository server that often holds credentials, package metadata, CI/CD trust relationships, and artifact distribution authority.
Conditions required:
  • Successful database access through the vulnerable component
  • Attacker can perform the vendor-described follow-on actions inside the internal database context
Where this breaks in practice:
  • Execution lands as the Nexus process user, not automatically root or SYSTEM
  • Containerized or hardened deployments may constrain host-level post-exploitation
Detection/coverage: EDR can catch child-process creation, shell launches, and anomalous Nexus user behavior on the host. Database-level abuse prior to process execution may be harder to see.
STEP 04

Monetize the repo server foothold

From the Nexus host, an attacker can steal stored secrets, alter hosted artifacts, tamper with cached dependencies, or pivot into build infrastructure. The software supply-chain role of Nexus is the real amplifier: even one compromised server can affect many downstream developers, runners, and production deployments.
Conditions required:
  • Nexus instance is integrated into CI/CD, artifact promotion, or internal package distribution
  • Attacker maintains enough access to modify or exfiltrate repository-controlled content
Where this breaks in practice:
  • Artifact signing, immutable promotion controls, and downstream verification can reduce blast radius
  • Some organizations use Nexus only as a cache, limiting direct write impact
Detection/coverage: Repository audit logs, unexpected artifact checksum drift, unusual token use, and CI pipeline failures are the best late-stage signals. Traditional vuln scanners will not detect post-compromise tampering.
03 · Intelligence Metadata

The supporting signals.

Baseline reality checkDespite 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 statusNo 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 statusNo 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.
EPSS0.00036 (~0.036% 30-day probability, from the user-supplied intel), which is very low and consistent with the narrow exposure requirement.
KEV statusNot KEV-listed; no CISA due date applies.
CVSS vectorSonatype 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 scopeAffected 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 versionFixed 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 realityNexus 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 creditDisclosed 2026-04-15 and credited by Sonatype to Shreyas Chavhan via the vendor bug bounty program.
04 · The Call

noisgate verdict.

Final Verdict
DOWNGRADED to HIGH (7.8/10)

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.

HIGH Affected version range and fixed version
HIGH Non-default listener requirement and legacy HA-C exposure condition
MEDIUM Real-world exposed population estimate across enterprise deployments

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=true is 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.

05 · Compensating Control

What to do — in priority order.

  1. Disable the binary listener — Remove nexus.orient.binaryListenerEnabled=true anywhere it is not strictly required. This directly breaks the exploit chain and, for a HIGH verdict, should be completed within 30 days.
  2. 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.
  3. 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.
  4. 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.
What doesn't work
  • 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.
06 · Verification

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.

noisgate-verify.py
PYTHONREAD-ONLYSAFE
#!/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()
07 · Bottom Line

If you remember one thing.

TL;DR
Monday morning, do not treat this as a universal Nexus fire drill; treat it as a targeted hunt for legacy or explicitly enabled OrientDB listener exposure. Inventory every Nexus 3 instance, flag anything on 3.0.0–3.70.5, and immediately check 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

  1. Sonatype advisory for CVE-2026-5189
  2. NVD record for CVE-2026-5189
  3. Sonatype Nexus Repository 3.71.0 release notes
  4. Sonatype upgrade guidance for 3.71.0 and beyond
  5. CISA Known Exploited Vulnerabilities catalog
  6. FIRST EPSS overview
  7. Sonatype Nexus Repository product page
  8. MITRE CWE-798 definition
Peer Review

What defenders are saying.

Submit a review attribution: handle + country only
0 flags selected · stored anonymously
Validation Results

Crowdsourced verification outputs.

Results submitted by users who ran the verification payload against their environment.