How should we interpret CVSS severity scores?

CVSS estimates technical severity, but it does not automatically equal business risk. Prioritize using context like internet exposure, asset criticality, known exploitation, and whether compensating controls exist. A Medium CVSS on an exposed production system can be more urgent than a Critical on an isolated non-production host.

Vulnerability Database

Q: What is a Vulnerability (CVE) and why does it matter?

A security vulnerability is a weakness in software, hardware, or configuration that can be exploited to compromise confidentiality, integrity, or availability. Many vulnerabilities are tracked as CVEs (Common Vulnerabilities and Exposures), which provide a standardized identifier so teams can coordinate patching, mitigation, and risk assessment across tools and vendors.

Q: What's the difference between a vulnerability, an exploit, and a zero-day?

A vulnerability is the underlying weakness. An exploit is the method or code used to take advantage of it. A zero-day is a vulnerability that is unknown to the vendor or has no publicly available fix when attackers begin using it. Risk increases sharply when exploitation becomes reliable or widespread.

Q: Why do vulnerabilities keep reappearing in our environment?

Recurring findings usually come from incomplete asset discovery, inconsistent patch management, inherited images, and configuration drift. In modern environments, you also need to watch the software supply chain: dependencies, containers, build pipelines, and third-party services can reintroduce the same weakness even after you patch a single host.

Q: How do we prioritize remediation without burning out the team?

Use a repeatable triage model: focus first on externally exposed assets, high-value systems (identity, VPN, email, production), vulnerabilities with known exploits, and issues that enable remote code execution or privilege escalation. Then enforce patch SLAs and track progress so remediation is steady, not reactive.

Q: How can SynScan help reduce vulnerability risk over time?

SynScan combines attack surface monitoring and continuous security auditing to keep your inventory current, flag high-impact vulnerabilities early, and help you turn raw findings into a practical remediation plan.

363,159

Total vulnerabilities in the database

Poweradmin: OIDC `sub` collation bypass in Poweradmin leading to account takeover — poweradmin / poweradmin

