PHP zaif serverlarda autentifikatsiyasiz hujumchilarga kod ijro etish imkonini berishi mumkin bo'lgan ikkita muhim zaiflikni bartaraf etish uchun shoshilinch xavfsizlik yangilanishlarini e'lon qildi.
Ushbu zaifliklar CVE-2026-109618 va CVE-2026-109619 sifatida kuzatiladi va har ikkalasi CVSS v4.0 bo'yicha 9.2 ballga ega. Tuzatishlar PHP 8.5.12, 8.4.27, 8.3.36 va 8.2.35 versiyalariga kiritilgan.
Administratorlar darhol yangilanishlari kerak, chunki faqat konfiguratsiya o'zgarishlari bilan xavfni to'liq bartaraf etib bo'lmaydi.
PHP loyihasi veb-so'rovlarni xizmat qiladigan barcha o'rnatishlarni potentsial xavf ostida deb hisoblaydi, jumladan PHP-FPM, Apache mod_php, php-cgi, FrankenPHP va LiteSpeed.
Ular orasida Apache mod_php eng yuqori isbotlangan xavfni taqdim etadi: tadqiqotchilar autentifikatsiyasiz so'rovlar orqali ilova kodi ishga tushishidan oldin kod ijro etishga erishgan. Muvaffaqiyatli ekspluatatsiya zararli kodni veb-ishchi hisobining huquqlari bilan ishlashiga imkon beradi.
CVE-2026-109618 PHPning xotira tugashi (OOM) sharoitlarini qayta ishlashiga ta'sir qiladi. Avval PHP xotira ajratish muvaffaqiyatsiz bo'lganda ijroni to'xtatish uchun longjmp() dan foydalangan.
Agar bu to'xtatish so'rov ma'lumotlari qisman ishga tushirilgan holda sodir bo'lsa, keyingi o'chirish tartiblari noto'g'ri ichki tuzilmalar ustida ishlashi mumkin, bu esa xotira buzilishiga va potentsial masofaviy kod ijro etishga olib keladi.
Ko'p qismli (multipart) so'rovlarni qayta ishlash xotira tugashiga bir nechta yo'llarni taqdim etadi. Masalan, foydalanish mumkin bo'lgan Content-Length ma'lumotlari bo'lmagan so'rovlar dastlabki o'lcham tekshiruvlarini chetlab o'tishi mumkin.
Shu bilan birga, ortiqcha ko'p qismli sarlavhalar va ichki fayl metama'lumotlari nomutanosib xotira iste'mol qilishi mumkin. Apache mod_php ishga tushirish muvaffaqiyatsizliklaridan so'ng shartsiz so'rovni o'chirishni amalga oshiradi, bu esa ilova mantig'i boshlanishidan oldin buzilgan holatni ochib qo'yadi.
Tuzatish OOM qayta ishlashni o'zgartiradi: keskin muvaffaqiyatsizlikni virtual mashinaning xavfsiz nuqtasida sodir bo'ladigan kechiktirilgan, yumshoq muvaffaqiyatsizlik bilan almashtiradi. Shuningdek, yuqoriroq xotira chegarasi _exit() orqali jarayonni darhol tugatishni ishga tushiradi, bu esa xotira nazoratini saqlab qolgan holda xavfsiz tozalashni oldini oladi.
CVE-2026-109619 so'rovga tegishli xotiraga tegishli bo'lib, bu xotira bo'shatilgandan keyin doimiy ishchi global o'zgaruvchilari tomonidan murojaat qilinadi. Fatal xatolar yoki kechki o'chirish diagnostikalari keyingi so'rovlar uchun eskirgan xato, sessiya, obyekt yoki kengaytma holatini qoldirishi mumkin.
Ekspluatatsiya bir operatsiya eskirgan holatni qoldirishi va xuddi shu ishchi tomonidan qayta ishlanadigan boshqa so'rov global o'zgaruvchilarni qayta ishga tushirishdan oldin uni iste'mol qilishi kerak. Tasdiqlangan yo'llar PHP 8.5 dagi fatal-xato izlari (backtraces) va sessiya yuklash jarayoni qayta ishlashini o'z ichiga oladi.
Tadqiqotchilar mod_php ga qarshi masofaviy kod ijro etish mumkinligini va maxsus ilovaga bog'liq sessiya yo'llari orqali PHP-FPM ga qarshi ham mumkinligini tasdiqlagan. Bir nechta ishchilardan foydalanish har bir so'rov bo'yicha muvaffaqiyatli ekspluatatsiya ehtimolini kamaytirishi mumkin, lekin zaiflikni butunlay bartaraf etmaydi.
Administratorlar o'z filiallari uchun tuzatilgan PHP relizini o'rnatishlari yoki orqaga moslashtirilgan tuzatishlarni o'z ichiga olgan sotuvchi paketlarini olishlari kerak. PHP 8.1 va undan eski versiyalar endi yuqori darajadagi yangilanishlarni olmaydi; ta'sirlangan operatorlar o'z tarqatish yoki LTS provayderi bilan maslahatlashishlari yoki qo'llab-quvvatlanadigan relizga ko'chishlari kerak.
Vaqtinchalik choralar session.upload_progress.enabled ni va PHP 8.5 da fatal_error_backtraces ni o'chirishni, so'ngra barcha ishchilarni qayta ishga tushirishni o'z ichiga oladi. Bu o'zgarishlar tasdiqlangan ekspluatatsiya yo'llarini to'sadi, lekin har bir potentsial variantni emas. Ko'rsatiladigan xatolarni bostirish eskirgan holat ekspluatatsiyasini oldini olmaydi.
OOM ta'sirini bartaraf etish uchun memory_limit=-1 ni joriy etish bashorat qilinadigan PHP xotira-chegarasi triggerini oldini oladi, lekin asosiy ajratish muvaffaqiyatsizliklari hali ham mumkin.
Konservativ so'rov chegaralarini joriy etish va konteyner yoki cgroup chegaralaridan foydalanish ta'sir va mavjudlik xavflarini kamaytirishga yordam beradi. PHP RLIMIT_AS yoki RLIMIT_DATA ni almashtirishdan aniq ogohlantiradi, chunki bu zaif ajratish muvaffaqiyatsizliklarini ishga tushirishi mumkin. Yangilanish ta'sirlangan o'rnatishlar bo'yicha har ikkala zaiflik uchun yagona to'liq yechim bo'lib qoladi.
PHP released emergency security updates to address two critical vulnerabilitiesthat could allow unauthenticated attackers to execute code on vulnerable servers.
These vulnerabilities are tracked as CVE-2026-109618 and CVE-2026-109619, and both have a CVSS v4.0 score of 9.2. The fixes are included in PHP versions 8.5.12, 8.4.27, 8.3.36, and 8.2.35.
Administrators should update immediately, as configuration changes alone cannot fully eliminate exposure.
The PHP project considers all installations serving web requests to be potentially at risk, including PHP-FPM, Apache mod_php, php-cgi, FrankenPHP, and LiteSpeed.
Among these, Apache mod_php presents the highest demonstrated risk: researchers have been able to achieve code execution through unauthenticated requests before any application code executes. Successful exploitation allows malicious code to run with the privileges of the web worker account.
CVE-2026-109618 impacts PHP’s handling of out-of-memory (OOM) conditions. Previously, PHP used longjmp() to abandon execution when memory allocation failed.
If this interruption occurred while request data remained partially initialized, subsequent shutdown routines could operate on invalid internal structures, leading to memory corruption and potential remote code execution.
Multipart request processing offers several pathways to memory exhaustion. For example, requests lacking usable Content-Length information can bypass initial size checks.
At the same time, excessive multipart headers and nested file metadata can consume disproportionate memory. Apache mod_php performs an unconditional request shutdown after startup failures, exposing a corrupted state before application logic begins.
The patch modifies OOM handling by replacing the abrupt failure with a delayed, graceful failure that occurs at a safe point in the virtual machine. Additionally, a higher memory threshold triggers immediate process termination through _exit(), preventing unsafe cleanup while maintaining memory controls.
CVE-2026-109619 relates to request-owned memory that is referenced by persistent worker globals after that memory has been freed. Fatal errors or late shutdown diagnostics can leave stale error, session, object, or extension state available for subsequent requests.
Exploitation requires one operation to leave the stale state and another request, handled by the same worker, to consume it before initialization resets the globals. Confirmed paths include fatal-error backtraces in PHP 8.5 and session upload progress processing.
Researchers have validated that remote code execution is possible against mod_php and, through specific application-dependent session paths, PHP-FPM. Using multiple workers might reduce the chance of successful exploitation per request, but does not eliminate the vulnerability.
Administrators should deploy the corrected PHP release for their branch or obtain vendor packages containing backported fixes. PHP versions 8.1 and older no longer receive upstream updates; affected operators should consult their distribution or LTS provider, or migrate to a supported release.
Temporary measures include disabling session.upload_progress.enabled and, on PHP 8.5, fatal_error_backtraces, followed by restarting all workers. These changes will block confirmed exploitation paths, but not every potential variant. Suppressing displayed errors does not prevent exploitation of the stale state.
To address OOM exposure, enforcing memory_limit=-1 avoids the predictable PHP memory-limit trigger but still allows for underlying allocation failures.
Implementing conservative request limits and using container or cgroup boundaries can help reduce exposure and availability risks. PHP explicitly warns against replacing RLIMIT_AS or RLIMIT_DATA, as this may trigger vulnerable allocation failures. Updating remains the only complete solution for both vulnerabilities across affected deployments.
Stops Cyber threats before impact with 21 min faster MTTR. Integrate ANYRUN’s Sandbox in your SOC.