🔥 CyberForge CVE of the Day #075
🚨 CVE-2026-108860 — BotSharp: JWT authentication bypass through a published default signing secret
A bearer identity can look valid while its signing secret is already public. Start with actual API trust, then follow the accepted identity into its permissions and operations.
VulnCheck identifies BotSharp through 5.2.0. WebStarter ships a usable HMAC signing secret; its verifier trusts the configured value. The path requires a reachable deployment retaining that published default. CNA vectors require no prior credentials or victim interaction.
⚠️ Prioritise affected reachable instances retaining exposed trust. A file, package update or accepted response alone cannot settle exposure or compromise.
🗓️ Case status checked: 12th October 2026, 09:50:49 UTC / 10:50:49 BST. No verified fixed release; linked research is static-only with downstream operations untested.
🎯 THE QUICK HIT
What failed? A usable shared JWT signing secret ships in public source. A caller holding that effective secret can present a bearer identity the configured check accepts. HMAC itself is not shown to be broken.
Who should check? Relevant WebStarter owners through the CNA's 5.2.0 ceiling. Confirm the serving build, effective signing key, validation setup and real API reachability, including every serving copy.
What is the impact? The CNA describes known-user impersonation, including administrators. The linked research is static-only and leaves particular downstream rights/actions untested. Actual permissions and effects need deployment evidence.
Start with effective trust. Resolve overrides privately, then replace and retire exposed trust through the application/identity owner. No verified fixed release was established; obtain maintainer guidance.
Follow the trail. Join accepted requests to available legitimate issuance, backing identity, object activity and changes using node, request/trace and bounded UTC time. Preserve sources before expiry.
Escalate corroborated unauthorised effects. A default-key match supports exposure; unexplained protected activity is a lead. Neither an accepted response nor absence of a fresh login proves compromise.
Be careful with normal bearer reuse, SSO, stale files, runtime overrides and old verifiers. A non-default file value or a completed change ticket cannot settle all those questions.
🔑 KEY DETAILS
• CVE-2026-108860 — SciSharp BotSharp, WebStarter / BotSharp.OpenAPI bearer authentication.
• VulnCheck CNA: Critical, CVSS v3.1 9.1.
• Exact v3.1 vector: CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:N.
• Additional CNA assessment: Critical, CVSS v4.0 9.3.
• Exact v4.0 vector: CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:H/VI:H/VA:N/SC:N/SI:N/SA:N.
• NVD: VulnCheck-attributed v3.1 Primary / v4.0 Secondary, not independent NIST scoring.
• CWE-321: Use of Hard-coded Cryptographic Key. Shared HMAC secret; not an asymmetric public verification key.
• Network, low complexity, no prior privileges or victim interaction. CNA impersonation concerns a known target identity.
• CNA custom range: through 5.2.0 inclusive. Exposure depends on a relevant reachable verifier retaining the published default as effective trust.
• Documented capability: authentication bypass and CNA-described known-user/admin impersonation. Actual protected effects depend on the deployment; universal host RCE/root is not established.
• Settings: Jwt:Key, Jwt:Issuer and Jwt:Audience. Normal published issuer/audience label: botsharp. These names are product context, not malicious IOCs.
• Verified fixed release: none at cutoff. Latest returned r5.2-image-composition and examined current master retain the affected 5.2.0 source/default trust.
• CVE PUBLISHED on 11 October; NVD Received. No CISA ADP/SSVC assessment found.
• KEV: no exact match; catalogue 2026.10.08, released 8th October 20:09 UTC, 1,739 entries. Feed/mirror agree; catalogue predates publication.
• EPSS: HTTP 200, total 0, empty data. Probability, percentile and score date unavailable, not zero.
• Finder: hieuPenguinnn. Linked research is static-only with an unexecuted sequence; no independent runtime reproduction or field exploitation verified here.
🧠 WHAT THE TRUST FAILURE MEANS
The project configuration commits a usable HMAC secret. WebStarter enables validation, and the bearer handler builds its signing key from the configured string. Verification can behave as designed while signing authority is no longer exclusive. Issuer labels and expiry checks cannot restore a secret already known to others.
The defender sequence:
1. Identify the relevant serving verifier and effective trust.
2. Establish whether the default was trusted during a reachable interval.
3. Examine accepted protected activity and its attributed principal.
4. Follow backing-user/authorisation checks into the actual operation.
5. Retire exposed trust and separately resolve earlier effects.
The CNA describes known-user/admin impersonation. Its linked researcher explicitly leaves specific downstream outcomes untested; our source review found claim-derived identity plus backing-user/authorisation operations. Preserve those lanes rather than certifying every accepted principal as a demonstrated all-powerful account. No signing value, token or request recipe is supplied.
📦 APPLICABILITY — BUILD, EFFECTIVE CONFIGURATION AND API PATH
Record owner, stable node, serving binary/image and build provenance. The cited release declares 5.2.0 / net8.0. Installed files, tags and source checkouts can differ from serving code.
http://ASP.NET Core can override shipped JSON through environment-specific settings, environment variables, command-line inputs and configured providers. Jwt__Key is the environment-variable form. Confirm actual precedence and effective trust privately.
A file-only default match is a lead until overrides/running state are resolved. A different file value proves neither effective use nor strength/secrecy. State the evidence's scope.
Include active replicas, rollout overlap, standby/recovery and exposed development copies. Map proxy routes/direct listeners and the event's bearer/cookie scheme. JWT key rotation is not universal cookie/SSO revocation.
The CNA interval is custom and names no repair release. Do not invent 5.2.1, certify current master or clear an unfamiliar number. Obtain build/maintainer confirmation.
🕰️ TIMELINE AND THE EXPOSURE WINDOW
17th October 2025, 19:39 UTC: latest returned r5.2-image-composition release; its tag resolves to the cited commit. The year is verified through the release API, not inferred from a short “17 Oct” label.
29th September 2026, 03:13 UTC: examined current master commit, still declaring 5.2.0 and retaining the matching default-secret fingerprint/verifier.
11th October 2026, 13:26 UTC: CNA publication. NVD followed at 14:17 UTC. These are record events, not proof of first exploitation.
12th October 2026, 09:50:49 UTC: final case-status refresh. No verified corrected release, field campaign or independent runtime reproduction established in this review.
Set the hunt window from actual build, key-trust and reachability history. Start at the earliest supported exposed-trust time; end only when the last relevant verifier retires it. Record uncertain boundaries and retention. Publication day alone is not the exposure window.
🧭 THE SOC TRAIL — SIX INVESTIGATIVE CHECKS
Objective: investigate whether accepted protected activity used unauthorised authority and produced a real effect. These checks are Forge analysis. Define assets, UTC interval, clock uncertainty, permissions, schema and source health first. The image has empty reader boxes.
C01 — Scope effective signing trust
Action/location: join inventory, serving build/image, approved secret-provider/configuration history, validation setup and ingress/direct-listener evidence. The owner confirms the effective key privately across every relevant node.
Signal/correlation: an applicable build, reachable protected bearer surface and actual default-key trust support exposure. Join stable instance/node, build, key-version or owner attestation and dates. A file-only result leaves runtime scope unresolved.
Benign causes/limits: unused samples, overrides, offline copies and stale manifests. Missing/different input is not clearance or a strength test.
Escalate: exposed trust needs urgent application/identity ownership. Give unknown effective state an owner/deadline; it is a scope gap, not compromise.
C02 — Preserve request, identity and change evidence
Action/location: preserve existing ingress/proxy, app/authentication, legitimate token/SSO issuance, deployment and secret-change records over the justified interval. Protect sensitive originals; use redacted working material.
Signal/correlation: authenticated protected activity, verifier/key changes or material source gaps. Join original record IDs, UTC/offsets, node, request/trace and auth scheme where retained. Record filtering and retention.
Limits: console/conversation logs do not guarantee HTTP/issuance audit. Sampling, rotation and missing collection can hide history; enabling logging now cannot restore it.
Escalate: imminent evidence loss and absent required sources go to collection/IR owners. Containment of demonstrated harm may precede ideal collection. Keep tokens and secrets private.
C03 — Hunt protected activity needing an authority explanation
Action/location: compare actual protected-route use with subject behaviour, approved automation and available legitimate issuance. Map source route examples to the real app and anonymous-action exceptions.
Signal/correlation: unexpected privileged activity or unusual subject/source combinations. Join node, identity, request, proxy-origin context, available token identifier and time to independent issuance/authentication. Token claims are not independent evidence of rightful origin.
Benign causes/limits: normal reuse, SSO, NAT, service identities, role changes and missing issuance logs. No fresh /token request is not proof of forgery.
Escalate corroborated unexplained activity to identity-owner/IR review. Acceptance or decoding alone remains a lead.
C04 — Establish the protected operation and effect
Action/location: follow retained requests into backing-user/role, agent/conversation, object-access and configuration records relevant to the action. Examine its own authorisation and result.
Signal/correlation: independently supported unapproved reads, writes or identity/role changes. Join request/trace, target object, accepted/backing identities, node and time; compare approved changes.
Benign causes/limits: maintenance, migrations, approved edits and automatic user creation. The reviewed /user/me GET can create users when enabled; use retained evidence, not production probes.
Escalate: corroborated unauthorised effects warrant IR with observed scope. A 2xx, error, source path or accepted principal alone does not establish the business result.
C05 — Restore exclusive signing authority
Action/location: the application/identity owner replaces the exposed secret and retires its trust across relevant issuers/verifiers, with approved restrictions where needed. The project release fix remains unverified.
Signal/correlation: new secret ownership/version, completed deployment/reload evidence and no serving copy retaining exposed or fallback trust. Join ticket, node, effective state and retirement times; keep values private.
Benign causes/limits: rollout overlap, cached options, unloaded secret-manager changes and retained fallback keys. Old verification trust preserves the path during its retention. Cookie/SSO schemes need separate decisions.
Escalate: incomplete retirement/service disruption goes to the change/identity owner; continuing unauthorised effects go to IR. Retire the exposed shared HMAC secret, not asymmetric public-key validation.
C06 — Verify rollout, service health and remaining gaps
Action/location: reconcile serving nodes and recovery copies with approved effective-state evidence. Complete applicable restarts/reloads, normal owner-controlled authentication/service checks and collection-health review.
Signal/correlation: exclusive trust after change, ordinary service continuity and node parity. Record final old-trust retirement, post-change interval and remaining unexplained effects.
Limits: disconnected replicas, stale inventory, late logs and missing history. Metadata is not a JWT/upgrade test; no forgery test is supplied or performed.
Escalate: remaining exposed trust, recurrent unauthorised activity and coverage gaps need named owners. Keep exposure, suspicion, corroborated compromise and insufficient telemetry distinct. No findings is not proof of a clean system.
📝 THE ANALYST HANDOVER
Record asset/owner, node/build, effective trust, reachability/window, original source IDs, accepted/backing identity, objects/effects, approved explanations, gaps, change/final-retirement times, confidence and next owner. Keep event, ingestion and action times separate.
A negative finding names the nodes, interval, sources and limits reviewed. Missing issuance/object history can prevent reliable clearance. Preserve restricted originals/acquisition details alongside the redacted summary.
🔎 INDICATORS AND OBSERVABLE BEHAVIOUR
No independently verified CVE-specific malicious IP/domain/hash set was established. Public config and source description support exposure assessment, not a campaign attribution.
Jwt:Key, botsharp issuer/audience, ordinary bearer headers and route names are normal context, not malicious IOCs. An anonymous action does not demonstrate crossing that action's authentication gate.
Useful lead: unexpected protected activity during an exposed-trust period, aligned with independent unauthorised effects. Normal integrations, reuse and missing logs can resemble parts of that trail. Establish correlation before declaring compromise.
Do not submit captured tokens to public decoder sites or replay suspicious requests. Claims can contain sensitive data, and decoding cannot certify rightful issuance. Use authorised retained metadata.
🧰 TOOLS AND BOUNDED CHECKS
Check A — What signing state does this evidence describe?
Use approved configuration/secret-management views and local JSON inspection on an authorised copy. Resolve provider precedence. The offline companion compares a supplied setting with the published-default fingerprint without printing key/digest, creating tokens or contacting the API.
A match is a file observation; a different value needs runtime confirmation. Missing/blank/redacted, ambiguous, duplicate, malformed or oversized input is not safe. The aid requires strict plain JSON and cannot assess secrecy, history or compromise.
Check B — Which build is serving?
Use deployment provenance or a saved one-container Docker inspection. Project name, image reference, immutable image ID and state, omitting environment/command values. Reconcile with source/SBOM and the actual node. Use equivalent supported build records outside containers.
The projection reads saved JSON only. A tag/inactive container is not fix evidence. Both aids passed 40 synthetic scenarios; no live BotSharp/JWT, Docker daemon or customer data was tested.
Check C — Does the trail support the conclusion?
Use approved record/SIEM views over a bounded UTC interval, retaining schema, source-health, limits and errors. Join accepted activity to independent authority and actual effects. Conditional conversation logs do not replace auth/object audit. New HTTP logging needs owner review, can expose private data/add load and cannot recover history.
🩹 REMEDIATION AND VERIFICATION
1 — Assign ownership and confirm effective exposure: serving build, provider/key trust, verifier and reachable routes. Use approved restrictions where immediate replacement needs preparation; check alternate listeners and integrations.
2 — Preserve relevant request/identity/object/change evidence before expiry or cleanup, without delaying containment of demonstrated harm. Keep signing values and bearer tokens in restricted evidence handling.
3 — Restore signing authority. The researcher proposes removing usable secrets from source, requiring a strong private deployment secret and failing startup when required trust is absent or known public. This is recommended engineering, not a verified merged/tested vendor patch. Obtain maintainer guidance.
4 — Verify every issuer/verifier and applicable restart/reload. Record effective secret version, final old-trust retirement and normal service health. Cached settings, retained fallback keys or an old serving replica can preserve exposure after the main node changes.
5 — Assess cookie/SSO sessions, connected credentials and earlier protected effects separately. Scope action to exposure, observed access and the incident plan; JWT key rotation is not universal revocation or historical clearance.
6 — Close the investigation with evidence and owners. Review corroborated unauthorised effects, continuing anomalies and coverage gaps. An applied configuration change and case closure require separate acceptance records.
Changing only issuer labels, user passwords or Swagger visibility does not retire exposed signing trust. Do not disable signature validation. A verified deployment-specific trust change can address this path while the project release repair remains unknown.
🧾 EVIDENCE SEPARATION
CNA/official: identifier, range, hard-coded-key mechanism, known-user/admin description, scores/CWE and dated catalogue/model observations.
Project source: configured-key verifier, validation-enabled startup, identity/backing-check context and release/current-source observations; read statically.
Researcher: static argument, illustrative unexecuted sequence and proposed repair, with downstream outcomes expressly untested.
Forge analysis: the SOC trail, authority restoration and rollout acceptance. No customer conclusion follows without deployment evidence.
Unknown: verified fixed release, field campaign, universal RCE, every operation's result, malicious IOC set, EPSS row or real deployment integrity.
🔥 CYBERFORGE VERDICT
CVE-2026-108860 can undermine the API's identity boundary while signature checks remain enabled. Prioritise affected reachable WebStarter instances retaining the exposed secret. Catalogue absence and unavailable EPSS do not answer applicability or integrity.
Defender order: scope actual trust → preserve useful records → retire exposed trust on every serving copy → verify ordinary operation and investigate earlier effects. Resolve release guidance with the maintainer/build owner instead of guessing a floor.
The decisive question joins an accepted identity to authority and actual effects supported by evidence.
💜 A signature deserves trust only when the authority behind its key does.
🔗 SOURCES AND FURTHER READING
VulnCheck CNA advisory:
https://www.vulncheck.com/advisories/botsharp-through-5.2.0-authentication-bypass-via-hard-coded-jwt-signing-key
CVE record:
https://www.cve.org/CVERecord?id=CVE-2026-108860
NVD:
https://nvd.nist.gov/vuln/detail/CVE-2026-108860
CNA-linked research, including its static-review limits:
https://hackmd.io/@1ExmmukzRMWN7B4gQ4W-4Q/scisharp-botsharp-public-jwt-signing-key
Project release history; no verified CVE repair at cutoff:
https://github.com/SciSharp/BotSharp/releases
Microsoft configuration and provider precedence:
https://learn.microsoft.com/en-us/aspnet/core/fundamentals/configuration/?view=aspnetcore-8.0
CISA KEV:
https://www.cisa.gov/known-exploited-vulnerabilities-catalog
FIRST EPSS query; empty result at cutoff:
https://api.first.org/data/v1/epss?cve=CVE-2026-108860
#CyberSecurity #CVE #BotSharp #JWT #BlueTeam #ThreatHunting #IncidentResponse #SOC #CyberForge
