Сигурностна актуализация на PHP 2026: наръчник за отстраняване на PHP2Shell (CVSS 9.2)

Самото разкриване беше необичайно. На 20 октомври сигурностният екип на PHP публикува предварително уведомление, насрочи изданието за 21 октомври в 14:00 UTC и си запази правото да го пусне и по-рано. Идентификаторите CVE изтекоха ден преди официалното оповестяване, заедно с преувеличени твърдения за тежестта и засегнатите версии. Доставчиците на дистрибуции вече бяха получили пачовете за своите платформи, а националните CERT екипи започнаха да публикуват насоки още преди кодът да е станал публичен. С други думи: щом изданието излезе, никой нямаше легитимно извинение за забавяне.

Два дефекта, едно извънредно издание

Нито единият от двата дефекта не е логическа грешка в приложението. И двата се коренят в начина, по който PHP подготвя и приключва една заявка, и точно затова нито обновяване на рамка, нито на плъгин, нито правило на WAF може да замести надграждането на интерпретатора.

CVE-2026-109618 — RCE чрез повреда при изчерпване на паметта. Когато PHP свърши паметта, той прекратява заявката, вместо да продължи. Бюлетинът описва път, при който това прекратяване прекъсва PHP в момент, в който вътрешните данни за заявката са инициализирани само частично, така че по-късната стъпка за почистване на заявката взема невалидните данни за валидни. Атакуващ, който успее да изтласка използването на паметта до лимита, може да насочи това, което ще се случи след него. Точно този дефект прави препоръките за смекчаване толкова противоинтуитивни: производителят иска от администраторите да попречат на PHP да достига собствения си таван на паметта, а не да го затега.

CVE-2026-109619 — RCE чрез остатъчно глобално състояние. Вътрешно състояние, собственост на една заявка, може да оцелее и след освобождаването на паметта зад него. Следващата заявка, поета от същия работен процес, може да използва това остатъчно състояние, преди нормалната инициализация да го нулира. При дълго живеещ работен процес — а точно такива са PHP-FPM, mod_php и LiteSpeed — преизползването на паметта е нормално и постоянно условие, което означава, че не става дума за изключение при екзотични настройки.

Името PHP2Shell не е официално обозначение на PHP проекта; наложиха го изследователи и сигурностни компании, така че ще го срещнете в изхода на скенери, хостинг бюлетини и съвети на CERT, отнасящи се точно до тези два CVE.

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

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

Ако хоствате WordPress, WooCommerce, Laravel, Magento, ERP системи от типа на Magento или който и да е PHP портал за резервации на вашия търговски бизнес, попадате в първите три реда дори когато кодът на приложението е безупречен. За по-широк поглед към въпроса кой изобщо трябва да управлява рантайма, вижте нашия наръчник за IT аутсорсинг в Турция.

Проверете версията си за две минути

Капанът тук е аритметиката на версиите. Дистрибуциите поддържат PHP 8.3.6 или 8.2.x с години и бакпортират сигурностните поправки в същия видим номер на версията, така че php -v само по себе си не показва дали сте защитени. Сравнете три неща.

1. Видимата PHP версия и SAPI компонентът, който обслужва трафика.

2. Версията на пакета от дистрибуцията, а не тази от ъпстрийм. При Debian и Ubuntu честният отговор е дневникът с промените; при RPM системите проверете дневника на пакета.

Ако дневникът с промените споменава и двата CVE в инсталираната версия, значи сте пачнати, макар php -v все още да отчита 8.3.6. Това е разликата между истински отговор по сигурността и суеверие в номерата на версиите.

3. Дали работещият процес е заредил наново пачнатия двоичен файл. Обновяване на пакет, което не е последвано от рестарт, оставя стария код в паметта. Сравнете времето на стартиране на услугата с времето на инсталиране на пакета:

