WordPress.org seizes ACF plugin and redirects auto-updates to its SCF fork

What happened

WordPress.org has unilaterally taken control of the distribution of the Advanced Custom Fields (ACF) plugin and used the platform's automatic update system to steer existing users onto a fork called Secure Custom Fields (SCF), according to a report on dev.to. The fork is managed directly by WordPress.org rather than by ACF's original developers.

For site owners, the change did not arrive as an explicit choice: the standard update channel redirected installations to different software carrying the new name. Anyone accepting repository updates would end up running code they never deliberately selected.

The stated justification

According to the dev.to write-up, WordPress founder Matt Mullenweg defended the takeover as a security measure. The reasoning given was that WP Engine had lost access to WordPress.org infrastructure, and that users needed a safe, centrally maintained alternative. The move sits inside the broader and still-escalating trademark dispute between Automattic and WP Engine.

A trust problem for the repository

The decision has ignited debate over whether WordPress.org can still act as a neutral steward of its plugin directory, the dev.to report notes. Many developers see the action as an unauthorised intervention in a third party's intellectual property — a break with the norms of consent and collaboration that open source relies on.

The concern is not abstract. Plugin authors, agencies and integrators build long-term systems on the assumption that the repository distributes what a plugin's maintainers publish. If the operator of the central directory can substitute code at will, that assumption no longer holds.

Supply chain risk

The dev.to piece frames the incident as a dangerous precedent for software supply chains. When a central repository can unilaterally replace distributed code, the stability of every plugin update becomes conditional on the repository operator's decisions rather than on the plugin's own release process.

There are immediate practical risks as well. Because SCF was produced without the involvement of ACF's original developers, users may encounter missing features, behavioural differences or bugs that the original project had already engineered away. For sites that depend on ACF for API security and system integrations, an unplanned swap is not a routine update — it is a compatibility event that needs testing before it lands in production.

What site owners can do

The report offers concrete mitigation for anyone who needs to keep running the original ACF. Install and update the plugin manually instead of through the WordPress repository, avoid automatic updates for it, and follow the original developer's official channels for releases whose integrity can be verified.

The trade-off is real. Manual distribution means slower security patches and more operational overhead, which is exactly why the redirected auto-update channel mattered so much in the first place. Teams that pin the original plugin should also budget time to review what SCF does and does not change, in case future infrastructure decisions force a migration.

Why it matters

WordPress powers an enormous share of the web, and its plugin repository is one of the largest software distribution channels in existence. This incident shows that the channel is not neutral infrastructure: it can be redirected in the middle of a corporate dispute. For developers, the lesson is that depending on any single upstream distributor carries governance risk, not just technical risk, and that update pipelines deserve the same scrutiny as code itself. For the WordPress ecosystem, the cost is harder to repair — trust in the directory, once spent, is difficult to rebuild, and the demonstration that a live plugin can be reassigned and redirected mid-flight will shape how agencies, enterprises and plugin authors treat WordPress.org as a distribution channel going forward.