Case-Sensitivity Validation Flaw in Drupal OpenID Connect / OAuth Client Can Cause Duplicate Emails and Access Bypass

Improper Handling of Case Sensitivity vulnerability in Drupal OpenID Connect / OAuth client allows Privilege Escalation.This issue affects OpenID Connect / OAuth client: from 0.0.0 before 1.5.0.

• The normalized record identifies Drupal OpenID Connect / OAuth client as affected from 0.0.0 before 1.5.0; the supplied default status is unaffected outside that range.
• The Drupal advisory uses the condition <1.5.0 and specifically directs users of the OpenID Connect 8.x-1.x branch to upgrade to OpenID Connect 8.x-1.5.
• No additional product branch is confirmed by the approved advisory. A proposed update mentions an additional Drupal 7 product, but that tracking issue remains under review and is not treated as confirmed affected scope.

Drupal OpenID Connect / OAuth client uses an external OpenID Connect provider to authenticate users and create a Drupal account during the first sign-in. The advisory states that the module does not sufficiently validate the uniqueness of certain user fields for all combinations of database engine and collation. In the documented case, email addresses that differ only by case may be accepted as separate accounts, creating data integrity problems and potentially affecting identity association. The attacker-controlled input is the account data supplied by the identity provider, particularly the email address. The normalized record characterizes the attack as network reachable, requiring low privileges, no user interaction, and high attack complexity, but the advisory does not specify the exact request sequence or the privilege boundary that would be crossed.

When the module is enabled and integrated with an external identity provider, the OpenID Connect login flow is reachable over the network. The normalized record describes low required privileges, no user interaction, and high attack complexity; the advisory does not explain what initial authorization those privileges represent. The vendor describes a condition involving first-time sign-in through the identity provider and Drupal account creation, but does not publish a reproducible exploit sequence. The record does not confirm known exploitation and does not identify a public exploit; that absence does not prove that exploitation has never occurred.

The flaw weakens user-identity uniqueness when values that differ only by case are processed differently depending on the database engine and collation. The direct outcome documented by the vendor is that multiple accounts may be created with the same email address, causing data integrity issues. The normalized record indicates low confidentiality and integrity impact, no identified availability impact, and unchanged scope. The base description states privilege escalation, but the vendor advisory does not identify which privilege could be obtained or what operation would demonstrate escalation; that aspect remains unspecified.

Sites using Drupal OpenID Connect / OAuth client may create multiple accounts that appear distinct even though they use the same email address without regard to case. The advisory says this can cause data integrity issues and classifies the issue as an access bypass. Depending on how the site links accounts to identity-provider identities, duplicate records could cause identity confusion or changes in access, but the advisory does not provide evidence of a specific breach. The normalized record does not identify an availability impact.

1. Upgrade the module according to Drupal's advisory. For the OpenID Connect 8.x-1.x branch, install OpenID Connect 8.x-1.5.
2. Audit existing accounts for email addresses that differ only by case. Updating the module does not automatically resolve accounts already affected by the bug.
3. Resolve each conflicting account according to site policy and the applicable email provider. Drupal documentation identifies possible actions such as changing conflicting email addresses or blocking affected accounts, but the appropriate choice depends on the site's data and administrative process.
4. Recheck uniqueness after resolving legacy conflicts and monitor accounts created through the external identity provider.
5. The advisory does not provide a separate temporary mitigation that replaces upgrading; account review should not be treated as a substitute for the fix.

1. Inventory sites with the openid_connect module enabled and determine the deployed release.
2. Record the database engine and collation in use, because the advisory says the uniqueness check depends on these factors.
3. Inspect users_field_data for email addresses that differ only by case, using a normalized expression such as LOWER(mail) and reviewing langcode when grouping records.
4. Manually validate duplicate results before taking action, because multilingual user data can produce false positives in the report.
5. Review account-creation and external identity-provider sign-in records as a precaution. The advisory does not define a specific log event or IOC, and the absence of current log evidence does not prove that the system was never affected.