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

AWS published security bulletin 2026-148-AWS disclosing two vulnerabilities in Multi Model Server (MMS), its open-source ML model-serving tool, affecting all versions up to 1.1.11 with no fix available or planned. The more severe flaw, CVE-2026-115812, is rated 9.8 on CVSS 3.1 and allows a crafted model archive to write files outside the intended directory, potentially leading to code execution; AWS notes the MMS management interface requires no authentication, so anyone who can reach the port can instruct the server to load a model. MMS and the SageMaker Inference Toolkit built on it were both archived in November 2025, leaving operators of existing inference containers to remediate themselves.

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 .