CVE-2026-8597

What it actually does

This is a deserialization flaw in the Triton inference handling path of the Amazon SageMaker Python SDK. SDK versions before 2.257.2 in the v2 line and before 3.8.0 in the v3 line did not adequately verify the integrity of model artifacts loaded from S3. A remote authenticated attacker who already has write access to the S3 location used for a SageMaker model artifact can replace that artifact with a crafted pickle payload. When the affected inference container loads and deserializes the modified artifact, attacker-controlled code can execute inside the inference container context. The vulnerability does not provide initial access by itself; it depends on compromised or overly permissive S3 write privileges to the model artifact path.

Why it matters to the business

Successful exploitation can turn write access to a model artifact bucket into code execution inside production or development inference containers. This can disrupt model serving, alter inference behavior, expose data available to the container, steal credentials or tokens accessible from the runtime, and potentially provide a foothold for further movement within the cloud environment depending on the container role and network access. The CVSS score is high and the attack complexity is low once S3 write access exists, but current public exploitation signals are limited: it is not listed in CISA KEV, is not associated with ransomware use, has no reported exploit maturity, and has a low EPSS score. Organizations using SageMaker ModelBuilder with Triton models should still prioritize remediation because compromised CI/CD, data science, or storage credentials could make the prerequisite S3 write access realistic.

How an attack unfolds

An attacker first obtains authenticated AWS credentials or an IAM role that can write to the S3 path containing a SageMaker Triton model artifact created with an affected version of the SageMaker Python SDK. The attacker identifies the model artifact used by a SageMaker endpoint, batch transform job, or deployment workflow. They then replace or overwrite the artifact, or a component inside it, with a malicious pickle payload designed to execute code during deserialization. When the vulnerable Triton inference container starts, reloads, or otherwise processes the model artifact, the handler deserializes the untrusted pickle content without sufficient integrity verification. The payload executes inside the inference container, allowing the attacker to run commands with the permissions and network access available to that container. From there, the attacker may attempt to read environment variables, access mounted files, query instance metadata or cloud credentials where reachable, alter inference outputs, or establish persistence through modified model artifacts or deployment automation.

How to fix it

Upgrade the Amazon SageMaker Python SDK to a fixed version: v2.257.2 or later for SDK v2, or v3.8.0 or later for SDK v3. Rebuild any Triton models previously created with ModelBuilder using the updated SDK; upgrading the local package alone is not sufficient for already-built vulnerable artifacts. Redeploy affected SageMaker endpoints, batch transform jobs, pipelines, or model packages so they use rebuilt artifacts. Rotate or review IAM credentials that had write access to model artifact S3 paths, especially if there is evidence of unauthorized object modification. Apply least privilege to S3 model artifact locations: restrict write permissions, separate build-time and runtime roles, enable S3 versioning and object lock where appropriate, and require controlled deployment pipelines for model artifact updates. Consider adding integrity controls such as artifact signing, checksum validation, immutable release buckets, and CI/CD enforcement that only trusted build systems can publish model artifacts.

How to confirm the fix worked

Confirm all build and deployment environments use Amazon SageMaker Python SDK v2.257.2 or later, or v3.8.0 or later, by checking package manifests, lock files, container images, and notebook environments. Verify that all Triton models created with ModelBuilder before the upgrade have been rebuilt and redeployed using the fixed SDK. Review SageMaker model definitions and deployment artifacts to confirm they reference newly generated S3 objects rather than legacy artifacts. Validate S3 controls by confirming only approved build roles can write to model artifact prefixes and that inference/runtime roles do not have unnecessary write access. Test by redeploying a rebuilt Triton model in a non-production environment and confirming normal startup without using legacy artifacts. Where S3 versioning is enabled, compare the active object version against the expected artifact hash or build provenance record.

Typical attack path

1. Obtain AWS credentials or an assumed role with write access to the S3 prefix that stores SageMaker model artifacts.
2. Identify a Triton model artifact created with SageMaker ModelBuilder using Amazon SageMaker Python SDK v2 before 2.257.2 or v3 before 3.8.0.
3. Prepare a malicious pickle payload embedded in or substituted for the expected model artifact content.
4. Overwrite, copy over, or otherwise replace the model artifact in S3.
5. Wait for or trigger an endpoint deployment, container restart, model reload, batch transform job, or other workflow that causes the inference container to read the artifact.
6. The vulnerable handler deserializes the crafted pickle payload without integrity verification.
7. Attacker-controlled code executes inside the inference container.
8. Use the container context to inspect data, credentials, runtime configuration, network access, or to tamper with model behavior.

How to detect it

Look for evidence that SageMaker model artifacts were modified outside expected build or deployment workflows. Primary log sources are AWS CloudTrail management events, CloudTrail S3 data events for model artifact buckets, S3 server access logs, SageMaker endpoint and model deployment events, CI/CD audit logs, IAM role assumption logs, and CloudWatch logs from SageMaker inference containers. Hunt for writes to model artifact objects shortly before endpoint creation, update, restart, or batch transform execution, especially by unusual users, access keys, roles, IP addresses, user agents, or outside normal release windows. Investigate S3 object version history for overwritten model archives or unexpected metadata changes. In inference container logs, look for abnormal startup errors, deserialization exceptions, unexpected shell or interpreter execution, outbound network connections, credential access attempts, or inference behavior changes after an artifact update. Because pickle payloads can vary widely, detection should focus on unauthorized artifact modification, anomalous container behavior after artifact load, and unexpected IAM activity by principals with S3 write access.

• eventName=PutObject
• eventName=CopyObject
• eventName=CompleteMultipartUpload
• eventName=DeleteObject
• eventName=DeleteObjectVersion
• eventName=PutObjectAcl
• eventName=PutObjectTagging
• eventName=CreateModel
• eventName=UpdateEndpoint
• eventName=CreateEndpointConfig
• eventName=CreateTransformJob
• model.tar.gz
• tar.gz
• pickle
• pickle.loads
• cPickle.loads
• _pickle.loads
• __reduce__
• __reduce_ex__
• /opt/ml/model
• /opt/ml/model/model.tar.gz
• /opt/ml/code
• /opt/ml/input/data
• sagemaker-triton
• tritonserver
• python -c
• /bin/sh -c
• /bin/bash -c
• curl http://
• wget http://
• 169.254.169.254
• AWS_CONTAINER_CREDENTIALS_RELATIVE_URI
• AWS_ACCESS_KEY_ID

What your security team should do

• Inventory SageMaker Triton models and identify any artifacts created with SageMaker Python SDK v2 before 2.257.2 or v3 before 3.8.0.
• Upgrade SageMaker Python SDK installations to v2.257.2 or later, or v3.8.0 or later, across notebooks, CI/CD runners, training/build containers, and deployment automation.
• Rebuild and redeploy all previously created Triton ModelBuilder artifacts using the fixed SDK.
• Audit S3 write permissions to model artifact buckets and remove broad write access from users, notebooks, runtime roles, and third-party integrations.
• Review CloudTrail and S3 data events for unexpected PutObject, CopyObject, DeleteObject, DeleteObjectVersion, CompleteMultipartUpload, or object version changes affecting model artifact paths.
• Enable or confirm S3 versioning, server-side encryption, access logging, and alerting for model artifact buckets.
• Rotate credentials and investigate associated activity for any principal that made suspicious writes to model artifact locations.
• Implement artifact provenance controls such as checksums, signed artifacts, approval gates, and immutable release prefixes.
• Prioritize remediation based on exposure: production endpoints, internet-adjacent inference workflows, artifacts writable by multiple teams, and roles with broad downstream permissions should be addressed first.