CVE-2026-67602 in phpIPAM
Summary
by MITRE • 08/24/2026
phpIPAM before 1.8.2 contains an authentication bypass vulnerability in the REST API that allows unauthenticated attackers to gain full API access by exploiting an insecure object cache keying mechanism. The cache is keyed by lookup value alone without including the searched column, enabling an entry written during an app_id lookup to satisfy a subsequent app_code lookup, allowing attackers to use the numeric database row identifier as an API token to read, write, and delete all IP address management records.
If you want to get best quality of vulnerability data, you may have to visit VulDB.
Analysis
by VulDB Data Team • 08/24/2026
The vulnerability identified in phpIPAM versions prior to 1.8.2 represents a critical authentication bypass within its REST API infrastructure, stemming from a fundamental flaw in how the application manages object caching for user sessions or tokens. The core technical issue lies in an insecure cache keying mechanism where the cache lookup is performed using only the value of a specific identifier without validating the corresponding column type that generated it. Specifically, when the system performs lookups based on app_id and app_code, it fails to distinguish between entries stored under these distinct keys if their underlying values happen to match numerically. This design oversight allows an attacker to manipulate the cache state by first triggering an operation with a crafted app_id value, which stores a valid session token or authentication object in the cache keyed solely by that numeric string. Subsequently, when the system attempts to authenticate via an app_code lookup using the same numeric string as its key, it retrieves the previously cached entry intended for the app_id context. This cross-context retrieval effectively bypasses the authentication requirement because the application accepts a valid token from one logical domain within another unrelated domain where that token was never authorized or generated.
From an operational perspective, this flaw grants unauthenticated attackers full administrative access to the IP Address Management (IPAM) system without requiring any credentials. Once authenticated through this cache poisoning technique, the attacker can utilize standard REST API endpoints to read sensitive network topology data, modify existing records, and delete critical infrastructure information. The impact is severe as it compromises the integrity of DNS configurations, subnet allocations, and device inventory records that are central to IT operations. An adversary could disrupt service availability by deleting essential IP assignments or cause significant operational confusion by altering address ranges without authorization. This level of access also facilitates further reconnaissance within the network, potentially leading to lateral movement if other systems rely on the compromised phpIPAM data for automated provisioning or security policies.
This vulnerability aligns with CWE-287 Improper Authentication and CWE-362 Concurrent Execution using Shared Resource with Insufficient Synchronization in terms of state management errors that lead to privilege escalation via cache manipulation. In the context of the MITRE ATT&CK framework, this exploit maps directly to T1078 Valid Accounts as it involves obtaining legitimate credentials through improper validation mechanisms rather than brute force or credential stuffing. It also relates to T1534 Internal Spearphishing if used in conjunction with social engineering but primarily stands alone as a direct API exploitation technique categorized under privilege escalation via application logic flaws. The lack of strict separation between different identifier types during cache retrieval is the primary vector that enables this unauthorized access path.
Mitigation strategies must focus on immediate patching and architectural review. Organizations running phpIPAM versions earlier than 1.8.2 should upgrade to the latest stable release immediately, as version 1.8.2 contains a fix for this specific caching logic error. Until upgrading is possible, administrators can implement temporary compensating controls such as placing the REST API behind an external Web Application Firewall that enforces strict rate limiting and validates request origins. Additionally, disabling unnecessary API endpoints or restricting access to internal networks only can reduce the attack surface. It is also advisable to review application code for similar patterns where cache keys are derived from single values without sufficient context validation across different functional modules. Regular security audits focusing on session management and caching implementations in web applications will help prevent recurrence of such logic-based authentication bypasses.