EUVD-2026-114076
GHSA-77p8-2qmx-794p
Attack ChainAIDerived
Hypothetical attack flow derived from CVE metadata – not a confirmed exploit chain
-
AccessReach MuseBot admin HTTP endpoint
-
ExploitForge MuseBot-session cookie with default key
-
ExecutionSubmit forged cookie for admin session
-
ImpactRead password hashes and config, stop bots
Vulnerability Assessment
| Weakness |
CWE
OWASP Top 10:2025
A07:2025 - Authentication Failures
ASVS 5.0
V6 - Authentication Authentication mechanism
|
| Exploitation Conditions | No special conditions for a default deployment - remote unauthenticated exploitation against MuseBot instances before 2.0.0 whose admin interface is network-reachable and whose session_key was left at the hard-coded default 'muse_bot_session_key' (the pre-patch default). The limiting factors are: the MuseBot admin HTTP endpoint must be reachable by the attacker, and an operator who explicitly overrode session_key with a custom value before the fix is not exploitable because the forged cookie signature would not validate; the patched 2.0.0 behavior (auto-generated, persisted random key, with the legacy default actively rejected) also removes the condition. |
| Impact | All signals point in the same direction for the affected product, but real-world reach is the open question. The CVSS 4.0 vector (AV:N/AC:L/AT:N/PR:N/UI:N) describes a trivially exploitable, network-reachable, unauthenticated flaw with high confidentiality, integrity and availability impact, and the vuln.today decision label is act_now with a patch available - so for anyone running MuseBot before 2.0.0 this is a genuine priority, not a high-CVSS-but-low-real-risk paper cut. The root cause is a hard-coded default session signing key ('muse_bot_session_key', CWE-1394), which is public in source and docs, so forging an admin cookie requires no bug-class acrobatics - only knowledge of the key. No EPSS score and no CISA KEV entry are provided, and there is no 'POC/Exploit: Publicly available (confirmed)' marker; a public technical write-up (hackmd) and the vendor advisory describe the technique, so treat this as a public PoC reference that is not verified as working exploit code rather than confirmed active exploitation. The counterweight is deployment footprint: MuseBot is a single-maintainer open-source GitHub project (yincongcyincong/MuseBot), so the absolute number of exposed, internet-facing admin panels is likely small, which argues the practical risk is opportunistic against the few exposed instances rather than widespread. |
| Exploit ScenarioDerived | An attacker who can reach a MuseBot (pre-2.0.0) admin HTTP endpoint crafts a MuseBot-session cookie containing a user_id and signs it with the publicly known default key 'muse_bot_session_key', producing a valid forged admin session with no credentials. Sending that cookie grants full administrative access - reading stored password hashes and chat records, altering bot configuration, and stopping bots. A public technical write-up describing the method exists; it is not verified as working exploit code, but the attack is simple to reproduce given the known key. |
Get an e-mail when this CVE is exploited, patched or re-scored. Free account.
Alert meAnalysisAIv1 – Oct 30, 2026
Authentication bypass in MuseBot releases before 2.0.0 lets remote unauthenticated attackers forge an administrative session by signing a MuseBot-session cookie with the hard-coded default session_key 'muse_bot_session_key', which ships as the built-in default of the -session_key flag. Any deployment whose admin HTTP interface is network-reachable and which never overrode that default is fully compromised: the forged cookie carries an attacker-chosen user_id and yields administrative access to password hashes, chat records and bot configuration, and allows bots to be stopped. The vendor has released 2.0.0, which auto-generates and persists a random key and actively rejects the legacy default; no CISA KEV entry or public exploit code is confirmed at time of analysis, though a public technical writeup of the bypass exists, so exposure of admin endpoints should be treated as urgent.
RemediationAI
Upgrade to MuseBot 2.0.0, which contains the vendor fix in commits 3e64518948fe7037058f07ef987d35216c3f0cae and 139f6158b50283b983d76976f593a3a09a064681 (advisory: https://www.vulncheck.com/advisories/musebot-before-2.0.0-authentication-bypass-via-hard-coded-session-key). After upgrading, no manual key handling is required: ensureSessionKey detects an empty session_key or the legacy literal 'muse_bot_session_key', generates a 32-byte random key, persists it to data/admin_session_key with 0600 permissions and reloads it on restart, and logs only the key source - though operators who prefer to manage the secret themselves can set the -session_key flag or SESSION_KEY environment variable to a long random value, at the cost of having to keep that secret out of source control and shell history. If the upgrade cannot be applied immediately, the actionable stopgap is to set session_key to a long random value on the current build (equivalent to the flag's documented override) so that cookies forged with the published default no longer validate - note this invalidates all existing admin sessions, forcing re-login, and it only removes the exposure if every replica is actually restarted with the new value, since a single instance still running the default keeps the bypass live; rotating the key does not remediate anything else, as the underlying default remains in the binary. Where the key cannot be rotated yet, restrict the admin HTTP endpoint to trusted networks at the reverse proxy or firewall and avoid exposing it to the internet, accepting the loss of remote administrative access; this is a containment measure that leaves the hard-coded default in place and must be paired with the upgrade. The patched code additionally sets HttpOnly, SameSite, Path=/ and a 30-day MaxAge on the session cookie and stops logging the session key, so operators on 2.0.0 gained no additional steps beyond verifying the generated key file permissions and that no deployment still passes the legacy value explicitly.
Affected VersionsENISA
Affected Packages
Source: OSV (Open Source Vulnerabilities)
Affects your stack
Affects 1 package in euvd
Checking this CVE against your own stacks and servers is part of the Basic plan and up.
Technical ContextAI · show details
MuseBot is a Go-based chat/bot management application whose admin panel derives its session-integrity guarantee entirely from the secrecy of a symmetric signing key. The pre-fix code in admin/conf/conf.go registered the flag as flag.StringVar(&BaseConfInfo.SessionKey, "session_key", "muse_bot_session_key", "session key"), and admin/controller/login.go fed that value into the gorilla/sessions cookie store. Because the key was a compile-time constant published in the source tree and old documentation, anyone could compute a valid signature for an arbitrary session payload - CWE-1394, Use of Default Credentials, applied to a cookie-signing secret rather than a login password. The triggering mechanism is simply presenting a well-formed signed cookie to the admin controller; no credentials, no race condition and no memory-corruption primitive is involved (CVSS 4.0 AV:N/AC:L/AT:N/PR:N/UI:N, corroborated by the independent CVSS:3.1/AV:N/AC:L/PR:N/UI:N assessment). Exploitability therefore hinges on two deployment facts only: whether the admin endpoint is reachable, and whether session_key was left at its default. The upstream fix (commits 3e64518948fe7037058f07ef987d35216c3f0cae and 139f6158b50283b983d76976f593a3a09a064681) introduces legacySessionKeyDefault, a new ensureSessionKey/ensureSessionKeyAt pair that generates a 32-byte crypto/rand key, hex-encodes it, persists it at data/admin_session_key with 0600 permissions and reloads it across restarts, replaces the legacy value when detected, stops logging the key material, and hardens the cookie with HttpOnly, SameSite, Path=/ and a 30-day MaxAge.
Know when Musebot gets its next vulnerability
- Watch products and get an email when something new is published
- Check this CVE against your own stack and servers
- Exploit and PoC references, threat intelligence from 22 sources
No credit card · 7-day full trial
Severity by source
CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:H/VI:H/VA:H/SC:N/SI:N/SA:N
Publicly known default key allows unauthenticated network forging of admin sessions (PR:N/AC:L/AV:N), yielding full read (C:H), config tampering (I:H) and bot shutdown (A:H), scope unchanged.
Primary rating from Vendor (VulnCheck).
CVSS VectorVendor: VulnCheck
DescriptionCVE.org
MuseBot before 2.0.0 contains an authentication bypass vulnerability that allows unauthenticated attackers to forge admin sessions by using the hard-coded default session_key 'muse_bot_session_key'. Attackers can sign a MuseBot-session cookie carrying a user_id to gain full administrative access, reading password hashes, chat records, and bot configuration, and stopping bots.
Executive ViewAI
MuseBot deployments running versions prior to 2.0.0 expose their administrative interface to anyone on the network, allowing an attacker to bypass login entirely and gain full admin control. Organizations running MuseBot with an internet- or network-reachable admin endpoint face exposure of sensitive data including password hashes, chat records, and bot configuration, and attackers could stop active bots. Leadership should care because a single misconfigured deployment can result in full compromise of a business-critical messaging/bot platform without any credentials.
Apply vendor patch.
Threat Intelligence Overview
NVD
CVE.org
EPSS
How this decision was reached
The engine reads each signal below and applies a fixed list of rules from top to bottom. The first rule that matches sets the recommended action – like a statement, every line is shown.
What every action level means
SSVC AssessmentENISA
Priority Score
Attack Technique
Authentication bypass attacks exploit flaws in the verification mechanisms that control access to systems and applications.
Exploit-DB