Jedna luka w oprogramowaniu otrzymała ocenę 9.6 w skali CVSS (Common Vulnerability Scoring System — skala 0-10 oceniająca powagę luki) [cve]. Dotyczy aplikacji do notatek SiYuan i może pozwolić na przejęcie kontroli nad komputerem użytkownika 1. Atak nie wymaga żadnej interakcji poza wyświetleniem listy dodatków w wewnętrznym sklepie aplikacji, zwanym Bazaar.

Problem leży w sposobie, w jaki aplikacja przetwarza metadane pakietów dostarczanych przez zewnętrznych autorów 2. Brak odpowiedniej sanitazyacji danych wejściowych może umożliwić wstrzyknięcie złośliwego kodu, który wykonuje się z uprawnieniami aplikacji na komputerze ofiary 3 4. Dla polskich firm, nawet tych niekorzystających z SiYuan, jest to studium przypadku ryzyka związanego z oprogramowaniem wykorzystującym framework Electron oraz z łańcuchem dostaw w postaci marketplace’ów z dodatkami.

TL;DR

  • Produkt: SiYuan, aplikacja do notatek oparta na frameworku Electron, wersje przed 3.6.1 2.
  • Wektor: Złośliwy pakiet opublikowany w marketplace „Bazaar”. Atakujący umieszcza kod w polach displayName, description lub w pliku README pakietu 5.
  • Luka: CVE-2026-56395 [cve]. Błąd typu Cross-Site Scripting (XSS) wynikający z braku sanitazyacji metadanych pakietów 2.
  • Skutek: Zdalne wykonanie kodu (RCE — Remote Code Execution, czyli zdalne wykonanie kodu na komputerze ofiary) na stacji roboczej użytkownika, który jedynie przegląda marketplace 1.
  • Mechanizm: Wstrzyknięty kod JavaScript wykorzystuje niebezpieczną konfigurację Electrona (nodeIntegration) do wywołania poleceń systemowych 4.
  • Kogo dotyczy: Wszyscy użytkownicy aplikacji SiYuan w wersji poniżej 3.6.1 2. Problem jest szczególnie istotny dla twórców oprogramowania i firm w Polsce, które tworzą lub używają aplikacji opartych o Electron.
  • Pierwszy ruch: Natychmiastowa aktualizacja SiYuan do wersji 3.6.1 lub nowszej. Jeśli aktualizacja jest niemożliwa, należy bezwzględnie unikać korzystania z marketplace’u Bazaar.

Wektor ataku

Luka zidentyfikowana jako CVE-2026-56395 [cve] dotyczy aplikacji desktopowej SiYuan, która służy do tworzenia i zarządzania notatkami w formie bazy wiedzy. Aplikacja zbudowana jest na popularnym frameworku Electron, który pozwala tworzyć programy desktopowe przy użyciu technologii webowych: HTML (HyperText Markup Language), CSS i JavaScript (JS).

SiYuan posiada wbudowany marketplace o nazwie Bazaar, z którego użytkownicy mogą pobierać i instalować dodatki, motywy i inne rozszerzenia. Problem polega na tym, że wersje aplikacji przed 3.6.1 nie weryfikowały poprawnie treści pobieranych z tego marketplace’u 2.

Atak przebiega w kilku krokach:

  1. Przygotowanie ładunku: Operator przygotowuje złośliwy pakiet do publikacji w Bazaar. W polach tekstowych, takich jak nazwa pakietu (displayName), jego opis (description) lub zawartość pliku README.md, umieszcza złośliwy kod HTML i JavaScript 5.
  2. Publikacja w marketplace: Pakiet zostaje opublikowany w oficjalnym lub nieoficjalnym repozytorium Bazaar. Nie wymaga to przełamania żadnych dodatkowych zabezpieczeń po stronie serwera — luka znajduje się w aplikacji klienckiej.
  3. Ekspozycja ofiary: Użytkownik podatnej wersji SiYuan otwiera marketplace Bazaar w celu przeglądania dostępnych dodatków. Nie musi niczego instalować ani nawet klikać w konkretny pakiet. Wystarczy, że złośliwy pakiet pojawi się na liście.
  4. Wykonanie kodu (XSS): Aplikacja, renderując listę pakietów, interpretuje złośliwy kod HTML/JS jako część interfejsu użytkownika. Może dojść do ataku typu Cross-Site Scripting (XSS).
  5. Eskalacja do RCE: Tu kluczową rolę odgrywa architektura Electrona. Luka wykorzystuje fakt, że w podatnej konfiguracji proces renderujący interfejs ma włączoną opcję nodeIntegration 4. Pozwala to kodowi JavaScript na dostęp do modułów Node.js, w tym do funkcji umożliwiających wykonywanie poleceń w systemie operacyjnym (OS) komputera. Wstrzyknięty skrypt może więc uruchomić dowolny program, pobrać i wykonać malware, czy wykraść pliki użytkownika.

