Критични уязвимости в PHP (CVE-2026-109618 и CVE-2026-109619): какво се случи и какво да направите

На 21 октомври 2026 г. проектът PHP публикува корекции за две критични грешки, а CERT-EU още същия ден издаде предупреждение 2026-018. И двете са оценени с 9,2 и и двете са описани като изпълнение на код от разстояние без удостоверяване. Ако поддържате сайт на WordPress, магазин или друго приложение на PHP, това Ви засяга, а решението е обновяване, не настройка. Статията обяснява какво е известно, как атаката намира вход и какво да направите. Състояние към 22 октомври 2026 г., по версия 1.1 на предупреждението на CERT-EU.

Какво се случи

PHP обяви издание със защитни корекции на 20 октомври и публикува поправките на 21 октомври в 13:30 UTC. CERT-EU озаглави предупреждението си „Критични уязвимости в PHP“ и посочва два CVE: CVE-2026-109618 и CVE-2026-109619, всеки с оценка 9,2. CERT-EU пише още, че техническите подробности вече се обсъждат публично и че е започнал да се разпространява първият код за доказване на концепцията. Предупреждението не потвърждава атаки в реална среда, но отбелязва, че това прави по-вероятно атакуващите вече да използват грешките. Приемете го като спешно.

Кой е засегнат

Засегнати са всички издания на PHP под коригираното в поддържан клон, както и всеки клон с приключила поддръжка.

CERT-EU назовава PHP-FPM, Apache с mod_php, php-cgi, FrankenPHP и LiteSpeed. Според екипа на PHP mod_php носи най-висок риск. Засегнати могат да бъдат и продукти, които вграждат PHP; CERT-EU препраща към списък на нидерландския NCSC в края на тази статия. Брои се всяка инсталация, която обслужва уеб заявки, независимо дали има форма за качване на файлове.

Как атакуващият стига до първата грешка

Няма нужда от вход. Според CERT-EU демонстриран експлойт показва, че една-единствена заявка без удостоверяване може да задейства атаката, преди да се изпълни какъвто и да е код на приложението. Това е точката, която повечето пропускат: няма значение дали Вашият WordPress е актуален, дали добавките Ви са обновени и дали контактната Ви форма е защитена. Заявката стига първо до ядрото на PHP.

Първата грешка, CVE-2026-109618, действа така:

1. Заявка пристига на адрес, който се обслужва от PHP. Без вход, без профил.
2. PHP започва да чете тялото на заявката. CERT-EU посочва като пример разчитането на качвания на файлове чрез форми.
3. PHP налага своя memory_limit чрез longjmp(). Когато лимитът бъде надвишен, прекъсва всичко, с което се е занимавал, и приключва заявката.
4. Ако това стане по средата на подготовката на вътрешните данни на заявката, те остават само наполовина изградени.
5. Последвалото почистване приема невалидните данни за валидни и освобождава памет, която никога не е била инициализирана. В нея още може да има данни от по-ранни заделяния, които атакуващият е контролирал.
6. Оттук предупреждението описва изпълнение на код от разстояние на сървъра.

Съзнателно не описваме как атакуващият управлява последната стъпка. Достатъчно е да знаете, че входната точка не е Вашето приложение, и затова нищо в приложението не може да я спре.

Втората грешка: състояние, което надживява паметта си

CVE-2026-109619 е друг механизъм със същия резултат. PHP пази вътрешно състояние за всяка заявка. След определени откази, например фатална грешка, това състояние може да остане, макар паметта под него вече да е освободена. Следващата заявка, обработена от същия работен процес, може да използва това остаряло състояние, преди то да бъде нулирано по обичайния ред. На атакуващия са нужни две заявки, които попадат при същия работен процес; CERT-EU оценява резултата като при първата грешка: изпълнение на код от разстояние.

Какво да направите днес

