Security readout for executives and security teams
Plain-English summary
Casdoor 2.362.0 and earlier may let a valid token from one organization be exchanged for access to an application in another organization. For businesses using Casdoor across tenants or business units, this could break organizational isolation and allow unauthorized access.
Executive priority
Treat this as urgent for any Casdoor-backed identity environment. The business risk is unauthorized cross-organization access, which can affect confidentiality, integrity, and availability if tenant boundaries are trusted for access control.
Technical view
The issue is in GetTokenExchangeToken in object/token_oauth.go. JWT signatures are validated, but the function does not verify that the token user belongs to the same organization as the target application, enabling cross-organization privilege escalation.
Likely exposure
Highest exposure is Casdoor deployments running version 2.362.0 or earlier, especially multi-organization instances using OAuth token exchange for application access.
Exploitation context
The provided sources rate this as critical with CVSS 9.8. They do not state active exploitation, and KEV is false in the bundle. Exploitability is still concerning because the vector is network-based with low complexity and no required privileges or user interaction.
Researcher notes
Evidence points to an authorization check failure after JWT signature validation. The key research question is whether token exchange paths bind the source user organization to the target application organization. Do not assume a patch version from the supplied sources.
Mitigation direction
- Inventory all Casdoor deployments and confirm whether any run version 2.362.0 or earlier.
- Check Casdoor and CERT guidance for an official fixed version or mitigation.
- Prioritize vendor-confirmed upgrade or configuration changes for multi-organization deployments.
- Review tenant isolation assumptions for applications relying on Casdoor token exchange.
- Increase monitoring for unusual cross-organization authentication or token exchange activity.
Validation and detection
- Confirm Casdoor version on all production, staging, and internet-facing instances.
- Identify whether OAuth token exchange is used for applications across organizations.
- Review access logs for unexpected token exchanges involving different organizations.
- Check whether target applications enforce independent organization membership checks.
- Document findings and track remediation against vendor or CERT guidance.
Public sources used
Generated from the cited source records. This long-tail analysis has not been individually reviewed by a named human.
Conservative CVE-to-ATT&CK context
These mappings and lookup hints may be relevant to the vulnerability behavior, CWE, affected product, or exposure path. Glexia-inferred context is not an official MITRE, ATT&CK, CWE, or CVE Program mapping.
ATT&CK lookup starting points
Use these exact CWE pages and searches to review the Glexia ATT&CK library from this CVE's weakness and description context.
CWE-284: Authorization and privilege behavior lookup
Authorization weaknesses can support privilege escalation and valid-account review, depending on exploit path. Open the exact CWE lookup page first, then review the ATT&CK searches from that MITRE weakness context. This is a Glexia lookup hint, not an official ATT&CK mapping.
Open ATT&CK lookupCredential and access behavior lookup
The CVE wording references authentication or credential exposure, so valid-account and credential-access review may help. This is a Glexia inferred lookup path, not an official MITRE, ATT&CK, or CVE Program mapping.
Open ATT&CK lookupPrivilege behavior lookup
The CVE wording references privilege impact, so privilege escalation and authorization behavior review may help. This is a Glexia inferred lookup path, not an official MITRE, ATT&CK, or CVE Program mapping.
Open ATT&CK lookupCVE-2026-9094 mapping review
Open the CVE-to-ATT&CK bridge for reviewed, inferred, or future official mappings tied to this CVE.
Open ATT&CK lookup- Severity
- Critical
- CVSS
- 9.8 (3.1)
- Known Exploited
- No
- Published
Vector: CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H
CNA and ADP enrichment extracted from CVE v5
These fields come from the CVE record and ADP containers, not from Glexia's Take. They preserve time-varying source decisions such as CISA SSVC, KEV status, CVSS metrics, and provider references.
SSVC decision data
CVSS vector scores
1 official scoreWe collect every scored CVSS vector available in the official CNA and ADP containers. When more than one version is present, the table keeps the source vectors side by side instead of collapsing them into the highest score.
CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H3.95.9CISA-ADPVulnerability scoring details
Base CVSS 3.1 score
9.8CriticalVector: CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H
Vulnerability timeline
Timeline events are normalized from CVE metadata, CNA source timelines, ADP timelines, and KEV metadata when present.
- CVE reservedCVE Program
The CVE ID was reserved by the assigning CNA.
- CVE publishedCVE Program
The CVE record was published.
- CVE updatedCVE Program
The CVE record metadata indicates this as the latest update time.
ADP provider summaries
Source materials
- CVE List V5 sourceCVE List V5
- https://kb.cert.org/vuls/id/780781CVE reference, certcc
Products and packages named in the record
CWE details
CWE links open Glexia weakness intelligence pages with official CWE context, developer remediation guidance, and related CVE mappings.
Improper Access Control
Improper Access Control represents a recurring weakness pattern that can create exploitable paths when design, validation, or implementation controls are missing.