OpenAI proponuje pięć etapów ujawniania luk w PHP

21 października 2026 r. OpenAI opublikowało propozycję pięcioetapowego procesu skoordynowanego ujawniania podatności, przedstawioną przy okazji reakcji na dwa krytyczne błędy PHP. Proces ma prowadzić od potwierdzenia i naprawy błędu do publikacji instrukcji po udostępnieniu poprawki. To propozycja OpenAI, nie przyjęty standard.

PHP to otwartoźródłowy język programowania działający po stronie serwera, używany do obsługi stron i aplikacji internetowych. Obie luki mogą umożliwić zdalne wykonanie kodu bez uwierzytelnienia w instalacjach obsługujących żądania internetowe.

Pięć etapów proponowanych przez OpenAI

OpenAI opisuje kolejno naprawę błędu u źródła, przygotowanie organizacji, współpracę z rządami, gotowość do wdrożenia aktualizacji oraz publiczne instrukcje po udostępnieniu poprawki.

1. Potwierdzić błąd i przygotować poprawkę. Opiekunowie projektu, badacze i partnerzy techniczni mają ocenić wpływ podatności, opracować i przetestować poprawkę. Propozycja przewiduje też testy z udziałem zaawansowanych modeli, które mają szukać sposobów obejścia naprawy i podobnych błędów.
2. Dać czas organizacjom, których dotyczy luka. Dystrybutorzy mogą dostosować poprawki do starszych wydań, operatorzy hostingu przetestować zabezpieczenia, a dostawcy usług ochronnych przygotować wykrywanie zagrożeń lub reguły zapory WAF.
3. Skoordynować działania z rządami. Agencje mogą pomóc w organizacji szerszej reakcji i przekazywaniu zaleceń operatorom infrastruktury krytycznej. OpenAI podało, że zaangażowało amerykańskich i międzynarodowych partnerów, w tym CISA, Office of the National Cyber Director oraz White House Super Intelligence Force.
4. Przygotować aktualizacje dla zależnych produktów i usług. Gdy poprawki, zalecenia i plan ujawnienia będą gotowe, w koordynację mogą włączyć się kolejni dystrybutorzy, dostawcy usług, zespoły reagowania i operatorzy. Mają przygotować wdrożenia oraz znaleźć luki w zasięgu poprawek.
5. Opublikować instrukcje po udostępnieniu poprawki. Zalecenia mają pomagać operatorom rozpoznać narażone systemy, znaleźć aktualizacje lub środki tymczasowe, sprawdzić, czy poprawka działa, i uzyskać pomoc.

Kiedy może zmienić się harmonogram ujawnienia

Według propozycji OpenAI każdy uczestnik powinien otrzymać tylko informacje potrzebne do działań ochronnych. Zespoły mają przy tym ważyć ryzyko ujawnienia szczegółów wobec korzyści, jakie może przynieść ich udostępnienie.

Harmonogram można ponownie ocenić, jeśli luka jest aktywnie wykorzystywana, dojdzie do wycieku, publiczna poprawka ujawni podatność albo opóźnienia w naprawie zwiększą ryzyko dla użytkowników. OpenAI poprosiło też o opinie na temat długości okna na przygotowanie poprawek, etapowego powiadamiania oraz zabezpieczeń awaryjnego łatania systemów, do których operator ma uprawniony dostęp.

Luki PHP i wydania z poprawkami

PHP opisało obie podatności jako błędy umożliwiające zdalne wykonanie kodu bez uwierzytelnienia. Każda otrzymała ocenę 9,2 w skali CVSS v4.0.

CVE-2026-109618 dotyczy błędu obsługi braku pamięci. Przerwanie żądania przy częściowo zainicjalizowanych danych może sprawić, że procedura sprzątająca potraktuje nieprawidłowe dane jako poprawne. CVE-2026-109619 wiąże się z nieaktualnym stanem globalnym: stan przypisany do żądania może pozostać po zwolnieniu pamięci, a kolejne żądanie obsługiwane przez ten sam proces roboczy może użyć go przed ponowną inicjalizacją.

PHP wymienia jako potencjalnie zagrożone instalacje obsługujące żądania WWW, między innymi PHP-FPM, Apache z mod_php, php-cgi, FrankenPHP i LiteSpeed. Najwyższe ryzyko przypisuje mod_php.

W panelu WordPressa wersję PHP można sprawdzić, przechodząc do Narzędzia → Stan witryny → Informacje → Serwer. Taką ścieżkę podaje instruktaż DopeShit. Wcześniejsze omówienie NeoTeo opisuje wydania PHP naprawiające oba błędy.

Co mogą zrobić środki tymczasowe

PHP wskazuje aktualizację do wydania z poprawką jako jedyne pełne rozwiązanie. Jeśli nie da się jej wdrożyć od razu, zalecenia tymczasowe ograniczają konkretne ścieżki ataku, ale nie zabezpieczają całej instalacji:

• CVE-2026-109618: ustawienie memory_limit=-1, ograniczenie rozmiaru żądań POST i innych żądań oraz użycie limitów kontenerów lub cgroups jako granicy dostępności.
• CVE-2026-109619: wyłączenie session.upload_progress.enabled przed analizą żądania i ponowne uruchomienie wszystkich workerów.
• PHP 8.5: ustawienie fatal_error_backtraces=0 blokuje potwierdzoną ścieżkę wykorzystującą ślady stosu błędów krytycznych.

PHP 8.1 i starsze nie otrzymują już aktualizacji projektu. PHP udostępniło minimalne poprawki źródłowe dla wersji 7.4, 8.0 i 8.1; backporty mogą też przygotowywać dystrybucje Linuksa i dostawcy oferujący długoterminowe wsparcie. Operatorzy starszych instalacji powinni sprawdzić status pakietu u swojego dostawcy.