При cPanel, Plesk, DirectAdmin или управлявана платформа еквивалентът е PHP селекторът плюс собственият бюлетин за сигурност на хоста: установете вградената версия, към която сайтът ви реално е разпределен, а не най-новата, рекламирана в панела. Ако вашият хост не може да посочи дата на пача, приемете сайта за непачнат. Нашите услуги за цифрова инфраструктура обхващат този одит заедно със самото надграждане; може и просто да се свържете с нас с вашия стек и ще ви кажем какво бихме проверили.

Поправени версии и пропастта на края на поддръжката

PHP поддържа всеки клон две години активно разработване и още две години само сигурностни поправки. Тази политика породи четирите едновременни поправки на 21 октомври — и точно тя оставя по-старите клонове сами на себе си.

Два практически предупреждения от бюлетина. Първо, ако инсталирате PHP от общностно хранилище, а не от вашата дистрибуция, такова хранилище може да изостава от сигурностния прозорец: поддържащите на широко използваните Remi пакети заявиха, че няма да имат обновявания в самия ден, така че безопасният път са пакетите на вашата дистрибуция или собствена компилация от изходен код. Второ, ако сте на PHP 8.1 или по-стар, „изчакваме нашия хост“ е решение по сигурността, което вземате вместо вашите клиенти — или го документирайте, или го сменете.

Пачване на производствен сървър без инцидент

Сигурностните обновявания в рамките на един минор рядко чупят приложение; непроверените рестарти точно това правят. Редът по-долу е този, който използваме на живи търговски платформи, и той държи прозореца за риск кратък, без да залагаме сайта на карта.

1. Първо снапшот. Снапшот на хипервайзор или том, чиято функция за възстановяване наистина сте тествали, връща системата за минути и превръща решението да пачнете в евтино решение.
2. Възпроизведете версията в тестова среда. Същият клон, същите разширения, същите конфигурационни файлове на PHP, копие на производствените данни. Пробвайте потоките за поръчка, запитване за оферта и плащане, а не само началната страница.
3. Надградете набора пакети като едно цяло. Смесването на надграден CLI със стар двоичен файл на FPM е рецептата хората да останат с пачнат php -v и непачнат уеб път: apt-get update && apt-get install --only-upgrade 'php8.3-*' или dnf update --security 'php*' при RPM базирани хостове.
4. Рестартирайте процеса, обслужващ заявките, и после проверете, че се е рестартирал. systemctl restart php8.3-fpm (или презаредете Apache / рестартирайте LiteSpeed), след което проверете отново времето на стартиране на услугата и изпълнете още веднъж заявките за версията и за дневника с промените.
5. Наблюдавайте журнала за грешки в продължение на час. Съобщения за изчерпена памет, нови сигнатури на фатални грешки и необичайни нива на 5xx са сигналите, че настройките за смекчаване по-долу може да се нуждаят от донастройване — а не причините да отложите надграждането.
6. Запазете доказателствата. Версия на пакета, ред от дневника с промените, споменаващ и двата CVE, момент на рестарта. Клиенти, одитори и прегледи на контроли в стила на ISO 27001 питат точно за това, а запазването им отнема десет секунди.

Когато надграждането наистина трябва да почака — валидирана ERP интеграция, ембарго върху календара на изданията, цикъл на одобрение от клиент — сложете пред него компенсиращ контрол още същия ден, вместо да оставите порта отворен и да се надявате на добро. Точно това препоръчаха бюлетините на националните CERT екипи за точно такава ситуация: изолирайте PHP приложенията, изложени на интернет, от публичната мрежа, когато незабавното пачване е невъзможно.

Временни мерки: стеснете прозореца, не го затваряйте

Бюлетинът на PHP го казва прямо: пълно смекчаване няма и обновяването е единственият безопасен избор. Възприемете следното като защита за дни, не за седмици, приложена на ниво, което приложението не може да отмени, при последващ рестарт на всички работни процеси.

