AWS warns that every Multi Model Server release is vulnerable, with no patch planned

What AWS disclosed

AWS published security bulletin 2026-148-AWS [1] on October 23. It covers Multi Model Server 1.1.11 and earlier, which means every public release is affected.

The bulletin describes two separate routes into a model-serving process. The first begins with a crafted model archive, and the second begins with a model URL supplied to the management interface.

AWS says the management interface does not require authentication. Deployments become much more exposed when that interface listens on a network address that untrusted callers can reach.

How a model archive can become code execution

The official CVE-2026-115812 record [2] describes relative path traversal during archive extraction. An archive can contain a path that escapes the intended extraction directory, which may let a remote attacker write files elsewhere and execute code with the privileges of the MMS process.

The record gives the flaw a CVSS 3.1 score of 9.8. Its vector says an attacker can reach it over a network, needs no prior privileges or user interaction, and can cause high confidentiality, integrity and availability impact.

The GitHub Advisory Database entry [5] independently carries the critical advisory and points users back to the AWS bulletin and CVE record.

The second flaw can reach internal services

The CVE-2026-115813 record [3] describes server-side request forgery in the model download path. A crafted model URL may make MMS send a request to an internal network destination.

Its CVSS 3.1 score is 5.8, but operators should assess the two flaws together. The same unauthenticated management surface accepts model-loading instructions, and access to internal destinations may reveal services that were never designed for outside callers.

The public records do not say that either flaw is being exploited. They also do not provide a public proof of concept, so exposure should be assessed from affected versions and reachable interfaces rather than exploit chatter.

Why there will be no normal patch cycle

The AWS repository [4] is archived and read-only. Its own production notes already state that MMS has no authentication and should run behind an authentication proxy and firewall.

AWS says the project reached end of life on November 20, 2025. The company does not plan to publish a fixed version through GitHub, PyPI or Docker Hub.

That changes the response decision. Pinning a newer MMS release cannot solve the problem because no such release exists. Teams need to retire the component, maintain and audit their own fork, or accept temporary network controls while they migrate.

What operators should do now

Start with inventory because the project may appear in old inference images, internal base images or derivative services even when nobody remembers choosing it directly. Record the package version, container image digest, listening addresses and callers for each deployment.

Treat network isolation as a temporary measure. AWS says the management interface can be bound to loopback when management and inference use separate ports, but that option is not available in every configuration. SageMaker-style configurations can place management and inference on the same port.

If you maintain a fork, reject an archive member whenever its normalized destination escapes the chosen extraction directory, and permit downloads only from approved URLs. Review the whole model-loading boundary rather than copying two checks without tests.

• Search source repositories, dependency manifests, image SBOMs and running processes for multi-model-server and the MMS CLI.
• Block the management port from the public internet and from untrusted internal networks.
• Stop accepting model archives or model URLs from untrusted callers.
• Rotate credentials available to the MMS process if an exposed deployment accepted untrusted models.
• Review filesystem changes, child processes, model-registration logs and outbound requests for unexpected activity.
• Choose a maintained replacement and test model packaging, handlers, metrics, autoscaling and rollback before switching traffic.
• Keep the old service isolated after cutover until incident review and data retention requirements are complete.

What is confirmed and what remains unknown

• Confirmed: every released MMS version through 1.1.11 is affected.
• Confirmed: CVE-2026-115812 can lead to code execution with the MMS process's privileges.
• Confirmed: CVE-2026-115813 can send requests to internal network destinations.
• Confirmed: AWS will not publish a fixed MMS release and recommends migration.
• Unknown: whether attackers are exploiting either vulnerability in production environments.
• Unknown: how many derivative images and forks still contain the vulnerable extraction and download code.
• Deployment-specific: the practical impact depends on interface reachability, process privileges, mounted files, network access and accepted model sources.

Frequently asked questions

• Is there a safe MMS version to upgrade to? No. AWS says all released versions are affected and no fixed release is planned.
• Is this limited to Amazon SageMaker? No. The advisory covers the open-source Multi Model Server. Teams should inspect self-hosted deployments, images and forks wherever they run.
• Does localhost binding remove the risk? It reduces remote reachability, but it does not repair archive extraction or URL validation. Other local processes and trusted callers may still supply unsafe input.
• Should teams wait for exploit code before acting? No. The critical flaw needs no authentication according to its CVSS vector, and the vendor recommends migration.
• Can a firewall replace migration? It can reduce exposure while teams move, but AWS presents it as a workaround and says it is unavailable in some configurations.
• What should a replacement test include? Test model registration, archive handling, authentication, network egress, handler compatibility, observability, autoscaling and rollback under the same workload.