Критични пробиви в PHP: какво трябва да направят собствениците на сайтове

Две критични уязвимости в PHP, известни под общото име PHP2Shell, предизвикаха спешни предупреждения към администраторите на сайтове и уеб приложения. Проблемите могат да позволят на нападател без потребителски акаунт да изпълнява код на засегнат сървър. Поправките бяха публикувани на 21 октомври, а разработчиците на PHP призовават за незабавно обновяване.

Уязвимостите са обозначени като CVE-2026-109618 и CVE-2026-109619. Всяка има оценка 9,2 от 10 по CVSS 4.0, което ги поставя в критичната категория. CERT-EU препоръчва незабавно инсталиране на поправките, а когато това не е възможно – да се обмисли временно изолиране на публично достъпните приложения до отстраняване и проверка на проблема.

Защо проблемът е по-широк от уязвимост в отделен сайт

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

Изследователите от Wiz съобщават, че са демонстрирали изпълнение на код без автентикация срещу инсталации на WordPress, Drupal и Joomla с актуалните към момента на тестовете им контейнерни образи. Те подчертават, че тези платформи са примери за въздействието, а не източникът на дефекта. Дори минимално приложение може да бъде уязвимо при съответните условия.

Практическото следствие за собствениците на сайтове е съществено: обновяването на WordPress, темата или плъгините само по себе си не отстранява PHP2Shell. Необходима е актуализация на PHP от администратора на сървъра или хостинг доставчика.

Как работят двете уязвимости

Двата проблема са свързани с управлението на паметта и поведението на PHP при прекъсване на обработката на заявка.

При CVE-2026-109618 достигането на лимита за памет може да прекъсне изпълнението в момент, когато част от вътрешните структури още не са напълно подготвени. Последващото почистване на заявката може да обработи тези невалидни данни като валидни и да доведе до повреждане на паметта. Официалният анализ описва и промяна в начина, по който PHP обработва подобни ситуации, така че прекъсването да не оставя опасно вътрешно състояние.

При CVE-2026-109619 вътрешни препратки към данни могат да останат активни, след като паметта зад тях вече е освободена. Ако същият обслужващ процес поеме следваща заявка, той може да използва тези остарели препратки. Това е разновидност на проблем, известен като use-after-free – използване на памет след освобождаването ѝ. Конкретната възможност за експлоатация зависи от засегнатото вътрешно състояние и последователността на операциите.

Последиците не се ограничават до срив на сайт. Wiz съобщава и за демонстрирано четене на чувствителна информация от паметта на PHP процеса, включително пароли, токени за достъп и API ключове, без непременно да се стига до изпълнение на чужд код. Същевременно работеща атака срещу една конфигурация може да изисква значителни промени, за да успее срещу друга.

Кои сървъри са изложени на риск

Разработчиците предупреждават за всички засегнати PHP инсталации, обслужващи уеб заявки, включително PHP-FPM, Apache с mod_php, php-cgi, FrankenPHP и LiteSpeed.

Като най-рискова конфигурация е посочен Apache с mod_php. При нея е демонстрирана атака, която може да бъде задействана от заявка без автентикация още преди изпълнението на кода на самото приложение. Използването на PHP-FPM обаче не е основание актуализацията да се пропуска.

Google Cloud посочва засегнати издания, започващи от PHP 5.4. Компанията уточнява, че собствената ѝ облачна инфраструктура не е уязвима, но PHP приложенията, които клиентите изпълняват върху нея, могат да бъдат. Дали обновяването става автоматично зависи от конкретната услуга и начина на внедряване.

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

За поддържаните стабилни клонове са публикувани следните коригирани издания:

По-старите версии в тези клонове трябва да бъдат актуализирани или да получат съответната поправка чрез доставчика на пакетите. Linux дистрибуциите и доставчиците на дългосрочна поддръжка са получили корекциите предварително.

