Luka oznaczona jako CVE-2026-46490 otrzymała ocenę 8.8 w skali CVSS (Common Vulnerability Scoring System – skala 0-10 oceniająca powagę luki). Dotyczy ona biblioteki samlify dla środowiska Node.js, używanej do implementacji mechanizmów logowania jednokrotnego, czyli SSO (Single Sign-On), w oparciu o protokół SAML 1. Wiele polskich firm technologicznych i startupów wykorzystuje Node.js, a SSO jest standardem w dostępie do systemów korporacyjnych. Błąd w obsłudze danych wejściowych może pozwolić zwykłemu użytkownikowi na uzyskanie uprawnień administratora.

Problem polega na sposobie, w jaki biblioteka przetwarza atrybuty użytkownika przed ich cyfrowym podpisaniem. Atakujący może spreparować wartość jednego ze swoich atrybutów, na przykład imienia lub adresu e-mail, aby wstrzyknąć do dokumentu SAML dodatkowe, nieautoryzowane uprawnienia. Podpisany przez zaufany serwer dokument staje się dla aplikacji docelowej wiarygodnym poświadczeniem, co może prowadzić do eskalacji uprawnień 2.

TL;DR

  • Produkt: samlify, biblioteka Node.js do obsługi protokołu SAML.
  • Wektor: Wstrzyknięcie XML (XML Injection) w atrybutach użytkownika przetwarzanych przez mechanizm SAML.
  • Identyfikator: CVE-2026-46490 (CVSS 8.8, High).
  • Wpływ: Eskalacja uprawnień. Użytkownik o niskich uprawnieniach może przypisać sobie dowolne role (np. administratora) w docelowej aplikacji.
  • Kogo dotyczy: Aplikacje webowe zbudowane w oparciu o Node.js, które używają biblioteki samlify w wersji starszej niż 2.13.0.
  • Pierwszy ruch: Identyfikacja użycia samlify w projektach i natychmiastowa aktualizacja do wersji 2.13.0 lub nowszej.

Wektor ataku

Atak wykorzystuje błąd w logice przetwarzania szablonów XML w bibliotece samlify. Protokół SAML (Security Assertion Markup Language) opiera się na wymianie cyfrowo podpisanych dokumentów XML, zwanych asercjami, pomiędzy dostawcą tożsamości (IdP – Identity Provider) a dostawcą usługi (SP – Service Provider). W uproszczeniu, IdP to system, w którym się logujemy (np. firmowy Active Directory), a SP to aplikacja, do której chcemy uzyskać dostęp.

Problem w samlify polegał na niewystarczającym oczyszczaniu danych wejściowych. Wersje biblioteki starsze niż 2.13.0 poprawnie zabezpieczały jedynie konteksty atrybutów XML 3. Jednak wartości wstawiane bezpośrednio do treści elementów, takich jak <saml:AttributeValue>, nie były odpowiednio filtrowane 4.

Scenariusz ataku wygląda następująco:

  1. Preparacja danych: Użytkownik o standardowych uprawnieniach modyfikuje jeden ze swoich atrybutów w systemie IdP. Może to być pole „Imię”, „Nazwisko” lub inne, które są synchronizowane z aplikacją. Wartość pola zostaje zmieniona tak, aby zawierała złośliwy fragment kodu XML 5.

    Przykład złośliwej wartości w polu email: </saml:AttributeValue></saml:Attribute><saml:Attribute Name="role"><saml:AttributeValue>admin</saml:AttributeValue>

  2. Wstrzyknięcie atrybutu: Biblioteka samlify, tworząc asercję SAML, wstawia tę wartość bez odpowiedniego oczyszczenia. W efekcie wewnątrz dokumentu XML zamykany jest oryginalny atrybut (email), a następnie dodawany jest zupełnie nowy, spreparowany atrybut (role z wartością admin) 6.

  3. Podpisanie asercji: Dostawca tożsamości (IdP) traktuje całą wygenerowaną strukturę jako prawidłową i podpisuje ją cyfrowo swoim kluczem prywatnym. Z jego perspektywy operacja jest poprawna 7.

  4. Akceptacja przez usługę: Podpisana asercja jest przesyłana do dostawcy usługi (SP). Aplikacja docelowa weryfikuje podpis cyfrowy, który jest prawidłowy. Następnie odczytuje zawarte w asercji atrybuty, w tym ten wstrzyknięty przez atakującego 7.

  5. Eskalacja uprawnień: Aplikacja przydziela użytkownikowi uprawnienia na podstawie odczytanych atrybutów. Ponieważ w asercji znajduje się atrybut role=admin, użytkownik może otrzymać dostęp administracyjny 2.

Wskaźniki kompromitacji

