On this page (7 sections)
A GitHub security advisory rates the pypa/gh-action-pypi-publish GitHub Action as Critical (CVSS 9.3). According to the GitHub advisory GHSA-5xjx-3w67-w9x9, older releases of the action bundled the emSign root CA certificate through the certifi trust store, and that CA is tied to the chain used by Sigstore for PyPI Trusted Publishing and Digital Attestations.
If your release pipeline publishes Python packages with this action, check which version you pin and move to 1.14.3. The public record is thin, so this article sticks to what the advisory states and marks what is still unknown.
What the advisory says
The advisory is titled as a revocation of a CA in the chain that Sigstore uses. It explains that the action bundled the emSign root CA trust store certificate through the certifi distribution, and that this has since been removed from the bundle. The new version no longer includes it.
It also notes that the certifi-provided TLS trust store is used by many projects in the Python ecosystem, including Sigstore, which the action relies on for Trusted Publishing and Digital Attestations. A related external compromise is referenced in the advisory with a tracking link, but the text available to us does not describe it, so we cannot say what happened there.
Background: trust stores and what is not explained
A trust store is the list of certificate authorities (CAs) a program accepts when it validates TLS connections and certificate chains. Python projects commonly get this list from the certifi package, which is why a change to certifi's contents can reach tools that depend on it, including the action and Sigstore.
What the advisory does not tell us matters just as much. It does not explain why the emSign root was removed, whether that CA was distrusted and by whom, or what concrete effect keeping it had on Sigstore signatures or attestations. Its title mentions a revocation of a CA in the chain, and the linked external compromise is not described in the text we have. Any claim about real-world impact on signed artifacts would go beyond the source.
The advisory's CVSS v4 metrics list a network attack vector, low complexity, no privileges and no user interaction, with high confidentiality and integrity impact on the vulnerable system. These are scoring inputs, not a description of an attack. The research describes no concrete attack, and we do not speculate about one.
Who is exposed
- Python projects that publish to PyPI from GitHub Actions using pypa/gh-action-pypi-publish.
- Teams using Trusted Publishing or publishing Digital Attestations through that action.
- Workflows pinned to a floating tag, a branch or a commit that resolves to version 1.14.2 or earlier.
- Agencies and hosting teams that ship internal or client Python packages through the same workflow.
The advisory's affected component is the publishing action. It does not describe projects that only install packages from PyPI as affected.
How to check your exposure
Search your repositories for the action reference and note the version or commit each workflow uses. This read-only command, run from the root of a checked-out repository, lists every workflow line that references the action. Look at the ref after the @ sign.
grep -rn "pypa/gh-action-pypi-publish" .github/workflows/If a line shows a version of 1.14.2 or lower, or a commit hash you cannot map to 1.14.3 or later, treat it as affected. Also check any reusable workflows or templates your organization shares, since they can carry the old reference into many repositories.
What to do now
0 of 7 done
A pinned reference after the update should look like the example below. It only shows the version tag in a workflow file; substitute whatever pinning policy your team uses.
- name: Publish package to PyPI
uses: pypa/gh-action-pypi-publish@v1.14.3Detection and monitoring afterwards
Watch your package's release history on PyPI for uploads you did not initiate, and review the GitHub Actions run log for each release. Enable Dependabot or a similar updater for GitHub Actions so action versions do not drift.
If you also run public websites or download pages for your packages, a free SSL certificate checker can show the certificate chain your own domains present, and certificate and DNS monitoring can alert you when it changes. These cover your web endpoints only, not the action's internal trust store. For broader context, see our small business website security guide.
What we do not know yet
- Whether this has been exploited in the wild. The advisory does not say.
- Why the emSign root was removed and what impact it had on Sigstore signatures or attestations. The advisory does not explain.
- The details of the external compromise the advisory links to.
- Whether a CVE identifier will be assigned. None appears in the research.
- Independent confirmation. Only the GitHub advisory covers this so far, so details may change as it is updated.
Sources
This article is based on the public sources below. Details can change as vendors and researchers publish more; check the original advisories before acting on version numbers.