No fix, workaround or mitigation extracted yet
Cloud Foundry UAA incorrectly treated XML encryption to the Service Provider (confidentiality) as a substitute for XML signatures from the Identity Provider (authenticity) in two SAML flows: the OAuth 2.0 SAML2 bearer grant (token endpoint) and browser SSO (ACS) when wantAssertionSigned is set to false. Assertions or responses that were unsigned but contained encrypted content could still be accepted. Encryption uses the SP's public key from published metadata, therefore, any party, not only a trusted IdP, can produce ciphertext UAA can decrypt; successful decryption therefore does not prove the IdP issued the message. Affected versions: Cloud Foundry UAA (uaa_release) 2.0.0 through 78.13.0. Cloud Foundry CF Deployment all versions through 56.1.0.
When applications specify HTTP response headers for servlet applications using Spring Security, there is the possibility that the HTTP Headers will not be written. This issue affects Spring Security Servlet applications using lazy (default) writing of HTTP Headers: : from 5.7.0 through 5.7.21, from 5.8.0 through 5.8.23, from 6.3.0 through 6.3.14, from 6.4.0 through 6.4.14, from 6.5.0 through 6.5.8, from 7.0.0 through 7.0.3.
Discuss the latest advisories, swap patch-day notes with other infra teams, and get support — straight from the people who run VulniPulse.
Join the communityIf you want to support server/domain costs, please donate below — much love ❤️
Donate