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
9 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 6.2.1, 5.0.6, 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 5.0.0-alpha.20 (pre-release) or 4.17.0 by release line, 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.
Validation of an XML Signature requires verification that the hash value of the related XML-document (after any optional transformations and/or normalizations) matches a specific DigestValue-value, but also that the cryptografic signature on the SignedInfo-tree (the one that contains the DigestValue) verifies and matches a trusted public key. Within the simpleSAMLphp/xml-security library (https://github.com/simplesamlphp/xml-security), the hash is being validated using SignedElementTrait::validateReference, and the signature is being verified in SignedElementTrait::verifyInternal https://github.com/simplesamlphp/xml-security/blob/master/src/XML/SignedElementTrait.php: What stands out is that the signature is being calculated over the canonical version of the SignedInfo-tree. The validateReference method, however, uses the original non-canonicalized version of SignedInfo. Impact If an attacker somehow (i.e. by exploiting a bug in PHP's canonicalization function) manages to manipulate…
Recommended action: Upgrade to 5.0.0-alpha.13 (pre-release) or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
The validateSignature method in the SAML2\Utils class in SimpleSAMLphp before 1.14.10 and simplesamlphp/saml2 library before 1.9.1, 1.10.x before 1.10.3, and 2.x before 2.3.3 allows remote attackers to spoof SAML responses or possibly cause a denial of service (memory consumption) by leveraging improper conversion of return values to boolean.
Recommended action: Upgrade to 2.3.3, 1.10.3, 1.9.1 or 1.8.1 by release line, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
HTTPRedirect.php in the saml2 library in SimpleSAMLphp before 1.15.4 has an incorrect check of return values in the signature validation utilities, allowing an attacker to get invalid signatures accepted as valid by forcing an error during validation. This occurs because of a dependency on PHP functionality that interprets a -1 error code as a true boolean value.
Recommended action: Upgrade to 3.1.4, 2.3.8 or 1.10.6 by release line, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
The SAML2 library before 1.10.4, 2.x before 2.3.5, and 3.x before 3.1.1 in SimpleSAMLphp has a Regular Expression Denial of Service vulnerability for fraction-of-seconds data in a timestamp.
Recommended action: Upgrade to 3.1.1, 2.3.5 or 1.10.4 by release line, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
The XmlSecLibs library as used in the saml2 library in SimpleSAMLphp before 1.15.3 incorrectly verifies signatures on SAML assertions, allowing a remote attacker to construct a crafted SAML assertion on behalf of an Identity Provider that would pass as cryptographically valid, thereby allowing them to impersonate a user from that Identity Provider, aka a key confusion issue.
Recommended action: Upgrade to 3.1.3, 2.3.7 or 1.10.5 by release line, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.