PHP 8.1 и по-старите клонове вече не получават обичайните актуализации от проекта. Някои външни доставчици предоставят пренесени поправки. Заради тежестта на случая PHP екипът е публикувал и минимални корекции в изходния код за PHP 7.4, 8.0 и 8.1, предназначени за организации, които компилират сами или нямат доставчик на такава поддръжка. Това не означава възстановяване на редовната поддръжка на тези версии.

Вече има наблюдавани опити за атаки

Cloudflare съобщава за атакуващ трафик към свои клиенти и за промени в изпращаните заявки, с които нападателите се опитват да заобиколят защитите. Компанията е внедрила правила за своята защитна стена за уеб приложения, включително за безплатните планове с активиран WAF. Тя изрично препоръчва PHP да бъде обновен въпреки наличието на този допълнителен защитен слой.

AWS публикува и данни за по-ранна активност. При ретроспективен анализ на системата си от примамки MadPot Amazon Threat Intelligence е открила опит за експлоатация от 17 октомври – четири дни преди публичното разкриване. Компанията уточнява, че не е ясно как извършителят е получил информация за атаката и дали ранните опити биха успели срещу реални системи. След публикуването на поправките AWS отчита допълнителни атаки и определя експлоатацията като широко разпространена.

Тези наблюдения не доказват, че всеки уязвим сайт е компрометиран. Те обаче означават, че администраторите трябва да проверяват и за предходна подозрителна активност, вместо да приемат момента на публичното съобщение за начало на риска.

Проблем със следи още от 2024 г.

PHP Foundation признава, че първите признаци за проблема с изчерпването на паметта са открити още през 2024 г., при работа след външен одит на Quarkslab. Тогава е обсъждана теоретична възможност за експлоатация, но не е бил намерен конкретен работещ път за атака.

Различните предложения за поправка са имали компромиси със съвместимостта, производителността или разширенията на PHP. Фондацията определя забавянето като структурен провал, свързан с процеса за вземане на решения и недостига на ресурси. След новите доклади през август 2026 г., които показват реалното въздействие, поправката става водещ приоритет.

Каква е ролята на изкуствения интелект

Случаят показва как AI инструментите могат да променят практическата експлоатируемост на стари дефекти. Според Wiz сложността при комбинирането на грешки и приспособяването към различни конфигурации дълго е била сериозна пречка. Екипът посочва използване на Wiz Atlas, Gemini 4 Argon и GPT-5.6 Sol за изследването, разработката на демонстрации и проверката на поправките. Това е оценката на участвалите изследователи за ролята на инструментите, а не доказателство, че всяка атака вече е лесна или автоматична.

Какво трябва да направят собствениците на сайтове

За сайтове на споделен или управляван хостинг първата стъпка е потвърждение от доставчика, че използваната PHP среда е коригирана конкретно за CVE-2026-109618 и CVE-2026-109619. Automattic например обявява, че сайтовете на WordPress.com, WordPress VIP, WP Cloud, Pressable и Tumblr са защитени. Това съобщение се отнася до изброените платформи и не обхваща автоматично всички самостоятелно хоствани WordPress сайтове.

При собствени сървъри и контейнери трябва да бъдат обхванати всички работещи среди. Google изрично посочва необходимостта собствените контейнерни образи да бъдат изградени отново с поправен PHP и внедрени повторно. Обновяването на един основен сървър не променя автоматично отделно пакетирани приложения.

Ако незабавно обновяване е невъзможно, официалните препоръки включват ограничаване на определени заявки и изключване на конкретни функции. Това са временни мерки срещу отделни пътища за атака и не правят инсталацията безопасна. Промените трябва да се съобразят с приложението и инфраструктурата; CERT-EU препоръчва да се обмисли изолиране от публичната мрежа до прилагане на поправката.

Следва да се прегледат и журналите за необичайни заявки, грешки за недостиг на памет и поредици от HTTP 500 отговори. AWS препоръчва проверка за неочаквано стартиране на процеси и промени във файлове на уеб сървърите. Такива признаци изискват разследване, но поотделно не доказват успешен пробив.