chore(deps): [dataflow-gcs-to-alloydb] Update dependency jaraco-context to v6.1.0 [SECURITY] #307
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
This PR contains the following updates:
6.0.1→6.1.0jaraco.context Has a Path Traversal Vulnerability
CVE-2026-23949 / GHSA-58pv-8j8x-9vj2
More information
Details
Summary
There is a Zip Slip path traversal vulnerability in the jaraco.context package affecting setuptools as well, in
jaraco.context.tarball()function. The vulnerability may allow attackers to extract files outside the intended extraction directory when malicious tar archives are processed.The strip_first_component filter splits the path on the first
/and extracts the second component, while allowing../sequences. Paths likedummy_dir/../../etc/passwdbecome../../etc/passwd.Note that this suffers from a nested tarball attack as well with multi-level tar files such as
dummy_dir/inner.tar.gz, where the inner.tar.gz includes a traversaldummy_dir/../../config/.envthat also gets translated to../../config/.env.The code can be found:
This report was also sent to setuptools maintainers and they asked some questions regarding this.
The lengthy answer is:
The vulnerability seems to be the
strip_first_componentfilter function, not the tarball function itself and has the same behavior on any tested Python version locally (from 11 to 14, as I noticed that there is a backports conditional for the tarball).The stock tarball for Python 3.12+ is considered not vulnerable (until proven otherwise 😄) but here the custom filter seems to overwrite the native filtering and introduces the issue - while overwriting the updated secure Python 3.12+ behavior and giving a false sense of sanitization.
The short answer is:
If we are talking about Python < 3.12 the tarball and jaraco implementations / behaviors are relatively the same but for Python 3.12+ the jaraco implementation overwrites the native tarball protection.
Sampled tests:

Details
The flow with setuptools in the mix:
PoC
This was tested on multiple Python versions > 11 on a Debian GNU 12 (bookworm).
You can run this directly after having all the dependencies:
Output:
Impact
Remediation
I guess removing the custom filter is not feasible given the backward compatibility issues that might come up you can use a safer filter
strip_first_componentthat skips or sanitizes../character sequences since it is already there eg.Severity
CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:C/C:H/I:N/A:NReferences
This data is provided by OSV and the GitHub Advisory Database (CC-BY 4.0).
Release Notes
jaraco/jaraco.context (jaraco-context)
v6.1.0Compare Source
v6.0.2Compare Source
Configuration
📅 Schedule: Branch creation - "" (UTC), Automerge - At any time (no schedule defined).
🚦 Automerge: Disabled by config. Please merge this manually once you are satisfied.
♻ Rebasing: Whenever PR becomes conflicted, or you tick the rebase/retry checkbox.
🔕 Ignore: Close this PR and you won't be reminded about this update again.
This PR was generated by Mend Renovate. View the repository job log.