CVE-2026-41940 — Обход аутентификации до входа в cPanel и WHM с получением прав root через CRLF-инъекцию в файл сессии

Технический детальный анализ с точки зрения защиты

1. Краткое описание

cPanel и WHM — доминирующее программное обеспечение панелей управления для общего и реселлерского веб-хостинга. cPanel — это интерфейс учётной записи клиента; WHM — это административный интерфейс уровня root, используемый хостинг-провайдерами и владельцами серверов. Обе панели обслуживаются одним и тем же Perl-демоном cpsrvd, который слушает парные порты для каждого интерфейса (cPanel: 2082/2083, WHM: 2086/2087, Webmail: 2095/2096).

CVE-2026-41940 позволяет атакующему вообще без каких-либо учётных данных манипулировать состоянием сессии на диске до прохождения аутентификации, заставляя cpsrvd впоследствии интерпретировать предоставленные атакующим данные как легитимные атрибуты полностью аутентифицированной, привилегированной root-сессии. Результат — полная компрометация плоскости управления каждого веб-сайта и учётной записи на сервере — это не проблема отдельного арендатора, а проблема всего сервера, всего провайдера, а в совокупности — всей индустрии, учитывая рыночную концентрацию cPanel.

2. Почему эта уязвимость важнее, чем её оценка CVSS

Оценка 9.8 по CVSS встречается достаточно часто, чтобы к ней можно было привыкнуть. Три структурных фактора делают CVE-2026-41940 на практике необычно серьёзной:

1. Радиус поражения — весь сервер, а не одна учётная запись. Компрометация WHM — это компрометация root. Каждая клиентская учётная запись, каждая база данных, каждый закрытый ключ TLS, каждая резервная копия и каждая DNS-зона на этом сервере немедленно оказываются под угрозой.

2. Это была настоящая уязвимость нулевого дня в течение примерно двух месяцев. Телеметрия KnownHost указывает на начало эксплуатации около 23 февраля 2026 года, задолго до выхода патча 28 апреля. Любая организация, чьи системы были доступны из интернета в этот период, должна исходить из возможной (а не просто теоретической) компрометации и провести ретроспективную оценку, а не полагаться на «мы установили патч, значит, всё в порядке».

3. Большинство затронутых организаций не могут самостоятельно установить это исправление. cPanel обычно развёртывается хостинг-провайдерами от имени арендаторов. Конечные клиенты не имеют контроля над исправлением на уровне кода и полностью зависят от графика обновлений своего провайдера — именно поэтому несколько крупных хостеров (Namecheap, KnownHost, HostPapa, InMotion) решили превентивно блокировать входящий трафик на затронутые порты, а не ждать обновления от каждого арендатора.

На этом третьем пункте стоит остановиться подробнее. По оценкам, cPanel контролирует около 94% рынка панелей управления. Единственная логическая ошибка в коде обработки сессий одного вендора на несколько недель превратилась в де-факто общеотраслевую уязвимость получения root-доступа. Этот риск концентрации — повторяющаяся тема, которую стоит осознать независимо от данной конкретной CVE.

3. Архитектурные основы

3.1 cpsrvd и модель портов

cpsrvd — это долгоживущий Perl-демон, который обслуживает все три интерфейса продуктов cPanel из одного и того же бинарного файла и, что критично, из одного и того же кода обработки сессий:

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

3.2 Двойное представление сессии

Сессии cPanel сохраняются в двух параллельных представлениях на диске, по-видимому, по соображениям производительности:

1. Необработанный файл сессии (/var/cpanel/sessions/raw/<session-id>) — построчный текстовый формат ключ=значение, один атрибут на строку.
2. JSON-кэш (/var/cpanel/sessions/cache/<session-id>, концептуально) — структурированный JSON-документ, который при обычной обработке запросов читается преимущественно, поскольку его парсинг дешевле.

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

4. Первопричина: четыре независимые ошибки, объединяющиеся в цепочку

CVE-2026-41940 — это не единичная ошибка. Это результат четырёх отдельных слабостей, каждая из которых по отдельности могла бы быть объяснима как изолированное проектное решение, которые вместе образуют полный обход аутентификации. Эта структура «швейцарского сыра» поучительна для специалистов по защите и аудиторов кода далеко за пределами данного конкретного продукта.

