Аккаунт cPanel превращается в root-шелл: разбор CVE-2026-87899

22 сентября cPanel выпустил патчи сразу для трёх уязвимостей. Главная из них, CVE-2026-87899, позволяет любому авторизованному аккаунту cPanel выполнить код от root и получить полный контроль над сервером. Для шаред-хостинга это худший из возможных сценариев.

Коротко

Уязвимость находится в сервисе CalDAV/CardDAV cPanel, который хранит календари и контакты каждого аккаунта. В официальном advisory формулировка прямая: успешная эксплуатация ведёт к выполнению кода от root и полному контролю над сервером. Единственное условие — наличие аккаунта cPanel. Не нужны админские права, особая роль или цепочка zero-day. Достаточно обычного аккаунта.

В том же наборе патчей закрыли ещё две уязвимости:

• CVE-2026-87900 — баг в логике создания баз данных в WP Toolkit. Авторизованный пользователь cPanel может менять базы, принадлежащие чужим аккаунтам на том же сервере.
• CVE-2026-68490 — уязвимость пониже классом в том же CalDAV/CardDAV. Локальный пользователь может читать календари и контакты других аккаунтов, только чтение, без root.

Все три нашёл исследователь Ali Mustafa под ником rz1027, который фигурирует в целой серии свежих находок по cPanel и Plesk.

Почему root-баг самый опасный

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

CVE-2026-87899 эту границу стирает. Аккаунт cPanel на типичном провайдере есть у широкого круга лиц:

• у каждого платящего клиента, включая того, кто зарегистрировался только что по краденой карте;
• у любого, кто сфишил, подобрал по словарю или иначе завладел логином клиента;
• у любого малоценного сайта на сервере, уже скомпрометированного через что-то постороннее: устаревший плагин WordPress, слабый пароль и так далее.

Любой из них получает root. А root на шаред-сервере означает доступ ко всем сайтам на машине: дампы баз по всем тенантам, залитые вебшеллы, массовый дефейс, сбор учётных данных из конфигов, тихий плацдарм на будущее. Типичный сценарий разбора инцидента выглядит одинаково: первичный пролом происходит на самом незначительном аккаунте, а эскалация превращает мелкую проблему в захват всего сервера.

Механику эксплуатации в advisory не раскрывают, что на раннем этапе оправдано. Но код обработки CalDAV/CardDAV, работающий с правами доступа к файлам по каждому аккаунту, представляет классическую поверхность для эскалации. Сервис исполняется с повышенными привилегиями, чтобы управлять хранилищем календарей всех аккаунтов, поэтому дефект в обработке запроса авторизованного пользователя даёт прямой переход от непривилегированного аккаунта к контексту root. cPanel отмечает, что апдейт восстанавливает права на календари и контакты у существующих аккаунтов — а значит права были частью проблемы.

Затронутые и исправленные версии

Уязвимости CalDAV/CardDAV (и -87899, и -68490) затрагивают cPanel & WHM v120 и новее. Пропатченные сборки:

Баг в WP Toolkit (CVE-2026-87900) стоит особняком. Он затрагивает WP Toolkit 6.11.2-10794 и старше, исправлен в 6.11.3 и новее. Важный нюанс: WP Toolkit — это отдельный пакет (wp-toolkit-cpanel) со своим путём обновления, апдейт cPanel & WHM его не тянет. На практике часто встречаются серверы, где сама панель свежая, а встроенный аддон отстаёт на месяцы, поэтому одно обновление не закрывает оба.

Что делать

1. Обновить cPanel & WHM

В WHM: Home » cPanel » Upgrade to Latest Version, либо от root:

/usr/local/cpanel/scripts/upcp --force

Апдейт заодно восстанавливает состояние прав на календари и контакты у уже существующих аккаунтов.

2. Обновить WP Toolkit отдельно

Если WP Toolkit установлен, нужно явно поставить 6.11.3:

bash <(curl https://wp-toolkit.plesk.com/cPanel/installer.sh || wget -O - https://wp-toolkit.plesk.com/cPanel/installer.sh) --version 6.11.3

cPanel не подтвердил, накатят ли автообновления 6.11.3 самостоятельно, поэтому версию стоит проверить вручную.

3. Если обновиться сразу нельзя

Официального воркэраунда для root-бага нет — единственный фикс это апдейт. Значит, это вопрос приоритета, а не опциональная задача. На серверах, которые не получится тронуть немедленно:

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

Есть ли эксплуатация в дикой природе

По состоянию на 23 сентября ни в одном из трёх advisory не упоминается эксплуатация в дикой природе, и ни одна из CVE не попала в каталог Known Exploited Vulnerabilities от CISA. Это хорошая новость, но лишь снимок на конкретный момент, а не гарантия. Root RCE в cPanel представляет высокую ценность: панель установлена на значительной доле рынка шаред-хостинга, и уязвимость такого качества обычно быстро притягивает внимание, как только детали расходятся. Отсутствие в advisory руководства по обнаружению работает и в обратную сторону: cPanel не даёт способа проверить, был ли конкретный сервер задет до апдейта, поэтому фраза «мы ничего не заметили» не равна «ничего не было». При обновлении сервера, который оставался открытым, разумнее заказать аудит безопасности инфраструктуры и проверить целостность, чем считать его чистым по умолчанию.

Общая картина

Это не единичный случай. Тому же исследователю приписывают минимум семь находок по cPanel и Plesk с конца августа, часть из которых — эскалации привилегий, заканчивающиеся root или полным захватом сервера. Среди них RCE через EmailTrack рядом с WP Toolkit ранее в сентябре и два бага в Plesk Backup Manager. Оба продукта принадлежат одному вендору, WebPros, и делят компоненты. cPanel не сообщил, несёт ли Plesk-сборка WP Toolkit ту же уязвимость -87900, и этот вопрос операторам Plesk стоит задать вендору напрямую.

Мы уже разбирали похожий по духу случай в CVE-2026-87902 в ядре WordPress: там тоже критическая RCE без требования авторизации, только на уровне CMS, а не хостинг-панели. Логика одна и та же — чем ниже по стеку сидит уязвимый компонент, тем выше цена одной пропущенной заплатки.

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