[ обложка статьи ]
Режим чтения
Что вас ждёт в статье:
Краткая сводка
1. Почему это коснулось всех
2. Атаки начались раньше огласки
3. Как отреагировал мир
4. Детект и охота
5. Что делать
Заключение
Таймлайн и источники
Краткая сводка
В первой части мы разобрали технику: две дыры в ядре PHP (CVE-2026-109618 и 109619), обе дают удалённое выполнение кода без авторизации и обе выросли из ошибок работы с памятью. Если ты её пропустил, загляни, там вся механика по полочкам, в этой статье она не понадобится. А теперь о том, что из всего этого вышло в реальном мире. Спойлер — вышло громко.
21 октября 2026 PHP выпустил экстренные патчи, и мир отреагировал почти паникой: госсайты уходили офлайн, платформы переключались в режим «только для чтения», игры вставали на внеплановые техработы. Разберём, почему так, кто именно закрывался и что с этим делать.
21 октября 2026 PHP выпустил экстренные патчи, и мир отреагировал почти паникой: госсайты уходили офлайн, платформы переключались в режим «только для чтения», игры вставали на внеплановые техработы. Разберём, почему так, кто именно закрывался и что с этим делать.
1. Почему это коснулось всех
На PHP работает огромная часть веба: по разным оценкам, около трёх четвертей сайтов, у которых вообще можно разглядеть backend. WordPress, Drupal, Joomla, Magento, WooCommerce, Битрикс — всё это сверху PHP.
А уязвиомсть сидит этажом ниже этих CMS, в самом PHP, поэтому ей без разницы, какая система стоит сверху и насколько аккуратно написан твой код. Глава Drupal Association сформулировала это так: «уязвимы все серверы на любой версии PHP, выпущенной за последние 20 лет».
Рис. 1. уязвимость в ядре PHP лежит под всеми CMS сразу — код приложения тут ни при чём
В сеть смотрит больше миллиона уязвимых хостов. Атаковать можно без логина — хватает того, что сайт отвечает на запросы. Особенно опасен mod_php, где вредоносный запрос добивает до бага раньше, чем стартует код сайта. Проще говоря, под ударом оказались примерно все, кто держит что-то на PHP.
На виртуальном хостинге всё ещё хуже. На одном сервере часто крутятся десятки и сотни чужих сайтов под общим PHP, и одна уязвимая версия ставит под угрозу сразу всех соседей по машине, как бы аккуратны они ни были. Хостерам пришлось не обновить свой сайт, а экстренно обновлять платформу под тысячами клиентов разом. Отсюда и часть тех самых массовых техработ.
А уязвиомсть сидит этажом ниже этих CMS, в самом PHP, поэтому ей без разницы, какая система стоит сверху и насколько аккуратно написан твой код. Глава Drupal Association сформулировала это так: «уязвимы все серверы на любой версии PHP, выпущенной за последние 20 лет».
Рис. 1. уязвимость в ядре PHP лежит под всеми CMS сразу — код приложения тут ни при чём
В сеть смотрит больше миллиона уязвимых хостов. Атаковать можно без логина — хватает того, что сайт отвечает на запросы. Особенно опасен mod_php, где вредоносный запрос добивает до бага раньше, чем стартует код сайта. Проще говоря, под ударом оказались примерно все, кто держит что-то на PHP.
На виртуальном хостинге всё ещё хуже. На одном сервере часто крутятся десятки и сотни чужих сайтов под общим PHP, и одна уязвимая версия ставит под угрозу сразу всех соседей по машине, как бы аккуратны они ни были. Хостерам пришлось не обновить свой сайт, а экстренно обновлять платформу под тысячами клиентов разом. Отсюда и часть тех самых массовых техработ.
2. Атаки начались раньше огласки
Быстро выяснилось, что атаковать начали ещё до того, как мир узнал об уязвимостях. Honeypot-сеть Amazon зафиксировала попытку эксплуатации 17 октября, за четыре дня до публикации патчей. Откуда у атакующего была информация, Amazon сказать не берётся.
После огласки всё понеслось куда быстрее: Cloudflare сообщил о первых атаках, а watchTowr заявил, что воспроизвёл оба бага и уже видит попытки. При этом публичный эксплойт оказался так себе — по оценке Rapid7, он капризный и работает только при конкретных сочетаниях ОС, версии PHP и веб-сервера. А часть гуляющего по сети PoC и вовсе шла с малварью внутри, так что любители запустить чужой код у себя рисковали поймать не славу, а троян)
17 октября ловушки Amazon увидели первый заход, а патчи вышли только 21-го. Четыре дня у кого-то на руках был работающий (пусть и капризный) подход к уязвимости, о которой официально ещё никто не знал. Версий, как это вышло, по сути две: независимая находка тем же методом или утечка из процесса координации. Ни одна не радует.
СМИ подхватили ещё одну деталь: уязвимости, по сообщениям, нашли с помощью ИИ-инструментов, а среди тех, кого PHP Foundation благодарит за находку, значится и OpenAI. Axios даже окрестил происходящее «Чёрным октябрём» и заговорил о новой эпохе, где серьёзные баги ищут уже не только люди. Где тут правда, а где хайп, покажет время.
Напрашивается сравнение с Log4Shell 2021 года — той дырой в Java-библиотеке логирования, что тогда тряхнула полмира. Схема один в один: уязвимость сидит не в приложении, а в компоненте-фундаменте, который стоит у всех и о котором мало кто вообще думает. Отличие в том, что в этот раз, по сообщениям, свою роль в находке сыграл ИИ. Это, пожалуй, главная примета новой эпохи: искать такие уязвимости стало быстрее, а значит, быстрее находить их будут обе стороны.
После огласки всё понеслось куда быстрее: Cloudflare сообщил о первых атаках, а watchTowr заявил, что воспроизвёл оба бага и уже видит попытки. При этом публичный эксплойт оказался так себе — по оценке Rapid7, он капризный и работает только при конкретных сочетаниях ОС, версии PHP и веб-сервера. А часть гуляющего по сети PoC и вовсе шла с малварью внутри, так что любители запустить чужой код у себя рисковали поймать не славу, а троян)
17 октября ловушки Amazon увидели первый заход, а патчи вышли только 21-го. Четыре дня у кого-то на руках был работающий (пусть и капризный) подход к уязвимости, о которой официально ещё никто не знал. Версий, как это вышло, по сути две: независимая находка тем же методом или утечка из процесса координации. Ни одна не радует.
СМИ подхватили ещё одну деталь: уязвимости, по сообщениям, нашли с помощью ИИ-инструментов, а среди тех, кого PHP Foundation благодарит за находку, значится и OpenAI. Axios даже окрестил происходящее «Чёрным октябрём» и заговорил о новой эпохе, где серьёзные баги ищут уже не только люди. Где тут правда, а где хайп, покажет время.
Напрашивается сравнение с Log4Shell 2021 года — той дырой в Java-библиотеке логирования, что тогда тряхнула полмира. Схема один в один: уязвимость сидит не в приложении, а в компоненте-фундаменте, который стоит у всех и о котором мало кто вообще думает. Отличие в том, что в этот раз, по сообщениям, свою роль в находке сыграл ИИ. Это, пожалуй, главная примета новой эпохи: искать такие уязвимости стало быстрее, а значит, быстрее находить их будут обе стороны.
3. Как отреагировал мир
Реакция была массовой, но отключение сайта — это ещё не взлом. Большинство уводило сервисы офлайн на всякий случай, не дожидаясь, пока их ковырнут. В крайнем случае то же советовала и CISA: не можешь пропатчиться прямо сейчас — выключай.
Рис. 2. Кто уводил сайты офлайн в октябре 2026 (звёздочка — по сообщениям, без официального подтверждения)
Особенно отличился госсектор. Финляндия через Valtori вырубила публичные госсервисы, Бельгия сняла сайты МИД, Франция — префектуры МВД, Германия и Чехия тоже уводили порталы. Нидерланды закрыли Overheid.nl и сайт собственного NCSC, Канада и Дания — туда же. По сообщениям, задело и нижнюю палату парламента Нидерландов, но официально это не подтверждено.
Платформы и сервисы не отставали. Вспомогательная инфраструктура Wikimedia ушла на профилактику, Fur Affinity объявил превентивную остановку; по сообщениям, 4chan переключился в режим только для чтения, а Something Awful временно лёг. Отдельно отметились игры: Cygames остановила Granblue Fantasy, Umamusume и Princess Connect на экстренные техработы. Даже порт Роттердама и ирландское издание The Journal на время сняли свои сайты.
На уровне властей и вендоров закрутилось всё и сразу: CISA выпустила алерт, CERT-EU — адвизори, Cloudflare выкатил WAF-правила, сам же назвав их «затычкой», министр по цифровизации Канады призвал обновляться прямо в соцсетях. За пару дней тема из технического бюллетеня превратилась в международный инцидент.
Подтверждённых массовых взломов на тот момент не было, а реакция всё равно вышла нервной. Логика тут простая, уязвимость бьёт без авторизации, подход к эксплуатации уже где-то гуляет, а поверхность — это буквально весь публичный веб на PHP. Дождавшись подтверждённой атаки именно на нас, вполне можно узнать о ней уже постфактум, по утёкшей базе. Увести сайт на несколько часов офлайн и спокойно пропатчиться выходит дешевле, чем потом объяснять регулятору, как утекли данные. Поэтому решения принимали не из паники, а вполне руководствуясь здравым смыслом.
Большинство площадок вернулось в строй в течение суток-двух, как только обновились и убедились, что их не успели тронуть. Громкая волна отключений вышла управляемой паузой, неприятной и дорогой, но всё равно несопоставимо дешевле, чем разбор последствий настоящего взлома. Перестраховка тут и означает заплатить немного простоя заранее, чтобы не платить репутацией потом.
Рис. 2. Кто уводил сайты офлайн в октябре 2026 (звёздочка — по сообщениям, без официального подтверждения)
Особенно отличился госсектор. Финляндия через Valtori вырубила публичные госсервисы, Бельгия сняла сайты МИД, Франция — префектуры МВД, Германия и Чехия тоже уводили порталы. Нидерланды закрыли Overheid.nl и сайт собственного NCSC, Канада и Дания — туда же. По сообщениям, задело и нижнюю палату парламента Нидерландов, но официально это не подтверждено.
Платформы и сервисы не отставали. Вспомогательная инфраструктура Wikimedia ушла на профилактику, Fur Affinity объявил превентивную остановку; по сообщениям, 4chan переключился в режим только для чтения, а Something Awful временно лёг. Отдельно отметились игры: Cygames остановила Granblue Fantasy, Umamusume и Princess Connect на экстренные техработы. Даже порт Роттердама и ирландское издание The Journal на время сняли свои сайты.
На уровне властей и вендоров закрутилось всё и сразу: CISA выпустила алерт, CERT-EU — адвизори, Cloudflare выкатил WAF-правила, сам же назвав их «затычкой», министр по цифровизации Канады призвал обновляться прямо в соцсетях. За пару дней тема из технического бюллетеня превратилась в международный инцидент.
Подтверждённых массовых взломов на тот момент не было, а реакция всё равно вышла нервной. Логика тут простая, уязвимость бьёт без авторизации, подход к эксплуатации уже где-то гуляет, а поверхность — это буквально весь публичный веб на PHP. Дождавшись подтверждённой атаки именно на нас, вполне можно узнать о ней уже постфактум, по утёкшей базе. Увести сайт на несколько часов офлайн и спокойно пропатчиться выходит дешевле, чем потом объяснять регулятору, как утекли данные. Поэтому решения принимали не из паники, а вполне руководствуясь здравым смыслом.
Большинство площадок вернулось в строй в течение суток-двух, как только обновились и убедились, что их не успели тронуть. Громкая волна отключений вышла управляемой паузой, неприятной и дорогой, но всё равно несопоставимо дешевле, чем разбор последствий настоящего взлома. Перестраховка тут и означает заплатить немного простоя заранее, чтобы не платить репутацией потом.
4. Детект и охота
Ловить это тяжело, чистых индикаторов «вот такой запрос => атака» почти нет, эксплуатация капризная, сигнатуры ещё толком не устоялись. Но кое-что сделать можно и нужно.
Начать стоит даже не с детекта, а с инвентаризации. Прежде чем искать атаку, узнайте, где у вас вообще крутится PHP и какой версии. Прячется он в самых неожиданных местах: в контейнерах, на старых забытых поддоменах, во внутренних сервисах. Аутентифицированные сканеры тут честнее сетевых, они видят реальную версию, а не только ту, что торчит наружу.
Amazon, поймавший первую попытку ещё 17 октября, прямо советует начинать разбор инцидентов не с даты раскрытия, а с 17-го. Смотреть стоит на последствия RCE, механика которых от конкретного бага не зависит:
аномальные multipart-запросы — необычно крупные, со странной вложенностью или числом частей, особенно туда, где загрузка файлов вообще не нужна;
учащённые падения и рестарты воркеров PHP — порча памяти часто сопровождается крэшами;
веб-сервер или php-процесс, внезапно порождающий оболочку или сетевые утилиты, — классический признак RCE;
необычный исходящий трафик с веб-сервера и обращения к файлам или базе, которых по логике приложения быть не должно.
Раз атаки шли с 17 октября, а многие узнали о проблеме только 21-го или позже, велик шанс, что след уже в логах, просто его никто не искал. Если есть возможность, подними историю запросов и падений воркеров за эти даты и прогони по признакам выше. Учтите и неприятное: аккуратный атакующий после успешного захода первым делом подчистит очевидные следы и закрепится, так что отсутствие явных аномалий ещё не значит «нас не трогали».
С WAF тоже всё непросто. Cloudflare выкатил правила в день релиза, но сам же называет их «затычкой», они перекрывают известные векторы, а не саму дыру. Полагаться только на край нельзя, это выигрыш времени, а не лечение.
Начать стоит даже не с детекта, а с инвентаризации. Прежде чем искать атаку, узнайте, где у вас вообще крутится PHP и какой версии. Прячется он в самых неожиданных местах: в контейнерах, на старых забытых поддоменах, во внутренних сервисах. Аутентифицированные сканеры тут честнее сетевых, они видят реальную версию, а не только ту, что торчит наружу.
Amazon, поймавший первую попытку ещё 17 октября, прямо советует начинать разбор инцидентов не с даты раскрытия, а с 17-го. Смотреть стоит на последствия RCE, механика которых от конкретного бага не зависит:
аномальные multipart-запросы — необычно крупные, со странной вложенностью или числом частей, особенно туда, где загрузка файлов вообще не нужна;
учащённые падения и рестарты воркеров PHP — порча памяти часто сопровождается крэшами;
веб-сервер или php-процесс, внезапно порождающий оболочку или сетевые утилиты, — классический признак RCE;
необычный исходящий трафик с веб-сервера и обращения к файлам или базе, которых по логике приложения быть не должно.
Раз атаки шли с 17 октября, а многие узнали о проблеме только 21-го или позже, велик шанс, что след уже в логах, просто его никто не искал. Если есть возможность, подними историю запросов и падений воркеров за эти даты и прогони по признакам выше. Учтите и неприятное: аккуратный атакующий после успешного захода первым делом подчистит очевидные следы и закрепится, так что отсутствие явных аномалий ещё не значит «нас не трогали».
С WAF тоже всё непросто. Cloudflare выкатил правила в день релиза, но сам же называет их «затычкой», они перекрывают известные векторы, а не саму дыру. Полагаться только на край нельзя, это выигрыш времени, а не лечение.
5. Что делать
Патчиться, и желательно вне обычного окна обновлений: только это реально закрывает обе дыры.
Обновить PHP до исправленной версии своей ветки: 8.2.35, 8.3.36, 8.4.27 или 8.5.12. После обновления обязательно перезапустить все воркеры — иначе старые процессы останутся уязвимыми.
Сидишь на 7.4, 8.0 или 8.1 — там только минимальные сорс-бэкпорты, а 8.1 и старше вообще сняты с регулярной поддержки. Это сигнал что пора мигрировать на живую ветку.
Проверить реальные версии везде, включая контейнеры и OS-пакеты: дистрибутивы выпускают свои сборки с обоими фиксами, ориентируйся на их адвизори.
Временные меры, пока не обновились:
задать memory_limit на уровне администратора и убедиться, что приложение не может его переопределить;
отключить session upload progress в php.ini, пуле FPM или конфиге сервера;
на PHP 8.5 — отключить трассировку фатальных ошибок;
на фронте резать размер запроса, число и вложенность multipart-частей, а неиспользуемые multipart-запросы блокировать;
не использовать RLIMIT_AS и RLIMIT_DATA — они как раз подталкивают к уязвимому пути.
После любой из этих правок снова перезапустите воркеры. Всё это лишь сужает площадь атаки, а не лечит. Если пропатчиться прямо сейчас никак, а система торчит наружу на 8.1 или старше, CISA прямо говорит: уводи в офлайн. Именно это в те дни и делали по всему миру.
Убедитесь, что реально закрылись. После обновлений сверяйте версию именно у запущенного процесса, а не у пакета на диске, то, что показывает php -v в консоли, и то, что реально отдаёт веб-сервер, иногда расходятся, особенно если воркеры не перезапустили. Если PHP ставится из пакетов дистрибутива, ориентируйтесь на номер сборки вендора, а не на голую версию PHP: фиксы там часто бэкпортят в старый номер, и сборка вида «8.2.28-1+distro» может уже содержать патч, хотя по цифре кажется уязвимой. Если сомневаетесь, то можете прогнать повторный скан уже после обновления, желательно агентский, а не только сетевой.
Обновить PHP до исправленной версии своей ветки: 8.2.35, 8.3.36, 8.4.27 или 8.5.12. После обновления обязательно перезапустить все воркеры — иначе старые процессы останутся уязвимыми.
Сидишь на 7.4, 8.0 или 8.1 — там только минимальные сорс-бэкпорты, а 8.1 и старше вообще сняты с регулярной поддержки. Это сигнал что пора мигрировать на живую ветку.
Проверить реальные версии везде, включая контейнеры и OS-пакеты: дистрибутивы выпускают свои сборки с обоими фиксами, ориентируйся на их адвизори.
Временные меры, пока не обновились:
задать memory_limit на уровне администратора и убедиться, что приложение не может его переопределить;
отключить session upload progress в php.ini, пуле FPM или конфиге сервера;
на PHP 8.5 — отключить трассировку фатальных ошибок;
на фронте резать размер запроса, число и вложенность multipart-частей, а неиспользуемые multipart-запросы блокировать;
не использовать RLIMIT_AS и RLIMIT_DATA — они как раз подталкивают к уязвимому пути.
После любой из этих правок снова перезапустите воркеры. Всё это лишь сужает площадь атаки, а не лечит. Если пропатчиться прямо сейчас никак, а система торчит наружу на 8.1 или старше, CISA прямо говорит: уводи в офлайн. Именно это в те дни и делали по всему миру.
Убедитесь, что реально закрылись. После обновлений сверяйте версию именно у запущенного процесса, а не у пакета на диске, то, что показывает php -v в консоли, и то, что реально отдаёт веб-сервер, иногда расходятся, особенно если воркеры не перезапустили. Если PHP ставится из пакетов дистрибутива, ориентируйтесь на номер сборки вендора, а не на голую версию PHP: фиксы там часто бэкпортят в старый номер, и сборка вида «8.2.28-1+distro» может уже содержать патч, хотя по цифре кажется уязвимой. Если сомневаетесь, то можете прогнать повторный скан уже после обновления, желательно агентский, а не только сетевой.
Заключение
История эта не столько про PHP, сколько про цепную реакцию, которая начинается, когда одна уязвимость лежит под фундаментом половины веба. Код, который годами молча работал, за сутки превратил министерства, форумы и игровые студии в нерабочие странички с тех. работами.
Атаки пошли раньше огласки, патч вышел экстренно, а решение «выключить сайт, пока не разобрались» оказалось разумной тактикой, а не паникой. Когда уязвимость бьёт без авторизации по миллионам хостов, перестраховка выходит дешевле инцидента.
Скорость считается нынче в часах. Между первой попыткой и патчем прошло четыре дня, между патчем и международным переполохом — считанные часы. Инфраструктура, у которой нет готового ответа на вопрос «где у нас вообще крутится PHP и как мы его экстренно обновим», в такие дни оказывается голой. Поэтому главный вывод касается вопроса готовности к подобным ситуациям, т. е. важны инвентаризации, живые версии, отрепетированный аварийный патч. Всё это скучно, делается заранее и окупается ровно в такие недели.
Баги такого масштаба всё чаще находят с помощью ИИ, и хорошо, если первыми их находят те, кто потом выпускает патч, а не те, кто пишет эксплойт. В этот раз, кажется, успели!
Атаки пошли раньше огласки, патч вышел экстренно, а решение «выключить сайт, пока не разобрались» оказалось разумной тактикой, а не паникой. Когда уязвимость бьёт без авторизации по миллионам хостов, перестраховка выходит дешевле инцидента.
Скорость считается нынче в часах. Между первой попыткой и патчем прошло четыре дня, между патчем и международным переполохом — считанные часы. Инфраструктура, у которой нет готового ответа на вопрос «где у нас вообще крутится PHP и как мы его экстренно обновим», в такие дни оказывается голой. Поэтому главный вывод касается вопроса готовности к подобным ситуациям, т. е. важны инвентаризации, живые версии, отрепетированный аварийный патч. Всё это скучно, делается заранее и окупается ровно в такие недели.
Баги такого масштаба всё чаще находят с помощью ИИ, и хорошо, если первыми их находят те, кто потом выпускает патч, а не те, кто пишет эксплойт. В этот раз, кажется, успели!
Таймлайн и источники
Рис. 3. Хронология PHP2Shell: от первой попытки в honeypot до эксплойтов в полях
Связка известна как PHP2Shell. Нашли: LCFR из Calif.io (эксплойт и разбор), демо-видео — Kirill Firsov; PHP Foundation благодарит Calif, OpenAI, Wiz и других. Патчи вышли 21 октября 2026.
Источники:
Объявление и адвизори PHP: PHP: News Archive - 2026
CISA, алерт от 21 октября 2026: Critical Vulnerabilities in PHP Require Immediate Patching | CISA
CERT-EU, Security Advisory 2026-018: Critical Vulnerabilities in PHP
Amazon Threat Intelligence, попытка эксплуатации в MadPot: Amazon Threat Intelligence identifies PHP2Shell exploitation prior to public disclosure in MadPot | Amazon Web Services
Cloudflare, защита на уровне WAF: Cloudflare deploys protections against php2shell vulnerability
Rapid7, анализ уязвимостей и публичных PoC: Rapid7
Tenable, FAQ по PHP2Shell: https://www.tenable.com/blog/php2sh...tly-asked-questions-about-critical-php-remote
Axios, «Black October»: https://www.axios.com/2026/10/22/php-vulnerability-security-update-websites
CNBC, «Чёрный октябрь» и роль ИИ: AI's 'Black October': Critical PHP flaws set off global security scramble
CNBC, отключение госсайтов: Government websites in Europe and elsewhere go dark as software flaw sparks security scramble
Engadget, отключения в ЕС и Канаде, слова Тиффани Фаррисс (Drupal Association): https://www.engadget.com/2293625/go...-canada-taken-offline-over-php-vulnerability/
Reuters, перечень отключившихся организаций (перепечатка в The Star): Factbox-Websites taken offline over PHP risks
TechCrunch, хроника событий: PHP-ocalypse: How two critical web bugs almost broke the internet | TechCrunch
TechRadar, какие крупные сайты затронуло: https://techradar.com/computing/cyb...so-far-from-wikipedia-to-the-internet-archive
Dexerto, игры Cygames на экстренных техработах: Pokemon, Umamusume and other major games taken offline over critical PHP vulnerability - Dexerto
Источники:
Объявление и адвизори PHP: PHP: News Archive - 2026
CISA, алерт от 21 октября 2026: Critical Vulnerabilities in PHP Require Immediate Patching | CISA
CERT-EU, Security Advisory 2026-018: Critical Vulnerabilities in PHP
Amazon Threat Intelligence, попытка эксплуатации в MadPot: Amazon Threat Intelligence identifies PHP2Shell exploitation prior to public disclosure in MadPot | Amazon Web Services
Cloudflare, защита на уровне WAF: Cloudflare deploys protections against php2shell vulnerability
Rapid7, анализ уязвимостей и публичных PoC: Rapid7
Tenable, FAQ по PHP2Shell: https://www.tenable.com/blog/php2sh...tly-asked-questions-about-critical-php-remote
Axios, «Black October»: https://www.axios.com/2026/10/22/php-vulnerability-security-update-websites
CNBC, «Чёрный октябрь» и роль ИИ: AI's 'Black October': Critical PHP flaws set off global security scramble
CNBC, отключение госсайтов: Government websites in Europe and elsewhere go dark as software flaw sparks security scramble
Engadget, отключения в ЕС и Канаде, слова Тиффани Фаррисс (Drupal Association): https://www.engadget.com/2293625/go...-canada-taken-offline-over-php-vulnerability/
Reuters, перечень отключившихся организаций (перепечатка в The Star): Factbox-Websites taken offline over PHP risks
TechCrunch, хроника событий: PHP-ocalypse: How two critical web bugs almost broke the internet | TechCrunch
TechRadar, какие крупные сайты затронуло: https://techradar.com/computing/cyb...so-far-from-wikipedia-to-the-internet-archive
Dexerto, игры Cygames на экстренных техработах: Pokemon, Umamusume and other major games taken offline over critical PHP vulnerability - Dexerto
AI-выжимка
сгенерировано ИИ
Тезисы статьи скоро
Статья читается полностью. Тезисы со ссылками на разделы появятся позже.
Содержание
Codeby Academy
Практика и мастерство
От основ до продвинутого — программы для практиков Codeby.
Перейти к курсу →
Продолжить чтение
Следующий разбор
Часть 1. PHP2Shell (CVE-2026-109618 и 109619)
Ещё по теме
4
СтатьяЧасть 1. PHP2Shell (CVE-2026-109618 и 109619)
0
65
30.10.2026
N
Softпереход из oom в rce. CVE-2026-109618
0
2 тыс.
22.10.2026
СтатьяРазбор критической уязвимости CVE-2026-107181 в Telegram Desktop
0
2 тыс.
13.10.2026
СтатьяIvanti Sentry уязвимость auth bypass: разбор CVE-2026-10523 (CVSS 9.9) и захват mobile gateway
0
1 тыс.
17.08.2026
Комментарии
0