Shibboleth Identity Provider Security Advisory [13 May 2026]

[Scott Cantor]

>> 1. That mnetadata is not formed sensibly.
> 
> If there are concrete errors or mistakes I'd be happy to report them
> to the eduGAIN Operations Team.

25 declarations of a single namespace with different prefixes is about as clear a definition of "not sensible" as I can think of. That leads directly to the point that it's not meant for public consumption, it's a system artifact of a service designed to be used by the federations. If they're happy with it, fine. But by exposing it to clients, I think they kind of have an obligation to do things sensibly or tell people that they don't intend to cater to that use case.

> One thing I noticed in the past (and this may in fact be a pyff issue,
> too) is that XML namespace declarations are not normalised (not using
> one consistent prefix for one formal namespace URI) but instead any
> prefix used by any of the source metadata documents is preserved and
> added to the final document, leading to something like this on the
> root element:

That is the problem, yes. There's nothing we can do about that at our stage of the process. If you intend to consume that, then it's fair to say you are going to be at higher risk of attack. We can't do anything about that we haven't done, we took pains to accommodate this issue despite it costing us more time in getting this fixed.

People complain about how many settings we have; this is the reason why. Most software punts these issues.

>> 2. Nobody should be consuming that metadata, let alone any aggregate in 2026.
> 
> No SAML IDP or SP operator should of course be consuming the eduGAIN
> MDS aggregate (for several reasons, including there being no sane way
> of ever coordiating key rollovers with potentially thousands of
> unknown metadata consumers) but *all* of the currently 84 federations
> currently participating in eduGAIN (https://technical.edugain.org/) do
> have to consume and process and republish that document to their
> constituency in one form or another (including not in aggregate form).

Right, but that's not this aggregate; we assume part of the point is to clean it all up, and the federations we work the most closely with do that, using our software a lot of the time. It helps clean up these issues.

> We can certainly disagree about of the severity of the problem of
> aggregates (resource consumption, mostly, with sideeffects for
> implementations such as the Shib SP via its legacy XML parser) vs. the
> severity of the problem of avoiding aggregates (introducing hard
> realtime-dependencies on central federation infrastructure, only
> partially mitigated by optional end entities' caching efforts;
> decentral IDP discovery).

It's a bit hard for me to accept that as an argument in a world rushing madly to OpenID, which explicitly rejects aggregates as "broken" and "insufficient".

People can't have it both ways. I realize it's partly that we hear the loudest voices, and the ones who aren't on board with all those changes aren't as loud about it. I guess I would make the case that people need to speak up if they disagree with what's coming.

>  But I'm guessing we're not the only ones
> still using (and having our constituency consume) aggregates. And at
> least I "didn't get the memo" that the (eduGAIN) metadata we're all
> necessarily relying on was in such a bad state it would warrant an
> urgent fix.

I don't consider any denial of service issue "urgent". I barely consider them worthy of note anymore, but the world doesn't agree and unfortunately this issue was reported by a third party that seemed likely to make a big deal of it.

-- Scott