Blog Application Security

Briefing: the developer toolchain is the target

Three stories this week sit in the build and deploy path rather than at the network edge: a CI secret stealer pushed through hijacked GitHub accounts, an agentic pentest platform used in live AWS intrusions, and a critical HTTP/2 flaw in Apache httpd. Here is the through-line and the checklist.

Published 6 min read
Banner showing a build pipeline of connected nodes with a broken link glowing red, with the headline that the developer toolchain is the target.

Key takeaways

  • This week's three lead stories all sit in the build and deploy path: CI runners, application hosts and the web server in front of them.
  • wfx-loot shows a stolen developer login is enough to turn GitHub Actions into a credential harvester that persists in AWS and Azure.
  • The AntiFox intrusions pivot from an IIS app's web.config to a successful read of an AWS production secret.
  • Apache's critical mod_http2 race condition is reachable pre-authentication on any unpatched HTTP/2-enabled httpd in the affected range.
  • Rotation is not eviction: audit what the attacker changed, including trust policies and federated credentials.
  • Patch Apache now, and drop h2 and h2c from Protocols wherever patching lags.

The week's three biggest stories do not share a vendor, a CVE class or an actor. They share a location. Each one lands in the path between a developer's keyboard and a running service: the CI runner that holds the cloud credentials, the application host that holds the config file, and the web server that fronts everything. None of them needed a network perimeter to fail.

Story one: wfx-loot and the hijacked GitHub accounts #

Starting November 10, an attacker with stolen credentials for thousands of GitHub accounts opened probe pull requests titled "docs: dependency audit notes" and then pushed a roughly 1,500-line shell script, which calls itself wfx, into GitHub Actions workflows, CI scripts and npm postinstall hooks. Aikido Security, which disclosed the campaign, puts the scale at 4,837 compromised accounts and 61,764 targeted repositories, with the payload confirmed to have run and exfiltrated credentials in at least 1,806 repositories, later revised to at least 1,835. SafeDep counted 8,093 public repositories that received malicious commits on default branches. These are vendor figures, from different vendors, measuring different things; keep them apart.

The script, analysed by Endor Labs and OX Security, takes everything a runner can see: Actions secrets and variables, the GITHUB_TOKEN, OIDC tokens, and credential files for AWS, Azure, GCP, Docker, Kubernetes, npm, PyPI, SSH, GPG, Vault and Terraform, plus AI provider keys. It exchanges the OIDC tokens for live cloud sessions. Then it makes itself hard to evict by rewriting AWS role trust policies to allow any AWS principal and adding Azure federated credentials with a wfx-ci prefix. It posts forged success status checks to get past branch protection, reverts its own commit, and deletes the workflow run and its logs. Early copies exfiltrated over HTTP; OX Security reports new copies switched to Telegram bots on November 12. The campaign is live.

At least 50 of the hijacked accounts publish to npm, Go, Packagist, PyPI or crates.io, per Aikido, and compromised releases of at least two packages, one on Packagist and one Go module, are already known. The initial access vector is unconfirmed. Every source describes stolen credentials, not a GitHub platform vulnerability, and Aikido assesses the actor as different from October's GhostAction wave.

Story two: AntiFox, from web.config to Secrets Manager #

Arctic Wolf Labs published a report this week tying Alibaba Cloud hosts running AntiFox, an open-source, Chinese-language agentic pentesting platform built on the ARTEX framework, to confirmed intrusions. The attribution is infrastructural, and Arctic Wolf says so: cloud infrastructure "may be reassigned or shared with unrelated tenants", and the report does not prove an AI agent issued each command.

The chain is what matters. Initial access was either a compromised internet-facing IIS application, where the w3wp.exe worker spawned an ASPX web shell, or a valid AWS credential obtained "through unknown means". From the IIS host the actor used PowerShell and .NET configuration classes to parse web.config, lifted the database credential, and tried the internal production database. In AWS the actor enumerated 18 services, from IAM and S3 through Secrets Manager, KMS, EKS and Amazon Bedrock, and in one case cycled through identities to fire hundreds of requests in about 30 minutes. Most were denied. One was not: the activity "eventually progressed to a successful GetSecretValue request against a production secret". No victim was named, the IIS vulnerability was not identified, and AWS itself was not compromised.

Story three: a critical race condition in Apache mod_http2 #

The Apache Software Foundation shipped a new HTTP Server release this week fixing CVE-2026-119618, which Apache describes as a "Concurrent Execution using Shared Resource with Improper Synchronization vulnerability in Apache HTTP Server's mod_http2 in assign_headers() can lead to RCE" and rates critical. It was reported by Anthropic's OSS Scanner in late October and independently by Anthony Weems and Simon Scannell of Google Cloud Vulnerability Research in early November. Only servers that load mod_http2 and enable h2 or h2c through the Protocols directive are exposed, so the first job is to check the Protocols directive on every instance, including containers.

