GitHub's 'Pwn Request' misconfiguration: How InvisiRisk BAF Shields Your CI/CD from Hidden Threats

The automation prowess of GitHub Actions, a cornerstone of modern CI/CD pipelines, harbors a subtle yet critical loophole. The pull_request_target trigger, if misconfigured, can be exploited in what's known as a "pwn request" attack, granting malicious actors access to your repository's secrets and write permissions. High-profile open-source projects from organizations like Splunk and MITRE, as well as local projects like Spotipy, have had workflows susceptible to this, as uncovered by security researchers at Sysdig. This post dissects the exposure by analyzing the specific workflow misconfigurations, walks through a practical replication of the attack, and demonstrates how InvisiRisk's Build Application Firewall (BAF), through its robust, out-of-the-box security policies, can proactively thwart such attacks, safeguarding your development ecosystem.

The Anatomy of a "pwn request": A Latent Threat in Your Workflow

The pull_request_target trigger in GitHub Actions is designed to allow workflows to run with elevated privileges—including access to secrets—on pull requests from forked repositories. While intended for legitimate purposes like labeling PRs, it creates a significant security risk if it's also used to check out and execute code from the pull request itself.

Several security researchers brought the issue to the forefront by identifying insecure GitHub Actions workflows in several popular open-source repositories. The common thread was the dangerous combination of the pull_request_target trigger with a step that checks out untrusted code from the PR. This gives attackers the keys to the kingdom, allowing for the exfiltration of secrets like API keys and deployment tokens, or even the injection of malicious code into the codebase itself, leading to potential supply chain attacks.

As highlighted by StepSecurity and Snyk Labs, a "pwn request" typically requires three conditions:

1. Workflow triggered by pull_request_target event: This event runs in the context of the base repository, granting the workflow higher privileges and access to repository secrets, unlike the standard pull_request event, which runs in the context of the fork.

2. Explicit checkout from the forked repository: The workflow explicitly checks out the pull request's head ref or repository, e.g., using actions/checkout with

   
   

   Reference : refs/pull/${{ github.event.pull_request.number }}/merge Repository: ${{ github.event.pull_request.head.repo.full_name }}

3. Code execution or injection point: There's a subsequent step that executes code from the checked-out PR, or a command injection vulnerability exists within a step that uses attacker-controlled input (like PR title or body) without proper sanitization.

Let's examine the unsanitized workflows from the three repositories that were initially identified:

• Splunk/security_content (appinspect.yml): This workflow used pull_request_target and explicitly checked out the pull request's code using ref.

Figure: Unsanitized workflow using pull_request_target event.

This command pulls the contributor's code and merges it, creating a scenario where any malicious script in the PR is executed with repository secrets available.

• mitre-attack/car (regenerate-docs.yml): This workflow also used pull_request_target but checked out the PR code with repository and ref.

Figure: Unsanitized workflow using pull_request_target event.

This directly pulls the code from the attacker's forked repository branch, running it in the privileged context of the target repository.

• spotipy-dev/spotipy (integration_tests.yml): Similar to the MITRE repo, this workflow used pull_request_targetalongside repository.

Figure: Unsanitized workflow using pull_request_target event.

Executing untrusted code from the forked repository while having access to SPOTIPY_CLIENT_ID and SPOTIPY_CLIENT_SECRET.

Figure: Recreated Secret leak for demonstration purposes.

In all three cases, the fundamental flaw is the same: running untrusted code in a trusted, privileged environment. This exploitability can lead to compromised repositories, production environment breaches, and widespread dependency risks if popular open-source projects are affected.

The InvisiRisk BAF Defense: The Same Attack, A Different Outcome

Now, let's replay the exact same attack on the mitre-attack workflow, but this time with the InvisiRisk Build Application Firewall (BAF) integrated into the build process.

The Setup and The Bait: Attack Initiated The attacker submits the same malicious pull request. The misconfiguredregenerate-docs.yml workflow begins to execute. It checks out the attacker's code containing the malicious command.

The Execution: BAF Intervenes As the script attempts to execute its command, InvisiRisk BAF, acting as a real-time firewall for your build, intercepts the outbound network request. This is where the attack unravels, regardless of which repository's misconfiguration is being exploited.

First Layer of Defense: "Only Allows Trusted Package Registry" Policy BAF immediately checks the destination address against its list of approved and trusted domains. Since the attacker-controlled server is not a trusted source, the policy triggers, and BAF blocks the network request from ever leaving the build environment. The attack is stopped before any data can be exfiltrated. In the BAF Activity Log, the user would see this action clearly marked as "Blocked" due to an untrusted source violation.

Figure: InvisiRisk BAF blocking untrusted source.

Second Layer of Defense: "Prevents Secret Leaks" Policy InvisiRisk BAF provides a critical second layer of defense. IR BAF doesn't just check the destination; it performs a deep packet inspection. Even if an attacker tried to send data to a seemingly legitimate domain, the "Prevents Secret Leaks" policy would have scanned the outgoing data. Upon identifying the distinct pattern of the secrets in the request's payload, BAF would have immediately blocked the request to prevent the leak. This action is flagged as a critical security finding, alerting the team to the attempted exfiltration.

Figure: InvisiRisk BAF blocking secret leak.

AI Anomaly Detection (The Game Changer): Even if standard policies are bypassed, the AI engine detects this malicious action as a deviation. It compares the build's network activity to its learned baseline of normal behavior. This unexpected network call to an unknown server stands out as a high-risk anomaly, triggering an alert even without a specific rule violation.

Figure: IR BAF’s Anomalies Detector flagging secrets leak anomaly.

The Result: Attack Thwarted, Secrets Secured with InvisiRisk BAF in place, the attack fails completely. The malicious script is prevented from communicating with its external destination, and the secrets remain secure within the buildenvironment. The team responsible receives immediate, actionable alerts detailing the blocked threat, allowing them to reject the malicious PR and secure their workflow configuration.

Figure: Visualization of InvisiRisk BAF.

Conclusion: From Reactive to Proactive Security

The discovery of the "pwn request" misconfiguration—present in the workflows of major projects—underscores the importance of a proactive and layered security posture. While it's crucial to follow secure workflow configuration best practices, such as:

• Disabling unnecessary pull_request_target triggers: If elevated privileges and secrets aren't strictly needed for PRs from forks, use the pull_request event instead.

• Limiting token permissions: Configure the permissions key in your workflows to grant the least privilege necessary for each job.

• Avoiding checkout of untrusted code: If pull_request_target is necessary, ensure that code from the forked repository is never checked out or executed. If it must be, implement stringent validation and isolation.

• Reviewing codes thoroughly: Regularly audit workflow configurations and the actions used within them for potential misconfigurations.

• Using security tools: Leverage tools like GitHub's CodeQL, OSSF Scorecards, or specialized CI/CD security platforms to identify and monitor for insecure patterns.

The dynamic nature of CI/CD pipelines necessitates a solution that can identify and block threats as they happen. InvisiRisk BAF acts as a vigilant guardian for your build process, ensuring that even if a vulnerability is present, it cannot be successfully exploited. By shifting from a reactive to a proactive security model, you can confidently leverage the power of automation without compromising the integrity of your software supply chain.

For more information about InvisiRisk and to get your free scan, please click here.