[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]

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.

[gpshead]

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

FWIW - agreed, this felt borderline given it required specific less-strict filters. if agreed, do we keep the cve assignment or undo that one?

i'm happy to move the news entry to Library, remove the cve ref, and reduce the level of backporting.

[StanFromIreland]

'm happy to move the news entry to Library, remove the cve ref, and reduce the level of backporting.

Sounds good to me, as for the CVE, closing the GHSA will tidy up the CVE. Sorry for the trouble!

[gpshead]

I have made the requested changes; please review again.

[bedevere-app]

Thanks for making the requested changes!

@StanFromIreland: please review the changes made to this pull request.