Written by 
Back in November 2014, a WordPress developer named Sergej Mueller raised what seemed like a reasonable concern: users had no way of knowing if a plugin they were using had been removed from the official repository – even if it was removed for security reasons. His ticket – officially #30465 – was closed relatively soon after, but with no resolution. Little did Sergej know that it would be reopened almost ten years later.
And here we are, at the start of 2025, with me writing an update about it.
Why?
For a few reasons.
First, it’s highly relevant to some plugin security events that happened recently – October of last year to be exact. I’ll talk about those shortly. And, second, the will and momentum to resolve the issue has been picking up some serious steam – the last activity on the ticket was less than a month ago:
So it looks as if Sergej’s patience might finally be paying off soon…
Let’s start by retracing the development of the ticket. Then, we can move into what’s been happening with it in recent weeks:
From “won’t fix” to taking the stage at WCEU 2023 🙅♂️
When the ticket was first opened, it received a few responses but was shut down fairly quickly by WordPress lead developer Andrew Nacin. He closed it and marked it as “won’t fix,” explaining that plugin removals happened for various reasons, not only security issues:
There was some flurry of commentary after that, but then it died down into a once-a-year (sometimes even less than that) comment of someone attempting to revive the issue.
Then, in March 2023, something interesting happened. Joost de Valk, a well-known figure in the WordPress community, officially reopened the ticket. His argument was that WordPress has a responsibility to tell users whether a plugin is maintained or not.
He also pointed out that WordPress.org was already showing this information on the platform itself, but only after a 60-day waiting period. His suggestion was to bring that same transparency to the WordPress backend where users actually manage their plugins.
That set off a new wave of enthusiasm across the thread. The ticket grew so popular that Oliver Sild, the CEO and co-founder of Patchstack, even mentioned it in his WCEU 2023 speech:
Not only did he mention it, but he encouraged the WCEU attendees to leave comments on the thread by using the custom QR code that he added to his presentation. He also used this plug as a delayed alley-oop for a contest that Patchstack would host the following year.
Patchstack’s October 2024 event 🪲
In October 2024, Patchstack launched a Bug Bounty event as part of Cyber Security Month. If Oliver’s mention of ticket #30465 in his WCEU speech was the alley-oop, then the results of this event would be its slam dunk.
Security researchers who participated in the event, ended up discovering a staggering 1,571 valid security vulnerability reports in a single month. These weren’t just minor issues either – we’re talking about:
- 73 cases where attackers could upload malicious files.
- 67 SQL injection vulnerabilities that could compromise entire databases.
- 58 ways for attackers to escalate their privileges.
- 17 remote code execution vulnerabilities (yikes!)
The aftermath resulted in close to 1,000 plugins temporarily closing. And when Patchstack tried to contact plugin developers about these issues, almost 74% were completely unreachable. Either their contact forms were broken, their emails bounced, or their domains had expired.
The kicker is that many of these vulnerable plugins had been sitting in the repository for 6-11 years. Some dated as far back as 17 years! And yes, there are still live websites depending on these plugins.
Needless to say, all of this data gave Oliver leverage in the thread to push ticket #30465 forward toward completion. He happily took advantage of it, and posted some of the details two weeks before the publication of the official Patchstack blog post discussing the event:
From discussion to action 🛠️
Activity on the thread was already snowballing when Oliver added his comment so gauging its individual impact is tough. However, it’s not unreasonable to assume that it added fuel to a growing flame. Especially with other users (of which at least one is a Patchstack employee) openly supporting his commentary.
In response, WordPress lead developer Dion Hulse (@dd32) gave some pushback on several points, but also stepped up in a huge way by creating an experimental plugin that implements the long-awaited feature:
The implementation is beautifully simple – 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.
Someone find Sergej and tell him, “mama we made it!”
Well…almost.
It’s not part of WordPress core yet, but I do sense that we’re close to the finish line here!
Now that it’s been shown to be possible, the next step is to decide on a final implementation. Then it can be integrated into WordPress core.
What’s next? 🎯
As of the time of this writing, the feature is being considered for inclusion in WordPress 6.8 (per Dion Hulse), though there are still some hurdles to clear. These include:
- Finalizing the notification timing (there’s discussion about possibly extending the 60-day window).
- Standardizing closure reason documentation.
- Balancing user awareness with developer support burden.
- Deciding on exact location (the site health screen vs directly on the plugin as shown in the plugin example screenshot).
The big picture 🌐
The evolution of WordPress ticket #30465 tells us something fascinating about how WordPress security has changed over the past decade. What was once dismissed as an edge case has become increasingly critical as the ecosystem has grown and security challenges have multiplied.
While it’s taken ten years to get here, the experimental plugin suggests we’re finally approaching a solution that balances security awareness with user experience. With millions of WordPress installations potentially affected by vulnerable plugins, this feature can’t come soon enough.
If you want to follow along with the development then check out the experimental plugin on GitHub, or keep an eye on ticket #30465. This might be one of those rare moments where we get to witness a decade-long conversation transform into a tangible outcome. 💡
What do you think about this feature? Do you think it would be helpful to you as a WordPress user to be informed that a plugin was closed? Let me know in the comments. I’ll see you there.
Yay! 🎉 You made it to the end of the article!