Description

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.

Executive Summary

Technical Details

Mitigations

References

Additional Metadata

{
  "score": "9.1",
  "pubDate": "2026-08-24T14:16:57.347Z",
  "pubdate": "2026-08-24T14:16:57.347Z",
  "executiveSummary": "phpIPAM before 1.8.2 suffers from an authentication bypass vulnerability within its REST API component. The underlying security flaw stems from an insecure object cache keying mechanism that improperly differentiates cache keys. Specifically, the caching layer keys entries strictly by the lookup value alone, omitting the associated searched database column from the key structure.\nThis design flaw allows an entry written during an app_id lookup to improperly satisfy a subsequent app_code lookup. Consequently, unauthenticated attackers can leverage this cache collision by using a numeric database row identifier as a valid API token.\nSuccessful exploitation grants unauthorized threat actors full, unauthenticated API access to the underlying system. The resulting impact includes the complete compromise of confidentiality, integrity, and availability of all IP address management records stored within the application.\nAttackers achieve full administrative capabilities over IP management data, enabling them to read, write, and delete critical network records without possessing valid credentials. No prior authentication or elevated privileges are required, lowering the barrier to exploitation across exposed network endpoints hosting the vulnerable REST API.",
  "technicalDetails": "The vulnerability resides in the REST API authentication handling of phpIPAM versions prior to 1.8.2. The root cause is an insecure object cache keying implementation. When the application performs database lookups to validate API application identifiers, it caches the results to optimize performance.\nHowever, the cache generation logic fails to incorporate the targeted database column into the cache key composition. The cache key is constructed using only the raw lookup value. This architectural oversight introduces a cross-column cache collision vulnerability.\nThe attack flow proceeds as follows: First, an unauthenticated attacker interacts with the REST API using a crafted request. By querying the application with a specific numeric value intended for an app_id lookup, the application queries the database and caches the resulting object associated solely with that raw numeric string.\nNext, the attacker initiates a subsequent authentication request targeting the app_code validation mechanism using the exact same numeric value as the lookup parameter. Because the caching mechanism evaluates only the lookup value and ignores the column context, the cache retrieves the previously stored entry.\nThe cached entry, originally mapped from the app_id query, satisfies the app_code validation check. This effectively permits the attacker to supply a predictable numeric database row identifier—such as integer values starting from 1—to masquerade as a legitimate, authenticated API token.\nNetwork exposure is defined by the availability of the phpIPAM REST API endpoints over the network. Authentication requirements are entirely bypassed due to the flawed cache validation logic, and no privilege requirements exist for the initial phase of the attack.\nPost-exploitation impact is severe. Once the authentication check is bypassed via the numeric database row identifier, the attacker gains unrestricted API access. This grants the capability to execute administrative-level commands to read, write, and delete all IP address management records, exposing internal network topologies and facilitating further lateral movement or network disruption."
}