Dockhand 1.0.45 fixes a CVSS 10 authentication bypass: any request path ending in .js skips login

Dockhand, a self-hosted Docker management UI, has an authentication bypass in versions up to 1.0.44. The global auth hook skips authentication for paths ending in static-asset extensions such as .js, and that includes API routes. An unauthenticated attacker can reset the administrator's password. CVE-2026-110130 is rated CVSS 10.0. The fix is in 1.0.45, which shipped on 27 August 2026, about seven weeks before the CVE was published. Neither the sources we read nor the CISA KEV catalog show exploitation.

What happened

The flaw is tracked as CVE-2026-110130. NVD published the record on 13 October 2026, and it was assigned by VulnCheck acting as CNA. NVD lists it as "Awaiting Analysis". The record covers Dockhand from Finsys, with versions before 1.0.45 affected.

The CVE is newer than the fix. Dockhand 1.0.45 was released on 27 August 2026, the same day as the GitHub advisory, with the release note "This is important security upgrade with a number of API hardenings". The latest release is v1.0.53 (10 October 2026). So the CVE labels a bug that has had a patch available for roughly seven weeks.

The CVE is also newer than the vendor's advisory. The GitHub advisory, GHSA-r3mg-r5vm-3v6w, is dated 27 August 2026 and shows no CVE id, so searches on the GHSA alone will not find the CVE. The GitHub advisory credits the reporter as allanvictor. The VulnCheck advisory credits Allan Victor.

Why it matters

Dockhand is a management plane for Docker hosts. According to the advisory, an attacker who takes the admin account gets user management, settings and Docker operations. The attacker can also delete the last admin and so disable authentication globally, which locks out the operators.

The advisory states the exposure condition as "any self-hosted Dockhand instance with authentication enabled and at least one local user". The attack needs no credentials and no user interaction, and it works over the network (compare the AWS Loom admin takeover, another management plane that trusted unauthenticated clients). NVD records this as CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:C/C:H/I:H/A:H, scored 10.0. The CVSS 4.0 vector also scores 10.0. We have no source for how many Dockhand instances are internet-facing, so we give no exposure figure. Any instance reachable by an untrusted network, or by a compromised machine on the internal network, is exposed.

Status: not in CISA KEV as of 14 October 2026, and we found no report of exploitation. The advisory includes a proof of concept, so exploitation is straightforward to reproduce. We treat that as a reason to patch promptly, not as evidence of attacks.

Technical details

The advisory describes two chained weaknesses.

One unauthenticated request with a .js suffix reaches the user API and resets the admin password.

1. Static-asset check before authentication. The global auth hook in hooks.server.ts returns early for any path ending in .js, .css, .png, .svg, .ico, .webp or .jpg. It runs before session validation. The check matches on the path suffix, so an API route such as /api/users/1.js passes it, and the request reaches the API handler without authentication (we covered a similar path-encoding login bypass in Cisco SD-WAN Manager).
2. Handlers that fail open. The user-mutation handlers in src/routes/api/users/[id]/+server.ts skip their permission checks when auth.user is null. That is the state of an unauthenticated request that the hook let through. Password changes also do not require the current password.

Our reading, not stated in the advisory: either flaw alone would be less severe. With only the first, handlers that deny a null user would still reject the request. With only the second, the auth hook would still block it. Together they let an anonymous request modify any account.

What the fix changed. Our reading of the fix commit (08166722, "harden authentication and authorization on the user API", 27 August 2026): the static-asset check now returns false for any /api/ path, so API routes always go through authentication. The user PUT and DELETE handlers return 401 when authentication is enabled and the caller is not signed in. The edit-permission check now fails closed, so a caller who is neither the target user nor holds the users:edit permission is denied.

Per the advisory, three methods on /api/users/<id>.js are reachable without authentication:

• PUT resets a user's password.
• GET returns user records.
• DELETE removes users and can disable authentication globally.

The advisory's attack sequence is to reset the admin password, log in with the new credentials, and optionally delete the last admin to switch authentication off. The proof of concept is in the GitHub advisory. We link it and do not reproduce it.

NVD and VulnCheck classify the issue as CWE-288 (Authentication Bypass Using an Alternate Path or Channel). The GitHub advisory lists CWE-284, CWE-287, CWE-306 and CWE-863.

The two sources give the affected range slightly differently. GitHub says 1.0.44 and earlier, and NVD says before 1.0.45. These are the same set of releases.

What defenders should do

• Check your version. Any Dockhand instance at 1.0.44 or earlier is affected. Upgrade to 1.0.45 or later. Dockhand ships as the Docker image fnsys/dockhand:v<version>, also tagged :latest, so check the image tag of the running container. A container created from :latest before 27 August stays on 1.0.44 or earlier until you re-pull the image and recreate it.
• Building from source? Our finding, not the vendor's: the public git tag v1.0.45 predates the fix commit, and the first tag that contains it is v1.0.46 (2 September). The official 1.0.45 image contains the fix. If you build from source, use v1.0.46 or later.
• Review the admin account. The advisory's attack changes the admin password. If you cannot account for a recent password change, or an operator cannot log in, treat the instance as compromised. Check whether authentication is still enabled. The sources do not list indicators of compromise.
• Look in access logs. Look for requests to /api/users/ paths ending in .js, especially PUT or DELETE. These requests have no legitimate use. This is our suggestion, not guidance from the sources, and it only works if you log request paths, for example at a reverse proxy.
• If you cannot upgrade immediately. The advisories we read name no workaround. As general hardening, which the sources do not cover, take the instance off untrusted networks and restrict access at the network layer or reverse proxy. A rule that blocks /api/ paths ending in a static-asset extension would also fit. Test any such rule, because it is not a vendor-supported fix.
• If you were exposed, assume the Docker side may be affected. An attacker with admin access can run Docker operations through Dockhand. Review the containers and images on the managed hosts, and rotate secrets that Dockhand can reach.

What is still unclear

• Whether anyone has exploited this. We found no report, and the CVE is absent from CISA KEV.
• How many instances are internet-facing. No source gives a figure.
• Whether the vendor documents a workaround or indicators of compromise. The advisory text we read has none.
• NVD analysis is pending, so the NVD score and weakness data could change. The listed values are the CNA's.
• Why the CVE was published about seven weeks after the fix and the GitHub advisory. The sources do not say.

Sources

• NVD record for CVE-2026-110130 (API)
• GitHub advisory GHSA-r3mg-r5vm-3v6w (Finsys/dockhand)
• VulnCheck advisory
• Dockhand v1.0.45 release notes
• Dockhand fix commit 08166722
• CISA Known Exploited Vulnerabilities catalog