Netbox Community
Monthly
Arbitrary code execution in the CI pipeline of the NetBox devicetype-library repository lets an unauthenticated contributor run attacker-controlled Python on GitHub Actions runners by submitting a pull request that adds a shadowing module (for example tests/git.py to hijack the harness's 'from git import ...') or a tests/conftest.py that pytest auto-imports during collection. The flaw exists because the repository lacks tests/__init__.py and invokes pytest without --import-mode=importlib, so pytest's default prepend import mode places tests/ and the repository root at the front of sys.path, causing PR-supplied files to take precedence over installed packages such as GitPython. Per the assessed vector (AV:N/AC:L/PR:N/UI:R), exploitation is unauthenticated but gated by user interaction: PR-supplied code only executes when a maintainer approves or runs the fork-PR workflow, and by default fork-PR workflows receive a read-only GITHUB_TOKEN with no repository secrets, so token or secret theft is fully realized only where that approval gate is disabled, on workflows with write tokens, or when a maintainer runs the harness locally; no public exploit code was identified at time of analysis, and this is a CI/supply-chain code-execution issue affecting the repository's build pipeline rather than any deployed NetBox instance.
Credential exposure in NetBox through 4.7.0 allows any authenticated user with only view-level permissions to retrieve plaintext Git passwords and Amazon S3 secret access keys via the REST API and GraphQL interfaces. The flaw is rooted in missing field-level redaction in the API serializer and GraphQL type layer, and represents an incomplete remediation of a previously reported issue (GitHub issue #12625). A public proof-of-concept is available, and successful exploitation grants attackers direct access to external Git repositories and S3 storage buckets configured as NetBox data source backends - extending the breach well beyond the NetBox instance itself.
Remote code execution in NetBox 4.3.5-4.5.4 allows authenticated users with exporttemplate or configtemplate permissions to execute arbitrary Python code as the NetBox service user by injecting malicious callables into Jinja2 template environment parameters. Attackers bypass SandboxedEnvironment protections by setting the finalize parameter to dangerous imports like subprocess.getoutput, which executes on every rendered expression outside sandbox call interception. Public proof-of-concept exploit exists (chocapikk.com), and upstream patch available via GitHub PR #22078 implements an allowlist-based validation mechanism that blocks unauthorized callable resolution at both save-time and render-time.
Authorization bypass in NetBox (2.9.0 up to but not including 4.7.4) lets authenticated users who hold a bulk add-component permission such as dcim.add_interface or dcim.add_modulebay act on parent devices and virtual machines that their ObjectPermission constraints should hide from them. By submitting arbitrary primary keys in the 'pk' list, or '_all' together with a GET filter, the attacker can view out-of-scope device details and create components on those parents; the flaw is in BulkComponentCreateView, which failed to apply the 'view' permission restriction to the parent queryset. Impact is limited to confidentiality and integrity at low severity (CVSS 5.3 / assessed CVSS:3.1 5.3, PR:L, no availability impact), it requires a valid account and the add-component permission, and it matters chiefly in multi-tenant or role-separated deployments using constrained ObjectPermissions; no public exploit code was identified at time of analysis and the issue is not in CISA KEV, with a vendor fix released in 4.7.4.
Session cookie and API token theft in NetBox versions 2.9.5 through 4.6.x lets an authenticated user holding the "Can add custom links" permission exfiltrate the credentials of higher-privileged users who merely view an affected object. The flaw exposes the raw Django HttpRequest object to the Jinja2 custom-link template context, so an attacker can embed request.COOKIES['sessionid'] or a victim's API token inside an <img src> URL that slips past the clean_html sanitizer and auto-transmits to an attacker-controlled host when a privileged user opens the page, enabling full account takeover. Exploitation is conditional: it requires a delegated custom-link permission (PR:L) and a privileged victim to passively trigger the payload (UI:P), and no public exploit has been identified at time of analysis; upgrading to NetBox 4.7.0, which substitutes a sanitized request subset, removes the exposure entirely.
Untrusted code execution in the NetBox devicetype-library CI pipeline lets any contributor who can open a pull request run arbitrary commands on the repository's GitHub Actions runner before a maintainer ever reviews the change. Because validation.yml triggers on the pull_request event and consumes three PR-editable files (requirements.txt for pip install, the pre-commit hook configs, and .gitmodules for submodule checkout), an unauthenticated remote attacker with no repository write access can inject code that executes automatically with no user interaction; impact is capped at low confidentiality and integrity loss because fork PRs run with a read-only token and no secrets. Only versions prior to commit f41fc1e are affected, and no public exploit code identified at time of analysis.
Pull-request authors against the community NetBox Device Type Library repository can repoint that repository's own pytest validation harness at an attacker-chosen Git host or substitute forged tests/known-*.json validation caches, allowing CI runs to bypass slug, module, and rack uniqueness checks that the library is supposed to enforce. The exposed constant NETBOX_DT_LIBRARY_URL in tests/test_configuration.py is consumed unvalidated by tests/definitions_test.py during pytest collection through GitPython's Repo.clone_from and create_remote("upstream").fetch(), yielding blind outbound Git smart-HTTP requests to an attacker-selected host with no ability to set arbitrary metadata-service headers or read response bodies, and no remote Git hook execution. The CVSS vector is AV:N/PR:N (unauthenticated from a network perspective), but the assessed impact is confined to CI integrity on repository revisions before fix commit 8980c690097e92f5028c7e6df402b327d827ecd5 - no deployed NetBox instance is affected, no public exploit identified at time of analysis, and GitHub Actions' usual maintainer-approval gate for fork pull_request workflows further limits practical abuse, making this a genuinely low real-world risk issue.
Cross-user disclosure in NetBox through 4.7.0 exposes all users' private Notifications, Subscriptions, and Bookmark records to any authenticated user with standard view permissions, via unscoped querysets in both the REST API and GraphQL API. The root cause is CWE-639 (Authorization Bypass Through User-Controlled Key): affected endpoints return the full table rather than filtering records to the requesting user's identity. A publicly available proof-of-concept exists demonstrating exploitation against a default 4.7.0 installation; no active exploitation has been confirmed in CISA KEV.
Arbitrary code execution in the CI pipeline of the NetBox devicetype-library repository lets an unauthenticated contributor run attacker-controlled Python on GitHub Actions runners by submitting a pull request that adds a shadowing module (for example tests/git.py to hijack the harness's 'from git import ...') or a tests/conftest.py that pytest auto-imports during collection. The flaw exists because the repository lacks tests/__init__.py and invokes pytest without --import-mode=importlib, so pytest's default prepend import mode places tests/ and the repository root at the front of sys.path, causing PR-supplied files to take precedence over installed packages such as GitPython. Per the assessed vector (AV:N/AC:L/PR:N/UI:R), exploitation is unauthenticated but gated by user interaction: PR-supplied code only executes when a maintainer approves or runs the fork-PR workflow, and by default fork-PR workflows receive a read-only GITHUB_TOKEN with no repository secrets, so token or secret theft is fully realized only where that approval gate is disabled, on workflows with write tokens, or when a maintainer runs the harness locally; no public exploit code was identified at time of analysis, and this is a CI/supply-chain code-execution issue affecting the repository's build pipeline rather than any deployed NetBox instance.
Credential exposure in NetBox through 4.7.0 allows any authenticated user with only view-level permissions to retrieve plaintext Git passwords and Amazon S3 secret access keys via the REST API and GraphQL interfaces. The flaw is rooted in missing field-level redaction in the API serializer and GraphQL type layer, and represents an incomplete remediation of a previously reported issue (GitHub issue #12625). A public proof-of-concept is available, and successful exploitation grants attackers direct access to external Git repositories and S3 storage buckets configured as NetBox data source backends - extending the breach well beyond the NetBox instance itself.
Remote code execution in NetBox 4.3.5-4.5.4 allows authenticated users with exporttemplate or configtemplate permissions to execute arbitrary Python code as the NetBox service user by injecting malicious callables into Jinja2 template environment parameters. Attackers bypass SandboxedEnvironment protections by setting the finalize parameter to dangerous imports like subprocess.getoutput, which executes on every rendered expression outside sandbox call interception. Public proof-of-concept exploit exists (chocapikk.com), and upstream patch available via GitHub PR #22078 implements an allowlist-based validation mechanism that blocks unauthorized callable resolution at both save-time and render-time.
Authorization bypass in NetBox (2.9.0 up to but not including 4.7.4) lets authenticated users who hold a bulk add-component permission such as dcim.add_interface or dcim.add_modulebay act on parent devices and virtual machines that their ObjectPermission constraints should hide from them. By submitting arbitrary primary keys in the 'pk' list, or '_all' together with a GET filter, the attacker can view out-of-scope device details and create components on those parents; the flaw is in BulkComponentCreateView, which failed to apply the 'view' permission restriction to the parent queryset. Impact is limited to confidentiality and integrity at low severity (CVSS 5.3 / assessed CVSS:3.1 5.3, PR:L, no availability impact), it requires a valid account and the add-component permission, and it matters chiefly in multi-tenant or role-separated deployments using constrained ObjectPermissions; no public exploit code was identified at time of analysis and the issue is not in CISA KEV, with a vendor fix released in 4.7.4.
Session cookie and API token theft in NetBox versions 2.9.5 through 4.6.x lets an authenticated user holding the "Can add custom links" permission exfiltrate the credentials of higher-privileged users who merely view an affected object. The flaw exposes the raw Django HttpRequest object to the Jinja2 custom-link template context, so an attacker can embed request.COOKIES['sessionid'] or a victim's API token inside an <img src> URL that slips past the clean_html sanitizer and auto-transmits to an attacker-controlled host when a privileged user opens the page, enabling full account takeover. Exploitation is conditional: it requires a delegated custom-link permission (PR:L) and a privileged victim to passively trigger the payload (UI:P), and no public exploit has been identified at time of analysis; upgrading to NetBox 4.7.0, which substitutes a sanitized request subset, removes the exposure entirely.
Untrusted code execution in the NetBox devicetype-library CI pipeline lets any contributor who can open a pull request run arbitrary commands on the repository's GitHub Actions runner before a maintainer ever reviews the change. Because validation.yml triggers on the pull_request event and consumes three PR-editable files (requirements.txt for pip install, the pre-commit hook configs, and .gitmodules for submodule checkout), an unauthenticated remote attacker with no repository write access can inject code that executes automatically with no user interaction; impact is capped at low confidentiality and integrity loss because fork PRs run with a read-only token and no secrets. Only versions prior to commit f41fc1e are affected, and no public exploit code identified at time of analysis.
Pull-request authors against the community NetBox Device Type Library repository can repoint that repository's own pytest validation harness at an attacker-chosen Git host or substitute forged tests/known-*.json validation caches, allowing CI runs to bypass slug, module, and rack uniqueness checks that the library is supposed to enforce. The exposed constant NETBOX_DT_LIBRARY_URL in tests/test_configuration.py is consumed unvalidated by tests/definitions_test.py during pytest collection through GitPython's Repo.clone_from and create_remote("upstream").fetch(), yielding blind outbound Git smart-HTTP requests to an attacker-selected host with no ability to set arbitrary metadata-service headers or read response bodies, and no remote Git hook execution. The CVSS vector is AV:N/PR:N (unauthenticated from a network perspective), but the assessed impact is confined to CI integrity on repository revisions before fix commit 8980c690097e92f5028c7e6df402b327d827ecd5 - no deployed NetBox instance is affected, no public exploit identified at time of analysis, and GitHub Actions' usual maintainer-approval gate for fork pull_request workflows further limits practical abuse, making this a genuinely low real-world risk issue.
Cross-user disclosure in NetBox through 4.7.0 exposes all users' private Notifications, Subscriptions, and Bookmark records to any authenticated user with standard view permissions, via unscoped querysets in both the REST API and GraphQL API. The root cause is CWE-639 (Authorization Bypass Through User-Controlled Key): affected endpoints return the full table rather than filtering records to the requesting user's identity. A publicly available proof-of-concept exists demonstrating exploitation against a default 4.7.0 installation; no active exploitation has been confirmed in CISA KEV.