Sonatype Nexus Repository Schwachstellen: BSI warnt vor Lücken

Das BSI führt seit dem 16. Oktober 2026 eine Meldung zu Sonatype Nexus Repository Schwachstellen im Warn- und Informationsdienst – Kennung WID-SEC-2026-4004, Einstufung „hoch". Betroffen sind Betreiber des Artifact-Repository-Managers, also in der Regel Unternehmen und öffentliche Stellen, die Build-Artefakte, Container-Images und interne Pakete über die Plattform verteilen. Der Meldungstext nennt mehrere Angriffsziele gleichzeitig: das Umgehen von Sicherheitsvorkehrungen, die Offenlegung von Informationen, die Ausführung beliebigen Programmcodes, das Erlangen von Administratorrechten sowie Cross-Site Scripting.

Kennung, Datum und die Einstufung „hoch" sind in der Liste der aktuellen technischen Sicherheitshinweise geführt. Eine CVE-Nummer, eine Versionsliste oder ein Verweis auf konkrete Patches geht aus dem öffentlich zugänglichen Meldungstext dagegen nicht hervor.

Sonatype Nexus Repository Schwachstellen: Was das Advisory belegt – und was offen bleibt

Die Meldung beschreibt Auswirkungen, nicht Ursachen. Welche CVE-IDs das Advisory auflistet, welche Versionen als betroffen gelten und ob Fixes benannt werden, bleibt offen – die Detailseite zum Advisory ließ sich beim Abruf nicht auslesen. Für Admins ist das der entscheidende Vorbehalt: „hoch" signalisiert Handlungsbedarf, ersetzt aber keine Versionsprüfung. Wer die Meldung als Patch-Auftrag liest, muss selbst ermitteln, welche Installation betroffen ist.

Auffällig ist die Bandbreite der genannten Kategorien. Umgehung von Schutzmechanismen, Codeausführung, Administratorrechte und XSS in einer Meldung deuten auf mehrere separate Probleme statt auf einen einzelnen Bug. Das passt zur Rolle des Systems: Ein Repository-Manager verwaltet Zugangsdaten, verteilt Fremdcode an Build-Pipelines und ist häufig aus Entwicklernetzen erreichbar. Genau diese Position macht ihn interessant — kompromittiert man ihn, liest man an vielen Stellen der Lieferkette mit.

Welche Nexus-Lücken unabhängig dokumentiert sind

Getrennt vom BSI-Meldungstext sind mehrere Schwachstellen im Nexus Repository Manager in Herstellerdokumentation und NVD erfasst. CVE-2026-3199 wird mit CVSS 9.4 als authentifizierte Remote-Code-Execution geführt: Ein Angreifer mit bestimmten Berechtigungen kann demnach beliebigen Code ausführen und potenziell den Server samt Inhalten kompromittieren. CVE-2026-5189 liegt bei CVSS 9.2 und ist als Hardcoded Credential in einer internen Datenbankkomponente beschrieben.

Beide Schwachstellen betreffen nach Herstellerangaben ältere OSS-Deployments und sind in neueren CE- und Pro-Releases behoben. Ob die BSI-Meldung vom 16.10.2026 dieselben Lücken adressiert oder eine spätere Patch-Generation, ist aus den verfügbaren Quellen nicht ableitbar — die Herstellerkommunikation zu beiden CVEs datiert auf den 26.05.2026, also rund fünf Monate vor der BSI-Meldung.

CVE-2026-5189: fest verdrahtete Zugangsdaten und die Rolle von OrientDB

Beim unangenehmsten Szenario kommt ein Angreifer ohne Anmeldung aus. Für CVE-2026-5189 beschreibt das Hersteller-Advisory einen unauthentifizierten Angreifer mit Netzwerkzugriff, der unautorisiert auf die interne Datenbank zugreift und Kommandos auf dem Hostsystem ausführt. Die Ausnutzung setzt allerdings eine OrientDB-basierte Installation voraus; der betreffende Passus liegt nur unvollständig vor, weshalb die Einordnung hier bewusst vorsichtig bleibt. Installationen mit PostgreSQL-Backend oder die Cloud-Variante fallen nicht in dieses Muster.

Der CVSS-Wert von 9.2 bildet das abstrakt ab, sagt aber nichts über die eigene Exposition. Entscheidend sind zwei Fragen: Ist die Instanz aus dem Internet oder aus wenig vertrauenswürdigen Netzen erreichbar? Und läuft im Backend noch OrientDB? Erst beides zusammen ergibt ein reales Risiko — ohne Netzwerkzugriff bleibt die Lücke theoretisch.

Ein zweites Muster betrifft die Anmeldung selbst. CVE-2026-3329 ist als Authentication-Handling-Problem mit Datum 11.06.2026 dokumentiert; laut Kurzbeschreibung können remote unauthentifizierte Angreifer Credential-Guessing gegen Benutzerkonten führen und bei Erfolg unautorisierten Zugriff erlangen. Diese Einordnung stammt aus der Kurzfassung des Eintrags, nicht aus einem vollständig geprüften Dokument, und ist entsprechend als Hinweis zu behandeln. Im NVD ist zudem CVE-2026-14646 mit CWE-918 (Server-Side Request Forgery) für die Produktkonfiguration erfasst — auch hier nur auf Snippet-Ebene, nicht im Volltext verifiziert.

Patch-Lage: Upgrade, Wechsel von OSS zu CE oder Pro, OrientDB-Migration

Die Herstellerempfehlungen sind konkret und in drei Stufen gestaffelt. Erstens: aktuelle Version prüfen und zeitnah upgraden. Zweitens: Wer Nexus Repository OSS betreibt, soll auf CE oder Pro wechseln, weil in neueren Releases dieser Linien die beiden kritischen Lücken behoben sind. Drittens: OrientDB-basierte Deployments sollen auf Nexus Repository Cloud oder PostgreSQL migriert werden — das entfernt die Voraussetzung für CVE-2026-5189 strukturell, unabhängig vom Patchstand.

Zusätzlich ist eine Härtung gegen Stored XSS angekündigt: Ab dem Self-Hosted-Release 3.95.0 dürfen Blob-Store-Namen keine HTML-Sonderzeichen mehr enthalten. Dieses Release war laut Release-Notes für August 2026 erwartet; ob und in welcher Form es tatsächlich erschienen ist, ist zum Redaktionszeitpunkt nicht verifiziert. Für die Cloud-Variante existiert eine separate Fix-Übersicht mit Stand 21.05.2026.

Was Admins jetzt prüfen sollten

Die drei Schritte sind unabhängig von der offenen CVE-Zuordnung des BSI-Advisories sinnvoll, weil sie den Angriffsflächen-Kern adressieren: Version und Patchstand ermitteln, Erreichbarkeit der Instanz einschränken, veraltete Backends ablösen. Wer noch OSS mit OrientDB betreibt, hat den dringendsten Handlungsbedarf — dort greifen beide dokumentierten kritischen Lücken zusammen.

Zur Einordnung des Bedrohungsbilds: In den verfügbaren Quellen finden sich keine Hinweise auf aktive Ausnutzung, keinen öffentlich dokumentierten Exploit-Code und keine Angriffsbeobachtungen zu diesen CVEs. Die Einstufung „hoch" durch das BSI und die CVSS-Werte von 9.4 und 9.2 beschreiben das Potenzial, nicht den Ist-Zustand. Die XSS-Kategorie aus dem Meldungstext bleibt zudem unspezifiziert — ob Stored oder Reflected, ist offen. Bis zur Klärung gilt: internes Advisory lesen, Exposition prüfen, patchen.

Quellen