[gpshead]

When a hard link member's target is missing, makelink_with_filter() extracts a copy of the referenced member instead. If that member is a symlink, _extract_member() went on to apply the hard link's owner, mode and mtime with calls that follow the symlink, so they could land on a file outside the destination with the 'tar' and 'fully_trusted' filters. Attribute setting is now skipped when a hard link member ended up as a symlink; the nested extraction has already applied the symlink member's own attributes without following it. A hard link extracted as a copy of a regular file still gets the hard link's attributes, as before.

Fixes #160297

ANT-2026-Y0H1Y0ER

• Issue: tarfile applies a hard link member's attributes through a symlink extracted in its place #160297

[StanFromIreland]

Please add the CVE.

[gpshead]

I put up a GHSA for assignment. We don't need to wait for that to fix things though.

[StanFromIreland]

@gpshead, JFYI you can accept the GHSA yourself (add [ACCEPTED] to the title), which will trigger assignment of a CVE. To wait even less, since the bot runs on an hourly cron, you can trigger a run in python/psrt-ghsa-bot, to get one almost instantly.

[StanFromIreland]

I ran the steps, and CVE-2026-116125 was assigned.

[StanFromIreland]

I ran the steps, and CVE-2026-116125 was assigned.

[StanFromIreland]

Suggested change

	Fix :meth:`tarfile.TarFile.extractall` and :meth:`tarfile.TarFile.extract`
	.. cve: CVE-2026-116125
	Fix :meth:`tarfile.TarFile.extractall` and :meth:`tarfile.TarFile.extract`

[StanFromIreland]

Sorry, properly reviewing this now I don't think this is a type-security issue (more so a correctness issue). As documented, tarfile.tar_filter:

This filter does not check link targets (TarInfo.linkname). It allows benign cases (like links to /dev/null), but it also allows links (symbolic and hard) to arbitrary files on the filesystem, potentially granting unintended access to these files.

Because of that, a single hard link member with linkname ../flag already creates a hard link to the outside file and applies the member's mode, mtime and owner to it. The PR's two-member fallback route reaches nothing the filter does not already permit directly. The data filter, which is the documented to refuse to extract links (hard or soft) that link to absolute paths, or ones that link outside the destination, already rejects this fallback with LinkFallbackError, and fully_trusted is trusted by definition, so no documented security boundary is crossed under any built-in filter.

[bedevere-app]

When you're done making the requested changes, leave the comment: I have made the requested changes; please review again.