Search This Blog

Powered by Blogger.

Blog Archive

Labels

Footer About

Footer About

Labels

Showing posts with label supply chain. Show all posts

GhostAction Returns: 772 GitHub Repos Hit as Supply Chain Campaign Picks Back Up

 



A GitHub Actions credential-theft campaign that researchers first flagged a year ago has returned with a fresh wave of attacks, hitting 772 public repositories between August 31 and September 30, 2026, and going after more than 2,500 developer secrets in the process.

The campaign, named GhostAction, was first reported in September 2025 after attackers compromised 817 public repositories across 327 GitHub user accounts and walked off with at least 3,325 secrets. It relied on injecting a malicious GitHub Actions workflow into victim repositories using what appeared to be stolen developer credentials. The 2026 wave uses the exact same method.

The attack injects a workflow file named `github_actions_security.yml` with the commit message "Add Github Actions Security workflow." Instead of dumping an entire environment, the attacker hardcodes into the workflow the specific secret names it already found referenced in the target's legitimate workflows, then sends those values in a single HTTP POST request to an attacker-controlled server.

The only meaningful change from 2025 is the exfiltration destination. This wave routes stolen data over plain HTTP to a bare IP address, `193.32.204.199`, replacing the named domains used previously. On September 7, a second variant appeared across seven repositories under the filename `security-check.yml`, posting secrets to a dedicated API endpoint on the same server with a unique identifier per injection. The tracking mechanism suggests the attacker now runs a backend that logs exactly which repository each stolen secret came from.


Three Bursts, 2,577 Targets

The injections rolled out in clusters. On August 31, 143 repositories were hit. Between September 2 and 5, roughly 400 more were targeted, with a single-day peak of 294 on September 5. On September 15, another 103 repositories were injected, with smaller activity continuing through the rest of the month.

Across all 772 repositories, the workflows targeted 2,577 secrets. SSH private keys and deployment server credentials were the most sought-after, appearing in 446 cases. Azure credentials followed at 218, with one organization alone exposing an Azure personal access token and an SSH key across 92 repositories. Container registry credentials for DockerHub and GHCR appeared 142 times; database credentials, 112; AWS access keys, 106; FTP credentials, 92; Google Cloud and Firebase credentials, 80; and GitHub tokens, 66. The list also included API keys for Telegram bots, Slack, Discord, npm, PyPI, and various AI providers.

GitHub's own approval mechanisms blunted much of the damage. Of 3,669 workflow runs tracked across 605 repositories, only 499 actually ran. A total of 336 completed successfully, exfiltrating 26 secrets from 13 repositories. Only 124 of the 772 affected repositories, roughly 16 percent, showed evidence of cleanup by October 5.


A Campaign That Never Stopped

Calling this a revival would be misleading. In 92 of the 2026 cases, the attacker did not add a new workflow at all. It modified one already sitting in the repository from an earlier injection, with the commit message "Update Github Actions Security workflow." Those updates simply pointed existing files at the new exfiltration IP, with the replaced endpoints including the original 2025 domains and a previously undocumented address, `170.39.218.2`.

The full timeline runs from September 2025 through the present: roughly 900 repositories in the initial wave, quieter activity across late 2025 and early 2026 under two different endpoints, then the August and September 2026 surge of 772.


A Cryptominer Hidden in DevOpsGPT

The new wave also produced an unexpected finding. A day and a half before the first August 31 injections, a commit labeled "fix(subtask): update the OpenAI version" was pushed to `kuafuai/DevOpsGPT`, an open-source project with roughly 6,000 stars. The commit embedded an XMRig 6.21.0 Monero miner into the project's Docker image, disguised as a routine worker process and set to run on a 45-second restart loop. The mining configuration was XOR-encrypted with the key `devops2024`, and the wallet pointed to `pool.supportxmr.com`.

The same compromised account was then used on September 15 to push the GhostAction workflow to four DevOpsGPT repositories. Whether the miner and the credential-theft campaign share the same operators remains unclear. The miner commit used a forged author email never seen on that account before, was crafted specifically for that project, and left no trace in any other repository, while GhostAction's payloads are generic and hit hundreds of repos within hours.


One Compromised Account, Multiple Attackers

Cross-referencing GhostAction victims against other malicious GitHub activity turned up 13 victim repositories that had also been exploited for cryptomining by at least four separate campaigns with distinct wallets, pools, and infrastructure. In some cases the miners arrived before the GhostAction workflow; in others they followed months later.

The most likely explanation is that the credentials GhostAction used were not exclusive to its operators. Stolen developer tokens circulate through infostealer logs and credential markets, where multiple actors can buy and reuse the same access independently.

That creates a specific gap in the standard remediation advice. Rotating the secrets stolen through the malicious workflow is necessary, but it is not enough. The underlying GitHub credential that allowed the injection in the first place also needs to be found and revoked, or whoever holds that token next will use it.

