CVE-2024-6577: PyTorch unverified S3 bucket exposes

Q: Is CVE-2024-6577 actively exploited?

Proof-of-concept exploit code is publicly available for CVE-2024-6577, increasing the risk of exploitation.

Q: How to fix CVE-2024-6577?

1. Immediately audit all TorchServe deployments to determine if `upload_results_to_s3.sh` runs in any automated pipeline. 2. Disable or remove the script if benchmarking uploads are not operationally required. 3. If the script must run, redirect it to an internally-owned, access-controlled S3 bucket under your AWS account. 4. Block outbound S3 traffic to `s3://benchmarkai-metrics-prod` at egress firewall or VPC endpoint policy level. 5. Review IAM roles assigned to TorchServe workloads — apply least privilege and revoke any S3 PutObject permissions not explicitly needed. 6. Enable CloudTrail and alert on unexpected S3 PutObject calls to external buckets from ML workload accounts. No upstream patch available; monitor the torchserve GitHub for a fix.

Q: What systems are affected by CVE-2024-6577?

This vulnerability affects the following AI/ML architecture patterns: model serving, MLOps CI/CD pipelines, benchmarking infrastructure, training pipelines.

Q: What is the CVSS score for CVE-2024-6577?

CVE-2024-6577 has a CVSS v3.1 base score of 6.3 (MEDIUM). The EPSS exploitation probability is 0.36%.

CISO Take

TorchServe's benchmarking script uploads performance metrics to an S3 bucket without verifying ownership — if that bucket is unclaimed, an adversary can register it and silently receive your model benchmark telemetry. Audit whether your TorchServe deployments execute this script in any automated pipeline and block outbound access to `benchmarkai-metrics-prod` at the network layer immediately. Risk is low for standard inference workloads but meaningful for teams running automated benchmarking in CI/CD.

What is the risk?

Medium risk in practice. EPSS of 0.00113 reflects very low current exploitation probability — the attack requires an adversary to have pre-claimed the specific S3 bucket name, limiting opportunistic exploitation. However, any organization running TorchServe benchmark scripts is silently leaking operational data to a potentially adversary-controlled endpoint with no error or alert. No official patch is available for torchserve <= 0.11.0, making workarounds the only remediation path.

What systems are affected?

Package	Ecosystem	Vulnerable Range	Patched
PyTorch	pip	<= 0.11.0	No patch
100.9K OpenSSF 6.4 22.7K dependents Pushed 3d ago 11% patched ~216d to patch Full package profile →

Do you use PyTorch? You're affected.

How severe is it?

CVSS 3.1

6.3 / 10

EPSS

0.4%

chance of exploitation in 30 days

Higher than 28% of all CVEs

Source: EPSS v3 — FIRST.org

Exploitation Status

Exploit Available

Exploitation: MEDIUM

Sophistication

Trivial

Exploitation Confidence

medium

○ CISA SSVC: Public PoC

○ Public PoC indexed (trickest/cve)

Composite signal derived from CISA KEV, VulnCheck KEV, CISA SSVC, EPSS, Metasploit, Exploit-DB, trickest/cve, Nuclei templates, and inthewild.io exploitation reports.

What is the attack surface?

AV Network

AC Low

PR None

UI Required

S Unchanged

C Low

I Low

A Low

What should I do?

6 steps

Immediately audit all TorchServe deployments to determine if upload_results_to_s3.sh runs in any automated pipeline.
Disable or remove the script if benchmarking uploads are not operationally required.
If the script must run, redirect it to an internally-owned, access-controlled S3 bucket under your AWS account.
Block outbound S3 traffic to s3://benchmarkai-metrics-prod at egress firewall or VPC endpoint policy level.
Review IAM roles assigned to TorchServe workloads — apply least privilege and revoke any S3 PutObject permissions not explicitly needed.
Enable CloudTrail and alert on unexpected S3 PutObject calls to external buckets from ML workload accounts. No upstream patch available; monitor the torchserve GitHub for a fix.

What does CISA's SSVC say?

Decision Track*

Exploitation poc

Automatable No

Technical Impact partial

