CVE-2026-1778

What it actually does

The flaw causes the Amazon SageMaker Python SDK to disable TLS certificate verification for HTTPS requests made during Triton Python model import workflows. Because certificates are not validated, HTTPS connections that should fail when presented with invalid, expired, mismatched, or self-signed certificates can instead succeed. A network-positioned attacker who can intercept or redirect traffic could impersonate a trusted endpoint and tamper with model import responses, artifacts, or metadata in transit. The primary technical consequence is integrity compromise rather than direct service takeover: the attacker does not need credentials, but they generally need a privileged network position such as DNS control, proxy control, compromised routing, or access to an intercepting network path.

Why it matters to the business

Organizations using affected SageMaker Python SDK versions in machine learning build, deployment, or model-import pipelines may unknowingly trust data delivered by an attacker-controlled endpoint. This can lead to poisoned model artifacts, compromised ML workflows, incorrect predictions, leakage of workflow metadata, or deployment of untrusted code or dependencies associated with a Triton model import process. The CVSS score is moderate and EPSS is currently low, with no CISA KEV listing or known ransomware association, so broad opportunistic exploitation is less likely; however, the risk is higher in environments that run ML pipelines over untrusted networks, use outbound proxies, rely on private package or model registries, or permit dynamic model imports in automated CI/CD workflows. The supplied affected-product metadata appears inconsistent with the vulnerability description, so teams should verify exposure against the actual upstream package and advisory before closing remediation.

How an attack unfolds

An attacker first obtains a position that allows interception or redirection of HTTPS traffic from a system running an affected SageMaker Python SDK version. This could be achieved through malicious DNS responses, a compromised proxy, routing manipulation, a rogue wireless or corporate network position, or compromise of an internal endpoint that the workflow contacts. The victim then imports a Triton Python model using the vulnerable SDK path. During that import, the SDK makes HTTPS requests but does not properly validate the server certificate. The attacker presents a self-signed or otherwise invalid certificate and serves modified responses, model artifacts, configuration, or metadata. Because certificate validation is disabled, the client accepts the attacker-controlled HTTPS session. Depending on what the import workflow consumes, the attacker may be able to poison the model supply chain, alter deployment behavior, or introduce malicious model-side code or artifacts that execute later in the ML runtime or build process.

How to fix it

Upgrade the Amazon SageMaker Python SDK to a fixed version: use v2.256.0 or later for the 2.x branch, or v3.1.1 or later for the 3.x branch. Rebuild containers, notebooks, CI runners, training images, and deployment images that vendor or pin the SDK. Review dependency lockfiles and base images to ensure no older transitive or cached package remains. If the supplied product metadata is being used for asset matching, note that it lists open-formulieren/open-forms with commit f080250ed8ed773114d5e4675cae035eda53782e, which does not align with the SageMaker SDK description; validate against the authoritative upstream advisory and package inventory. As compensating controls until upgrades are complete, restrict outbound network access from ML build and deployment environments, require trusted egress proxies with certificate validation, pin allowed artifact/model endpoints, enforce DNS integrity, and avoid importing Triton Python models from untrusted or mutable sources.

How to confirm the fix worked

Confirm installed SDK versions using package inventories, dependency lockfiles, container image scans, and runtime checks such as `python -m pip show sagemaker` or `python -c "import sagemaker; print(sagemaker.__version__)"`. Exposure is present when the installed SageMaker Python SDK is earlier than 2.256.0 on the 2.x branch or earlier than 3.1.1 on the 3.x branch and the environment imports Triton Python models. Validate remediation by confirming all relevant execution environments report fixed versions and by rebuilding any pinned images or notebook kernels. Where safe, test that HTTPS connections made by the model import path reject a self-signed or invalid certificate. Also search source code and dependency overrides for local changes that disable certificate verification, such as `verify=False`, `ssl.CERT_NONE`, or urllib3 warning suppression.

Typical attack path

1. Identify an organization or workflow using an affected Amazon SageMaker Python SDK version before v2.256.0 or before v3.1.1.
2. Gain the ability to intercept or redirect outbound HTTPS traffic from the build, training, notebook, or deployment environment, such as through DNS, proxy, routing, or local network control.
3. Wait for or induce a Triton Python model import operation that triggers vulnerable SDK HTTPS requests.
4. Present an invalid, mismatched, expired, or self-signed TLS certificate while impersonating the expected remote endpoint.
5. Return attacker-controlled model artifacts, metadata, configuration, or responses over the accepted HTTPS connection.
6. Rely on the ML pipeline to consume the tampered content, potentially affecting model integrity, deployment behavior, or downstream execution.

How to detect it

Investigate whether affected environments performed Triton Python model imports while running vulnerable SageMaker Python SDK versions. Useful sources include Python package inventories, CI/CD logs, notebook execution logs, SageMaker training and processing job logs, container image build logs, egress proxy logs, DNS resolver logs, TLS inspection logs, VPC flow logs, endpoint protection telemetry, and model registry audit logs. Look for imports or deployments of Triton Python models that occurred over HTTPS sessions with self-signed, expired, hostname-mismatched, or otherwise invalid certificates; connections to unexpected model or artifact hosts; DNS responses pointing expected endpoints to unusual IP addresses; proxy CONNECT activity to unapproved destinations; and changes in model artifact hashes or metadata around the time of import. Because successful exploitation may not generate an application error, detection should focus on correlating vulnerable SDK usage, Triton import activity, network-path anomalies, and unexpected artifact changes. If threat hunting historical activity, compare imported model artifacts against known-good checksums, review commit/build provenance, and examine any model package code for unexpected additions.

• sagemaker<2.256.0
• sagemaker>=3.0.0,<3.1.1
• python -m pip show sagemaker
• import sagemaker; print(sagemaker.__version__)
• verify=False
• ssl.CERT_NONE
• ssl._create_unverified_context
• urllib3.disable_warnings
• InsecureRequestWarning
• CERTIFICATE_VERIFY_FAILED
• certificate verify failed
• self signed certificate
• self-signed certificate
• hostname mismatch
• Triton Python model
• triton_python_backend
• model.py
• config.pbtxt

What your security team should do

• Inventory all notebooks, training jobs, CI/CD pipelines, containers, model-serving images, and developer workstations that include the Amazon SageMaker Python SDK.
• Prioritize upgrades for environments that import Triton Python models, run automated model ingestion, or operate on networks where outbound traffic may traverse proxies or shared infrastructure.
• Upgrade to SageMaker Python SDK v2.256.0 or later, or v3.1.1 or later, and rebuild all dependent artifacts rather than only updating source repositories.
• Audit recent Triton Python model imports for unexpected source endpoints, altered artifacts, unusual hashes, or changes shortly before deployment.
• Harden ML supply-chain controls by requiring artifact checksums or signatures, restricting approved model registries, and preventing direct imports from untrusted locations.
• Review egress proxy, DNS, and TLS inspection logs for invalid certificate acceptance or connections to unexpected endpoints during model import windows.
• Treat the provided affected-product/fixed-version metadata as potentially inconsistent and validate package exposure using the authoritative SageMaker Python SDK version data.