Live › vulnerability › CVE-2026-89295
Eclipse Mnestix AAS Generator versions 0.1.0 up to 1.5.0 do not cap the count parameter on the submodel ID generation endpoints. A remote unauthenticated caller can request a huge count, making the service hold identifiers in memory until it runs out and stops responding.
Summary written from the sources below. Check the originals before acting.
First seen by InfraStack 2026-11-03 14:21 UTC. All times on this page are UTC.
Teams running Mnestix AAS Generator from 0.1.0 up to but excluding 1.5.0 whose ID generation endpoints are reachable over the network. The description also requires the service to have successfully retrieved its ID-generation configuration from its backend repository, so a deployment without that configuration is less exposed. Deployments already on 1.5.0 or later are not affected.
No product ranges from the sources yet.
1.5.0/api/v1/IdGenerator/submodelIds/{count} or /api/v2/IdGenerator/submodelIds/{count} endpoints are reachable from the network1.5.0 or laterEach row is the first time that source carried this signal. The analyst’s rows are its own findings.
In Eclipse Mnestix AAS Generator versions 0.1.0 up until but excluding 1.5.0, a practical upper bound on the client-supplied count parameter of the GET /api/v1/IdGenerator/submodelIds/{count} and GET /api/v2/IdGenerator/submodelIds/{count} endpoints is not enforced. The service generates and retains identifiers in memory before returning a response. A remote unauthenticated attacker can submit a large count to cause excessive memory consumption, potentially resulting in denial of service. Exploitation requires network access to the endpoint and successful retrieval of the ID-generation configuration from the configured backend repository.
This page as .md · .json · in your agent: get_signal("CVE-2026-89295")
NVD data is provided by NIST and is public domain. Posts quoted belong to their authors.