PHP2Shell: критична дупка в PHP — обновете сайта си сега

На 21 октомври PHP пусна извънредна корекция за две критични уязвимости, които изследователите нарекоха PHP2Shell. Те позволяват на атакуващ да изпълни собствен код на сървъра — без парола, без акаунт и без нито една грешка в самия сайт. Засегнати са почти всички версии на PHP от последните 14 години, а първите опити за атака бяха засечени още преди корекцията да излезе. Ето какво се случи, как работи дупката и какво да проверите още днес.

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

PHP е езикът, на който работят WordPress, WooCommerce, Joomla, Drupal, OpenCart, PrestaShop и повечето сайтове по поръчка. Използва се от около 70% от сайтовете, чийто сървърен език е известен — затова всяка сериозна дупка в него засяга огромна част от интернет.

Уязвимостите са две: CVE-2026-109618 и CVE-2026-109619. Екипът на PHP ги оценява с 9,2 от 10 по скалата CVSS — категория „критична“. Ето защо са толкова сериозни:

• Не е нужен вход. Атаката се прави с обикновени HTTP заявки към сайта, без потребител и парола.
• Проблемът е в самия PHP, а не във WordPress, темата или плъгините. Изследователите показват, че дори страница, която само изписва „Hello World“, може да е уязвима.
• Засегнати са всички начини, по които PHP работи с уеб сървър — PHP-FPM, Apache mod_php, php-cgi, LiteSpeed и FrankenPHP. Най-рискова е конфигурацията с Apache mod_php, където атаката може да успее, преди кодът на сайта изобщо да се изпълни.
• Могат да изтекат тайни. Освен изпълнение на код, един от вариантите позволява да се прочете част от паметта на сървъра — а там може да има пароли, API ключове, токени и сертификати.

Каква е дупката — обяснено без жаргон

И двете уязвимости идват от едно и също място: какво прави PHP, когато нещо се обърка по средата на заявка.

CVE-2026-109618: когато паметта свърши

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

CVE-2026-109619: остатъците от предишната заявка

Един PHP процес („работник“) обслужва много заявки една след друга. След фатална грешка част от вътрешното му състояние може да оцелее, макар паметта, към която сочи, вече да е освободена. Следващата заявка, попаднала в същия работник, използва тези остатъци, преди да бъдат нулирани — а атакуващият може да ги подготви предварително.

Представете си маса в ресторант, която не е разчистена между двама клиенти. Предишният е оставил фалшива бележка с поръчка, а сервитьорът я взима заедно с поръчката на новия клиент, без да провери откъде е дошла.

Не е нужно сайтът ви да има грешка. Достатъчно е да работи на необновен PHP.

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

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

Уязвим е всеки PHP от версия 5.4 (2012 г.) насам, който не е обновен след 21 октомври 2026 г. Поправката е в следните версии:

Важна подробност: дистрибуциите на Linux и платформи като CloudLinux често вграждат поправката, без да сменят номера на версията. Затова по-стар номер в панела на хостинга не означава непременно, че сте уязвими. Ако се съмнявате, попитайте хостинга дали е приложил корекцията от 21 октомври.

След обновяването всички PHP процеси трябва да се рестартират. Иначе работниците, стартирани преди това, продължават да обслужват заявки със стария код.

Атакува ли се вече?

Да, опити има. Amazon засича първия опит за атака в своите капани за хакери (т.нар. honeypots) още на 17 октомври — четири дни преди корекцията. Cloudflare съобщи за ранни атаки и пусна временни правила в защитната си стена, а watchTowr регистрира опити за използване и на двете уязвимости броени часове след публикуването на пача. До 23 октомври към атаките се присъединиха и оператори на ботнети от типа Mirai.

Добрата новина е, че към 23 октомври няма потвърден успешен пробив, а публично разпространените експлойти работят основно срещу слабо защитени, тестови конфигурации. Лошата е, че изследователи вече са създали версия, която заобикаля защитата на паметта ASLR и работи при стандартните настройки на работещ сървър. Въпрос на време е подобни инструменти да стигнат до масовите атаки.

Мащабът е огромен: по анонимни данни на Qualys от около 12 000 клиента около 71% от PHP инсталациите в тяхната извадка работят на версии от 5.4 до 8.1, които вече не получават официални корекции.

На 23 октомври беше обявена и трета, по-малко опасна уязвимост — CVE-2026-115560. Тя засяга само необичайно конфигурирани приложения, затова поправката ѝ ще дойде със следващото редовно обновяване на PHP.

Най-⁠интересното: дупка на 14 години, намерена с изкуствен интелект

Кодът, в който е грешката, съществува от PHP 5.4 — версия, пусната през 2012 г. Една от грешките дори е била забелязана при одит през 2024 г., но не е поправена: разработчиците не са постигнали съгласие за решение, а и никой не беше показал, че тя реално може да се използва за атака.

Това се промени, когато два независими екипа — Calif и Wiz — анализираха PHP с помощта на AI модели. Изследователят от Calif Райън Остин е работил по проекта на OpenAI „Patch the Planet“ с модела GPT-5.6 Sol, а Wiz са комбинирали Gemini 4 Argon, GPT-5.6 Sol и собствения си инструмент Wiz Atlas. Според публикацията на Wiz AI е помогнал за най-трудната част — експлойтът да заработи на различни версии, конфигурации и подредби на паметта, като анализира неуспешните опити и пробва отново. Името PHP2Shell също е тяхно: дупката може да даде на атакуващия команден ред (shell) на сървъра.

Самото разкриване мина като трилър:

