AWS warns of critical flaw in retired Multi Model Server; no patch will ship

Amazon Web Services (AWS) disclosed on October 23, 2026, that every released version of Multi Model Server (MMS), its open-source tool for serving machine-learning models, contains a critical flaw (CVE-2026-115812, CVSS 9.8) that can let an attacker run code on the server by feeding it a crafted model file. MMS is end of life and AWS will not ship a fix. If you run MMS yourself, including inside containers built on the SageMaker Inference Toolkit, keep its ports away from untrusted callers now and plan a migration.

What happened, in plain English

Once a machine-learning (ML) model is trained, something has to "serve" it: load it into memory and answer requests such as "classify this image" over HTTP. Multi Model Server is one of those serving tools. AWS published it on GitHub, PyPI (the Python Package Index) and Docker Hub, and it is the serving stack underneath the AWS SageMaker Inference Toolkit, which people use to build their own model containers. The project was archived, read-only, on November 20, 2025 — the SageMaker Inference Toolkit repository was archived the same day — and MMS's last stable release, 1.1.11, dates from June 2023.

MMS has two interfaces: an inference API that answers predictions, and a management API used to load and unload models. Models arrive as archive files that MMS unpacks into a folder. According to AWS, MMS does not properly check the file paths inside those archives. A crafted archive can contain entries that point outside the intended folder, a weakness called path traversal, so unpacking it writes files elsewhere on the server. That can lead to code running with the privileges of the MMS process.

An analogy: a warehouse worker who unpacks every delivery box and puts each item exactly where its label says, even when a label reads "put me in the manager's office."

A second, lower-severity flaw (CVE-2026-115813, CVSS 5.8) lets the model download feature be pointed at unintended network destinations, a server-side request forgery (SSRF).

The aggravating factor: the MMS management interface has no authentication at all. Anyone who can reach it can tell it to load a model.

Are you affected? What to do now

You are affected if you run Multi Model Server yourself, at any version (AWS lists 1.1.11 and earlier, which is every release), or a container image that includes it. Most readers will not have it: it is an older tool, originally built around MXNet and ONNX models. The AWS bulletin does not say that any managed AWS service is affected, and it does not list any as unaffected. If your team does not deploy custom model-serving containers, there is likely nothing to do.

Check

• Search your Python environments and images for the package: pip show multi-model-server, or look for multi-model-server in requirements files, lock files and Dockerfiles.
• Look for the SageMaker Inference Toolkit (sagemaker-inference), which installs MMS as its serving stack. Custom SageMaker containers built on it are in scope.
• Find where MMS listens. In its config.properties (or the file named by MMS_CONFIG_FILE), check inference_address and management_address. The documented defaults are 127.0.0.1:8080 and 127.0.0.1:8081, meaning localhost only. Any 0.0.0.0 or external address means the management API is reachable from the network.
• Check who can reach those ports: security groups, firewall rules, load balancers, Kubernetes services.

Act, in this order

• Restrict access now. Limit the serving port to the specific callers that need it. Nothing on the internet should be able to reach an MMS port.
• If inference and management run on separate ports, bind management to the loopback address, as AWS recommends, and do not pass external URLs to the model download path.
• If you use the configuration shipped for SageMaker-style deployments, know that AWS says it binds management to all addresses on the same port as inference, and that management cannot be moved to loopback there without disabling model loading. AWS advises prioritising migration and, until then, limiting the serving port to trusted callers.
• Only load model archives you built yourself, from storage that only your pipeline can write to.
• Plan the migration to a supported model-serving solution. AWS does not name a replacement in the bulletin.
• If an MMS management port was ever exposed, review the server for unexpected files and models, and treat any credentials available to that host or container, such as cloud roles and API keys, as possibly exposed.

AWS has published no indicators of compromise, and as of November 5, 2026, we found no public proof-of-concept and no listing in the CISA (US Cybersecurity and Infrastructure Security Agency) Known Exploited Vulnerabilities catalog.

The expert view

Root cause. CVE-2026-115812 is a classic archive-extraction bug (CWE-23, relative path traversal), often called "Zip Slip": the extractor trusts the member names inside an archive and joins them to a destination directory without confirming that the result stays inside it. It is a well-known class, and model servers are a natural home for it, because their core job is to accept a packaged artefact and unpack it.

Attack chain, conceptually. The attacker needs MMS to unpack an archive they control. The unauthenticated management API, whose whole purpose is registering new models, provides that path to anyone who can reach it. A write outside the extraction folder then becomes code execution by overwriting something the server or its runtime will later load or execute. CVE-2026-115813 adds a second primitive on the same interface: making the server fetch from internal addresses. In cloud environments that class of flaw is often used to probe internal services. The bulletin describes outcomes, not exploitation details, and none are needed to act.

Why the defences failed. MMS's own documentation says it has no built-in authentication and recommends an authentication proxy and a firewall in front of it. Its defaults are sensible: both APIs bind to localhost. The weak point is the deployment pattern AWS itself flags, where inference and management share one network-facing port. In that layout, anyone allowed to send predictions can also load models, and network isolation is the only control left.

Severity in context. AWS, as the CVE Numbering Authority, scores it 9.8 under CVSS 3.1 (AV:N/AC:L/PR:N/UI:N) and 9.3 under CVSS 4.0. That is fair for an MMS with a reachable management interface. For a localhost-bound default install, practical risk is much lower, because the attacker first needs network access or another foothold. The rating is less important than the end-of-life status: no patch will ever ship, so any remaining deployment is permanent exposure unless it is retired or isolated.

The broader trend. This fits a pattern we keep seeing across ML infrastructure: serving and loading layers that were built for trusted internal networks, treat model artefacts as trusted input, and stay deployed long after maintenance ends. A model archive is code-adjacent content. It deserves the same provenance checks and least-privilege handling as a software package. AWS also asks maintainers of MMS forks to reject archive entries that resolve outside the extraction directory and to allowlist download URLs, a reminder that forked code inherits bugs silently.

Still unknown. How many MMS deployments remain in production; which, if any, AWS-provided container images still ship MMS (the bulletin does not list them); whether forks of MMS carry the same extraction code; and whether either flaw has been exploited. The researcher credited, Sujal Tuladhar, had not published a write-up we could find as of November 5, 2026.

Official sources

• AWS Security Bulletin 2026-148-AWS — CVE-2026-115812 and CVE-2026-115813, Multi Model Server (October 23, 2026)
• CVE-2026-115812 — CVE record (CNA: Amazon; CVSS 3.1 9.8, CVSS 4.0 9.3)
• CVE-2026-115813 — NVD entry
• awslabs/multi-model-server — archived repository and security notes
• Multi Model Server configuration documentation (default addresses and ports)
• aws/sagemaker-inference-toolkit — "serving stack is built on Multi Model Server" (archived)
• multi-model-server on PyPI (release history)
• Coverage: The Hacker Wire — CVE-2026-115812 analysis