CVE в cPanel. Разбираем критический баг, угрожающий хостингам

Уяз­вимос­ти CVE-2026-41940 был прис­воен рей­тинг опас­ности 9,8. Хакеру дос­таточ­но най­ти стра­ницу логина в WHM, что­бы зах­ватить сер­вер.

WHM (Web Host Manager) — это панель адми­нис­три­рова­ния сер­вера, которая работа­ет над cPanel и исполь­зует­ся для управле­ния акка­унта­ми cPanel и самим сер­вером. При авто­риза­ции от име­ни root поль­зователь получа­ет рут‑пра­ва и на сер­вере тоже. По фак­ту рут в WHM — это рут на сер­вере.

CVE-2026-41940 сво­дит­ся к двум незави­симым проб­лемам в коде. Пер­вая проб­лема — недос­таточ­ная санити­зация вво­да. Основной демон панель­ки cpsrvd выпол­няет час­тичную очис­тку вво­да в пароле поль­зовате­ля: уда­ляет нулевые сим­волы \0, но игно­риру­ет \r\n. Это пря­мой путь к CRLF-инъ­екции.

CRLF-инъ­екция — уяз­вимость веб‑при­ложе­ний, при которой зло­умыш­ленник внед­ряет сим­волы перево­да стро­ки (\n, 0x0A, LF) и воз­вра­та карет­ки (\r, 0x0D, CR) в HTTP-зап­рос или заголо­вок. Это при­водит к наруше­нию поведе­ния: при­ложе­ние дума­ет, что закон­чилась одна стро­ка и началась дру­гая. В cPanel эта уяз­вимость поз­воля­ет обой­ти авто­риза­цию, манипу­лируя фай­лом сес­сии.

Сес­сии cPanel хра­нят­ся в двух мес­тах:

• /var/cpanel/sessions/raw/ — «сырые» сес­сии в фор­мате key=value, по одной записи в стро­ке;
• /var/cpanel/sessions/cache/ — кеширо­ван­ные сес­сии в фор­мате JSON для быс­трой заг­рузки.

В сыром фор­мате сес­сии раз­делите­лем слу­жит сим­вол новой стро­ки \r\n. В исходни­ках есть фун­кция, которая очи­щает ввод от перено­сов (filter_sessiondata()), но по каким‑то при­чинам раз­работ­чики не при­мени­ли ее к паролю в механиз­ме авто­риза­ции через заголо­вок Authorization: Basic. Зло­умыш­ленник может нап­рямую записы­вать в файл сес­сии любые зна­чения. Нап­ример:

Это файл сес­сии, дос­таточ­ный для обхо­да авто­риза­ции и получе­ния root на сер­вере.

Стро­ка root:x нуж­на для кор­рек­тнос­ти фай­ла: этот логин и пароль никог­да не будут про­верять­ся. Для бай­паса важ­на перемен­ная successful_internal_auth_with_timestamp, которая сооб­щает сис­теме, что аутен­тифика­ция уже прой­дена в прош­лом (нап­ример, через SSO или внут­ренний сер­вис).

Пе­ремен­ная user опре­деля­ет имя поль­зовате­ля. Для обхо­да двух­фактор­ной аутен­тифика­ции нуж­на tfa_verified — перемен­ная, которая ука­зыва­ет WHM, что поль­зователь работа­ет с пра­вами root.

Проб­лема не была бы кри­тичес­кой при пра­виль­ной работе механиз­ма кодиро­вания перед сох­ранени­ем сес­сии. По задум­ке раз­работ­чиков пароль дол­жен хра­нить­ся в таком виде: