Overview
Casdoor versions 2.362.0 and earlier contain several identity and access management vulnerabilities that enable broad authentication bypass and privilege escalation. These flaws relate to Casdoor’s Security Assertion Markup Language (SAML) processing, account binding, and token exchange mechanisms. An attacker able to interact with Casdoor’s authentication interface may impersonate users, bypass multifactor authentication (MFA), forge and replay assertions, and achieve persistent unauthorized access.
Description
Casdoor is an open-source identity and access management (IAM) platform and Model Context Protocol (MCP) gateway that provides authentication, single sign-on, and multi-protocol identity services. It is designed to centralize and streamline access control, allowing organizations to manage user identities and permissions across multiple applications and environments.
CVE-2026-9090
Casdoor versions 2.362.0 and earlier contain a vulnerability that allows an attacker to bypass authentication by supplying an arbitrary signing certificate. The buildSpCertificateStore function extracts the X.509 certificate directly from the incoming SAMLResponse instead of using the trusted pre-configured Identity Provider certificate, allowing an attacker to forge assertions signed with an attacker-controlled key.
CVE-2026-9091
A logic flaw in Casdoor’s social‑login binding flow allows users to bypass configured MFA requirements. The binding‑rule code path in controllers/auth.go calls HandleLoggedIn directly without invoking checkMfaEnable. Any user authenticating via this path is logged in without MFA enforcement.
CVE-2026-9092
Casdoor contains a vulnerability involving unverified email binding that may enable account takeover. The getExistUserByBindingRule function matches users by email address without checking the email_verified claim returned from upstream providers, and the idp.UserInfo struct does not include a EmailVerified field. Therefore, an attacker can supply an unverified email claim from an upstream provider to take over accounts that use the same email address.
CVE-2026-9093
Casdoor’s SAML service provider implementation does not validate the AudienceRestriction element in SAML assertions. Casdoor never sets the AudienceURI field to specify which service provider the assertion is intended for, and does not check for audience mismatch warnings alerted by WarningInfo.NotInAudience. As a result, Casdoor may improperly accept assertions that were issued for a different service provider.
CVE-2026-9094
Casdoor contains a vulnerability that enables cross-organization token exchange. The GetTokenExchangeToken function in object/token_oauth.go validates JWT signatures but does not verify that the token’s user belongs to the same organization as the target application. This can result in privilege escalation across organizational boundaries.
CVE-2026-9095
Casdoor maps SAML assertions to user sessions without replay protection. The ParseSamlResponse() function in object/saml_sp.go calls sp.RetrieveAssertionInfo() and immediately maps the result to a user session. There is no assertion ID cache, OneTimeUse condition enforcement, or replay detection anywhere in the SAML SP code path. As a result, an attacker can replay a previously captured SAML assertion to obtain an authenticated session for the assertion’s subject, including administrator accounts, without needing the user’s password or MFA credentials.
CVE-2026-9096
Casdoor does not enforce SAML assertion time bounds. The gosaml2 library reports all time-validation results, including NotOnOrAfter and NotBefore, in the assertionInfo.WarningInfo field. However, ParseSamlResponse() never reads this field, meaning that time bounds are computed by the library but silently discarded before the user session is issued.
CVE-2026-9097
Casdoor does not verify that a JWT used for token exchange is still active. The GetTokenExchangeToken() function in object/token_oauth.go validates the JWT signature and parses its claims, but never queries the Token table to verify whether the subject token has been revoked or invalidated. Because the revocation check is entirely absent, administrators are unable to terminate active sessions or revoke compromised tokens.
CVE-2026-9098
The SAML callback handler in controllers/auth.go accepts any well-formed SAMLResponse sent to /api/acs without verifying that it corresponds to an AuthnRequest previously issued by Casdoor. Additionally, if an administrator disables or deletes an identity provider (IdP) after a SAML flow has started, the handler still processes the response using the provider snapshot loaded at the start of the request. As a result, an attacker controlling a registered upstream IdP can send unsolicited SAML responses, or replay a legitimately captured response in a different session or after the original flow has ended. In both cases, Casdoor accepts the response and issues a session, enabling persistent unauthorized access.
Impact
Exploitation of these vulnerabilities can allow attackers to impersonate users, bypass authentication controls, and escalate privileges across Casdoor deployments.
CVE‑2026‑9090, CVE‑2026‑9093, CVE‑2026‑9095, CVE‑2026‑9096, CVE‑2026‑9098:
Multiple flaws in SAML processing allow assertion forgery or replay, misuse of assertions across sessions, and the processing of expired or unsolicited SAML responses. Because certificate trust is not enforced, time bounds and audience restrictions are ignored, and responses are not correlated to prior AuthnRequests, attackers can submit malicious or previously-captured assertions to obtain authenticated sessions for arbitrary users, including administrators.
CVE‑2026‑9091, CVE‑2026‑9092:
Weaknesses in MFA protection and binding logic further contribute to the risk of account compromise, enabling attackers to bypass MFA and potentially take over other accounts via unverified email claims. An attacker can exploit these flaws to gain persistent unauthorized access by bypassing configured authentication requirements or security controls.
CVE‑2026‑9094, CVE‑2026‑9097:
The discovered token-exchange flaws enable cross‑organization privilege escalation and prevent administrators from reliably revoking tokens. Because user‑organization membership is not validated and token revocation status is not checked, compromised or malicious tokens may be exchanged for elevated privileges in other organizations, and administrators cannot reliably terminate active sessions.
Solution
Unfortunately, we were unable to reach the Casdoor team to coordinate this vulnerability, and a patch is not yet available. Users are advised to implement stricter identity governance controls and utilize external validation tools to better enforce application boundaries. Restrict identity provider (IdP) usage only to trusted providers, reinforce high-privilege accounts with additional authentication paths such as downstream MFA, and monitor logs for any unusual SAML or token activity to reduce the exploitability of these issues.
Acknowledgements
We extend our thanks to Zixu (Jason) Zhou (University of Toronto, PhD student), David Lie (University of Toronto, Professor), Ilya Grishchenko (University of Toronto, Postdoc), and Xiangyu Guo (University of Toronto, PhD student) for researching and reporting these vulnerabilities. This document was written by Molly Jaconski.

