OpenAI розкрила деталі інциденту, у ході якого скомпрометований npm‑пакет Axios опинився в одному з GitHub Actions‑воркфлоу, що використовувався для підпису десктопних застосунків для macOS. За заявою компанії, дані користувачів та внутрішні системи не були зламані, однак сертифікат підпису розглядається як потенційно скомпрометований і підлягає відкликанню та ротації.
Як Axios став точкою входу в ланцюг постачання OpenAI
Наприкінці березня фахівці Google Threat Intelligence Group пов’язали компрометацію популярного HTTP‑клієнта Axios із північнокорейським угрупованням UNC1069. Зловмисники отримали доступ до облікового запису мейнтейнера npm і опублікували дві шкідливі версії пакета: 1.14.1 та 0.30.4.
У ці релізи було непомітно додано фальшиву залежність plain-crypto-js, яка розгортала кросплатформений бекдор WAVESHAPER.V2. Шкідливий код був здатен працювати в середовищах Windows, macOS і Linux, що робить інцидент класичним прикладом атаки на ланцюг постачання ПЗ (software supply chain attack) — коли компрометується не готовий продукт, а довірені бібліотеки та інструменти розробки.
OpenAI підтвердила, що 31 березня один із GitHub Actions‑воркфлоу завантажив та виконав Axios версії 1.14.1 під час процесу підпису macOS‑додатків. Цей pipeline мав доступ до сертифіката підпису та матеріалів нотаризації, що використовуються для ChatGPT Desktop, Codex, Codex CLI та Atlas.
Внутрішній аналіз OpenAI показав, що ймовірність ексфільтрації приватного ключа сертифіката оцінюється як низька. На це вплинула послідовність кроків у job, час ін’єкції сертифіката та інші технічні обмеження. Водночас компанія дотримується принципу «готовність до найгіршого сценарію» і вважає сертифікат таким, що міг бути скомпрометований.
Відкликання сертифіката OpenAI для macOS: що зміниться для користувачів
У відповідь OpenAI розпочинає відкликання та ротацію сертифіката підпису macOS‑додатків. Це означає, що старі версії клієнтів компанії втратять підтримку й можливість отримувати оновлення, а з 8 травня 2026 року система безпеки macOS за замовчуванням блокуватиме їх при завантаженні та запуску.
Разом з Apple компанія забезпечує, щоб програмне забезпечення, підписане старим сертифікатом, більше не могло отримати нову notarization. Протягом приблизно 30‑денного перехідного періоду користувачам рекомендується оновити застосунки до версій, підписаних новим сертифікатом, аби уникнути перебоїв у роботі.
Ключовий ризик у разі компрометації сертифіката полягає в тому, що атакаючі могли б підписувати шкідливий код так, ніби це легітимне ПЗ OpenAI. Хоча видачу нових нотаризацій зі старим сертифікатом заблоковано, завжди залишається людський фактор: користувач може свідомо проігнорувати попередження macOS і запустити файл вручну.
Більша кампанія: Trivy, TeamPCP, CanisterWorm і CVE‑2026‑33634
Історія з Axios — лише частина ширшої supply chain кампанії проти open source‑екосистеми. Паралельною мішенню став популярний сканер вразливостей Trivy від Aqua Security, на який спрямовувала зусилля кібергрупа TeamPCP (UNC6780).
Компрометація ланцюга постачання Trivy дозволила зловмисникам викрасти облікові дані SANDCLOCK, після чого вони використали ці секрети для атаки на низку npm‑пакетів і розгортання саморозповсюджуваного черв’я CanisterWorm. Надалі ті самі вкрадені облікові дані застосовувалися для ін’єкції шкідливого коду в GitHub Actions‑воркфлоу компанії Checkmarx та публікації модифікованих версій пакетів LiteLLM і Telnyx у Python Package Index (PyPI).
Розвиток технік атаки та наслідки для екосистеми
За даними Trend Micro, TTP зловмисників швидко еволюціонують: від примітивних Base64‑рядків у CI/CD‑пайплайнах до стеганографії у WAV‑файлах та одночасного ураження Linux і Windows із підвищеною стійкістю на Windows‑хостах. На Windows шкідлива версія Telnyx SDK запускала «msbuild.exe», який витягував із PNG‑зображення завантажувач DonutLoader, а потім — повноцінний троян і beacon, пов’язаний із C2‑фреймворком AdaptixC2.
Кампанія отримала ідентифікатор CVE‑2026‑33634 і була внесена до каталогу Known Exploited Vulnerabilities агентства CISA. Федеральним структурам США приписано запровадити заходи захисту до 9 квітня 2026 року, що підкреслює критичність інциденту.
Аналіз GitGuardian показує масштаби витоків: шкідливий GitHub Actions‑воркфлоу trivy-action був виконаний щонайменше в 474 публічних репозиторіях, а близько 1750 Python‑пакетів автоматично підтягували заражені залежності. За оцінкою Google, у результаті атак на Axios та Trivy в обігу можуть залишатися «сотні тисяч викрадених секретів», які створюють базу для подальших supply chain атак, компрометації SaaS‑сервісів, шантажу та крадіжки криптоактивів.
Чому атакують інструменти безпеки та як посилити ланцюг постачання ПЗ
Фокус атак на інструментах із підвищеними привілеями — сканерах вразливостей, CI/CD‑середовищах, інфраструктурі ШІ — не випадковий. Представники правоохоронних органів, зокрема кіберпідрозділів ФБР, наголошують: компрометація засобів безпеки дає нападнику прямий доступ до найчутливіших середовищ, оскільки цим інструментам за замовчуванням довіряють і надають широкі повноваження.
Практика останніх інцидентів підтверджує тезу, яку формулюють провідні CISO: у сучасному DevOps‑середовищі довіра має бути не припущенням, а результатом перевірки. На практиці це означає перехід на верифіковані базові образи контейнерів замість випадкових community‑збірок, використання зафіксованих версій (pinned versions) замість тегів latest, впровадження мінімально необхідних та короткоживучих секретів замість постійних токенів і застосування ізольованих CI‑ранерів замість загальнодоступних середовищ.
Атаки на Axios, Trivy та пов’язані екосистеми демонструють, що основною точкою ризику стає автоматизація: GitHub Actions, CI/CD‑пайплайни, менеджери залежностей, сканери коду. Організаціям варто оперативно провести інвентаризацію свого ланцюга постачання ПЗ, впровадити безперервне сканування секретів, посилити контроль над open source‑залежностями, моніторити аномальну активність у pipeline та регулярно оцінювати вплив відомих кампаній на кшталт CVE‑2026‑33634.
За оцінками Mandiant (Google), кількість атак на ланцюг постачання вже «виходить за всі рамки», тож захисним командам доцільно виділяти окремі проєкти на аналіз наслідків, ремедіацію та розвиток DevSecOps‑процесів. Чим раніше буде побудований прозорий, контрольований контур — від вихідного коду до продакшна, — тим менша ймовірність, що наступна хвиля supply chain атак застане компанію зненацька. Саме зараз доречно переглянути політики безпеки, оновити інструменти моніторингу та навчити команди розробки працювати за принципом «довіряй, але перевіряй» на кожному етапі життєвого циклу ПЗ.
