RCE-уязвимость в Squid затрагивает (https://www.securitylab.ru/news/562058.php) один из базовых элементов интернет-инфраструктуры — HTTP-прокси, на котором держатся корпоративные сети, CDN и операторские шлюзы. Проблема кроется в переполнении буфера при обработке URN-запросов, что открывает путь к удалённому исполнению кода без аутентификации. Под ударом миллионы систем, где Squid служит звеном между клиентом и веб-сервером.
Уязвимость охватывает почти все активно используемые версии, включая серии 4.x, 5.x и 6.x до выхода 6.4. Техническая особенность в том, что атака инициируется через малосложное сетевое соединение, а в процессе эксплуатации возможна утечка до 4 КБ оперативной памяти прокси, где могут находиться токены, ключи и другие чувствительные данные. Для атакующего это — возможность совместить удалённое выполнение кода с кражей критической информации в одном сценарии.
Инцидент демонстрирует, что даже зрелые проекты с многолетней историей могут содержать уязвимости, критичные для всей экосистемы. Обновление до 6.4 или блокировка URN-запросов — минимальные меры, но стратегически важнее выстраивать постоянный процесс аудита сетевых компонентов, которые традиционно считались стабильными.
Уязвимость охватывает почти все активно используемые версии, включая серии 4.x, 5.x и 6.x до выхода 6.4. Техническая особенность в том, что атака инициируется через малосложное сетевое соединение, а в процессе эксплуатации возможна утечка до 4 КБ оперативной памяти прокси, где могут находиться токены, ключи и другие чувствительные данные. Для атакующего это — возможность совместить удалённое выполнение кода с кражей критической информации в одном сценарии. Инцидент демонстрирует, что даже зрелые проекты с многолетней историей могут содержать уязвимости, критичные для всей экосистемы. Обновление до 6.4 или блокировка URN-запросов — минимальные меры, но стратегически важнее выстраивать постоянный процесс аудита сетевых компонентов, которые традиционно считались стабильными.