en.Wedoany.com Reported - GitHub has launched actions/checkout v7, which automatically blocks unsafe workflows to prevent so-called "pwn request" attacks. These attacks exploit misconfigurations in the pull_request_target workflow trigger, allowing attacker code to run with full workflow permissions.

The root cause lies in developers switching to the pull_request_target trigger to obtain secrets such as API keys. This trigger itself has no vulnerabilities, but when improperly configured with actions/checkout, it checks out code from untrusted branches, opening a backdoor to the repository and its secrets. Released on June 18, actions/checkout v7 now automatically blocks such risky workflows and causes them to fail.

In the v7 changelog, GitHub noted that the only way to bypass these checks is for developers to explicitly add allow-unsafe-pr-checkout to opt out. This change marks the beginning of a new era of "secure by default," where security is defined by the system rather than left to developers. As part of this initiative, the new default settings will be backported to all supported major versions on July 16. Workflows pinned to floating major tags (e.g., actions/checkout@v4) will automatically receive the changes, while those pinned to specific SHAs, minor versions, or patch versions will not be affected by the backport and will need to be upgraded via Dependabot or established upgrade processes.

Recently, attacks using the pwn request technique have caused significant damage, with open-source repositories continuously targeted by the TeamPCP hacker group. Last month, attackers exploited this vulnerability to compromise 170 npm packages, including the TanStack Router ecosystem. Additionally, in a separate incident not involving pwn request, source code from approximately 3,800 internal GitHub repositories was also stolen.

GitHub has taken action, planning a series of security reforms, including restricting the execution of automatic installation scripts in npm earlier this month. The changelog also stated that since pwn request attacks may occur through other avenues, future versions may explore further strengthening protections for other events.

This article is compiled by Wedoany. All AI citations must indicate the source as "Wedoany". If there is any infringement or other issues, please notify us promptly, and we will modify or delete it accordingly. Email: news@wedoany.com