Две действия от actions-cool за GitHub Actions бяха деактивирани за втори път, след като хранилищата станаха достъпни миналата седмица, месеци след като бяха компрометирани по време на кампанията Mini Shai-Hulud през май 2026 г.

Засегнатите GitHub Actions са изброени по-долу -

  • actions-cool/issues-helper
  • actions-cool/maintain-one-comment

Посещението на което и да е от хранилищата сега показва съобщението: „Достъпът до това хранилище е деактивиран от екипа на GitHub поради нарушение на Общите условия на GitHub. Ако сте собственик на хранилището, можете да се свържете с поддръжката на GitHub за повече информация.“

„На 16 септември 2026 г. и двете хранилища станаха отново достъпни“, каза изследователят от Socket Карло Занки. „Техните етикети на версии (release tags) не бяха почистени предварително. Те все още сочат към зловредното съдържание, въведено на 18 май, така че всеки работен процес (workflow), който реферира някое от действията чрез етикет за версия, възобнови изтеглянето и изпълнението на зловредния код при следващото си стартиране.“

Двата работни процеса на GitHub Actions бяха първоначално компрометирани на 18 май 2026 г., за да изпълняват зловреден код, който събира чувствителни идентификационни данни от CI/CD конвейерите, които ги стартират, и извлича данните към сървър, контролиран от атакуващия.

Впоследствие активността беше свързана с клъстера на активност Mini Shai-Hulud, позовавайки се на съвпадения в домейна за извличане на данни ("t.m-kosche[.]com"), използван в работните процеси на GitHub Actions, и npm пакетите от екосистемата @antv.

„Това сочи към същия клъстер на активност Mini Shai-Hulud, а не към отделен инцидент, свързан само с npm“, каза тогава пред The Hacker News Филип Буркхард, ръководител на анализа на заплахите в Socket.

Хранилищата бяха активирани отново на 16 септември 2026 г. в даден момент между 11:09 ч. и 18:16 ч. GMT+2. В момента не е известно защо се е случило това.

Но последното развитие показва друг проблем: зловредният код остана в засегнатите кодови бази и никога не беше почистен, а всичко необходимо за активиране на заплахата беше хранилищата отново да станат достъпни за изтегляне.

Като се има предвид, че все още има няколко работни процеса, които използват двете GitHub Actions, излагането на риск би могло да доведе до сериозни рискове за сигурността на веригата за доставки на софтуер, без да е необходимо авторите на заплахата да използват нов експлойт или да изграждат нова инфраструктура.

„И двете действия автоматизират поддръжката на проблеми (issues) и коментари, като например затваряне на неактивни проблеми, проверка на новоотворени или поддържане на актуален единичен коментар от бот“, казаха от Socket.

„Работните процеси, които ги извикват, обикновено се изпълняват по дневен график или всеки път, когато някой отвори проблем или заявка за изтегляне (pull request). На практика повечето засегнати хранилища вероятно са изпълнили зловредния код в рамките на един ден след повторното активиране, без да са необходими допълнителни действия от страна на атакуващия.“

Проблемът не засяга работни процеси, които фиксират някое от действията към пълния commit SHA на версия отпреди 18 май 2026 г. На разработчиците се препоръчва да предприемат следните стъпки -

  • Намерете всяка референция към засегнатите действия и третирайте "actions-cool/issues-helper@v2.2.1" като засегната.
  • Премахнете действията и ги фиксирайте към известен като чист SHA, който е отпреди 18 май 2026 г.
  • Завъртете (променете) всички изложени на риск тайни/пароли (secrets).
  • Прегледайте историята на изпълнение на работните процеси и проверете за нови успешни стартирания след продължителен период на грешки от тип „Set up job“.
  • Одитирайте историята на хранилището за неочаквани промени (commits) след 16 септември 2026 г.

„Повечето инциденти във веригата за доставки включват нещо ново: новопубликувана зловредна версия, наскоро отвлечен акаунт или новоинжектиран работен процес“, каза Занки. „Този инцидент не беше такъв. Не беше публикуван нов код и не бяха променяни конфигурации.“

„Този инцидент показва,телно че променлив етикет (mutable tag) може да бъде компрометиран, овладян и след това повторно активиран без никаква промяна във вашия собствен файл на работния процес. Фиксирането чрез SHA премахва тази зависимост от състоянието на външното хранилище.“