The campaign continued into October. On October 8, a new burst hit 346 repositories in two automated sweeps lasting only minutes. Two compromised maintainer accounts pushed the workflow to every repository they could write to, including kitao/pyxel, a Python retro game engine with over 18,400 stars, and uber/athenadriver. The exfiltration endpoint remained `193.32.204.199`. Unlike most of the September wave, which was blocked pending approval, these runs executed and exfiltration was confirmed. This variant also goes further than its predecessor: rather than targeting only named GitHub Actions secrets, it combs the full git commit history for cloud credentials, including AWS keys, GitHub and GitLab tokens, and API keys for services like OpenAI and Anthropic.


A Go Worm Stole MemTensor's CI Tokens and Shipped Backdoored Packages to npm and PyPI

 



On September 23, 2026, an attacker spent roughly five hours poisoning two packages belonging to MemTensor, the company behind the MemOS operating system for AI memory. By the time a researcher flagged the issue on GitHub at 4:17 AM UTC, malicious versions were already sitting at the top of the npm and PyPI registries, ready to install for any developer who ran a plain `npm install` or `pip install MemoryOS` that morning.

The packages hit were `@memtensor/memos-cloud-openclaw-plugin` on npm and `MemoryOS` on PyPI. Security firm SafeDep, which flagged the incident through its threat intelligence monitoring, found that three npm versions, `0.1.21`, `0.1.23`, and `0.1.25`, and one PyPI version, `2.0.34`, all contained the same Go binary: a credential-harvesting implant the attacker internally called `sckit`, built under the module path `supplychain.local/campaign`.


How the Attacker Got Inside the Pipeline

The attacker did not need a zero-day. Instead, they exploited a well-understood weakness in how GitHub Actions jobs share environment state.

The OpenClaw plugin publishes to npm through a GitHub Actions release workflow that reads its publish token from a repository secret. The attacker, operating through a GitHub account called `Memtensor-AI`, pushed a short-lived branch named `sc/release-0.1.21-20260922-cloud`, made a three-line change to a validation script that runs earlier in the same job, then deleted the branch. They repeated this process five times between 00:48 and 02:03 UTC.

The change was precise: it wrote a `BASH_ENV` entry into `$GITHUB_ENV`, which is GitHub's mechanism for passing environment variables between steps. Because Bash reads the file named in `BASH_ENV` before running any non-interactive script, this let the attacker's shell script execute silently before the real publish step. That script called `collectStageZero()` from within the package itself, passed the `NPM_TOKEN` to the `sckit` binary, then deleted itself and exited with a failure code. The publish step failed visibly, so nothing appeared on npm from that run. The token was already gone.

The PyPI compromise used the same `BASH_ENV` trick but through a different entry point. The attacker pushed an unsigned commit to the MemOS repository that replaced the standard build backend in `pyproject.toml` with a custom wrapper called `sckit_poetry_build`. On import, that wrapper injected its own bridge script into the CI environment. The bridge ran only inside the PyPI upload action's container, captured `INPUT_PASSWORD` (the PyPI token), sent it to a server at `10729e014d0e.skyleen[.]fr`, and then exited cleanly. Two hours later, a follow-up commit removed the capture code, and the next tag push uploaded the fully malicious wheel to PyPI using MemTensor's own legitimate credentials.


What the Package Does After Install

The implant activates at runtime, not at install time, so `--ignore-scripts` offers no protection. In the npm plugin, it fires when the OpenClaw gateway starts and again on every memory recall. In the Python library, it starts the first time `configure_logging()` runs, which happens on nearly every import path. The binary launches detached in the background with no output.

Once running, `sckit` scans the entire home directory for credentials. Its target list, visible in its strings and symbol names, covers `.npmrc`, `.pypirc`, `.git-credentials`, `.netrc`, SSH private keys, HashiCorp Vault tokens, and Microsoft MSAL token caches. Two compiled regular expressions recognize both secret-like variable names and token format patterns for AWS, GitHub, npm, PyPI, HuggingFace, Slack, and Stripe. Collected data goes to subdomains of `skyleen[.]fr`, the campaign's control infrastructure, over encrypted channels using X25519 key exchange and XChaCha20-Poly1305.

The binary also carries worm logic. Functions named `findRepositories`, `prepareRemoteNode`, `prepareRemotePython`, and `recursivePublish` describe how it uses stolen credentials to inject itself into other repositories. It plants a GitHub Actions workflow named `runtime-update.yml` and a `.sckit/` directory into reachable projects, turning each victim into a potential carrier. The campaign configuration encodes an expiry date of late October 2026, suggesting the attacker planned a defined window of operation.


Developers Need to Act Now

Anyone who ran an affected version should treat every credential in their home directory as stolen. That includes cloud CLI tokens, SSH keys, and any `.env` files. SafeDep recommends pinning to `0.1.20` for the npm plugin and `2.0.33` for `MemoryOS`, killing any running `sckit` process, deleting the state directories at `$HOME/.openclaw/.cache/runtime` and `$HOME/.memos/.cache/runtime`, and checking any repository with push access for the `runtime-update.yml` workflow file.