Ten wektor ataku jest szczególnie podstępny, ponieważ nie wymaga od użytkownika żadnej niestandardowej, ryzykownej akcji. Przeglądanie oficjalnego sklepu z dodatkami jest postrzegane jako bezpieczna czynność. Dla polskich deweloperów tworzących aplikacje w Electronie jest to przypomnienie, że opcja nodeIntegration powinna być domyślnie wyłączona, a wszelkie treści pochodzące z zewnętrznych źródeł muszą być bezwzględnie sanitazywane przed wyświetleniem.

Wskaźniki kompromitacji

Na ten moment nie są dostępne publiczne wskaźniki kompromitacji (IoC — Indicators of Compromise, czyli np. hashe plików, adresy IP, domeny) powiązane z aktywnym wykorzystaniem tej luki.

Zespoły SOC (Security Operations Center — zespół monitoringu bezpieczeństwa) powinny jednak monitorować telemetrię ze stacji roboczych pod kątem nietypowych procesów potomnych uruchamianych przez proces aplikacji SiYuan (np. siyuan.exe). Każde wywołanie cmd.exe, powershell.exe, bash czy curl przez aplikację do notatek jest sygnałem alarmowym.

Co zrobić w 24-48h

Rekomendowane podejście zakłada natychmiastowe działania mitygujące. Poniższe kroki nie zastępują pełnej konsultacji bezpieczeństwa, ale stanowią podstawę reagowania.

  1. Identyfikacja i aktualizacja: Należy zidentyfikować wszystkie stacje robocze w organizacji, na których zainstalowana jest aplikacja SiYuan. Priorytetem jest aktualizacja do wersji 3.6.1 lub nowszej. W środowiskach korporacyjnych proces ten powinien być zarządzany centralnie przez dział IT.

  2. Blokada dostępu do marketplace: Jeśli natychmiastowa aktualizacja nie jest możliwa, należy poinstruować użytkowników, aby pod żadnym pozorem nie otwierali marketplace’u Bazaar. W miarę możliwości technicznych, warto zablokować na poziomie zapory sieciowej lub serwera proxy ruch do repozytoriów Bazaar.

  3. Przegląd oprogramowania w organizacji: Incydent ten powinien stać się pretekstem do przeglądu polityki dopuszczonego oprogramowania (tzw. allow-list) w polskich firmach, zwłaszcza w sektorze MŚP. Niszowe, choć funkcjonalne aplikacje, często nie podlegają takiemu samemu rygorowi bezpieczeństwa jak oprogramowanie od dużych dostawców. Należy ocenić ryzyko związane z każdą aplikacją, która ma dostęp do sieci i przetwarza dane z zewnętrznych źródeł.

  4. Weryfikacja dla deweloperów: Polskie software house’y i zespoły deweloperskie tworzące aplikacje w Electronie powinny potraktować ten przypadek jako ostrzeżenie. Należy przeprowadzić audyt własnych aplikacji pod kątem:

    • Użycia nodeIntegration w procesach renderujących treść. Zgodnie z najlepszymi praktykami, powinno być wyłączone.
    • Implementacji contextIsolation i sandbox.
    • Sanitazyacji wszystkich danych wejściowych pochodzących od użytkowników lub z zewnętrznych API, zanim zostaną wyświetlone w interfejsie.

  5. Kontekst regulacyjny (NIS2): Dla podmiotów objętych dyrektywą NIS2 (unijna dyrektywa o bezpieczeństwie sieci, obowiązuje od 2024), zarządzanie podatnościami w oprogramowaniu firm trzecich jest częścią obowiązku dbania o bezpieczeństwo łańcucha dostaw. Ten przypadek pokazuje, że „łańcuch dostaw” to nie tylko kod źródłowy, ale także ekosystemy dodatków i marketplace’y.

Źródła

Zobacz też

Przypisy

  1. Atakujący mogą osiągnąć zdalne wykonanie kodu na dowolnym użytkowniku przeglądającym Bazaar. — nvd.nist.gov › CVE 2026 56395 ↩ ↩2

  2. SiYuan przed wersją v3.6.1 niepoprawnie sanitizuje metadane pakietów i zawartość plików README w marketplace Bazaar. — nvd.nist.gov › CVE 2026 56395 ↩ ↩2 ↩3 ↩4 ↩5

  3. Luka ta pozwala złośliwym autorom pakietów na wstrzyknięcie dowolnego kodu HTML i JavaScript. — nvd.nist.gov › CVE 2026 56395 ↩

  4. Luka wykorzystuje ustawienie nodeIntegration w Electronie do wykonywania poleceń systemu operacyjnego. — nvd.nist.gov › CVE 2026 56395 ↩ ↩2 ↩3

  5. Zdalne wykonanie kodu jest możliwe poprzez osadzenie ładunków XSS w polach displayName, description lub README pakietu. — nvd.nist.gov › CVE 2026 56395 ↩ ↩2