CVE-2015-2559

What it actually does

The flaw permits an authenticated user sharing an identical password hash with another account to bypass authorization checks via a specially crafted password reset URL and forcibly change the other account's password.

Why it matters to the business

Attackers can seize control of additional user accounts, enabling unauthorized access to sensitive information, administrative functions, or further compromise of the application.

How an attack unfolds

An attacker first obtains or identifies an account whose password hash matches a target account, then crafts and submits a malicious password reset URL that the application accepts without proper ownership validation, thereby resetting the target's password and allowing login as that user.

How to fix it

Upgrade Drupal 6.x installations to version 6.35 or later and Drupal 7.x installations to version 7.35 or later; apply the exact GIT fixes bcd100d812b525c982cf75d6c6dabe839f61634a for php/php-src and 5e60a2770329300866319aac1ab465159688d319 for drupal/drupal.

How to confirm the fix worked

Confirm the running Drupal version is at least 6.35 or 7.35, verify the listed GIT commits are present in the codebase, and test that password reset requests are rejected when the requesting user does not own the target account.

Typical attack path

1. Locate or create an account sharing a password hash with the target
2. Craft a malicious password reset URL targeting the other account
3. Submit the URL through the application's reset mechanism
4. Authenticate using the newly set password on the target account

How to detect it

Inspect web server and application logs for password reset requests originating from authenticated sessions that reference accounts other than the session owner; correlate with successful logins using recently reset credentials.

What your security team should do

• Apply the listed Drupal version upgrades immediately given the multi-year exposure window
• Audit all accounts for shared password hashes and enforce unique strong passwords
• Review access logs for historical password reset anomalies
• Implement additional authorization checks around password reset flows if patching is delayed