build: bump starlette to 1.3.1 and tornado to 6.5.6 to fix container CVEs#4396
Closed
ko3n1g wants to merge 2 commits into
Closed
build: bump starlette to 1.3.1 and tornado to 6.5.6 to fix container CVEs#4396ko3n1g wants to merge 2 commits into
ko3n1g wants to merge 2 commits into
Conversation
…p7-x3pw-xc5r Remediate two High-severity starlette CVEs in the uv-managed /opt/venv install: - GHSA-82w8-qh3p-5jfq (request.form() limit bypass DoS), patched in 1.3.1 - GHSA-wqp7-x3pw-xc5r (StaticFiles UNC SSRF, Windows-only), patched in 1.1.0 starlette is transitive (fastapi, mlflow-skinny, prometheus-fastapi-instrumentator, sphinx-autobuild); neither CVE has a 0.x backport, so the floor is pinned via [tool.uv] override-dependencies, matching the existing CVE-remediation pattern. prometheus-fastapi-instrumentator is bumped 7.0.0 -> 8.0.0 because its 7.x line caps starlette<1.0.0; the 8.x line requires starlette>=1.0.0. fastapi, mlflow-skinny and sphinx-autobuild already permit starlette 1.x. Does not address the system-level (/usr/local/lib dist-packages) starlette/tornado findings, which live in the fw_final image, not this uv-managed environment. Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com> Signed-off-by: oliver könig <okoenig@nvidia.com>
|
Auto-sync is disabled for draft pull requests in this repository. Workflows must be run manually. Contributors can view more details about this message here. |
ko3n1g
added
area:build
…fw_final The fw_final 'Address CVE' block pins packages in the system interpreter (/usr/local/lib/python3.12/dist-packages). Two of those pins are now flagged by the same scan: - starlette==0.49.1 -> 1.3.1 (GHSA-82w8-qh3p-5jfq, GHSA-wqp7-x3pw-xc5r) - tornado==6.5.5 -> 6.5.6 (GHSA-mgf9-4vpg-hj56, AsyncHTTPClient gzip-bomb DoS) This is the system-level counterpart to the uv-managed /opt/venv starlette bump in the previous commit; both installs are flagged separately by the scanner. Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com> Signed-off-by: oliver könig <okoenig@nvidia.com>
ko3n1g
changed the title
Contributor
Author
|
/ok to test |
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Background / motivation
The
26.06.rc8NeMo FW container scan flagged three High-severity CVEs across two Python installs in the image:starletterequest.form()size limits silently ignored → DoS1.3.1starletteStaticFilesUNC-path SSRF / NTLM theft (Windows-only)1.1.0tornadoAsyncHTTPClientaccumulates decompressed chunks without limit (gzip bomb) → DoS6.5.6Both starlette CVEs are patched only in the
1.xline (no0.xbackport).The scan's Package Location column splits these across the two installs the image carries, and both are owned by this repo's Docker build:
/opt/venv/.../site-packages— the uv-managed install (uv.lock):starlette 0.52.1./usr/local/lib/python3.12/dist-packages— the system interpreter, pinned indocker/Dockerfile.fw_final's "Address CVE" block:starlette 0.49.1,tornado 6.5.5.What changed
uv-managed (
/opt/venv):starlette>=1.3.1via[tool.uv] override-dependencies(transitive — pulled byfastapi,mlflow-skinny,prometheus-fastapi-instrumentator,sphinx-autobuild).prometheus-fastapi-instrumentator7.0.0 → 8.0.0(its 7.x line capsstarlette<1.0.0; 8.x requires>=1.0.0).uv.lock:starlette 0.52.1 → 1.3.1,prometheus-fastapi-instrumentator 7.0.0 → 8.0.0. No other packages change.system interpreter (
/usr/local/lib/.../dist-packages),docker/Dockerfile.fw_final:starlette==0.49.1 → 1.3.1tornado==6.5.5 → 6.5.6Details
override-dependenciespattern (urllib3>=2.6.3,langchain>=0.3.28, …).fastapi(>=0.46.0),mlflow-skinny(<2) andsphinx-autobuild(>=0.35) already permitstarlette 1.x; onlyprometheus-fastapi-instrumentatorhad to move with it.tornadois an explicit pin there (not just awandb[launch]transitive), so it has to be bumped directly.Tested
uv lock --upgrade-package starlette --upgrade-package prometheus-fastapi-instrumentator(run in container) resolved 349 packages cleanly, no rebuilds:Updated starlette v0.52.1 -> v1.3.1Updated prometheus-fastapi-instrumentator v7.0.0 -> v8.0.0starlette==1.3.1andtornado==6.5.6confirmed present on PyPI.pre-commitclean on changed files.starlette0.x→1.x major boundary, so the build/functional jobs are the real check thatfastapi/vllm/instrumentator paths still import cleanly).