GitHub Tightens Bug Bounty While Losing Control of Its CI/CD

GitHub has restructured its public bug bounty program, slashing payouts and creating an invite-only VIP tier, while its Actions infrastructure is simultaneously being abused as a global botnet for attacks on hosting servers through compromised repositories and malicious workflows with active command-and-control.

On July 27, 2026, GitHub's bug bounty restructuring takes effect, reducing public payouts and creating an invite-only VIP tier. Over the same period, an active campaign has turned GitHub Actions into a distributed botnet for attacks on hosting servers, leveraging compromised repositories and malicious workflows with active command-and-control. The chronological coincidence highlights an operational contradiction: while GitHub restricts human access to its attack surface, its automated infrastructure is being abused at global scale.

Key Takeaways

GitHub announced a reduction in public bug bounty payouts effective July 27, 2026: critical rewards drop from $30,000 to $10,000, with an invite-only VIP tier maintaining at least $30,000 for critical findings.
An active campaign converts GitHub Actions into a global botnet: malicious workflows in compromised repositories download multi-architecture payloads from an active C2 at IP 43.228.157.68.
The attack vector is not in the distributed PHP package code — which remains benign — but in workflow files under .github/workflows/, executed on GitHub's ephemeral Ubuntu runners.
The campaign has deployed 583 malicious workflow files, with GitHub searches associating the campaign with approximately 6,100–16,000 matching files, and a heartbeat to the C2 every 30 seconds.

The Bounty Cut: Less Public, More Exclusive

The source cites precise figures for the new system. Public payouts fall to $250 for low severity (previously $500–$1,000), $2,000 for medium (from $2,000–$5,000), $5,000 for high (from $5,000–$20,000), and $10,000 for critical (from $10,000–$30,000). The invite-only VIP tier maintains higher payouts: at least $30,000 for critical, with access reserved for researchers with a history of valid reports.

The official rationale, expressed by GitHub Product Security Engineer Catherine Cassell, is reducing the "noise" generated by AI-generated and low-effort reports. New researchers must satisfy HackerOne's "signal requirement," with four initial opportunities to prove report quality.

"These changes are about two things: reducing the noise so we can focus on the signal, and building a program that serious researchers find rewarding to participate in." — Catherine Cassell, GitHub Product Security Engineer

The reduction of the public bounty and creation of an exclusive tier represent an operational bet: fewer reports, but from researchers with proven track records. The source does not specify whether this restructuring correlates with the active botnet campaign on the same platform.

How the Botnet Works on GitHub Actions

The campaign documented by the primary source exploits an architectural separation in GitHub Actions: workflow files in .github/workflows/ are versioned in the repository but execute on GitHub infrastructure, not the end user's environment. This creates an abusable trust boundary: the code "sold" as a PHP package on Packagist is benign, but workflows triggered on push or manual dispatch execute malicious operations on GitHub's runners.

The ten compromised packages — all associated with the now-suspended account dinushchathurya — collectively contain 583 malicious workflow files distributed across development versions, with a density of 55–62 workflows per package. Activation occurs on specific events (push or manual trigger), not on installation via Composer, making the vector less immediate but more persistent: the compromised repository continues to host executable payloads as long as it remains online.

GitHub's ephemeral Ubuntu runners download the payload from the command-and-control server at IP 43.228.157.68, reachable via HTTP on architecture-specific paths: /api/dl/386, /api/dl/amd64, /api/dl/arm, /api/dl/arm64. The download uses curl or wget with permissive flags. The AMD64 payload, with SHA-256 hash 22f7...81f1, implements a scanner for vulnerability CVE-2026-41940 (CVSS 9.8 CRITICAL) targeting cPanel/WHM systems.

The C2 implements a heartbeat every 30 seconds to /api/github-heartbeat and an exfiltration endpoint at /api/github-results. Enumeration includes Git data, environment variables, and other information from the execution context. The mechanism transforms legitimate, temporary compute resources into geographically distributed botnet nodes, with automatic source IP rotation for each workflow execution.

The Scale: Between Matching Files and False Positives

The source reports two figures for the spread of related workflows. GitHub searches for the DNSHook identifier found approximately 6,100 matching workflow files. Broader searches with other indicators associate the campaign with approximately 15,000–16,000 files. These numbers do not indicate strictly compromised repositories: they include forks, mirrors, staging, and potential false positives. The source does not quantify actual impact in terms of compromised servers or stolen credentials.

The original dinushchathurya account has been suspended, but the campaign is considered ongoing: the C2 remains active, forks and mirrors survive the original account's removal, and GitHub Actions infrastructure continuously provides new ephemeral nodes. Persistence lies not in malware installed on disk — runners are ephemeral — but in the replicability of the workflow through forking of compromised repositories.

Why It Matters

The dossier does not specify whether GitHub was aware of the botnet campaign at the time of the bounty restructuring announcement. It does not document specific remedial measures taken against the malicious workflows beyond suspension of the identified account. The identity of the actor behind the campaign is unconfirmed, and no infrastructure overlaps link the operator to known threat groups at this time.

The source does not quantify the number of actual victims among the cPanel/WHM servers targeted by the scanner. It is unclear whether vulnerability CVE-2026-41940 is present in public databases at the time of analysis: the dossier reports it with CVSS 9.8 CRITICAL but provides no verification from NVD or official vendor advisory.

The operational dissonance remains the most solid finding: GitHub is tightening the human vulnerability reporting channel while its automated infrastructure suffers systemic abuse. For organizations using GitHub Actions, the source specifies no preventive controls beyond generic auditing of workflows in their own repositories and dependencies.

The Contradiction Between Researcher Control and Infrastructure Control Loss

The bug bounty restructuring and the botnet campaign are not causally linked in available documents. However, their chronological coincidence raises a structural question for development platforms: filtering who can report problems does not solve filtering what gets executed in the infrastructure itself. GitHub is investing moderation resources on the human frontier of the bounty, while the automated frontier of Actions presents a wider attack surface that is harder to contain with manual processes.

For security researchers, the contraction of public payouts and the raised "signal requirement" reduce economic opportunities for emerging talent. For the industry, the tension between democratization of security research — assisted by AI — and the need for quality risks expelling expertise before it can mature. The source provides no data on the actual volume of AI-generated reports that motivated the restructuring.

The botnet campaign demonstrates instead that malicious automation can exploit legitimate automation without competing for the same human attention resources. Malicious workflows require no bug bounty reports, nor moderator approval: they require only public repositories and execution triggers.

Information is based on the cited source and current as of publication.

Sources

Sources and references