AWS Won't Patch a CVSS 9.8 Bug in Multi Model Server. Its Management API Has No Login

• Book: Ship It — the pragmatic startup tech stack
• Also by me: Thinking in Go (2-book series) — Complete Guide to Go Programming + Hexagonal Architecture in Go
• My project: Hermes IDE | GitHub — an IDE for developers who ship with Claude Code and other AI coding tools
• Me: xgabriel.com | GitHub

---

On October 23, AWS published security bulletin 2026-148-AWS for two vulnerabilities in Multi Model Server (MMS), its open-source tool for serving ML models. Every released version (<=1.1.11) is affected, and the bulletin says "no fixed version is available or planned on any distribution channel."

The worse of the two, CVE-2026-115812, is rated 9.8 on CVSS 3.1 and 9.3 on CVSS 4.0, according to Strix's CVE record. AWS describes it as a flaw in model archive extraction: a crafted archive can write files outside the intended directory, which could lead to code execution with the privileges of the MMS process.

If you shipped a model on MMS a few years ago and never touched the container again, this one is yours to deal with. Nobody upstream is going to release 1.1.12.

What AWS disclosed

The bulletin covers two CVEs:

• CVE-2026-115812 — path traversal during model archive extraction. A crafted archive writes outside the extraction directory, with possible code execution as the MMS process (AWS). Strix lists it as CWE-23, relative path traversal.
• CVE-2026-115813 — an issue in the model download path that lets the management interface be directed to make requests to unintended network destinations (AWS). That is server-side request forgery, scored 5.8 on CVSS 3.1.

The detail that turns these from bad to urgent sits in one line of the bulletin: the MMS management interface does not require authentication, and deployments that bind it to a network-accessible address are at increased risk (AWS). Anyone who can reach that port can tell your server to load a model.

At the time of writing, there is no public proof of concept indexed and the CVE is not in CISA's Known Exploited Vulnerabilities catalog, per TheHackerWire and Strix. AWS says the issues came in through coordinated vulnerability disclosure.

CVE-2026-115812: a crafted model archive writes files outside the folder it was meant to unpack into.

Why there's no patch

MMS is end of life. Its GitHub repository was archived by its owner on November 20, 2025 and is read-only, and the bulletin confirms the end-of-life status (AWS). The package still installs from PyPI as multi-model-server, and AWS notes it was also published on Docker Hub.

It also lives one layer down in stacks that never name it. The SageMaker Inference Toolkit README says its "serving stack is built on Multi Model Server", and its own install line is pip3 install multi-model-server sagemaker-inference. That repository was archived on the same day, November 20, 2025. If your team built a custom inference container from that toolkit, MMS is in it.

Find out if you run it

Start with the code and the images. From the root of each repo that builds a model-serving container:

git grep -n -e multi-model-server \
  -e sagemaker-inference -e MMS_CONFIG_FILE

Inside a running container or virtualenv, ask pip directly:

pip show multi-model-server

Then check where the two APIs listen. MMS reads config.properties from MMS_CONFIG_FILE, then the --mms-config flag, then the working directory (MMS configuration docs):

grep -E '^(inference|management)_address' \
  config.properties

The defaults are http://127.0.0.1:8080 for inference and http://127.0.0.1:8081 for management, and the docs say MMS "only allows localhost access by default" (configuration docs). If management_address says 0.0.0.0, or the container publishes 8081, treat the server as exposed. An open inference address matters too when management shares its port, as in the SageMaker-style setup covered below.

The last check is from outside. The management API docs list models with a plain GET /models. Run this against your own host from a machine that should not have access:

curl -s --max-time 5 "http://$MMS_HOST:8081/models"

If you built on the SageMaker Inference Toolkit, management shares the serving port, so run the same request against 8080 or whatever port your container publishes.

If either request returns a model list, so would an attacker's request. The same API registers models with POST /models?url=..., and the docs say url can be an HTTP(S) URL (management API docs). Registration is where MMS downloads a model and unpacks its archive, the two steps these CVEs target.

Two APIs, one with a lock: MMS separates inference from management, and only network placement protects the second.

The stopgap AWS describes

AWS's actual recommendation is to stop using MMS and move to a supported model-serving solution (AWS). Until that ships, the bulletin offers a workaround with a catch.

If inference and management run on separate ports, bind management to loopback and don't pass external URLs to the model-download path (AWS). In config.properties, that means keeping management on its documented default and writing it out explicitly, so nobody widens it later along with the inference address:

inference_address=http://0.0.0.0:8080
management_address=http://127.0.0.1:8081

Here inference is opened to the network because something has to call it; management stays on the loopback address.

The catch: AWS says the SageMaker-style configuration binds management to all addresses on the same port as inference, so you can't move it to loopback without disabling model loading. For those deployments, the bulletin says to prioritise migration and, meanwhile, limit access to the serving port to trusted callers (AWS). In practice that means a security group or network policy that admits only the services that call the model, not a whole VPC.

So, for this week:

1. Run the git grep and pip show checks across every repo and image that serves a model.
2. For each hit, confirm where management listens and run the outside curl.
3. Lock management to loopback, or the serving port to known callers.
4. Put the migration on the roadmap with a date, because AWS has said no fix is planned for MMS.

Old inference containers are easy to forget. They answer requests, nobody pages on them, and they outlive the people who built them.

If you maintain a fork

Some teams vendored MMS and kept patching it themselves. AWS addresses you directly: reject archive entries whose resolved path falls outside the extraction directory, and restrict model downloads to an explicit URL allowlist (AWS).

The first rule is the standard zip-slip guard. Here it is in Python for a zip archive, using only zipfile and os.path:

import os
import zipfile

def safe_extract(archive: str, dest: str) -> None:
    root = os.path.realpath(dest)
    with zipfile.ZipFile(archive) as zf:
        for name in zf.namelist():
            path = os.path.join(root, name)
            target = os.path.realpath(path)
            if os.path.commonpath([root, target]) != root:
                raise ValueError(f"unsafe entry: {name}")
        zf.extractall(root)

It resolves every entry before writing anything and refuses the whole archive if one entry escapes. The allowlist is the same idea for URLs: compare the parsed host of the url parameter against a fixed set before the server fetches anything. Both are a few lines. Neither replaces moving off an unmaintained server.

---

If this was useful

Most of what bit here is deployment hygiene: a management port bound wider than it needed to be, inside a container nobody tracked after its maintainers left. Ship It covers that stretch between localhost and production for a small team, from hosting and CI/CD to monitoring, so the next end-of-life notice finds you with a list instead of a search.

If you work with Claude Code or other coding agents, I build Hermes IDE, an IDE for running them side by side. It's on GitHub.