SURIQ
phpIPAM is the open-source tool a lot of network and hosting teams lean on to document their address space. Every subnet, every IP, who owns it, the hostname and MAC address behind it, and a free-text notes field where operators routinely park device credentials and configuration detail. A flaw disclosed on August 17 turns a single shared link into a read of that entire database. CVE-2026-75105 is rated 8.7 on the CVSS version 4 scale, it affects every release through 1.8.1, and the fix is in 1.8.2.
The root cause is a broken authorization check, not an injection or a memory bug. phpIPAM lets you mint a temporary share link so someone without an account can view one specific subnet. According to VulnCheck, the CVE numbering authority for this record, the code behind those links reads the numeric address ID straight from the URL and looks it up as a database key, without confirming the address actually belongs to the subnet the link was issued for. Change that number and you get a different record. Walk the numbers in order and you get all of them, across every section and subnet in the install, not just the one that was shared.
What an attacker actually walks away with
Label it information disclosure and it sounds like a minor leak. It is not, because of what phpIPAM stores. An IPAM database is the map of the network: internal ranges, live hosts, naming conventions, DNS names, MAC addresses, and the owner and contact fields that tell an attacker which machine matters and who runs it. The CVE record also calls out the notes field, and that is the sharp edge. Notes are where a tired operator writes down a switch password, an iDRAC login, or a VLAN quirk. One unauthenticated read of the whole table is a finished reconnaissance package: the target list and, often, the way in.
That is the part most of the early framing understates. This is classed as read-only exposure, but for a documentation system the read is the prize. You do not need write access to a map to use it.
The share link is a weaker guard than it looks
The one precondition is that the attacker holds a valid, non-expired share link. That sounds like a high bar. It is lower than it sounds, because share links are built to be handed to people who do not have accounts, which means they travel. They go out in email threads, support tickets, chat messages, and calendar invites, and they sit in browser history and proxy logs long after the person who needed them is done. Any one of those copies works until the token expires, and the CVSS vector reflects that: the vulnerability needs no privileges and no user interaction (CWE-639, authorization bypass through a user-controlled key). Treat every share link you have ever sent as a credential that can be replayed by whoever ends up with it.
There is no report of exploitation in the wild yet, the CVE is not on CISA's Known Exploited Vulnerabilities list, and no public proof-of-concept has been posted. That is the current state, not a reason to wait. The mechanism is simple enough to rediscover from the advisory description alone.
How you would know a link was walked
Patching closes the hole. It does not tell you whether someone already dumped your address space through a share link that is still live. That is the question worth answering before you move on, and the answer is in your web server access logs.
The abuse pattern is sequential enumeration: repeated requests to the temporary-share address view from one source, with an ID parameter that climbs through a range of values in a short window. A legitimate viewer opens the subnet they were given and stops. An attacker walks the numbers. Pull the access logs for the share endpoints, group by source address, and look for a single client that requested many distinct address IDs in a burst. If you find one, treat the records it touched as exposed and rotate anything sensitive, starting with whatever lived in the notes.
This is a good example of a self-hosted app where broken access control, not a headline remote-code bug, is the real exposure, the same shape we saw in the Magento account-takeover flaw and in the run of unauthenticated web-app disclosures landing this month.
Update to 1.8.2, then revoke every share link
Upgrade phpIPAM to 1.8.2. The release was published on August 16 and bundles this fix with a batch of other security corrections, per the project's release notes, so there is more than one reason to take it.
Then do the step the patch does not do for you: revoke or expire every temporary share link currently issued. The patch fixes new behavior, but a link that leaked before you upgraded is only neutralized when the token itself is gone. After that, hunt the access logs as above for sequential-ID reads against the share endpoints, and if you find them, rotate the credentials and configuration that sat in the exposed records. Patch, revoke, hunt, rotate, in that order.