Notepad++ Update-Hijacking: CVE-2025-15556, 8.9.2 Double Lock

Stand: 18. Februar 2026 – zuletzt aktualisiert

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. Der Beitrag gibt Maßnahmen für Unternehmen und konkrete Schritte. [News]

Mit Version 8.9.2 hat Notepad++ die Lücken geschlossen („Double Lock“, CVE-2025-15556 adressiert; zusätzlich CVE-2026-25926 behoben). Für Unternehmen bleibt relevant: Es handelt sich 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.

1. Update Februar 2026: Was ist neu?

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

Notepad++ hat mit Version 8.9.2 einen umfassenden Security-Fix ausgeliefert. [Release Notes] 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. [News]

Der Supply-Chain-Vorfall (Update-Hijacking) ist unter CVE-2025-15556 (CVSS 7.7) geführt. [CVE] 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. [Analyse] [Analyse]

Zusätzlich adressiert 8.9.2 eine eigenständige Schwachstelle (nicht Teil des Hijacking-Vorfalls): CVE-2026-25926 (CVSS 7.3, High). [CVE] 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. [News]

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). [News (älter)]

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.

2. 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). [News (älter)]

3. 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. [Bericht]

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. [Release Notes (älter)] [News]

4. 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. [Analyse]

4.1 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. [News (älter)]

4.2 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. [Release Notes (älter)]
• 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. [Release Notes] [News]
• Infra-Seite: Umzug der Website/Infra zu einem neuen Hosting-Provider mit stärkerer Security-Praxis. [News (älter)]

4.3 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.

[News]

4.4 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.).

5. 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.

6. 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:

1. Update kontrollieren (zentral statt Client-Internet):
   Wenn möglich, Notepad++ über Softwareverteilung/Paketmanagement aktualisieren (z. B. via Managed Installer), statt den Updater auf Clients frei ins Internet kommunizieren zu lassen.
2. Auf aktuellen Stand bringen:
   Notepad++ 8.9.2 (oder neuer) einsetzen und in Change-/Patch-Prozesse integrieren – inkl. Double Lock und WinGUp-Härtungen. Installer ausschließlich von notepad-plus-plus.org oder GitHub Releases beziehen. [Release Notes]
3. Egress-Kontrolle & Allowlisting:
   Definieren, welche Updater-Prozesse wohin kommunizieren dürfen. Abweichungen alarmieren (Proxy/SWG/EDR).
4. Detections für „Updater-Missbrauch“:
   Regel: Wenn gup.exe ungewöhnliche Child-Prozesse startet oder fremde Domains kontaktiert → Alert.
5. Forensik bei Verdacht:
   Betroffene Endpoints isolieren, Artefakte sichern, Signaturen/Hashes prüfen, ggf. Reimage (abhängig von Befund & Kritikalität).

7. 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.

PowerShell: schnelle Suche nach Process-Create-Events (Sysmon) und TEMP-Artefakten.

      # 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
    

Detection-Policy (YAML): vereinfachtes Muster für Allowlisting & Alerts.

      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.

8. Ü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.

9. FAQ

Bin ich betroffen, wenn wir Notepad++ nutzen?

Relevant ist weniger „ob genutzt“, sondern wie aktualisiert wird: Wenn Clients selbstständig per WinGUp updaten und kaum Egress-/Monitoring existiert, ist die Risikolage höher. Besonders kritisch sind Admin-Workstations und Geräte außerhalb zentraler Softwareverteilung.

Welche Zeiträume sind für Forensik/Log-Checks relevant?

Konservativ sollten Sie Logs ab Juni 2025 bis 02.12.2025 prüfen, wenn Notepad++/WinGUp in Ihrer Umgebung genutzt wurde. Hintergrund: Serverzugriff soll am 02.09.2025 beendet gewesen sein, aber Umleitungen waren durch verbleibende Zugangsdaten bis 02.12.2025 zumindest möglich.

Woran erkenne ich, ob manipulierte Updates installiert wurden?

Prüfen Sie Netzwerk- und Prozessdaten rund um gup.exe: ungewöhnliche Domains/Redirects, verdächtige TEMP-Artefakte, unerwartete Child-Prozesse sowie Code-Signaturen der Installer. [Analyse]

Reicht es, automatische Updates zu deaktivieren?

Kurzfristig kann das Risiko sinken. Nachhaltig ist es nur, wenn Sie einen kontrollierten Update-Prozess etablieren (Softwareverteilung, Freigaben, Verifikation) und Updater-Telemetrie sauber überwachen.

Welche Version ist empfohlen – und was ist mit dem signierten XML?

Nach aktuellem Stand Notepad++ 8.9.2 oder neuer. Ab 8.9.2 gilt das „Double Lock“-Design (Installer- und XML-Signaturprüfung), und weitere WinGUp-Härtungen (kein DLL-Sideloading, sichere SSL-Optionen, Zertifikatsbindung für Plugins) sind umgesetzt. In Unternehmen bleibt die wichtigste Maßnahme: Updates zentral verteilen und nicht dem freien Client-Internet überlassen. [News]