Common Weakness Enumeration

CWE-287

Discouraged

Improper Authentication

Abstraction: Class · Status: Draft

When an actor claims to have a given identity, the product does not prove or insufficiently proves that the claim is correct.

6194 vulnerabilities reference this CWE, most recent first.

GHSA-CJXX-HX7W-X32F

Vulnerability from github – Published: 2024-10-23 03:31 – Updated: 2024-10-23 03:31
VLAI
Details

The WooCommerce Order Proposal plugin for WordPress is vulnerable to privilege escalation via order proposal in all versions up to and including 2.0.5. This is due to the improper implementation of allow_payment_without_login function. This makes it possible for authenticated attackers, with Shop Manager-level access and above, to log in to WordPress as an arbitrary user account, including administrators.

Show details on source website

{
  "affected": [],
  "aliases": [
    "CVE-2024-9927"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-287"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2024-10-23T02:15:07Z",
    "severity": "HIGH"
  },
  "details": "The WooCommerce Order Proposal plugin for WordPress is vulnerable to privilege escalation via order proposal in all versions up to and including 2.0.5. This is due to the improper implementation of allow_payment_without_login function. This makes it possible for authenticated attackers, with Shop Manager-level access and above, to log in to WordPress as an arbitrary user account, including administrators.",
  "id": "GHSA-cjxx-hx7w-x32f",
  "modified": "2024-10-23T03:31:11Z",
  "published": "2024-10-23T03:31:11Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-9927"
    },
    {
      "type": "WEB",
      "url": "https://wpovernight.com/downloads/woocommerce-order-proposal"
    },
    {
      "type": "WEB",
      "url": "https://www.wordfence.com/threat-intel/vulnerabilities/id/cdc993a4-6f65-4570-811c-13a80dbec064?source=cve"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:H/UI:N/S:U/C:H/I:H/A:H",
      "type": "CVSS_V3"
    }
  ]
}

GHSA-CM23-HMWF-5VG9

Vulnerability from github – Published: 2022-04-29 01:28 – Updated: 2022-04-29 01:28
VLAI
Details

Netbus 1.5 through 1.7 allows more than one client to be connected at the same time, but only prompts the first connection for authentication, which allows remote attackers to gain access.

Show details on source website

{
  "affected": [],
  "aliases": [
    "CVE-2003-1475"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-287"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2003-12-31T05:00:00Z",
    "severity": "MODERATE"
  },
  "details": "Netbus 1.5 through 1.7 allows more than one client to be connected at the same time, but only prompts the first connection for authentication, which allows remote attackers to gain access.",
  "id": "GHSA-cm23-hmwf-5vg9",
  "modified": "2022-04-29T01:28:08Z",
  "published": "2022-04-29T01:28:08Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2003-1475"
    },
    {
      "type": "WEB",
      "url": "https://exchange.xforce.ibmcloud.com/vulnerabilities/11982"
    },
    {
      "type": "WEB",
      "url": "http://securityreason.com/securityalert/3289"
    },
    {
      "type": "WEB",
      "url": "http://www.securityfocus.com/archive/1/320980"
    },
    {
      "type": "WEB",
      "url": "http://www.securityfocus.com/bid/7538"
    }
  ],
  "schema_version": "1.4.0",
  "severity": []
}

GHSA-CM63-5MV5-74RV

Vulnerability from github – Published: 2022-05-13 01:33 – Updated: 2022-05-13 01:33
VLAI
Details

IBM API Connect 5.0.0.0-5.0.8.3 Developer Portal does not enforce Two Factor Authentication (TFA) while resetting a user password but enforces it for all other login scenarios. IBM X-Force ID: 144483.

Show details on source website

