phpIPAM CVE-2026-67602

Exploitation requires that the phpIPAM REST API be enabled and network-reachable by the attacker; the attacker supplies a numeric database row identifier (app_id value) where a secret API token (app_code) is expected, and relies on a prior cache entry so that the incorrectly-keyed object cache resolves the collision. No authentication, credentials, or user interaction are needed (PR:N/UI:N), and default configurations with the API in use are exploitable. The main limiting factors are that the REST API must be active and exposed - instances that do not expose or use the REST API, or that restrict it to trusted hosts, are not practically reachable - and the target must be running a version before 1.8.2.

The signals are consistent and point to real, actionable risk rather than an inflated CVSS number. The CVSS 4.0 vector (AV:N/AC:L/AT:N/PR:N/UI:N/VC:H/VI:H/VA:N) indicates fully remote, low-complexity, unauthenticated exploitation with high confidentiality and integrity impact, and the exploitation primitive - substituting a low-integer row ID for a secret token - is trivially automatable and requires no special knowledge or brute forcing of a large keyspace. It is not in CISA KEV and no EPSS score was provided, so widespread active exploitation is not confirmed; however, the technique is documented in a VulnCheck advisory and reproducible from the public patch commit, which typically shortens time-to-exploit. Any organization running phpIPAM with the REST API enabled and reachable from an untrusted network should treat this as urgent and patch promptly. Note the one apparent tension: the description mentions the ability to delete records (an availability/integrity effect), yet the vendor vector sets VA:N - deletion is scored here as an integrity impact rather than availability, which is defensible but worth verifying against the vendor advisory if availability weighting matters to your prioritization.

An attacker who can reach the phpIPAM REST API sends an authentication request presenting a small integer (e.g., a low database row ID) in place of a secret app_code token; due to the cache key collision, the value is accepted and the attacker receives authenticated API access. From there they enumerate, modify, and delete all IPAM records - subnets, addresses, and device data - without any credentials. The technique is documented by VulnCheck and reproducible from the public patch, so a working exploit path is effectively known even absent a packaged tool.