Что произошло?
17 октября злоумышленники атаковали инфраструктуру российских хостинг-провайдеров через уязвимость в VMmanager 6, платформе виртуализации от ISPsystem. Атаки затронули FirstVDS и других провайдеров, использующих эту систему. В некоторых случаях злоумышленники получили возможность работать с дисками клиентских виртуальных серверов на уровне хостовой инфраструктуры и извлекать оттуда пароли, SSH-ключи, API-токены, конфигурации и другие чувствительные данные. При этом сами виртуальные серверы могли продолжать работать совершенно нормально. То есть сайт открывается, приложение отвечает, мониторинг рисует привычные графики, а содержимое твоего сервера уже кто-то изучает снаружи. ISPsystem подтвердил инцидент.
Это больше, чем очередная новость про утечку базы данных...
Когда ты арендуешь VPS, обычно кажется, что покупаешь изолированный кусок вычислительных ресурсов. У тебя собственная операционная система, собственные приложения, доступ по SSH, файрвол, бэкапы и прочие атрибуты взрослой серверной жизни. Но физически и архитектурно твой сервер остаётся частью чужой инфраструктуры. Между тобой и железом есть гипервизор, панель управления, сервисные учётные записи, внутренние сети и целая цепочка программного обеспечения, о существовании которого большинство клиентов даже не задумывается.
Если проблема находится на уровне управления виртуализацией, границы твоего виртуального сервера могут оказаться не такими надёжными, как ты привык считать. Можно идеально настроить Linux, закрыть ненужные порты, запретить вход по паролю и установить все обновления. Но если злоумышленник получает доступ к диску со стороны хостовой инфраструктуры, твои настройки внутри гостевой системы не обязательно помогут. В случае с VMmanager особенно неприятно то, что отсутствие очевидных следов внутри виртуальной машины не означает отсутствия компрометации.
Иными словами, безопасность собственного сервера не всегда находится исключительно в твоих руках. Иногда она заканчивается ровно там, где начинается чужая административная панель.
А теперь к PHP
21 октября разработчики языка выпустили экстренные обновления, закрывающие две критические уязвимости: CVE-2026-109618 и CVE-2026-109619. Обе получили оценку 9,2 по CVSS 4.0 и при определённых условиях позволяют удалённому злоумышленнику выполнять произвольный код на сервере без предварительной аутентификации. Уязвимости затрагивают установки PHP, обслуживающие веб-запросы, включая различные конфигурации PHP-FPM, Apache и другие варианты развёртывания.
PHP по-прежнему лежит в основе огромного количества сайтов, интернет-магазинов, CMS и внутренних корпоративных систем. WordPress, Drupal, Joomla, Magento и самописные приложения существуют в совершенно разных условиях, но могут зависеть от одной и той же среды исполнения. Поэтому уязвимость на уровне PHP не ограничивается каким-то одним продуктом или разработчиком. Она потенциально затрагивает целый пласт веба.
По данным предупреждения NHS England Digital, исследователям удалось продемонстрировать эксплуатацию обеих уязвимостей с удалённым выполнением кода. Информация о проблемах начала распространяться до запланированного раскрытия, а сообщения об атаках появились ещё до того, как обновления успели установить повсеместно. Получается довольно мерзкая гонка: разработчики выпускают исправление, администраторы пытаются его применить, а злоумышленникам достаточно найти тех, кто по какой-то причине отложил обновление.
Наши привычки
Мы привыкли воспринимать интернет как огромную, но в целом устойчивую систему. Сайты работают, облака масштабируются, данные синхронизируются, приложения общаются через API. Всё это выглядит почти естественным состоянием вещей. Но за удобным интерфейсом скрывается невероятно сложная конструкция из библиотек, рантаймов, операционных систем, контейнеров, сетевых сервисов, систем управления и сторонних зависимостей.
Причём проблема не только в количестве уязвимостей. Уязвимости существовали всегда, и сам факт их обнаружения ещё не означает, что завтра перестанет работать половина интернета. Вопрос в другом: насколько быстро их теперь находят, насколько быстро превращают в рабочие инструменты атаки и сколько систем успевают исправить до того, как эти инструменты начинают массово применять.
Раньше поиск сложных ошибок мог требовать серьёзной экспертизы, времени и значительных ресурсов. Теперь инструменты на основе искусственного интеллекта помогают исследователям анализировать большие объёмы кода и находить проблемы, которые долго оставались незамеченными. Та же технология потенциально упрощает работу злоумышленников: от изучения исходников до поиска способов обойти защиту и автоматизации отдельных этапов атаки.
Это не означает, что нейросеть завтра взломает любой сервер одной кнопкой. Реальность, к сожалению, не настолько кинематографична. Но барьер входа постепенно снижается, а скорость исследования программного обеспечения растёт. И это меняет экономику кибербезопасности: у защитников становится больше инструментов, но и у атакующих тоже. При этом защитник обязан работать по регламенту, сохранять доступность сервиса и отвечать за последствия, а атакующему достаточно найти один удачный маршрут.
Особенно показательно, что уязвимости могут годами существовать в фундаментальных компонентах. Программное обеспечение становится стандартом де-факто, на него опираются миллионы проектов, а затем выясняется, что определённая комбинация условий позволяет обойти привычные границы безопасности. И проблема внезапно превращается из технического долга одного проекта в задачу для целой отрасли.
Отдельная история — концентрация инфраструктуры. Тысячи серверов управляются через одни и те же платформы, проекты используют общие библиотеки, а хостинг-провайдеры строят сервисы поверх одинаковых технологических решений. Это удобно, дёшево и эффективно ровно до того момента, когда в одном из общих компонентов обнаруживается серьёзная проблема.
Преимущество масштаба превращается в множитель риска
Уязвимость в небольшом независимом приложении может затронуть одного владельца. Уязвимость в широко используемом рантайме или панели управления способна открыть путь к множеству систем сразу. Не обязательно все они будут взломаны, но сама возможность массового воздействия меняет ситуацию. И чем больше зависимостей скрыто за красивой кнопкой «Создать сервер», тем сложнее обычному клиенту оценить реальный уровень риска.
При этом индустрия продолжает продавать нам удобство как синоним надёжности. Разворачивай инфраструктуру за минуту, подключай интеграции в пару кликов, храни секреты в переменных окружения, отправляй всё в облако, автоматизируй деплой. Сама по себе автоматизация не зло, но она часто создаёт ложное ощущение, будто сложность системы исчезла. Нет, она просто переместилась туда, куда пользователь обычно не смотрит.
В результате один забытый токен, одна уязвимая панель управления или один неустановленный патч могут оказаться важнее всех остальных мер защиты вместе взятых. А если атакующий получает доступ на уровне хостовой системы, последствия могут выходить далеко за пределы одного приложения.
И это касается не только крупных компаний. Небольшие студии, независимые разработчики, владельцы интернет-магазинов и люди, которые держат собственные сервисы на VPS, часто располагают гораздо меньшими ресурсами для безопасности. У них нет круглосуточного SOC, отдельной команды реагирования и человека, который только и делает, что изучает журналы событий. Обычно есть разработчик, несколько проектов и надежда, что сегодня хотя бы ничего не сломается.
Надежда, как известно, отличный инструмент планирования бюджета, но довольно сомнительный механизм защиты серверов.
Что с этим делать? Очевидного универсального решения нет. Но есть несколько вещей, которые пора перестать считать необязательными. Обновления критических компонентов должны устанавливаться оперативно, а не после очередного релиза сайта. Панели управления и административные интерфейсы не должны без необходимости торчать в публичном интернете. Секреты не стоит хранить там, где компрометация одного сервера автоматически раскрывает доступ ко всем остальным. Бэкапы нужно не просто создавать, но и проверять возможность восстановления. А после подтверждённого инцидента следует исходить из того, что затронутые пароли, ключи и токены могли быть скопированы, даже если никаких подозрительных процессов внутри системы не обнаружено.
И самое главное — перестать путать работоспособность с безопасностью. Сайт может открываться, сервер может отвечать на запросы, а база данных может исправно принимать записи. Ни один из этих фактов не доказывает, что система не скомпрометирована.
Я не думаю, что интернет завтра рухнет. Подобные прогнозы обычно пишут люди, которым нужно продать очередной курс по информационной безопасности или промт с помощью которого Клод найдет и закроет все уязвимости в проекте. Гораздо вероятнее другой сценарий: больше инцидентов, больше экстренных обновлений, больше временно отключённых сервисов и всё меньше времени между обнаружением уязвимости и её практической эксплуатацией.
Но это не делает ситуацию менее серьёзной.
Мы строим всё больше экономики, коммуникаций и повседневной жизни на инфраструктуре, сложность которой не успеваем осмыслить. При этом значительная часть этой инфраструктуры зависит от ограниченного набора программных компонентов, общих стандартов и поставщиков. Система становится мощнее, но одновременно увеличивается количество способов, которыми её можно вывести из равновесия.
Так что да...
Мы стоим на краю пропасти. Не потому, что интернет обязательно перестанет существовать, а потому, что цена ошибки растёт быстрее, чем многие организации успевают перестраивать свои процессы безопасности.
Ирония в том, что чем больше мы автоматизируем, объединяем и упрощаем, тем сильнее зависим от вещей, которые не контролируем напрямую. Мы можем самостоятельно написать приложение, выбрать базу данных, настроить сервер и закрыть все лишние порты. Но мы не можем в одиночку проверить весь код, на котором работает современная цифровая инфраструктура.
В какой-то момент вопрос уже не в том, найдут ли новую уязвимость. Их будут находить. Вопрос в том, сколько времени потребуется, чтобы превратить её в массовую проблему, и сколько систем к этому моменту останутся без защиты.
И вот это, пожалуй, самое тревожное. Не существование дыр в программном обеспечении, а скорость, с которой они перестают быть теоретическими.