Сегодня Mizuho Bank, MUFG Bank и Daiwa Securities остановили часть своих онлайн-сервисов. Shizuoka Bank отключил приложение интернет-банка и сообщил, что включит обратно, «как только безопасность будет подтверждена». К ним добавились Aomori Michinoku Bank, Yamanashi Chuo Bank и San-in Godo Bank.
Это не авария. Их никто не ломал. Они выключили себя сами.
Следом за банками сервисы отключили Japan Airlines, ANA, железнодорожная компания East Japan Railway, сеть Seven-Eleven Japan и французский оператор Orange.
Причина — две уязвимости в PHP. В том самом PHP, на котором работает ваш сайт, если он на WordPress, Битриксе, OpenCart, Joomla или вообще почти на чём угодно. И это только часть того, что произошло за неделю.
Что случилось за семь дней
| Когда | Что |
|---|---|
| 17 октября | Amazon фиксирует первую попытку эксплуатации на своих серверах-приманках. За четыре дня до того, как об уязвимости объявили публично |
| 21 октября, за 10 часов до объявления | Cloudflare видит в своей сети первые тысячи попыток |
| 21 октября | PHP выпускает срочные исправления: CVE-2026-109618 и CVE-2026-109619, обе 9,2 из 10, обе дают выполнение чужого кода на сервере |
| +45 минут | Десятки тысяч попыток |
| +2 часа | Сотни тысяч |
| 21 октября | GitLab закрывает CVE-2026-110264 — 10 из 10, выполнение кода без всякого входа в систему. Уязвимы все версии начиная с 7.0, вышедшей в 2014 году. В том же релизе ещё одиннадцать уязвимостей |
| 21 октября | Node.js выпускает октябрьский набор исправлений: десять уязвимостей, включая выполнение кода через распаковщик Brotli |
| 22 октября | Попыток — миллионы. Японские банки, авиакомпании и железные дороги выключают сервисы |
Три опоры, на которых держится заметная часть интернета, получили критические дыры в один день. PHP — это сайты. GitLab — это хранилища исходного кода и конвейеры сборки, то есть ключи от всего остального. Node.js — это серверная часть современных приложений.
Почему всё так быстро
Атаки начались раньше объявления. Это главное, что стоит унести из хронологии: Amazon видел попытки за четыре дня до раскрытия, Cloudflare — за десять часов. То есть к моменту, когда администратор прочитал новость, сканирование уже шло.
А дальше включается то, о чём мы писали неделю назад: публикация заплатки — это одновременно публикация информации о том, где была ошибка. У уязвимости GitLab, по заявлению исследователя из компании Wiz, рабочий эксплойт собрали за семнадцать минут — по тексту бюллетеня, с помощью языковой модели. Проверить это утверждение со стороны нельзя, но порядок величины согласуется с тем, что мы уже измеряли: у уязвимости Atlassian между публикацией разбора и первыми попытками прошло два часа.
Чего пока не произошло
Теперь холодная вода, и она важна не меньше.
Ни одного подтверждённого взлома нет. Об этом заявили немецкое ведомство BSI, голландская служба кибербезопасности, американское агентство CISA, представитель правительства Японии и исполнительный директор PHP Foundation. Немцы добавили, что эксплуатация оказалась сложнее, чем ожидалось. Японская банковская ассоциация подтвердила, что межбанковская сеть расчётов не пострадала.
То есть миллионы попыток — и ноль результатов. Заголовки про «интернет трещит по швам» пока опережают факты.
Но вывод «значит, можно не торопиться» из этого не следует, и вот почему. Миллионы попыток означают, что инфраструктура массовой атаки уже построена и работает. Не хватает одного — надёжного способа довести попытку до конца. Когда он появится, он разойдётся по тем же самым миллионам запросов за часы. Между «первый подтверждённый взлом» и «массовые взломы» не будет промежутка, в который можно успеть.
Что это значит для вашего сайта
Если сайт на PHP — а он почти наверняка на PHP, — проверьте версию прямо сейчас. В панели хостинга или командой php -v на сервере.
Исправленные версии: 8.2.35, 8.3.36, 8.4.27, 8.5.12. Если у вас меньше — обновляйтесь сегодня.
И отдельно то, о чём почти не пишут. Для ветки 8.1 и всего, что старше, исправления не существует вовсе. Её поддержка закончилась 31 декабря 2025 года, заплатки не будет. Там нужно не обновление, а переезд на другую ветку языка — работа другой сложности, которую может заблокировать какой-нибудь модуль, не обновлявшийся два года.
Переезжать при этом надо сразу на 8.3 или 8.4: у ветки 8.2 поддержка заканчивается 31 декабря 2026 года, то есть через десять недель.
Ещё одна ловушка: установка пакета не перезапускает PHP-FPM. Старый код остаётся в памяти, сайт продолжает работать на уязвимой версии, а php -v при этом показывает новую. После обновления службу надо перезапустить и убедиться, что она действительно стартовала заново.
Если у вас самостоятельный GitLab — обновляться надо было вчера: 19.5.1, 19.4.3, 19.3.6 или соответствующий бэкпорт. Обходного пути нет. Если приложение на Node.js — смотрите октябрьские релизы.
Если обновиться нельзя
Это реальная ситуация, и именно в ней оказались японские банки. Вариантов больше, чем кажется:
- Проверьте, правда ли нельзя. Разверните копию на новой ветке — час работы. Часто выясняется, что мешает один модуль из пятнадцати.
- Выключитесь. Как Mizuho. Заглушка на время разбирательства — честный вариант, а не признание слабости.
- Выбросьте проблемный модуль вместе с функцией, если она не критична. Самый дешёвый выход.
- Изолируйте. Отдельный контейнер, урезанные права, никакого доступа к чужим базам и файлам. Не лечит, но ограничивает ущерб.
- Закройте известную форму атаки правилом на веб-сервере. Мера на дни, не на месяцы.
- Примите риск осознанно — но тогда уберите админку из открытого интернета, вынесите резервные копии за пределы сервера и читайте журналы.
Плохой вариант ровно один: не выбрать никакой и сделать вид, что проблемы нет.
Как это выглядело у нас
Один абзац, для масштаба. Вчера мы обновили три сервера и пять проектов за 10–15 минут, включая один переезд с ветки 8.1 на 8.3. Правок в коде не потребовалось ни одной, простой составил доли секунды на перезапуск.
Это не повод собой гордиться: пятнадцать минут получились не от умения, а оттого, что в этих проектах нет сторонних модулей — ломаться было нечему. На сайте с системой управления и полутора десятками расширений те же пятнадцать минут превращаются в дни, и мешает при этом не ваш код, а чужой. Подробно разберём это отдельно.
Коротко
- 21 октября критические уязвимости закрыли PHP (две, по 9,2 из 10), GitLab (10 из 10, выполнение кода без входа) и Node.js (десять исправлений).
- Атаки на уязвимость PHP начались за четыре дня до публичного раскрытия. Сейчас попыток миллионы.
- Семь японских банков, две авиакомпании, железнодорожная компания, Seven-Eleven и Orange отключили часть сервисов. Добровольно.
- Подтверждённых взломов нет ни одного. Это не повод медлить: инфраструктура атаки уже построена, не хватает только рабочего способа.
- Проверьте версию PHP. Нужно 8.2.35, 8.3.36, 8.4.27 или 8.5.12. Для 8.1 и старше заплатки не существует — только переезд на другую ветку.
- После обновления перезапустите PHP-FPM, иначе старый код останется в памяти.
Источники
- Бюллетени PHP: CVE-2026-109618 и CVE-2026-109619, 21 октября 2026 года.
- Сроки поддержки веток — поддерживаемые версии и список неподдерживаемых на php.net.
- Отключение сервисов японскими компаниями и заявление банковской ассоциации — сообщение Jiji Press от 22 октября 2026 года.
- Число попыток эксплуатации, данные Cloudflare и Amazon, заявления BSI, CISA, правительства Японии и PHP Foundation — публикация The Next Web от 22 октября 2026 года.
- Сведения об уязвимости GitLab и об уязвимостях Node.js приводятся по публикациям профильных изданий от 21–22 октября 2026 года; номера исправленных версий сверены с несколькими независимыми источниками.
- Про скорость появления атак после выхода заплатки — наша статья от 15 октября. Про то, чем платят на каждой ступени самостоятельности, — шкала зависимости.