Summary
phpIPAM contains an incorrect authorization check in the user API when requests use the identifiers id=="admins" or id=="all".
Depending on the endpoint and account permissions, an attacker may access or modify user-related resources that should be restricted.
Affected context
The vulnerability occurs in phpIPAM deployments using the user API controller, specifically where requests handle the admins or all identifiers. Risk depends on which API operations are exposed, how authentication and authorization are configured, and whether an attacker can submit requests to the affected endpoints.
Exploit preconditions
- Attack surface: phpIPAM user API endpoints handled by
api/controllers/User.php - Required access: The ability to reach the relevant API endpoint; authentication requirements depend on deployment configuration
- Trigger point: A request referencing
id=="admins"orid=="all" - Why exploitation is possible: Authorization logic does not correctly restrict access to these identifier values before the requested user operation is performed
Why this happens
The underlying bug is an authorization decision that does not correctly enforce permissions for special identifier values representing administrator or aggregate user selections.
When authorization checks are incomplete, incorrectly scoped, or evaluated differently for these values, a caller may reach operations outside their permitted scope. This behavior maps to CWE-863: Incorrect Authorization, where access-control logic fails to enforce the intended policy.
Potential impact
- Unauthorized disclosure of user or administrator account information may occur
- Unauthorized user-management actions could be performed
- Administrative account metadata may be exposed
- Account integrity or application access controls could be affected
- The issue could support follow-on attacks against phpIPAM or connected systems
General mitigation guidance
Mitigation generally focuses on enforcing authorization consistently for every identifier form, including special values such as aggregate or role-based selectors.
Common defensive patterns include:
- Applying server-side, deny-by-default authorization checks before each user operation
- Treating special identifiers as privileged resources rather than bypassing normal access checks
- Deriving authorization decisions from the authenticated principal and explicit resource ownership
- Avoiding reliance on client-supplied identifiers or UI-level restrictions
- Limiting API accounts and service identities to the minimum required privileges
- Recording and reviewing sensitive user-management operations
How teams detect issues like this
Organizations can look for this issue through:
- Static analysis and code review of authorization branches handling special identifiers
- Tests that compare permissions for individual, aggregate, and role-based resource selectors
- API security testing using accounts with distinct privilege levels
- Monitoring requests involving
id=adminsorid=all, especially when issued by non-administrative identities - Policy checks requiring authorization to occur before database access or state-changing operations
Automated application-security testing and authorization-focused regression suites can help identify inconsistent access-control behavior.
