CVE-2026-10579

CVE-2026-10579 is a framework design failure, not merely an implementation mistake. Picketlink's unsolicited response handler wasn't designed to skip verification through oversight—it was architected to accept unsigned assertions by default. The handler explicitly performs 'no verification or validation,' creating conditions where security shortcuts became the path of least resistance. This matters because unsolicited responses (IDP-initiated SSO) break the normal request-response security model. The SP receives a response without having initiated a corresponding request, so the normal cryptographic binding between request and response disappears. A well-designed framework would require MORE validation in this scenario. Instead, Picketlink created a shortcut where 'no prior request' was treated as synonymous with 'trust implicitly.' The 'any principal in any role' impact is devastating. This wasn't limited privilege escalation—it was complete authentication bypass. The scope suggests verification wasn't just missing; it may have been structurally impossible in this code path, meaning the vulnerability was baked into the architecture rather than introduced by a single error. This follows a documented genealogical pattern across SAML implementations: mod_auth_mellon CVE-2015-8601, Spring Security SAML CVE-2012-0035, and multiple OpenSAML CVEs all trace to identical 'simplified IDP-initiated flow' shortcuts. The pattern persists because the SAML specification created cognitive load conditions where developers reasonably choose insecure but simple paths over correct but burdensome implementations. What to check: Locate the UnsolicitedSSOHandler or equivalent class in your Picketlink deployment. Verify whether signature validation is explicitly enforced on incoming assertions—even for IDP-initiated flows. If your configuration accepts assertions without cryptographic verification, that is this vulnerability. Audit any SSO configuration guides or tutorials you followed; some may direct developers to this insecure path. Consider whether your documentation clearly distinguishes security requirements between unsolicited and SP-initiated responses—documented security assumptions that contradict implemented behavior are a distinct failure mode.

Reviewed through automated stages and approved by a human before publication.