4.1 Уровень 1 — Очистка, обеспечиваемая соглашением, а не самим путём записи

Подсистема сессий cPanel уже содержала процедуру очистки, отвечающую за удаление опасных символов — возвратов каретки, перевода строки и = — из значений сессии перед их сохранением. Проблема заключается в том, откуда эта процедура вызывалась: она находилась внутри функций-обёрток более высокого уровня (API «создания»/«изменения» сессии), и именно вызывающий код должен был использовать эти обёртки, а не записывать данные сессии напрямую.

Обработчик HTTP Basic Authentication внутри cpsrvd — путь кода, который принимает учётные данные непосредственно из HTTP-заголовка Authorization, — сохранял введённый пароль в файл сессии до аутентификации через низкоуровневую функцию сохранения, которая обходила очищающую обёртку. Поскольку очистка была опциональной, а не обязательной на этапе записи на диск, этот конкретный вызывающий код молча её пропустил.

Это классический сценарий отказа «проверяй у источника, а не у приёмника»: пока элемент управления безопасностью можно обойти, просто вызвав другую функцию, рано или поздно это произойдёт — из-за недосмотра, рефакторинга или пути кода, который никто не проверял на соответствие данному конкретному контролю. Окончательное исправление, выпущенное cPanel, перемещает вызов очистки внутрь самой функции сохранения, так что теперь его невозможно пропустить ни для одного вызывающего кода — ни настоящего, ни будущего.

4.2 Уровень 2 — Шифрование, которое атакующий мог отключить, управляя входными данными

Механизм записи сессии шифрует конфиденциальные поля (в частности, поле пароля) с использованием симметричного ключа на сессию. Этот ключ создаётся на основе компонента, встроенного в файл cookie сессии, который предоставляет клиент. В уязвимом коде, если этот компонент ключа отсутствовал в запросе — что полностью контролируется атакующим, поскольку он решает, какой cookie отправить, — этап шифрования молча пропускался, а не запись отклонялась.

Другими словами: атакующий, намеренно опуская часть своего сессионного cookie, может записать свои собственные данные на диск в незашифрованном виде. Шифрование, активация которого может быть отключена недоверенной стороной, предоставляющей входные данные, не является значимой границей безопасности; оно должно отказывать в работе закрыто (отказ в сохранении или отказ в запросе), а не открыто (сохранение без защиты).

4.3 Уровень 3 — Различие форматов между необработанным файлом и JSON-кэшем

Это суть «инъекции» в CRLF-инъекции. Необработанный файл сессии разделён на строки: последовательность «возврат каретки / перевод строки» завершает одну запись ключ=значение и начинает следующую. Формат JSON-кэша, напротив, представляет ту же последовательность символов как экранированную подстроку внутри одного JSON-строкового значения — семантически инертную, просто данные.

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

В этот момент CRLF-последовательности, которые атакующий встроил в свой «пароль», перестают быть инертными байтами внутри одного поля и становятся разделителями записей, расщепляя то, что должно было быть одним значением, на несколько независимых строк ключ=значение. Каждая из этих строк — включая те, у которых атакующий полностью контролирует имя и значение, — затем повышается до записи верхнего уровня в восстановленном JSON-кэше сессии, неотличимой для остального кода от легитимно установленного атрибута сессии.

Общий урок: всякий раз, когда два синтаксических анализатора могут интерпретировать одну и ту же последовательность байтов по-разному — сырой файл против кэша, форма URL против JSON, одно соглашение об экранировании против другого, — это расхождение является скрытым примитивом инъекции. Неважно, какой анализатор «более правильный»; важно то, что недоверенные данные могут пересекать границу между двумя представлениями без повторной проверки на соответствие грамматике второго анализатора.

4.4 Уровень 4 — Флаг «уже аутентифицирован» без криптографической привязки

Последнее звено в цепочке находится в самой логике проверки пароля. Если сессия уже содержит поле, фиксирующее недавнюю успешную временную метку внутренней аутентификации, проверка пароля пропускается полностью — одно только присутствие этого поля считается достаточным доказательством того, что аутентификация уже прошла. Аналогичный флаг подтверждения двухфакторной аутентификации подавляет запрос 2FA исключительно на основе своего присутствия.

