P4 Search: trzy CVE i poprawka 2026.4.2 — sprawdź tokeny oraz debug

5 października w rejestrze CVE opublikowano trzy rekordy dotyczące Perforce P4 Search. Dane dostarczone przez producenta wskazują 30 września jako datę wcześniejszego ujawnienia oraz 2026.4.2 jako wersję bez opisanych podatności. Dzisiejsza publikacja rekordów nie oznacza, że dopiero dziś pojawiła się poprawka lub doszło do ataku.

Problem dotyczy usługi wyszukiwania i jej obrazów kontenerowych. Zespół powinien sprawdzić własne wdrożenie P4 Search, jego dostępność sieciową oraz połączenie z P4 Server. Sama obecność Perforce w organizacji nie wystarcza do potwierdzenia ekspozycji.

Trzy mechanizmy opisane przez producenta

• CVE-2026-103510: pusty token uwierzytelniania usługi pozwalał ominąć kontrolę dostępu i uzyskać najwyższe uprawnienia aplikacji.
• CVE-2026-100103: obrazy kontenerowe przywracały publicznie udokumentowany domyślny token, co umożliwiało podobne obejście uwierzytelniania.
• CVE-2026-100102: obrazy udostępniały nieuwierzytelniony interfejs debugowania Java JDWP, umożliwiający wykonanie kodu z uprawnieniami konta usługi.

Rekordy obejmują wersje sprzed 2026.4.2 i wymagają dostępu sieciowego atakującego. Producent wskazuje również możliwość naruszenia połączonego P4 Server. Uprawnienia konta usługi nie oznaczają automatycznie uprawnień administratora hosta, a możliwy dalszy wpływ trzeba ocenić w konkretnej konfiguracji.

Co sprawdzić przed zamknięciem zgłoszenia

Rekomendacja Breachroad: nie kończ oceny na numerze obrazu zapisanym w repozytorium. Ustal wersję działających instancji, identyfikator uruchomionego obrazu i właściciela wdrożenia. Sprawdź środowiska testowe, stare repliki i zadania, które mogą odtworzyć wcześniejszy kontener.

Następnie sporządź krótką mapę dostępu: kto może połączyć się z usługą, jakie porty wystawiono oraz jakie uprawnienia ma integracja z P4 Server. Dostęp przez firmowy VPN również jest dostępem sieciowym. Decyzję o pilności oprzyj na tej mapie i zakresie uprawnień, a nie na samej etykiecie „wewnętrzne”.

Plan aktualizacji i kontroli

1. Ogranicz ekspozycję. Dopuść tylko potrzebnych odbiorców i usuń zbędne udostępnienie interfejsów diagnostycznych. To ograniczenie ryzyka podczas pracy nad poprawką.
2. Wdróż poprawioną wersję. Wybierz wspierane wydanie zawierające naprawę z 2026.4.2. Potwierdź aktualizację wszystkich instancji oraz konfiguracji używanej przy ponownym uruchomieniu.
3. Sprawdź uwierzytelnianie. Zweryfikuj w kontrolowanym środowisku, że brak tokenu i niewłaściwy token powodują odmowę dostępu. Nie umieszczaj rzeczywistych sekretów w zgłoszeniu ani w logu testu.
4. Sprawdź debugger i integrację. Potwierdź brak niepotrzebnego dostępu do JDWP oraz minimalne uprawnienia konta łączącego usługę z P4 Server.
5. Oceń wcześniejszy okres. Przejrzyj dostępne logi połączeń i operacji w ustalonym oknie. Przy podejrzeniu ujawnienia tokenu zaplanuj jego wymianę i unieważnienie poprzedniego zgodnie z procedurą incydentową.

Brak nietypowego wpisu w ograniczonych logach nie rozstrzyga, czy doszło do wykorzystania podatności. W raporcie warto oddzielić potwierdzone fakty od luk w obserwowalności.

Przykład szkoleniowy: aktualny tag, stara replika

W naszym fikcyjnym scenariuszu administrator zmienia tag obrazu w szablonie wdrożenia. Jedna stara replika nadal działa, a konfiguracja odtwarzania przechowuje wcześniejszy token. Zgłoszenie otrzymuje status „naprawione”, choć rzeczywisty stan nie odpowiada szablonowi.

Ćwiczenie polega na wskazaniu dowodów zakończenia pracy: wersji każdej repliki, wyniku odmowy dostępu bez poprawnego tokenu i potwierdzenia ograniczonej powierzchni sieciowej. Nie wymaga odtwarzania ataku ani używania produkcyjnych poświadczeń.

Szkolenia z cyberbezpieczeństwa dla zespołów technicznych pomagają przećwiczyć podział odpowiedzialności między administratorami, deweloperami i zespołem bezpieczeństwa. Uzupełnieniem jest poradnik o zarządzaniu sekretami i rotacji.

Źródła i wnioski Breachroad

Mechanizmy, zakres wersji i możliwy wpływ pochodzą z trzech podlinkowanych rekordów CVE zawierających dane Perforce. Mapa dostępu, plan kontroli i scenariusz są rekomendacjami Breachroad. Te rekordy same w sobie nie potwierdzają aktywnego wykorzystania ani incydentu u konkretnego użytkownika. Źródła sprawdziliśmy 5 października 2026 roku.