Уязвимость PHP затрагивает и сайты на WordPress

21 октября 2026 года необычно много сайтов ушли из сети. Город Майнц отключил свой портал, берлинская клиника Charité убрала из сети свой сайт, на время были недоступны также вузы, пожарная охрана и банки. По данным немецкого информационного агентства dpa, к 23 октября почти все сайты, отключённые в качестве меры предосторожности, снова стали доступны, в том числе сайты министерств, ведомств и Charité (t-online). Но на этом тема не закрыта. Любой сайт без обновления остаётся уязвимым, и, по данным dpa, волна автоматизированных атак, вероятно, продлится ещё недели и месяцы (Tagesspiegel).

За этим стоит не отдельная хакерская атака, а уязвимость в PHP. На этой технологии работает значительная часть всех сайтов, включая без исключения все сайты на WordPress.

Что случилось с уязвимостью PHP2Shell?

Когда посетитель открывает сайт, его браузер отправляет запрос на веб-сервер, где хранятся PHP-файлы. Сервер распознаёт PHP-код, выполняет содержащиеся в нём команды и превращает результат в чистый код HTML и CSS. Этот готовый код он отправляет обратно браузеру, который отображает его как страницу. Исходный PHP-код при этом остаётся невидимым для посетителя и защищённым на сервере. Так работает значительная часть интернета, от простого блога до новостных порталов и интернет-магазинов.

Именно в этом процессе обнаружили две серьёзные ошибки. 21 октября 2026 года проект PHP выпустил обновление, которое устраняет обе ошибки, его выход был анонсирован на 16:00 по немецкому времени. Всем владельцам сайтов следует установить его немедленно (php.net).

Злоумышленники могут выполнять на сервере посторонние команды

Обе уязвимости носят общее прозвище PHP2Shell. Специалисты обозначают их официальными идентификаторами CVE-2026-109618 и CVE-2026-109619. Обе срабатывают именно в тот момент, когда сервер обрабатывает запрос.

Если упростить, всё происходит так. Злоумышленник отправляет серверу специально подготовленный запрос с множеством вложенных друг в друга полей. Сам по себе он не особенно большой, но для каждого уровня вложенности PHP должен выделять дополнительную память. Это происходит ещё до того, как запускается сама страница. Поэтому при некоторых настройках сервера достаточно запроса к любой PHP-странице, форма не нужна. При других всё зависит от того, как запрограммирован сайт. PHP при этом упирается в свой лимит памяти, прерывается на полпути и при последующей очистке перепутывает собственные данные (Calif). При второй уязвимости в памяти остаются фрагменты запроса, которые затем подхватывает один из следующих запросов (php.net).

Именно в этой путанице и кроется опасность. Вместо того чтобы просто выдать страницу, сервер выполняет команды злоумышленника, причём без всякого пароля и с теми же правами, с которыми он обычно обслуживает сайт. Область сервера, которая должна быть защищена, оказывается открытой для злоумышленника. В худшем случае он захватывает сайт, получает доступ к данным клиентов, формам или паролям и использует сервер для дальнейших атак.

Провести такую атаку не так уж просто. По данным heise online, для этого часто требуется несколько тысяч запросов. Но для автоматизированных инструментов атаки это не препятствие. На видео компании Calif посторонние команды выполнялись на сервере с PHP-фреймворком Laravel уже через 38 секунд.

Как возникла ошибка

Проблема не совсем новая. Похожая уязвимость была в PHP ещё в 2004 году (Calif), а по данным BSI, затронуты все известные версии PHP, как минимум начиная с PHP 5 (BSI). Один из разработчиков команды PHP заметил ошибку ещё в 2024 году. Но поскольку тогда не удалось найти способ атаки, а небольшая команда не смогла договориться о решении, ошибка так и осталась неисправленной. Сегодня PHP Foundation сама называет это структурным провалом (The Next Web).

