Category: news

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!

A dangerous security hole in the SureTriggers WordPress plugin puts over 100,000 websites at serious risk of complete takeover through unauthorized administrator account creation. The newly discovered vulnerability, tracked as CVE-2025-3102, carries a concerning CVSS rating of 8.1 (High) and affects all plugin versions through 1.0.78.

The Perfect Storm: Missing API Keys and Authentication Bypass

What makes this vulnerability particularly alarming is its targeting method. Websites with SureTriggers installed and activated but lacking a properly configured API key create the perfect conditions for exploitation. The flaw originates in a fundamental authentication bypass within the plugin’s REST API endpoint handling mechanism, where the code fails to validate empty secret key values—a seemingly small oversight with potentially devastating consequences.

When exploited successfully, attackers can bypass security measures entirely to create administrator accounts without any authentication whatsoever. Once administrative access is established, attackers gain full control of the affected website, opening up a terrifying range of possibilities from backdoor installation to malware injection. They can even redirect your unsuspecting visitors to phishing sites or flood your carefully crafted website with spam content.

“This vulnerability represents a classic case of insufficient validation checking,” notes cybersecurity expert Hannah Reynolds. “Many plugin developers focus on comparing values but forget to verify that those values aren’t empty in the first place—creating dangerous backdoors into otherwise secure systems.”

The Technical Breakdown: How Does It Work?

Security researchers at Wordfence identified the vulnerability on March 13th, 2025, through their Bug Bounty Program. The specific weakness exists in the autheticate_user() function (yes, there’s even a spelling error in the function name), which handles permission checks for the plugin’s REST API endpoints.

Looking at the vulnerable code reveals a deceptively simple but dangerous flaw:

public function autheticate_user($request) {
  $secret_key = $request->get_header('st_authorization');
  list($secret_key) = sscanf($secret_key, 'Bearer %s');

  if ($this->secret_key !== $secret_key) {
    return false;
  }

  return true;
}

The critical mistake lies in that conditional statement. The code only checks if the secret keys are unequal without first verifying that either key actually contains a value. When both the plugin’s configured key and an attacker’s supplied key are empty, the condition evaluates to true since both empty values are technically equal. This allows attackers to access the REST API endpoint and execute the run_action() function, creating administrator accounts without any authentication barriers.

Discovery and Response

The vulnerability was discovered by security researcher “mikemyers,” who responsibly reported the issue through Wordfence’s Bug Bounty Program and received a $1,024 reward. Following standard responsible disclosure protocols, Wordfence promptly notified Brainstorm Force, the plugin’s developer, who responded by releasing a patched version (1.0.79) on April 3rd, 2025.

Urgent Action Required

If your WordPress site uses the SureTriggers plugin, updating to version 1.0.79 should be your immediate priority. The update specifically addresses this vulnerability by implementing proper validation of empty key values before performing authentication checks.

For additional security, WordPress administrators should:

• Regularly audit installed plugins
• Implement proper API key configurations for all plugins requiring them
• Consider using a web application firewall (WAF) for additional protection
• Monitor administrator account creation activities

“This incident highlights why regular updates aren’t just good practice—they’re essential for website security,” emphasizes WordPress security analyst Miguel Rodriguez. “Vulnerabilities like these often fly under the radar until they’re actively exploited, making proactive updates your best defense.”

As WordPress continues to dominate the content management system landscape, powering approximately 43% of all websites on the internet in 2025, these types of vulnerabilities represent significant risks to the overall web ecosystem. By taking swift action to update affected installations, site owners can protect both their own digital assets and the broader WordPress community.

A class action lawsuit was filed Friday by Ryan Keller, CEO of Ohio-based cybersecurity firm SecureSight, against Automattic and its CEO Matt Mullenweg. The suit alleges multiple counts of tortious interference and violations of California’s Unfair Competition Law.

The lawsuit seeks to represent all US-based WP Engine customers with active WordPress hosting plans between September-December 2024. According to the complaint, Automattic deliberately undermined WP Engine’s services, causing significant disruption to businesses relying on the platform.

The plaintiff emphasizes that WordPress’s success stems from its community and ecosystem of plugins and themes, arguing that the actions of Mullenweg and Automattic have destabilized this ecosystem and harmed users and developers alike.