Срещу CVE-2026-109618 (пътят при изчерпване на паметта)

• Оставете PHP да изчерпва паметта на машината, вместо собствения си лимит: memory_limit = -1, най-добре като php_admin_value memory_limit = -1, така че кодът на приложението да не може да върне тавана обратно.
• Дръжте телата на заявките малки при самия интерпретатор: насоката в бюлетина е около 8 MB, когато няма качване на файлове, и около 32 MB, когато има, като upload_max_filesize стои под post_max_size.
• Налагайте скъпите ограничения на проксито, защото поражението идва от декодираната заявка, а не от размера по мрежата: общ размер на декодираното тяло, брой входни полета, брой multipart части, брой хедъри, дълбочина на вложеност — и обхванете заявките, пристигащи без използваем Content-Length.
• Ограничете радиуса на поражение с лимит на паметта в контейнер или cgroup, оразмерен така, че прекратеният работен процес да е събитие за достъпността, а не за целия хост. Не го замествайте с RLIMIT_AS или RLIMIT_DATA: те задействат точно провала при заделяне на памет, който седи в уязвимия път.

Срещу CVE-2026-109619 (пътят с остатъчното състояние)

• Изключете проследяването на качването в сесиите чрез session.upload_progress.enabled = 0, зададено в php.ini, в пула на FPM или в конфигурацията на сървъра — място, което действа преди самата обработка на заявката. След това рестартирайте всички работни процеси, защото FPM споделя вече инициализираното състояние на модулите между заявките. ini_set() и .user.ini идват твърде късно, за да помогнат.
• При PHP 8.5 задайте fatal_error_backtraces = 0 и рестартирайте.
• Премахнете настройките за отделна заявка, които са невалидни или остарели и затова излъчват диагностика по време на ранната инициализация. Потискането на съобщението чрез error_reporting, display_errors или @ не премахва кодовия път.
• Издирвайте фатални грешки, достижими за атакващия, и дълго изпълняващи се таймаути в обработчиците за качване и импорт, в callback код и в почистващите процедури — същите места, където живеят и двата дефекта.

CDN или WAF пред origin сървъра също си заслужават: ограничаването на честотата, блокирането на аномални форми на заявки и виртуалните пачове намаляват шума и забавят опортюнистичното сканиране. За прицелен атакуващ те са само неравност по пътя, а не контрол, който можете да отчетете като отстраняване.

Какво да попитате хостинг доставчика си днес

Скриптовете за поддръжка отговарят на този въпрос с „при нас всичко е пачнато“. Поискайте вместо това доказателства, които можете да подредите в досието си:

• Вградената PHP версия, разпределена към нашия профил, и дали е пакет от дистрибуция или билд на доставчик.
• Датата, на която поправките за CVE-2026-109618 и CVE-2026-109619 са достигнали вашия сървърен парк, заедно с вътрешния низ за версията на пакета.
• Дали поправката важи за SAPI интерфейса, обслужващ нашия сайт (FPM, LiteSpeed, mod_php), и за евентуални staging или резервни възли, от които бихме възстановявали.
• Ако платформата още не е пачната: какъв компенсиращ контрол е приложен и до кога.
• Постоянната ви политика за клоновете с изтичаща поддръжка — какво става с сайта ми на 1 януари 2027 г., когато спира сигурностната поддръжка на PHP 8.2.

Доставчик, който отговори на тези пет въпроса в един имейл, е доставчик, когото си струва да запазите. Такъв, който отвърне с маркетингов текст, е повод за разговор за миграция; същата взискателност прилагаме и в нашата работа по оценката на пропуските по ISO 27001, където крайният резултат е доказателство, а не успокоение.

Трябва ли да приемете, че сте били компрометирани?

Не автоматично — но проверете, вместо да гадаете, особено ако сървърът е бил достъпен от публичния интернет през прозореца преди вашия пач.

