75.3.3 & 75.3.4 flagged for GHSA-5rjg-fvgr-3xxf?

[Grochocinski]

Hello,

I noticed that versions 75.3.3 and 75.3.4 were flagged as affected by GHSA-5rjg-fvgr-3xxf, but the fix was backported to the 75.3.X line in PR #5027 and both 75.3.3 and 75.3.4 contain the fix.

Should the affected range for the GHSA be updated from < 78.1.1 --> < 75.3.3, >= 75.4.0, < 78.1.1?

[kenny-ish]

Yes, the advisory range is stale for the 75.3.x line, and the thing to change is the advisory, not the code.

What I checked: the v75.3.3 tag (commit 9ec1c94) contains the #5027 backport (it landed on maint/75.3 as d95c3f8, "fix#5009"), and setuptools/package_index.py there has the same _sanitize and _resolve_download_filename code as the v78.1.1 tag, line for line. 75.3.4 (maint/75.3, commit 118f129, NEWS entry "Backport CVE-47273 from 78.1.1 for Python 3.8") adds the startswith(tmpdir) containment check from the original fix commit 250a6d1 on top of that, and the 75.3.4 wheel on PyPI ships that same file. So both releases are patched, and the correct affected range is what you wrote: < 75.3.3, plus >= 75.4.0, < 78.1.1 (75.4.0 is where 3.8 support was dropped and nothing in between got the fix until 78.1.1).

The GHSA record in github/advisory-database still has a single range, introduced 0 / fixed 78.1.1, and its last modification is 2025-06-13, so nobody has updated it since the backport. Two ways to get it changed:

1. Anyone can do this: open GHSA-5rjg-fvgr-3xxf, click "Suggest improvements for this vulnerability" on the right, set the affected versions to "< 75.3.3" and ">= 75.4.0, < 78.1.1" (patched 75.3.3 and 78.1.1), and in "Reason for change" link PR Backport security fix to 75.3.x #5027, the v75.3.3 NEWS entry and the 75.3.4 NEWS entry. That opens a PR in github/advisory-database that GitHub's curation team reviews, and because this advisory was published from the pypa/setuptools repo they also tag the original publisher (jaraco) for comment. Docs: https://docs.github.com/en/code-security/security-advisories/working-with-global-security-advisories-from-the-github-advisory-database/editing-security-advisories-in-the-github-advisory-database

2. The advisory lives in this repo (GHSA-5rjg-fvgr-3xxf), so a repo admin can also edit it directly: Security tab, Advisories, open it, "Edit advisory", change the affected products, "Update security advisory". Docs: https://docs.github.com/en/code-security/security-advisories/working-with-repository-security-advisories/editing-a-repository-security-advisory . I couldn't confirm from the docs whether an edit to an already published repository advisory flows into the global advisory on its own, so option 1 is the one that definitely reaches the database, and it does not need maintainer access.

Two related things. The PYSEC-2025-49 record in pypa/advisory-database has the same "fixed: 78.1.1" range (plus a GIT range fixed at 250a6d1), so OSV-based tools like pip-audit will keep flagging 75.3.3 and 75.3.4 until that YAML gets the same split; their README says existing entries are edited by pull request. And the v75.3.4 git tag in this repo currently points at a commit on main (fc00800, pyproject.toml says 81.0.0, no package_index.py at all) instead of the maint/75.3 "Bump version: 75.3.3 → 75.3.4" commit 118f129. The PyPI wheel matches the maint branch and is fine, but anyone checking the fix through the tag will get the wrong answer, so it is probably worth re-pointing the tag before filing the advisory change.

[Grochocinski]

Thanks for the sanity check that the ~75.3.3 versions aren't vulnerable!

The advisory lives in this repo (GHSA-5rjg-fvgr-3xxf), so a repo admin can also edit it directly

@jaraco as the publisher of the advisory, would you be able to confirm the advisory range isn't accurate and update the range on the in-repo advisory accordingly?

I couldn't confirm from the docs whether an edit to an already published repository advisory flows into the global advisory on its own

I couldn't figure out if the self-published advisory fed directly into the GHSA DB either, but if it needs a manual PR/suggestion I can tackle that after the in-repo advisory is updated.

[kenny-ish]

Sounds like a good plan. If the in-repo advisory gets updated but the global entry still shows < 78.1.1 after a few days, the "Suggest improvements" route will still work, and the PYSEC record in pypa/advisory-database needs its own PR either way.

If the range question is settled for you, marking this as the answer would help others who land here from a scanner warning.