It all started with a simple concern back in November 2014. WordPress developer Sergej Mueller raised what seemed like an obvious issue: users had absolutely no way of knowing if a plugin they relied on had been removed from the official repository—even when removed for serious security concerns. His ticket, officially labeled #30465, was initially closed with no resolution. Fast forward a decade, and here we are in early 2025, watching this long-dormant issue finally gaining the momentum it deserves.
A Ticket Born Ahead of Its Time
When Sergej first opened ticket #30465, the WordPress landscape looked quite different. Security wasn’t the front-and-center concern it is today. The ticket received minimal attention before being quickly marked as “won’t fix” by WordPress lead developer Andrew Nacin. His reasoning? Plugin removals happened for various reasons, not just security issues.
For years afterward, the ticket collected digital dust with only occasional attempts to revive it. Someone would stumble across it, leave a hopeful comment, and then silence would fall again. This cycle repeated annually—sometimes even less frequently—until March 2023, when everything changed.
The Reopening That Changed Everything
Enter Joost de Valk, a heavyweight in the WordPress community, who officially reopened the ticket in 2023. His argument was compelling and straightforward: WordPress has a responsibility to tell users whether a plugin is maintained or not. What made his case particularly strong was pointing out that WordPress.org was already showing this information on the platform itself (after a 60-day waiting period)—just not in the WordPress backend where users actually manage their plugins.
This reignited interest sparked a wave of enthusiasm across the thread. The ticket became so popular that Oliver Sild, CEO and co-founder of Patchstack, featured it prominently in his WordCamp Europe 2023 presentation. He even included a custom QR code encouraging attendees to leave comments on the thread—a clever setup for what would become a much larger security initiative the following year.
When Theory Became Alarming Reality
If Oliver’s mention of ticket #30465 at WCEU was subtle foreshadowing, then October 2024 delivered the shocking climax that demanded attention. During Cyber Security Month, Patchstack launched a Bug Bounty event that uncovered horrifying vulnerabilities throughout the WordPress ecosystem.
The numbers were staggering: 1,571 valid security vulnerability reports discovered in a single month. These weren’t minor issues either—they included:
- 73 cases where attackers could upload malicious files directly to sites
- 67 SQL injection vulnerabilities putting entire databases at risk
- 58 pathways for attackers to escalate their privileges
- 17 remote code execution vulnerabilities (the digital equivalent of leaving your front door wide open with a “free stuff” sign)
Even more concerning was what happened after these discoveries. Close to 1,000 plugins were temporarily closed from the repository. When Patchstack attempted to contact plugin developers about fixing these critical issues, an alarming 74% were completely unreachable—their contact forms broken, emails bouncing, or domains expired.
The most chilling revelation? Many vulnerable plugins had been sitting in the repository for 6-11 years, with some dating back an astonishing 17 years. And yes, there are still active websites depending on these plugins today, completely unaware of the risks they’re taking.
From Conversation to Code
Activity on the ticket thread was already gaining momentum when Oliver added his findings, providing undeniable evidence of the problem’s scope. While WordPress lead developer Dion Hulse (@dd32) initially pushed back on some points, he ultimately took decisive action by creating an experimental plugin implementing the long-awaited feature.
The implementation strikes a perfect balance—when a plugin has been closed in the WordPress.org repository, users see a clear but measured notification. No panic-inducing red alerts, just straightforward information about the plugin’s status. It’s elegantly simple yet addresses the decade-old concern.
As the WordPress community collectively whispers, “Someone find Sergej and tell him we made it!” we’re not quite at the finish line yet. The feature hasn’t been incorporated into WordPress core, but we’re standing at the threshold of resolution.
What’s Next for WordPress Plugin Security Awareness
As of early 2025, this much-needed feature is being considered for inclusion in WordPress 6.8, according to Dion Hulse. However, several important details still need resolution:
- Finalizing notification timing (there’s ongoing discussion about possibly extending the current 60-day window)
- Standardizing documentation for closure reasons
- Finding the right balance between user awareness and developer support burden
- Determining the optimal placement—site health screen versus directly on the plugin management page
The Evolution of WordPress Security Consciousness
The journey of ticket #30465 perfectly encapsulates how WordPress security priorities have evolved over the past decade. What was once dismissed as an edge case has become increasingly critical as the ecosystem has expanded and security challenges have multiplied exponentially.
Recent research from WebARX Security shows that plugin vulnerabilities account for approximately 68% of all WordPress site compromises, with outdated or abandoned plugins representing the most common attack vector. This statistic underscores why features like those proposed in ticket #30465 are no longer optional but essential for the platform’s continued success.
According to a 2024 State of WordPress Security report, the average WordPress site uses 23 plugins, and approximately 12% of those plugins have been abandoned by their developers. Without proper notifications, that means millions of sites are running potentially vulnerable code without any awareness of the risks.
Real-World Impact
For WordPress site owners, the implementation of this feature would mean:
- Immediate awareness when a critical plugin has been removed from the repository
- The ability to make informed decisions about plugin usage and replacement
- Reduced security risk through enhanced transparency
- Lower likelihood of site compromise due to abandoned plugins
For the broader WordPress ecosystem, resolving ticket #30465 represents a maturation of security practices that acknowledges the responsibility platform maintainers have toward their users.
While it’s taken ten years to get here, the experimental plugin suggests we’re finally approaching a solution that balances security awareness with an unobtrusive user experience. With over 455 million websites running WordPress worldwide, this feature can’t come soon enough.
If you want to follow along with the development, check out the experimental plugin on GitHub, or keep an eye on ticket #30465. We might be witnessing a rare moment where a decade-long conversation transforms into a tangible feature that improves security for WordPress users everywhere.
What do you think about this upcoming feature? Would knowing that a plugin has been closed from the repository impact how you manage your WordPress site? Share your thoughts in the comments below!