SiYuan CVE-2026-72811: backlinki otwierają drogę do SQL injection

14 sierpnia 2026 roku opublikowano CVE-2026-72811, krytyczną podatność SQL injection w SiYuan. Problem obejmuje wersje do 3.7.2 włącznie, a producent wskazuje 3.7.4 jako wydanie z poprawką. Błąd znajduje się w mechanizmie wyszukiwania backlinków i wzmianek, czyli funkcji, która ma pomagać użytkownikowi odnajdywać relacje między notatkami. W praktyce metadane bloku oraz słowo wyszukiwania mogą trafić do ręcznie składanego zapytania SQL.

Advisory projektu ocenia podatność na 10,0 w CVSS 3.1 i 9,9 w CVSS 4.0. Nie jest to błąd ograniczony do odczytu pojedynczej notatki. Zapytania są wykonywane na głównej bazie siyuan.db, a używany wariant sterownika pozwala na wykonywanie wielu instrukcji. Skutkiem może być odczyt danych z innych notatników, modyfikacja rekordów, usuwanie treści lub trwałe uszkodzenie bazy.

Jak działa podatny przepływ

Źródło problemu znajduje się w kodzie odpowiedzialnym za backlinki, między innymi w kernel/model/backlink.go. Aplikacja buduje warunek wyszukiwania pełnotekstowego z kilku elementów: tytułu bloku, nazwy, aliasu, tekstu kotwicy i słowa podanego przez klienta. Część znaków jest modyfikowana, ale pojedynczy apostrof nie jest bezpiecznie parametryzowany. To wystarcza, aby wartość opuściła kontekst tekstowy i zmieniła składnię SQL.

Pierwsza ścieżka jest klasycznym SQL injection pierwszego rzędu. Parametr wyszukiwania dostarczony w bieżącym żądaniu zostaje połączony z zapytaniem, które następnie trafia do silnika bazy. Atakujący otrzymuje rezultat działania w tym samym przepływie. Według advisory podatne są operacje związane z getBacklink, getBacklink2, getBacklinkDoc i getBackmentionDoc.

Druga ścieżka jest bardziej podstępna, bo ma charakter second-order SQL injection. Złośliwy tekst może najpierw zostać zapisany jako zwykła metadana przy użyciu prawidłowo parametryzowanego INSERT. Na tym etapie nie ma widocznego błędu. Dopiero później funkcja backlinków pobiera zapisany tytuł, alias lub anchor i wkleja go do nowego zapytania. Bezpieczny zapis nie gwarantuje zatem bezpiecznego ponownego użycia danych.

To ważna lekcja dla code review. Zaufanie nie powinno wynikać z tego, że wartość pochodzi z własnej bazy. Baza może przechowywać treść wcześniej kontrolowaną przez użytkownika, import, synchronizację albo integrację. Każde przejście danych do interpretera SQL musi ponownie stosować parametryzację odpowiednią dla bieżącego kontekstu.

Kto może uruchomić atak

Największe ryzyko występuje tam, gdzie SiYuan udostępnia funkcje publikacji lub współdzielenia szerszej grupie. Advisory opisuje osiągalność części ścieżek dla anonimowego użytkownika albo konta z rolą tylko do odczytu. Jest to szczególnie niebezpieczne, ponieważ organizacja może traktować czytelnika jako podmiot, który nie ma żadnego prawa do modyfikowania danych.

W przypadku second-order injection pierwsza osoba może przygotować blok o złośliwych metadanych, a inny użytkownik uruchomić podatne wyszukiwanie dopiero później. Logi aplikacyjne będą wtedy pokazywały dwa zdarzenia rozdzielone czasem, kontem i funkcją. Prosty monitoring pojedynczego żądania może nie połączyć przyczyny ze skutkiem.

Narażone są zespołowe bazy wiedzy, instancje publikujące dokumentację, prywatne serwery wystawione przez reverse proxy oraz środowiska synchronizujące notatniki między urządzeniami. W bazie mogą znajdować się notatki techniczne, fragmenty konfiguracji, wewnętrzne adresy, szkice procedur reagowania czy dane osobowe. Nawet jeżeli aplikacja nie przechowuje formalnego sekretu, jej zawartość często ułatwia dalszą penetrację organizacji.

Dlaczego skutki wykraczają poza wyciek

SQL injection kojarzy się z kradzieżą rekordów, ale tutaj potencjalny zakres jest szerszy. Wykonywanie wielu instrukcji może pozwolić dodawać, zmieniać lub usuwać rekordy. Atakujący może ingerować w treść notatek, metadane i relacje między blokami. Dla bazy wiedzy oznacza to również ryzyko naruszenia integralności: użytkownik nie wie, czy instrukcja operacyjna, konfiguracja albo opis incydentu nadal jest prawdziwy.

Integralność ma szczególne znaczenie w dokumentacji bezpieczeństwa. Dyskretna zmiana polecenia odzyskiwania, adresu repozytorium, reguły zapory lub kroku wdrożenia może pozostać niewykryta dłużej niż proste usunięcie danych. Kopia zapasowa pomaga odtworzyć plik, lecz bez osi czasu i niezależnych logów trudno ustalić, które rekordy są wiarygodne.