{
  "affected": [],
  "aliases": [
    "CVE-2018-1638"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-287"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2018-07-31T13:29:00Z",
    "severity": "HIGH"
  },
  "details": "IBM API Connect 5.0.0.0-5.0.8.3 Developer Portal does not enforce Two Factor Authentication (TFA) while resetting a user password but enforces it for all other login scenarios. IBM X-Force ID: 144483.",
  "id": "GHSA-cm63-5mv5-74rv",
  "modified": "2022-05-13T01:33:00Z",
  "published": "2022-05-13T01:33:00Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2018-1638"
    },
    {
      "type": "WEB",
      "url": "https://exchange.xforce.ibmcloud.com/vulnerabilities/144483"
    },
    {
      "type": "WEB",
      "url": "https://www.ibm.com/support/docview.wss?uid=ibm10718415"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.0/AV:N/AC:H/PR:N/UI:N/S:U/C:H/I:H/A:H",
      "type": "CVSS_V3"
    }
  ]
}

GHSA-CM9C-H987-49F4

Vulnerability from github – Published: 2026-05-17 09:30 – Updated: 2026-05-17 09:30
VLAI
Details

A weakness has been identified in Sanluan PublicCMS 5.202506.d. This issue affects the function execute of the file publiccms-trade/src/main/java/com/publiccms/views/directive/trade/TradeAddressListDirective.java of the component Trade Address Query Handler. Executing a manipulation of the argument userId/id can lead to missing authentication. The attack may be launched remotely. The exploit has been made available to the public and could be used for attacks. The vendor was contacted early about this disclosure but did not respond in any way.

Show details on source website

{
  "affected": [],
  "aliases": [
    "CVE-2026-8737"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-287"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2026-05-17T07:16:17Z",
    "severity": "MODERATE"
  },
  "details": "A weakness has been identified in Sanluan PublicCMS 5.202506.d. This issue affects the function execute of the file publiccms-trade/src/main/java/com/publiccms/views/directive/trade/TradeAddressListDirective.java of the component Trade Address Query Handler. Executing a manipulation of the argument userId/id can lead to missing authentication. The attack may be launched remotely. The exploit has been made available to the public and could be used for attacks. The vendor was contacted early about this disclosure but did not respond in any way.",
  "id": "GHSA-cm9c-h987-49f4",
  "modified": "2026-05-17T09:30:23Z",
  "published": "2026-05-17T09:30:23Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-8737"
    },
    {
      "type": "WEB",
      "url": "https://vuldb.com/submit/809885"
    },
    {
      "type": "WEB",
      "url": "https://vuldb.com/vuln/364325"
    },
    {
      "type": "WEB",
      "url": "https://vuldb.com/vuln/364325/cti"
    },
    {
      "type": "WEB",
      "url": "https://vulnplus-note.wetolink.com/share/VqmGhijVKGBM"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:L/I:N/A:N",
      "type": "CVSS_V3"
    },
    {
      "score": "CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:L/VI:N/VA:N/SC:N/SI:N/SA:N/E:P/CR:X/IR:X/AR:X/MAV:X/MAC:X/MAT:X/MPR:X/MUI:X/MVC:X/MVI:X/MVA:X/MSC:X/MSI:X/MSA:X/S:X/AU:X/R:X/V:X/RE:X/U:X",
      "type": "CVSS_V4"
    }
  ]
}

GHSA-CMC7-MFMR-XQRX

Vulnerability from github – Published: 2021-04-07 21:01 – Updated: 2024-10-21 21:02
VLAI
Summary
Logic error in authentication in proxy.py
Details

before_upstream_connection in AuthPlugin in http/proxy/auth.py in proxy.py before 2.3.1 accepts incorrect Proxy-Authorization header data because of a boolean confusion (and versus or).

Show details on source website

