GHSA-Q58J-G3F4-H26H
Vulnerability from github – Published: 2026-05-14 13:18 – Updated: 2026-06-09 11:55Summary
The GitHub Actions workflow (.github/workflows/static.yml) uses the pull_request_target trigger but dangerously checks out the unverified code from the pull request head (ref: ${{ github.event.pull_request.head.ref }}). Subsequently, it executes a script (bin/console) from this untrusted checkout.
This allows any external attacker to achieve Remote Code Execution (RCE) on the GitHub Actions runner simply by submitting a malicious Pull Request. Also known as a "Pwn Request" vulnerability.
Steps to Reproduce:
1. Fork the target repository.
2. In the forked repository, modify a file that satisfies the paths condition (e.g., src/dummy.php or composer.json) to trigger the workflow.
3. Modify the bin/console file (which is executed in the workflow steps) with the following malicious payload:
#!/bin/bash
echo "=== PWNED ==="
echo "whoami:"
whoami
- Commit the changes and open a Pull Request against the
5.0ornextbranch of the base repository. - The
Static Testsworkflow will trigger automatically. Navigate to the Actions tab and inspect the logs for theValidate YAML(or any step executingbin/console). - You will see the output of
whoami(typicallyrunner), proving that the arbitrary code was successfully executed in the runner's context.
Impact:
Because pull_request_target runs in the context of the base repository, the runner has access to repository secrets (e.g., PIMCORE_SECRET, PIMCORE_PRODUCT_KEY) loaded in the environment. An attacker can exfiltrate these secrets, modify repository contents (if the token has write permissions), or abuse the runner's computing resources.
Recommended Mitigation:
Do not checkout untrusted PR code (head.ref) when using pull_request_target if the code will be built or executed.
Consider adopting a separated architecture using the workflow_run event:
1. Use the pull_request event to safely run the build/tests in an unprivileged sandbox and upload artifacts.
2. Use the workflow_run event (which is privileged) to download the artifacts and perform actions requiring secrets.
{
"affected": [
{
"package": {
"ecosystem": "Packagist",
"name": "coreshop/core-shop"
},
"versions": [
"5.0.0"
]
}
],
"aliases": [
"CVE-2026-41249"
],
"database_specific": {
"cwe_ids": [
"CWE-94"
],
"github_reviewed": true,
"github_reviewed_at": "2026-05-14T13:18:16Z",
"nvd_published_at": "2026-06-04T20:16:57Z",
"severity": "HIGH"
},
"details": "### Summary\n\nThe GitHub Actions workflow (`.github/workflows/static.yml`) uses the `pull_request_target` trigger but dangerously checks out the unverified code from the pull request head (`ref: ${{ github.event.pull_request.head.ref }}`). Subsequently, it executes a script (`bin/console`) from this untrusted checkout.\nThis allows any external attacker to achieve Remote Code Execution (RCE) on the GitHub Actions runner simply by submitting a malicious Pull Request. Also known as a \"Pwn Request\" vulnerability.\n\n**Steps to Reproduce:**\n1. Fork the target repository.\n2. In the forked repository, modify a file that satisfies the `paths` condition (e.g., `src/dummy.php` or `composer.json`) to trigger the workflow.\n3. Modify the `bin/console` file (which is executed in the workflow steps) with the following malicious payload:\n```bash\n#!/bin/bash\necho \"=== PWNED ===\"\necho \"whoami:\"\nwhoami\n```\n4. Commit the changes and open a Pull Request against the `5.0` or `next` branch of the base repository.\n5. The `Static Tests` workflow will trigger automatically. Navigate to the Actions tab and inspect the logs for the `Validate YAML` (or any step executing `bin/console`).\n6. You will see the output of `whoami` (typically `runner`), proving that the arbitrary code was successfully executed in the runner\u0027s context.\n\n\u003cimg width=\"490\" height=\"87\" alt=\"\u30b9\u30af\u30ea\u30fc\u30f3\u30b7\u30e7\u30c3\u30c8 2026-04-14 11 14 56\" src=\"https://github.com/user-attachments/assets/94276033-b989-46dc-b4a1-3dafa1603235\" /\u003e\n\n\n**Impact:**\nBecause `pull_request_target` runs in the context of the base repository, the runner has access to repository secrets (e.g., `PIMCORE_SECRET`, `PIMCORE_PRODUCT_KEY`) loaded in the environment. An attacker can exfiltrate these secrets, modify repository contents (if the token has write permissions), or abuse the runner\u0027s computing resources.\n\n**Recommended Mitigation:**\nDo not checkout untrusted PR code (`head.ref`) when using `pull_request_target` if the code will be built or executed.\nConsider adopting a separated architecture using the `workflow_run` event:\n1. Use the `pull_request` event to safely run the build/tests in an unprivileged sandbox and upload artifacts.\n2. Use the `workflow_run` event (which is privileged) to download the artifacts and perform actions requiring secrets.",
"id": "GHSA-q58j-g3f4-h26h",
"modified": "2026-06-09T11:55:16Z",
"published": "2026-05-14T13:18:16Z",
"references": [
{
"type": "WEB",
"url": "https://github.com/coreshop/CoreShop/security/advisories/GHSA-q58j-g3f4-h26h"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-41249"
},
{
"type": "WEB",
"url": "https://github.com/coreshop/CoreShop/commit/cc1e3f547228ec5ebfc1dc0472f9a3cc5f4137a4"
},
{
"type": "PACKAGE",
"url": "https://github.com/coreshop/CoreShop"
},
{
"type": "WEB",
"url": "https://github.com/coreshop/CoreShop/blob/5.1.0-beta.1/.github/workflows/static.yml#L14"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:L/A:N",
"type": "CVSS_V3"
}
],
"summary": "CoreShop Vulnerable to Remote Code Execution (RCE) via Insecure `pull_request_target` Configuration"
}
Sightings
| Author | Source | Type | Date | Other |
|---|
Nomenclature
- Seen: The vulnerability was mentioned, discussed, or observed by the user.
- Confirmed: The vulnerability has been validated from an analyst's perspective.
- Published Proof of Concept: A public proof of concept is available for this vulnerability.
- Exploited: The vulnerability was observed as exploited by the user who reported the sighting.
- Patched: The vulnerability was observed as successfully patched by the user who reported the sighting.
- Not exploited: The vulnerability was not observed as exploited by the user who reported the sighting.
- Not confirmed: The user expressed doubt about the validity of the vulnerability.
- Not patched: The vulnerability was not observed as successfully patched by the user who reported the sighting.