SecurityAdvisories

This page provides access to the complete history of Security Advisories released for the Shibboleth V5 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.

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 V5 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 5 version unaffected by fixable vulnerabilities is 5.1.2.

Advisory List

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.

V5.1.3

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

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

• Spring Framerwork (CVE-2024-38809, CVE-2024-38816, CVE-2024-38819, CVE-2024-38820)

  • The IdP is not impacted by these issues.

• Bouncy Castle (CVE-2024-29857, CVE-2024-30171 , CVE-2024-30172, CVE-2024-34447)

  • The IdP is not impacted by these issues. Bouncy Castle is problematic to update because they do not follow sensible API and behavioral versioning practices and mix functional and ABI changes with security fixes. While we may update it once we are able, our priority is to remove our runtime dependency on it (It likely will continue to be used by the installer in very limited fashion).

• Netty (CVE-2024-47535)

  • This is a ridiculous CVE. Yes, if you give an attacker the ability to create a file on your Windows server running the IdP, they can cause a denial of service attack. They can also do a lot more than that by definition so they aren’t going to waste their time on a silly DOS like this.