{
  "affected": [
    {
      "package": {
        "ecosystem": "PyPI",
        "name": "proxy.py"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "2.3.1"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2021-3116"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-287",
      "CWE-480",
      "CWE-697"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2021-04-06T21:58:49Z",
    "nvd_published_at": "2021-01-11T05:15:00Z",
    "severity": "HIGH"
  },
  "details": "before_upstream_connection in AuthPlugin in http/proxy/auth.py in proxy.py before 2.3.1 accepts incorrect Proxy-Authorization header data because of a boolean confusion (and versus or).",
  "id": "GHSA-cmc7-mfmr-xqrx",
  "modified": "2024-10-21T21:02:47Z",
  "published": "2021-04-07T21:01:25Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2021-3116"
    },
    {
      "type": "WEB",
      "url": "https://github.com/abhinavsingh/proxy.py/pull/482"
    },
    {
      "type": "WEB",
      "url": "https://github.com/abhinavsingh/proxy.py/pull/482/commits/9b00093288237f5073c403f2c4f62acfdfa8ed46"
    },
    {
      "type": "WEB",
      "url": "https://github.com/abhinavsingh/proxy.py/commit/bff171ec26d826ae1d22d2466eaf9d8bdbf059d3"
    },
    {
      "type": "WEB",
      "url": "https://cardaci.xyz/advisories/2021/01/10/proxy.py-2.3.0-broken-basic-authentication"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/abhinavsingh/proxy.py"
    },
    {
      "type": "ADVISORY",
      "url": "https://github.com/advisories/GHSA-cmc7-mfmr-xqrx"
    },
    {
      "type": "WEB",
      "url": "https://github.com/pypa/advisory-database/tree/main/vulns/proxy-py/PYSEC-2021-46.yaml"
    },
    {
      "type": "WEB",
      "url": "https://pypi.org/project/proxy.py/2.3.1/#history"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:H/A:N",
      "type": "CVSS_V3"
    },
    {
      "score": "CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:N/VI:H/VA:N/SC:N/SI:N/SA:N",
      "type": "CVSS_V4"
    }
  ],
  "summary": "Logic error in authentication in proxy.py"
}

GHSA-CMGW-HG4C-4PP2

Vulnerability from github – Published: 2022-05-13 01:35 – Updated: 2022-05-13 01:35
VLAI
Details

A vulnerability in the API gateway of the Cisco Digital Network Architecture (DNA) Center could allow an unauthenticated, remote attacker to bypass authentication and access critical services. The vulnerability is due to a failure to normalize URLs prior to servicing requests. An attacker could exploit this vulnerability by submitting a crafted URL designed to exploit the issue. A successful exploit could allow the attacker to gain unauthenticated access to critical services, resulting in elevated privileges in DNA Center. This vulnerability affects Cisco DNA Center Software Releases prior to 1.1.2. Cisco Bug IDs: CSCvi09394.

Show details on source website

{
  "affected": [],
  "aliases": [
    "CVE-2018-0271"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-287"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2018-05-17T03:29:00Z",
    "severity": "CRITICAL"
  },
  "details": "A vulnerability in the API gateway of the Cisco Digital Network Architecture (DNA) Center could allow an unauthenticated, remote attacker to bypass authentication and access critical services. The vulnerability is due to a failure to normalize URLs prior to servicing requests. An attacker could exploit this vulnerability by submitting a crafted URL designed to exploit the issue. A successful exploit could allow the attacker to gain unauthenticated access to critical services, resulting in elevated privileges in DNA Center. This vulnerability affects Cisco DNA Center Software Releases prior to 1.1.2. Cisco Bug IDs: CSCvi09394.",
  "id": "GHSA-cmgw-hg4c-4pp2",
  "modified": "2022-05-13T01:35:29Z",
  "published": "2022-05-13T01:35:29Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2018-0271"
    },
    {
      "type": "WEB",
      "url": "https://tools.cisco.com/security/center/content/CiscoSecurityAdvisory/cisco-sa-20180516-dna2"
    },
    {
      "type": "WEB",
      "url": "http://www.securityfocus.com/bid/104191"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.0/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H",
      "type": "CVSS_V3"
    }
  ]
}

GHSA-CMJP-5PJJ-7527

Vulnerability from github – Published: 2022-05-01 18:23 – Updated: 2022-05-01 18:23
VLAI
Details

Session fixation vulnerability in Ampache before 3.3.3.5 allows remote attackers to hijack web sessions via unspecified vectors.

Show details on source website