Оба поля существуют для легитимных внутренних целей (передача единого входа между компонентами cPanel, внутренние инструменты, которые уже проверили пользователя другим способом). Проектная ошибка заключается в том, что ни одно из этих полей не привязано криптографически к какому-либо реальному событию аутентификации — это просто атрибуты сессии, которые, после того как Уровень 3 позволяет атакующему записывать произвольные атрибуты сессии, могут быть просто подделаны. Флаг, означающий «доверься мне, это уже было проверено», имеет смысл только в том случае, если его невозможно установить со стороны проверяемого.

4.5 Совокупный эффект

Ни одна из этих четырёх слабостей по отдельности не является катастрофической:

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

Объединившись, они дают полную неаутентифицированную удалённую компрометацию root. Это именно тот тип уязвимости, который не выявит модульное тестирование отдельных функций, потому что ни одна функция сама по себе не является «неправильной» — ошибка живёт во взаимодействии между подсистемами, каждая из которых была проанализирована независимо.

5. Концептуальная схема атаки

Ниже описаны логические этапы эксплуатации с уровнем детализации, уже опубликованным в бюллетенях вендора и отрасли, без воспроизведения буквальных байтов полезной нагрузки, закодированных заголовков или готовой к выполнению последовательности запросов.

Начиная с этапа 5, атакующий получает обычный, полностью авторизованный доступ к API WHM. Легитимный набор функций WHM — пользовательские хуки, управление пакетами/шаблонами, конфигурация обработчиков PHP, cron и управление учётными записями, редактирование DNS-зон — более чем достаточен, чтобы превратить это в интерактивное выполнение кода от root через полностью «поддерживаемые» административные функции, без необходимости в дополнительных уязвимостях.

В публичных отчётах отмечается, что полная цепочка требует лишь небольшого количества HTTP-запросов и включает безобидную гонку условий, связанную с недетерминированным порядком ключей хэша Perl при восстановлении кэша — то есть для полной надёжности может потребоваться небольшое количество повторных попыток, что имеет ценность для обнаружения (см. раздел 7.3).

6. Хронология

7. Инженерная защита обнаружения

7.1 Индикаторы на уровне файловой системы (наибольшая достоверность)

Наиболее надёжные свидетельства находятся в хранилище необработанных сессий — /var/cpanel/sessions/raw/. Сессия, возникшая в результате неудачного или непривилегированного входа, не должна содержать ни одно из следующих полей верхнего уровня:

• user=root
• hasroot=1
• tfa_verified=1
• successful_internal_auth_with_timestamp=<значение>

...если только эта сессия действительно не прошла полную аутентификацию root и 2FA через обычный процесс входа. Наличие этих полей в сессии, метаданные происхождения которой показывают неудачную попытку ввода пароля, является сильным индикатором эксплуатации.

