Severity by source
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
CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:C/C:H/I:H/A:L
Lifecycle Timeline
6DescriptionCVE.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).
Same weakness CWE-269 – Improper Privilege Management
View allSame technique Privilege Escalation
View allShare
External POC / Exploit Code
Leaving vuln.today
EUVD-2026-23902
GHSA-4cgq-vq3r-c9r4