Notepad++ Update-Hijacking: CVE-2025-15556 und aktuelle Patches

Notepad++ steht erneut im Fokus der IT-Security-Community: Der Maintainer hat bestätigt, dass Angreifer den Update-Mechanismus gezielt missbraucht haben, um Update-Traffic umzuleiten und kompromittierte Updates an ausgewählte Nutzer auszuliefern. Mit Version 8.9.2 wurde der Update-Prozess durch ein „Double Lock“-Design und weitere Härtungen abgesichert; der Supply-Chain-Vorfall ist als CVE-2025-15556 geführt. Für den aktuellen Patch-Stand sollten Unternehmen inzwischen 8.9.6.1 oder neuer einplanen. Der Beitrag gibt Maßnahmen für Unternehmen und konkrete Schritte.

Mit Version 8.9.2 hat Notepad++ die Update-Kette gehärtet („Double Lock“, CVE-2025-15556 adressiert; zusätzlich CVE-2026-25926 behoben). Seit 8.9.6.1 sind weitere Schwachstellen in XML-Konfigurationsdateien behoben. Für Unternehmen bleibt relevant: Es handelt sich beim ursprünglichen Vorfall um einen Supply-Chain-Angriffsvektor – selbst wenn die Anwendung an sich nicht „klassisch“ verwundbar ist, kann die Update-Infrastruktur kompromittiert werden, mit potenziell hohem Impact.

Update 2026: Was ist neu?

Update 28. Mai 2026: Notepad++ 8.9.6.1 & XML-Schwachstellen

Notepad++ hat mit Version 8.9.6.1 drei weitere Schwachstellen geschlossen: CVE-2026-48778 in config.xml, CVE-2026-48800 in shortcuts.xml und CVE-2026-48770 im Umgang mit fehlerhaften COPYDATASTRUCT-Daten. Die beiden XML-Themen sind kein Update-Infrastruktur-Hijacking, aber für Unternehmen mit Notepad++ auf Admin-, Entwickler- oder Helpdesk-Clients relevant.

Update 18. Februar 2026: Notepad++ 8.9.2 & neue CVEs

Notepad++ hat mit Version 8.9.2 einen umfassenden Security-Fix ausgeliefert. Im Zentrum steht ein von Maintainer Don Ho so bezeichnetes „Double Lock“-Design: Der Update-Prozess soll „robust und praktisch nicht ausnutzbar“ sein – durch Verifikation des signierten Installers (bereits ab 8.8.9) und die in 8.9.2 eingeführte Verifikation des signierten XML, das der Update-Server unter notepad-plus-plus[.]org zurückliefert.

Der Supply-Chain-Vorfall (Update-Hijacking) ist unter CVE-2025-15556 (CVSS 7.7) geführt. Die über manipulierten Update-Traffic ausgelieferte Malware wurde von Rapid7 und Kaspersky als Backdoor „Chrysalis“ identifiziert; die Attribution weist auf die China-nexus APT-Gruppe Lotus Panda hin.

Zusätzlich adressiert 8.9.2 eine eigenständige Schwachstelle (nicht Teil des Hijacking-Vorfalls): CVE-2026-25926 (CVSS 7.3, High). Es handelt sich um eine Unsafe-Search-Path-Lücke (CWE-426): Windows Explorer wurde ohne absoluten Pfad gestartet, was unter bestimmten Bedingungen die Ausführung einer manipulierten explorer.exe und damit Arbitrary Code Execution im Kontext der Anwendung ermöglichen kann.

Die Einordnung des Angriffs bleibt für Unternehmen zentral: Es handelt sich um einen infrastruktur-level compromise – kompromittierte Infrastruktur auf Hosting-/Provider-Ebene statt einer einzelnen App-Schwachstelle – mit selektiver Umleitung von Update-Traffic (gezielt gegen bestimmte Nutzer/Organisationen).