Ещё более достоверный сигнал: несколько строк pass= в одном файле сессии. При нормальной работе сессия содержит ровно одно поле пароля. Несколько вхождений могут быть вызваны только поведением расщепления CRLF, лежащим в основе этой уязвимости, и должны рассматриваться как практически неопровержимый индикатор компрометации.```bash

Sessions carrying privileged top-level fields

grep -lE '^(hasroot|tfa_verified|successful_internal_auth_with_timestamp)=1'
/var/cpanel/sessions/raw/* 2>/dev/null

Sessions with an embedded carriage return inside the password field

(indicative of CRLF-split injection rather than a single legitimate value)

grep -lP 'pass=.\r' /var/cpanel/sessions/raw/ 2>/dev/null

Sessions with more than one "pass=" line — should never legitimately occur

for f in /var/cpanel/sessions/raw/*; do n=$(grep -c '^pass=' "$f" 2>/dev/null) [ "${n:-0}" -gt 1 ] && echo "SUSPECT: $f ($n pass= lines)" done

### 7.2 Корреляция логов доступа (когда файлы сессий не централизованно пересылаются)

Если исходные файлы сессий не хранятся достаточно долго или не пересылаются в центральную систему логирования, логи доступа от `cpsrvd` могут их заменить. Полезны два шаблона корреляции:

**Шаблон A — неудачный вход сразу же после неуместного заголовка Basic-аутентификации.** Обычный клиент не отправляет заголовок `Authorization: Basic` в запросе на произвольный URL, не являющийся страницей входа, сразу после неудачной отправки пароля с того же источника. Эта последовательность — `401` на конечной точке входа, за которым в течение короткого временного окна следует запрос с Basic-аутентификацией в другом месте, коррелируемая по IP-источнику и/или куки сессии — является аномальной и заслуживает сигнализации.

**Шаблон B — токен в стиле `cpsess`, появляющийся в URL до того, как он был законно выдан.** Легитимные токены безопасности для сессии генерируются на стороне сервера и впервые появляются в ответе `Set-Cookie`/редиректе *до* того, как будут использованы в последующих URL запросов. Токен, появляющийся во входящем URL запроса без соответствующего предшествующего сгенерированного сервером экземпляра, не соответствует нормальному поведению клиента и заслуживает пометки, особенно если токен не соответствует ожидаемому формату, генерируемому сервером.

### 7.3 Поведенческий сигнал / сигнал повторных попыток

Поскольку регенерация кэша подвержена недетерминированному порядку хеш-ключей Perl, успешная эксплуатация в полевых условиях, как наблюдалось, иногда требует небольшого количества повторных попыток, прежде чем нужные поля «победят» в регенерированном кэше. Короткая серия структурно похожих запросов (один и тот же источник, та же сессия, тот же шаблон целевого URL, происходящие в течение нескольких секунд друг за другом), за которой сразу следует успешное использование административного API, является вторичным подтверждающим сигналом, который стоит взвешивать наряду с §7.1 и §7.2 — сам по себе он слишком общий, чтобы на него сигнализировать, но он повышает уверенность в сочетании с индикаторами файловой системы или логов доступа, описанными выше.

### 7.4 Индикаторы пост-компрометации

Поскольку доступ к WHM — это root-доступ, относитесь к подтверждённой эксплуатации как к полному расследованию компрометации хоста, а не как к инциденту веб-приложения. Ищите:

- Неожиданные учётные записи пользователей уровня WHM/root или учётные записи реселлеров, созданные вне процессов управления изменениями
- Новые или неузнаваемые открытые ключи SSH в `~/.ssh/authorized_keys` пользователя `root` или любой хостируемой учётной записи
- Неузнаваемые записи cron, как общесистемные, так и для каждой хостируемой учётной записи
- Пользовательские «хуки» WHM, которые не были подготовлены известными администраторами
- Неожиданные изменения в конфигурации обработчика PHP, определениях пакетов/шаблонов или файлах DNS-зон
- Исходящие соединения или процессы, работающие от root, которые не соответствуют известным службам cPanel/WHM

---

## 8. Плейбук по смягчению и реагированию на инциденты

### 8.1 Немедленные действия

1. **Проведите инвентаризацию** каждого экземпляра cPanel/WHM/WP Squared, находящегося под вашим контролем или контролем вашего провайдера.
2. **Определите интернет-доступность** для каждого экземпляра в течение окон раскрытия и предшествующего раскрытию информации (рассматривайте период с 23 февраля по 28 апреля 2026 года как критическое окно доступности).
3. **Установите исправление до исправленной версии:**

   | Ветка | Минимальная исправленная версия |
   |---|---|
   | 11.110.0.x | 11.110.0.97 |
   | 11.118.0.x | 11.118.0.63 |
   | 11.126.0.x | 11.126.0.54 |
   | 11.132.0.x | 11.132.0.29 |
   | 11.134.0.x | 11.134.0.20 |
   | 11.136.0.x | 11.136.0.5 |
   | WP Squared | 11.136.1.7 |

4. **Проверьте** применённую версию с помощью `/usr/local/cpanel/cpanel -V`.
5. **Перезапустите `cpsrvd`** после установки исправления — неперезапущенный демон может продолжать выполнять уязвимый код в памяти (`/scripts/restartsrv_cpsrvd`).
6. Если вы полагаетесь на стороннего хостинг-провайдера, **подтвердите статус исправления напрямую у провайдера**, а не предполагайте, что оно было применено.
7. Серверы с **отключённым автоматическим обновлением или зафиксированной версией** не восстановятся сами — они требуют явного ручного вмешательства и должны быть приоритетными, так как статистически наиболее вероятно, что они всё ещё уязвимы.

### 8.2 Краткосрочные меры (в течение нескольких дней после установки исправления)

- Выполните запросы обнаружения на основе файловой системы и логов из §7 для всего окна доступности, а не только «с момента, как мы заметили».
- Проверьте WHM на наличие неожиданных учётных записей, ключей SSH, записей cron и пользовательских хуков.
- Проверьте целостность файлов `/etc/`, `/usr/local/cpanel/`, конфигурации оболочки root и `authorized_keys` на соответствие известным хорошим базовым образам или резервным копиям.
- Смените пароли WHM для root и реселлеров, токены API и ключи SSH **независимо от того, были ли найдены индикаторы компрометации** — учитывая двухмесячное окно эксплуатации до раскрытия, отсутствие доказательств не является сильным доказательством отсутствия на хосте, который был доступен в течение этого периода.
- Очистите состояние сессии (`/var/cpanel/sessions/raw/` и каталог кэша JSON) после установки исправления, чтобы никакие остаточные поддельные сессии не могли быть воспроизведены.

### 8.3 Долгосрочное усиление защиты

- Ограничьте входящий доступ к портам cPanel/WHM/Webmail (2082, 2083, 2086, 2087, 2095, 2096) известными диапазонами административных IP через разрешающую политику брандмауэра. Эти порты управляющей плоскости не должны быть широко доступны через Интернет в нормальных условиях эксплуатации.
- Пересылайте логи доступа `cpsrvd` — и в идеале события записи сессий — в централизованно хранящуюся SIEM, так как файлы сессий на хосте эфемерны и легко теряются во время расследования, если их не сохранить быстро.
- Создайте базовую инвентаризацию ожидаемых учётных записей WHM, ключей SSH и заданий cron, а также отслеживайте отклонения.
- Отслеживайте версию cPanel/WHM и периодичность установки исправлений как первостепенный показатель управления активами, особенно для самостоятельно управляемых (не переданных на аутсорсинг) экземпляров.

### 8.4 Если компрометация подтверждена

- **Не пытайтесь исправить скомпрометированный хост на месте.** Получив root, атакующий мог изменить что угодно, включая инструменты, которые вы используете для расследования. Считайте «очистку» на месте ненадёжной.
- **Восстановите систему из заведомо чистых, исправленных образов**, а не устанавливайте исправление и продолжайте работать на потенциально скомпрометированной системе.
- **Смените все административные учётные данные** на всём сервере, а не только те, которые были непосредственно затронуты.
- **Замените все ключи SSH**, включая те, что принадлежат хостируемым учётным записям клиентов, так как атакующий с root-доступом мог собрать или внедрить любой из них.
- **Предположите, что все данные клиентов, размещённые на машине, были раскрыты**, и выполните применимые обязательства по уведомлению о нарушении.
- **Проверьте возможность бокового перемещения** в смежные внутренние сегменты сети, так как скомпрометированная хостинг-инфраструктура является распространённой точкой перехода в корпоративные среды (например, через учётные данные, доверительные отношения SSH или общие секреты, повторно используемые в других местах).

---

## 9. Часто задаваемые вопросы

**Является ли эта уязвимость червеобразной / пригодной для массовой автоматизированной эксплуатации?**
Лежащая в основе цепочка полностью неаутентифицирована и включает небольшое фиксированное количество HTTP-запросов, поэтому CISA повысила её статус до KEV, и инструменты массового сканирования, ссылающиеся на этот CVE, уже появились в открытом доступе. Считайте любой незапатченный, доступный через Интернет экземпляр находящимся под активным риском оппортунистической, автоматизированной компрометации, а не только целевой атаки.

**Защищает ли двухфакторная аутентификация от этой уязвимости?**
Нет. Инъекция напрямую подделывает флаг сессии «2FA уже проверено», поэтому вызов 2FA вообще не отображается. 2FA не обеспечивает смягчения для этой конкретной уязвимости.

**Сможет ли мой WAF (брандмауэр веб-приложений) это обнаружить?**
Только если он одновременно нормализует/проверяет полезные нагрузки `Authorization: Basic` на наличие встроенных последовательностей CRLF *и* отдельно проверяет куки сессии на наличие некорректного/усечённого шаблона, связанного с условием пропуска шифрования. Типовые наборы правил WAF в целом не обнаруживали эксплуатацию этой проблемы до её раскрытия. Установка исправления остаётся обязательной независимо от состояния WAF.

**Влияет ли это на развёртывания cPanel DNSOnly?**
Да, согласно консультации вендора — установки DNSOnly попадают под действие.

**Затрагивает ли это более старые, неподдерживаемые (до 11.40) версии cPanel?**
Нет — согласно публичному анализу, уязвимый путь кода не присутствовал в версиях до ветки 11.40, так как неподдерживаемые устаревшие версии предшествуют соответствующей реализации обработки сессий.

**Существует ли обходной путь, если я не могу установить исправление немедленно?**
Не существует функционального обходного пути, который полностью закрывает уязвимость, кроме установки исправления. Единственной эффективной временной мерой смягчения является блокировка входящего доступа к затронутым портам (2082/2083, 2086/2087, 2095/2096) на сетевом периметре или полная остановка служб `cpsrvd`/`cpdavd`, что также приводит к потере легитимного доступа.

---

## 10. Более широкие уроки для разработки программного обеспечения и безопасности

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

1. **Очищайте данные в точке сохранения, а не на усмотрение вызывающего кода.** Любая мера безопасности, которую можно обойти, просто вызвав другую функцию в той же подсистеме, со временем будет обойдена — будь то атакующим, нашедшим брешь, или будущим инженером, который не знает о её существовании.
2. **Меры безопасности должны закрываться при отсутствии или некорректных входных данных, никогда не открываться.** Если криптографическая операция зависит от материала, предоставленного клиентом, отсутствие этого материала должно прерывать операцию, а не молча пропускать защиту, которую она должна была обеспечить.
3. **Каждое двойное представление одних и тех же данных является потенциальным примитивом для контрабанды.** Везде, где система поддерживает две сериализации одного и того же состояния (сырое vs. кэшированное, в форме кодировки vs. JSON, экранированное vs. неэкранированное) и позже повторно выводит одну из другой, проверяйте этот путь повторного вывода на предмет случаев, когда недоверенные данные могут пересечь границу без фильтрации.
4. **Доверенные флаги должны быть криптографически привязаны к событию, которое они подтверждают, а не просто присутствовать.** Атрибут сессии, означающий «аутентификация уже выполнена», безопасен только в том случае, если атакующий не может независимо установить этот атрибут — с помощью подписи, MAC или эквивалентной привязки к фактическому событию аутентификации, а не через неаутентифицированное хранилище.
5. **Всё, что записывается на диск в результате неаутентифицированного запроса, должно рассматриваться как контролируемое атакующим**, включая данные, которые впоследствии читаются только *другими*, казалось бы, не связанными путями кода. Опасность в этой уязвимости заключалась не в коде, который записывал данные, а в совершенно другом, более позднем пути кода, который повторно интерпретировал их по другим правилам разбора.

---

## 11. Ссылки

- cPanel Security Advisory — *Critical Vulnerability with cPanel & WHM Login Authentication*, 28 апреля 2026 — `docs.cpanel.net/release-notes/release-notes`
- watchTowr Labs — первоначальный анализ первопричины и доказательство концепции, Сина Хейрха, 29 апреля 2026 — `labs.watchtowr.com`
- Rapid7 — Отчёт об emerging threat по CVE-2026-41940 — `rapid7.com`
- Arctic Wolf — Сводка угрозы CVE-2026-41940 — `arcticwolf.com`
- Hadrian — *CVE-2026-41940: A Critical Authentication Bypass in cPanel* — `hadrian.io`
- Picus Security — *CVE-2026-41940 Explained: The cPanel & WHM Authentication Bypass That Hit 1.5M Servers* — `picussecurity.com`
- Запись в каталоге известных эксплуатируемых уязвимостей (KEV) CISA для CVE-2026-41940 — `cisa.gov`
- BleepingComputer, The Hacker News, CyberScoop — современное освещение раскрытия и эксплуатации в дикой природе
- Журнал изменений WP Squared — `docs.wpsquared.com/changelogs`
- Консультация сообщества KnownHost, документирующая предполагаемую эксплуатацию до раскрытия