InvoiceShelf wydało poprawkę dla CVE-2026-55610, krytycznej luki, która pozwalała każdemu właścicielowi w jednej firmie przejąć konta użytkowników w innej firmie. Podatność, oceniona na 8,7 w skali CVSS, wynikała z braku sprawdzenia zakresu dzierżawcy (tenant-scope check) w kodzie Laravel aplikacji.

Jak działała ta luka

InvoiceShelf to narzędzie SaaS zbudowane na Laravelu, które pozwala firmom zarządzać użytkownikami, fakturami i ustawieniami z poziomu jednego panelu sterowania. Platforma odczytuje niestandardowy nagłówek, aby zidentyfikować dzierżawcę (tenant). Gdy Właściciel (Owner) żąda rekordu użytkownika, kod sprawdza jedynie: „Czy żądający jest Właścicielem własnej firmy?”.

Kod nigdy nie weryfikuje, czy docelowy użytkownik należy do tego samego dzierżawcy. Niejawne wiązanie modelu z trasą (implicit route-model binding) w Laravelu rozwiązuje identyfikator użytkownika na wiersz w globalnej tabeli użytkowników, a polityka autoryzacji zatwierdza żądanie wyłącznie na podstawie roli żądającego.

Atakujący mógł zatem:

  • Podać dowolny numeryczny identyfikator użytkownika w adresie URL żądania.
  • Otrzymać pełny rekord użytkownika, w tym adres e-mail.
  • Wykonać aktualizację, która nadpisuje adres e-mail i hasło ofiary, a nawet przypisuje konto do firmy atakującego jako super-admin.

W praktyce złośliwy Właściciel zmienił narzędzie do zarządzania firmą w uniwersalną broń do przejmowania kont. Nie wymagało to żadnych uprawnień wykraczających poza rolę „Owner”.

Kto jest narażony

Każdy klient InvoiceShelf korzystający z wersji starszej niż 2.4.1 był narażony na atak. Ponieważ luka znajduje się w głównym procesie obsługi żądań, każdy dzierżawca mógł stać się celem Właściciela innego dzierżawcy, niezależnie od wielkości czy poziomu zabezpieczeń. Skutki obejmują utratę poufności (adresy e-mail) oraz utratę integralności (nieautoryzowane zmiany haseł, podniesienie uprawnień do super-admina).

Poprawka

Deweloperzy wydali wersję 2.4.1, dodając jawne sprawdzenie dzierżawcy przed każdą operacją odczytu lub zapisu rekordu użytkownika. Poprawka ogranicza zakres zapytania do identyfikatora aktywnej firmy, wymuszając na Laravelu zwracanie tylko tych wierszy, które należą do dzierżawcy żądającego.

Czego powinni nauczyć się deweloperzy

  • Nigdy nie polegaj na globalnych kluczach głównych w aplikacjach typu multi-tenant.
  • Stosuj filtr dzierżawcy przy każdym wyszukiwaniu w bazie danych, a nie tylko przy operacjach usuwania lub tworzenia.
  • Sprawiaj, aby polityki autoryzacji weryfikowały zarówno rolę wykonawcy, jak i przynależność obiektu docelowego do dzierżawcy.
  • Traktuj niejawne funkcje frameworka, takie jak route-model binding, jako udogodnienia, które mogą ukrywać luki w zabezpieczeniach, jeśli nie dodasz jawnego ograniczania zakresu (scoping).

Spojrzenie w przyszłość

Incydent ten pokazuje szersze ryzyko dla każdego rozwiązania SaaS, które współdzieli tabele. Audyty bezpieczeństwa powinny obejmować wszystkie punkty końcowe (endpoints), które przyjmują identyfikatory, i potwierdzać, że ograniczanie zakresu dzierżawcy jest egzekwowane jednolicie.

Wniosek: pojedyncze brakujące sprawdzenie dzierżawcy może zmienić uprzywilejowaną rolę użytkownika w uniwersalny backdoor. Prawidłowe ograniczanie zakresu nie jest opcjonalne; jest fundamentem izolacji danych w każdym systemie typu multi-tenant.