GPU VulnDB

Database/AI/ML frameworks & serving

Quarkus LangChain4j: unauthenticated CONNECT frames leak chat scopes until the JVM exits

CVSS 6.9CVE-2026-108748AI/ML frameworks & servingcurated

Impact

An unauthenticated client that repeatedly sends CONNECT frames reusing a single chatId leaves orphaned scopes in the activeScopes map, which are never released for the lifetime of the JVM. The result is steadily growing heap on the serving process until it degrades or dies, with no user action required to trigger it. On a GPU node this matters more than the modest availability-only score suggests: the leaking process is the one holding the accelerator, so restarting it means the model weights are reloaded and the GPU sits idle through warm-up, and a process killed by the OOM killer can leave the device in a state that needs the pod rescheduled. Exposure depends on whether the chat-scopes WebSocket endpoint is reachable beyond the cluster.

Who can reach it

Anyone who can open a WebSocket to the /_chat/routes endpoint. No authentication is required, so the exposure is whatever network can reach the serving port - a tenant pod on the same cluster network, or the internet if the endpoint is published through an ingress.

What to do

Upgrade past the affected range (1.9.0 through 1.14.1); the record does not name a fixed version, so confirm it against the project advisory before scheduling. Until then, keep the chat-scopes WebSocket endpoint off any untrusted network and put authentication in front of it. Remediation is a redeploy and restart of the serving process - expect a model reload and a cold-start window per replica, so roll replicas rather than restarting them together. No node drain or reboot is involved.

References

Related entries

All AI/ML frameworks & serving entries

This entry is curated: imported from vendor advisories with machine assistance, not yet individually verified. Confirm against your vendor's advisory before acting, and report anything wrong.