What is the CVSS score of CVE-2026-30269?

CVE-2026-30269 has a CVSS 3.1 base score of 9.9 (Critical). CVSS vector: CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:C/C:H/I:H/A:L. EPSS exploitation probability: 0.0%.

Which versions of N A are affected by CVE-2026-30269?

Doorman API gateway versions 0.1.0 and 1.0.2 contain a critical privilege escalation flaw enabling any authenticated user to self-elevate to high-privileged roles (manager, developer) without…

How to fix or mitigate CVE-2026-30269?

Within 24 hours: Identify all Doorman API gateway instances running v0.1.0 or v1.0.2 in production and development environments; restrict API access to the /platform/user/{username} endpoint to administrative accounts only via WAF or network controls. Within 7 days: Monitor authentication logs for suspicious role modification attempts on the affected endpoint; prepare rollback plan if vendor patch becomes available. Within 30 days: Contact Doorman vendor for patched version timeline; evaluate alternative API gateway solutions if no patch released; implement mandatory administrative approval workflow for all role changes regardless of endpoint.

N A CVE-2026-30269

EUVD-2026-23902 CRITICAL

Improper Privilege Management (CWE-269)

2026-04-20 mitre

GHSA-4cgq-vq3r-c9r4

Privilege Escalation N A

9.9

CVSS 3.1 · NVD

Severity by source

NVD PRIMARY

9.9 CRITICAL

AV:N/AC:L/PR:L/UI:N/S:C/C:H/I:H/A:L

Primary rating from NVD · only source for this CVE.

CVSS VectorNVD

Attack Vector

Network

Attack Complexity

Low

Privileges Required

Low

User Interaction

None

Scope

Changed

Confidentiality

High

Integrity

High

Availability

Low

Lifecycle Timeline

Re-analysis Queued

Apr 27, 2026 - 15:37 vuln.today

cvss_changed

Analysis Generated

Apr 20, 2026 - 19:57 vuln.today

CVSS changed

Apr 20, 2026 - 19:22 NVD

9.9 (CRITICAL)

EUVD ID Assigned

Apr 20, 2026 - 17:15 euvd

EUVD-2026-23902

Analysis Generated

Apr 20, 2026 - 17:15 vuln.today

CVE Published

Apr 20, 2026 - 00:00 nvd

CRITICAL 9.9

DescriptionCVE.org

Improper access control in Doorman v0.1.0 and v1.0.2 allows any authenticated user to update their own account role to a non-admin privileged role via /platform/user/{username}. The role field is accepted by the update model without a manage_users permission check for self-updates, enabling privilege escalation to high-privileged roles.

AnalysisAI

Privilege escalation in Doorman API gateway v0.1.0 and v1.0.2 allows authenticated users to elevate their role to high-privileged (non-admin) accounts by directly editing the 'role' field via the /platform/user/{username} endpoint. The vulnerability stems from missing authorization checks on self-service user updates - any valid login credential is sufficient to escalate privileges to roles like 'manager' or 'developer'. CVSS 9.9 (Critical) reflects the Changed scope and broad compromise potential. SSVC indicates proof-of-concept code exists but exploitation requires human interaction (not automatable), suggesting targeted rather than mass-exploitation risk. No CISA KEV listing at time of analysis.

Technical ContextAI

Doorman is an API gateway and identity management platform. The vulnerability resides in the user account update handler at /platform/user/{username}, which accepts a 'role' parameter in PUT/PATCH requests. CWE-269 (Improper Privilege Management) indicates the platform fails to enforce separation of privilege management from self-service operations. The update model applies role changes before validating whether the requester holds 'manage_users' permission, creating a classic Insecure Direct Object Reference (IDOR) variant where users control their own authorization level. The Changed Scope (S:C) in the CVSS vector suggests escalated roles can impact resources beyond the user's original security boundary - likely accessing other tenants' data or administrative functions. CPE data is incomplete (cpe:2.3:a:n/a:n/a), but GitHub repository and EUVD confirm the product is 'apidoorman/doorman' with versions 0.1.0 and 1.0.2 explicitly affected.

RemediationAI

Upgrade to Doorman version 1.0.3 or later if available - verify fix status at github.com/apidoorman/doorman/releases, as NVD data does not confirm a patched version number. Review the researcher's blog post at blog.orxiain.life/archives/cve-2026-30269 for vendor response timeline and mitigation guidance. If no patch is released: (1) Implement API gateway rules or reverse proxy ACLs to block PUT/PATCH requests to /platform/user/{username} for all users except those with explicit 'manage_users' permission - this prevents self-updates entirely but breaks legitimate profile editing (users cannot update email, password, etc.); (2) Apply input validation middleware to reject 'role' parameters in user update payloads unless requester is admin - requires application-layer filtering and may be bypassable via parameter pollution; (3) Audit existing user roles via database query to identify and demote any unauthorized escalations - check audit logs for POST/PUT to /platform/user/* endpoints. Long-term: replace Doorman with actively maintained API gateway solutions if the project is unmaintained (repository has no activity since vulnerability disclosure).