Improper Authentication

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=...&amp;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`, `provider_id`)
) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4 COLLATE=utf8mb4_unicode_ci;

In the PoC database:

Field          Type          Collation
provider_id    varchar(50)   utf8mb4_unicode_ci
oidc_subject   varchar(255)  utf8mb4_unicode_ci

SELECT &#039;victim-login&#039; = &#039;victím-login&#039; COLLATE utf8mb4_unicode_ci;
-- accent_collision = 1

part1 — OIDC `sub` flows into a normal SQL equality lookup

Poweradmin reads the subject from OIDC userinfo data. If no custom subject mapping is configured, it uses the sub claim:

// lib/Application/Service/OidcService.php:424-459
$resourceOwner = $provider-&gt;getResourceOwner($token);
$userData = $resourceOwner-&gt;toArray();
...
subject: $userData[$mapping[&#039;subject&#039;] ?? &#039;sub&#039;] ?? &#039;&#039;,

The callback passes the resulting OidcUserInfo to provisioning:

// lib/Application/Service/OidcService.php:269-291
$userInfo = $this-&gt;getUserInfo($provider, $token, $providerId);
$userId = $this-&gt;userProvisioningService-&gt;provisionUser($userInfo, $providerId);

Provisioning first tries to find an existing user by subject:

// lib/Application/Service/UserProvisioningService.php:86-90
$existingUserId = $authMethod === self::AUTH_METHOD_SAML
    ? $this-&gt;findUserBySamlSubject($userInfo-&gt;getSubject(), $providerId)
    : $this-&gt;findUserByOidcSubject($userInfo-&gt;getSubject(), $providerId);

The lookup is normal SQL equality evaluated under the column's weak collation:

// lib/Application/Service/UserProvisioningService.php:145-149
$stmt = $this-&gt;db-&gt;prepare(&quot;
    SELECT user_id FROM oidc_user_links
    WHERE oidc_subject = ? AND provider_id = ?
&quot;);
$stmt-&gt;execute([$subject, $providerId]);

When the attacker authenticates with sub = victím-login, MySQL matches the existing row for oidc_subject = victim-login and returns the victim's user_id.

part2 — The returned user ID becomes the authenticated session

After provisioning returns the matched user_id, Poweradmin fetches the database username for that user and stores the matched user ID in the session:

// lib/Application/Service/OidcService.php:307-317
$databaseUsername = $this-&gt;userProvisioningService-&gt;getDatabaseUsername($userId);
$this-&gt;setSessionValue(&#039;userlogin&#039;, $databaseUsername);

// lib/Application/Service/OidcService.php:360-371
$this-&gt;setSessionValue(&#039;userid&#039;, $userId);
...
$this-&gt;setSessionValue(&#039;authenticated&#039;, true);

The attacker's OIDC password is validated by the IdP, but the local user_id selected by Poweradmin comes from the weak-collation SQL lookup.

Security Impact

An attacker who can register or control an OIDC principal with an accent/collation variant of a victim's OIDC subject can authenticate with the attacker's own IdP credentials and obtain a Poweradmin session for the victim's local account.

The confirmed PoC used distinct OIDC usernames, subjects, emails, and passwords. The attacker did not know or modify the victim's password.

Reproduction

1. Start the local Poweradmin OIDC lab

sudo -n docker compose -p poweradminoidcpoc -f poc/work/poweradmin-oidc-collation/docker-compose.yml up -d

The lab uses MySQL utf8mb4_unicode_ci and a local OIDC provider with two real login accounts:

Victim:
  username/sub: victim-login
  email: [email protected]
  password: VictimPassword123!

Attacker:
  username/sub: victím-login
  email: [email protected]
  password: AttackerPassword123!

2. Log in once as the victim through OIDC

Authenticate through GET /oidc/login?provider=generic using:

username: victim-login
password: VictimPassword123!

Poweradmin creates the victim local user and OIDC link:

users:
id  username      fullname            email
2   victim-login  Victim Poweradmin   [email protected]

oidc_user_links:
id  user_id  provider_id  oidc_subject
1   2        generic      victim-login

3. Log in as the attacker OIDC user

Authenticate from a separate browser session with:

username: victím-login
password: AttackerPassword123!

Observed result from poc/work/poweradmin-oidc-collation/run_poc.py:

{
  &quot;attacker_login&quot;: {
    &quot;selected_idp_user&quot;: &quot;attacker&quot;,
    &quot;selected_idp_username&quot;: &quot;victím-login&quot;,
    &quot;has_session_cookie&quot;: true,
    &quot;home_contains_victim_username&quot;: true,
    &quot;home_contains_attacker_username&quot;: false
  },
  &quot;attacker_resolved_to_victim&quot;: true
}

Database evidence after both logins:

version  charset_server  collation_server
8.4.10   utf8mb4         utf8mb4_unicode_ci

accent_collision
1

users:
id  username      fullname            email
2   victim-login  Victim Poweradmin   [email protected]

oidc_user_links:
id  user_id  provider_id  oidc_subject  oidc_subject_hex
1   2        generic      victim-login   76696374696D2D6C6F67696E

The application audit log also records all OIDC login events as the victim user:

user:victim-login operation:login_success auth_method:oidc

No local user or OIDC link was created for victím-login.

Recommended Fix

Treat OIDC subject identifiers as byte-exact strings.

For MySQL, migrate the OIDC mapping identifiers to a binary or byte-preserving collation:

ALTER TABLE oidc_user_links
  MODIFY COLUMN provider_id varchar(50)
    CHARACTER SET utf8mb4 COLLATE utf8mb4_bin NOT NULL,
  MODIFY COLUMN oidc_subject varchar(255)
    CHARACTER SET utf8mb4 COLLATE utf8mb4_bin NOT NULL;

Also make lookup queries byte-preserving so patched application code protects existing deployments before schema migrations are complete:

$stmt = $this-&gt;db-&gt;prepare(&quot;
    SELECT user_id FROM oidc_user_links
    WHERE BINARY oidc_subject = BINARY ?
      AND BINARY provider_id = BINARY ?
&quot;);

Review related identity and authorization lookups:

findUserByEmail() uses users.email = ? and can be impacted when link_by_email is enabled.
findPermissionTemplateByName() uses perm_templ.name = ? for SSO permission template mapping.
findGroupByName() uses user_groups.name = ? for SSO group mapping.

Those fields should either be intentionally documented as case/accent-insensitive or migrated/looked up with byte-preserving semantics where they represent security boundaries.

Patches

Fixed in 4.2.5, 4.3.4, and 4.4.0. OIDC and SAML subject identifiers are now matched byte-for-byte. The fix includes a database migration that changes the collation of the identity link columns, so upgrading requires running the SQL update script for your database in the sql/ directory.

Acknowledge / Credit

whale120 (@whale120_tw), working with DEVCORE Internship Program

Published: Jul 24, 2026
Updated: Jul 25, 2026
GHSA: GHSA-cmwh-g2h8-c222
Severity: High
Exploit:
CISA KEV:

CVSS v3:

Severity: High
Score: 8.1
AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:N

CWEs:

CWE-287

OWASP TOP 10:

A2 - Broken Authentication

Affected Software
References

Software	From	Fixed in
poweradmin / poweradmin	4.1.0	4.2.5
poweradmin / poweradmin	4.3.0	4.3.4

Deep Security Visibility Without the Complexity

SynScan provides clear, real-time security insights so you can monitor your attack surface, spot risks early, and act fast—without extra complexity.

No setup fees
5-min deployment
Cancel anytime

Book a Demo

Frequently Asked Questions

What is a Vulnerability (CVE) and why does it matter?

A security vulnerability is a weakness in software, hardware, or configuration that can be exploited to compromise confidentiality, integrity, or availability. Many vulnerabilities are tracked as CVEs (Common Vulnerabilities and Exposures), which provide a standardized identifier so teams can coordinate patching, mitigation, and risk assessment across tools and vendors.

CVSS (Common Vulnerability Scoring System) estimates technical severity, but it doesn't automatically equal business risk. Prioritize using context like internet exposure, affected asset criticality, known exploitation (proof-of-concept or in-the-wild), and whether compensating controls exist. A "Medium" CVSS on an exposed, production system can be more urgent than a "Critical" on an isolated, non-production host.

A vulnerability is the underlying weakness. An exploit is the method or code used to take advantage of it. A zero-day is a vulnerability that is unknown to the vendor or has no publicly available fix when attackers begin using it. In practice, risk increases sharply when exploitation becomes reliable or widespread.

Recurring findings usually come from incomplete Asset Discovery, inconsistent patch management, inherited images, and configuration drift. In modern environments, you also need to watch the software supply chain: dependencies, containers, build pipelines, and third-party services can reintroduce the same weakness even after you patch a single host. Unknown or unmanaged assets (often called Shadow IT) are a common reason the same issues resurface.

Use a simple, repeatable triage model: focus first on externally exposed assets, high-value systems (identity, VPN, email, production), vulnerabilities with known exploits, and issues that enable remote code execution or privilege escalation. Then enforce patch SLAs and track progress using consistent metrics so remediation is steady, not reactive.

SynScan combines attack surface monitoring and continuous security auditing to keep your inventory current, flag high-impact vulnerabilities early, and help you turn raw findings into a practical remediation plan.