{
  "affected": [],
  "aliases": [
    "CVE-2007-4438"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-287"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2007-08-20T22:17:00Z",
    "severity": "MODERATE"
  },
  "details": "Session fixation vulnerability in Ampache before 3.3.3.5 allows remote attackers to hijack web sessions via unspecified vectors.",
  "id": "GHSA-cmjp-5pjj-7527",
  "modified": "2022-05-01T18:23:34Z",
  "published": "2022-05-01T18:23:34Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2007-4438"
    },
    {
      "type": "WEB",
      "url": "https://exchange.xforce.ibmcloud.com/vulnerabilities/36122"
    },
    {
      "type": "WEB",
      "url": "http://bugs.gentoo.org/show_bug.cgi?id=189607"
    },
    {
      "type": "WEB",
      "url": "http://secunia.com/advisories/26542"
    },
    {
      "type": "WEB",
      "url": "http://secunia.com/advisories/27253"
    },
    {
      "type": "WEB",
      "url": "http://security.gentoo.org/glsa/glsa-200710-13.xml"
    },
    {
      "type": "WEB",
      "url": "http://www.ampache.org/announce/3_3_3_5.php"
    }
  ],
  "schema_version": "1.4.0",
  "severity": []
}

GHSA-CMM9-H7P3-233M

Vulnerability from github – Published: 2024-08-07 06:31 – Updated: 2024-08-07 06:31
VLAI
Details

An improper authentication vulnerability in web component of EPMM prior to 12.1.0.1 allows a remote malicious user to access potentially sensitive information

Show details on source website

{
  "affected": [],
  "aliases": [
    "CVE-2024-34788"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-200",
      "CWE-287"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2024-08-07T04:17:17Z",
    "severity": "MODERATE"
  },
  "details": "An improper authentication vulnerability in web component of EPMM prior to 12.1.0.1 allows a remote malicious user to access potentially sensitive information",
  "id": "GHSA-cmm9-h7p3-233m",
  "modified": "2024-08-07T06:31:09Z",
  "published": "2024-08-07T06:31:09Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-34788"
    },
    {
      "type": "WEB",
      "url": "https://forums.ivanti.com/s/article/Security-Advisory-Ivanti-Endpoint-Manager-for-Mobile-EPMM-July-2024"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.0/AV:N/AC:L/PR:N/UI:N/S:U/C:L/I:N/A:N",
      "type": "CVSS_V3"
    }
  ]
}

GHSA-CMW7-F487-JF92

Vulnerability from github – Published: 2022-05-13 01:50 – Updated: 2024-03-21 03:33
VLAI
Details

** DISPUTED *** Lack of authentication in Citrix Xen Mobile through 10.8 allows low-privileged local users to execute system commands as root by making requests to private services listening on ports 8000, 30000 and 30001. NOTE: the vendor disputes that this is a vulnerability, stating it is "already mitigated by the internal firewall that limits access to configuration services to localhost."

Show details on source website

{
  "affected": [],
  "aliases": [
    "CVE-2018-18014"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-287"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2018-10-24T21:29:00Z",
    "severity": "HIGH"
  },
  "details": "** DISPUTED *** Lack of authentication in Citrix Xen Mobile through 10.8 allows low-privileged local users to execute system commands as root by making requests to private services listening on ports 8000, 30000 and 30001.  NOTE: the vendor disputes that this is a vulnerability, stating it is \"already mitigated by the internal firewall that limits access to configuration services to localhost.\"",
  "id": "GHSA-cmw7-f487-jf92",
  "modified": "2024-03-21T03:33:32Z",
  "published": "2022-05-13T01:50:37Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2018-18014"
    },
    {
      "type": "WEB",
      "url": "https://advisories.dxw.com/advisories/xen-mobile-backing-service-allows-unauthenticated-local-users-to-execute-system-commands-as-root"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.0/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H",
      "type": "CVSS_V3"
    }
  ]
}

GHSA-CMWH-G2H8-C222

Vulnerability from github – Published: 2026-07-24 21:56 – Updated: 2026-07-24 21:56
VLAI
Summary
Poweradmin: OIDC `sub` collation bypass in Poweradmin leading to account takeover
Details

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`, `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 'victim-login' = 'victím-login' 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->getResourceOwner($token);
$userData = $resourceOwner->toArray();
...
subject: $userData[$mapping['subject'] ?? 'sub'] ?? '',