Overview
A privilege escalation vulnerability, nicknamed “Dirty Frag,” has been discovered in the Linux kernel versions 4.10 and later. This vulnerability is a result of chaining together two previously discovered vulnerabilities, xfrm-ESP Page-Cache Write CVE-2026-43284 and the RxRPC Page-Cache Write CVE-2026-43500. This vulnerability was publicly disclosed on May 07, 2026.
Description
Dirty Frag is a Linux kernel vulnerability affecting the IPv4/IPv6 fragmentation and reassembly subsystem. The issue stems from improper handling of overlapping or malformed fragment offsets during the reassembly process. An attacker capable of sending crafted network packets to a vulnerable host can exploit the flaw to trigger memory corruption conditions.
The publicly documented proof of concept demonstrates that fragmentation logic can be manipulated such that the kernel processes inconsistent fragment states, enabling a controlled write out-of-bounds scenario. When successfully exploited, this can result in local or remote denial of service (kernel panic) and, depending on configuration and kernel build options, may create a primitive for more advanced memory manipulation.
The vulnerability arises from insufficient validation of fragment metadata during reassembly, specifically around:

Incorrect or incomplete enforcement of fragment boundary checks
Acceptance of overlapping fragments in unsafe sequences
Inadequate cleanup when transitions occur between valid and invalid fragment states

The fragment queue logic in affected kernels does not fully verify that fragment offsets, sizes, and overlap conditions remain consistent throughout reassembly. This allows malformed sequences to be processed without proper rejection.
Impact
The primary security concern is potential privilege escalation, similar in nature to the previously disclosed VU#260001 (“Copy Fail”) vulnerability.
Depending on system configuration, kernel hardening features, and network exposure, successful exploitation may result in:

