MITRE’s description of CWE-829: The product imports, requires, or includes executable functionality (such as a library) from a source that is outside of the intended control sphere.
Common consequences MITRE lists
- Confidentiality, Integrity, Availability: Execute Unauthorized Code or Commands
Included code runs with your privileges, so whoever controls its source controls your users’ sessions, your build secrets or your releases.
- Run untrusted code, such as pull requests from forks, without secrets or write permissions, and keep it apart from release jobs.
- Pin third-party scripts, actions and plugins to immutable versions or digests, and check integrity, for example with Subresource Integrity.
- Load third-party functionality only from sources you have reviewed and can monitor.
Guides on this site
Keep untrusted CI work outside the release boundary
Review workflow authority, persistent state and artifact handoffs before contributor-controlled code reaches privileged jobs.
Protect the path from pull request to release
Separate untrusted contribution checks from privileged release work and verify the identity of the artifact that is actually deployed.
Constrain MCP and multi-agent trust boundaries
Validate each connection and delegated action without treating a token for another service, a tool description, another agent or a state handle as authority.
Harden GitHub Actions against workflow and supply-chain attacks
Close the paths that give untrusted pull-request code secrets or a write token: pass context through env, keep pull_request_target away from fork code, pin actions to commit SHAs, scope GITHUB_TOKEN and OIDC, and treat artifacts as data.
Stop dependency confusion and typosquatting at install time
Pin every internal package name to its real source, verify installed bytes against a lockfile, and delay or gate install scripts so a public look-alike cannot replace a private dependency.
Case study: the tj-actions/changed-files compromise (CVE-2025-30066)
In March 2025 an attacker moved the version tags of a popular GitHub Action, and of a reviewdog action before it, to code that printed CI secrets into build logs. This case study traces the token chain back to one pull_request_target workflow, sizes the exposure, and shows how it was caught and which controls held.
Case study: the Shai-Hulud npm worm (2025-2026)
How a self-replicating npm worm turned stolen tokens into hundreds of infected packages in 2025, how its 2026 successors hijacked release pipelines and trusted publishing, what npm and GitHub changed in response, and the publishing, install and response practices that stop it.
Secure AI-assisted development with coding assistants and agents
Treat generated code, suggested packages, repository text and MCP servers as untrusted inputs, and confine coding agents with OS-level isolation and short-lived, narrowly scoped credentials.
Treat model releases as executable supply-chain inputs
Verify provenance, constrain loading and preserve the relationship between model weights, configuration and runtime dependencies.
Case study: event-stream and ua-parser-js, two npm package takeovers
Two ways attackers took over popular npm packages: event-stream (2018), handed to a stranger who added a targeted, encrypted payload through a new dependency, and ua-parser-js (2021), whose maintainer's account was hijacked to publish versions that installed malware for four hours. Timelines, detection and the controls that stop both.
Case study: the polyfill.io CDN takeover (2024)
How the sale of the polyfill.io domain and project in February 2024 turned a script tag on more than 100,000 websites into a channel for malicious redirects by June, why Subresource Integrity could not have protected it, and the controls that would have.
Secure the developer workstation: extensions, package managers, secrets and AI agents
Attackers reach the software supply chain through developers' editors, package installs and AI agents. Allow-list extensions, stop install scripts and brand-new versions, keep long-lived secrets off laptops, and lock down repository files that run code when a project opens.
Map PCI DSS Requirement 6 to engineering practice and evidence
Turn PCI DSS v4.0.1 Requirement 6 into engineering work: secure development, review, patching, web-attack protection, payment-page script control and change management, with the records an assessor samples and the parts that became mandatory on 31 March 2025.
Threat pattern library for threat modeling
Thirty-two recurring threat patterns grouped by identity, authorization, parsers, concurrency, integrations, data exposure, supply chain, availability and AI agents, each with where it shows up on a data-flow diagram, mitigations, a verification step and STRIDE, CWE and CAPEC links, plus a YAML catalog and a script that lists patterns per diagram element.
Prevent file inclusion: LFI, RFI, dynamic imports and template names
Stop request data from choosing which file, module or template your application loads: local and remote file inclusion in PHP, dynamic require() and import() in Node.js, importlib and template names in Python, Thymeleaf view names in Spring, render in Rails, and the allowlist fix that works in all of them.
Case study: the Nx s1ngularity compromise and its AI-assisted payload (2025)
How a pull-request-title injection in a GitHub Actions workflow on an outdated branch gave an attacker the Nx npm token in August 2025, how the malicious versions tried to turn developers' own AI command-line tools into file-search agents, and the workflow, publishing and agent controls that stop the same chain.
Practice
- Actions injection lab: Flag GitHub Actions expression injection · Browser lab
- File upload lab: Accept avatars without publishing pages · Browser lab
- Build and verify a signed software release · Local project
- Enforce retrieval and tool boundaries across crashes · Local project
- Repair a security pipeline for GitHub Actions and GitLab CI · Local project
- Run model-generated Python in a locked-down container · Local project
References
List data from MITRE; the name, definition and consequences are from MITRE’s CWE 4.20 catalogue. A guide is listed as the main subject when the weakness is what the guide is about, and as covering it when a dedicated section or worked example addresses it.
CWE content: Copyright © 2006–2026, The MITRE Corporation. CWE, CWSS, CWRAF, and the CWE logo are trademarks of The MITRE Corporation. CWE™ is free to use by any organization or individual for any research, development, and/or commercial purposes, per these CWE Terms of Use. Accordingly, The MITRE Corporation hereby grants you a non-exclusive, royalty-free license to use CWE for research, development, and commercial purposes. Any copy you make for such purposes is authorized on the condition that you reproduce MITRE’s copyright designation and this license in any such copy. CWE is a trademark of The MITRE Corporation. CWE Terms of Use.