@sethmlarson wrote on the security-announce list (emphasis mine):
Correction for affectedness, an earlier description of the vulnerabilities mentioned that only Python 3.12 and later are affected, however the tarfile extraction filtering feature had been backported to earlier Python versions. If using extraction filtering in versions earlier than 3.12 then that usage may be affected. As always, please look to the CVE records for up-to-date information about which Python versions are affected.
My understanding from Seth’s original note was that the compromised feature was new with 3.12. Sure enough, looking at the 3.12 What’s New document, I see:
The extraction methods in :mod:tarfile, and :func:shutil.unpack_archive,
have a new a filter argument that allows limiting tar features than may be
surprising or dangerous, such as creating files outside the destination
directory.
I thought new features weren’t supposed to be backported to already released versions, precisely to reduce the chances of introducing new bugs into versions which were already in production.
That’s the policy, yes!
The Steering Council or release managers can always grant exceptions, and in this case, this was an explicit part of the PEP.
Additionally, it was a security feature, which are often backported. In the What’s new in 3.8 that Petr linked, a number of other security features are mentioned as being backported. Indeed, many of which are on by default and add a new module global, class attribute or function parameter to turn them off, rather than being fully backwards-compatible and only being opt-in if the new filter argument is passed.
The original fix (adding filters) was incomplete. It was also opt-in.
The docs did imply that you could trust the new filters. If any project was correctly“inspecting” tarballs to ensure they’re safe (unlikely without disabling most of tarfile’s functionality), and it actively switched from that to use the filters (off by default, until 3.14), then it had a new security issue.