Know every vulnerabilitybefore it knows you.
DevGuard continuously monitors your dependencies and alerts you when CVEs like this one affect your stack — with real-time threat intelligence built for developers.
GHSA-jrrg-99xh-5j2q
No affected components available
Summary
simplesamlphp-module-casserver builds file paths for the file-based CAS ticket store by directly concatenating the configured ticket directory with an attacker-controlled ticket identifier. Public CAS validation/proxy endpoints pass attacker-controlled ticket / pgt query parameters into this store.
In deployments using FileSystemTicketStore, a remote attacker can use path traversal sequences such as ../target.serialized to make the CAS server read and unserialize files outside the ticket directory. In the CAS 1.0 validation flow, the same attacker-selected path is also passed to deleteTicket() immediately after getTicket() returns, which can delete the target file when it is readable by the PHP process, deletable under the PHP process filesystem permissions, and unserializes to a value compatible with the ?array return type.
Preconditions
The demonstrated issue requires:
- the
casservermodule to be enabled; - the file-based ticket store to be configured (
FileSystemTicketStore); - public CAS validation/proxy endpoints to be reachable;
- the PHP process to have filesystem permissions for the target path.
- for the demonstrated CAS 1.0 deletion impact,
getTicket()must return without throwing; practically, the target file must contain serialized PHP data that unserializes to a value compatible with the?arrayreturn type, such as an array or null. Full CAS semantic validation is not required for deletion in CAS 1.0 becausedeleteTicket($ticket)is called immediately aftergetTicket($ticket).
The attacker does not need administrator access to SimpleSAMLphp.
Impact
Affected deployments can allow remote attackers to escape the configured CAS ticket directory through public ticket validation inputs.
Confirmed impact:
- read and unserialize files outside the ticket cache when the file content is valid serialized PHP data;
- delete attacker-selected files outside the ticket cache through the CAS 1.0 validation flow when the target is readable by the PHP process, deletable under the PHP process filesystem permissions, and the target content unserializes to a value compatible with the
?arrayreturn type, such as a serialized array or serialized null. Full CAS semantic validation is not required before deletion in the CAS 1.0 flow.
The file deletion impact depends on filesystem permissions of the PHP process. In realistic deployments, this can destroy CAS tickets, serialized SimpleSAMLphp runtime/cache files, or other writable files whose contents can be unserialized into a value accepted by the ?array return type. It may also delete attacker-created files outside the ticket directory if the attacker has another primitive to place such serialized content.
The unserialize() call creates a dangerous secondary primitive if an attacker can place a serialized object file at a reachable path, although this report does not claim a complete object-injection or RCE chain.
The vulnerability can be exploited over the network without needing physical access. It is easy for an attacker to exploit this vulnerability. An attacker does not need any special privileges or access rights. No user interaction is needed for the attacker to exploit this vulnerability. The impact is confined to the system where the vulnerability exists. There is a low impact on the confidentiality of the information. There is a high impact on the integrity of the data. There is a low impact on the availability of the system.
Exploitation activity has been observed. Apply available patches or mitigations urgently.
The exploit probability is very low. The vulnerability is unlikely to be exploited in the next 30 days.
We did not find any exploit available. Neither in GitHub repositories nor in the Exploit-Database.
Browse More
Continuously monitor your dependencies and get alerted when vulnerabilities like this one affect your stack.
Checkout DevGuard