Drupal OAuth/OIDC Client XSS in callback error rendering

Improper Neutralization of Input During Web Page Generation ('Cross-site Scripting') vulnerability in Drupal OAuth & OpenID Connect Single Sign On – SSO (OAuth/OIDC Client) allows Cross-Site Scripting (XSS).This issue affects OAuth & OpenID Connect Single Sign On – SSO (OAuth/OIDC Client): from 3.0.0 before 3.44.0, from 4.0.0 before 4.0.19.

• miniorange_oauth_client 3.x: affected from 3.0.0 before 3.44.0. The Drupal advisory describes the corresponding branch as 8.x-3.x for Drupal 9 and Drupal 10 and directs users to upgrade to 8.x-3.44.
• miniorange_oauth_client 4.x: affected from 4.0.0 before 4.0.19. The advisory specifies 4.0.19 for Drupal 9, Drupal 10, and Drupal 11.
• 7.x-1.x branch: the Drupal advisory also directs users on this branch to upgrade to 7.x-1.355. The normalized record does not provide a lower bound or a complete vulnerable interval for this branch, so no additional range is inferred.

This Drupal module supports user authentication through an Identity Provider or OAuth Server. The flaw occurs because query parameters sent to the callback URL are not sufficiently escaped when the module displays error messages, particularly when the response lacks the code parameter. This is a CWE-79 weakness in the callback error handling and rendering path. The record describes network reachability, no required privileges, and required user interaction, but the advisory does not identify every affected parameter, the implementing function, a specific callback path, or an exploit payload.

The normalized record describes network reachability, low complexity, no required authentication or privileges, and required user interaction. This is consistent with a scenario in which a user opens a callback or error page containing a query parameter that is processed unsafely. The delivery mechanism and the method used to cause a victim browser to load the page are not documented in the available evidence. The record does not mark a public exploit; that does not establish that exploitation has never occurred. No specific campaign, victim, or indicator of compromise is established.

Successful exploitation can execute script in the browser security context of a user who views the affected callback error page. The normalized record describes low confidentiality and integrity impact, no availability impact, and changed scope because the script executes in the context of the affected user or application. The practical result depends on the victim's permissions, the data available in the session, and browser security controls. The flaw does not by itself establish server-side code execution or Drupal privilege escalation.

The flaw can cause untrusted script to execute in a user's browser when the user views an affected callback page or error message. Possible consequences include access to some data available to the browser session, modification of rendered content, or actions performed in the user's application context. Risk is more significant for sites that use the module as an authentication gateway connected to an IdP or OAuth Server. The available evidence does not establish a specific data breach, account takeover, server-side code execution, or service outage.

1. Inventory miniorange_oauth_client across all Drupal sites and determine the deployed Drupal and module branches.
2. For the 3.x branch, upgrade to 3.44.0 as represented in the normalized record, corresponding to the advisory's 8.x-3.44 release for Drupal 9 and Drupal 10.
3. For the 4.x branch, upgrade to 4.0.19. The advisory gives this guidance for Drupal 9, Drupal 10, and Drupal 11.
4. For the 7.x-1.x branch, upgrade to 7.x-1.355 as directed by the advisory.
5. No confirmed workaround is provided by the available evidence. If an update cannot be applied immediately, assess exposure of the OAuth/OIDC callback flow and monitor for unusual requests, but do not treat those precautions as a substitute for the fix.

1. Inventory Drupal sites that install miniorange_oauth_client, including sites using the module for OAuth or OpenID Connect login.
2. Identify the deployed module branch and version, then compare it with the affected and fixed boundaries in the affected summary.
3. Where callback URLs are known, review web logs for requests with unusual query parameters or a missing code parameter. Treat this as precautionary review because the advisory does not provide a specific IOC or request pattern.
4. Inspect callback error responses to determine whether query parameters are inserted into HTML or error messages without output escaping.
5. After updating, verify the installed version on each server and retest the OAuth/OIDC login flow. Absence of suspicious requests in logs does not prove that a deployment is safe.