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

> Source: <https://dev.to/gabrielanhaia/aws-wont-patch-a-cvss-98-bug-in-multi-model-server-its-management-api-has-no-login-2e71>
> Published: 2026-10-24 19:05:16+00:00

On October 23, AWS published [security bulletin 2026-148-AWS](https://aws.amazon.com/security/security-bulletins/2026-148-aws/) for two vulnerabilities in [Multi Model Server](https://github.com/awslabs/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](https://www.strix.ai/cve/CVE-2026-115812). 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](https://aws.amazon.com/security/security-bulletins/2026-148-aws/) 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.

The bulletin covers two CVEs:

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](https://aws.amazon.com/security/security-bulletins/2026-148-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](https://www.thehackerwire.com/vulnerability/CVE-2026-115812/) and [Strix](https://www.strix.ai/cve/CVE-2026-115812). 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.*

MMS is end of life. Its [GitHub repository](https://github.com/awslabs/multi-model-server) was archived by its owner on November 20, 2025 and is read-only, and the bulletin confirms the end-of-life status ([AWS](https://aws.amazon.com/security/security-bulletins/2026-148-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](https://github.com/aws/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.

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](https://github.com/awslabs/multi-model-server/blob/master/docs/configuration.md)):

```
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](https://github.com/awslabs/multi-model-server/blob/master/docs/configuration.md)). 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](https://github.com/awslabs/multi-model-server/blob/master/docs/management_api.md) 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](https://github.com/awslabs/multi-model-server/blob/master/docs/management_api.md)). 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.*

AWS's actual recommendation is to stop using MMS and move to a supported model-serving solution ([AWS](https://aws.amazon.com/security/security-bulletins/2026-148-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](https://aws.amazon.com/security/security-bulletins/2026-148-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](https://aws.amazon.com/security/security-bulletins/2026-148-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:

`git grep` and `pip show` checks across every repo and image that serves a model.`curl`.
Old inference containers are easy to forget. They answer requests, nobody pages on them, and they outlive the people who built them.

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](https://aws.amazon.com/security/security-bulletins/2026-148-aws/)).

The first rule is the standard zip-slip guard. Here it is in Python for a zip archive, using only [`zipfile`](https://docs.python.org/3/library/zipfile.html) and `os.path`:

``` php
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.

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](https://www.amazon.com/dp/B0GW2NTCR5) 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](https://hermes-ide.com/download), an IDE for running them side by side. It's on [GitHub](https://github.com/hermes-hq/hermes-ide).
