Hi! Could you elaborate on the first attack scenario?
> Target: Python package managers using tokio-tar (e.g., uv). An attacker uploads a malicious package to PyPI. The package's outer TAR contains a legitimate pyproject.toml, but the hidden inner TAR contains a malicious one that hijacks the build backend. During package installation, the malicious config overwrites the legitimate one, leading to RCE on developer machines and CI systems.
It seems to imply that you’re already installing a package uploaded by a malicious entity. Is the vulnerable workflow something like “you manually download the package archive, unpack it with system tar, audit all the files and then run uv install, which will see different files”?
Someone could release a malicious package that looks okay to a scanner tool, but when installed using uv can behave differently, allowing attackers to masquerade executable code.
In addition, for OCI images, it is possible to produce an OCI image that can overwrite layers in the tar file, or modify the index. This could be done in a way that is undetectable by the processor of the OCI image. Similar attacks can be done for tools that download libraries, binaries, or source code using the vulnerable parser, making a tar file that when inspected looks fine but when processed by a vulnerable tool, behaves differently.
It is possible to exploit this bug by crafting a file that has tar contents without a header, thus making it hard to detect even with recursive archives.
Since this came up specifically for `uv` (i.e. since the Python ecosystem relies on source distributions packaged as .tar.gz): has the Python standard library implementation (which is used by pip) been checked for a similar vulnerability?
