Description

NetBox Device Type Library is a collection of community-sourced device type definitions for import into NetBox. Prior to commit f41fc1e, the CI workflow .github/workflows/validation.yml runs on pull_request and executes code supplied by the pull request before any maintainer review. Three PR-editable files drive this: "requirements.txt", ".pre-commit-hooks-config.yaml" / ".pre-commit-yamlfmt-config.yaml", and ".gitmodules". A contributor with no special repository access could open a pull request that modifies these files and have their code run on the CI runner. This issue has been patched via commit f41fc1e.

Executive Summary

Technical Details

Mitigations

References

Additional Metadata

{
  "score": "6.5",
  "pubDate": "2026-10-01T20:17:25.957Z",
  "pubdate": "2026-10-01T20:17:25.957Z",
  "executiveSummary": "The NetBox Device Type Library is susceptible to an unauthenticated Remote Code Execution (RCE) vulnerability within its CI/CD pipeline.\nThe vulnerability stems from improper trust configuration in the GitHub Actions workflow, which executes user-supplied code from pull requests prior to maintainer review.\nAn unauthenticated attacker can exploit this by submitting a pull request that modifies configuration files, triggering the execution of arbitrary commands on the CI runner.\nThis vulnerability allows an attacker to compromise the runner environment, potentially exfiltrating sensitive CI secrets, modifying repository contents, or accessing connected internal services.\nThe issue affects the CI workflow defined in .github/workflows/validation.yml and is mitigated by commit f41fc1e.\nThe risk is critical, as it bypasses standard security gates by leveraging the automated build process to execute malicious payloads with the permissions granted to the GitHub Actions runner.",
  "technicalDetails": "The root cause of this vulnerability lies in the insecure configuration of the .github/workflows/validation.yml GitHub Actions workflow. The workflow is configured to execute automatically upon the 'pull_request' trigger, prior to any human review or approval from project maintainers.\nThe CI pipeline relies on three specific repository files—requirements.txt, .pre-commit-hooks-config.yaml / .pre-commit-yamlfmt-config.yaml, and .gitmodules—to define the runtime environment and tool configuration for the validation process.\nBecause the repository allows contributors without special access rights to submit pull requests, an attacker can modify these configuration files to include malicious directives. By injecting custom packages into requirements.txt, adding arbitrary execution hooks via the pre-commit configuration, or manipulating .gitmodules to include malicious submodules, the attacker forces the CI runner to execute code during the setup or execution phases of the pipeline.\nThe attack flow proceeds as follows: 1) The attacker clones the target repository. 2) The attacker crafts a pull request containing malicious code within one of the identified input-driven files (e.g., adding a malicious entry to requirements.txt). 3) Upon opening the pull request, the CI runner automatically initiates the 'validation.yml' workflow. 4) The runner installs the dependencies and executes the pre-commit hooks, which triggers the attacker's payload.\nThe execution occurs within the context of the GitHub Actions runner. Once the payload is triggered, the attacker gains the ability to execute arbitrary commands on the runner host. This leads to severe post-exploitation consequences, including the potential theft of repository secrets stored as environment variables, unauthorized modification of the codebase, or the usage of the runner as a pivot point to perform internal reconnaissance or network attacks against infrastructure accessible to the runner.\nThis vulnerability bypasses the intended security boundary of maintainer code review, as the malicious code is executed automatically before a maintainer is even alerted to the existence of the pull request. The vulnerability was resolved in commit f41fc1e, which likely restricts the execution context or introduces strict validation requirements for PR-submitted configuration changes."
}