Dwie krytyczne luki atakują systemy firm

Dwie krytyczne luki uderzają w systemy firmowe

W krótkim odstępie czasu ujawniono i opisano dwie poważne podatności w popularnych rozwiązaniach używanych w środowiskach firmowych. Jedna dotyczy platformy Issabel Framework i jest już aktywnie wykorzystywana przez atakujących. Druga obejmuje systemy Check Point Security Management oraz Log Server i pozwala na zdalne uruchomienie kodu jako root, choć producent na razie nie widzi oznak realnej eksploatacji.

Obie luki są krytyczne, bo w praktyce mogą dać napastnikowi bardzo szeroki dostęp do infrastruktury, jeśli administratorzy nie zareagują na czas.

Issabel: obejście uwierzytelniania i wykonanie komend

Pierwszy problem dotyczy Issabel Framework, czyli webowego frameworka dla oprogramowania PBX do zunifikowanej komunikacji. Podatność oznaczona jako CVE-2026-89026 otrzymała wysokie oceny 9,8 w CVSS v3.1 i 9,3 w CVSS v4.0.

Błąd wynika z tego, że w pliku pbxapi index.php zastosowano na stałe wpisany klucz JWT używany do podpisywania tokenów HS256. Co istotne, ten sam klucz był obecny w każdej instalacji. To pozwalało atakującemu bez logowania wygenerować poprawny token i wywołać endpoint '/pbxapi/manager/originate' z parametrem System, przez co Asterisk mógł wykonać dowolne komendy systemowe jako użytkownik Asterisk.

Poprawka została wdrożona 1 sierpnia 2026 roku. Zastąpiono w niej twardo zakodowany klucz da893kasdfam43k29akdkfaFFlsdfhj23rasdf kluczem przechowywanym w pliku /etc/issabel.conf.

Według dostępnych informacji pierwsze oznaki aktywnej eksploatacji tej luki zauważono 9 września 2026 roku. Na ten moment nie ujawniono jednak, w jaki sposób jest ona wykorzystywana, kto stoi za atakami ani jak duża jest skala kampanii.

Check Point: krytyczny błąd przed logowaniem

Druga podatność dotyczy produktów Check Point: Security Management Server i Log Servers. Problem oznaczono jako CVE-2026-91843 i oceniono na 9,8/10 w skali CVSS.

To stack overflow w procesie logowania, działający jeszcze przed uwierzytelnieniem. W praktyce oznacza to, że atakujący bez danych logowania może przesłać odpowiednio przygotowane żądanie i doprowadzić do wykonania kodu z uprawnieniami root. Według analizy podatność wyzwala m.in. żądanie logowania z bardzo długą nazwą użytkownika.

Producent poinformował, że wydał poprawkę przez kanał LivePatch i nie ma obecnie dowodów na to, by luka była wykorzystywana w atakach. Część klientów z włączonymi automatycznymi aktualizacjami ma być już zabezpieczona, ale administratorzy powinni to zweryfikować samodzielnie.

Które wersje są zagrożone

Według danych producenta podatność obejmuje m.in. następujące gałęzie:

• R82.10 z Jumbo Hotfix Take 44 lub starszym
• R82 z Jumbo Hotfix Take 126 lub starszym
• R81.20 z Jumbo Hotfix Take 166 lub starszym
• R81.10 z Jumbo Hotfix Take 190 lub starszym
• a także R81, R80.40, R80.30, R80.20, R80.10 i R80, które są już po zakończeniu wsparcia

Dodatkowo potwierdzono, że podatna jest również wersja R82.20, mimo że nie została pierwotnie wymieniona w rekordzie CVE. Wrażliwe są także wdrożenia typu standalone, a więc takie, w których zarządzanie i brama działają na jednym systemie, oraz Multi-Domain servers. Z kolei hostowana usługa Smart-1 Cloud nie jest objęta problemem, bo poprawka została tam już wdrożona.

Co powinni zrobić administratorzy

W obu przypadkach kluczowe jest szybkie działanie. Administratorzy powinni:

• zainstalować najnowsze poprawki dla Issabel Framework;
• wdrożyć LivePatch wskazany przez producenta w środowiskach Check Point;
• sprawdzić, czy automatyczne aktualizacje faktycznie zostały pobrane i zainstalowane;
• upewnić się, że ustawienie Trusted Clients w Check Point ogranicza dostęp wyłącznie do zaufanych hostów;
• nie wystawiać interfejsów zarządzających bezpośrednio do internetu.

W praktyce problem nie dotyczy tylko samej obecności aktualizacji, ale także sposobu konfiguracji. Jeśli dostęp do paneli administracyjnych jest zbyt szeroki, ryzyko przejęcia infrastruktury znacząco rośnie.

Dlaczego te luki są tak groźne

W obu przypadkach mówimy o błędach, które mogą prowadzić do zdalnego wykonania kodu bez wcześniejszego przełamania hasła czy zdobycia konta. To jedne z najgroźniejszych klas podatności, bo atakujący może od razu przejść do działania na poziomie systemu operacyjnego.

W dodatku jeden z problemów — w Issabel — jest już wykorzystywany w realnych atakach. To oznacza, że organizacje korzystające z tych rozwiązań nie powinny odkładać reakcji na później.