Vulnerability with setuptools < 70.0.0 (CVE-2024-6345)

Hello,

I've seen CVE-2024-6345 report today. I was wondering if you plan to update setuptools at least on 3.11 images like you did in the past on #783.

Thank you

Not that this only affects version 3.11 and under. Version 3.12 is not affected.

Could this also be fixed in the 3.10 images? Thank you

@LaurentGoderre

@LaurentGoderre Is it alright if we make the same change as in PR #783, specifically updating the setuptools version to 70.0.0? If so, I can create the pull request.

Current versions of setuptools in affected versions:

3.11.9: 65.5.1
3.10.14: 65.5.1
3.9.19: 58.1.0
3.8.19: 57.5.0

Do we have any idea how many breaking changes there are between even 65.5.1 and 70.0.0? Also, any idea whether cpython upstream plans to do a new release with a different version bundled, since their upstream artifacts are also affected?

I'll also link to #781 (comment) explicitly, as it's even more relevant here (where the proposed update is 65.5.1 -> 70.0.0, not just 65.5.0 -> 65.5.1 as it was there).

GHSA-cx63-2mw6-8hw5

These functions, which are used to download packages from URLs provided by users or retrieved from package index servers, are susceptible to code injection. If these functions are exposed to user-controlled inputs, such as package URLs, they can execute arbitrary commands on the system.

I think I'm understanding correctly that this is only a security issue if you're blindly trusting attacker-controlled URLs and asking for them to be installed? That seems to limit the spread/impact considerably, especially since setuptools being part of an actual application stack seems unlikely (it'd be much more likely to be used during image build for installing packages/dependencies).

pypa/setuptools@v65.5.1...v70.0.0 is frankly a huge amount of change, and I'm certainly not comfortable making the blanket decision that this aggressive of an update is "OK" for all users of these images.

(Again, see #781 (comment) for a longer-form explanation of where I [still] stand on this.)

This is extremely annoying if you consider many companies are dealing with auomated security scans for SOC2 etc related stuff. Not sure if there is anything that can be done to be fixed other than building a custom image with setuptools>70 or ignoring this vuln on dockerhub

if you don't need setuptools once your image is built, you may uninstall it (i.e. include RUN pip uninstall setuptools -y near the end of the Dockerfile

Your options for getting an updated setuptools or clean scan (#1012 (comment)):

You will either need to either:

Update to Python 3.12 or newer (which no longer bundles setuptools)

Update setuptools in your own Dockerfile

Ask upstream CPython to update to newer setuptools in Python 3.11

Suppress the vulnerability alert if appropriate (you didn't say what vulnerability you were referring to, but it's quite possible it's a non-issue in practice - many setuptools codepaths are not used when it's used as a pip build backend, or need several other criteria to be a problem etc)

Because of the extreme likelihood of a breaking changes, we no longer update setuptools in the python images; we just include the bundled version (or don't include it at all, as is the case with 3.12+). Again, see also #781 (comment) for a longer form explanation.

Change base image to python:3.12-slim

Navigation Menu

Repository navigation

Vulnerability with setuptools < 70.0.0 (CVE-2024-6345) #942

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Vulnerability with setuptools < 70.0.0 (CVE-2024-6345) #942

Description

Activity

LaurentGoderre commented on Jul 16, 2024

johandebraak commented on Jul 18, 2024

guoard commented on Jul 20, 2024

tianon commented on Jul 22, 2024

tianon commented on Jul 22, 2024

tianon commented on Jul 22, 2024

tianon commented on Jul 22, 2024

aiakubovich commented on Aug 23, 2024

isidentical commented on Oct 18, 2024

johandebraak commented on Oct 18, 2024

aiakubovich commented on Oct 18, 2024

yosifkit commented on Mar 20, 2025

Metadata

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Issue actions