Listen to this Post
Introduction
The software supply chain has once again become the battlefield for a highly sophisticated cyberattack, this time targeting one of the most trusted components in modern DevOps environments: GitHub Actions. Security researchers recently uncovered a compromise involving the widely used issues-helper action from the actions-cool organization, exposing a dangerous new method attackers are using to infiltrate continuous integration and continuous deployment pipelines.
Unlike traditional malware campaigns that rely on phishing or vulnerable endpoints, this operation focused directly on developer infrastructure. By hijacking repository tags and redirecting them toward malicious dangling commits, attackers transformed a legitimate automation tool into a covert credential-stealing weapon. The attack demonstrates how deeply modern development environments rely on trust, and how devastating the consequences can become when that trust is abused.
The compromised action was designed to silently harvest sensitive credentials from active GitHub runner environments, scrape secrets directly from memory, and transmit them to attacker-controlled infrastructure. The precision and speed of the operation immediately raised alarms across enterprise security teams and DevSecOps communities worldwide.
Malicious GitHub Action Hijacked Trusted CI/CD Workflows
Security analysts discovered that the attackers manipulated release tags associated with the popular actions-cool/issues-helper GitHub Action. Instead of pointing toward legitimate commits within the repository’s default branch history, the tags were redirected to fraudulent dangling commits crafted specifically for malicious execution.
This tactic proved especially dangerous because many development pipelines automatically trust release tags without validating commit ancestry. As a result, organizations unknowingly executed attacker-controlled code inside highly privileged CI/CD environments.
Once activated inside a GitHub runner, the malicious workflow began a carefully orchestrated credential theft sequence. The payload initially downloaded the bun JavaScript runtime onto the runner infrastructure. Using this runtime, the malicious code launched secondary child processes written in Python, specifically designed to escalate access inside the worker environment.
The malware then targeted the memory space of the main GitHub Runner Worker process. By accessing /proc/Runner.Worker PID/mem, the attackers could scrape decrypted authentication tokens, secrets, API credentials, and environment variables directly from active memory before security controls could isolate or encrypt them.
This represented a significant evolution in CI/CD malware techniques. Instead of merely reading environment variables or exposed configuration files, the attackers actively harvested secrets from live process memory, bypassing many traditional detection mechanisms.
Fake Build Messages Helped Hide the Attack
One of the most deceptive aspects of the campaign involved the visual imitation of legitimate GitHub Action logs. The attackers designed the malicious commits to generate fake build messages that looked nearly identical to the formatting used by the original maintainers.
To developers monitoring workflows, the pipelines appeared normal on the surface. However, timestamp analysis later revealed abnormal automation behavior. Investigators identified fifty-three malicious imposter commits generated within just three minutes, clearly indicating a scripted mass-compromise operation.
The attack infrastructure also established outbound communication channels to an attacker-controlled domain used for exfiltration. Network monitoring tools detected suspicious JavaScript processes initiating unauthorized external connections intended to deliver the stolen credentials outside the CI/CD environment.
Security researchers identified the exfiltration destination as t.m-kosche[.]com, which was rapidly added to enterprise blocklists and threat intelligence feeds after discovery.
Enterprise Security Tools Responded Rapidly
The incident triggered an immediate response from multiple security vendors and DevSecOps platforms. Security tools such as Harden-Runner detected suspicious child process execution patterns associated with the malicious GitHub Actions and flagged the workflows for investigation.
Meanwhile, StepSecurity rapidly updated its compromised action protection policies to include the poisoned repositories. Any workflow attempting to execute the compromised actions would now be automatically canceled before initialization.
This defensive measure proved critical because it stopped the malicious JavaScript runtime from downloading and prevented the Python memory scraping payloads from accessing sensitive runner processes.
Organizations also implemented outbound network filtering to block any traffic attempting to connect with the attacker infrastructure. Even in cases where the malicious action managed to start execution, the stolen credentials could no longer be exfiltrated successfully.
The coordinated response demonstrated how modern DevSecOps ecosystems increasingly depend on automated detection and policy enforcement to combat software supply chain attacks in real time.
Indicators of Compromise
Indicator Type Technical Details
Compromised Action actions-cool/issues-helper
Compromised Action actions-cool/maintain-one-comment
Exfiltration Domain t.m-kosche[.]com
File System Marker /home/runner/.bun/bin/bun
Target Process /proc/Runner.Worker PID/mem
Security researchers advised defenders to only re-fang indicators within controlled threat intelligence environments such as SIEM platforms, sandbox environments, or malware analysis systems.
What Undercode Say:
This attack highlights a dangerous shift in the cybercriminal mindset. Attackers are no longer focusing exclusively on end users or corporate workstations. Instead, they are moving upstream into the software development lifecycle itself, targeting the very infrastructure responsible for building, testing, and deploying modern applications.
GitHub Actions have become deeply integrated into software engineering operations across enterprises, startups, open-source communities, and cloud-native environments. Because these workflows often contain privileged access tokens, deployment credentials, cloud secrets, and package publishing permissions, they represent an extremely valuable target.
The most alarming aspect of this breach is not simply the compromised repository. It is the technique used to manipulate release tags. Many organizations assume that using tagged releases guarantees integrity. In reality, attackers demonstrated that if repository controls are compromised, tags themselves can become attack vectors.
Another important observation is the malware’s use of live memory scraping. Traditional CI/CD attacks usually attempt to steal plaintext secrets from environment variables or configuration files. This campaign bypassed those approaches entirely by reading directly from active process memory. That indicates the attackers possessed strong technical understanding of Linux internals, GitHub runner architecture, and process memory management.
The use of the bun runtime is also notable. Threat actors increasingly adopt modern JavaScript runtimes and lightweight execution frameworks because they blend naturally into developer environments. Security systems historically tuned for Python or Bash abuse may initially overlook newer runtimes operating inside pipelines.
The attack also exposes a larger weakness in supply chain trust models. Many CI/CD pipelines automatically download third-party actions without pinning exact commit hashes. This creates an ecosystem where maintainers, repositories, tags, dependencies, and automation workflows become implicit trust anchors. Once any of those anchors are compromised, attackers gain indirect access to thousands of downstream environments.
Another concerning detail is the speed of the compromise. Fifty-three malicious commits generated in just three minutes strongly suggest automation. This means attackers may already possess frameworks capable of mass hijacking repositories at scale, potentially affecting hundreds of actions simultaneously during future operations.
Organizations should now reconsider how they validate GitHub Actions. Pinning workflows to immutable commit SHAs rather than floating tags is becoming essential. Runtime isolation, ephemeral runners, restricted outbound network policies, and memory protection controls should also become standard practices in mature DevSecOps pipelines.
This incident also demonstrates why behavioral monitoring inside CI/CD systems matters as much as vulnerability scanning. The malware was not exploiting a coding flaw in the runner itself. Instead, it abused legitimate functionality in a malicious sequence. Only runtime behavior analysis exposed the abnormal child process creation and outbound traffic patterns.
From a strategic perspective, software supply chain attacks will likely continue evolving toward stealthier techniques. Attackers increasingly recognize that compromising developers gives them indirect access to production systems, cloud infrastructure, customer environments, and software distribution channels simultaneously.
The cybersecurity industry is entering a phase where build pipelines themselves are becoming high-value operational battlegrounds. Companies that still treat CI/CD environments as “internal trusted systems” are operating under outdated assumptions.
This attack serves as another reminder that trust in software development must now be continuously verified, monitored, and constrained at every stage of execution.
Fact Checker Results
✅ Researchers confirmed malicious tag redirection affecting the actions-cool/issues-helper GitHub Action.
✅ The malware used process memory scraping techniques targeting GitHub Runner Worker processes to extract secrets.
❌ There is currently no public evidence suggesting GitHub’s core infrastructure itself was compromised during the incident.
Prediction
🔮 Supply chain attacks against GitHub Actions and CI/CD ecosystems will increase significantly over the next two years as attackers pursue developer infrastructure instead of traditional endpoints.
🔮 Security vendors will begin introducing mandatory action verification, signed workflow enforcement, and memory-protected runner environments as default enterprise features.
🔮 Organizations relying heavily on third-party GitHub Actions without commit pinning will become primary targets for automated large-scale credential harvesting campaigns.
🕵️📝Let’s dive deep and fact‑check.
References:
Reported By: cyberpress.org
Extra Source Hub (Possible Sources for article):
https://www.stackexchange.com
Wikipedia
OpenAi & Undercode AI
Image Source:
Unsplash
Undercode AI DI v2
Bing
🔐JOIN OUR CYBER WORLD [ CVE News • HackMonitor • UndercodeNews ]
📢 Follow UndercodeNews & Stay Tuned:
𝕏 formerly Twitter 🐦 | @ Threads | 🔗 Linkedin | 🦋BlueSky | 🐘Mastodon