В 2026 году компания по кибербезопасности Calif с конца июля целенаправленно исследовала PHP с помощью ИИ в рамках программы безопасности OpenAI. 11 августа она сообщила об уязвимости команде PHP (Calif).

Почему атаки начались именно сейчас

До октября об уязвимости знали лишь немногие участники, например её первооткрыватели, команда PHP и поставщики, готовившие обновления. Без подсказки почти никто не найдёт отдельную ошибку в огромном программном коде PHP. Незадолго до выхода обновления эта секретность частично рухнула. 20 октября около 17:00 по немецкому времени в сети начали распространяться идентификаторы уязвимостей, технических подробностей тогда ещё не было. После этого команда PHP перенесла выпуск обновления на день раньше, на 21 октября (heise online). В тот же вечер Calif по ошибке опубликовала видео атаки. А 21 октября один из поставщиков программного обеспечения выложил исправленные пакеты более чем за шесть часов до официального срока (The Next Web).

С выходом обновления окончательно стало видно, какое место в коде было исправлено. BSI считал вероятным, что уже через несколько часов после выхода обновления злоумышленники начнут массово использовать уязвимость с помощью ИИ-инструментов (BSI). Amazon даже зафиксировал первую попытку атаки на собственном сервере-приманке ещё 17 октября. В ночь на 21 октября, ещё до обновления, появились первые примеры атак, через несколько часов после обновления последовали новые, а сейчас Amazon наблюдает в сети широкомасштабные попытки атак (AWS Security Blog). Поэтому тем, кто обновился лишь спустя несколько дней, не стоит исходить из того, что ничего не произошло.

Какую роль в этом играет ИИ

ИИ сыграл роль на обеих сторонах. 19 августа, спустя чуть больше недели после сообщения Calif, на эти ошибки независимо наткнулась и компания по кибербезопасности Wiz. По её собственным данным, Wiz использовала при этом ИИ-модели, чтобы выявить уязвимости и проверить обновление (Wiz). Ошибки, которые раньше считались слишком сложными для использования, с помощью ИИ внезапно становятся пригодными для атак. Но то, что помогает исследователям безопасности, точно так же помогает и злоумышленникам.

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

Почему так много сайтов ушли в офлайн?

Владельцы отключили свои сайты в качестве меры предосторожности до установки обновления. Пока сайт отключён, ни один запрос злоумышленника не доходит до сервера. Для посетителей это было неприятно, но в такой ситуации это было самое разумное решение.

BSI советовал при сомнениях отключать сайты

Федеральное ведомство по информационной безопасности Германии (BSI) присвоило ситуации уровень угрозы «3 / оранжевый», то есть оценило её как чрезвычайно серьёзную. Тем, кто не мог сразу установить обновление, BSI рекомендовал рассмотреть возможность временно отключить сайт от интернета (Tagesspiegel). Марк Хенрихманн, председатель Парламентского контрольного комитета Германии по надзору за спецслужбами, назвал её одной из самых серьёзных уязвимостей последних лет (Tagesspiegel).

Многие организации последовали этой рекомендации. По данным dpa, недоступны были, в частности, сайты Charité, берлинской пожарной охраны, берлинской благотворительной продовольственной организации Berliner Tafel, Потсдамского университета и клиники имени Эрнста фон Бергмана. Город Майнц отключил несколько онлайн-сервисов, в том числе свой портал mainz.de (Tagesspiegel). По данным ZDFheute, сайты банков и сберегательных касс также частично были недоступны несколько часов. Сам онлайн-банкинг затронут не был, поскольку он построен на совершенно других технических компонентах.

Отключение говорит об осторожности, а не об атаке

Для ведомств и клиник выбор прост. Сайт, недоступный несколько часов, раздражает посетителей. А если злоумышленники доберутся до данных пациентов или заявлений граждан, ущерб будет реальным. Поэтому отключённый сайт в эти дни был скорее признаком ответственности. До 22 октября BSI не выявил случаев, в которых уязвимость была бы использована. Однако исключить успешные атаки ведомство не могло (Tagesspiegel). Поэтому критическими остаются сайты, которые просто продолжают работать без обновления.

