CVE-2026-111643 is a missing authentication flaw (CWE-306) in Misaka Danmu Server through 2.8.9, scored 9.8 critical. An unprotected configuration rollback endpoint lets anyone change security settings and become administrator. I could not confirm a fixed release, so restrict access and check the project.
What's affected
Misaka Danmu Server through 2.8.9, per the CVE record. The record names the unprotected POST /api/ui/config-history/rollback endpoint. It lets an unauthenticated caller write arbitrary configuration keys, including the IP allow list, the trusted proxy list and the webhook API key.
The record names no fixed version, so check the project for a release after 2.8.9 and read its notes.
How to check if you're exposed
Find the version on the application's status or about page, or in the deployment image tag. If it is 2.8.9 or older, treat it as affected.
Check how the server is reachable. If the web interface is open to the internet, restrict it now. Then review the configuration history for entries you did not make, and check the current values of the IP allow list, trusted proxies and webhook key.
In access logs, look for requests to the rollback path from unfamiliar addresses.
You can also run the free in-browser dependency scan or browse the Gold directory to see where a package or product shows up in your stack.
What to do now
- Put the server behind a VPN or an authenticating reverse proxy, and block the rollback path from untrusted clients.
- Review the configuration history and the current allow list, trusted proxy list and webhook key for unexpected changes.
- Rotate the webhook API key and any other secrets the application stores.
- Look for a release newer than 2.8.9 that fixes the issue, and upgrade when one is available.
- Review administrator activity for the period since you deployed this version.
Why it matters
The endpoint that restores old configuration forgot to check who is calling, which is CWE-306, missing authentication for a critical function. Because configuration includes the settings that decide who is trusted, writing it means controlling access to everything else. The record describes setting the allow list to the attacker's own address, which then opens every protected endpoint.
The pattern is worth checking in your own code. Admin and rollback actions are often added late and skip the shared checks that guard the main routes. A deny by default rule on the whole router prevents this class of mistake.
The record does not flag this CVE as exploited in the wild and it is not a CISA Known Exploited Vulnerability.
Quick check
Why is an allow list change so serious?
If an attacker can write the allow list, they can add themselves to it and then pass the check that guards the admin routes.
Is there a fix?
I could not confirm one. Check the project for a release after 2.8.9.
Sources
Last reviewed: 19 October 2026.
