NullHub EUVD-2026-101244

Requires the NullHub management API (/api/*) to be bound to a non-loopback interface - the referenced Dockerfile deployment, which exposes the listener beyond localhost, is the realistic affected mode; a strictly loopback-bound instance is not remotely reachable. Given that exposure, no further prerequisites exist: the attacker simply omits the Authorization and Origin headers, and the null-default auth_token causes the request to be accepted, so there is no authentication, user interaction, or special feature toggle needed. The primary limiting factor is therefore network exposure of the listener (AT:P), not any attacker-side complexity.

This is a genuine high-priority issue, not a CVSS-inflated one. The provided CVSS 4.0 vector (AV:N/AC:L/AT:P/PR:N/UI:N) describes a network-reachable, low-complexity, unauthenticated flaw with high confidentiality, integrity and availability impact to the vulnerable system (VC:H/VI:H/VA:H), scoring 9.2 - fully consistent with CWE-306 (missing authentication) and with the description, which states the auth_token defaults to null and is never assigned. The one mitigating signal is AT:P (attack requirement present): exploitation is gated on the management API listening on a non-loopback interface, so a strictly loopback-bound instance is not remotely reachable. No EPSS score and no KEV listing were supplied, and there is no indication of CISA-tracked active exploitation; however, a detailed public technical write-up (hackmd) and exact vulnerable source-line references on GitHub substantially lower the barrier to weaponization even though no packaged exploit is named. EPSS being absent (not low) means probabilistic exploitation likelihood cannot be compared here - its absence should not be read as low risk. Net: for any instance exposed beyond loopback (notably the referenced Docker deployment), treat as urgent; the only real limiter is network exposure of the listener.

An attacker who can reach a NullHub instance bound to a non-loopback address (e.g. a Docker container exposing the API) sends HTTP requests to /api/* with no Authorization or Origin header; because auth_token is null, every request is accepted as authorized. The attacker then rewrites the configuration to exfiltrate or replace stored provider credentials and reconfigures agent instances, cron jobs, and MCP servers to run attacker-controlled logic. No packaged exploit is named in the inputs, but a public technical write-up and exact vulnerable source references make reproduction straightforward.