Description

SEP sesam before 5.2.0.24 mishandles User Authorization with MFA. If AD authentication is configured and MFA is enforced, an attacker can create a second OTP access capability. SEP sesam and Active Directory handle username capitalization differently, which may allow multiple SEP sesam user accounts to be created for the same Active Directory (AD) account. Active Directory treats usernames as case-insensitive, while SEP sesam distinguishes between different letter casing. As a result, the same AD user can be represented by multiple SEP sesam user accounts that differ only in username capitalization. When Active Directory authentication is configured and multi-factor authentication (MFA) is enforced, this behavior may allow an additional OTP Authenticator to be registered for the same AD account, reducing the effectiveness of MFA protection.

Executive Summary

Technical Details

Mitigations

References

Additional Metadata

{
  "score": "3.5",
  "pubDate": "2026-09-12T23:17:00.893Z",
  "pubdate": "2026-09-12T23:17:00.893Z",
  "executiveSummary": "A vulnerability exists in SEP sesam versions prior to 5.2.0.24 involving the mishandling of User Authorization when integrated with Active Directory (AD) and Multi-Factor Authentication (MFA).\nThe flaw originates from an inconsistency in how usernames are processed; Active Directory treats usernames as case-insensitive, whereas SEP sesam treats them as case-sensitive.\nThis discrepancy enables an attacker to create multiple distinct SEP sesam accounts for a single underlying AD identity by varying the character casing.\nConsequently, an attacker can register an additional OTP Authenticator for the same AD account, effectively bypassing the intended security posture of the MFA enforcement.\nThis vulnerability degrades the integrity of the MFA mechanism, allowing for potential unauthorized access to systems protected by AD authentication.\nSuccessful exploitation requires the ability to create or influence account mappings in the application when AD authentication and MFA are active.",
  "technicalDetails": "The root cause of this vulnerability is an improper implementation of user identifier normalization within the SEP sesam authentication module when interfacing with Active Directory (AD) services.\nWhile AD infrastructure universally enforces case-insensitive lookups for security principals, the SEP sesam application logic fails to normalize user input to a canonical format, treating strings like 'UserAccount' and 'useraccount' as unique entities.\nThis architecture creates a collision in the identity management layer where the application-side authorization logic maintains a separate record for each casing variant, despite the underlying AD account remaining constant.\nThe attack flow proceeds as follows: First, an attacker identifies an AD account that is configured for SEP sesam access with MFA enabled. Second, because SEP sesam allows the registration of multiple user entries for the same identity due to the case-sensitivity flaw, the attacker creates or registers a new identity entry using a different casing (e.g., 'AdminUser' vs 'adminuser').\nThird, the application fails to link this new entry to the existing MFA secret or security policy associated with the original account. Fourth, the attacker registers a second OTP device for this newly created 'case-variant' identity.\nBecause the system treats this as a separate authentication object, it permits the registration of a new, attacker-controlled MFA token.\nPost-exploitation, the attacker possesses a valid, secondary MFA secret that grants access to the target system as the victim AD account, effectively neutralizing the efficacy of the primary MFA enrollment. This allows the attacker to maintain persistence or access restricted resources under the identity of the target user, even if the primary user is unaware of the secondary device enrollment.\nThe vulnerability is localized to the user authentication and authorization logic within versions of SEP sesam released prior to 5.2.0.24. Access to the environment is required for the initial identity creation, and the exposure is predicated on the use of external AD authentication providers."
}