Ta luka nie jest związana z typowymi wskaźnikami kompromitacji (IoC – Indicators of Compromise), takimi jak adresy IP czy hashe plików. Jedynym wskaźnikiem jest użycie podatnej na atak wersji biblioteki samlify.

Zespoły deweloperskie i bezpieczeństwa powinny natychmiast zweryfikować swoje projekty Node.js. Najprostszym sposobem jest sprawdzenie pliku package-lock.json lub yarn.lock w poszukiwaniu samlify i jego wersji.

Można również użyć wbudowanych narzędzi menedżera pakietów Node.js. W katalogu głównym projektu należy wykonać polecenie:

npm list samlify
# lub jeśli używasz yarn
yarn why samlify

Jeśli wynikiem jest wersja niższa niż 2.13.0, aplikacja jest podatna. Analiza logów po stronie dostawcy usługi (SP) w poszukiwaniu nietypowych lub zduplikowanych atrybutów w asercjach SAML może pomóc w wykryciu prób wykorzystania luki, ale jest to metoda mało precyzyjna i trudna do wdrożenia bez wcześniejszego przygotowania.

Co zrobić w 24-48h

Zalecane podejście zakłada natychmiastowe działanie, zwłaszcza w organizacjach, gdzie SSO jest kluczowym elementem architektury bezpieczeństwa. Dotyczy to zarówno polskich software house’ów tworzących oprogramowanie dla klientów, jak i firm utrzymujących własne aplikacje wewnętrzne.

  1. Identyfikacja (Priorytet 1): Należy niezwłocznie przeskanować wszystkie repozytoria kodu pod kątem użycia biblioteki samlify. Zautomatyzowane narzędzia do analizy składu oprogramowania (SCA – Software Composition Analysis) mogą znacząco przyspieszyć ten proces.

  2. Aktualizacja (Priorytet 1): We wszystkich zidentyfikowanych projektach należy zaktualizować samlify do wersji 2.13.0 lub nowszej 8. Można to zrobić za pomocą polecenia:

    npm install samlify@latest
# lub
yarn add samlify@latest

    Następnie należy upewnić się, że plik blokujący wersje (package-lock.json / yarn.lock) został zaktualizowany i wdrożony na środowisko produkcyjne.

  3. Weryfikacja (Priorytet 2): Po aktualizacji kluczowe jest przeprowadzenie testów regresji, aby potwierdzić, że mechanizm logowania jednokrotnego nadal działa poprawnie. Należy przetestować logowanie dla różnych ról użytkowników.

  4. Analiza (Priorytet 3): Chociaż trudne, zaleca się przejrzenie logów audytowych systemów, które korzystały z podatnej biblioteki. Należy szukać anomalii, takich jak przyznanie podwyższonych uprawnień użytkownikom, którzy nie powinni ich mieć, zwłaszcza w okresie poprzedzającym aktualizację. Eskalacja uprawnień to incydent bezpieczeństwa, który może mieć konsekwencje w kontekście zgodności z RODO (Rozporządzenie o Ochronie Danych Osobowych), jeśli prowadził do nieautoryzowanego dostępu do danych osobowych.

Powyższe kroki nie zastępują pełnej konsultacji bezpieczeństwa, ale stanowią podstawę do szybkiej reakcji na zidentyfikowane zagrożenie.

Źródła

Zobacz też

Footnotes

  1. samlify to biblioteka Node.js przeznaczona do SAML single sign-on. — https://nvd.nist.gov/vuln/detail/CVE-2026-46490 ↩

  2. Pozwalało to na eskalację uprawnień, gdy atrybuty były używane do autoryzacji (role/grupy). — https://nvd.nist.gov/vuln/detail/CVE-2026-46490 ↩ ↩2

  3. Przed wersją 2.13.0, podstawianie szablonów w samlify uciekało tylko konteksty atrybutów. — https://nvd.nist.gov/vuln/detail/CVE-2026-46490 ↩

  4. Wartości wstawiane do tekstu elementu (np. saml:AttributeValue) nie były uciekane. — https://nvd.nist.gov/vuln/detail/CVE-2026-46490 ↩

  5. Zwykły użytkownik mógł wstrzyknąć znacznik XML do wartości atrybutu (np. email, nazwa). — https://nvd.nist.gov/vuln/detail/CVE-2026-46490 ↩

  6. Użytkownik mógł dodać nowe elementy saml:Attribute wewnątrz podpisanego potwierdzenia. — https://nvd.nist.gov/vuln/detail/CVE-2026-46490 ↩

  7. IdP (Identity Provider) podpisywał zmienione potwierdzenie, a SP (Service Provider) akceptował wstrzyknięte atrybuty jako zaufane. — https://nvd.nist.gov/vuln/detail/CVE-2026-46490 ↩ ↩2

  8. Problem został załatany w wersji 2.13.0 biblioteki samlify. — https://nvd.nist.gov/vuln/detail/CVE-2026-46490 ↩