Shibboleth OIDC OP plugin: unescaped form_post parameters and unbound DPoP in PAR allow security policy bypass
On 9 November 2026 the Shibboleth Project published two security advisories for its OpenID Connect OpenID Provider (OIDC OP) plugin, and CERT-FR relays them as a security policy bypass affecting releases before V4.3.3 (shibboleth.net/community/advisories/secadv_20261109.txt; shibboleth.net/community/advisories/secadv_20261109a.txt). The main flaw is a form_post encoding defect that leaves response parameters unescaped, which the project rates medium to high, with high for releases before V4.1.0 or where Content Security Policy is disabled. A second flaw, rated low by the project, means a DPoP proof sent with a Pushed Authorization Request is not tied to the later stages of the flow, and it affects only versions 4.2.0 to 4.3.2. Neither advisory assigns a CVE ID, and neither reports exploitation in the wild. Exposure is limited by prerequisites: the form_post issue needs that response mode in use and a user lured toward a crafted page, while the DPoP issue needs an attacker who already holds an authorization code and, for confidential clients, the client credentials or the PKCE verifier. The item is rated high because the form_post flaw reaches every earlier release of an identity provider plugin and the vendor itself rates it high for older branches.
Entenda a falha
A vulnerabilidade
Two flaws, with no CVE, in the OpenID Connect OP (OIDC OP) plugin for Shibboleth Identity Provider. The main one is in the form_post response mode: response parameters, including state, are returned as unescaped HTML form values, allowing markup injection on the IdP origin. The attacker needs form_post in use and a user lured to a crafted page; the result can be redirection to untrusted sites and, in implicit and hybrid flows, token exposure. The project rates it medium to high, and high for releases before V4.1.0 or with CSP disabled. All earlier versions are affected, including pre-V3.0 ones; V4.3.3 fixes it. The second flaw is rated low and affects only 4.2.0 to 4.3.2: the DPoP proof sent in a Pushed Authorization Request (PAR) is not bound to later stages. It needs an attacker who already holds an authorization code and, for confidential clients, the client credentials or the PKCE verifier. It is also fixed in V4.3.3.
Como funciona
In the form_post flow, the plugin answers the authorization request with an HTML page that carries the response parameters, such as state, as form fields that the browser submits to the client. The plugin writes these values into the page without escaping them. Anything controlled by the attacker, such as a crafted request parameter, can therefore end up as markup on the IdP's own origin. In the DPoP case, the client sends a DPoP proof with the PAR request and the plugin checks it. The public key thumbprint from that proof is not carried into the later stages, the authorization code exchange and the token issuance. A party holding the code can therefore get a token bound to another key or to no key, when the configuration allows it.
Por que é vulnerável
The form_post issue is an output encoding defect: response parameters are placed into the HTML form without being escaped. Since V4.1.0 the default page carries a CSP that blocks reflected XSS when cspEnabled is true, but markup injection remains possible. The DPoP issue is a missing binding check: the proof is validated in the PAR request, but the key thumbprint is not enforced in later stages of the sequence. The advisories do not say why either went unnoticed. The fix in V4.3.3 addresses both.
Onde está
The form_post response page of the OIDC OP plugin and the DPoP handling in its PAR flow, described in Shibboleth advisories secadv_20261109 and secadv_20261109a; the articles name no files or functions.
Como foi descoberta
The Shibboleth Project team found the form_post issue itself. The DPoP issue was reported by Janne Lauros of CSC - IT Center for Science Ltd. Both were published as vendor advisories on 9 November 2026, and CERT-FR relayed them the next day as a security policy bypass. Neither advisory assigns a CVE or reports exploitation in the wild.
Explicação gerada por IA a partir da matéria e dos artigos, em 10/11/2026 13:49.
Detalhes técnicos
- form_post encoding (medium to high, vendor rating): the plugin returns response parameters, including the state value, as unescaped HTML form values. This allows markup injection on the IdP origin, which could lead users to untrusted sites and could expose tokens in the implicit and hybrid flows. Since V4.1.0 the default page carries a CSP that blocks reflected XSS when cspEnabled is true, but markup injection remains possible. All earlier versions, including the pre-official releases before V3.0, are affected. The Shibboleth Project team found this issue itself (shibboleth.net/community/advisories/secadv_20261109.txt).
- DPoP binding in PAR (low, vendor rating): the plugin verifies the DPoP proof in a PAR request but does not bind the public key thumbprint to later stages of the sequence, so an access token could be bound to a new key or to no key when configuration allows it. Versions 4.2.0 through 4.3.2 are affected. The issue was reported by Janne Lauros of CSC - IT Center for Science Ltd (shibboleth.net/community/advisories/secadv_20261109a.txt).
Remediação
Update the OIDC OP plugin to V4.3.3 or later; the IdP plugin installer can perform the update (shibboleth.net/community/advisories/secadv_20261109.txt; shibboleth.net/community/advisories/secadv_20261109a.txt). If an immediate update is not possible for the form_post issue, since V4.1.0 the global property idp.oauth2.responseModes or the responseModes setting of the OIDC.SSO profile can exclude form_post, and since V3.4.0 signed request objects (useRequestObject and signRequestObject) can be enforced to stop attackers from altering request parameters. The advisories give no workaround for the DPoP issue, so updating is the only listed remedy for it.
Linha do tempo
-
Shibboleth OIDC OP plugin: unescaped form_post parameters and unbound DPoP in PAR allow security policy bypass
ler a análise desta fonte ocultar
On 9 November 2026 the Shibboleth Project published two security advisories for its OpenID Connect OpenID Provider (OIDC OP) plugin, and CERT-FR relays them as a security policy bypass affecting releases before V4.3.3 (shibboleth.net/community/advisories/secadv_20261109.txt; shibboleth.net/community/advisories/secadv_20261109a.txt). The main flaw is a form_post encoding defect that leaves response parameters unescaped, which the project rates medium to high, with high for releases before V4.1.0 or where Content Security Policy is disabled. A second flaw, rated low by the project, means a DPoP proof sent with a Pushed Authorization Request is not tied to the later stages of the flow, and it affects only versions 4.2.0 to 4.3.2. Neither advisory assigns a CVE ID, and neither reports exploitation in the wild. Exposure is limited by prerequisites: the form_post issue needs that response mode in use and a user lured toward a crafted page, while the DPoP issue needs an attacker who already holds an authorization code and, for confidential clients, the client credentials or the PKCE verifier. The item is rated high because the form_post flaw reaches every earlier release of an identity provider plugin and the vendor itself rates it high for older branches.
Technical Details
- form_post encoding (medium to high, vendor rating): the plugin returns response parameters, including the state value, as unescaped HTML form values. This allows markup injection on the IdP origin, which could lead users to untrusted sites and could expose tokens in the implicit and hybrid flows. Since V4.1.0 the default page carries a CSP that blocks reflected XSS when cspEnabled is true, but markup injection remains possible. All earlier versions, including the pre-official releases before V3.0, are affected. The Shibboleth Project team found this issue itself (shibboleth.net/community/advisories/secadv_20261109.txt).
- DPoP binding in PAR (low, vendor rating): the plugin verifies the DPoP proof in a PAR request but does not bind the public key thumbprint to later stages of the sequence, so an access token could be bound to a new key or to no key when configuration allows it. Versions 4.2.0 through 4.3.2 are affected. The issue was reported by Janne Lauros of CSC - IT Center for Science Ltd (shibboleth.net/community/advisories/secadv_20261109a.txt).
Remediation
Update the OIDC OP plugin to V4.3.3 or later; the IdP plugin installer can perform the update (shibboleth.net/community/advisories/secadv_20261109.txt; shibboleth.net/community/advisories/secadv_20261109a.txt). If an immediate update is not possible for the form_post issue, since V4.1.0 the global property idp.oauth2.responseModes or the responseModes setting of the OIDC.SSO profile can exclude form_post, and since V3.4.0 signed request objects (useRequestObject and signRequestObject) can be enforced to stop attackers from altering request parameters. The advisories give no workaround for the DPoP issue, so updating is the only listed remedy for it.