Dostęp do głównej bazy oznacza także przekroczenie logicznych granic między notatnikami. Kontrola na poziomie aplikacji może ograniczać użytkownikowi widok, lecz ręcznie zmienione zapytanie jest wykonywane niżej, gdzie takie reguły nie zawsze obowiązują. Dlatego nie wolno opierać oceny skutku wyłącznie na uprawnieniach widocznych w interfejsie.

Co zrobić teraz

Najważniejszym działaniem jest aktualizacja do SiYuan 3.7.4 lub nowszej wersji zawierającej poprawkę. Przed wdrożeniem wykonaj kopię bazy oraz konfiguracji, przetestuj odtworzenie i zapisz sumy kontrolne. Sama aktualizacja usuwa podatny mechanizm na przyszłość, ale nie cofa modyfikacji, które mogły nastąpić wcześniej.

Do czasu aktualizacji ogranicz dostęp do funkcji publikacji i backlinków. Reverse proxy powinien wymagać silnego uwierzytelnienia, a instancja nie powinna być bezpośrednio osiągalna z Internetu. Jeżeli publiczne notatki są potrzebne, rozważ statyczny eksport pozbawiony dynamicznych endpointów jądra. Konto procesu powinno mieć minimalne prawa do systemu plików, a kopie zapasowe muszą być zapisane poza katalogiem, który aplikacja może zmienić.

Po aktualizacji przeprowadź kontrolę integralności. Porównaj aktualne notatki i rekordy z ostatnią zaufaną kopią. Sprawdź nietypowe zmiany w tytułach, aliasach i anchorach, masowe modyfikacje, usunięcia oraz zdarzenia blisko wywołań endpointów backlinkowych. Jeżeli w bazie były sekrety lub tokeny, potraktuj możliwość odczytu jako przesłankę do rotacji.

Jak wykrywać próby wykorzystania

W logach reverse proxy szukaj żądań do funkcji backlinków i wzmianek zawierających nietypowe apostrofy, komentarze SQL, kodowanie znaków lub bardzo długie parametry. Nie buduj jednak detekcji na jednej sygnaturze. Treść może zostać zakodowana, podzielona albo zapisana wcześniej w metadanych, więc brak charakterystycznego ciągu w żądaniu uruchamiającym nie wyklucza ataku.

Po stronie bazy analizuj błędy składni, nieoczekiwane instrukcje modyfikujące i nagłe zmiany liczby rekordów. Dobrą praktyką jest wysyłanie logów poza host aplikacji. Jeśli napastnik uzyska możliwość zmiany bazy, lokalne artefakty nie są wystarczającym źródłem prawdy.

Second-order injection wymaga korelacji. Warto zachować informację, kto i kiedy utworzył blok lub zmienił metadane, a następnie łączyć ją z późniejszym użyciem backlinków. Alert powinien wskazywać zarówno żądanie wykonujące zapytanie, jak i obiekt będący źródłem wykorzystanej wartości.

Jak zapobiegać podobnym błędom

Poprawnym rozwiązaniem jest konsekwentne używanie parametrów bindowanych przez sterownik bazy. Ręczne dodawanie cudzysłowów, zamiana kilku znaków czy budowanie listy dozwolonych fragmentów nie daje równoważnej ochrony. Jeżeli wyszukiwanie pełnotekstowe ma specjalną składnię, aplikacja powinna rozdzielić strukturę zapytania od danych i zastosować bibliotekę przeznaczoną do tej składni.

Testy powinny obejmować dane przechodzące przez magazyn. Najpierw zapisują wartości z apostrofami i sekwencjami granicznymi, a później uruchamiają każdą funkcję, która je ponownie wykorzystuje. Analiza przepływu danych musi oznaczać wszystkie pola kontrolowane przez użytkownika jako niezaufane niezależnie od tego, czy aktualnie pochodzą z HTTP, pliku importu czy bazy.

Warto też ograniczać skutki. Oddzielenie publicznego odczytu od bazy roboczej, niezmienne kopie, wersjonowanie treści i osobne konto bazy z minimalnymi prawami zmniejszają blast radius. Warstwa WAF może zatrzymać część prób, lecz nie zastępuje naprawy, zwłaszcza przy wektorze drugiego rzędu.

Fakty, wnioski i następny krok

Faktem z advisory jest podatność wersji do 3.7.2, dwie ścieżki SQL injection, wysoka ocena CVSS i poprawka w 3.7.4. Faktem jest również to, że problem dotyczy głównej bazy i może prowadzić do operacji wykraczających poza odczyt. Nie ma natomiast podstaw, aby na tej informacji samej w sobie ogłaszać masowe wykorzystanie w Internecie.

Wnioskiem Breachroad jest konieczność traktowania firmowej bazy wiedzy jak systemu o wysokiej wartości. Zawiera ona kontekst, który łączy ludzi, infrastrukturę i procesy, więc jej naruszenie może przyspieszyć kolejne etapy ataku. Aktualizacja jest pierwszym krokiem; dopiero kontrola integralności, rotacja ujawnionych sekretów i ograniczenie publicznej powierzchni zamykają incydent.

Jeżeli chcesz sprawdzić, czy aplikacje wiedzy, panele i API rzeczywiście egzekwują granice uprawnień, zobacz testy penetracyjne aplikacji webowych i API. Dla zespołów tworzących lub utrzymujących takie systemy dobrym uzupełnieniem jest szkolenie cyberbezpieczeństwa dla organizacji, oparte na realnych przepływach danych i decyzjach obronnych.