Apache assigns no CVSS score; Red Hat's near-maximum rating is Red Hat's own. Exploitation status is contested: Red Hat says public research has demonstrated a reliable exploit against a default configuration, while Wiz said no exploit was available, as reported by The Hacker News. Apache lists no workaround, but Wiz advises removing h2 and h2c from Protocols where patching lags, and The Hacker News notes the directive must be checked on every virtual host as well as server-wide. Standalone mod_h2 users have no fixed release at all, since The Hacker News reports the project's repository has been archived read-only since June.

The through-line #

Put the three side by side and the pattern is hard to miss.

Credentials, not exploits, open the door. wfx-loot starts with stolen GitHub logins. One of the AntiFox chains starts with a valid AWS key. Even the IIS chain, once inside, does nothing cleverer than reading a config file. Application security that stops at input validation misses all of it.

The build and deploy path is the richest target in the company. A CI runner holds more credentials than almost any production host: cloud OIDC trust, registry tokens, signing keys, AI provider keys. The wfx script is a checklist of every file a runner might contain. The AntiFox actor went straight for web.config, which is the application-layer equivalent.

Rotation is not eviction. The wfx persistence in AWS trust policies and Azure federated credentials survives a secret rotation. The AntiFox report makes the same point from the other side: rotate before revoking sessions and the attacker keeps the session. In both cases the fix is to look at what the attacker changed, not just what they took.

Pre-authentication paths still exist. The Apache bug is the counterexample that proves the rule. It is reachable by anyone who can negotiate HTTP/2, no credential required, and it sits on the one box that every application behind it depends on.

The checklist for this week #

  • GitHub. Search every repository, including ones where your accounts are only collaborators, for the probe PR title, the wfx-docs branch, and commit messages beginning "ci: refresh build cache", "chore: add ci helper", "chore: add dependency audit workflow", "ci: restore" and "ci: cleanup". Look for gaps in workflow run numbers.
  • Cloud. Audit AWS role trust policies for wildcard principals and Azure federated credentials with a wfx-ci prefix. Alert on successful GetSecretValue calls from unfamiliar infrastructure and on wide service enumeration from one identity.
  • CI hardening. Code-owner review on workflow files, a read-only default GITHUB_TOKEN, OIDC trust scoped to specific repositories and branches, and npm ci with --ignore-scripts.
  • Application hosts. Treat web.config and its equivalents as credential stores. Alert when w3wp.exe spawns a shell. Enforce IMDSv2 and least privilege on application identities.
  • Apache. Inventory every httpd instance with HTTP/2 enabled, including containers. Patch to the newest release or distribution backport. Where you cannot, drop h2 and h2c from Protocols at the server level and in every VirtualHost.

Sources #

Sources

  1. wfx-loot campaign pushes CI secret stealer to tens of thousands of repositories, Aikido Security
  2. Hijacked GitHub Accounts Push “wfx” CI Secret Stealer to Thousands of Repositories, Endor Labs
  3. Thousands Of GitHub Accounts Hijacked With wfx-loot CI Secret Stealing Malware Via GitHub Actions & npm, OX Security
  4. Attacker Used 4,837 Hijacked GitHub Accounts to Run a CI Secret Stealer in 1,806+ Repositories, The Hacker News
  5. Antifox Agentic Pentesting Platform Used to Steal AWS Credentials and Move Laterally in Compromised Environments, Arctic Wolf Labs
  6. AntiFox AI Pentesting Platform Linked to Attacks That Accessed AWS Production Secrets, The Hacker News
  7. Apache HTTP Server 2.4 vulnerabilities, Apache Software Foundation
  8. Critical Apache HTTP/2 Flaw Could Let Unauthenticated Attackers Execute Code Remotely, The Hacker News

Questions this raises

What connects these three stories?
Location. Each one lands in the path between a developer and a running service: the CI runner, the application host and its config file, and the web server. None required the network perimeter to fail.
If I rotate every secret my CI runner could see, am I done with wfx-loot?
No. Aikido and Endor Labs report the script rewrites AWS role trust policies to allow any principal and adds Azure federated credentials. Those survive rotation and must be removed.
Did an AI agent carry out the AntiFox intrusions?
Arctic Wolf links the activity to Alibaba Cloud hosts running AntiFox interfaces. It does not prove an agent issued each command, and it notes that cloud infrastructure can be reassigned or shared.
Is the Apache bug being exploited?
Reports conflict. Red Hat says a reliable exploit has been demonstrated against a default configuration, while Wiz said no exploit was available. Patch as if one exists.

briefingsupply-chainci-cd