plaincve:~$

// threat brief

CVE-2026-108860

BotSharp hard-coded JWT signing key: if the default key isn't replaced, an attacker can forge login tokens and impersonate known users (the CVE record says including admins)

CVSS
9.3 CRITICAL
CISA KEV
Not listed
Weakness
CWE-321
Topics
Web apps · AI security

PlainCVE Team · Published 2026-10-18 · AI-assisted · Press brief ↓

AI review 2026-10-18 (not human-reviewed)Command tests: none yetReproduced: not yetVerification record ↓

BotSharp ≤5.2.0 ships a public JWT key; if not replaced, anyone can forge tokens as known users (CVE: incl. admins; finder: admin rights not established).

Who is affectedDeployments running BotSharp WebStarter 5.2.0 or earlier that have not overridden Jwt:Key through an environment variable or other configuration source, with the API reachable over the network.
What happensThe CVE record (CNA: VulnCheck) says an unauthenticated remote attacker can impersonate any known user, including administrators, on API routes that require login ([Authorize]). The finder's report that the CVE record cites only confirms that a forged token passes the [Authorize] check; it explicitly does not establish administrative rights, role escalation or access to a specific user's data, and no runtime validation was performed.
What to do nowNo fixed version is known (not vendor advice; the maintainers have published no advisory). The researcher and the third-party site OffSeq suggest replacing Jwt:Key with a random value only you know, via an environment variable, user secret or command-line option. PlainCVE also suggests restricting network access to the WebStarter API (the researcher notes the attacker must be able to reach the API over the network).
Affected versionsAll versions through 5.2.0; the researcher confirmed it on r5.2-image-composition (commit a11ee03) and master commit 5151983, earlier releases not tested
Fixed versionsNo fixed version is known
CVSS vector
Show full vectorCVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:H/VI:H/VA:N/SC:N/SI:N/SA:N
Timeline
  • First public 2026-10-11

Blue team playbook

Check, fix / mitigate, respond, harden. Matching the affected versions does not mean you were compromised, and a check that finds nothing does not prove you are safe; each item says what it can and cannot show. Tagged steps point to where the attack flow below can be stopped.

DETECTCheckAm I affected? Any signs of compromise?
  1. 01Check whether you still use the default key

    You are affected if: you run BotSharp WebStarter 5.2.0 or earlier with its default signature validation (enableValidation = true), Jwt:Key is not overridden by an environment variable, user secret or command-line option, and the API is reachable over the network. An attacker also needs to know the identity of the user to impersonate. Run the command below from the root of your BotSharp source tree (it only reads a file); for a published deployment, check the appsettings.json in your deployment directory instead. Note that the source config file will always show the committed key, and this command cannot tell whether your deployment overrides Jwt:Key with an environment variable, user secret or command-line option, so check your deployment's configuration separately. If the Jwt:Key your deployment actually uses matches the committed one and the API is reachable, treat it as affected.

    Read-only check
    grep -n -A4 '"Jwt"' src/WebStarter/appsettings.json
    Step 1Step 4
MITIGATEFix / mitigatePatch; block it if you cannot patch yet
  1. 01Replace Jwt:Key

    No official fix is known. The third-party site OffSeq suggests changing Jwt:Key to a secure, unique value that is not hard-coded or committed in configuration files; the researcher notes the shipped key is used only if no other configuration source overrides Jwt:Key. This is not vendor advice.

    Step 1Step 4
  2. 02Restrict network access to the WebStarter API

    The attacker has to reach the API. Until the key is replaced, allow access only from trusted networks. This is PlainCVE's suggestion, not vendor advice.

    Step 3
RESPONDRespondIf you find signs of compromise
  1. 01Review activity on login-protected routes

    The vendor has provided no detection guidance. PlainCVE suggests reviewing what administrators and other privileged accounts did on [Authorize] routes, looking for actions they did not take.

    Step 5
  2. 02Invalidate old tokens by replacing the key

    Our analysis: because validation uses Jwt:Key directly, replacing the key means every token signed with the old key, forged ones included, stops validating, and users will need to log in again.

    Step 4
HARDENHardenPrevent the next one
  1. 01Never commit signing keys to the repository

    Keep keys in environment variables or a secrets manager, generated separately for each deployment.

    Step 1
  2. 02Watch for a vendor fix

    At the time of writing no vendor advisory or fix commit is known, and the researcher reports current master still carries the same key.

