Експерти по киберсигурност от Searchlight Cyber обединиха във верига няколко дребни слабости във функционалността за обработка на изображения на Cloudflare. Тази верига им позволи да изпълнят JavaScript код в сайт, конфигуриран изрично да го блокира.

Кевин Жерво (Kevin Gervot) и Адам Кус (Adam Kues) публикуваха своето изследване на 28 октомври 2026 г. в материал със заглавие „Cache Me If You Can“. Те демонстрираха работеща уязвимост за междусайтово скриптиране (XSS) през крайния адрес /cdn-cgi/image/ на cloudflare.com. Публикацията не посочва CVE идентификатор или статус на корекция за сигурност, поради което потребителите следва да направят справка с Cloudflare.

XSS уязвимости в Cloudflare

Cloudflare обслужва 24,3% от всички уебсайтове. Когато даден сайт се включи към мрежата на Cloudflare, компанията добавя управляван път /cdn-cgi/ към собствения домейн на този сайт. Там се намират функции като проверки за ботове, Web Analytics, Access и Image Transformations.

Тъй като тези страници се зареждат от собствения домейн на клиента, грешка в тях се изпълнява с нивото на доверие на самия сайт. Други изследователи вече бяха открили начини за заобикаляне на Content Security Policy (CSP) в този път. CSP представлява набор от правила на браузъра, ограничаващи скриптовете, които страницата има право да изпълнява.

Cloudflare почиства SVG изображенията посредством svg-hush — инструмент, написан на Rust и базиран на библиотеката xml-rs. Инструментът проверява файла и след това го презаписва. Изследователите установиха, че xml-rs екранира стандартните стойности на атрибутите, но записва стойностите на пространствата от имена (настройката xmlns) в необработен вид.

Атакуващ може да скрие кавичка в тази стойност и да излезе от нейния контекст. Тъй като филтърът вече е одобрил файла на този етап, тагът script преминава успешно. Cloudflare предоставя тези изображения със строга политика default-src 'none', която блокира скриптове. Въпреки това крайният адрес препредава заглавните части Cache-Control от изходното изображение.

HTTP правилата позволяват формат като no-cache='Content-Security-Policy', който указва на кеша да премахне посочения хедър. Само Chromium спазва това правило и приема всяко име на хедър. При първоначалното зареждане CSP остава активна. След като Chromium запише страницата в кеша, политиката изчезва.

Познат CTF похват след това принуждава Chromium да презареди запазеното копие. Атакуващият отваря страницата в нов прозорец, пренасочва този прозорец към друг сайт и извиква history.back().

Връзката към първоначалния прозорец (opener) не позволява страницата да попадне в back/forward кеша (bfcache), поради което Chromium използва своя дисков кеш и скриптът се изпълнява. Свързано кеш-базирано заобикаляне на CSP, отразено по-рано от Cyber Security News, разчиташе на същото пренасочване към дисковия кеш.

Функцията Image Transformations извлича изображения единствено от разрешени източници. Настройката по подразбиране е „This zone only“. Модулът за извличане обаче следва пренасочвания, без да проверява крайния адрес. Поради това всяко отворено пренасочване (open redirect) в разрешен сайт позволява на нападателя да зареди изображение от произволно място.

Екипът се е стремил към метод, който не изисква отворено пренасочване. Те установиха, че след като Cloudflare Access бъде активиран за което и да е име на хост в дадена зона, адресът /cdn-cgi/access/logout започва да функционира за всяко име на хост в тази зона. Неговият параметър returnTo приема произволен поддомейн на cloudflare.com.

Пренасочване в изследователски хост на Cloudflare след това изпраща модула за извличане директно към файла на атакуващия. Това завършва веригата дори при зони със строги ограничения на източника. След това екипът тества кеш похвата и на други платформи. В Netlify Image CDN те го използват за премахване както на CSP, така и на хедъра Content-Type. Chromium впоследствие определя типа на файла според съдържанието му и третира SVG изображение, започващо с doctype, като HTML документ.

Инструкция за обработка (processing instruction) скрива скрипта от инструмента за почистване SVGO, който проверява само стандартните елементи. Изследователите отбелязват, че хостваният код на Netlify не е публичен, поради което не са могли да потвърдят дали съвпада с версията с отворен код. Amazon S3 и Google Cloud Storage също позволяват подписани връзки, които пренаписват заглавните части на отговора. Такива връзки могат да задават response-content-type и response-cache-control.

Това е от съществено значение за хранилища (buckets) зад персонализирани домейни или прокси сървъри, които препредават заявките с параметри (query strings). Идеята надгражда предишни изследвания за пренаписване на Content-Type и функционалностите за пренаписване в S3 GetObject.

Основният извод е, че доверие не бива да се гласува единствено на тялото на файла. Заглавните части, препредавани от услуга за изображения или слой за съхранение, стават пряка част от вашата сигурност. Екипите следва да избягват препращането на заглавни части Cache-Control и X-* от ненадеждни източници.

Препоръчва се също задаване на X-Content-Type-Options: nosniff и детайлен преглед на източниците, от които инструментите за изображения имат право да изтеглят съдържание. Отстраняването на отворени пренасочвания също помага. Досегашният опит показва, че дори надеждните филтри могат да се провалят, както се вижда при изследванията за заобикаляне на WAF при инжектиран код за XSS. Многослойната защита остава ключов фактор.