AWS Updates GluonTS for Unsafe Model Deserialization

P2 — VALIDATE AND UPDATEHigh · 7.8 (project CVSS v3.1)EXPLOITATION: NOT STATED

Quick Answer

GluonTS versions before 0.17.0 can execute commands when an application loads a crafted model directory it does not control. AWS identifies Predictor.deserialize() and RepresentablePredictor.deserialize() as entry points. The commands run with the model-loading process's privileges; this is a library update, not a claim that AWS automatically repaired every customer environment.

Confirm Scope And Apply The Supported Fix

What to do now: update the GluonTS installation used by each notebook, training/inference worker or deployment image to a supported release containing the 0.17.0 fix. Track forks separately and accept model directories only from trusted, controlled sources. Do not load a suspect artifact to inspect whether it is malicious.

Open the authoritative advisory

Last verified: October 2, 2026 UTC against AWS and the GluonTS project advisory. No model was loaded.

Scope And Authority

Product scopeAmazon GluonTS before 0.17.0
Advisory2026-119-AWS
CVECVE-2026-100308
Authoritative release date2026-09-29 15:00:00 UTC
Authority revision date2026-09-29 15:00:00 UTC
Affected versionsAmazon GluonTS releases before 0.17.0 when applications deserialize model directories they do not fully control.
Fixed versionAmazon GluonTS 0.17.0
CVSS base score7.8 (CVSS v3.1, GluonTS project advisory GHSA-64q6-5qv7-cwj9; the AWS bulletin does not print a score)
CVSS severityHigh (GluonTS project advisory)
Exploitation statusNot stated by the authority; no exploitation claim is inferred.

What Changed

The GluonTS project advisory rates CVE-2026-100308 High, with a CVSS v3.1 score of 7.8. AWS also calls for derivative and forked code to incorporate the fix. Updating a base Python environment does not establish the version in a different virtual environment or a previously built worker image.

What To Validate Now

  1. Trace model loading. Identify applications calling the named deserialize methods, their Python environment/image and the origin and write permissions of model directories.
  2. Update the actual runtime. Apply the supported GluonTS fix through that deployment's dependency process; rebuild images and restart long-running workers as required. Preserve dependency and artifact identities for recovery.
  3. Review forks and artifact trust. Confirm derivative code includes the security changes. Restrict accepted artifacts to controlled sources even after patching; a filename or claimed model type is not provenance.
  4. Test a known-good model. In the approved test environment, load a trusted existing artifact and run representative forecast inputs. Check expected outputs and compatibility without claiming this exercises an exploit.
  5. Retain the right evidence. Keep active runtime version, image/lockfile identity, trusted artifact identity and test result. Investigate suspicious earlier loads separately from the package update.

Operational Cautions

Model loading can cross a code-execution trust boundary. Run workers with only the filesystem, credential and network access their job requires, and do not deserialize unknown artifacts under a privileged account. Operational isolation reduces impact; it does not replace the library fix or establish that an earlier load was harmless.

Evidence To Retain

  • Exact product, release stream, package or application version, enabled feature, environment, and accountable owner.
  • UTC timestamps, authority revision, approved change record, installer or package-manager output, and resulting version.
  • Relevant logs and monitoring evidence, test results, exceptions, compensating controls, and rollback decisions.

Related TechGeeks Resources

Authoritative References

Correction policy: If the authority changes affected versions, fixed versions, severity, exploitation information, mitigations, or required action, TechGeeks will update this notice and its verification date.