Full remediation steps and notes

No vendor fix or advisory is known as of writing, so none of the following is vendor advice.

  1. Replace the key first. The researcher notes the default key is not used once Jwt:Key is overridden through another configuration source. In .NET you can supply the new value via an environment variable, user secret or command-line option. Use a long random string and never commit it.
  2. Mind the ordering. Our analysis: after the key changes, every token signed with the old key, including any forged ones, stops validating, and users will have to log in again. That is expected.
  3. Confirm it took effect. After deploying, check that the Jwt:Key actually in use is no longer the one in appsettings.json.

Attack flow

Read left to right: this is the order the attack happens in. A blue shield means the step can be stopped; the earlier, the better. Click an icon for details.

Read top to bottom: this is the order the attack happens in. A blue shield means the step can be stopped; the earlier, the better. Tap an icon for details.

BotSharp hard-coded JWT signing key: if the default key isn't replaced, an attacker can forge login tokens and impersonate known users (the CVE record says including admins): 1. Gets the default key from the public repository → 2. Signs a fake login token with that key → 3. Sends the fake token to the WebStarter API → 4. The system checks the signature with the same key, and it passes → 5. Acts as that user on login-protected API routesCVE-2026-108860 · BotSharp hard-coded JWT signing key: if the default key isn't replaced, an attacker canforge login tokens and impersonate known users (the CVE record says including admins)AttackerYour systemGets the default key from the public repository — WebStarter's appsettings.json commits Jwt:Key into the project, and the issuer and audience are both fixed to "botsharp". 1Gets the defaultkey from thepublic repositorySigns a fake login token with that key — The token names a user whose identity the attacker knows (the CVE record says this can include administrators; the finder's report says admin rights were not established). No account is needed. 2Signs a fake logintoken with that keySends the fake token to the WebStarter API — The attacker must be able to reach the API over the network. 3Sends the faketoken to theWebStarter APIThe system checks the signature with the same key, and it passes — The JWT handler takes its key straight from the Jwt:Key setting; WebStarter turns signature validation on, but it validates against a key everyone can obtain. 4The system checksthe signature withthe same key, andit passesActs as that user on login-protected API routes — The impact covers routes marked [Authorize], such as conversation creation; routes marked [AllowAnonymous] need no login anyway. 5Acts as that useron login-protectedAPI routesAttack pathCan be stopped herePlainCVE · plaincve.date/en/vulns/cve-2026-108860-botsharp-hardcoded-jwt-key · CC BY 4.0
BotSharp hard-coded JWT signing key: if the default key isn't replaced, an attacker can forge login tokens and impersonate known users (the CVE record says including admins): 1. Gets the default key from the public repository → 2. Signs a fake login token with that key → 3. Sends the fake token to the WebStarter API → 4. The system checks the signature with the same key, and it passes → 5. Acts as that user on login-protected API routesCVE-2026-108860 · BotSharp hard-codedJWT signing key: if the default keyisn't replaced, an attacker can forgelogin tokens and impersonate known user…Gets the default key from the public repository — WebStarter's appsettings.json commits Jwt:Key into the project, and the issuer and audience are both fixed to "botsharp". 1AttackerGets the default key from thepublic repositorySigns a fake login token with that key — The token names a user whose identity the attacker knows (the CVE record says this can include administrators; the finder's report says admin rights were not established). No account is needed. 2AttackerSigns a fake login token withthat keySends the fake token to the WebStarter API — The attacker must be able to reach the API over the network. 3AttackerSends the fake token to theWebStarter APIThe system checks the signature with the same key, and it passes — The JWT handler takes its key straight from the Jwt:Key setting; WebStarter turns signature validation on, but it validates against a key everyone can obtain. 4Your systemThe system checks the signaturewith the same key, and it passesActs as that user on login-protected API routes — The impact covers routes marked [Authorize], such as conversation creation; routes marked [AllowAnonymous] need no login anyway. 5AttackerActs as that user onlogin-protected API routesAttack pathCan be stopped herePlainCVE · CC BY 4.0plaincve.date/en/vulns/cve-2026-108860-botsharp-hardcoded-jwt-key
Free to use in reporting and teaching under CC BY 4.0. Attribution is already on the image.
  1. Attacker

    Gets the default key from the public repository

    WebStarter's appsettings.json commits Jwt:Key into the project, and the issuer and audience are both fixed to "botsharp".

    Defense: Override Jwt:Key with your own random value via an environment variable, user secret or command-line option, so the public key becomes useless.

  2. Attacker

    Signs a fake login token with that key

    The token names a user whose identity the attacker knows (the CVE record says this can include administrators; the finder's report says admin rights were not established). No account is needed.

  3. Attacker

    Sends the fake token to the WebStarter API

    The attacker must be able to reach the API over the network.

    Defense: Don't expose the WebStarter API directly to untrusted networks.

  4. Your system

    The system checks the signature with the same key, and it passes

    The JWT handler takes its key straight from the Jwt:Key setting; WebStarter turns signature validation on, but it validates against a key everyone can obtain.

    Defense: Once the key is replaced, tokens signed with the public key fail validation.

  5. Attacker

    Acts as that user on login-protected API routes

    The impact covers routes marked [Authorize], such as conversation creation; routes marked [AllowAnonymous] need no login anyway.

    Defense: Review administrator activity on login-protected routes for anything unusual.

Who is affected

ConditionAffected?
BotSharp WebStarter 5.2.0 or earlier + using the project’s shipped Jwt:Key + API reachable over the networkAffected
Jwt:Key already overridden with your own value via an environment variable, user secret or command-line optionThe researcher says the default key is not used in this case
Any known versionNo fixed version is known

The researcher confirmed the issue on r5.2-image-composition (commit a11ee03, tagged 2025-10-17) and on master commit 5151983; the key and validation setup are identical in both. Earlier releases were not tested. Our analysis is that the CVE’s “5.2.0” most likely refers to the r5.2-image-composition release tag, but no source says so outright.

How it works

After you log in, the server gives you a JWT (a signed “pass”) that you show with every later request. The server checks the signature with a secret signing key (here, a symmetric key) to confirm it issued the pass.

BotSharp’s WebStarter project writes this key directly into appsettings.json and commits it to the public repository, with the issuer and audience both fixed to botsharp. In the vendor’s code, the JWT handler takes its validation key straight from Jwt:Key, and WebStarter does turn signature validation on. The problem is that it validates against a key anyone can see. Unless a deployment overrides it, an attacker can sign their own passes and get past the login check on API routes marked [Authorize], such as conversation creation. The CVE record says this lets them impersonate any user whose identity they know, including administrators; the finder’s report only confirms passing the login check, explicitly does not establish administrative rights or access to a specific user’s data, and did not perform runtime validation. This maps to CWE-321 (use of hard-coded cryptographic key).

The flawed approach (conceptual illustration, not the original source code):

Show code example(csharp)
// The key ships with the source code
var key = config["Jwt:Key"]; // comes from appsettings.json committed to the repo

A safer approach (conceptual illustration):

Show code example(csharp)
// Take the key only from the deployment environment; refuse to start without one
var key = config["Jwt:Key"]; // supplied by an environment variable or secrets manager
if (string.IsNullOrEmpty(key) || key == ShippedDefaultKey)
    throw new InvalidOperationException("Set a unique Jwt:Key");

Timeline

DateEvent
2025-10-17r5.2-image-composition (commit a11ee03) tagged; the researcher confirmed this release is affected
UnknownWhen the researcher wrote the report, coordinated disclosure was in progress and no CVE had been assigned
2026-10-11VulnCheck publishes the CVE record; NVD receives it (not yet analysed); GitHub publishes unreviewed advisory GHSA-w9f8-hvcg-hgcm
2026-10-12Still not listed in CISA KEV

Further reading

  • Scoring: VulnCheck (the CNA) gives CVSS 4.0 9.3 and CVSS 3.1 9.1, both Critical; NVD has not scored it. The researcher’s writeup labels it “high, conditional”; PlainCVE’s reading is that this reflects the preconditions (key not replaced, API reachable).
  • A news site says successful exploitation can lead to complete host takeover, but the CVE record describes only identity impersonation on API routes and rates availability impact as None. No primary source supports host takeover, and this page does not repeat it.
  • Exploitation: it is not in CISA KEV, but that does not prove it hasn’t been exploited; there is no evidence either way. A news site reported that no standalone public exploit had been published when it wrote its article.
  • The GitHub advisory is unreviewed and does not link to any maintainer advisory. The CVE was assigned by VulnCheck, not the BotSharp maintainers. It was found by hieuPenguinnn. Every mention of “the researcher” on this page refers to the finder’s report (the page contains exploit material, so we do not link it; the CVE record lists it as a reference).

Verification Checked item by item against sources by AI under our review rules, all passed; not human-reviewed and not yet reproduced in our lab

AI review2026-10-18 · review rules

Verification records describe the environment and the result only, never reproduction steps or code that could attack other people’s systems. See our policy.

Sources

  1. CVE / NVD / OSVCVE-2026-108860 record (CVE Services API) · CVE Program / VulnCheck, 2026-10-11 · accessed 2026-10-12
  2. CVE / NVD / OSVNVD - CVE-2026-108860 · NIST, 2026-10-11 · accessed 2026-10-12
  3. AdvisoryGHSA-w9f8-hvcg-hgcm (unreviewed GitHub advisory) · GitHub, 2026-10-11 · accessed 2026-10-12
  4. Vendorsrc/WebStarter/appsettings.json at a11ee03 · SciSharp (GitHub) · accessed 2026-10-12
  5. VendorBotSharpOpenApiExtensions.cs at a11ee03 · SciSharp (GitHub) · accessed 2026-10-12
  6. OtherCVE-2026-108860 tracker entry · HOL Guard · accessed 2026-10-12
  7. OtherCVE-2026-108860: Use of Hard-coded Cryptographic Key in SciSharp BotSharp · OffSeq Radar · accessed 2026-10-12

Press brief

In one sentence

The open-source project BotSharp, through version 5.2.0, ships the WebStarter project's configuration file (appsettings.json) containing the key used to sign login tokens, and that key is visible to anyone in the public repository. If a deployment does not replace it, an unauthenticated remote attacker can sign their own tokens and impersonate known users; the CVE record says this includes administrators, but the finder's report says admin rights were not established and no runtime validation was performed. VulnCheck published the vulnerability on October 11, 2026, rating it 9.3 under CVSS 4.0; no fixed version is known.

Key facts

Severity
CVSS 4.0 9.3 / CVSS 3.1 9.1 (VulnCheck) cveawg.mitre.org
Affected versions
Through 5.2.0 cveawg.mitre.org
CVE published
2026-10-11 (assigned by VulnCheck) cveawg.mitre.org
Found by
hieuPenguinnn cveawg.mitre.org
Fixed version
Unknown (a third-party tracker lists it as not reported) hol.org

Confirmed

  • BotSharp WebStarter's appsettings.json in the official repository commits a Jwt:Key, with issuer and audience fixed to "botsharp".
  • As of 2026-10-12 it is not listed in CISA's Known Exploited Vulnerabilities catalog.

Unconfirmed / disputed

  • The CVE record (CNA) says that if the key is not overridden, an unauthenticated remote attacker can impersonate any known user, including administrators, on [Authorize]-protected API routes; the finder's report it cites was static analysis only and explicitly does not establish administrative rights, and no runtime validation was performed.
  • No fixed version or vendor advisory is known; the researcher reports current master still has the same key.
  • Severity labels differ: the CNA rates it Critical (9.1/9.3), while the researcher labels it "high, conditional".
  • A news site says it can lead to complete host takeover, but the CVE record describes only identity impersonation on the API, and no primary source supports that claim.
  • There is no evidence either way on whether it has been exploited in the wild.

Quotable line

When everyone holds the same stamp, a stamped document proves nothing.

Images

Download the share image (PNG) · Attack flow diagram (downloadable)

Please credit "PlainCVE" and link to this page. Full citation format is under "How to cite" below. Found a factual error? Report it.

How to cite this page

This article is CC BY 4.0. Please keep the attribution and link when republishing.

PlainCVE Team (2026). "BotSharp hard-coded JWT signing key: if the default key isn't replaced, an attacker can forge login tokens and impersonate known users (the CVE record says including admins)". PlainCVE. https://plaincve.date/en/vulns/cve-2026-108860-botsharp-hardcoded-jwt-key (accessed YYYY-MM-DD)
BibTeX
@misc{cve2026108860botsharphardcodedjwtkey2026,
  title  = {BotSharp hard-coded JWT signing key: if the default key isn't replaced, an attacker can forge login tokens and impersonate known users (the CVE record says including admins)},
  author = {PlainCVE Team},
  year   = {2026},
  howpublished = {PlainCVE},
  url    = {https://plaincve.date/en/vulns/cve-2026-108860-botsharp-hardcoded-jwt-key},
  note   = {Updated 2026-10-18}
}