CVE-2026-81905: Concrete CMS Auth Bypass Vulnerability

CVE-2026-81905 Overview

CVE-2026-81905 is a business logic flaw in Concrete CMS versions below 9.5.3. The application stores user validation hashes for email verification, password reset, and persistent login in a single database table distinguished by a type column. The redemption path resolves a hash by value alone and never verifies the hash type. An attacker who obtains a valid hash issued for one purpose can redeem it against a different endpoint. A long-lived registration hash with a 60-day expiry can be submitted to the password-change endpoint to reset an account password.

Critical Impact
Hash type confusion allows attackers to convert any leaked validation hash into an account takeover primitive, amplifying the impact of email interception, log exposure, or SSRF against internal mail relays.

Affected Products

Concrete CMS versions prior to 9.5.3
Concrete CMS user validation subsystem (email validation, password reset, persistent login)
Concrete CMS account activation workflow

Discovery Timeline

Vulnerability reported by Yonatan Drori from Tenzai to the Concrete CMS security team
2026-09-11 - CVE-2026-81905 published to NVD
2026-09-11 - Last updated in NVD database

Technical Details for CVE-2026-81905

Vulnerability Analysis

The root defect is a missing authorization check in the hash redemption logic [CWE-640]. Concrete CMS uses a unified table to persist single-use tokens for three distinct workflows: registration email validation, password reset, and persistent login. Each row carries a type column that identifies the intended purpose of the hash.

The redemption code path queries the table by hash value only. It returns the matching row without validating that the row's type matches the endpoint being invoked. This turns the type column into documentation rather than an enforced constraint.

An attacker who acquires a registration hash can submit it to the password-change endpoint. The endpoint accepts the row, marks the hash consumed, and applies the new password to the target account. The reverse also works: a password-reset hash submitted to the email-validation endpoint activates a previously unverified account.

Root Cause

The underlying weakness is broken access control in the token verification routine. The code trusts the hash presented by the client as sufficient proof of authorization for whichever action the client selects. No server-side check ties a token to its issuing workflow, and no scope binding is performed at redemption time.

Attack Vector

Exploitation requires the attacker to first obtain a valid hash through a separate channel. Realistic acquisition paths include email interception at an upstream mail relay, exposure of hashes in application or proxy logs, and Server-Side Request Forgery (SSRF) against internal SMTP infrastructure. The flaw amplifies the impact of a hash disclosure but does not, on its own, create a network entry point. Once a hash is in hand, the attacker sends it to the endpoint corresponding to the desired action, such as POST to the password change handler with the registration hash as the token parameter.

Detection Methods for CVE-2026-81905

Indicators of Compromise

Password change requests immediately preceded by requests to registration or email validation endpoints from the same IP or session.
Successful password reset events on accounts that have no corresponding user-initiated forgot password request in application logs.
Account activation events for users whose registration hash age approaches the 60-day expiry window.
Repeated failed hash submissions across multiple validation endpoints in a short time window, suggesting hash-type probing.

Detection Strategies

Correlate hash redemption events against the original hash issuance record and alert when the endpoint type does not match the issued type.
Monitor mail relay and reverse proxy logs for outbound URLs containing validation tokens that never reach the intended recipient domain.
Baseline password reset volume per tenant and alert on statistical anomalies that coincide with SSRF or log exposure indicators.

Monitoring Recommendations

Enable verbose audit logging on the UserValidationHash table and record the endpoint that consumed each row.
Ingest Concrete CMS application logs into a centralized data lake and retain them for a period exceeding the 60-day hash lifetime.
Alert on any administrative account whose password was changed via a token flow rather than an authenticated session.

How to Mitigate CVE-2026-81905

Immediate Actions Required

Upgrade all Concrete CMS installations to version 9.5.3 or later without delay.
Invalidate outstanding validation, reset, and registration hashes issued before the upgrade.
Audit mail relay configurations and application logs for prior exposure of validation URLs.
Force password resets for administrative accounts and any account showing anomalous activation activity.

Patch Information

Concrete CMS resolved the issue in version 9.5.3. The fix enforces type validation at hash redemption so that a hash issued for one workflow cannot satisfy another. Review the ConcreteCMS Version 9.5.3 Release Notes for the full change list and upgrade guidance.

Workarounds

Restrict access to validation endpoints behind an authenticated proxy where operationally feasible.
Shorten the registration hash expiry window from 60 days to reduce the exposure interval until the upgrade is applied.
Route outbound validation emails through a dedicated relay that is isolated from internal services reachable via SSRF.
Monitor and rate-limit token submissions to /register/validate and /login/callback/password_change handlers.

bash

# Configuration example: see the ConcreteCMS 9.5.3 release notes for the
# authoritative upgrade procedure. The patch is applied by upgrading the
# core package; no additional configuration flag is required to enforce
# hash-type validation once the upgrade is in place.