1. Установете коя версия на PHP всъщност обслужва Вашия сайт. php -v в командния ред показва версията за командния ред, която може да се различава от тази на уеб сървъра. Проверете php-fpm -v, хостинг панела или страница, която извиква phpinfo(). При споделен хостинг попитайте доставчика си.
2. Обновете до коригирана версия: 8.5.12, 8.4.27, 8.3.36 или 8.2.35. Дистрибуциите често пренасят корекциите, без да сменят номера на версията, затова потърсете номерата на CVE в известието за сигурност на Вашия доставчик. При контейнери изградете образа наново от обновен базов образ. Екипът на PHP отбелязва, че rpms.remirepo.net не е имал обновления в деня на издаването, и препоръчва пакети на дистрибуцията или компилиране от изходен код.
3. Рестартирайте всеки работен процес на PHP. Обновяването на диска не променя процесите, които вече работят. Рестартирайте PHP-FPM или уеб сървъра, след което проверете отново работещата версия.
4. Ако не можете да обновите днес, изолирайте сървъра от публичните мрежи, докато корекцията не бъде приложена и проверена. CERT-EU е категоричен, че само обновяването отстранява напълно тези грешки.
5. Ако ползвате PHP 8.1 или по-стар, поискайте пренесената корекция от доставчика си или преминете към поддържан клон. За тези версии няма редовни обновления.

Заобиколни мерки, които намаляват риска, но не отстраняват грешката

CERT-EU изброява мерки, които правят атаката по-трудна. Изрично посочва, че те не правят една инсталация сигурна. Прилагайте ги, докато подготвяте обновяването, а не вместо него.

• Срещу CVE-2026-109618: задайте memory_limit=-1 по начин, който приложенията не могат да сменят, например с php_admin_value в пула на FPM, и проверете дали някой пул, директория или запис на приложение не задава отново краен лимит. Задайте нисък post_max_size (8M без качвания, 32M с качвания) и дръжте upload_max_filesize под него. Ограничете размера на заявката, броя на полетата, частите на многокомпонентната заявка, броя на заглавните полета и дълбочината на влагане на ниво уеб сървър или прокси. Използвайте лимит на паметта на контейнера или cgroup като граница за наличността, но не RLIMIT_AS или RLIMIT_DATA, които могат да предизвикат уязвимия отказ при заделяне на памет.
• Срещу CVE-2026-109619: задайте session.upload_progress.enabled=0 в php.ini, в пула на FPM или в конфигурация на сървъра, която се прилага преди разчитането на заявката (не с ini_set() или .user.ini), и рестартирайте всички работни процеси. При PHP 8.5 задайте и fatal_error_backtraces=0. Премахнете невалидните или остарели настройки за отделна заявка, които извеждат диагностични съобщения преди инициализацията, и отстранете фаталните грешки и изтичанията на времето за изпълнение, до които атакуващият може да стигне.

Какво може и какво не може да направи SilentShield

Това не е проблем с ботове и предпочитаме да го кажем направо, вместо една продуктова страница да остави друго впечатление. Атаката засяга ядрото на PHP, преди заявката да бъде видяна от нещо наше или от каквато и да е CAPTCHA, добавка или правило на защитна стена във Вашето приложение. Защита от ботове върху форма не я спира и никой не бива да Ви казва обратното. Единственото пълно решение е обновяването на PHP.

API и таблото на SilentShield не са написани на PHP. Добавката за WordPress и PHP SDK работят във Вашия собствен PHP, затова при тях обновяването трябва да стане на Вашия сървър. След като обновите, обичайната защита от ботове и от спам във формите е също толкова полезна, колкото преди; просто никога не е била отговорът на този проблем.

Източници

• CERT-EU Security Advisory 2026-018: Критични уязвимости в PHP
• Съобщение на PHP от 20 октомври 2026 г.
• GHSA-w8hw-w9fx-j79w (CVE-2026-109618)
• GHSA-6wmf-4rv5-p3rp (CVE-2026-109619)
• NCSC-NL php2shell: продукти, които вграждат PHP