The callback passes the resulting OidcUserInfo to provisioning:

// lib/Application/Service/OidcService.php:269-291
$userInfo = $this->getUserInfo($provider, $token, $providerId);
$userId = $this->userProvisioningService->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->findUserBySamlSubject($userInfo->getSubject(), $providerId)
    : $this->findUserByOidcSubject($userInfo->getSubject(), $providerId);

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

// lib/Application/Service/UserProvisioningService.php:145-149
$stmt = $this->db->prepare("
    SELECT user_id FROM oidc_user_links
    WHERE oidc_subject = ? AND provider_id = ?
");
$stmt->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->userProvisioningService->getDatabaseUsername($userId);
$this->setSessionValue('userlogin', $databaseUsername);
// lib/Application/Service/OidcService.php:360-371
$this->setSessionValue('userid', $userId);
...
$this->setSessionValue('authenticated', 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: victim.poweradmin@example.com
  password: VictimPassword123!

Attacker:
  username/sub: victím-login
  email: attacker.poweradmin@example.com
  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   victim.poweradmin@example.com

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:

{
  "attacker_login": {
    "selected_idp_user": "attacker",
    "selected_idp_username": "victím-login",
    "has_session_cookie": true,
    "home_contains_victim_username": true,
    "home_contains_attacker_username": false
  },
  "attacker_resolved_to_victim": 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   victim.poweradmin@example.com

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->db->prepare("
    SELECT user_id FROM oidc_user_links
    WHERE BINARY oidc_subject = BINARY ?
      AND BINARY provider_id = BINARY ?
");

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

Show details on source website

{
  "affected": [
    {
      "package": {
        "ecosystem": "Packagist",
        "name": "poweradmin/poweradmin"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "4.1.0"
            },
            {
              "fixed": "4.2.5"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    },
    {
      "package": {
        "ecosystem": "Packagist",
        "name": "poweradmin/poweradmin"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "4.3.0"
            },
            {
              "fixed": "4.3.4"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [],
  "database_specific": {
    "cwe_ids": [
      "CWE-287"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2026-07-24T21:56:02Z",
    "nvd_published_at": null,
    "severity": "HIGH"
  },
  "details": "## Preface\n\nPoweradmin 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.\n\nThe confirmed local PoC used two different OIDC users:\n\n- Victim subject: `victim-login`\n- Attacker subject: `vict\u00edm-login` (`\u00ed`, U+00ED)\n\nMySQL 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\u0027s own password and Poweradmin resolved the session to the victim\u0027s local account.\n\n## Server Info\n\n- **Application:** Poweradmin\n- **Version:** `targets/poweradmin` git `e1f9c9a`\n- **Database:** MySQL `8.4.10`, `character_set_server=utf8mb4`, `collation_server=utf8mb4_unicode_ci`\n- **Access Permissions:** Any user who can create or control an account in the connected OIDC provider\n- **Auth Method:** OIDC generic provider\n- **Tools:** Docker Compose, local OIDC provider, Python PoC harness\n\n**Affected Entry Point:**\n\n```text\nGET /oidc/login?provider=generic\nGET /oidc/callback?code=...\u0026state=...\n```\n\nRelevant request properties:\n\n- Authentication: valid OIDC authorization code flow\n- Trigger: attacker OIDC account has a `sub` that collides with a victim\u0027s linked `sub`\n- Vulnerable field: OIDC `sub` stored and looked up as `oidc_user_links.oidc_subject`\n\n## Root Cause Analysis\n\n### part0 \u2014 `oidc_user_links.oidc_subject` uses an accent-insensitive collation\n\nThe MySQL schema defines the OIDC link table with `utf8mb4_unicode_ci`:\n\n```sql\n-- sql/poweradmin-mysql-db-structure.sql:341-356\nCREATE TABLE `oidc_user_links` (\n  `user_id` INT(11) NOT NULL,\n  `provider_id` VARCHAR(50) NOT NULL,\n  `oidc_subject` VARCHAR(255) NOT NULL,\n  ...\n  UNIQUE KEY `unique_subject_provider` (`oidc_subject`, `provider_id`)\n) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4 COLLATE=utf8mb4_unicode_ci;\n```\n\nIn the PoC database:\n\n```text\nField          Type          Collation\nprovider_id    varchar(50)   utf8mb4_unicode_ci\noidc_subject   varchar(255)  utf8mb4_unicode_ci\n\nSELECT \u0027victim-login\u0027 = \u0027vict\u00edm-login\u0027 COLLATE utf8mb4_unicode_ci;\n-- accent_collision = 1\n```\n\n### part1 \u2014 OIDC `sub` flows into a normal SQL equality lookup\n\nPoweradmin reads the subject from OIDC userinfo data. If no custom `subject` mapping is configured, it uses the `sub` claim:\n\n```php\n// lib/Application/Service/OidcService.php:424-459\n$resourceOwner = $provider-\u003egetResourceOwner($token);\n$userData = $resourceOwner-\u003etoArray();\n...\nsubject: $userData[$mapping[\u0027subject\u0027] ?? \u0027sub\u0027] ?? \u0027\u0027,\n```\n\nThe callback passes the resulting `OidcUserInfo` to provisioning:\n\n```php\n// lib/Application/Service/OidcService.php:269-291\n$userInfo = $this-\u003egetUserInfo($provider, $token, $providerId);\n$userId = $this-\u003euserProvisioningService-\u003eprovisionUser($userInfo, $providerId);\n```\n\nProvisioning first tries to find an existing user by subject:\n\n```php\n// lib/Application/Service/UserProvisioningService.php:86-90\n$existingUserId = $authMethod === self::AUTH_METHOD_SAML\n    ? $this-\u003efindUserBySamlSubject($userInfo-\u003egetSubject(), $providerId)\n    : $this-\u003efindUserByOidcSubject($userInfo-\u003egetSubject(), $providerId);\n```\n\nThe lookup is normal SQL equality evaluated under the column\u0027s weak collation:\n\n```php\n// lib/Application/Service/UserProvisioningService.php:145-149\n$stmt = $this-\u003edb-\u003eprepare(\"\n    SELECT user_id FROM oidc_user_links\n    WHERE oidc_subject = ? AND provider_id = ?\n\");\n$stmt-\u003eexecute([$subject, $providerId]);\n```\n\nWhen the attacker authenticates with `sub = vict\u00edm-login`, MySQL matches the existing row for `oidc_subject = victim-login` and returns the victim\u0027s `user_id`.\n\n### part2 \u2014 The returned user ID becomes the authenticated session\n\nAfter provisioning returns the matched `user_id`, Poweradmin fetches the database username for that user and stores the matched user ID in the session:\n\n```php\n// lib/Application/Service/OidcService.php:307-317\n$databaseUsername = $this-\u003euserProvisioningService-\u003egetDatabaseUsername($userId);\n$this-\u003esetSessionValue(\u0027userlogin\u0027, $databaseUsername);\n```\n\n```php\n// lib/Application/Service/OidcService.php:360-371\n$this-\u003esetSessionValue(\u0027userid\u0027, $userId);\n...\n$this-\u003esetSessionValue(\u0027authenticated\u0027, true);\n```\n\nThe attacker\u0027s OIDC password is validated by the IdP, but the local `user_id` selected by Poweradmin comes from the weak-collation SQL lookup.\n\n## Security Impact\n\nAn attacker who can register or control an OIDC principal with an accent/collation variant of a victim\u0027s OIDC subject can authenticate with the attacker\u0027s own IdP credentials and obtain a Poweradmin session for the victim\u0027s local account.\n\nThe confirmed PoC used distinct OIDC usernames, subjects, emails, and passwords. The attacker did not know or modify the victim\u0027s password.\n\n## Reproduction\n\n### 1. Start the local Poweradmin OIDC lab\n\n```bash\nsudo -n docker compose -p poweradminoidcpoc -f poc/work/poweradmin-oidc-collation/docker-compose.yml up -d\n```\n\nThe lab uses MySQL `utf8mb4_unicode_ci` and a local OIDC provider with two real login accounts:\n\n```text\nVictim:\n  username/sub: victim-login\n  email: victim.poweradmin@example.com\n  password: VictimPassword123!\n\nAttacker:\n  username/sub: vict\u00edm-login\n  email: attacker.poweradmin@example.com\n  password: AttackerPassword123!\n```\n\n### 2. Log in once as the victim through OIDC\n\nAuthenticate through `GET /oidc/login?provider=generic` using:\n\n```text\nusername: victim-login\npassword: VictimPassword123!\n```\n\nPoweradmin creates the victim local user and OIDC link:\n\n```text\nusers:\nid  username      fullname            email\n2   victim-login  Victim Poweradmin   victim.poweradmin@example.com\n\noidc_user_links:\nid  user_id  provider_id  oidc_subject\n1   2        generic      victim-login\n```\n\n### 3. Log in as the attacker OIDC user\n\nAuthenticate from a separate browser session with:\n\n```text\nusername: vict\u00edm-login\npassword: AttackerPassword123!\n```\n\nObserved result from `poc/work/poweradmin-oidc-collation/run_poc.py`:\n\n```json\n{\n  \"attacker_login\": {\n    \"selected_idp_user\": \"attacker\",\n    \"selected_idp_username\": \"vict\u00edm-login\",\n    \"has_session_cookie\": true,\n    \"home_contains_victim_username\": true,\n    \"home_contains_attacker_username\": false\n  },\n  \"attacker_resolved_to_victim\": true\n}\n```\n\nDatabase evidence after both logins:\n\n```text\nversion  charset_server  collation_server\n8.4.10   utf8mb4         utf8mb4_unicode_ci\n\naccent_collision\n1\n\nusers:\nid  username      fullname            email\n2   victim-login  Victim Poweradmin   victim.poweradmin@example.com\n\noidc_user_links:\nid  user_id  provider_id  oidc_subject  oidc_subject_hex\n1   2        generic      victim-login   76696374696D2D6C6F67696E\n```\n\nThe application audit log also records all OIDC login events as the victim user:\n\n```text\nuser:victim-login operation:login_success auth_method:oidc\n```\n\nNo local user or OIDC link was created for `vict\u00edm-login`.\n\n## Recommended Fix\n\nTreat OIDC subject identifiers as byte-exact strings.\n\nFor MySQL, migrate the OIDC mapping identifiers to a binary or byte-preserving collation:\n\n```sql\nALTER TABLE oidc_user_links\n  MODIFY COLUMN provider_id varchar(50)\n    CHARACTER SET utf8mb4 COLLATE utf8mb4_bin NOT NULL,\n  MODIFY COLUMN oidc_subject varchar(255)\n    CHARACTER SET utf8mb4 COLLATE utf8mb4_bin NOT NULL;\n```\n\nAlso make lookup queries byte-preserving so patched application code protects existing deployments before schema migrations are complete:\n\n```php\n$stmt = $this-\u003edb-\u003eprepare(\"\n    SELECT user_id FROM oidc_user_links\n    WHERE BINARY oidc_subject = BINARY ?\n      AND BINARY provider_id = BINARY ?\n\");\n```\n\nReview related identity and authorization lookups:\n\n- `findUserByEmail()` uses `users.email = ?` and can be impacted when `link_by_email` is enabled.\n- `findPermissionTemplateByName()` uses `perm_templ.name = ?` for SSO permission template mapping.\n- `findGroupByName()` uses `user_groups.name = ?` for SSO group mapping.\n\nThose fields should either be intentionally documented as case/accent-insensitive or migrated/looked up with byte-preserving semantics where they represent security boundaries.\n\n## Patches\n\nFixed 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.\n\n## Acknowledge / Credit\n\nwhale120 (@whale120_tw), working with DEVCORE Internship Program",
  "id": "GHSA-cmwh-g2h8-c222",
  "modified": "2026-07-24T21:56:02Z",
  "published": "2026-07-24T21:56:02Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/poweradmin/poweradmin/security/advisories/GHSA-cmwh-g2h8-c222"
    },
    {
      "type": "WEB",
      "url": "https://github.com/poweradmin/poweradmin/commit/cbb78f401a9cc77c976939e93b558f39cb738965"
    },
    {
      "type": "WEB",
      "url": "https://github.com/poweradmin/poweradmin/commit/f814f9e241a7af742193cb68f80b19867c24ba69"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/poweradmin/poweradmin"
    },
    {
      "type": "WEB",
      "url": "https://github.com/poweradmin/poweradmin/releases/tag/v4.2.5"
    },
    {
      "type": "WEB",
      "url": "https://github.com/poweradmin/poweradmin/releases/tag/v4.3.4"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:N",
      "type": "CVSS_V3"
    }
  ],
  "summary": "Poweradmin: OIDC `sub` collation bypass in Poweradmin leading to account takeover"
}

Mitigation
Architecture and Design

Strategy: Libraries or Frameworks

Use an authentication framework or library such as the OWASP ESAPI Authentication feature.

CAPEC-114: Authentication Abuse

An attacker obtains unauthorized access to an application, service or device either through knowledge of the inherent weaknesses of an authentication mechanism, or by exploiting a flaw in the authentication scheme's implementation. In such an attack an authentication mechanism is functioning but a carefully controlled sequence of events causes the mechanism to grant access to the attacker.

CAPEC-115: Authentication Bypass

An attacker gains access to application, service, or device with the privileges of an authorized or privileged user by evading or circumventing an authentication mechanism. The attacker is therefore able to access protected data without authentication ever having taken place.

CAPEC-151: Identity Spoofing

Identity Spoofing refers to the action of assuming (i.e., taking on) the identity of some other entity (human or non-human) and then using that identity to accomplish a goal. An adversary may craft messages that appear to come from a different principle or use stolen / spoofed authentication credentials.

CAPEC-194: Fake the Source of Data

An adversary takes advantage of improper authentication to provide data or services under a falsified identity. The purpose of using the falsified identity may be to prevent traceability of the provided data or to assume the rights granted to another individual. One of the simplest forms of this attack would be the creation of an email message with a modified "From" field in order to appear that the message was sent from someone other than the actual sender. The root of the attack (in this case the email system) fails to properly authenticate the source and this results in the reader incorrectly performing the instructed action. Results of the attack vary depending on the details of the attack, but common results include privilege escalation, obfuscation of other attacks, and data corruption/manipulation.

CAPEC-22: Exploiting Trust in Client

An attack of this type exploits vulnerabilities in client/server communication channel authentication and data integrity. It leverages the implicit trust a server places in the client, or more importantly, that which the server believes is the client. An attacker executes this type of attack by communicating directly with the server where the server believes it is communicating only with a valid client. There are numerous variations of this type of attack.

CAPEC-57: Utilizing REST's Trust in the System Resource to Obtain Sensitive Data

This attack utilizes a REST(REpresentational State Transfer)-style applications' trust in the system resources and environment to obtain sensitive data once SSL is terminated.

CAPEC-593: Session Hijacking

This type of attack involves an adversary that exploits weaknesses in an application's use of sessions in performing authentication. The adversary is able to steal or manipulate an active session and use it to gain unathorized access to the application.

CAPEC-633: Token Impersonation

An adversary exploits a weakness in authentication to create an access token (or equivalent) that impersonates a different entity, and then associates a process/thread to that that impersonated token. This action causes a downstream user to make a decision or take action that is based on the assumed identity, and not the response that blocks the adversary.

CAPEC-650: Upload a Web Shell to a Web Server

By exploiting insufficient permissions, it is possible to upload a web shell to a web server in such a way that it can be executed remotely. This shell can have various capabilities, thereby acting as a "gateway" to the underlying web server. The shell might execute at the higher permission level of the web server, providing the ability the execute malicious code at elevated levels.

CAPEC-94: Adversary in the Middle (AiTM)

An adversary targets the communication between two components (typically client and server), in order to alter or obtain data from transactions. A general approach entails the adversary placing themself within the communication channel between the two components.