
Wprowadzenie do problemu / definicja luki
Zespół Notepad++ opublikował wersję 8.8.9, która uszczelnia mechanizm aktualizacji WinGUp po incydentach, w których aktualizator pobierał zamiast legalnych instalatorów — złośliwe pliki wykonywalne. Twórcy opisują zjawisko jako „hijacking ruchu” WinGUp, skutkujący przekierowaniem do fałszywych serwerów aktualizacji. W 8.8.9 wprowadzono weryfikację podpisu i certyfikatu pobieranego instalatora; w razie niepowodzenia aktualizacja jest przerywana.
O incydentach poinformowały media branżowe — m.in. BleepingComputer i heise — wskazując, iż aktualizator potrafił pobrać i uruchomić podstawiony plik EXE zamiast nowej wersji edytora.
W skrócie
- Co się stało? Część żądań aktualizatora WinGUp była „porywana”, co prowadziło do pobrania złośliwego instalatora zamiast prawidłowego pakietu Notepad++.
- Co naprawiono? Od Notepad++ 8.8.9 WinGUp weryfikuje podpis cyfrowy i łańcuch certyfikatu pobranego instalatora; brak zgodności = przerwanie aktualizacji.
- Dodatkowe utwardzenie: Już w 8.8.8 wymuszono GitHub.com jako jedyne źródło pobrań przez WinGUp, a 8.8.9 poszła dalej z walidacją podpisów.
- Status śledztwa: Twórcy przez cały czas ustalają dokładny wektor przechwycenia ruchu.
Kontekst / historia / powiązania
W 2025 r. Notepad++ mierzył się już z innymi kwestiami bezpieczeństwa (np. CVE-2025-49144 w instalatorze oraz zmiany wokół certyfikatu podpisującego), a także z modyfikacjami aktualizatora (aktualizacje cURL w WinGUp). To pokazuje, iż łańcuch aktualizacji narzędzia jest aktywnie wzmacniany od kilku wydań.
Równolegle media (The Register, heise) opisywały, iż hijacking był już wykorzystywany w praktyce i prowadził do realnych infekcji — stąd pilna publikacja 8.8.9.
Analiza techniczna / szczegóły luki
WinGUp (znany też jako GUP.exe) to niewielki aktualizator uruchamiany z Notepad++: pobiera metadane aktualizacji i wskazany instalator EXE, zapisuje go tymczasowo i uruchamia. jeżeli ruch HTTP(S) zostanie przechwycony lub przekierowany, aktualizator może otrzymać spreparowany URL/plik. Opis sekwencji żądań i działania (pobranie metadanych, URL do EXE, uruchomienie z %TEMP%) potwierdzają niezależne analizy.
Co zmieniono w 8.8.9?
- Dodano weryfikację podpisu kodu i certyfikatów pobranego instalatora przed jego uruchomieniem. Brak poprawnej weryfikacji → abort aktualizacji.
- Twórcy podkreślają, iż śledztwo wciąż trwa; zatem 8.8.9 to warstwa kontroli, która eliminuje skutki potencjalnego przekierowania, choćby jeżeli do niego dojdzie.
- Wcześniej, w 8.8.8, WinGUp ograniczono do pobrań z GitHub.com, co zmniejsza powierzchnię ataku przez zawężenie zaufanego źródła.
Praktyczne konsekwencje / ryzyko
- Ryzyko dla użytkowników: możliwość cichej instalacji malware z uprawnieniami użytkownika uruchamiającego aktualizację, potencjalnie eskalowanej dalszymi technikami ataku.
- Ryzyko dla organizacji: o ile stacje robocze automatycznie akceptowały aktualizacje, łańcuch dostaw aktualizacji aplikacji stawał się wektorem wejścia dla atakujących. Media branżowe raportowały realne incydenty.
Rekomendacje operacyjne / co zrobić teraz
- Zaktualizuj do Notepad++ 8.8.9 (lub nowszej) na wszystkich hostach. Preferuj instalację ręczną z oficjalnej strony zamiast starego auto-update’u, jeżeli pracujesz na wersjach < 8.8.9.
- Zweryfikuj podpis instalatora przed wdrożeniem masowym (PowerShell):
- Get-AuthenticodeSignature .\npp.8.8.9.Installer.x64.exe — status powinien być Valid.
- (opcjonalnie) Get-FileHash .\npp.8.8.9.Installer.x64.exe -Algorithm SHA256 i porównanie z sumami na GitHub/witrynie projektu.
- Odtwórz zaufane źródła aktualizacji w narzędziach proxy/allow-list (domena github.com i oficjalne hosty projektu).
- Monitoruj telemetrię EDR/SIEM pod kątem:
- Nietypowych uruchomień GUP.exe/WinGUp spoza standardowej ścieżki programu,
- Nowych procesów potomnych instalatora Notepad++ w godzinach nietypowych dla okna serwisowego,
- Połączeń wychodzących do nieznanych hostów w momencie aktualizacji. (Opis działania GUP pomaga zbudować reguły detekcji.)
- Rozważ tymczasowe wyłączenie auto-update’u w starszych wersjach i wykonanie wymuszonego upgrade’u do 8.8.9 z centralnego repozytorium (SCCM/Intune/PDQ).
- Segmentacja i zasady egress: ogranicz możliwość kontaktu aktualizatora z internetem jedynie do zaufanych domen; rozważ TLS inspection dla ruchu aktualizacyjnego aplikacji „z długim ogonem”.
Różnice / porównania z innymi przypadkami (jeśli dotyczy)
- To nie klasyczny „supply-chain” w stylu podmiany binariów u dostawcy (jak przy atakach na repozytoria). Tu mówimy o przechwyceniu/zmodyfikowaniu ruchu aktualizatora i skierowaniu go do fałszywego źródła, a następnie uruchomieniu pobranego EXE. Wydanie 8.8.9 dodaje krytyczną kontrolę integralności i pochodzenia, która chroni choćby wtedy, gdy komuś uda się wpłynąć na trasowanie ruchu.
Podsumowanie / najważniejsze wnioski
- Luka polegała na tym, iż WinGUp mógł uruchomić podmieniony instalator, jeżeli ruch został przechwycony/przekierowany.
- 8.8.9 wprowadza twardą walidację podpisu i certyfikatu, co zamyka najgroźniejszą ścieżkę nadużycia.
- Jeśli zarządzasz flotą Windows: zaktualizuj natychmiast, egzekwuj weryfikację podpisów, monitoruj anomalię w uruchomieniach GUP.exe i ogranicz aktualizator do zaufanych domen (GitHub).
Źródła / bibliografia
- Notepad++ — ogłoszenie wydania v8.8.9 (Vulnerability-fix). (notepad-plus-plus.org)
- BleepingComputer: „Notepad++ fixes flaw that let attackers push malicious update files”. (BleepingComputer)
- heise: „Notepad++ updater installed malware – v8.8.9 corrects this; 8.8.8 wymusza GitHub jako źródło”. (heise online)
- The Register: „Notepad++ under attack: hijacking WinGUp traffic to złośliwych serwerów”. (The Register)
- DoublePulsar: analiza działania GUP/WinGUp i przepływu aktualizacji (gup.xml → EXE w %TEMP%). (DoublePulsar)














