CVE-2026-108572: SSRF via pgtUrl in Casdoor’s CAS Proxy Validation (CasP3ProxyValidate)

Summary

Casdoor, the open-source identity provider, contains a server-side request forgery vulnerability tracked as CVE-2026-108572. The flaw sits in the function CasP3ProxyValidate in the file controllers/cas.go, part of the component the disclosure labels Proxy Validation. Manipulating the argument pgtUrl leads to server-side request forgery, classified as CWE-918.

Affected versions run up to 3.164.0/4.10.0, and upgrading to version 4.11.0 addresses the issue. The attack may be performed remotely, the CVSS 4.0 vector requires only low privileges and no user interaction, and the base score is 2.1 (LOW). The exploit has been disclosed publicly and may be used, which argues for prompt patching of exposed instances despite the low rating. The issue was discovered by pngyuo, a VulDB user, and the CVE was assigned by VulDB.

Technical Analysis

CWE-918, server-side request forgery (SSRF), describes a class of bugs in which an application fetches a URL — or otherwise initiates an outbound request — based on input an attacker controls, without sufficiently validating the destination. The server making the request typically sits inside a network the attacker cannot reach directly, so the flaw lets the attacker borrow the server's network position: requests can be aimed at attacker-controlled hosts or at internal destinations that would otherwise be off-limits. This is the weakness class the disclosure assigns to CVE-2026-108572.

The disclosure pinpoints the vulnerable code precisely: the function CasP3ProxyValidate in the file controllers/cas.go, within the component labeled Proxy Validation. The manipulated argument is pgtUrl. The function name indicates that this code implements the proxy validation functionality of the CAS (Central Authentication Service) protocol that Casdoor supports, and the parameter name pgtUrl corresponds to the proxy-granting-ticket URL argument used in that protocol's proxy validation flow. An SSRF classification for this argument is consistent with the server initiating an outbound request based on the URL supplied in pgtUrl during proxy validation. The exact request flow, the validation logic applied to the argument, and the endpoint routing details are not fully disclosed in the available sources.

Identity providers occupy a sensitive position in most architectures: they hold authentication state and are trusted by relying applications. A flaw inside a protocol handler such as proxy validation is therefore worth attention even when the scored impact is low, because the code path exists specifically to make outbound requests as part of the protocol — exactly the pattern that turns into SSRF when destination validation is missing. That structural observation is consistent with the disclosure's classification; the specific behavior of this implementation is not fully disclosed.

What the disclosure establishes directly:

The vulnerable argument is pgtUrl; manipulating it leads to server-side request forgery.
The attack may be performed from remote.
The exploit has been disclosed publicly and may be used.
Upgrading to version 4.11.0 addresses the issue.

The CVSS 4.0 vector is CVSS:4.0/AV:N/AC:L/AT:N/PR:L/UI:N/VC:L/VI:N/VA:N/SC:N/SI:N/SA:N/E:P, producing a base score of 2.1 (LOW). Each metric says something specific about how the bug can be attacked and what it costs the victim:

AV:N (Attack Vector: Network): the vulnerability is reachable over the network, consistent with the disclosure's statement that the attack may be performed remotely.
AC:L (Attack Complexity: Low): no specialized conditions are needed beyond reaching the vulnerable function.
AT:N (Attack Requirements: None): no prerequisites such as a particular configuration state or timing window.
PR:L (Privileges Required: Low): the attacker needs some level of privilege before exploiting the flaw — in practice, some form of authenticated or low-privileged access to the application.
UI:N (User Interaction: None): no victim interaction is required.
VC:L, VI:N, VA:N (Impact metrics): the scoring grants a low impact to the confidentiality of the vulnerable system and no impact to its integrity or availability.
E:P (Exploit Maturity: Proof of Concept): a public proof of concept exists, matching the disclosure's note that the exploit has been disclosed publicly.

The low score reflects the scoring system's view of impact — limited to a low confidentiality impact — rather than the effort needed to trigger the bug, which the vector describes as modest for an attacker who already holds low privileges. Read together with the E:P metric, the picture is: easy to reach for an authenticated user, limited scored blast radius, and a working public exploit.

Affected Software and Versions

The affected product is Casdoor, an open-source identity provider whose source code is published on GitHub. The disclosure lists the affected versions as up to 3.164.0/4.10.0 — read as the 3.x line up to and including 3.164.0 and the 4.x line up to and including 4.10.0, as reported in the vulnerability database entry. The vendor field in the record is not populated, so no separate vendor name is stated beyond the Casdoor project itself.

The fix is delivered in version 4.11.0. Two patch commits are referenced in the disclosure:

03c6c9aaa2eda5b085ce128ce0d60b34094efbd9
ada08ecd10cbf158f593dee23a8bab63efecf995

Operators should compare their deployed Casdoor version against the v4.11.0 release and upgrade if the deployment falls within the affected range. The disclosure's own recommendation is that it is advisable to upgrade the affected component.

Impact

According to the CVSS 4.0 scoring, the impact of CVE-2026-108572 is confined to a low confidentiality impact on the vulnerable system, with no scored impact on integrity or availability. The overall severity rating is LOW at 2.1.

The vulnerability class still matters for risk assessment. SSRF in an identity provider means the application server can be directed to issue requests to destinations chosen through the pgtUrl argument. What such requests can concretely reach in a given deployment — internal services, network-adjacent resources, or attacker-controlled listeners — is not fully disclosed in the available sources, and the official scoring assigns only a low confidentiality impact. Operators should weigh the confirmed public availability of an exploit, stated both in the disclosure and in the E:P exploit maturity metric, against the low score when prioritizing remediation.

