On this page (7 sections)
MuseBot, an open-source bot project, has a critical authentication bypass in versions before 2.0.0. According to the GitHub Advisory, the admin interface signs its session cookie with a hard-coded default key, so an unauthenticated attacker who knows that key can forge an admin session without a password.
If you run MuseBot with its admin panel reachable from a network, treat this as urgent. The flaw is tracked as CVE-2026-119660 and was published on October 30, 2026.
What happened
The NVD record describes an authentication bypass in MuseBot before 2.0.0. The admin component uses a default session key, the string 'muse_bot_session_key', that is written into the code rather than generated per installation. Because the key is the same everywhere and is public, it provides no secrecy.
The NVD text repeats the GitHub advisory and is not independent confirmation. Additional write-ups are linked from the advisory, including a VulnCheck advisory and a researcher write-up on HackMD. Treat the story as lightly corroborated so far, and read the vendor repository for the authoritative fix.
How the weakness works
Many web apps keep a user logged in with a signed cookie. The server signs the cookie with a secret key, and later trusts any cookie whose signature checks out. This only works if the key stays secret and unique.
Here the key is a well-known default. Per the advisory, an attacker can sign a MuseBot-session cookie that carries a chosen user_id, and the server will accept it as a genuine login. No credentials, no user interaction and no special network position are needed. The CVSS v4 metrics in the advisory list network attack vector, low complexity, no privileges and no user interaction, with high impact on confidentiality, integrity and availability.
The advisory states that a successful attacker gets full administrative access, which includes:
- Reading password hashes
- Reading chat records
- Reading the bot configuration
- Stopping bots
Bot configuration often holds API tokens and connection settings for other services. The research does not say which secrets MuseBot stores, so check your own configuration to see what an intruder could have read.
Who is affected
Any deployment of MuseBot older than 2.0.0 that exposes its admin interface is in scope. The risk is highest when the panel is reachable from the public internet or from a large shared network. An instance on a locked-down private network is harder to reach, but anyone who can connect to it can still forge a session.
The advisory lists no package and no confirmed list of patched versions, so do not rely on a package manager alert to tell you that you are exposed. You need to check your version yourself.
How to check your exposure
First find out which version you run and whether the admin interface is reachable. The vendor project is on GitHub; compare your release or commit against it. If you deploy from a cloned repository, this read-only command, run in the project directory, shows the most recent tag your checkout is based on:
git describe --tagsIf the result is a tag below 2.0.0, you are running an affected version. If you run it from a container image or packaged build, check the tag or version label you deployed instead.
Next, review where the admin interface listens. Confirm in your firewall, reverse proxy or cloud security group whether the admin port is open to the internet. If you cannot tell, a scan from outside your network will show what is exposed.
What to do now
0 of 7 done
The advisory points to two fix commits in the repository (139f615 and 3e64518) and an issue thread. The research does not describe what those commits change, so read them before assuming how session keys are now handled in your setup.
Detection and monitoring
Because a forged cookie is accepted as legitimate, there may be no failed-login trail. Look instead for admin actions that nobody on your team performed, admin requests from unfamiliar IP addresses in your reverse proxy or access logs, bots that stopped unexpectedly, and configuration changes you did not make.
Keep the admin panel off the public internet where possible, and keep an eye on what your public hosts expose. A read-only scan can help you see which services and pages are reachable from outside, and monitoring can alert you to unexpected changes on your public endpoints. For general guidance on reviewing a site after suspected misuse, see how to check if a website is hacked.
What is still unknown
- Whether attackers are exploiting this flaw in the wild: the research does not say, and it is not in CISA KEV
- The exact fixed version history: the advisory lists patched versions as unknown, while the description says the issue affects versions before 2.0.0
- Whether the GitHub advisory entry has been reviewed: it is marked unreviewed, and the score shown is CVSS v4
Details may change as maintainers and researchers publish more. Recheck the advisory and the project repository before you close the issue.
Sources
This article is based on the public sources below. Details can change as vendors and researchers publish more; check the original advisories before acting on version numbers.