Какие сайты затрагивает уязвимость PHP?

Под угрозой любой сайт, сервер которого обрабатывает запросы с помощью PHP и который ещё не получил обновление. Таких сайтов очень много. По данным W3Techs, PHP используют 69,3 процента всех сайтов, технология которых известна.

Без исключения каждый сайт на WordPress без обновления PHP

Уязвимость находится в самом PHP, а не в какой-то конкретной системе управления контентом. Такая CMS, как WordPress, по сути представляет собой большой набор PHP-файлов, которые сервер выполняет при каждом открытии страницы. Поэтому затронуты все системы, построенные на PHP. К ним относятся WordPress, Typo3, Joomla, Drupal, обучающая платформа Moodle и многие системы для интернет-магазинов. По оценке экспертов, только на WordPress работают от 400 до 500 миллионов сайтов по всему миру (Tagesspiegel). По данным Wiz, каждая версия PHP за последние десять лет затронута как минимум одной из уязвимостей, а самой старой затронутой версией является PHP 5.4 (Wiz).

Для владельцев сайтов на WordPress это уже вторая критическая уязвимость за несколько месяцев, хотя PHP2Shell находится не в самом WordPress. В июле 2026 года WordPress пришлось закрыть в версии 7.0.2 уязвимость, через которую злоумышленники также могли выполнять посторонний код (WordPress.org). Она стала известна под названием wp2shell, и тогда BSI тоже присвоил ситуации оранжевый уровень (IT-Administrator). Разница здесь важна. Уязвимость wp2shell находилась в PHP-файлах самого WordPress, поэтому помогло обновление WordPress. PHP2Shell находится уровнем глубже, в технологии, которая эти файлы выполняет. Поэтому на этот раз обновить нужно сам PHP.

Затронуты и устройства дома и в офисе

PHP работает и в устройствах, о которых сразу не подумаешь. У многих роутеров, межсетевых экранов и сетевых хранилищ (NAS) есть страница настроек, которая открывается в браузере. За этой страницей тоже часто работает PHP, как сообщает heise online об устройствах разных производителей. Если вы пользуетесь такими устройствами, стоит включить на них автоматические обновления (ZDFheute).

Тем, кто просто пользуется интернетом, ничего делать на своём компьютере или телефоне не нужно. Браузер получает от сервера только готовый HTML и CSS, а PHP-код выполняется исключительно на сервере. Поэтому уязвимость затрагивает серверы, а не устройства посетителей.

Как проверить и защитить ваш сайт прямо сейчас?

Для первой проверки безопасности сайта технические знания не нужны. Следующие три шага покажут, затронут ли ваш сайт и что нужно сделать.

Шаг 1: выясните, на чём работает ваш сайт

Если ваш сайт работает на WordPress, Typo3, Joomla или на системе для интернет-магазинов вроде Shopware или WooCommerce, он почти наверняка использует PHP. В WordPress это можно проверить самостоятельно. В разделе «Инструменты» найдите пункт «Здоровье сайта». На вкладке «Информация» в разделе «Сервер» указана точная версия PHP. Вкладка «Состояние» хотя и предупреждает об устаревшей технологии (WordPress.org), но, согласно документации, не сообщает целенаправленно об отсутствующих обновлениях безопасности, таких как обновление против PHP2Shell. Поэтому сравните номер версии самостоятельно.

От PHP2Shell защищены версии PHP 8.5.12, 8.4.27, 8.3.36 и 8.2.35 или новее. Если там указан более старый номер, сразу свяжитесь со своим хостинг-провайдером или агентством. На некоторых Linux-серверах номер может выглядеть старше, хотя хостинг-провайдер уже установил исправление, поэтому при сомнениях уточните у него. Если вы не знаете, на какой технологии работает ваш сайт, спросите там же.

