Американское агентство CISA отвело федеральным ведомствам всего три дня на устранение новой активно эксплуатируемой дыры в LiteSpeed для cPanel. Для тех, кто держит shared hosting, реселлерские панели или просто любит откладывать обновления «на окно», сигнал предельно понятный: уязвимость LiteSpeed cPanel уже вышла из категории теории и перешла в практику атак.
О проблеме, как пишет BleepingComputer, CISA сообщила 16 июня 2026 года, одновременно добавив уязвимость в каталог Known Exploited Vulnerabilities (KEV). Речь идет о high-severity flaw в пользовательском плагине LiteSpeed для cPanel, который ставится вместе с WHM-плагином. Уязвимыми названы все версии user-end plugin ниже 2.4.8. Сценарий неприятный для любого хостинга: если у злоумышленника уже есть FTP-доступ или web shell, он может поднять привилегии до root на shared hosting-серверах с CloudLinux/CageFS.
Техническая причина довольно приземленная и оттого особенно раздражающая: weakness класса UNIX symlink following. То есть проблема не из разряда экзотических цепочек с тремя нулевыми днями и шаманством вокруг памяти, а из знакомой администраторам категории ошибок, которые в мультиарендной среде бьют особенно больно. Когда на одном сервере сидят десятки или сотни клиентов, любая возможность вырваться из ограниченного пользовательского контекста наверх превращается из локальной неприятности в риск для всей площадки.
LiteSpeed еще в начале июня пометила дыру как активно эксплуатируемую и выпустила срочное обновление. Вендор отдельно посоветовал проверить серверы на возможные признаки компрометации через поиск по логам cPanel и var/cPanel: индикаторами названы вызовы, связанные с generateEcCert, packageUserSize и cert_action_entry. Если команда что-то находит, это не автоматически означает полный захват сервера, но уже повод поднимать журналы событий и смотреть, что делали обнаруженные IP-адреса. Практический смысл тут простой: патч сам по себе закрывает дверь, но не отвечает на вопрос, не вошел ли кто-то в нее вчера.
Важен и регуляторный контекст. CISA добавила проблему в KEV не для красоты, а в логике Binding Operational Directive 26-04. Этот документ был выпущен на прошлой неделе и заменил более старые директивы 19-02 и 22-01. Новая схема требует от федеральных агентств расставлять приоритеты по патчам не по календарю релизов и не по размеру CVSS-балла как такового, а по реальному риску эксплуатации. В фокусе четыре вопроса: есть ли уязвимость в KEV, торчит ли актив наружу в интернет, можно ли автоматизировать атаку в массовом масштабе и дает ли успешная эксплуатация частичный или полный контроль над системой. В случае с уязвимостью LiteSpeed cPanel ответы выглядят достаточно тревожно, чтобы дедлайн в три дня не казался бюрократическим перегибом.
Для русскоязычной аудитории здесь нет повода думать, что история касается только американских госорганов. cPanel, WHM, LiteSpeed и CloudLinux давно живут далеко за пределами США и особенно популярны там, где shared hosting до сих пор остается рабочей бизнес-моделью. И если федеральным структурам дают 72 часа на реакцию, коммерческим хостерам, SaaS-проектам на арендованной инфраструктуре и командам, у которых legacy-панель «просто работает», логично смотреть на ситуацию не менее серьезно. Эта уязвимость LiteSpeed cPanel не требует от атакующего невозможного: достаточно уже имеющегося низкоуровневого доступа, а дальше ошибка в плагине помогает превратить его в root. В реальных инцидентах именно такие цепочки часто и срабатывают: сначала слабый пароль, уязвимый сайт или забытый web shell, потом тихое повышение привилегий и движение по серверу без лишнего шума.
Отдельно настораживает повторяемость сюжета. BleepingComputer напоминает, что всего месяц назад CISA уже требовала от федеральных ведомств срочно закрыть другую уязвимость в LiteSpeed cPanel, которую злоумышленники использовали для запуска произвольных скриптов с root-привилегиями. Даже если не упираться в номера CVE, которые в подобных пересказах иногда путают сильнее, чем хотелось бы безопасникам, тренд читается безошибочно: стек вокруг cPanel и хостинговых плагинов оказался в зоне повышенного интереса атакующих. А значит, обсуждать только «установили ли мы последний патч» уже поздно. Нужны как минимум инвентаризация exposed-активов, ревизия доступа по FTP и SSH, контроль web shell-артефактов, проверка журналов и понимание, где именно у вас в инфраструктуре до сих пор живут старые сборки плагинов.
Для разработчиков и продуктовых команд вывод тоже довольно прикладной. Если проект размещен у провайдера на shared hosting или управляется через внешнюю админпанель, безопасность не заканчивается на приложении и зависимостях из package manager. Чужой плагин в панели, о котором команда вспоминает раз в год, может стать точкой входа не хуже дырявого CMS-модуля. Для бизнеса это уже вопрос не только простоя, но и соседского риска: компрометация одной учетной записи на общей площадке в худшем случае открывает путь к данным других клиентов и превращает обычный инцидент в репутационный пожар.
История с LiteSpeed для cPanel в очередной раз показывает неприятную, но честную вещь: наиболее опасными часто оказываются не «громкие» zero-day в хайповых продуктах, а инфраструктурные плагины второго плана, которые слишком глубоко встроены в операционную рутину, чтобы о них регулярно думали. И пока хостинговый рынок продолжает жить на сложных связках из cPanel, WHM, CloudLinux и вспомогательных модулей, такие уязвимости LiteSpeed cPanel будут оставаться не частным багом одного вендора, а симптомом всей экосистемы, где цена забытого обновления измеряется уже не часами работ админа, а root-доступом для атакующего.