GitHub Actions strengthens checkout security to block 'pwn request' attacks

Faced with an increase in cyberattacks wreaking havoc on development environments, GitHub has strengthened the security of GitHub Actions checkout to block 'pwn request' attacks that exploit the insecure use of the pull_request_target trigger to execute the attacker's code with full workflow privileges. It was announced on June 18 that actions/checkout v7 now automatically blocks and fails workflows when used inside pull_request_target or workflow_run events when attempting to retrieve untested fork pull request code.

See also: Coinbase was the target of GitHub Actions breaches

From now on, the only way to bypass these checks will be for developers to implement an exception by adding an allow-unsafe-pr-checkout to actions/checkout, as GitHub noted in the V7 changelog. The change marks the beginning of a new era of 'security by default', in which security will be determined by GitHub's system rather than developer judgment.

As part of this effort, on July 16, the new defaults will be integrated into all supported major versions. “Workflows that are associated with a floating major tag (e.g., actions/checkout@v4) will automatically adopt the change. Workflows that are associated with a specific SHA, minor, or patch version are not affected by the integration and will need to be upgraded using Dependabot or through standard upgrade processes,” GitHub explained.

However, because pwn request attacks can occur in other ways, “further enhancements to additional events may be considered in future releases,” the changelog added. One criticism that can be leveled at GitHub is that it took so long to address a vulnerability that has been known for years. The problem is with GitHub Actions, which allows triggers to execute workflows, including pull_request, which processes third-party forks without giving access to secrets like API keys, service tokens , and credentials.

The downside is that this restriction prevents some automations from working, so developers turn to an alternative trigger, pull_request_target, which provides the required access.

See also: GitHub Actions: Supply chain attack steals CI/CD credentials

At some point, the attackers realized that when pull_request_target was carelessly configured with actions/checkout to pull untrusted fork code, it provided a backdoor into repositories and their secrets. In other words, the weakness in pull_request_target is not the trigger itself, which is legal and safe when used correctly, but its misuse.

As the GitHub changelog states: “Retrieving the head of an unchecked pull request from a fork within one of these workflows would typically allow attacker-controlled code to be executed with full workflow privileges.” The arrival of actions/checkout v7, however, should make this more difficult, automatically blocking dangerous workflows regardless of their configuration. Unfortunately, a lot of damage has already been done.

Open source repositories have recently come under sustained attack from the hacking group TeamPCP, using a variety of techniques, including pwn requests. A notable example was their attack last month, which compromised 170 node package manager (npm) packages, including the TanStack Router ecosystem, thanks to a pwn request exploit. Embarrassingly, in a separate incident that did not involve a pwn request, GitHub itself was compromised, and the attackers extracted source code from around 3,800 of the company’s internal repositories.

See also: GitHub disables npm install scripts to protect against attacks

Better late than never, GitHub has begun a series of security reforms to the platform, including, earlier this month, restricting the automatic execution of installation scripts in npm.