NetBox devicetype-library EUVD-2026-82415

Requires the attacker to submit a pull request to the netbox-community/devicetype-library repository whose validation test harness (pytest over tests/definitions_test.py) then runs against the PR-controlled NETBOX_DT_LIBRARY_URL constant in tests/test_configuration.py, or against attacker-supplied tests/known-*.json caches. Exploitation is bounded to affected revisions before fix commit 8980c690 and is limited by: the request being blind (no arbitrary metadata-service headers, no readable response body), no remote Git hook execution, and - in practice - GitHub Actions typically requiring maintainer approval before fork pull_request workflows execute. Impact is confined to CI integrity (bypassing slug/module/rack uniqueness validation) and outbound blind probing from the runner; there is no impact on any deployed NetBox instance.

This is a genuinely low-real-world-risk issue despite a network-vector CVSS. The vendor CVSS 3.1 base of 5.3 (AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:L/A:N) reflects only an integrity-limited impact (I:L, C:N, A:N) - no code execution, no data disclosure, no availability loss. The 'network' vector is technically true only because the exploit primitive is an outbound Git smart-HTTP request from a CI runner, not because a production NetBox instance is remotely reachable; the affected artifact is a repository CI/test harness (devicetype-library), NOT a deployed NetBox service. No EPSS score, KEV listing, POC, or SSVC data was provided; per the input this is 'no public exploit identified at time of analysis.' The description itself narrows the primitive: the SSRF is blind (cannot set metadata-service headers, cannot return response bodies) and does not execute remote Git hooks, so it cannot be escalated to RCE or cloud-credential theft the way a full SSRF might. Real value is limited to (a) blind outbound probing from the runner and (b) substituting attacker-controlled known-*.json validation caches to bypass slug/module/rack uniqueness checks. Net: a legitimate CI supply-chain hardening fix, not an urgent production-facing priority. Note the CVSS AC:L is arguably optimistic - GitHub Actions fork pull_request workflows typically require maintainer approval before running, a real gating factor not reflected in the base vector.

An unauthenticated contributor opens a pull request against netbox-community/devicetype-library that edits the tracked NETBOX_DT_LIBRARY_URL constant in tests/test_configuration.py to point at an attacker-controlled host (or supplies crafted tests/known-*.json caches). When the validation harness runs under pytest, Repo.clone_from and create_remote('upstream').fetch() issue blind Git smart-HTTP requests to that host and/or load the substituted validation data, allowing the PR to slip past slug/module/rack uniqueness validation. No public exploit is identified; the request is blind (no response body, no arbitrary headers) and executes no remote Git hooks.