AJ-Report, Jpom, LMDeploy, OpenDeepWiki, MuseBot, REDAXO: Six Unauthenticated Takeovers in Self-Hosted Software

Between October 27 and 31, 2026, VulnCheck (acting as CNA) filed six critical CVEs in NVD against six open source projects that people run themselves: the reporting tool AJ-Report, the deployment platform Jpom, the LLM inference server LMDeploy, the documentation generator OpenDeepWiki, the bot admin panel MuseBot and the REDAXO CMS.

Six unrelated products, one shared outcome: an unauthenticated attacker gets admin access or code execution. In half of them, the root cause is identical: a signing secret everyone knows, shipped in the source code and used to sign access tokens.

All six carry the same VulnCheck scores: 9.8 in CVSS 3.1 (AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H) and 9.3 in CVSS 4.0. NIST has analyzed none of them, none has a CPE configuration, and none is in the CISA KEV catalog at the time of writing.

Hard-coded secrets: AJ-Report, OpenDeepWiki, MuseBot

A signed token (a JWT, a session cookie) is only as good as the secret behind it. If that secret sits in the project's Git repository, anyone can mint valid tokens offline, without touching the server until the attack itself.

AJ-Report — CVE-2026-120209

Through version 1.7.1, AJ-Report signs its Share-Tokens with a hard-coded JWT secret. According to NVD, an attacker forges a token with the reportCode set to dataSet, which grants access to the testTransform endpoint. That endpoint hands scripts to GroovyClassLoader, so the forged token ends in unauthenticated remote code execution.

This is the worst of the batch. A reporting tool is, by design, wired into business databases.

OpenDeepWiki — CVE-2026-119597

Through 2.0.6, the Jwt:SecretKey in the appsettings.json shipped with the project is public. An attacker signs HS256 bearer tokens with an Admin role claim and reaches the /api/admin endpoints: users, roles, repositories, settings and API keys. The latter are often pay-per-use LLM provider keys.

MuseBot — CVE-2026-119660

Before 2.0.0, the admin panel uses the default session key muse_bot_session_key. An attacker signs a MuseBot-session cookie carrying a user_id and gets full admin access: password hashes, chat records, bot configuration, and the ability to stop bots.

This pattern is not new: four open source projects were flagged for hard-coded secrets in mid-October.

Jpom — CVE-2026-120201

From 2.10.0 through 2.11.12, Jpom takes the value of the JPOM-USER-TOKEN header and uses it in a query built with Hutool's Condition parser. That parser treats a value such as is not null as an operator, not as a string to compare, so the condition matches any user and the attacker is logged in as super-administrator.

Jpom deploys and monitors applications on servers. Its script features then allow command execution, which the NVD description calls out explicitly.

LMDeploy — CVE-2026-119706

LMDeploy, InternLM's LLM inference server, exposes an unauthenticated /update_weights endpoint in versions 0.9.0 through 0.18.0. Its serialized_named_tensors field takes base64-encoded data that ForkingPickler.loads deserializes without validation.

Unpickling Python data from the network is code execution: a crafted pickle runs OS commands as the api_server process. On an inference box, that process usually has access to GPUs, model weights and often data volumes.

REDAXO — CVE-2026-117532

In REDAXO core from 5.3.0 up to (but not including) 5.21.4, the structure/history plugin issues temporary login tokens. Per the description, an unauthenticated attacker can force the session-tied secret into a predictable state, then forge a token for an account such as admin. That yields backend access and code execution when the instance is not in live mode.

The project's GitHub advisory (GHSA-px8f-whj8-hrpq) is listed in the NVD references.

Affected versions

These bounds come from VulnCheck's descriptions, not from NIST analysis. Where no fixed version is given, follow the project repository and the VulnCheck advisory in the references: the next release is not necessarily fixed until the project says so.

Detection

• Inventory: look for these projects on servers, in containers and in team Docker images. AI tooling such as LMDeploy and OpenDeepWiki often gets installed outside the usual process.
• Default secrets: on AJ-Report, OpenDeepWiki and MuseBot, check whether the signing secret was ever changed. If not, assume any token seen so far could have been forged.
• Logs: calls to testTransform (AJ-Report), /api/admin (OpenDeepWiki) or /update_weights (LMDeploy) from unexpected addresses; JPOM-USER-TOKEN headers containing SQL keywords or operators.
• Exposure: none of these services should be reachable from the Internet without an authenticating reverse proxy in front.

Mitigation

1. Upgrade MuseBot to 2.0.0 and REDAXO to 5.21.4 at minimum; for the others, track the fixes announced by each project.
2. Replace signing secrets with random per-instance values (AJ-Report, OpenDeepWiki, MuseBot), which also invalidates existing tokens.
3. LMDeploy: never expose api_server beyond 127.0.0.1 or a trusted network, and block /update_weights at the proxy.
4. Rotate the API keys stored in OpenDeepWiki and any credentials Jpom handles if an instance was exposed.
5. Put authentication upstream (proxy, VPN, SSO) in front of all these admin tools.

Why continuous monitoring of your self-hosted tools matters

These projects have no vendor, no central update console, and NVD has analyzed none of them, so monitoring that relies on CPE matching 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 names them, even before NVD analyzes it.