A new threat campaign, tracked as "prt-scan," has demonstrated how artificial intelligence can supercharge supply chain attacks on GitHub. Using automated scripts, a single threat actor opened hundreds of malicious pull requests across more than 450 repositories, targeting a specific misconfiguration in GitHub Actions. While the majority of attempts failed, the attacker successfully compromised at least two NPM packages and exposed sensitive credentials in several projects.
How the Attack Worked
The campaign exploited a well-known but still widespread misconfiguration: the use of the pull_request_target trigger in GitHub Actions. Unlike the standard pull_request trigger, which runs workflows in the context of the forked repository, pull_request_target runs in the context of the base repository. This gives the workflow access to repository secrets—API keys, cloud credentials, and other sensitive data—that the forked branch should never see. Developers often use this trigger to automatically test or approve pull requests from external contributors, but without proper safeguards, it becomes an open door for attackers.
In the prt-scan campaign, the attacker first scanned public repositories for signs of this trigger. Once identified, they forked the project, created a new branch, and embedded malicious code inside what appeared to be a routine update—such as a dependency bump or typo fix. The pull request would then trigger the workflow automatically, executing the payload inside the main repository's environment. The goal was to steal credentials, environment variables, and other secrets that could be used for lateral movement or further compromise.
AI-Augmented Automation
The scale of the campaign suggests the attacker used AI tools to automate the entire process. From repository scanning to pull request creation and payload customization, the attack unfolded in six distinct waves over three weeks. The first wave, beginning March 11, resembled a testing phase with only 10 pull requests. After a nearly two-week pause, the attacker resumed at a much higher velocity: over a 26-hour period on April 2, they opened 475 pull requests containing a sophisticated payload.
This rapid acceleration is a hallmark of AI-assisted automation. The attacker could generate pull request titles, commit messages, and even code changes that appeared legitimate at first glance. Wiz researchers noted that the payload itself was ambitious—designed to exfiltrate multiple types of credentials—but the implementation was sloppy. The attacker appeared to misunderstand some aspects of GitHub's permissions model, leading to techniques that rarely succeeded. Nevertheless, the campaign enjoyed a roughly 10% success rate, resulting in dozens of compromised repositories.
Comparison with Previous Campaigns
The prt-scan campaign is the second AI-augmented supply chain attack targeting GitHub in recent months. In late February, a similar campaign known as "hackerbot-claw" used malicious pull requests to exploit the same pull_request_target trigger. That campaign was more targeted, hitting high-profile repositories with custom-crafted attacks. It succeeded in stealing GitHub tokens, cloud credentials, and even managed to inject malware into some projects. In contrast, prt-scan cast a much wider net, targeting both small hobbyist projects and larger open-source initiatives. While it achieved fewer high-value compromises, its scale demonstrates how AI makes it easy for attackers to launch broad, untargeted campaigns with minimal effort.
The implications are significant. Low-sophistication threat actors can now leverage AI to automate the tedious parts of an attack—scanning, forking, creating pull requests—freeing them to focus on payload development and target selection. This democratization of sophisticated attack techniques means that even amateur hackers can mount operations that would have previously required substantial resources and expertise.
What Was at Risk
In most successful attacks, the exposed credentials were ephemeral—GitHub tokens tied to the workflow itself, which expired quickly. However, in some cases, the attacker gained access to persistent secrets, including cloud API keys and repository secrets. The compromise of two NPM packages is particularly concerning, as it could allow the attacker to distribute malicious code to downstream users. The supply chain risk is magnified when attacks affect widely used open-source libraries; a single compromised package can affect thousands of applications.
Nevertheless, Wiz researchers noted that the campaign's impact was limited by the attacker's flawed approach. The malicious payload often failed to execute correctly, and even when it succeeded, the stolen data was often of limited value. But the campaign serves as a warning: as AI tools improve, so will the quality of such attacks. Future campaigns may combine the scale of prt-scan with the precision of hackerbot-claw, leading to more severe outcomes.
Preventing Similar Attacks
The key to defending against these attacks lies in understanding and mitigating the risks of pull_request_target. The GitHub documentation explicitly warns against using this trigger on pull requests from untrusted forks without additional controls. Security teams should audit their GitHub Actions workflows to identify any use of pull_request_target and ensure that it is either replaced with the safer pull_request trigger or guarded by strict conditionals that limit access to secrets. For example, workflows can be restricted to run only when specific paths are changed, or only when the pull request originates from the same repository (not a fork). Another best practice is to use token permissions with the least privilege principle, granting only the necessary scopes and setting permissions: read-all where possible.
Organizations should also monitor for unusual pull request activity. The prt-scan campaign exhibited distinct patterns: a sudden spike in pull requests from new accounts, repositories targeting specific workflow files, and payloads that attempted to access environment variables. Security teams can use GitHub's audit logs and external monitoring tools to detect such anomalies. Additionally, repositories with high sensitivity—those containing proprietary code or production credentials—should require manual review of all pull requests from external contributors, even if automated workflows are in place.
The threat landscape is evolving rapidly. The use of AI in cyberattacks is not new, but its application to supply chain attacks on platforms like GitHub represents a paradigm shift. Attackers no longer need to manually craft each exploit; they can let algorithms do the heavy lifting. For defenders, this means that traditional security measures must be augmented with behavioral analytics, automation, and continuous education. Developers must be trained to recognize suspicious pull requests, and security policies must be enforced through code reviews and automated checks.
GitHub itself has acknowledged the issue and continues to update its platform with security features like secret scanning and Dependabot alerts. However, as the prt-scan campaign shows, no amount of built-in security can fully protect against misconfigured workflows. The responsibility ultimately falls on repository maintainers to understand the tools they use and to apply security best practices consistently.
The prt-scan campaign is a stark reminder that even a flawed attack, when scaled with AI, can pose a tangible threat. The security community must remain vigilant, share intelligence about emerging tactics, and proactively harden development environments. The next AI-augmented attack may not be so clumsy—and the consequences could be far more severe.
Source: Dark Reading News