Шаг 2: поручите установить обновление

PHP установлен на сервере, а не в вашем сайте. Поэтому при обычном хостинг-тарифе обновлением, как правило, занимается хостинг-провайдер. По данным ZDFheute, крупные провайдеры, такие как IONOS, его уже установили. Если ваш сайт работает на собственном сервере, за это отвечает ваш ИТ-подрядчик или агентство.

Временные решения существуют, например определённые настройки PHP или защитные фильтры, которые перехватывают подозрительные запросы. Однако проект PHP подчёркивает, что полной защиты, кроме обновления, нет (php.net). Кроме того, с 23 октября проект PHP рекомендует пока отключить настройку «session.upload_progress.enabled», в том числе на уже обновлённых серверах. Причина в отдельной уязвимости, которую можно использовать только при необычном сочетании настроек и которая будет закрыта лишь со следующим плановым обновлением PHP. Это тоже может взять на себя ваш хостинг-провайдер или агентство. Если обновить PHP сразу невозможно, остаётся совет BSI ненадолго отключить сайт от сети. Для PHP 8.1 и более старых версий проект PHP больше не выпускает регулярных обновлений, некоторые поставщики Linux выпускают собственные исправления. В долгосрочной перспективе поможет только переход на актуальную версию.

Шаг 3: поручите проверить, не проник ли кто-то на сервер раньше

Обновление закрывает уязвимость, но не удаляет ничего из того, что злоумышленник уже успел оставить на сервере. Поскольку первые атаки начались ещё до выхода обновления, Amazon рекомендует искать следы начиная с 17 октября, а не только со дня обновления (AWS Security Blog). Серверы, как правило, записывают, какие запросы к ним поступали. Попросите хостинг-провайдера или агентство проверить эти записи на подозрительные признаки. В WordPress вы также можете сами посмотреть, нет ли учётных записей администраторов, которых вы не знаете.

Как проходит подробная профессиональная проверка безопасности сайта, мы рассказываем в статье Как закрыть крупнейшие уязвимости на вашем сайте.

Что делает сайт безопасным в долгосрочной перспективе?

PHP2Shell не станет последней крупной уязвимостью. Поэтому безопасные сайты получаются не благодаря одному обновлению, а благодаря правильной технологии и чётким процессам.

Четыре принципа безопасных сайтов

Во-первых, на сервере должно работать как можно меньше программного обеспечения. Каждая программа и каждый плагин, участвующие в открытии страницы, обрабатывают запрос посетителя и тем самым становятся потенциальным слабым местом. Во-вторых, обновления безопасности должны устанавливаться в течение часов, а не недель. В случае PHP2Shell первые атаки начались даже до выхода обновления.

В-третьих, нужна чёткая ответственность. Многим организациям в эти дни сначала пришлось выяснять, кто обслуживает их сайт и какая технология на нём работает. В экстренной ситуации этого времени нет. В-четвёртых, нужны актуальные резервные копии, чтобы после атаки сайт можно было быстро восстановить. На что обращать внимание при выборе партнёра для постоянной поддержки сайта, читайте в статье Как правильно выбрать агентство для поддержки сайта.

Что делает сайты Evelan безопасными

Сайты, которые мы сегодня создаём в Evelan, следуют этим принципам. Это не только защищает от отдельной уязвимости вроде PHP2Shell, но и делает весь сайт менее уязвимым:

