18-годишна RCE в nginx (CVE-2026-42945)

На 13 май беше поправена уязвимост в популярния уеб сървър nginx, който е често използван в системи с голяма натовареност: CVE-2026-42945, която потенциално може да доведе до RCE. Уязвимостта се появи преди 18 години (2008 година) в версия 0.6.27.

За да се експлоатира, в конфигурацията на сървъра трябва да се определи определена комбинация от директиви, не непременно у всички, но на места присъстващи, например:
rewrite ^(.*) /new?c=1;
set $myvar $1;
return 200 $myvar;

Съществени детайли:

  • първо идва директивата rewrite, където (първият аргумент) регулярното изражение с иззет параметър (нещо в кръгли скоби) се заменя с (втория аргумент) път, съдържащ знак за въпрос;
  • директивата set (вместо нея също подхожда втория rewrite или if), която използва иззетия параметър от оригиналния перезаписан път (в случая това е $1).

Уязвимостта действа така:

  • първата директива rewrite, натъквайки се на знака за въпрос, установява вътрешния флаг is_args, означаващ „в момента събираме get-параметрите за замененото url, трябва всичко да се екранира“, а (в това е същността на бага) забравя да нулира този флаг в края на работата си;
  • последващата директива set, при формирование на стойността за $myvar, погрешно прилага установения преди is_args и записва в my_var екранираната стойност на иззетия параметър $1; проблемът е, че буферът за $myvar се заделя предварително, още преди да бъдат извършени подстановките, и неговата дължина се изчислява с is_args=0, т.е. екранираната стойност се оказва по-дълга от определения буфер, поради което записа става извън рамките на определените буфери в други структури от данни на сървъра. За да се случи това, е достатъчно да се изпрати заявка с символи, подлежащи на екраниране, например знаци „плюс“, на мястото на изземване на параметъра на регулярното изражение.

Ако на хоста няма ALSR, то тази уязвимост може да бъде експлоатирана за дистанционно изпълнение на код с правата на работния процес на nginx, има PoC (там не е чист експлойт, демонстрация в пясъчната кутия).

Уязвимостта е поправена в стабилната версия nginx 1.30.1, и в новата разработка 1.31.0. линк към комита.

Забележително е, че преди 14 години (2012 година) подобна грешка вече беше поправяна на друго място в близост.

——-

На сайта F5 има препоръка за временно неутрализиране на уязвимостта в случай на невъзможност за бързо актуализиране на версията на nginx — трябва да се заменят неименуваните параметри с именувани, и в такъв случай, по техните думи, уязвимостта няма да се прояви. Пример оттам:
беше: rewrite ^/users/([0-9]+)/profile/(.*)$ /profile.php?id=$1&tab=$2 last;
стана: rewrite ^/users/(?[0-9]+)/profile/(?

.*)$ /profile.php?id=$user_id&tab=$section last;

Информацията за уязвимостта беше предоставена от Zhenpeng (Leo) Lin от DepthFirst. Освен това той съобщи за следните проблеми, които също са поправени:

  • CVE-2026-40701 (комит) use-after-free при използване на ssl_verify_client+ssl_ocsp (изглежда без RCE)
  • CVE-2026-42934 (комит) четене извън буфера в utf-8 парсера при специфични обстоятелства, може да доведе до малка изтичане на данни или срив на работния процес
  • CVE-2026-42946 (комит) прекомерно заделяне на памет и четене извън буфера при използване на модули scgi/uwsgi, проблемът проявява при наличие на злонамерен бекенд (upstream) чрез посочените протоколи, или при MITM на комуникацията с бекенда, може да доведе до четене на паметта на nginx или срив на работния процес

Източник: linux.org.ru

Купете надежден хостинг за сайтове със защита от DDoS, VPS и VDS сървъри 🔥 Купете надежден хостинг за сайтове със защита от DDoS, VPS и VDS сървъри | ProHoster