Untersuchungen deuten zudem darauf hin, dass die Angreifer gezielt nach Notepad++ suchten (und nicht breit nach anderen Projekten/Artefakten). Das unterstützt das Bild: Low Volume, High Impact – wenige Ziele, aber potenziell gravierende Folgen.

Timeline: Juni–Dez 2025 (Forensik-Zeiträume)

Für Betroffenheitsprüfungen (Logs/EDR/Proxy) hilft eine klare Zeitachse. Laut aktuellem Stand begann die Aktivität bereits im Juni 2025. Zusätzlich sind zwei Stichtage wichtig: 02.09.2025 (Serverzugriff verloren) und 02.12.2025 (Credentials/Services abgesichert).

Ausgangslage: Was ist passiert?

Der integrierte Updater von Notepad++ (WinGUp / gup.exe) hat in dokumentierten Fällen kompromittierte Update-Pakete bezogen. Die Kerndynamik: Update-Traffic wurde auf maliziöse Server umgebogen, sodass statt eines legitimen Installers ein anderes Binary ausgeliefert wurde.

Notepad++ reagierte mit Version 8.8.9 (zusätzliche Prüfungen für Installer-Signatur) und mit 8.9.2 durch das „Double Lock“-Design sowie weitere WinGUp-Härtungen – der Update-Prozess ist damit deutlich abgesichert.

Wie WinGUp (gup.exe) funktioniert – und wo der Angriff ansetzt

Notepad++ nutzt einen eigenen Updater namens WinGUp. Der Ablauf ist (vereinfacht) typischerweise: gup.exe fragt eine Update-URL ab, erhält eine Manifest-/XML-Antwort (z. B. gup.xml) und lädt anschließend den referenzierten Installer herunter, speichert ihn im %TEMP%-Ordner und führt ihn aus.

Kurz erklärt: Update-Flow

1. gup.exe fragt eine Update-URL an.
2. Der Server liefert ein Manifest (XML) mit einer Download-Location.
3. gup.exe lädt den Installer herunter.
4. Der Installer wird ausgeführt (häufig aus %TEMP%).

Angreifer, die diesen Pfad intercepten oder umleiten können (z. B. via kompromittierter Infrastruktur, DNS/Hosting/Credentials), können die Download-Location auf einen anderen Host zeigen lassen. Genau das macht Updater zu einem attraktiven Vektor.

Was sich technisch geändert hat (8.8.9 & 8.9.2)

In der Reaktion wurden mehrere Schutzmaßnahmen umgesetzt – mit Version 8.9.2 ist das „Double Lock“-Design vollständig aktiv:

• Installer-Verifikation: WinGUp/Notepad++ prüft ab 8.8.9 Zertifikate/Signaturen des von GitHub heruntergeladenen Installers.
• Signiertes Update-Manifest (XML): Ab 8.9.2 wird das vom Update-Server (notepad-plus-plus[.]org) zurückgelieferte XML signiert und zusätzlich verifiziert – damit ist die doppelte Absicherung (Installer + Manifest) aktiv.
• Infra-Seite: Umzug der Website/Infra zu einem neuen Hosting-Provider mit stärkerer Security-Praxis.

Technische Hardening-Maßnahmen in WinGUp (8.9.2)

In 8.9.2 wurden weitere sicherheitsrelevante Änderungen am Auto-Updater WinGUp vorgenommen:

• Entfernung von libcurl.dll: Das DLL wird nicht mehr mitgeliefert – damit entfällt das DLL-Sideloading-Risiko.
• Entfernung unsicherer cURL-SSL-Optionen: CURLSSLOPT_ALLOW_BEAST und CURLSSLOPT_NO_REVOKE wurden entfernt.
• Plugin-Management: Ausführung nur noch für Programme, die mit dem gleichen Zertifikat wie WinGUp signiert sind.

Visualisierung: Angriff auf die Update-Kette

Aus Angreiferperspektive ist der Updater ein effizienter Einstiegspunkt: Ein „offizielles Update“ wirkt legitim, wird häufig ohne große Skepsis ausgeführt und landet nicht immer in den gleichen Kontrollmechanismen wie produktive Software-Releases.

Wichtig: Selbst bei gezielten Angriffen ist die Auswirkung potenziell hoch, weil kompromittierte Endpoints wiederum Zugang zu weiteren Systemen ermöglichen können (Credential Theft, Lateral Movement, etc.). Vereinfacht: Update-Anfragen von gup.exe werden umgeleitet – das Opfer lädt ein anderes Binary.

Bin ich betroffen? Pragmatic Checks

Unternehmen sollten die Betroffenheit nicht „gefühlt“ beurteilen, sondern pragmatisch prüfen: Welche Geräte nutzen Notepad++? Wer hat Admin-/Dev-Tools? Und: Wurde im relevanten Zeitraum über WinGUp geupdatet?

• Asset-/Software-Inventar: Notepad++-Installationen (inkl. Version) erfassen, besonders auf Admin-Workstations.
• Update-Pfad klären: Wird Notepad++ per Softwareverteilung gepatcht oder „wild“ per Updater?
• Telemetry: EDR/SIEM/Proxy-Logs nach gup.exe und auffälligen Redirects/Domains durchsuchen.
• File-Checks: Installer/Artefakte im %TEMP%-Kontext und Code-Signaturen/Hashes prüfen.
• Zeitraum konservativ wählen: Wenn Sie nicht sicher sind, ob Updates bezogen wurden, prüfen Sie Logs ab Juni 2025 bis 02.12.2025.

Sofortmaßnahmen & Hardening für Unternehmen

Wenn Notepad++ in Ihrer Umgebung genutzt wird, empfehlen sich die folgenden Schritte – bewusst pragmatisch, damit sie auch in kleinen Teams umsetzbar bleiben:

IOC-Checks: PowerShell & Detection-Policy

Die folgenden Snippets sind bewusst einfach gehalten und sollen zeigen, wie Sie typische Spuren rund um gup.exe pragmatisch prüfen können. Passen Sie sie an Ihre Logging-/EDR-Landschaft an.

# Sysmon Event ID 1 (Process Create): Suchen nach gup.exe
Get-WinEvent -FilterHashtable @{
  LogName = 'Microsoft-Windows-Sysmon/Operational'
  ID      = 1
} -ErrorAction SilentlyContinue |
  Where-Object { $_.Message -like '*\gup.exe*' } |
  Select-Object TimeCreated, Message

# Verdächtige Dateien im TEMP-Verzeichnis (Beispielnamen; anpassen!)
Get-ChildItem -Path $env:TEMP -Recurse -Include update.exe, AutoUpdater.exe -ErrorAction SilentlyContinue |
  Select-Object FullName, Length, LastWriteTime

notepadpp-updater:
  processName: "gup.exe"

  allowedDomains:
    - "notepad-plus-plus.org"
    - "github.com"
    - "release-assets.githubusercontent.com"

  alertOnOtherDomains: true

  suspiciousTempFiles:
    - "update.exe"
    - "AutoUpdater.exe"

  suspiciousChildProcesses:
    # Beispiele: je nach Umgebung anpassen
    - "powershell.exe"
    - "cmd.exe"
    - "rundll32.exe"

Tipp: Solche Checks sind am wirksamsten, wenn Sie sie als wiederverwendbare Detection-Regeln (SIEM/EDR) etablieren und nicht nur ad hoc ausführen.

Übersichten: Versionen, Risiken, Lessons Learned

Die folgende Übersicht hilft dabei, Notepad++-Versionen grob einzuordnen und den Handlungsbedarf zu strukturieren.

Die wichtigste „Meta-Lesson“: Update-Infrastruktur ist eine kritische Supply-Chain-Komponente. Selbst wenn ein Projekt sauber entwickelt ist, können Hosting, interne Dienste oder Credentials kompromittiert werden. Behandeln Sie Updater daher wie produktive, sicherheitskritische Komponenten.

FAQ