On this page (7 sections)
OpenDeepWiki (the AIDotNet/OpenDeepWiki project) has a critical flaw tracked as CVE-2026-119597. According to the GitHub advisory, versions through 2.0.6 contain a hard-coded JWT signing key that is publicly known, so an unauthenticated attacker can create a valid administrator token.
If you run an OpenDeepWiki instance that is reachable from the internet or from a shared network, treat it as a priority. The advisory does not list a patched version, so the steps below focus on checking exposure and reducing risk while you confirm a fix with the project.
What happened
The NVD record describes a hard-coded JWT signing key. The key is the Jwt:SecretKey value in appsettings.json, which is publicly known. Because the application accepts tokens signed with that key, an unauthenticated attacker can produce an HS256 bearer token carrying an Admin role claim.
With such a token, the advisory says an attacker can reach the /api/admin endpoints and control users, roles, repositories, settings and API keys. The NVD entry repeats the GitHub advisory text, so it is not a second, independent confirmation. A researcher write-up on HackMD, a VulnCheck advisory and a project issue are listed as references.
Why a hard-coded signing key is so dangerous
A JWT is a signed message that says who you are and what role you hold. With HS256, the same secret both signs and verifies tokens. The server cannot tell a token it issued from one an attacker made, as long as the signature matches.
When that secret is published in the project's configuration file, it stops being a secret. No password guessing, user interaction or special privileges are needed. The CVSS v4 metrics in the advisory reflect this: network attack vector, low complexity, no privileges required and no user interaction, with high impact on confidentiality, integrity and availability of the vulnerable system.
The practical consequence can reach beyond the application itself. The advisory says an attacker with a forged admin token can control repositories, settings and API keys, so any credentials or repository access configured in the instance should be considered at risk.
Who is realistically exposed
- Instances running OpenDeepWiki 2.0.6 or earlier that still use the Jwt:SecretKey value from the project's appsettings.json.
- Instances published to the internet, or reachable from guest, partner or shared networks.
- Teams that stored repository tokens or third-party API keys inside OpenDeepWiki, since an attacker with admin access can control repositories, settings and API keys.
- Instances where an operator already replaced the signing key with a unique random value. The advisory does not say whether these are affected, so verify your own configuration rather than assuming.
How to check your exposure
Start by finding out what version you run and whether your signing key is still the published one. Do not paste your real key into tickets or chats while doing this.
- Identify the deployed version (release tag, container image tag or the commit you built from) and compare it with 2.0.6.
- Open the appsettings.json your instance actually loads, and any environment variables or secrets that override it, and look at the Jwt:SecretKey value.
- Compare it with the value in the public v2.0.6 appsettings.json. If they match, assume the key is known to attackers.
- Check whether the application is reachable from outside your trusted network, including through a reverse proxy.
If your deployment runs in a container, this read-only command lists running containers and their image tags so you can confirm what is deployed (run it on the Docker host; look for the OpenDeepWiki image and its tag):
docker ps --format 'table {{.Names}}\t{{.Image}}\t{{.Status}}'To look for signs of past admin API use, search your reverse proxy or application logs for requests to the admin path. This read-only search prints matching lines; replace the path with your own log location. Admin requests from unfamiliar IP addresses, or at times no administrator was working, deserve a closer look:
grep '/api/admin' /var/log/nginx/access.logWhat to do now
Because no fixed version is named in the advisory, combine containment with a configuration change, and check the project for an updated release.
0 of 7 done
Detection and monitoring afterwards
Hard-coded secrets are easy to repeat across projects, so make checking for them routine. Alert on admin API calls from new IP addresses, on new admin users or role changes, and on API key creation. Keep admin interfaces off the public internet where you can, and put a reverse proxy or firewall rule in front of them. For background, see what a WAF is.
If you publish an OpenDeepWiki instance on your own domain, keep an eye on certificate and DNS changes as well. Webforta Monitor can track certificate, DNS and header changes, and a read-only scan of a site you verify can show what is exposed from the outside. Neither replaces fixing the application itself.
Current status and what is unconfirmed
- Only one independent publisher (the GitHub advisory) covers the flaw so far; the NVD entry repeats it.
- No fixed version is named, and affected versions are given only as through 2.0.6.
- The research reports no exploitation in the wild and lists no CISA KEV entry. That can change quickly for a flaw that needs no authentication.
- The advisory was published on October 30, 2026.
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.