Summary
- CVE-2026-115812 and CVE-2026-115813 affect all released Multi Model Server versions through 1.1.11.
- The unauthenticated management interface creates elevated risk if reachable by untrusted users.
- AWS will not release patches for the retired project and recommends migration to supported model-serving software.
Amazon Web Services has disclosed two vulnerabilities in its retired Multi Model Server software, warning that affected systems face code execution and network request risks without a vendor patch path. The model-serving project reached end of life and its source repository was archived in November 2025, leaving organisations still depending on it without a maintained vendor patch path.
The advisory, published on 23 October as bulletin 2026-148-AWS, covers CVE-2026-115812 and CVE-2026-115813. Both affect released versions up to and including 1.1.11. AWS says the project’s source repository has been archived and read-only since November 2025 and that no fixed version is available or planned through its distribution channels.
Multi Model Server is an open-source component used to serve machine learning models for inference. Depending on deployment, it can accept model archives, make models available to applications and process management requests. Its usefulness in a model-serving stack also gives its management interface capabilities that would be dangerous if accessible to unauthorised users.
The first vulnerability concerns model archive extraction. A crafted model archive could cause files to be written outside the directory intended for extraction, with potential code execution under the privileges of the Multi Model Server process. The second involves the model download path, where the management interface could be induced to request unintended network destinations.
The latter behaviour falls into the category of server-side request forgery, where a service with network access is made to contact an unexpected destination. Depending on what the service can reach, such a defect could expose internal resources that the original external requester cannot contact directly. The bulletin does not report that either vulnerability has been exploited against named customer systems.
AWS says the management interface does not require authentication in both cases. Deployments that bind it to a network-accessible address therefore face greater risk than those where management is available only to trusted callers. Even so, the advisory warns that not every installation can move management traffic to a separate loopback interface without affecting application behaviour.
In particular, AWS identifies SageMaker-style configurations in which the inference and management functions share a port bound to all addresses. Turning that shared port into a loopback-only service would also disable normal model loading in that arrangement. Such environments need an alternative network containment plan during migration rather than a simplistic change copied from another deployment.
The retirement status changes the normal patch response. In a supported product, an organisation can identify the vulnerable version and install a vendor release that corrects the defect. Here, AWS has explicitly said there will be no such release. Customers must inventory deployments, identify whether they are using the original package or a derivative, and plan replacement or maintain the relevant code themselves.
For forks, AWS describes the underlying control objectives: reject archive entries resolving outside the intended extraction directory and restrict model-download destinations to approved URLs. These are engineering changes that require implementation and testing in the actual codebase, not ready-made updates for all distributions.
The case exposes a lifecycle issue in enterprise AI infrastructure. Model gateways, inference servers and experimentation tools may remain in production after their original maintainers stop releasing updates. Their administrative surfaces can become difficult to protect if security teams lack a current inventory of where they are deployed and which application owners depend on them.
Because the management endpoint can share infrastructure with inference traffic, simply checking whether an organisation exposes a public model API is not enough to determine management reachability. The deployment’s listening addresses, reverse proxies and network access rules must be reviewed as configured. Limiting exposure to trusted networks may reduce opportunity for abuse during migration, but AWS states that this is not available as a complete workaround in every deployment pattern.
AWS’s recommendation is to discontinue Multi Model Server and move to a supported alternative. It has not announced a revised support policy or provided a replacement timetable for affected customers.