Practical impact factors stated in the disclosure:

Remote exploitability: the attack may be performed from remote.
Low privilege requirement: the PR:L metric indicates the attacker needs some prior access to the application.
No user interaction: exploitation does not depend on tricking another user.
Public exploit: the exploit has been disclosed publicly and may be used.

Exploitation Scenario

The following scenario is illustrative and derived from the vulnerability description. It is not a verified exploit transcript, and the exact endpoint routing and request format are not fully disclosed in the available sources.

Consider a self-hosted Casdoor deployment running a version up to 3.164.0/4.10.0, reachable over a network, with the CAS proxy validation functionality in use. An attacker who holds a low-privileged account on the instance — the level of access implied by the PR:L metric — sends a request to the proxy validation handler (CasP3ProxyValidate in controllers/cas.go) in which the pgtUrl argument is manipulated to point at a destination of the attacker's choosing, such as a host they control or an internal address.

If the handler initiates an outbound request based on that argument without adequately validating the destination — the behavior implied by the CWE-918 classification — the server performs the request itself. The attacker observes the outcome through the application's response or through a listener on the destination host, achieving server-side request forgery from a remote position with no user interaction. The precise mechanics, including which responses are returned to the attacker and which destinations are reachable from the server, are not fully disclosed in the available sources.

Detection and Mitigation

Mitigation: upgrade Casdoor to version 4.11.0, which addresses the issue. The fix lives in the project's repository; the referenced patch commits are 03c6c9aaa2eda5b085ce128ce0d60b34094efbd9 and ada08ecd10cbf158f593dee23a8bab63efecf995. Reviewing those commit diffs shows how the maintainers changed the proxy validation code, which is useful both for verifying that a deployed build contains the fix and for understanding how this class of bug was closed. The disclosure's guidance is that it is advisable to upgrade the affected component.

Detection: because the vulnerable argument is pgtUrl in the proxy validation component, operators can review application and access logs for requests aimed at the proxy validation functionality that carry unusual pgtUrl values — for example, values pointing at internal addresses or unexpected external hosts. The E:P exploit maturity metric and the disclosure both confirm that a public proof of concept exists, so exploitation attempts may already have occurred; retrospective log review is worthwhile for any instance that ran an affected version.

A practical remediation sequence:

Inventory all Casdoor deployments and record their versions against the affected range of up to 3.164.0/4.10.0.
Upgrade to 4.11.0 or later, prioritizing instances reachable from untrusted networks.
Verify the deployed build includes the referenced patch commits.
Monitor proxy validation traffic for anomalous pgtUrl usage going forward.

Bug Bounty Angle

For bug bounty hunters, CVE-2026-108572 is a compact case study in working a low-severity SSRF disclosure end to end:

Open-source patch diffing: Casdoor's source and history are public. Reading the two referenced patch commits shows exactly how the maintainers closed the SSRF in CasP3ProxyValidate — a practical exercise in mapping a vulnerability disclosure back to concrete code changes.
Severity calibration: the CVSS 4.0 score of 2.1 (LOW) reflects a low confidentiality impact with no integrity or availability impact. Programs typically rate SSRF findings by what the induced request can reach; a low score here signals that the scored impact was limited, and hunters should set triage expectations accordingly.
Privilege requirement: PR:L means a valid low-privileged account is part of the attack path. When testing authorized targets, confirm that the program scope covers authenticated testing of identity and CAS endpoints.
Public disclosure: the exploit has been disclosed publicly and may be used. Some programs maintain specific policies about publicly known vulnerabilities; check the program rules before submitting findings that rest on a known public disclosure.

When writing up similar findings, anchor the report to the observable facts: the vulnerable function and parameter, the request that triggers the outbound call, the destination that demonstrates control, and the impact observed. CVE-2026-108572's disclosure follows that structure — function, file, component, argument, and weakness class — which is part of why it triages cleanly.

The standard caveat applies with extra weight here: only test systems you are explicitly authorized to test, and prefer verifying patched behavior on version 4.11.0 or later over probing unpatched instances outside a defined engagement.

Frequently Asked Questions

What is CVE-2026-108572?

A server-side request forgery (CWE-918) in Casdoor up to 3.164.0/4.10.0. Manipulating the pgtUrl argument of the CasP3ProxyValidate function in controllers/cas.go triggers SSRF. The attack works remotely and version 4.11.0 contains the fix.

How severe is CVE-2026-108572?

CVSS 4.0 rates it 2.1 (LOW): network attack vector, low attack complexity, low privileges required, no user interaction, low confidentiality impact, and no integrity or availability impact. A public proof of concept exists.

How is CVE-2026-108572 fixed?

Upgrade Casdoor to version 4.11.0. The fix is delivered in the commits 03c6c9aaa2eda5b085ce128ce0d60b34094efbd9 and ada08ecd10cbf158f593dee23a8bab63efecf995.

Who discovered CVE-2026-108572?

The issue was discovered by pngyuo, a VulDB user, and moderated by the VulDB Vulnerability Moderation Team. The CVE identifier was assigned by VulDB.

Discovery and Credits: CVE-2026-108572 was discovered by pngyuo (VulDB User), with moderation by the VulDB Vulnerability Moderation Team; the CVE was assigned by VulDB.