Log injection in SimpleSAMLphp before version 1.18.4. The www/erroreport.php script, which receives error reports and sends them via email to the system administrator, did not properly sanitize the report identifier obtained from the request. This allows an attacker, under specific circumstances, to inject new log lines by manually crafting this report ID. When configured to use the file logging handler, SimpleSAMLphp will output all its logs by appending each log line to a given file. Since the reportID parameter received in a request sent to www/errorreport.php was not properly sanitized, it was possible to inject newline characters into it, effectively allowing a malicious user to inject new log lines with arbitrary content.

PySAML2 before 5.0.0 does not check that the signature in a SAML document is enveloped and thus signature wrapping is effective, i.e., it is affected by XML Signature Wrapping (XSW). The signature information and the node/object that is signed can be in different places and thus the signature verification will succeed, but the wrong data will be used. This specifically affects the verification of assertion that have been signed.

Rob Richards XmlSecLibs, all versions prior to v3.0.3, as used for example by SimpleSAMLphp, performed incorrect validation of cryptographic signatures in XML messages, allowing an authenticated attacker to impersonate others or elevate privileges by creating a crafted XML message.

simplesamlphp before 1.6.3 (squeeze) and before 1.8.2 (sid) incorrectly handles XML encryption which could allow remote attackers to decrypt or forge messages.

An issue was discovered in the SAML Single Sign On (SSO) plugin for several Atlassian products affecting versions 3.1.0 through 3.2.2 for Jira and Confluence, versions 2.4.0 through 3.0.3 for Bitbucket, and versions 2.4.0 through 2.5.2 for Bamboo. It allows locally disabled users to reactivate their accounts just by browsing the affected Jira/Confluence/Bitbucket/Bamboo instance, even when the applicable configuration option of the plugin has been disabled ("Reactivate inactive users"). Exploiting this vulnerability requires an attacker to be authorized by the identity provider and requires that the plugin's configuration option "User Update Method" have the "Update from SAML Attributes" value.

The onelogin-saml-sso plugin before 2.2.0 for WordPress has a hardcoded @@@nopass@@@ password for just-in-time provisioned users.

Zendesk Samlr before 2.6.2 allows an XML nodes comment attack such as a name_id node with user@example.com followed by <!---->. and then the attacker's domain name.

In the miniOrange SAML SP Single Sign On plugin before 4.8.73 for WordPress, the SAML Login Endpoint is vulnerable to XSS via a specially crafted SAMLResponse XML post.

OneLogin PythonSAML 2.3.0 and earlier may incorrectly utilize the results of XML DOM traversal and canonicalization APIs in such a way that an attacker may be able to manipulate the SAML data without invalidating the cryptographic signature, allowing the attack to potentially bypass authentication to SAML service providers.

OneLogin Ruby-SAML 1.6.0 and earlier may incorrectly utilize the results of XML DOM traversal and canonicalization APIs in such a way that an attacker may be able to manipulate the SAML data without invalidating the cryptographic signature, allowing the attack to potentially bypass authentication to SAML service providers.