Shibboleth OIDC OP plugin: form_post injection and DPoP PAR binding flaws fixed in V4.3.3
The Shibboleth OpenID Connect OpenID Provider (OIDC OP) plugin for the Shibboleth Identity Provider has two flaws, both fixed in V4.3.3. The vendor published both bulletins on 9 November 2026 (shibboleth.net), and the CERT-FR advisory CERTFR-2026-AVI-1491 relays them without naming a CVE. The main flaw is an unescaped form_post response, which lets injected markup be served from the IdP's origin. The vendor rates it medium, or high for versions before V4.1.0 or where Content Security Policy is disabled (shibboleth.net). The second flaw, a DPoP binding gap in PAR requests, is rated low by the vendor and affects only versions 4.2.0 through 4.3.2 (shibboleth.net). Exploitation needs a lure or extra material such as an authorization code, which limits the practical impact, and no exploitation is reported.
Entenda a falha
A vulnerabilidade
The Shibboleth OpenID Connect OP plugin for the Shibboleth Identity Provider has two flaws, with no CVE assigned. The main one is in the form_post response mode: response parameters, including request values such as state, are not escaped in the HTML form. An attacker can inject markup into a page served from the IdP origin, but needs a lure to get a victim there. The vendor rates it medium, or high for versions before V4.1.0 or where CSP is disabled. All earlier versions are affected, including pre-official releases before V3.0. The second flaw is a DPoP binding gap in PAR requests, rated low and affecting 4.2.0 through 4.3.2. Both are fixed in V4.3.3.
Como funciona
In the form_post flow, the IdP returns the authorization response to the client as an auto-submitted HTML form that carries parameters such as state, taken from the request. The plugin writes these values into the page without escaping them, so crafted input can become markup in a page served from the IdP origin. In the DPoP flow, a client sends a Pushed Authorization Request with a DPoP proof, and the plugin checks that proof. It does not carry the proof's key thumbprint on to later stages, so at the token endpoint an authorization code obtained through PAR can be redeemed with a different DPoP key.
Por que é vulnerável
For form_post, the cause is missing output escaping of response parameters in the HTML form. Since V4.1.0 the default page is tied to CSP, which prevents reflected XSS on the IdP origin, but markup injection remains possible. For DPoP, the cause is a missing binding: the proof was validated at the PAR step, but its key thumbprint was not tied to the later stages. The fix in V4.3.3 addresses both. The articles give no further detail on why they went unnoticed.
Onde está
The vendor advisories at shibboleth.net are secadv_20261109 (form_post response mode) and secadv_20261109a (DPoP proof handling in PAR requests); the articles name no files, functions or commits.
Como foi descoberta
The articles do not say who found the flaws or how. The vendor published both bulletins on 9 November 2026 on shibboleth.net, and CERT-FR relayed them in advisory CERTFR-2026-AVI-1491 without naming a CVE. No exploitation is reported.
Explicação gerada por IA a partir da matéria e dos artigos, em 10/11/2026 13:49.
Detalhes técnicos
- form_post response mode (secadv_20261109): the plugin leaves response parameters unescaped in the HTML form, including request values such as state, so attacker input can be injected into a page served from the IdP origin. Since V4.1.0 the default page is wired to CSP, which prevents reflected XSS on the IdP origin, but markup injection remains possible (shibboleth.net).
- DPoP proof in PAR requests (secadv_20261109a): the plugin verified the DPoP proof sent with a Pushed Authorization Request but did not bind its key thumbprint to later stages. A different DPoP key could then be used at the token endpoint with an authorization code obtained through PAR. The attacker would still need the client credentials for confidential clients and the PKCE code verifier where PKCE is used (shibboleth.net).
Remediação
Update the OIDC OP plugin to V4.3.3 or later with the IdP's plugin installer (shibboleth.net). If the update is not possible, the vendor suggests restricting the allowed response modes to exclude form_post, using idp.oauth2.responseModes or the profile's responseModes setting (available since V4.1.0), and enforcing signed request objects through useRequestObject and signRequestObject (available since V3.4.0) to block tampering with request parameters (shibboleth.net). The vendor's form_post text states that all earlier versions, including the pre-official releases before V3.0, are affected (shibboleth.net).