1. Magento / Adobe Commerce и Mirasvit Cache Warmer В расширении Mirasvit Full Page Cache Warmer для Magento 2 нашли критичную уязвимость с CVSS 9.8. Это расширение “прогревает” кэш страниц интернет-магазина, чтобы сайт работал быстрее. Риск серьезный: уязвимая версия может позволить удаленное выполнение кода без аутентификации. Для e-commerce это почти худший сценарий: за сервером магазина стоят клиенты, заказы, интеграции, платежная логика и иногда доступы во внутреннюю инфраструктуру. Мой вывод: владельцам интернет-магазинов стоит срочно проверить, используется ли Magento / Adobe Commerce и стоит ли Mirasvit Cache Warmer. Если да - обновиться и проверить следы компрометации. Application Firewall может помочь как дополнительный слой, но при RCE в конкретном компоненте главное действие все равно одно: обновление и проверка. WAF не должен быть оправданием для жизни на старой версии. Источник: https://www.securityweek.com/mirasvit-vulnerability-exploited-to-execute-code-on-magento-servers/

2. Cisco Unified CM: SSRF, PoC и потенциальный root Cisco выпустила исправления для уязвимости в Unified Communications Manager. Это платформа, которая управляет корпоративной IP-телефонией: внутренние номера, маршрутизация звонков, телефоны, видеосвязь. Уязвимость связана с SSRF. Это когда атакующий заставляет сервер делать запросы от своего имени во внутренние сервисы, куда снаружи напрямую попасть нельзя. В этой истории цепочка может привести к записи файлов в ОС и потенциальному повышению привилегий до root. Здесь Application Firewall выглядит уже более уместным слоем защиты. Любой веб-интерфейс, который смотрит в интернет, должен фильтроваться. Уязвимости появляются постоянно, а бизнес часто не может быстро обновляться: зависимости, интеграции, кастомные доработки, страх “сломать прод”. Если WAF нет, минимум нужен регулярный внешний анализ веб-приложений: сканер, актуальная база проверок, понятный процесс устранения и контроль закрытия. Просто найти уязвимость недостаточно. Нужен Vulnerability Management. Источник: https://www.securityweek.com/cisco-warns-of-available-poc-for-critical-unified-cm-vulnerability/

3. GitHub token через Jupyter Notebook История с github.dev / VS Code и Jupyter Notebook интересна тем, что она находится на стыке файла, среды разработки, расширений и токенов доступа. Jupyter Notebook - это интерактивная “тетрадь” с кодом, результатами выполнения, графиками и метаданными. GitHub Access Token - это ключ, который позволяет инструментам действовать от имени пользователя в GitHub. Классические средства защиты здесь не всегда сработают напрямую. Песочница может проанализировать файл, но если виртуальная машина не похожа на реальное рабочее место разработчика, она может не увидеть вредоносный сценарий. Просто обращение к GitHub само по себе еще не IOC. Поэтому песочницы надо настраивать под реальные сценарии: какие инструменты есть у разработчика, какие доступы, браузеры, IDE, расширения, как выглядит типовая среда. AppSec-инструменты вроде PT Application Inspector тоже полезны: SAST/SCA/DAST/IAST помогают анализировать код, зависимости и приложение. Но они не являются гарантированной защитой от атаки через IDE, notebook и украденный токен. Нужны еще политики GitHub, контроль расширений, минимальные права токенов и аудит действий. Источник: https://www.securityweek.com/vs-code-vulnerability-allows-one-click-github-token-theft/

Общий вывод ИБ здесь не про “купить одну коробку”. WAF не отменяет патчи. Сканер без процесса закрытия - просто отчет. Песочница полезна, если похожа на реальную среду. AppSec-инструменты нужны, но не заменяют контроль доступов.