GitHub launched Package Firewall in public preview on October 20, 2026 — a network-layer inspection proxy that blocks malicious npm packages before they reach your CI/CD runners. The timing is not coincidental: one day earlier, the GhostAction campaign had compromised 1,900 GitHub accounts and swept malicious workflows through 30,000+ repositories, extracting 2,577 secrets including AWS keys, AI API credentials, and package-registry publishing tokens. This is GitHub’s direct answer to an attack class that executes at install time, before your application code ever runs.
What the Package Firewall Actually Does #
The firewall sits between GitHub Actions runners — and increasingly, AI coding agents — and the upstream npm registry, intercepting both metadata requests and package downloads. Administrators configure four policy controls at the enterprise level. The Advisory Database check blocks packages flagged for malware or CVEs in GitHub’s own advisory database. The attestation enforcement rejects packages that previously carried OIDC build provenance but no longer do — a sign that the publisher may have changed hands or switched to an unauthorized build environment.
The two most practically useful controls are the install script detection and the cooldown period. Install scripts — postinstall, preinstall, and relatives — are the primary execution vector for install-time credential theft. Packages that newly introduce these scripts get flagged. The cooldown period (configurable from 1 to 365 days) blocks newly published versions for a set window, giving the npm security team time to review and yank malicious releases before they spread. For most teams, setting cooldown to 7-14 days and relying on the Advisory Database for everything else covers the majority of real-world supply chain attack scenarios.
Blocked packages are not silently dropped — they surface through a GitHub Advanced Security exception workflow. Teams can request unblocks, and administrators review and approve. Expect some operational overhead in the first weeks as teams calibrate cooldown periods against their actual release cadence.
The GhostAction Connection: Why npm Supply Chain Defense Matters This Week #
GhostAction’s October 2026 wave is the reason this feature announcement hits differently than a typical enterprise security preview. The attackers compromised maintainer accounts through leaked Personal Access Tokens, then pushed security-audit.yml workflow files directly to default branches — no pull request, no review. These workflows did not just scan for currently configured secrets. They ran git log with full history depth, harvesting credentials committed and deleted years ago. AWS keys, OpenAI API tokens, PyPI publishing credentials — all fair game.
StepSecurity, the firm that analyzed the attack, noted something worth sitting with: the one control that actually stopped exfiltration in the field was requiring workflow run approval — a free feature available to every GitHub plan. The Package Firewall addresses a different layer of the same problem, but the cheap mitigation was already effective. Enable workflow run approval for external contributors and forks. It works.
Related: GhostAction Hits 30,000 GitHub Repos: Rotate Your Secrets Now
The Catch: Enterprise Cloud Only, npm Only #
Package Firewall is available exclusively to GitHub Enterprise Cloud customers — GitHub Free, Teams, and Enterprise Server are excluded. It currently covers npm only; PyPI, Maven, RubyGems, and other registries remain outside its scope. During the public preview it is free; GitHub plans to move to metered usage billing after general availability, similar to Actions pricing. The tension here is hard to ignore. GhostAction’s October wave targeted open source projects specifically — a popular game engine with 18,400 GitHub stars, a widely-used database driver, and hundreds of others. These projects live on GitHub Free. They were attacked. They cannot use the new tool. GitHub’s investment in supply chain defense is welcome, but its current scope prioritizes the customers who already have the most security resources.
What Free-Plan Teams Can Use Right Now #
If you are not on Enterprise Cloud, the options are real but require deliberate setup. [StepSecurity Harden-Runner](https://thehackernews.com/2026/10/ghostaction-compromises-about-1900.html) monitors and restricts outbound network calls from Actions runners — it would have caught GhostAction’s exfiltration to its command-and-control IP. Socket.dev runs as a free GitHub App, adding malware heuristics and typosquatting detection to npm installs. Neither blocks packages at the network layer the way the Firewall does, but both provide meaningful coverage. Combine with branch protection on .github/workflows/ to prevent direct-push workflow injection — the exact vector GhostAction used.
**Related:** [GitHub Actions Workflow Lockfiles: Stop the Next Supply Chain Hit](https://byteiota.com/github-actions-workflow-lockfiles-stop-the-next-supply-chain-hit/)
Key Takeaways #
- GitHub Package Firewall (public preview, October 20, 2026) blocks malicious npm packages before installation via cooldown periods, Advisory Database checks, attestation enforcement, and install script detection
- The feature directly targets the attack class GhostAction used this week — credential theft at install time, before application code runs
- It requires GitHub Enterprise Cloud; npm only; free now, metered billing after GA
- Free mitigation that already works: enable workflow run approval for forks and external contributors — StepSecurity confirmed this stopped GhostAction exfiltration in the field
- For non-enterprise teams: StepSecurity Harden-Runner, Socket.dev, and branch protection on .github/workflows/ provide meaningful defense in depth