NetBox devicetype-library CVE-2026-54916

Exploitation requires that the repository's pytest harness run without tests/__init__.py and without --import-mode=importlib, so pytest's default 'prepend' import mode places the tests/ directory (and repo root) at the front of sys.path during collection - the exact pre-fix state. An attacker submits a pull request adding a top-level/tests-level module that shadows a real import (e.g. tests/git.py to hijack 'from git import ...' in definitions_test.py) or a tests/conftest.py that pytest auto-executes at collection time. The decisive LIMITING factor (UI:R) is that PR-supplied code only runs when a maintainer approves or runs the fork-PR workflow: GitHub's default 'require approval for fork PRs / first-time contributors' setting must be enabled, and by default fork-PR workflows receive only a read-only GITHUB_TOKEN with no repository secrets - so token/secret theft impact is fully realized only where that approval gate is disabled, on branches with write tokens, or when a maintainer runs the harness locally. It affects the CI build pipeline of the netbox-community/devicetype-library repository, not any deployed NetBox application.

This is a CI/supply-chain code-execution flaw, not a flaw in deployed NetBox instances. The vendor CVSS 3.1 vector (AV:N/AC:L/PR:N/UI:R/S:U/C:H/I:H/A:H = 8.8 HIGH) is defensible for the code path itself: an unauthenticated contributor submits a pull request over the network (AV:N), the module-shadowing trigger is trivial to craft (AC:L), no account/authorization is needed to open a PR (PR:N), and a maintainer merging/approving supplies the required interaction (UI:R). No EPSS, KEV, or public POC was provided, so exploitation status is: no public exploit identified at time of analysis - do not treat as actively exploited. The key real-world nuance the raw 8.8 hides: GitHub's default posture for pull_request workflows from forks/first-time contributors grants a read-only GITHUB_TOKEN, withholds secrets, and requires maintainer approval before any PR-supplied code runs. The fix's own comments name that approval setting as the PRIMARY control. Therefore full C:H/I:H/A:H (token theft, result tampering, lateral network access) is realistically achieved on the maintainer-runs-locally path, or where the repo has weakened the fork-approval gate - not against a hardened default CI. Bottom line: a genuinely serious repo-integrity/RCE issue for this project's CI, but its blast radius is one upstream repo's build pipeline, and default GitHub protections meaningfully gate it - treat as high priority for the project maintainers, low urgency for NetBox operators.

An attacker with no special privileges opens a pull request to netbox-community/devicetype-library that adds tests/git.py (shadowing GitPython, which tests/definitions_test.py imports via 'from git import Git, Repo') or a tests/conftest.py that runs automatically during pytest collection. When CI runs the test harness, Python imports the attacker's module before any test executes, achieving arbitrary code execution on the GitHub Actions runner to steal workflow tokens, tamper with test results, or reach network resources. No public exploit is identified, and exploitation requires a maintainer to approve/run the fork PR (UI:R), which is the main limiting factor.