The Shibboleth IdP V4 software will leave support on September 1, 2024.

SecurityAdvisories

This is the advisory page for Identity Provider V4 releases. For IdP plugins supported by the project, see the plugins home page. For the older V3 IdP's advisories, please refer to the V3 IDP SecurityAdvisories page. For the newer V5 IdP’s advisories, please refer to the V5 IDP Security Advisories page.

For the SP, please refer to V3 SP SecurityAdvisories page.

As a courtesy, you can also find Jetty advisories at https://www.eclipse.org/jetty/security-reports.html and Tomcat advisories at http://tomcat.apache.org/security.html

This page provides access to the complete history of Security Advisories released for the Shibboleth V4 Identity Provider and an "at a glance" table showing you which releases are vulnerable to what kinds of issues. If you're running a particular version, you can use this table to identify the issues that could affect your system and determine how urgent an upgrade is. In addition to the announce mailing list, you can "watch" this page for changes to keep abreast.

You can determine the exact version you're running based on the process log during startup.

If you would like to report an issue you believe is security related, please drop an e-mail to security@shibboleth.net

As always, sites are advised to use the latest stable release of any Shibboleth product. Refer to the ProductVersioning page for information about our support and versioning policies. The Home page identifies the specific versions recommended at a given point in time

This page only covers advisories affecting the V4 Identity Provider software. Other advisories are not listed here, but you can find the complete set of advisories in this directory.

Obviously not all vulnerabilities are created equal, and the classifications in the matrices are general in nature, and are meant to point you to the relevant advisories to look into.

A particular version will typically be implicated by any advisories noted for it and for any newer versions above it in the tables.

Advisories noted for "All" versions should be reviewed by all deployers for relevancy to their deployment. Typically this indicates that an advisory is at least partly discussing issues that go beyond the scope of what the Shibboleth software can actually remediate and may affect the deployment as a whole. It does not in general refer to unfixed vulnerabilities in the Shibboleth software itself.

Identity Provider Vulnerability Matrix

The oldest IdP 4 version unaffected by fixable vulnerabilities is 4.2.1 (on Windows, 4.3.1.1)

Version

EOL

User Data Exposure

User Data Accuracy

Session Hijacking

Denial of Service

Remote Exploit

Advisories

Version

EOL

User Data Exposure

User Data Accuracy

Session Hijacking

Denial of Service

Remote Exploit

Advisories

All

 

X

X

 

 

X

2018-01-23, 2017-05-18

4.3.1

 

 

 

 

 

 

 

4.3.0

Mar 2023

X

X

 

 

 

2023-03-30

4.2.1

Jan 2023

 

 

 

 

 

 

4.1.6

Apr 2022

 

 

 

X

X

2022-12-16

4.1.5

Mar 2022

 

 

 

X

X

Spring vuln.

4.1.4

Jan 2022

 

 

 

X

X

 

4.1.2

Jul 2021

 

 

 

X

X

 

4.1.0

May 2021

 

 

 

X

X

 

4.0.1

Mar 2021

 

 

 

X

X

 

4.0.0

Jun 2020

 

 

 

X

X

 

Advisory List

Date

Title

Affects

Severity

CVE

Date

Title

Affects

Severity

CVE

2023-04-18

Jetty advisories

IdP on Windows < 4.3.1.1

low

CVE-2023-26048, CVE-2023-26049

2023-03-30

Regression in RemoteUser login flow could lead to impersonation

IdP V4.3.0 only

low

 

2022-12-16

OpenSAML and IdP mis-handle malicious encrypted XML content

IdP, OpenSAML < 4.2.0

critical

 

2018-01-23

Implications of ROBOT TLS vulnerability

All

high

 

2017-05-18

Default Kerberos configurations are unsafe

All

high

 

Library Issues

Because we have relatively infrequent releases and a strict versioning policy, it is not rare that we ship third-party libraries that may contain unfixed vulnerabilities when those issues are believed to be non-impactful. This is often due to timing; for example, we may be unable to adequately test a new version of something in time to include it in a release and may determine that the less risky course is to stay on an older version. Alternatively, it may be impossible to update something because of the API changes required, since many projects do not adhere to semantic (or any) versioning.

In the event that we ship releases known to, or that we subsequently discover to, contain vulnerable libraries and do not have specific plans to immediately issue a patch with a newer version, we will document any known issues here, and our official position as to the lack of relevance of the issue to the software. It is not our aim to pass generic, context-free scanners that simply flag every issue. Automation is not a substitute for human judgement.

V4.3.1

  • UserAgentUtils (any) (CVE-2021-4277)

    • This CVE is worded worse than most (and most are terrible) but it does not obviously seem to even be related to this library. The bigger issue is the library is EOL, so we will be deprecating the functionality and moving off it in V5, while deprecating the usage in V4. The only usage known is not within the code base proper but within the logout views, so we are reviewing possible impact.

  • Guava (any) (CVE-2020-8908)

    • We don't use the affected, deprecated function, and there is no fix for the issue.

  • Spring (5.3.25) (CVE-2023-20860, CVE-2023-20861, CVE-2023-20863)

    • We are not impacted by these issues, but will update Spring if another patch becomes necessary and there is time to update it.

  • logback < 1.3.12 (CVE-2023-6378)

    • The issue impacts an unusual feature of logback allowing remote collection of log events and the bug exists in the “receiver” component. Thus, the IdP’s use of logback would not involve this feature. We will patch in the event of a subsequent release.

  • Bouncy Castle < 1.73 (CVE-2023-33202)

    • The issue is a denial of service consideration when parsing untrusted PEM files. While there may be some unforeseen vectors to exploit that, it’s not something the software generally does so that plus the actual impact makes it very low priority for us. Bouncy Castle is problematic to update because it does not adhere to semantic versioning, so it is unlikely we can remediate this in the V4 branch (it was updated for V5 of course).