{"id":183943,"date":"2026-10-22T05:40:56","date_gmt":"2026-10-22T03:40:56","guid":{"rendered":"https:\/\/prohoster.info\/blog\/news\/raskryty-detali-kriticheskih-uyazvimostej-v-php-i-opublikovany-korrektiruyushhie-obnovleniya"},"modified":"2026-10-22T05:41:02","modified_gmt":"2026-10-22T03:41:02","slug":"details-of-critical-php-vulnerabilities-disclosed-and-security-updates-released","status":"publish","type":"post","link":"https:\/\/prohoster.info\/pl\/blog\/news\/details-of-critical-php-vulnerabilities-disclosed-and-security-updates-released","title":{"rendered":"Szczeg\u00f3\u0142y krytycznych luk w PHP zosta\u0142y ujawnione, a poprawki zosta\u0142y opublikowane","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"
Opublikowano poprawki do PHP 8.5.12, 8.4.27, 8.3.36 i 8.2.35, a tak\u017ce \u0142atki dla ju\u017c nie wspieranych ga\u0142\u0119zi PHP 7.4, PHP 8.0 i PHP 8.1 (wra\u017cliwe wersje od 5.4 do 7.3 pozostaj\u0105 bez poprawek), w kt\u00f3rych naprawiono dwie krytyczne luki bezpiecze\u0144stwa:<\/p>\n
\n
CVE-2026-109618 \u2014 zdalne wykonanie kodu spowodowane tym, \u017ce w przypadku wyczerpania dost\u0119pnej pami\u0119ci wolnej dla procesu, obs\u0142uga braku pami\u0119ci przez wywo\u0142anie funkcji longjmp() mo\u017ce przerwa\u0107 interpretator PHP w stanie, w kt\u00f3rym tylko cz\u0119\u015b\u0107 wewn\u0119trznych struktur zwi\u0105zanych z przetwarzaniem \u017c\u0105dania zosta\u0142a zainicjowana. W nast\u0119pstwie funkcja ko\u0144cz\u0105ca przetwarzanie \u017c\u0105dania odnosi si\u0119 do tych struktur jak do ju\u017c zainicjowanych, mimo \u017ce pami\u0119\u0107 dla nich nie zosta\u0142a przydzielona.\n
G\u0142\u00f3wnym wektorem ataku jest manipulacja \u017c\u0105daniami multipart w celu stworzenia warunk\u00f3w do wyczerpania dost\u0119pnej pami\u0119ci procesu. Aby obej\u015b\u0107 limit post_max_size, nag\u0142\u00f3wek Content-Length mo\u017ce nie by\u0107 uwzgl\u0119dniony, a do przesy\u0142ania mo\u017ce by\u0107 wykorzystana ogromna liczba nag\u0142\u00f3wk\u00f3w HTTP. Mo\u017cliwe jest prowadzenie te\u017c punktowych atak\u00f3w na konkretne operacje w aplikacjach PHP, kt\u00f3re nadmiernie zu\u017cywaj\u0105 pami\u0119\u0107. Obecno\u015b\u0107 exploita potwierdzono dla mod_php, poniewa\u017c wywo\u0142uje on funkcj\u0119 shutdown() nawet w przypadku awarii. PHP-FPM w przypadku awarii zako\u0144czy proces potomny, co utrudnia przeprowadzenie ataku, ale teoretycznie go nie wyklucza. <\/p>\n
CVE-2026-109619 \u2014 zdalne wykonanie kodu spowodowane dost\u0119pem do pami\u0119ci po jej zwolnieniu z powodu niew\u0142a\u015bciwego czyszczenia globalnego stanu powi\u0105zanego z konkretnym \u017c\u0105daniem. W przypadku przerwania \u017c\u0105dania z powodu b\u0142\u0119du krytycznego, przekroczenia limitu czasu lub braku pami\u0119ci, globalny stan mo\u017ce pozosta\u0107 nieczyszczony, a wska\u017aniki b\u0119d\u0105 aktywne, mimo \u017ce pami\u0119\u0107, na kt\u00f3r\u0105 wskazuj\u0105, zosta\u0142a zwolniona. Podczas przetwarzania nast\u0119pnego \u017c\u0105dania w tym samym procesie mo\u017ce wyst\u0105pi\u0107 dost\u0119p przez pozosta\u0142y wska\u017anik do starego globalnego stanu.\n
Do eksploatacji mo\u017cna wykorzysta\u0107 tworzenie warunk\u00f3w wyczerpania dost\u0119pnej pami\u0119ci podczas przetwarzania \u017c\u0105da\u0144 multipart w kodzie do wskazywania post\u0119pu \u0142adowania (session.upload_progress). Przy tym jako g\u0142\u00f3wny i potwierdzony wektor ataku wymienia si\u0119 obs\u0142ug\u0119 fatal_error_backtraces w PHP 8.5, kt\u00f3ra nie resetuje stanu \u015bledzenia przy zako\u0144czeniu. W pierwszym przypadku atak jest mo\u017cliwy na mod_php i PHP-FPM, a w drugim tylko na mod_php. M\u00f3wi si\u0119 r\u00f3wnie\u017c o niepotwierdzonej mo\u017cliwo\u015bci przeprowadzenia ataku w konfiguracjach, w ustawieniach kt\u00f3rych znajduj\u0105 si\u0119 dyrektywy prowadz\u0105ce do wy\u015bwietlania ostrze\u017ce\u0144 na wczesnym etapie przetwarzania \u017c\u0105dania (na przyk\u0142ad ostrze\u017cenia o u\u017cywaniu przestarza\u0142ych parametr\u00f3w).<\/p>\n<\/ul>\n
Zg\u0142oszono, \u017ce ca\u0142kowite zablokowanie luk jest mo\u017cliwe tylko poprzez zainstalowanie aktualizacji. Nast\u0119puj\u0105ce \u015brodki zmniejszaj\u0105 prawdopodobie\u0144stwo udanego przeprowadzenia atak\u00f3w, ale nie czyni\u0105 systemu ca\u0142kowicie bezpiecznym:<\/p>\n
\n
Ustawienie w php.ini parametru \u201ememory_limit=-1\u201d, co utrudnia mo\u017cliwo\u015b\u0107 atakuj\u0105cego kontrolowa\u0107 wyczerpanie limit\u00f3w pami\u0119ci.\n
Ustawienie parametru \u201epost_max_size = 8M\u201d, je\u015bli nie ma potrzeby przesy\u0142ania du\u017cych plik\u00f3w. Warto\u015b\u0107 parametru \u201eupload_max_filesize\u201d powinna by\u0107 mniejsza ni\u017c warto\u015b\u0107 parametru \u201epost_max_size\u201d.\n
Ustalenie limitu na dozwolone zu\u017cycie pami\u0119ci na poziomie systemowym, poprzez cgroup memory.max lub parametry zu\u017cycia pami\u0119ci kontenera, ale nie poprzez systemowe limity RLIMIT_AS i RLIMIT_DATA, kt\u00f3re jedynie prowokuj\u0105 problemowe wywo\u0142anie longjmp().\n
Je\u015bli wydajno\u015b\u0107 nie jest istotna, mo\u017cna ograniczy\u0107 liczb\u0119 \u017c\u0105da\u0144 przetwarzanych przez jeden proces roboczy poprzez pm.max_requests=1 w PHP-FPM i MaxRequestsPerChild w Apache httpd.\n