Local or remote denial of service through kernel panic
Memory corruption within the Linux networking stack
Privilege escalation
Container escape in certain containerized environments
Additional exploit primitives when chained with other vulnerabilities

Solution
Update Linux distribution
Update your distribution’s kernel package as soon as vendor patches become available. Most major Linux distributions are expected to release fixes through their standard update channels.
Workarounds (if patching is not immediately possible):
1) Disable at-risk modules (if loaded and loadable):
Use the following command to remove the modules in which the vulnerabilities occur and clear the page cache.
sh -c “printf ‘install esp4 /bin/falseninstall esp6 /bin/falseninstall rxrpc /bin/falsen’ > /etc/modprobe.d/dirtyfrag.conf; rmmod esp4 esp6 rxrpc 2>/dev/null; echo 3 > /proc/sys/vm/drop_caches; true”
Note: you can verify if a module is currently being used using lsmod and the Used field or reviewing refcnt data in /sys/module/<module_name>/refcnt for e.g., cat /sys/module/esp4/refcnt
2) If affected modules esp4, esp6, rxrpc are compiled into the kernel (not a dynamic module), the following parameter can be added to grub, systemd-boot, or grubby, depending on your boot configuration:
initcall_blacklist=esp4,esp6,rxrpc
This prevents the module from initializing at boot time. A system reboot is required for this change to take effect.
Mitigation for Containers
For containerized environments, where this vulnerability may be leveraged for container escape, consider applying one or more of the following mitigations:

Secure computing (seccomp) filtering: Restrict or deny system calls that create sockets using the AF_ALG address family (protocol 38) and AF_RXRPC (protocol 33) .
AppArmor policies: Use AppArmor to block creation of AF_ALG sockets and AF_RXRPC via the network alg rule.
eBPF-based enforcement: Deploy BPF-based controls to deny socket creation with address family AF_ALG (38) and AF_RXRPC (33).

Acknowledgements
This vulnerability was disclosed by Hyunwoo Kim. This document was written by Bob Kemerer.

Overview
Three vulnerabilities have been discovered in the SGLang project, two enabling remote code execution (RCE), and one regarding a path traversal vulnerability. In order for an attacker to exploit these vulnerabilities, the multimodal generation mode must be enabled, and an attacker must have network access to the SGLang service. No patch is available at this time, and no response was obtained from the project maintainers during coordination.
Description
SGLang is an open-source framework for serving large language models (LLMs) and multimodal AI models, supporting models such as Qwen, DeepSeek, Mistral, and Skywork, and is compatible with OpenAI APIs. Three vulnerabilities have been discovered within the tool and are tracked as follows:
CVE-2026-7301
The multimodal generation runtime scheduler’s ROUTER socket contains a sink that calls pickle.loads() on incoming messages, enabling RCE when exposed to the internet.
This vulnerability is distinct from CVE-2026-3060 and CVE-2026-3059, which would be open to the Internet via the ZMQ broker, which automatically binded to all network interfaces without user awareness. CVE-2026-7301 is exposed to the internet by default through the scheduler host, which binds to 0.0.0.0 by default.
CVE-2026-7302
The multimodal generation runtime is vulnerable to an unauthenticated path traversal vulnerability, allowing an attacker to write arbitrary files anywhere the server process has write access, by including ../ sequences in the upload filename when sent to specific endpoints.
CVE-2026-7304
The multimodal generation runtime is vulnerable to unauthenticated remote code execution when the –enable-custom-logit-processor option is enabled, as Python objects loaded via dill.loads() will be deserialized without validation.
Impact
If exploited, these vulnerabilities could allow an unauthenticated attacker to achieve remote code execution or arbitrary file writes on the host running SGLang. Deployments that expose the affected interface to untrusted networks are at the highest risk of exploitation.
Solution
Until a patch is available, affected users should consider the following mitigations:
Mitigation

Restrict access to the service interfaces and ensure they are not exposed to untrusted networks.
Implement network segmentation and access controls to prevent unauthorized interaction with the vulnerable endpoints.

Acknowledgements
Thanks to the reporter, Alon Shakevsky. This document was written by Christopher Cullen.