GHSA-q58j-g3f4-h26h

### Summary

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: ```bash #!/bin/bash echo "=== PWNED ===" echo "whoami:" whoami ``` 4. Commit the changes and open a Pull Request against the `5.0` or `next` branch of the base repository. 5. 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`). 6. You will see the output of `whoami` (typically `runner`), proving that the arbitrary code was successfully executed in the runner's context.

<img width="490" height="87" alt="スクリーンショット 2026-04-14 11 14 56" src="https://github.com/user-attachments/assets/94276033-b989-46dc-b4a1-3dafa1603235" />

**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.