Shibboleth XMLTooling before 3.2.4, as used in OpenSAML and Shibboleth Service Provider, allows SSRF via a crafted KeyInfo element. (This is fixed in, for example, Shibboleth Service Provider 3.4.1.3 on Windows.)

Insecure folder permissions in the Windows installation path of Shibboleth Service Provider (SP) before 3.4.1 allow an unprivileged local attacker to escalate privileges to SYSTEM via DLL planting in the service executable's folder. This occurs because the installation goes under C:\opt (rather than C:\Program Files) by default. NOTE: the vendor disputes the significance of this report, stating that "We consider the ACLs a best effort thing" and "it was a documentation mistake."

The OIDC OP plugin before 3.0.4 for Shibboleth Identity Provider allows server-side request forgery (SSRF) due to insufficient restriction of the request_uri parameter. This allows attackers to interact with arbitrary third-party HTTP services.

Shibboleth Service Provider 3.x before 3.2.2 is prone to a NULL pointer dereference flaw involving the session recovery feature. The flaw is exploitable (for a daemon crash) on systems not using this feature if a crafted cookie is supplied.

Shibboleth Service Provider before 3.2.1 allows content injection because template generation uses attacker-controlled parameters.

Shibboleth Identify Provider 3.x before 3.4.6 has a denial of service flaw. A remote unauthenticated attacker can cause a login flow to trigger Java heap exhaustion due to the creation of objects in the Java Servlet container session.

Shibboleth Service Provider (SP) 3.x before 3.1.0 shipped a spec file that calls chown on files in a directory controlled by the service user (the shibd account) after installation. This allows the user to escalate to root by pointing symlinks to files such as /etc/shadow.

The keygen.sh script in Shibboleth SP 2.0 (located in /usr/local/etc/shibboleth by default) uses OpenSSL to create a DES private key which is placed in sp-key.pm. It relies on the root umask (default 22) instead of chmoding the resulting file itself, so the generated private key is world readable by default.

The (1) HttpResource and (2) FileBackedHttpResource implementations in Shibboleth Identity Provider (IdP) before 2.4.1 and OpenSAML Java 2.6.2 do not verify that the server hostname matches a domain name in the subject's Common Name (CN) or subjectAltName field of the X.509 certificate, which allows man-in-the-middle attackers to spoof SSL servers via an arbitrary valid certificate.

Shibboleth XMLTooling-C before 1.6.4, as used in Shibboleth Service Provider before 2.6.1.4 on Windows and other products, mishandles digital signatures of user data, which allows remote attackers to obtain sensitive information or conduct impersonation attacks via crafted XML data. NOTE: this issue exists because of an incomplete fix for CVE-2018-0486.