• Търсете процеси, слушащи портове и cron записи, които не сте създавали, и изходящи връзки от потребителската сметка, под която работи PHP работният процес.
• Сравнете записваемите директории на приложението спрямо еталонното състояние на внедряването: нови PHP файлове, променени директории за качени файлове, неочаквано изпълними временни папки.
• Претърсете уеб журналите за серии заявки около часовете на оповестяването, необичайно големи multipart тела или заявки, върнали 500 със сигнатури на OOM в журнала за грешки на PHP.
• Проверете, че пачнатият двоичен файл реално работи — сравнението на времената на рестарта по-горе дава отговора.
• Ако нещо изглежда нередно, отнесете се към него като към инцидент: запазете диска и журналите, подменете всички идентификационни данни, които приложението може да прочете, и възстановете от гарантирано чист образ. Преинсталирането на PHP пакета върху компрометиран хост не е отстраняване на инцидента.

Работен пример от собствената ни инфраструктура

Поддържаме worldwidetradex.com на Ubuntu 24.04 LTS с nginx и PHP-FPM, затова на 22 октомври приложихме горните проверки към самите себе си. Резултатите илюстрират добре защо аритметиката на версиите има значение:

Урокът се пренася към всеки стек: вашата сигурност е версията на пакета плюс дневникът с промените плюс рестартът, а не маркетинговият низ с версията в хостинг панела.

Направете пачването рутина, а не героизъм

PHP2Shell няма да остане в паметта, защото е екзотичен; ще остане, защото интерпретаторът, на който работи по-голямата част от уеб, имаше критичен дефект, сработващ преди автентикация, и хиляди хостове трябваше да реагират в рамките на часове. Екипите, които спокойно го преспаха, не бяха просто късметлии — те имаха автоматизация.

• Автоматично изпълнявани сигурностни обновявания на интерпретатора, при които версията и рестарта се записват автоматично.
• Инвентар, който знае с какъв SAPI и с какъв клон на PHP работи всеки сайт, включително staging средите, бекъпите и оня WordPress от 2019 г.
• Репетиран път за възстановяване, така че „пачвай сега“ никога да не се мери срещу „не можем да върнем назад“.
• План за клоновете: нищо да не стои на PHP версия, чиято сигурностна поддръжка приключва в следващите дванадесет месеца.
• По един изрично назначен отговорник за сървър и писмен маршрут за ескалация за дните, в които пач се приземява в 14:00 UTC в сряда.

Ако предпочитате да купите тази способност, вместо да наемате хора за нея, ние поемаме изцяло производствени PHP платформи — ритъм на пачване, мониторинг, бекъпи и документирани възстановявания — като част от нашата работа по управлявана инфраструктура. Започнете с кратко задание и обеми: поискайте оферта.

Често задавани въпроси

Източници

• PHP — сигурностен бюлетин „Критични уязвимости за отдалечено изпълнение на код, актуализирайте сега“ и съобщенията за изданията от 21 октомври 2026 г., включително насоките за смекчаване и графикът на поддръжка на поддържаните версии.
• Съветите за сигурност на GitHub за хранилището на PHP: GHSA-w8hw-w9fx-j79w (CVE-2026-109618) и GHSA-6wmf-4rv5-p3rp (CVE-2026-109619).
• CERT-EU — Security Advisory 2026-018, „Критични уязвимости в PHP“, назоваващ и двата CVE.
• Infosecurity Magazine — „Критични PHP уязвимости изтекоха преди планираните сигурностни пачове“ (21 октомври 2026 г.) и „Опит за експлоатация на PHP2Shell, открит от Amazon четири дни преди разкриването на уязвимостта“ (22 октомври 2026 г.).

Искате надграждането да бъде поето вместо вас? За да обсъдите пачването, одит на версиите, миграция към управлявана и пачната PHP платформа или инфраструктурата около нея, свържете се с нас или се обадете на +90 505 679 78 03.