AWS Updates GluonTS for Unsafe Model Deserialization
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.
Last verified: October 2, 2026 UTC against AWS and the GluonTS project advisory. No model was loaded.
Scope And Authority
| Product scope | Amazon GluonTS before 0.17.0 |
|---|---|
| Advisory | 2026-119-AWS |
| CVE | CVE-2026-100308 |
| Authoritative release date | 2026-09-29 15:00:00 UTC |
| Authority revision date | 2026-09-29 15:00:00 UTC |
| Affected versions | Amazon GluonTS releases before 0.17.0 when applications deserialize model directories they do not fully control. |
| Fixed version | Amazon GluonTS 0.17.0 |
| CVSS base score | 7.8 (CVSS v3.1, GluonTS project advisory GHSA-64q6-5qv7-cwj9; the AWS bulletin does not print a score) |
| CVSS severity | High (GluonTS project advisory) |
| Exploitation status | Not 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
- Trace model loading. Identify applications calling the named deserialize methods, their Python environment/image and the origin and write permissions of model directories.
- 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.
- 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.
- 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.
- 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.

