OpenHands, danmu_api, MacCMS: Three Critical Unauthenticated Flaws in Self-Hosted Open Source

On October 26, 2026, VulnCheck (acting as CNA) filed three critical CVEs in NVD against three open source projects you install and run yourself: the OpenHands Software Agent SDK, the danmu_api service and the MacCMS v10 video CMS. The projects have nothing in common, but the outcome is the same: an unauthenticated attacker takes control — of a machine in one case, of configuration or user accounts in the other two.

For engineering teams, the OpenHands one matters most. It hits an AI coding-agent toolkit that typically runs on a developer laptop or a build server, with secrets close at hand.

VulnCheck also publishes a CVSS 4.0 score of 9.3 for each one. NVD has not analyzed any of these entries yet and attaches no CPE configuration to them. None is in the CISA KEV catalog at the time of writing.

OpenHands Software Agent SDK — CVE-2026-112346

Vector: AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H (9.8)

OpenHands runs its agents inside a sandbox — a Docker or Apptainer container hosting an agent server that takes instructions such as shell commands and file operations. According to the NVD description, in SDK versions before 1.52.0 the DockerWorkspace and Apptainer workspace launchers:

• bind that server to all network interfaces (0.0.0.0);
• with an empty session_api_keys list, which turns authentication off by default.

Anyone who can reach the container's published port can therefore send unauthenticated HTTP and WebSocket requests and:

• run shell commands as root inside the sandbox;
• access the mounted workspace — the code the agent is working on;
• read plaintext secrets from the secrets store.

The sandbox protects the host, but not what actually matters here: the source code and the secrets handed to the agent (API tokens, repository credentials and so on) are exactly what gets exposed. On a developer laptop on shared Wi-Fi, or a cloud VM with open ports, that exposure is very real.

The fix ships in version 1.52.0 (pull request 5209), referenced in NVD alongside the VulnCheck advisory.

It is the same design flaw we covered last week in five self-hosted AI agent platforms: a service that executes commands, listening on the network, with no authentication out of the box.

danmu_api — CVE-2026-116485

Vector: AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H (9.8)

Before 1.21.7, when the default TOKEN is left in place and ADMIN_TOKEN is unset, the /api/env/set, /api/env/add and /api/env/del routes accept POST requests without any real authentication. Per the NVD description, an attacker can:

• set ADMIN_TOKEN themselves and lock the operators out of their own service;
• point OTHER_SERVER or PROXY_URL at an address of their choosing, which opens the door to SSRF;
• trigger a redeployment.

MacCMS v10 — CVE-2026-116214

Vector: AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:N (9.1)

The MacCMS "forgot password" flow sends a recovery code, then checks it before resetting the password. The bug, per the description: check_msg() never compares the code's recipient (msg_to) with the targeted account. The attack goes like this:

1. request a recovery code to your own mailbox through user/findpass_msg;
2. submit it to user/findpass_reset along with the victim's email or phone number;
3. the victim's password is reset — account takeover.

The description says "any member". It does not state explicitly whether administrator accounts go through the same flow, so check that on your own instance before ruling the scenario out.

Affected versions

These bounds come from the descriptions published by VulnCheck, not from a NIST analysis. The first version outside the range is where the fix landed; ideally, install the latest release of each project.

Detection

• OpenHands: list the sandbox containers (docker ps) and check which addresses their ports are published on. A port bound to 0.0.0.0 on a machine reachable from another network needs attention now. Check the SDK version in the Python dependencies of every project that uses it.
• danmu_api: make sure TOKEN is not the default value and ADMIN_TOKEN is set. Look for POST requests to /api/env/ in the logs, and confirm OTHER_SERVER and PROXY_URL still point where you configured them.
• MacCMS: look for user/findpass_reset calls whose code was requested for a different address, and for password resets that members did not ask for.

Mitigation

1. Upgrade all three projects to at least the first version outside the affected range.
2. OpenHands, until then: publish the agent server port on 127.0.0.1 only, block it at the firewall, and rotate any secrets handed to an agent that was exposed.
3. danmu_api: replace the default TOKEN, set a strong ADMIN_TOKEN, then review the whole environment configuration.
4. MacCMS: after upgrading, force a password reset on administrator accounts if suspicious resets show up.

Why continuous monitoring matters for self-hosted tools

These projects don't come through a vendor or a central update console. They are dependencies someone installed once and then forgot. And since NVD hasn't analyzed them, monitoring that relies on CPE matches alone will miss them.

With cveo.tech, add the open source tools you run to your inventory, with their versions, and get an alert as soon as a CVE mentions them — even before NVD has analyzed it.