Останні події у сфері кібербезпеки знову демонструють знайому тенденцію: навіть зрілі організації системно ігнорують базові рекомендації, а проміжок між публічним розкриттям уразливості та її масовою експлуатацією скорочується до лічених днів. На цьому тлі особливо виділяється масштабна атака на ланцюг постачання через Trivy та серія нових критичних CVE у популярному ПЗ.
Компрометація Trivy: удар по ланцюгу постачання та CI/CD-процесам
Trivy від Aqua Security — один із найпоширеніших open source-сканерів уразливостей: десятки тисяч зірок на GitHub і сотні мільйонів завантажень образів з Docker Hub роблять його де-факто стандартом для DevSecOps. Та сама популярність перетворила інструмент на привабливу ціль для атак на ланцюг постачання.
Зловмисникам вдалося скомпрометувати офіційні релізи Trivy та пов’язані GitHub Actions, які інтегровані у тисячі CI/CD-пайплайнів. У легітимні артефакти було вбудовано шкідливий код, орієнтований на крадіжку облікових даних і секретів, що використовуються на етапах збірки, тестування й розгортання.
Ключовий наслідок — численні організації не виконали своєчасну ротацію скомпрометованих секретів. Повторне використання одних і тих самих токенів і ключів у різних проектах призвело до каскадних компрометацій, зараження пов’язаних репозиторіїв і інфраструктур. За наявною інформацією, це сприяло поширенню саморазмножувального шкідливого ПЗ CanisterWorm, спеціально спроєктованого для подальших атак на ланцюг постачання.
GitHub Actions, DevOps та новий рівень ризику для розробників
Інцидент із Trivy логічно вписується в стійкий тренд атак на інструменти розробників, GitHub Actions та інші платформи автоматизації. CI/CD-системи давно стали критичною частиною ланцюга постачання ПЗ: їхній компроміс відкриває шлях до вихідного коду, секретів інфраструктури та механізмів доставки оновлень кінцевим користувачам.
Платформи вже реагують. Зокрема, GitHub змінив дефолтну логіку workflow типу pull_request_target, щоб ускладнити низку векторів атак. Однак цей кейс показує: платформених змін недостатньо, якщо організації не будують , не обмежують привілеї токенів та не впроваджують обов’язкову ротацію секретів.
Критичні уразливості тижня: CVE, які не можна ігнорувати
Публічні реєстри уразливостей щотижня поповнюються новими записами, а вікно між їх розкриттям і реальною експлуатацією постійно скорочується. Наразі особливої уваги потребує низка критичних CVE, які вже активно аналізуються дослідниками та, ймовірно, привертають увагу зловмисників.
До переліку входять, зокрема: CVE-2026-21992 (Oracle), CVE-2026-33017 (Langflow), CVE-2026-32746 (GNU InetUtils telnetd), CVE-2026-32297 і CVE-2026-32298 (Angeet ES3 KVM), CVE-2026-3888 (Ubuntu), CVE-2026-20643 (Apple WebKit), CVE-2026-4276 (LibreChat RAG API), CVE-2026-24291 (RegPwn, Microsoft Windows), CVE-2026-21643 (Fortinet FortiClient), CVE-2026-3864 (Kubernetes), CVE-2026-32635 (Angular), CVE-2026-25769 (Wazuh), CVE-2026-3564 (ConnectWise ScreenConnect), CVE-2026-22557 та CVE-2026-22558 (Ubiquiti), CVE-2025-14986 (Temporal), CVE-2026-31381 і CVE-2026-31382 (Gainsight Assist), CVE-2026-26189 (Trivy), а також CVE-2026-4439, CVE-2026-4440, CVE-2026-4441 (Google Chrome), CVE-2026-33001, CVE-2026-33002 (Jenkins), CVE-2026-21570 (Atlassian Bamboo Data Center) і CVE-2026-21884 (Atlassian Crowd Data Center).
Організаціям варто як мінімум проінвентаризувати наявність цих продуктів в інфраструктурі, призначити відповідальних за оновлення та максимально швидко встановити патчі для систем, що виходять в інтернет або задіяні в ланцюгу постачання: CI/CD, системи керування доступом, браузери, засоби віддаленого адміністрування.
Старі слабкі місця, нові техніки: IoT, хмари та мобільні пристрої
На тлі гучних атак на ланцюг постачання зловмисники не полишають «класичні» вектори: незахищені IoT-пристрої, відкриті сховища даних, помилки конфігурації хмарних сервісів і слабко захищені мобільні пристрої співробітників. Сучасні шкідливі програми стають більш «терплячими»: розраховані на тривалу приховану присутність та поступове розширення контролю над інфраструктурою.
Окремо варто відзначити тихі, довгострокові операції за підтримки держав і таргетовані атаки через неправильно налаштовані сервіси або поспіхом встановлені оновлення. У більшості випадків масштаб збитків визначається не унікальністю експлойта, а розривом між виявленням проблеми та її фактичним усуненням.
Правові рамки та безпечне використання інструментів безпеки
Інструменти для сканування уразливостей, аналізу інфраструктури та моделювання атак переважно доступні публічно та мають подвійне призначення. Їхнє використання допустиме лише в рамках закону, у тестових або ізольованих середовищах і після ретельного аудиту коду. Запуск подібних утиліт у бойовій інфраструктурі без перевірки суттєво підвищує ризик додаткової компрометації.
Головний висновок: проблема рідко полягає в окремій уразливості. Небезпечні саме «розриви» — між виявленням атаки й її детектуванням, між випуском патча та його встановленням, між усвідомленням ризику та реальними діями. Щоб звузити ці проміжки, вже зараз доцільно оновити мобільні пристрої, переглянути всі компоненти, пов’язані з CI/CD та GitHub Actions, виконати негайну ротацію секретів при найменшій підозрі на витік і ніколи не зберігати критичні дані — такі як seed-фрази криптогаманців — у звичайних нотатках чи незахищених хмарних сервісах. Чим раніше ці базові заходи стануть частиною культури безпеки, тим менша ймовірність побачити назву власної організації в наступній гучній кіберновині.
