Poweradmin OIDC `sub` Collation Bypass Leads to Account Takeover
A collation vulnerability in Poweradmin's OIDC integration allows an unauthenticated attacker to take over victim accounts by exploiting the case and accent-insensitive MySQL collation (`utf8mb4_unicode_ci`) used for OIDC subject (`sub`) identifiers, causing the attacker's colliding `sub` to resolve to the victim's `user_id` during authentication.
A high-severity vulnerability has been identified in Poweradmin, an open-source web-based management tool for PowerDNS. This flaw, tracked in GHSA-cmwh-g2h8-c222, allows an unauthenticated attacker to bypass OIDC identity collation, leading to account takeover. The issue stems from Poweradmin's use of a case- and accent-insensitive MySQL collation (utf8mb4_unicode_ci) for storing and matching OIDC subject identifiers (oidc_subject). An attacker can create an OIDC account with a subject that is a collation variant of a legitimate victim's subject (e.g., victim-login vs. victím-login). When the attacker attempts to authenticate, Poweradmin's database lookup, performed under the weak collation, incorrectly matches the attacker's subject to the victim's existing user_id, granting the attacker an authenticated session to the victim's Poweradmin account. The vulnerability affects Poweradmin versions 4.1.0 through 4.2.4 and 4.3.0 through 4.3.3, and it has been fixed in versions 4.2.5, 4.3.4, and 4.4.0.
Attack Chain
- A legitimate victim links their OIDC account with Poweradmin; Poweradmin stores the victim's OIDC
sub(e.g.,victim-login) in theoidc_user_linkstable with autf8mb4_unicode_cicollation. - An attacker creates an OIDC account at the same OIDC provider with a
subidentifier that is a collation variant of the victim'ssub(e.g.,victím-login), exploiting the accent-insensitive nature of the collation. - The attacker initiates an OIDC login to Poweradmin by accessing
/oidc/login?provider=genericand authenticates with their attacker OIDC credentials (victím-login). - Poweradmin receives the attacker's OIDC
sub(victím-login) from the OIDC provider's userinfo endpoint after a successful authorization code flow. - Poweradmin queries its
oidc_user_linksdatabase table to find an existing user linked to the receivedoidc_subjectandprovider_id. - Due to the
utf8mb4_unicode_cicollation used foroidc_subject, the database query interprets the attacker'ssub(victím-login) as equal to the victim'ssub(victim-login). - The database returns the
user_idassociated with the victim's account, and Poweradmin establishes an authenticated session for the attacker under the victim's identity, leading to account takeover.
Impact
Successful exploitation of this vulnerability allows an unauthenticated attacker, with control over an OIDC account that has a colliding subject identifier, to gain full access to a victim's Poweradmin account. This can result in unauthorized modification or deletion of DNS records, compromise of administrative settings, and complete control over the PowerDNS environment managed by Poweradmin. The attacker can achieve this without knowing or modifying the victim's password, leveraging only their own OIDC credentials and the database collation weakness. No specific victim counts or targeted sectors were provided, but any organization using affected Poweradmin versions with OIDC authentication is at risk.
Recommendation
- Patch Poweradmin installations to versions 4.2.5, 4.3.4, or 4.4.0 immediately to address the OIDC
subcollation bypass vulnerability. - As part of the upgrade process, execute the provided SQL update script located in the
sql/directory for your specific database to migrate theoidc_user_linkstable columns (oidc_subject,provider_id) to a binary or byte-preserving collation (e.g.,utf8mb4_bin). - Review other identity and authorization lookups within your Poweradmin environment, specifically
findUserByEmail(),findPermissionTemplateByName(), andfindGroupByName(), to ensure they enforce byte-exact matching where security boundaries are involved.