CVE-2025-47271 is a code injection vulnerability classified under CWE-94 (Improper Control of Generation of Code) affecting the OZI-Project's 'publish' GitHub Action, specifically versions 1.13.2 through 1.13.5. This GitHub Action automates the publishing of releases to PyPI, including mirroring releases, signature bundles, and provenance information in tagged releases. The vulnerability arises because untrusted input—specifically branch names—flows into the pull request (PR) creation logic without adequate sanitization or validation. An attacker who can influence branch naming conventions could craft a malicious branch name that injects arbitrary code into the GitHub Action workflow. This code would then execute with the permissions of the GitHub Action runner, potentially allowing unauthorized code execution within the CI/CD pipeline. The vulnerability is patched in version 1.13.6, and as a temporary workaround, users may downgrade to a version prior to 1.13.2, which does not contain the vulnerable code path. The CVSS 4.0 base score is 6.3 (medium severity), reflecting network attack vector, low attack complexity, no privileges or user interaction required, but with high impact on confidentiality, integrity, and availability. No known exploits are currently reported in the wild. The vulnerability does not require authentication or user interaction, increasing its risk in automated environments. The flaw is significant because it targets the software supply chain, where compromise can lead to widespread downstream impact by injecting malicious code into published packages or release artifacts. Given the nature of GitHub Actions and PyPI publishing, this vulnerability could be leveraged to distribute malicious Python packages or tamper with release provenance, undermining trust in software artifacts.

For European organizations, the impact of CVE-2025-47271 is primarily on the integrity and trustworthiness of software supply chains. Organizations relying on the OZI-Project 'publish' GitHub Action for automated release management to PyPI or internal mirrors risk unauthorized code execution within their CI/CD pipelines. This could lead to the injection of malicious code into Python packages distributed internally or publicly, potentially affecting downstream consumers and users. The compromise of release signatures and provenance data could further erode confidence in software authenticity and traceability. Given the widespread use of Python and GitHub Actions in European software development, this vulnerability could disrupt software development lifecycles, cause reputational damage, and introduce backdoors or malware into production environments. The medium severity rating indicates a moderate but tangible risk, especially for organizations with automated release workflows that do not implement additional validation or isolation controls. The absence of known exploits suggests that proactive mitigation can prevent exploitation. However, the potential for supply chain attacks makes this vulnerability particularly concerning for sectors with high software integrity requirements, such as finance, healthcare, and critical infrastructure within Europe.

1. Upgrade the OZI-Project 'publish' GitHub Action to version 1.13.6 or later immediately to apply the official patch. 2. If upgrading is not immediately feasible, downgrade to a version prior to 1.13.2 as a temporary workaround to avoid the vulnerable code path. 3. Implement strict branch naming policies and validation in the repository to prevent injection of malicious characters or code in branch names. 4. Restrict who can create branches and pull requests in repositories using this action, limiting to trusted contributors only. 5. Use GitHub Actions workflow permissions to minimize the privileges granted to the 'publish' action, employing least privilege principles. 6. Enable workflow run approvals for pull requests from forks or untrusted sources to prevent automatic execution of potentially malicious code. 7. Monitor CI/CD logs and audit trails for unusual activity or unexpected code execution during release workflows. 8. Consider isolating the publishing workflow in a separate repository or environment with strict access controls. 9. Employ software composition analysis and supply chain security tools to detect anomalous changes in published packages or signatures. 10. Educate development teams about the risks of code injection in CI/CD pipelines and encourage secure coding and DevSecOps practices.