* SECURITY UPDATE: tarfile 'data'/'tar' extraction filter bypass via a hard link to a symbolic link (CWE-59, link following). TarFile.makelink_with_filter() passed tarinfo._link_target straight to os.link(); link(2) does not follow symbolic links, so an archive storing a hard link whose target is an archived symlink got the *same symlink inode* materialised one directory shallower than the symlink the filter had validated. Its relative body then re-based outside the destination directory, and the chmod()/utime() that extraction performs on the newly created name followed the link onto the outside file, changing its permissions and modification time; its contents also became readable through the in-tree path. Reproduced on the patched 3.9.23 tree with a four-member archive ('x' regular decoy, 'sub/' directory, 'sub/link' -> '../x' symlink, 'escape' hard link to 'sub/link' with mode 0777 and mtime 946684800) extracted with filter='data': a file outside the destination went 0600 -> 0755, its mtime was rewritten to 946684800 and its contents were readable through dest/escape. After the fix the outside file is untouched and dest/escape is a genuine in-tree hard link to the extracted decoy. - debian/patches/CVE-2026-82049.patch: backport of cpython b8f23e307097552eaea2604383a12ab280520d0d (gh-157190, GH-157191, GH-157192), which resolves the hard-link source with os.path.realpath() before calling os.link(), plus its regression test test_sneaky_hardlink_relocation in Lib/test/test_tarfile.py. This one-liner is sufficient only because CVE-2026-11940 is already applied: it closes the variant where the archive carries a decoy at the symlink's in-destination target so os.path.exists() is true and os.link() runs, while the no-decoy variant skips os.link() entirely and is closed by the guard CVE-2026-11940.patch added to makelink_with_filter(). The two must not be separated. - CVE-2026-82049