SURIQ
If you saw the phpIPAM 1.8.2 update last week and decided the flaw it fixed was too niche to rush, this changes the math. The same release closes a second bug, and this one is worse. CVE-2026-67602 is a critical authentication bypass in phpIPAM's REST API: no login, no share link, no credentials. An unauthenticated attacker who can reach the API can read, change, and delete every record in your address database.
phpIPAM is the open-source tool many teams use to track their subnets, IP allocations, VLANs, and device notes. VulnCheck, which assigned the CVE, rates it 9.3 on the CVSS version 4 scale (9.1 on version 3.1). It is fixed in version 1.8.2, and every release before that is affected.
A row number that works as a master key
The bug lives in how phpIPAM cached API objects. The cache stored each result under a key built from the value being looked up, but it left out which field that value belonged to. So an entry saved during one kind of lookup could be served back for a different kind of lookup that happened to share the same value.
The practical effect, per VulnCheck's advisory, is that a plain database row number can stand in for a valid API token. The API treats the attacker as an authenticated client and hands over full access. There is no password to guess and no session to steal, which is what pushes this into critical territory. Unauthenticated bypasses also get mass-scanned quickly once they are known, the same urgency we flagged with the recent NetScaler bypass. The patch makes the cache key include the field name, so a token lookup can no longer collide with an unrelated record lookup.
Two critical flaws, one patch
We wrote about CVE-2026-75105 a week ago: a broken-authorization flaw rated 8.7 where anyone holding a temporary share link could read every subnet, not just the one the link was issued for. That one at least needed a valid link. CVE-2026-67602 needs nothing, and it adds write and delete on top of read. Both are fixed in the same 1.8.2 release, so a single update closes both.
| Flaw in phpIPAM 1.8.2 | CVE-2026-75105 | CVE-2026-67602 |
|---|---|---|
| Type | Broken authorization | Authentication bypass |
| Access needed | A valid temporary share link | None (unauthenticated) |
| CVSS v4.0 | 8.7 | 9.3 |
| What an attacker gets | Read every IP record | Read, change, and delete every record |
| Fixed in | 1.8.2 | 1.8.2 |
What a full IPAM takeover exposes
An IP address manager is a map of your whole network, and that map is exactly what an attacker wants before moving laterally. Read access alone gives up your subnet layout, hostnames, device roles, and any credentials or context teams have dropped into the free-text notes fields, which people do constantly. Write and delete access is worse. An attacker can quietly change records to misdirect your own operators, or wipe allocations to cause an outage. For a tool that normally sits on an internal management network, public exposure of its API is the emergency to check first.
How would you know if someone used it
This is the uncomfortable part. Because the flaw abuses the API's own authentication path, a successful hit does not produce a failed-login event. There is no brute force to spot. What you can look for is the shape of the abuse: unauthenticated-looking API traffic that succeeds, requests to the REST API that carry very small numeric values where a token belongs, or reads and deletes fanning across many subnets in a short window. Pull your reverse proxy and web server access logs for the phpIPAM REST API path and review who has been calling it.
This is the kind of exposure a managed detection setup is meant to surface: an internal app that suddenly serves API traffic it never did before, raised as an alert rather than found weeks later. Patching closes the hole. Log review tells you whether anyone walked through it first.
Update to 1.8.2, then close off the API
Upgrade to phpIPAM 1.8.2 now. It is the fix for both this bug and the share-link flaw, so there is no reason to stage it. After you patch, do two more things. Make sure the phpIPAM REST API is not reachable from the public internet, behind your VPN or an IP allowlist where most internal tools belong. Then rotate your phpIPAM API keys, since you cannot be certain one was not scraped through the cache before the fix landed. There is no public exploit and no reported in-the-wild abuse yet, but the root cause is simple enough that this quiet window will not last.