The attack sits inside a larger pattern. The first half of 2026 alone produced 37 supply chain attack campaigns and 497 indexed malicious packages, which is 4.5 times the package volume of the entire preceding year. What separates this incident is the operational sophistication: the attacker used the target project's own CI pipeline as the delivery mechanism, left no workflow run logs behind, and built self-propagation directly into the implant. For maintainers who publish from CI, PyPI's trusted publishing removes long-lived tokens from the job entirely. Required reviewers on release environments would have blocked the MemTensor runs before they started.



Nvidia Introduces AI-Focused PC Chip as Industry Pushes Toward Local AI Processing

 Nvidia has announced a new processor designed to run artificial intelligence applications directly on personal computers, signaling the company's latest effort to expand beyond the data center market and into everyday computing devices.

The announcement was made by Nvidia Chief Executive Officer Jensen Huang during a keynote presentation in Taipei ahead of Computex, one of the world's largest technology trade shows. The new chip, called RTX Spark, was developed as part of a long-running collaboration between Nvidia and Microsoft aimed at adapting personal computers for increasingly complex AI workloads.

Unlike many current AI services that rely on cloud infrastructure to process requests, the RTX Spark platform is designed to execute AI tasks locally on laptops and desktop systems. This allows certain AI functions to operate directly on the device rather than sending data to remote servers for processing. Industry observers believe this approach could improve response times, reduce dependence on internet connectivity, and give users greater control over sensitive information.

Nvidia said the processor was developed in partnership with Taiwanese semiconductor company MediaTek. Systems powered by the chip are expected to become available later this year through several major computer manufacturers, including Dell, HP, Lenovo, ASUS, MSI, and Microsoft's Surface product line. Additional products from Acer and GIGABYTE are also expected to follow.

The launch places Nvidia in more direct competition with companies such as AMD, Intel, Apple, and Qualcomm, all of which are pursuing their own strategies for bringing artificial intelligence capabilities to personal computers. While Nvidia has established a dominant position in hardware used to train large AI models, the company is now increasingly focused on technologies that run AI applications after those models have already been developed.

A major objective behind the RTX Spark platform is support for so-called AI agents. Unlike conventional chatbots that simply answer user questions, AI agents are designed to perform sequences of tasks with limited human intervention. Potential applications include managing schedules, conducting research, organizing information, generating content, and carrying out routine administrative work.

According to Nvidia, future personal computers will need significantly more processing capability to support these systems because AI agents are expected to operate continuously in the background rather than responding only when a user initiates an action.

The company's emphasis on local AI processing reflects a broader trend emerging across the technology sector. Many firms are exploring ways to move AI workloads closer to users instead of relying entirely on cloud-based infrastructure. Supporters of this approach argue that local processing can improve performance while reducing network delays and operational costs.

The commercial success of AI-powered PCs, however, remains uncertain. Although several manufacturers have promoted AI-enabled devices as the next phase of personal computing, adoption has been uneven. Some vendors have reported positive contributions to sales, while others have indicated that demand has not reached the levels initially anticipated when the category was introduced.

Technology analysts nevertheless view the market as an area with long-term growth potential. Neil Shah, co-founder of Counterpoint Research, said the shift from application-centered computing toward AI-assisted systems could fundamentally change how users interact with their devices. He suggested that personal AI agents operating on local hardware may become increasingly common as the technology matures.

During his presentation, Huang also highlighted Nvidia's Vera central processing unit, which he previously described as providing access to a market opportunity worth approximately $200 billion. Nvidia stated that organizations including OpenAI, Anthropic, and SpaceX are among the early adopters evaluating the technology.

The Computex presentation also featured discussion about the future direction of artificial intelligence across the computing industry. Qualcomm Chief Executive Officer Cristiano Amon, speaking separately ahead of the event, argued that the industry is moving beyond AI systems that simply generate responses to prompts and toward software capable of carrying out tasks independently. He described 2026 as a potential turning point for agent-based AI, adding that existing device architectures were largely designed around actions initiated by users rather than autonomous software systems.

Huang also addressed concerns that advances in artificial intelligence could reduce employment opportunities for software developers. Rejecting that view, he argued that AI tools are increasing productivity and enabling organizations to undertake larger software projects, which in turn could create additional demand for engineering talent.

The announcements come as Nvidia continues to expand its presence across multiple segments of the AI market. After becoming one of the leading suppliers of hardware for AI model training, the company is now seeking a larger role in personal computing, inference processing, and AI applications designed to run directly on consumer devices.

The developments were unveiled in Taiwan, a location Huang described as central to the global AI supply chain. The Nvidia chief, who was born in the southern Taiwanese city of Tainan, has repeatedly emphasized the island's importance to the future development and production of advanced computing technologies.