GHSA-cmwh-g2h8-c222

Preface

Poweradmin maps OIDC identities into local users through oidc_user_links.oidc_subject plus provider_id. In the MySQL schema, the OIDC link table explicitly uses utf8mb4_unicode_ci, which is case-insensitive and accent-insensitive. OIDC sub is a stable external subject identifier and should be matched byte-for-byte within the issuer/provider scope.

The confirmed local PoC used two different OIDC users:

• Victim subject: victim-login
• Attacker subject: victím-login (í, U+00ED)

MySQL reported those two subjects as equal under utf8mb4_unicode_ci. After the victim linked their OIDC account, the attacker authenticated to the same provider with the attacker's own password and Poweradmin resolved the session to the victim's local account.

Server Info

• Application: Poweradmin
• Version: targets/poweradmin git e1f9c9a
• Database: MySQL 8.4.10, character_set_server=utf8mb4, collation_server=utf8mb4_unicode_ci
• Access Permissions: Any user who can create or control an account in the connected OIDC provider
• Auth Method: OIDC generic provider
• Tools: Docker Compose, local OIDC provider, Python PoC harness

Affected Entry Point:

GET /oidc/login?provider=generic
GET /oidc/callback?code=...&state=...

Relevant request properties:

• Authentication: valid OIDC authorization code flow
• Trigger: attacker OIDC account has a sub that collides with a victim's linked sub
• Vulnerable field: OIDC sub stored and looked up as oidc_user_links.oidc_subject

Root Cause Analysis

part0 — oidc_user_links.oidc_subject uses an accent-insensitive collation

The MySQL schema defines the OIDC link table with utf8mb4_unicode_ci:

-- sql/poweradmin-mysql-db-structure.sql:341-356
CREATE TABLE `oidc_user_links` (
  `user_id` INT(11) NOT NULL,
  `provider_id` VARCHAR(50) NOT NULL,
  `oidc_subject` VARCHAR(255) NOT NULL,
  ...
  UNIQUE KEY `unique_subject_provider` (`oidc_subject`,...