A supply chain technique that abuses package lifecycle scripts that run before installation completes. Because these scripts execute automatically, they can launch payloads, download secondary tooling, or collect secrets before defenders notice. The main risk is that dependency installation becomes an execution path, not just a file transfer.
Expanded Definition
Preinstall attack is a software supply chain abuse pattern where package lifecycle hooks execute before installation finishes, turning dependency retrieval into an execution step. In practice, the attacker relies on package managers that automatically run script logic during install, allowing code to launch processes, alter host state, or reach out for follow-on payloads before a reviewer or scanner has a chance to intervene. NHI Management Group treats this as an execution-path risk, not just a packaging issue, because the danger appears at the moment trust is granted to code that has not yet been validated in context.
The term overlaps with broader supply chain compromise, but it is narrower than generic malicious package tampering because the timing of execution is the key control failure. Guidance in sources such as the NIST SP 800-53 Rev 5 Security and Privacy Controls maps most closely to software integrity, execution control, and change management outcomes rather than a dedicated “preinstall” control. The most common misapplication is assuming package installation is passive file ingestion, which occurs when teams allow lifecycle scripts to run by default in CI/CD or on developer endpoints without review.
Examples and Use Cases
Implementing controls against preinstall attack rigorously often introduces friction in developer workflows, requiring organisations to weigh installation speed against script execution risk.
- A developer installs a dependency and its preinstall hook silently runs a shell command that profiles the host and exfiltrates environment variables.
- A CI job pulls a package and the installation script downloads a second-stage payload, creating a pathway that security tooling only sees after execution begins.
- An enterprise build pipeline allows unmanaged package-manager scripts, so a compromised dependency can modify local artifacts before signing or testing completes.
- A security team blocks install-time scripts in sensitive environments and allows them only after review, using allowlists and isolated build runners.
- A response team correlates package events with indicators in MITRE ATT&CK Enterprise Matrix and guidance from CISA cyber threat advisories to identify execution triggered by software delivery rather than by a traditional user action.
In AI-enabled environments, preinstall attack can also be a delivery route for tooling that prepares systems for later agent abuse, though that should be distinguished from model manipulation. Where package ecosystems intersect with automated agents, install-time execution deserves the same scrutiny as any other code path that can reach secrets, tokens, or cloud credentials.
Why It Matters for Security Teams
Preinstall attack matters because it collapses the boundary between acquisition and execution. Security teams that focus only on malware scanning or checksum validation can miss the real risk: trusted automation that runs attacker code with build, developer, or deployment privileges. That matters for secrets hygiene, because lifecycle scripts often inherit the same environment variables, mounted credentials, and network access that legitimate installers use.
The governance lesson is that package trust must include execution policy. Teams need to decide whether install-time scripts are permitted, where they are allowed, and what compensating controls exist when they are not. That decision becomes more important in environments using autonomous agents or AI-assisted workflows, where installation requests can be triggered programmatically and executed at machine speed. The relevance of this pattern is reinforced by broader supply chain and intrusion reporting, including Anthropic — first AI-orchestrated cyber espionage campaign report and the MITRE ATLAS adversarial AI threat matrix where automation amplifies the speed of post-compromise activity. Organisations typically encounter the true impact only after a package install triggers suspicious outbound traffic or secret exposure, at which point preinstall attack becomes operationally unavoidable to address.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP Non-Human Identity Top 10 address the attack and risk surface, while NIST CSF 2.0, NIST SP 800-53 Rev 5, NIST AI RMF and NIST AI 600-1 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST CSF 2.0 | PR.IP-1 | Addresses secure configuration and change control for software installs and scripts. |
| NIST SP 800-53 Rev 5 | CM-7 | Least functionality limits unnecessary script execution during installation. |
| OWASP Non-Human Identity Top 10 | Covers non-human identity exposure when install scripts access secrets or tokens. | |
| NIST AI RMF | AI RMF governance applies when automated agents trigger package installs. | |
| NIST AI 600-1 | GenAI supply chain risk includes malicious tooling introduced through installation paths. |
Treat install hooks as secret-access pathways and block credential exposure in build environments.