Source: CISA Vulnrichment (SSVC v2.0). Decision based on the CISA Coordinator decision tree.

How is it classified?

Supply Chain Data Leakage Data Extraction Framework Inference AML.T0010.001 - AI Software AML.T0025 - Exfiltration via Cyber Means AML.T0055 - Unsecured Credentials

Which compliance frameworks are affected?

This CVE is relevant to:

EU AI Act

Art. 15 - Accuracy, robustness and cybersecurity

ISO 42001

A.6.1.2 - AI system supply chain A.9.4 - Data security and privacy controls

NIST AI RMF

GOVERN 1.6 - Policies and procedures for third-party AI risks MANAGE 2.2 - Risk response for identified AI risks

Frequently Asked Questions

What is CVE-2024-6577?

TorchServe's benchmarking script uploads performance metrics to an S3 bucket without verifying ownership — if that bucket is unclaimed, an adversary can register it and silently receive your model benchmark telemetry. Audit whether your TorchServe deployments execute this script in any automated pipeline and block outbound access to `benchmarkai-metrics-prod` at the network layer immediately. Risk is low for standard inference workloads but meaningful for teams running automated benchmarking in CI/CD.

Is CVE-2024-6577 actively exploited?

Proof-of-concept exploit code is publicly available for CVE-2024-6577, increasing the risk of exploitation.

How to fix CVE-2024-6577?

1. Immediately audit all TorchServe deployments to determine if `upload_results_to_s3.sh` runs in any automated pipeline. 2. Disable or remove the script if benchmarking uploads are not operationally required. 3. If the script must run, redirect it to an internally-owned, access-controlled S3 bucket under your AWS account. 4. Block outbound S3 traffic to `s3://benchmarkai-metrics-prod` at egress firewall or VPC endpoint policy level. 5. Review IAM roles assigned to TorchServe workloads — apply least privilege and revoke any S3 PutObject permissions not explicitly needed. 6. Enable CloudTrail and alert on unexpected S3 PutObject calls to external buckets from ML workload accounts. No upstream patch available; monitor the torchserve GitHub for a fix.

What systems are affected by CVE-2024-6577?

This vulnerability affects the following AI/ML architecture patterns: model serving, MLOps CI/CD pipelines, benchmarking infrastructure, training pipelines.

What is the CVSS score for CVE-2024-6577?

CVE-2024-6577 has a CVSS v3.1 base score of 6.3 (MEDIUM). The EPSS exploitation probability is 0.36%.

What is the AI security impact?

Affected AI Architectures

model servingMLOps CI/CD pipelinesbenchmarking infrastructuretraining pipelines

MITRE ATLAS Techniques

AML.T0010.001 AI Software

AML.T0025 Exfiltration via Cyber Means

AML.T0055 Unsecured Credentials

Compliance Controls Affected

EU AI Act: Art. 15

ISO 42001: A.6.1.2, A.9.4

NIST AI RMF: GOVERN 1.6, MANAGE 2.2

What are the technical details?

Original Advisory

In the latest version of pytorch/serve, the script 'upload_results_to_s3.sh' references the S3 bucket 'benchmarkai-metrics-prod' without ensuring its ownership or confirming its accessibility. This could lead to potential security vulnerabilities or unauthorized access to the bucket if it is not properly secured or claimed by the appropriate entity. The issue may result in data breaches, exposure of proprietary information, or unauthorized modifications to stored data.

Exploitation Scenario

An adversary searches GitHub and public documentation, identifies that TorchServe's `upload_results_to_s3.sh` hardcodes the bucket name `benchmarkai-metrics-prod`. They attempt to register this bucket in their own AWS account — if unclaimed, they succeed immediately. Any organization running TorchServe benchmarking pipelines (common in MLOps CI/CD for performance regression gating) will then automatically upload benchmark results to the adversary's bucket. The adversary passively collects inference throughput, latency baselines, and hardware telemetry over time, building a reconnaissance profile of the target's AI serving infrastructure. This data can inform subsequent targeted attacks such as resource exhaustion, model extraction timing, or infrastructure-specific exploits.