phpIPAM EUVD-2026-96994

Requires a valid authenticated phpIPAM account with low privileges (CVSS PR:L) - there is no unauthenticated path. Given such an account, exploitation works against default code in phpIPAM through 1.8.3: the customers (objects.php/ipaddresses.php), single-location.php, and nat_details.php pages do not invoke Subnets::check_permission, so no special configuration or feature toggle is needed. Limiting factors: the attacker must already possess credentials; no user interaction is required; impact is strictly read-only disclosure of network inventory data (IPs, CIDRs, hostnames, MACs) and does not grant write access, code execution, or availability impact.

This is a genuine but moderate-severity issue, not a top-tier priority. The vendor-supplied CVSS 4.0 vector (AV:N/AC:L/AT:N/PR:L/UI:N/VC:L/VI:N/VA:N, 5.3 Medium) is internally consistent with the description: a network-reachable, low-complexity flaw that nonetheless requires an authenticated low-privilege account (PR:L) and yields only limited confidentiality impact (VC:L) with no integrity or availability effect. The CWE-862 (Missing Authorization) classification aligns cleanly with the described behavior - specific tool pages skip Subnets::check_permission - so there is no conflict between the vector and the narrative. No EPSS score was provided in the input, so exploitation probability cannot be quantified. KEV status is not present in the input, so this is not confirmed as actively exploited. A detailed public write-up (hackmd) and exact vulnerable source-line references exist, lowering the barrier to exploitation even though no weaponized exploit tool is cited. Net real-world risk: a post-authentication horizontal information-disclosure bug that leaks network inventory data to users who already have some access - valuable for internal reconnaissance/privilege-boundary violations but gated behind authentication and limited to read-only data exposure, so it ranks below unauthenticated or code-execution flaws.

A low-privilege phpIPAM user (or an attacker who has phished/obtained such an account) who is only authorized for a subset of sections directly requests tools/customers objects.php, tools/locations/single-location.php, or tools/nat/nat_details.php. Because these pages omit the Subnets::check_permission call, the server returns IP addresses, CIDRs, hostnames, and MAC addresses from subnets and sections the user was never granted access to. A public technical write-up documents the exact pages and lines involved, making the technique trivial to reproduce even without packaged exploit code.