• Никакого классического бэкенда на сервере: сайт работает на Next.js. Контент, вход в систему и данные хранятся отдельно в облачном сервисе Sanity. Здесь нет бэкенда WordPress и нет плагинов, которые злоумышленники могли бы использовать на веб-сервере. Уязвимости вроде PHP2Shell или wp2shell эти сайты не затрагивают, потому что на них не работают ни PHP, ни WordPress.
• Готовые страницы из глобальной сети серверов: страницы, как правило, заранее преобразуются в готовый HTML и CSS и доставляются через Vercel, как и наш собственный сайт evelan.de. Когда посетитель открывает страницу, сервер просто отправляет этот готовый файл. При этом почти не выполняется код, который можно было бы атаковать. Но и Next.js не свободен от уязвимостей, например в конце 2025 года пришлось закрывать уязвимость React2Shell (Vercel).
• Обновления без стресса с обслуживанием: на уровне инфраструктуры Vercel, согласно собственной документации, автоматически устанавливает важные обновления безопасности (Vercel). Никому не нужно обновлять сервер по ночам. Компоненты, из которых состоит сам сайт, мы дополнительно поддерживаем в актуальном состоянии.
• Защищённый контент: по собственным данным, Sanity сертифицирован в области безопасности по стандарту SOC 2 Type 2 и соответствует требованиям GDPR. Доступ можно точно регулировать с помощью ролей, а в зависимости от тарифа Sanity ведёт историю версий изменений. Кроме того, Sanity непрерывно создаёт резервные копии базы данных и может восстановить её на любой момент за последние 30 дней (Sanity).
• Обслуживание из одних рук: по желанию мы берём на себя хостинг, эксплуатацию и обновления, чтобы вам не приходилось заниматься этим самостоятельно.

Даже безопасной технологии нужны обновления

И всё же неуязвимых технологий не бывает. В тот же день, 21 октября, обновления безопасности получил и Node.js, среда выполнения Next.js (Aikido). Разница в том, кто их устанавливает и как быстро. Согласно документации, Vercel при необходимости автоматически устанавливает такие обновления Node.js, а остальные компоненты сайта мы при необходимости обновляем и публикуем заново. Чем различаются оба подхода, показывает наше сравнение Headless CMS против классической CMS.

Другие статьи Evelan по теме

• Как закрыть крупнейшие уязвимости на вашем сайте
• Headless CMS против классической CMS: что выбрать
• Редизайн сайта как инвестиция в будущее

Источники

• https://www.php.net/archive/2026.php
• https://www.heise.de/en/news/php2shell-Critical-flaws-allow-code-injection-in-PHP-11494897.html
• https://www.bsi.bund.de/DE/Service-Navi/Presse/Pressemitteilungen/Presse2026/261021_PHP-kritische-Schwachstelle.html
• https://www.tagesspiegel.de/wirtschaft/dpa-bsi-warnt-und-rat-im-zweifel-zum-trennen-der-server-vom-netz-16184490.html
• https://www.tagesspiegel.de/gesellschaft/medien/dpa-viele-webseiten-wieder-online--aber-noch-keine-entwarnungwas-sie-zur-php-sicherheitslucke-wissen-mussen-16186542.html
• https://www.t-online.de/digital/aktuelles/id_101494558/php-sicherheitsluecke-viele-betroffenen-webseiten-wieder-online.html
• https://www.zdfheute.de/politik/php-sicherheitsluecke-faq-websites-internet-100.html
• https://w3techs.com/technologies/details/pl-php
• https://thenextweb.com/news/php-foundation-structural-failure-2024-flaw-leak
• https://calif.io/php2shell/
• https://www.wiz.io/blog/php2shell-php-rce
• https://aws.amazon.com/blogs/security/amazon-threat-intelligence-identifies-php2shell-exploitation-prior-to-public-disclosure-in-madpot/
• https://wordpress.org/documentation/wordpress-version/version-7-0-2/
• https://wordpress.org/documentation/article/site-health-screen/
• https://www.it-administrator.de/wordpress-bsi-alarmstufe-orange-schwachstelle-websites
• https://www.aikido.dev/blog/node2shell-nodejs-brotli-rce-cve-2026-111497
• https://www.sanity.io/security
• https://vercel.com/blog/resources-for-protecting-against-react2shell
• https://vercel.com/docs/functions/runtimes/node-js/node-js-versions