CVE-2026-110616 is a High severity (CVSS 8.1) missing authentication flaw in NullHub through 2026.5.29. The management API at /api accepts unauthenticated requests when the listener is not on loopback. We could not confirm a fixed version, so restrict network access now.
What's affected
The record says NullHub through 2026.5.29 is affected. VulnCheck gives the same range. Neither names a fixed release, so we do not state one. Check the nullclaw/nullhub repository for a newer release.
The weakness is CWE-306, missing authentication for a critical function. Per the record, the auth_token setting defaults to null and is never assigned, so the check that should protect the management API does not protect it. Requests that arrive without an Authorization or Origin header, to a listener that is not bound to loopback, are accepted.
The record lists the impact: control of agent instances, rewriting of configuration including provider credentials, and management of cron jobs and MCP servers. Severity differs by source. The record gives 8.1 (High) because attack complexity is rated high. VulnCheck lists 9.2 (Critical) on a CVSS 4.0 vector. Treat it as urgent if the service is reachable beyond your own machine.
How to check if you're exposed
Find where NullHub listens. Check for an open port on the host and see which address it is bound to.
ss -ltnp | grep -i nullhub
A listener on 127.0.0.1 is only reachable from the same machine. A listener on 0.0.0.0 or a LAN address is reachable by anyone who can route to it. The record references the project's Dockerfile, so check container deployments in particular.
Then check the version you run. If it is 2026.5.29 or lower, you are in range. Review recent changes to agent configuration, stored provider keys and scheduled jobs for edits you did not make. The free in-browser dependency scan at gold.safeguard.sh/scan can match a manifest or lockfile against known CVEs without installing anything.
What to do now
- Bind NullHub to loopback, or put it behind a reverse proxy that requires authentication, and block direct access with a firewall rule.
- Do not publish the container port to the internet or a shared network.
- Check for a fixed release in the nullclaw/nullhub repository, upgrade when one is confirmed, and set an auth token if the release supports one.
- Rotate provider API keys and any credentials stored in NullHub if the service was reachable from an untrusted network.
- Review cron jobs, MCP server entries and agent configurations for changes you did not make.
Why it matters
A control plane for AI agents holds a lot of authority: provider keys, scheduled jobs and tool servers that can act on other systems. If the control API has no working authentication, anyone who can reach the port can reconfigure all of it.
The cause here is a setting that looks like protection but is never turned on. A default of null for the token means the check has nothing to compare with. Services that bind to all interfaces by default make this worse, because the first deployment is already exposed. The record does not mark this CVE as known exploited, and none of the pages we read say it is.
Quick check
Is NullHub fixed?
We could not confirm a fixed release from the pages we read. Check the project repository.
Why do the severity scores differ?
The record rates it 8.1 High and VulnCheck lists 9.2 Critical using a different scoring version. Both call for prompt action.
Sources
Last reviewed: 18 October 2026.
