CWE-287
DiscouragedImproper 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.
6051 vulnerabilities reference this CWE, most recent first.
GHSA-CMJP-5PJJ-7527
Vulnerability from github – Published: 2022-05-01 18:23 – Updated: 2022-05-01 18:23Session fixation vulnerability in Ampache before 3.3.3.5 allows remote attackers to hijack web sessions via unspecified vectors.
{
"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:31An improper authentication vulnerability in web component of EPMM prior to 12.1.0.1 allows a remote malicious user to access potentially sensitive information
{
"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** 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."
{
"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:56Preface
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/poweradmingite1f9c9a - 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
subthat collides with a victim's linkedsub - Vulnerable field: OIDC
substored and looked up asoidc_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()usesusers.email = ?and can be impacted whenlink_by_emailis enabled.findPermissionTemplateByName()usesperm_templ.name = ?for SSO permission template mapping.findGroupByName()usesuser_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
{
"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"
}
GHSA-CP23-9G3V-FP46
Vulnerability from github – Published: 2022-05-24 17:30 – Updated: 2022-05-24 17:30The Agent Update System in ConnectWise Automate before 2020.8 allows Privilege Escalation because the _LTUPDATE folder has weak permissions.
{
"affected": [],
"aliases": [
"CVE-2020-15838"
],
"database_specific": {
"cwe_ids": [
"CWE-287"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2020-10-09T07:15:00Z",
"severity": "HIGH"
},
"details": "The Agent Update System in ConnectWise Automate before 2020.8 allows Privilege Escalation because the _LTUPDATE folder has weak permissions.",
"id": "GHSA-cp23-9g3v-fp46",
"modified": "2022-05-24T17:30:23Z",
"published": "2022-05-24T17:30:23Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2020-15838"
},
{
"type": "WEB",
"url": "https://dbeta.com/2020/10/05/PrivilegeEscalationInAutomateAgent"
},
{
"type": "WEB",
"url": "https://www.connectwise.com/company/trust/security-bulletins"
}
],
"schema_version": "1.4.0",
"severity": []
}
GHSA-CP2G-FW99-PPRJ
Vulnerability from github – Published: 2022-10-15 12:00 – Updated: 2022-10-18 19:00An issue in OXHOO TP50 OXH1.50 allows unauthenticated attackers to access the administrative panel via browsing to the URL http://device_ip/index1.html.
{
"affected": [],
"aliases": [
"CVE-2022-41436"
],
"database_specific": {
"cwe_ids": [
"CWE-287"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2022-10-14T21:15:00Z",
"severity": "CRITICAL"
},
"details": "An issue in OXHOO TP50 OXH1.50 allows unauthenticated attackers to access the administrative panel via browsing to the URL http://device_ip/index1.html.",
"id": "GHSA-cp2g-fw99-pprj",
"modified": "2022-10-18T19:00:29Z",
"published": "2022-10-15T12:00:54Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2022-41436"
},
{
"type": "WEB",
"url": "https://github.com/NF-Security-Team/CVEs/blob/main/CVE-OXHOO/Readme.md"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:N",
"type": "CVSS_V3"
}
]
}
GHSA-CP3M-5WF6-4649
Vulnerability from github – Published: 2026-02-11 15:30 – Updated: 2026-02-12 18:30METIS WIC devices (versions <= oscore 2.1.234-r18) expose a web-based shell at the /console endpoint that does not require authentication. Accessing this endpoint allows a remote attacker to execute arbitrary operating system commands with root (UID 0) privileges. This results in full system compromise, allowing unauthorized access to modify system configuration, read sensitive data, or disrupt device operations
{
"affected": [],
"aliases": [
"CVE-2026-2248"
],
"database_specific": {
"cwe_ids": [
"CWE-287"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2026-02-11T15:16:17Z",
"severity": "CRITICAL"
},
"details": "METIS WIC devices (versions \u003c= oscore 2.1.234-r18) expose a web-based shell at the /console endpoint that does not require authentication. Accessing this endpoint allows a remote attacker to execute arbitrary operating system commands with root (UID 0) privileges. This results in full system compromise, allowing unauthorized access to modify system configuration, read sensitive data, or disrupt device operations",
"id": "GHSA-cp3m-5wf6-4649",
"modified": "2026-02-12T18:30:21Z",
"published": "2026-02-11T15:30:27Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-2248"
},
{
"type": "WEB",
"url": "https://cydome.io/vulnerability-advisory-cve-2026-2248-unauthenticated-remote-root-shell-in-metis-wic"
},
{
"type": "WEB",
"url": "https://www.metis.tech"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H",
"type": "CVSS_V3"
}
]
}
GHSA-CP4Q-WHX3-Q2QG
Vulnerability from github – Published: 2022-05-17 04:50 – Updated: 2022-05-17 04:50The Cisco Unified IP Phone 7960G 9.2(1) and earlier allows remote attackers to bypass authentication and change trust relationships by injecting a Certificate Trust List (CTL) file, aka Bug ID CSCuj66795.
{
"affected": [],
"aliases": [
"CVE-2014-0737"
],
"database_specific": {
"cwe_ids": [
"CWE-287"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2014-02-22T21:55:00Z",
"severity": "MODERATE"
},
"details": "The Cisco Unified IP Phone 7960G 9.2(1) and earlier allows remote attackers to bypass authentication and change trust relationships by injecting a Certificate Trust List (CTL) file, aka Bug ID CSCuj66795.",
"id": "GHSA-cp4q-whx3-q2qg",
"modified": "2022-05-17T04:50:41Z",
"published": "2022-05-17T04:50:41Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2014-0737"
},
{
"type": "WEB",
"url": "http://tools.cisco.com/security/center/content/CiscoSecurityNotice/CVE-2014-0737"
},
{
"type": "WEB",
"url": "http://tools.cisco.com/security/center/viewAlert.x?alertId=32957"
}
],
"schema_version": "1.4.0",
"severity": []
}
GHSA-CP6R-8QHX-6M32
Vulnerability from github – Published: 2022-05-24 19:01 – Updated: 2022-07-13 00:01A security vulnerability has been identified in the HPE Edgeline Infrastructure Manager, also known as HPE Edgeline Infrastructure Management Software, prior to version 1.22. The vulnerability could be remotely exploited to bypass remote authentication leading to execution of arbitrary commands, gaining privileged access, causing denial of service, and changing the configuration. HPE has released a software update to resolve the vulnerability in the HPE Edgeline Infrastructure Manager.
{
"affected": [],
"aliases": [
"CVE-2021-29203"
],
"database_specific": {
"cwe_ids": [
"CWE-287"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2021-05-06T21:15:00Z",
"severity": "CRITICAL"
},
"details": "A security vulnerability has been identified in the HPE Edgeline Infrastructure Manager, also known as HPE Edgeline Infrastructure Management Software, prior to version 1.22. The vulnerability could be remotely exploited to bypass remote authentication leading to execution of arbitrary commands, gaining privileged access, causing denial of service, and changing the configuration. HPE has released a software update to resolve the vulnerability in the HPE Edgeline Infrastructure Manager.",
"id": "GHSA-cp6r-8qhx-6m32",
"modified": "2022-07-13T00:01:16Z",
"published": "2022-05-24T19:01:26Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2021-29203"
},
{
"type": "WEB",
"url": "https://support.hpe.com/hpsc/doc/public/display?docLocale=en_US\u0026docId=emr_na-hpesbgn04124en_us"
},
{
"type": "WEB",
"url": "https://www.tenable.com/security/research/tra-2021-15"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H",
"type": "CVSS_V3"
}
]
}
GHSA-CP9F-7JR4-M2MJ
Vulnerability from github – Published: 2025-04-08 21:31 – Updated: 2025-04-08 21:31ColdFusion versions 2023.12, 2021.18, 2025.0 and earlier are affected by an Improper Authentication vulnerability that could result in arbitrary code execution in the context of the current user. An attacker could leverage this vulnerability to bypass authentication mechanisms and execute code with the privileges of the authenticated user. Exploitation of this issue requires user interaction in that a victim must be coerced into performing actions within the application.
{
"affected": [],
"aliases": [
"CVE-2025-30282"
],
"database_specific": {
"cwe_ids": [
"CWE-287"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2025-04-08T20:15:25Z",
"severity": "CRITICAL"
},
"details": "ColdFusion versions 2023.12, 2021.18, 2025.0 and earlier are affected by an Improper Authentication vulnerability that could result in arbitrary code execution in the context of the current user. An attacker could leverage this vulnerability to bypass authentication mechanisms and execute code with the privileges of the authenticated user. Exploitation of this issue requires user interaction in that a victim must be coerced into performing actions within the application.",
"id": "GHSA-cp9f-7jr4-m2mj",
"modified": "2025-04-08T21:31:40Z",
"published": "2025-04-08T21:31:40Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-30282"
},
{
"type": "WEB",
"url": "https://helpx.adobe.com/security/products/coldfusion/apsb25-15.html"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:L/PR:H/UI:N/S:C/C:H/I:H/A:H",
"type": "CVSS_V3"
}
]
}
Mitigation
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.