WP Packages and WP Sec Adv: The Future of WordPress Dependencies in Composer

Emnes April 17, 2026

Illustration of WP Packages and WP Sec Adv working with composer audit

In spring 2026, the Roots.io team launched two projects that reshape how WordPress dependencies are managed at the Composer layer: WP Packages and WP Sec Adv. Both are small in scope and massive in consequence. WP Packages replaces WPackagist as the default Composer repository for WordPress.org plugins and themes, with better reliability, public infrastructure, and dev-trunk revision pinning. WP Sec Adv wires WordPress-specific security advisories directly into composer audit, closing a years-old gap where WordPress plugin vulnerabilities were invisible to Composer’s standard security tooling.

If you’re running any Bedrock-based WordPress site, both are worth adopting. This guide walks through what each one is, why they exist, how to migrate, and what they change about how teams manage WordPress dependencies in 2026.

The Problem: Composer’s WordPress Blind Spot

WordPress has had a Composer story for over a decade. WPackagist, launched in 2013 by Outlandish, mirrors the WordPress.org plugin and theme directory and exposes every plugin as a wpackagist-plugin/* Composer package. Bedrock projects have defaulted to it since day one. It works.

But WPackagist has structural weaknesses that became more visible as Roots-based projects grew in scale:

Single maintainer dependency. WPackagist is community-run but effectively maintained by a small team. When the service had reliability issues (slow responses, stale package indexes), there was no escalation path.
No public status page. When installs failed, you had to guess whether it was your network, your config, or WPackagist itself.
Dev-trunk packages are volatile. Installing a plugin at dev-trunk gets you whatever the plugin’s SVN trunk looks like at install time. Two composer install runs three hours apart could give you different code without any version change logged anywhere.
No advisory integration. WPackagist serves packages; security is somebody else’s problem.
Closed-source infrastructure. If you wanted to run your own mirror or contribute improvements, there was no codebase to fork.

And on the security side, composer audit — Composer’s built-in vulnerability scanner — only understood PHP packages. A Composer-managed WordPress site with 30 plugins and themes was running composer audit against its handful of PHP dependencies, while the 30 plugins (which is where Patchstack attributes 96% of WordPress vulnerabilities) were completely invisible to the tool.

WP Packages and WP Sec Adv are the Roots team’s answer to both of these problems.

WP Packages: A New Composer Repository for WordPress

WP Packages launched March 16, 2026. It was briefly called “WP Composer” — renamed on March 19 after Nils Adermann (Composer’s co-creator) pointed out the name implied it was a fork of Composer itself, which it isn’t.

Technically, WP Packages is a Composer v2 repository at https://repo.wp-packages.org that mirrors the WordPress.org plugin and theme directory. It uses the same namespace conventions as WPackagist, so migration is a one-line change: replace the WPackagist URL in your composer.json with the WP Packages URL, and the same wp-plugin/* and wp-theme/* package names (almost) still work.

What’s Different About WP Packages

Open-source. The entire codebase is at github.com/roots/wp-packages. Fork it, run your own mirror, contribute.
Public status page launched April 2, 2026. You can see exactly when the service is degraded.
SVN revision pinning for dev-trunk (March 26, 2026). Instead of dev-trunk being a moving target, you can pin to a specific SVN revision — dev-trunk#r3088472 — and get reproducible installs even for pre-release plugins.
GitHub Action that injects changelogs and stable-version warnings into pull requests when a plugin is updated. No more merging a PR that bumps a plugin without knowing what changed.
Faster package index updates — the plugin directory refreshes multiple times per hour, so a newly-released plugin is available quickly.
Namespace conventions match WPackagist. wp-plugin/* and wp-theme/* are the naming standards both repositories use (WPackagist uses wpackagist-plugin/*; WP Packages drops the wpackagist- prefix).

Migrating from WPackagist to WP Packages

The migration is mechanical. In your composer.json, find:

"repositories": [
{ "type": "composer", "url": "https://wpackagist.org", "only": ["wpackagist-plugin/*", "wpackagist-theme/*"] }
]

Replace with:

"repositories": [
{ "type": "composer", "url": "https://repo.wp-packages.org", "only": ["wp-plugin/*", "wp-theme/*"] }
]

Then rename every wpackagist-plugin/* in require to wp-plugin/*, and wpackagist-theme/* to wp-theme/*. Run composer update, verify your lockfile shows the new names, and commit.

For new Bedrock projects (1.30+), WP Packages is already the default — no migration needed.

Should You Migrate?

Not urgently, but yes eventually. WPackagist is still maintained and still works. The WP Packages improvements — revision pinning, status page, open-source — are real but not critical for most sites. Migrate when you have a free afternoon, not as a high-priority task.

For teams running many sites, the revision pinning is the most compelling feature. If you’ve ever had a composer install produce different behavior than an identical install three days earlier because of silent dev-trunk drift, you’ll appreciate the deterministic pinning.

WP Sec Adv: Composer-Native Security for WordPress Dependencies

WP Sec Adv launched April 1, 2026. It’s a Composer repository that contains security advisories for WordPress plugins, themes, and core, sourced from Wordfence Intelligence and updated twice daily. The repository is configured in your composer.json alongside WP Packages, and it plugs into Composer’s standard security workflow — no custom tooling required.

The result: composer audit — which previously only caught vulnerabilities in PHP packages like Symfony, Guzzle, or Laravel — now also flags vulnerable WordPress plugins and themes installed in your project. composer require also refuses to install a known-vulnerable plugin version by default (you can override, but the friction is intentional).

Why This Matters

WordPress plugins are the single most exploited attack surface on the platform. Patchstack’s 2025 annual report attributed 96% of WordPress vulnerabilities to plugins. Wordfence blocked over 90 billion malicious login attempts in 2024 alone, many of them targeting specific plugin vulnerabilities.

Until WP Sec Adv, the standard workflow for keeping plugins secure was:

Subscribe to a security-news feed (Wordfence, Patchstack, Sucuri).
Notice an advisory in your inbox.
Check whether the plugin is on any of your sites.
Run composer update on each affected site.
Deploy.

That workflow works, but it’s fragile. It depends on the person subscribed to the feed being available and on the mental bookkeeping of which sites run which plugins. WP Sec Adv replaces that chain with a composer audit command run in CI on every build, which automatically fails the pipeline when a vulnerable plugin is installed.

Installing WP Sec Adv

Add the repository to composer.json:

"repositories": [
{ "type": "composer", "url": "https://repo.wp-sec-adv.org" }
]

Run composer update once to hydrate the advisory cache, then run:

composer audit

Any known vulnerabilities in your installed plugins, themes, or WordPress core will surface as advisories with severity, CVE IDs, and remediation guidance.

Features

Twice-daily updates from Wordfence Intelligence.
Custom mirrors supported — organizations that want to self-host the advisory feed can do so.
Explicit suppressions — you can suppress a specific advisory, but you must document why. The suppression and its reason are stored in your lockfile, so the whole team sees the context.
Works with both WP Packages and WPackagist. You don’t have to migrate to WP Packages to use WP Sec Adv.
Replaces roave/security-advisories — the older PHP-packages-only advisory tool that Bedrock used to ship with (removed in Bedrock 1.28.4).

Wiring It Into CI

The real power of WP Sec Adv is running it on every build. Add to your CI pipeline:

composer install --no-dev --optimize-autoloader
composer audit

Configure composer audit to exit with a non-zero status on any advisory above a severity threshold (--severity=medium is a reasonable default). Your pipeline fails, PRs can’t be merged, and vulnerable plugins never reach production.

For teams running Renovate or Dependabot, WP Sec Adv improves those tools too — a PR that bumps a plugin to a vulnerable version is caught immediately, not after it’s deployed.

How the Two Projects Interact

WP Packages is where you get plugins. WP Sec Adv tells you when those plugins have known vulnerabilities. They’re complementary, not overlapping.

A modern Bedrock composer.json uses both:

"repositories": [
{ "type": "composer", "url": "https://repo.wp-packages.org" },
{ "type": "composer", "url": "https://repo.wp-sec-adv.org" }
]

WP Packages provides the plugin and theme packages. WP Sec Adv provides the advisory data that Composer uses to evaluate their security. Neither requires the other — you can use WP Sec Adv with WPackagist, or WP Packages with a different advisory feed — but using both together gives you the strongest setup.

Roadmap and Longevity

Both projects are community-funded via GitHub Sponsors. Their sustainability depends on:

Infrastructure costs — keeping the repositories online and fast.
Advisory licensing — Wordfence Intelligence is commercial data, and the Roots team maintains a licensing agreement to redistribute it.
Community adoption — the more sites use both, the stronger the ecosystem’s bargaining position for licensing and the more sponsor revenue is available for maintenance.

For agencies and teams running many sites, sponsoring Roots at even the $10/month tier is a reasonable way to underwrite infrastructure you now depend on.

Frequently Asked Questions

Do I have to migrate from WPackagist to WP Packages?

No. WPackagist continues to work. Migrate when convenient for the revision pinning and reliability improvements, not as an emergency.

Can I use WP Sec Adv without Bedrock?

Yes. WP Sec Adv is a standalone Composer repository. Any Composer-managed WordPress project (Bedrock or not) can add it.

What does `composer audit` report for vulnerable plugins?

A standard Composer advisory format: CVE ID (if assigned), severity (low/medium/high/critical), affected version range, fixed version, advisory title, and a link to the full Wordfence advisory. Clear enough to act on without needing to cross-reference other tools.

What if I need to keep a vulnerable plugin temporarily?

Suppress the advisory explicitly with a reason:

composer audit --ignore=CVE-2026-XXXX --reason="Vendor fix expected March 30, tracked in JIRA-1234"

The suppression is recorded in your lockfile so the team sees the context. Don’t make this the default — suppressions should be rare, documented, and time-boxed.

Does WP Sec Adv cover premium plugins?

Only if Wordfence tracks them. Most widely-used premium plugins (ACF Pro, Gravity Forms, WooCommerce extensions) are in the feed. Obscure or niche plugins may not be.

How fast does an advisory reach my `composer audit`?

The feed updates twice daily, so worst case about 12 hours between Wordfence publishing an advisory and composer audit flagging it. For most advisories, that’s fast enough; for actively-exploited zero days, you’ll want additional monitoring (Wordfence’s own alerts, Patchstack, security mailing lists).

Adopt Both, Benefit Forever

WP Packages and WP Sec Adv are two of the most impactful additions to the Composer-managed WordPress workflow in years. Neither requires rewriting anything. Both take a few minutes to configure. The returns — more reliable package infrastructure, automated security scanning across every plugin and theme — compound across every deploy, forever.

At Emnes, we’ve migrated to WP Packages on all new Bedrock projects and have WP Sec Adv running in CI across every site. The security-advisory visibility alone has already caught two vulnerabilities we would otherwise have deployed unknowingly.