Skip to content

Fix: Triton inference spec hmac exposure#5654

Open
pravali96 wants to merge 4 commits intoaws:masterfrom
pravali96:fix/triton-inference-spec-hmac-exposure
Open

Fix: Triton inference spec hmac exposure#5654
pravali96 wants to merge 4 commits intoaws:masterfrom
pravali96:fix/triton-inference-spec-hmac-exposure

Conversation

@pravali96
Copy link
Collaborator

@pravali96 pravali96 commented Mar 19, 2026

Issue #, if available:

Description of changes:
Security fixes for HMAC key exposure and missing integrity check in the Triton inference handler and all model server prepare paths.

Issue

Three security issues were identified in the sagemaker-serve package:

  1. Missing integrity check in Triton handler (CWE-502): triton/model.py deserialized serve.pkl via cloudpickle.load() with no integrity verification before execution. A # TODO comment at line 32 acknowledged this gap. All other handlers (TorchServe, MMS, TF Serving, SMD) already had this check.

  2. Hardcoded secret key for ONNX path (CWE-798): model_builder_utils.py set self.secret_key = "dummy secret key for onnx backend" in the Triton ONNX export path. This was passed as SAGEMAKER_SERVE_SECRET_KEY into container environment variables and exposed in plaintext via DescribeModel API. The ONNX path does not use pickle serialization, so no secret key is needed.

  3. HMAC secret key exposed via environment variables (CWE-200, CWE-522): All model server implementations injected the HMAC secret key as SAGEMAKER_SERVE_SECRET_KEY into container environment variables. These are returned in plaintext by DescribeModel, DescribeEndpointConfig, and DescribeModelPackage APIs, allowing any principal with read permissions to extract the key and forge valid integrity signatures for malicious pickle payloads.

Fix

Switch from HMAC-SHA256 (requires a secret key) to plain SHA-256 (no key needed), matching the approach taken for CVE-2026-1777 (PR #5348/#5379) which made the same change for the remote function path.

Changes

check_integrity.py

  • Removed generate_secret_key() — no longer needed
  • compute_hash() now uses hashlib.sha256() instead of hmac.new()
  • perform_integrity_check() no longer reads SAGEMAKER_SERVE_SECRET_KEY from environment

By submitting this pull request, I confirm that you can use, modify, copy, and redistribute this contribution, under the terms of your choice.

Pravali Uppugunduri added 2 commits March 19, 2026 20:54
The ONNX export path in _prepare_for_triton() set self.secret_key to a
hardcoded value 'dummy secret key for onnx backend'. This key was then
passed as SAGEMAKER_SERVE_SECRET_KEY into container environment variables
and exposed in plaintext via DescribeModel/DescribeEndpointConfig APIs.

The ONNX path does not use pickle serialization — models are exported to
.onnx format and loaded natively by Triton's ONNX Runtime backend. There
is no serve.pkl, no metadata.json, and no integrity check to perform.
The secret key was dead code that also constituted a hardcoded credential
(CWE-798).

With this change, self.secret_key remains empty string (set by
_build_for_triton), and the existing cleanup in _build_for_transformers
removes empty SAGEMAKER_SERVE_SECRET_KEY from env_vars before CreateModel.

Addresses: P400136088 (Bug 2 - Hardcoded secret key)
Addresses P400136088 Bug 1 and V2146375387 (Triton path).

Three changes:

1. check_integrity.py: Switch from HMAC-SHA256 to plain SHA-256.
   - Remove generate_secret_key() — no longer needed
   - compute_hash() now uses hashlib.sha256() instead of hmac.new()
   - perform_integrity_check() no longer reads SAGEMAKER_SERVE_SECRET_KEY
     from environment

2. triton/model.py: Add integrity check in initialize() BEFORE
   cloudpickle deserialization. Previously the handler called
   cloudpickle.load() with no verification (acknowledged by a TODO
   comment). Now reads the file into a buffer, runs
   perform_integrity_check(), then deserializes with cloudpickle.loads().

3. triton/server.py: Remove SAGEMAKER_SERVE_SECRET_KEY from container
   environment variables in both local and SageMaker deployment modes.
   The key is no longer needed since integrity checking uses plain
   SHA-256.

4. model_builder_utils.py: Update _hmac_signing() to use plain SHA-256
   and stop generating/storing a secret key. Remove generate_secret_key
   import.

The integrity check still detects accidental corruption of model
artifacts in S3. The HMAC was providing a false sense of security since
the key was exposed via DescribeModel/DescribeEndpointConfig APIs.
@pravali96 pravali96 force-pushed the fix/triton-inference-spec-hmac-exposure branch from 3b99611 to cb365fb Compare March 19, 2026 22:18
@pravali96 pravali96 force-pushed the fix/triton-inference-spec-hmac-exposure branch from 24f9bba to 30d0c21 Compare March 20, 2026 17:20
@pravali96 pravali96 changed the title Fix/triton inference spec hmac exposure Fix: Triton inference spec hmac exposure Mar 20, 2026
@pravali96 pravali96 force-pushed the fix/triton-inference-spec-hmac-exposure branch from 9e4d69c to 2db9ae8 Compare March 20, 2026 18:18
Remove generate_secret_key import and usage from TorchServe, MMS,
TF Serving, and SMD prepare functions. Switch compute_hash calls
from HMAC-SHA256 to plain SHA-256 (no secret_key parameter).

This is required because generate_secret_key was removed from
check_integrity.py in the previous commit. Without this change,
all model server imports fail with ImportError.
@pravali96 pravali96 force-pushed the fix/triton-inference-spec-hmac-exposure branch from 2db9ae8 to 8ecfe9d Compare March 20, 2026 19:34
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant