CVE-2026-8596

What it actually does

The flaw exposes an HMAC signing key associated with SageMaker ModelBuilder/Serve-generated model artifacts in SageMaker API responses. A remote authenticated actor who can call relevant SageMaker describe APIs and can write to the S3 location that stores the model artifact can recover the key, modify or replace the artifact, generate a valid integrity signature, and cause the modified artifact to be accepted by the serving workflow. Because SageMaker inference containers load and execute code packaged with model artifacts, a successfully forged artifact can result in code execution inside the inference container. The issue affects Amazon SageMaker Python SDK versions before 2.257.2 and v3 versions before 3.8.0, and models previously built with vulnerable ModelBuilder versions may remain risky until rebuilt with a fixed SDK.

Why it matters to the business

An attacker with elevated but plausible cloud permissions could tamper with machine-learning model packages and run unauthorized code in inference workloads. This can lead to theft of model data or secrets available to the container, manipulation of inference behavior, disruption of ML services, and lateral movement using the runtime role or connected cloud resources. The issue is not currently listed in CISA KEV, has no known public exploit maturity, and has a low EPSS score, but the impact is high where SageMaker model artifact paths are writable by users or automation that also have SageMaker describe permissions.

How an attack unfolds

An attacker first obtains authenticated access with permissions to call SageMaker describe APIs for ModelBuilder/Serve-created resources. They query the affected SageMaker APIs and extract the exposed HMAC signing key from the response data. The attacker then prepares a modified model artifact, potentially embedding malicious inference code or startup logic, and uploads it to the S3 path used by the affected model artifact. Using the recovered key, they generate a valid integrity signature so the tampered artifact appears legitimate to the serving workflow. When the model is deployed, updated, or otherwise loaded by SageMaker inference infrastructure, the container accepts and unpacks the artifact, causing the attacker's code to execute within the inference container context.

How to fix it

Upgrade the Amazon SageMaker Python SDK to version 2.257.2 or later for v2 deployments, or version 3.8.0 or later for v3 deployments. Rebuild any models previously created with ModelBuilder using the updated SDK; upgrading the library alone may not remediate already-created artifacts or metadata that were generated by vulnerable versions. Rotate or invalidate any exposed signing material where feasible, replace affected model artifacts, and redeploy endpoints from newly built artifacts. Review IAM permissions so users and automation do not simultaneously have broad SageMaker describe permissions and write access to production model artifact S3 paths unless required. Restrict S3 writes to artifact prefixes, enable S3 versioning and object lock where appropriate, and require controlled CI/CD pipelines for model artifact publication. If immediate upgrade is not possible, mitigate by removing unnecessary SageMaker describe permissions, blocking direct writes to model artifact locations, and redeploying only from trusted, verified artifact build processes.

How to confirm the fix worked

Confirm installed package versions with package inventory tooling, dependency manifests, build logs, or commands such as `pip show sagemaker`; vulnerable deployments use Amazon SageMaker Python SDK versions earlier than 2.257.2 in the v2 line or earlier than 3.8.0 in the v3 line. Verify that all ModelBuilder-created models have been rebuilt with the fixed SDK rather than merely redeployed from old artifacts. Review SageMaker model metadata and API responses in a non-production validation workflow to ensure HMAC signing material is no longer returned. Confirm S3 model artifact paths are not writable by broad developer, notebook, or runtime roles. Validate that production endpoints, batch jobs, and model packages reference newly generated artifact objects and not legacy object versions. Finally, run a controlled deployment test from a rebuilt artifact and confirm the serving container starts successfully without relying on legacy signatures or metadata.

Typical attack path

1. Gain authenticated cloud access with sufficient SageMaker describe permissions and S3 write access to the model artifact location.
2. Enumerate SageMaker models or ModelBuilder/Serve resources and identify artifacts created with an affected SageMaker Python SDK version.
3. Call SageMaker describe APIs and recover the exposed HMAC signing key from API response data.
4. Download or recreate the target model artifact and modify it to include malicious code or altered inference behavior.
5. Upload the crafted artifact to the S3 model artifact path or overwrite an existing artifact version where permitted.
6. Forge a valid integrity signature using the exposed HMAC key.
7. Trigger or wait for model deployment, endpoint update, batch transform, or container restart that causes the artifact to be loaded.
8. Achieve code execution inside the SageMaker inference container and use the container's permissions, network access, and mounted data to continue the attack.

How to detect it

Retrospective detection should focus on correlating cloud control-plane activity, S3 object changes, and inference-container behavior because extraction of the HMAC key from an API response may not be logged directly. Review CloudTrail for SageMaker Describe* activity against ModelBuilder/Serve-created resources, especially from principals, IP addresses, sessions, or automation that do not normally inspect model metadata. Correlate those events with S3 PutObject, CopyObject, CompleteMultipartUpload, DeleteObject, or object-version changes against model artifact paths, particularly files such as model.tar.gz or other model package archives. Look for subsequent CreateModel, UpdateModel, CreateEndpointConfig, UpdateEndpoint, CreateTransformJob, or endpoint restart activity that would cause a changed artifact to be loaded. In S3, compare object versions, ETags, sizes, timestamps, and server access logs for unexpected overwrites or uploads. In SageMaker and container logs, hunt for abnormal startup behavior, shell execution, package installation, unexpected network egress, access to credentials endpoints, or inference code paths that differ from approved builds. If threat hunting finds a suspicious describe-to-S3-write-to-deploy sequence, preserve CloudTrail, S3 object versions, container logs, and build artifacts for forensic comparison.

• eventName":"DescribeModel"
• eventName":"DescribeModelPackage"
• eventName":"DescribeEndpointConfig"
• eventName":"DescribeEndpoint"
• eventName":"CreateModel"
• eventName":"UpdateEndpoint"
• eventName":"CreateEndpointConfig"
• eventName":"CreateTransformJob"
• eventName":"PutObject"
• eventName":"CopyObject"
• eventName":"CompleteMultipartUpload"
• eventName":"DeleteObject"
• eventSource":"sagemaker.amazonaws.com"
• eventSource":"s3.amazonaws.com"
• model.tar.gz
• ModelBuilder
• Serve
• sagemaker<2.257.2
• sagemaker<3.8.0

What your security team should do

• Prioritize upgrading Amazon SageMaker Python SDK to 2.257.2 or later, or v3.8.0 or later, across notebooks, build systems, CI/CD runners, and ML development images.
• Inventory SageMaker models created with ModelBuilder/Serve and rebuild those artifacts with a fixed SDK before redeploying them.
• Identify principals that have both SageMaker describe permissions and S3 write access to model artifact prefixes; remove or separate those privileges where possible.
• Enable or review CloudTrail data and management events for SageMaker and S3 so describe calls, artifact writes, and endpoint updates can be correlated.
• Search historical logs for unusual sequences of SageMaker Describe* calls followed by S3 PutObject or CopyObject activity against model artifact locations and subsequent endpoint updates.
• Use S3 versioning, artifact immutability, signed CI/CD publishing, and approval gates to prevent direct overwrite of production model artifacts.
• Rotate related secrets and redeploy affected endpoints if suspicious artifact modification or unexplained inference-container behavior is found.
• Monitor inference container logs for unexpected process execution, outbound connections, dependency installation, shell invocation, or changes in inference output behavior.