• На 20 октомври подробности изтекоха в Hacker News, а Calif по погрешка публикува видео с демонстрация на атаката.
• PHP изтегли пускането на корекцията с един ден — за 21 октомври.
• Компанията Chainguard публикува пакети с поправката около шест часа преди официалното пускане. Сравнението между стария и новия код подсказва на атакуващите къде точно да търсят.
• Агенцията за национална сигурност на САЩ (NSA) препоръча системите, които не могат да бъдат обновени веднага, да бъдат спрени. Временно офлайн излязоха правителствени сайтове в няколко европейски държави, част от услугите на Wikimedia и дори Internet Archive.

Още един детайл казва много: според The Guardian PHP Foundation — организацията, която поддържа езика на милиони сайтове — има едва 13 служители на пълен и непълен работен ден, докато в AI се инвестират милиарди. Wiz сравняват PHP2Shell с Heartbleed (2014) и Log4Shell (2021) и я определят като възможна повратна точка: AI прави старите грешки, смятани за „твърде сложни за използване“, отново опасни.

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

Какво да направите сега: 8 стъпки

1. Проверете версията на PHP. В WordPress: Инструменти → Здраве на сайта → Информация → Сървър. Версията се вижда и във всеки хостинг панел (cPanel, Plesk, DirectAdmin), където често може и да се избира.
2. Попитайте хостинга. Конкретно: приложена ли е корекцията от 21 октомври за CVE-2026-109618 и CVE-2026-109619 и не работи ли сайтът ви на PHP 8.1 или по-стара версия. При споделен и управляван хостинг обновяването е тяхна работа, но потвърждението трябва да е ваше.
3. Ако имате собствен сървър (VPS), обновете веднага. Инсталирайте обновените пакети и рестартирайте всички PHP процеси — PHP-FPM, Apache или LiteSpeed. Без рестарт старият код продължава да работи.
4. Ако сте на PHP 8.1 или по-стара версия, планирайте преминаване. Тези версии не получават официални корекции. Минете поне на 8.2, а по-добре на 8.4 или 8.5 — първо на тестово копие и с пълно резервно копие. Ако се притеснявате, че стара тема или плъгин ще спрат да работят, можем да направим обновяването на PHP версията вместо вас.
5. Ако не можете да обновите днес, намалете риска. Временните мерки са за администратора на сървъра: изключване на session.upload_progress.enabled (WordPress не използва тази функция), нисък post_max_size и лимити за размера на заявките и паметта, зададени на ниво сървър. Точните настройки са описани в бюлетина на CERT-EU. Ако сайтът е зад Cloudflare, правилата срещу PHP2Shell са включени във всички планове, но в платените проверете, че блокират атаките, а не само ги записват. Нито една от тези мерки не е пълна защита.
6. Ако сайтът не може да бъде нито обновен, нито защитен — спрете го временно. Това препоръчват NSA и американската агенция за киберсигурност CISA. Няколко часа офлайн струват по-малко от пробит сървър.
7. Потърсете следи от атака. Сигнали в логовете: необичайни заявки с качване на файлове, последвани от грешки за изчерпана памет; серии от грешки 500; необичайно големи или странни бисквитки PHPSESSID; необясними рестарти на PHP процесите.
8. При съмнение сменете паролите и ключовете. Понеже една от дупките позволява четене на паметта, при признаци на атака сменете паролата на базата данни, API ключовете (плащания, куриери, имейл), SMTP паролите и ключовете в wp-config.php.

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

Урокът: обновяването не е еднократна задача

PHP2Shell не е първата и няма да е последната сериозна дупка. Разликата е, че с AI откриването и използването на уязвимости става по-бързо — и за изследователите, и за атакуващите. Сайтовете, които се поддържат редовно, минават през такива седмици спокойно. Тези, които стоят на PHP 7.4, „защото работи“, са първите мишени.

Ако не искате сами да следите бюлетини за сигурност и версии на PHP, можете да го оставите на нас чрез поддръжката на уеб сайт — заедно с резервните копия, без които никое обновяване не е безопасно.

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

Трябва ли да обновя WordPress заради PHP2Shell?

Не. Уязвимостта е в PHP, а не във WordPress, и WordPress.org заяви, че актуализация на WordPress не е нужна. Обновяването трябва да стане на ниво сървър — от хостинга или от администратора ви.

Сайтът ми не е на WordPress. Засегнат ли съм?

Да, ако работи на PHP — независимо дали е Joomla, Drupal, OpenCart, PrestaShop, Laravel или сайт, писан по поръчка. Дупката е в самия език, затова платформата няма значение.

Сайтът ми е на споделен хостинг. Трябва ли да направя нещо?

Хостингът обновява PHP за всички клиенти, но проверете две неща: дали е потвърдил корекцията и коя версия е избрана за вашия сайт. В много панели всеки сайт може да работи на различна версия — ако вашият е останал на 7.4 или 8.0, той може да не е покрит.

Достатъчно ли е, че сайтът е зад Cloudflare?

Не. Защитната стена на Cloudflare спира известните варианти на атаката и е полезен допълнителен слой, но атакуващите вече променят заявките си, за да я заобиколят. Единствената пълна защита е обновен PHP.

Как да разбера дали сайтът ми вече е пробит?

Обърнете внимание на непознати файлове в папките на сайта, нови администратори, пренасочвания към чужди сайтове, предупреждения от Google или хостинга и рязко повишено натоварване на сървъра. Ако забележите нещо такова, вижте как работи поправката на хакнат сайт — или ни пишете веднага.

Искате да го проверим вместо вас?

В безплатната първа консултация ще проверим на каква версия на PHP работи сайтът ви, дали хостингът е приложил корекцията и какво трябва да се направи — от обикновено потвърждение до пълно обновяване на PHP. Ако подозирате, че вече има проблем, използвайте спешна техническа помощ. Работим с 0 € аванс — плащате, когато работата е готова и сте одобрили резултата. Пишете ни и ще се свържем с вас.