Open actionable advisories and recorded vendor fixes. This public package view has no inventory attached and cannot establish whether your deployment is affected. A vendor fix never resolves your finding; verify your installed version and the source guidance.
Open advisories
4 actionable advisories, newest first. Withdrawn advisories and news are excluded. Coverage is partial.
This library turned out to be vulnerable to Denial-of-Service attacks using XPath transforms. A mitigation has been put in place to restrict the number of transforms and to restrict transforms to only the transform-algorithms mentioned in the SAML 2.0 Core Specifications (and specifically refuse XPath transforms). Impact An attacker is able to send specially crafted messages to any entity relying on SimpleSAMLphp (or directly on this SAML2-library) to be able to perform a Denial-of-Service attack.
Recommended action: Upgrade to 4.20.3 or 4.19.3 by release line, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
SimpleSAMLphp's HTTP-Artifact receive path can treat an unsigned embedded SAML Response as cryptographically valid for the wrong IdP. In the HTTPArtifact::receive() flow, the SOAP ArtifactResponse receives a TLS-based validator from SOAPClient::addSSLValidator(). The embedded SAML Response then receives a validator that delegates signature validation to that outer ArtifactResponse. Later, the SP validates the embedded Response against metadata selected from the embedded response issuer, not necessarily the artifact issuer. The critical issue is that SOAPClient::validateSSL() returns normally when the TLS public key does not match the key currently being validated. SAML2\Message::validate() treats any validator call that does not throw an exception as successful. As a result, an ArtifactResponse obtained from one IdP can validate an unsigned embedded SAML Response that claims to be issued by a different IdP. In a multi-IdP/federation deployment where a malicious or lower-trust…
Recommended action: Upgrade to 4.20.2 or 4.19.3 by release line, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
There's a signature confusion attack in the HTTPRedirect binding. An attacker with any signed SAMLResponse via the HTTP-Redirect binding can cause the application to accept an unsigned message. I believe that it exists for v4 only. I have not yet developed a PoC. V5 is well designed and instead builds the signed query from the same message that will be consumed. Details What is verified The data['SignedQuery'] is the string that will be verified by the public key. It is defined here: https://github.com/simplesamlphp/saml2/blob/9545abd0d9d48388f2fa00469c5c1e0294f0303e/src/SAML2/HTTPRedirect.php#L178-L217 THe code will iterate through each parameter name. Notably, sigQuery is overridden each time when processing, making the last of SAMLRequest/SAMLResponse used for sigQuery. For example, given: SAMLRequest=a&SAMLResponse=idpsigned SAMLResponse=idpsigned will be set as sigQuery, then later verified What is actually processed Processing uses SAMLRequest parameter value first, (if…
Recommended action: Upgrade to 4.17.0 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
When loading an (untrusted) XML document, for example the SAMLResponse, it's possible to induce an XXE. $options is defined as: https://github.com/simplesamlphp/saml2/blob/717c0adc4877ebd58428637e5626345e59fa0109/src/SAML2/DOMDocumentFactory.php#L41 including the DTDLoad option, which allows an attacker to read file contents from local file system OR internal network. While there is the NONET option, an attacker can simply bypass if by using PHP filters: php://filter/convert.base64-encode/resource=http://URL OR FILE From there an attacker can induce network connections and steal the targeted file OOB (haven't fully tested this). RCE may be possible with the php://expect or php://phar wrappers, but this hasn't been tested. Note: The mitigation here: https://github.com/simplesamlphp/saml2/blob/717c0adc4877ebd58428637e5626345e59fa0109/src/SAML2/DOMDocumentFactory.php#L63-L69 Comes too late, as the XML has already been loaded into a document. Mitigation: Remove the LIBXMLDTDLOAD…
Recommended action: Upgrade to 4.6.14 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.