Category: Security

Anchor Hosting founder Austin Ginder has disclosed his fourth WordPress.org plugin supply chain attack in a month, this time with help from WP Beacon, a new automated scanning tool he is building to detect the structural patterns these backdoors share.

The WordPress Plugins Team closed the Scroll To Top plugin on April 26, one day after Ginder reported that its buyer had been operating a secret update server since 2023, keeping 20,000 sites on tampered code that WordPress.org never saw.

Ginder published a detailed write-up about the attack on April 30. According to Ginder, WP Beacon flagged the plugin during a scan of the top 2,000 plugins on WordPress.org after detecting it was polling a third-party update server instead of WordPress.org. The plugin’s owner, who bought the plugin sometime in 2023, had registered the domain cdnstaticsync.com nine days before committing the backdoor code in November 2023.

Every installation has been polling that domain on cron ever since. In February 2024, the server began distributing version 1.5.5 — never published to WordPress.org — which rewrites site content by fetching replacement pages from a command-and-control server and injecting them directly into the database.

WordPress.org pushed a clean version 1.5.6, but it will only reach sites that pull from WordPress.org. The 20,000 installations already running the tampered version continue polling cdnstaticsync.com and won’t see the cleanup unless site owners manually reinstall.

Plugins Team co-rep Francisco Torres confirmed Ginder’s write-up as “essentially what happened” and praised his work. 

“Austin is doing an excellent job investigating these issues, correlating events, and drawing conclusions from them,” Torres said. “We truly appreciate his efforts, and we believe he’s doing a fantastic job that is having a positive impact on the ecosystem’s security.”

Torres said the Plugins Team had been working on something similar to WP Beacon. 

“From what I’ve seen, we’re taking different approaches in what we’re building, but it is clear that our objectives are aligned,” he said. “I can definitely see how both approaches could complement each other, ultimately helping to develop an effective tool for automated checks like this.”

The tampered version of Scroll To Top includes two backdoor capabilities. The first, active since February 2024, phones home daily to rewrite WordPress posts or Elementor documents through direct database updates. The second, which Ginder says has not yet been triggered, lets the attacker replace the 1.5.5 zip with any payload, including a webshell, which would auto-install across every affected site at the next update check.

The plugin owner still has SVN commit access to three other plugins he also purchased from a developer named Satrya — Advanced Random Posts Widget, Smart Recent Posts Widget, and Comments Widget Plus — with a combined 40,000+ active installations. None currently ship backdoor code.

The Scroll To Top attack follows the same pattern as Quick Page/Post Redirect, which Ginder disclosed on April 14 — a side-channel update mechanism that evaded WordPress.org oversight for more than five years.

Both exploited WordPress.org’s lack of visibility into third-party update servers, where the code registering the update channel passes review, but the malicious payload served later from attacker infrastructure never gets seen.

Ginder said he built WP Beacon to address that blind spot. The tool, which is coming soon, scans plugin metadata, commit history, author information, and release files for structural patterns of supply chain compromise, including ownership transitions, committer takeovers, update-checker hijacks, and domains registered shortly before releases. He said he used Claude Code extensively to build the detection rules, SVN crawler, and database schema.

Ginder’s other disclosures in the past month include Quick Page/Post Redirect on April 14, the 31-plugin Flippa portfolio on April 9, and Widget Logic on March 31.

Torres previously told The Repository that the Plugins Team was exploring how AI-assisted defenses could strengthen proactive security measures, though he declined to share specifics.

Site owners running Scroll To Top can find cleanup instructions in Ginder’s original disclosure.

The WordPress Plugins Team has closed the Quick Page/Post Redirect plugin after the plugin’s author planted a backdoor in 2020 that let the plugin update from an attacker-controlled server instead of WordPress.org — a technique that evaded oversight for more than five years.

Anchor Hosting founder Austin Ginder published a detailed write-up about the attack this week after discovering 12 sites in his fleet were running a tampered version of the plugin that had been pulling updates from the author’s own server since March 2021.

The Plugins Team closed the plugin on April 14. It had more than 70,000 active installations.

Ginder’s investigation found the plugin’s author, who operates under the username anadnet, had committed code to WordPress.org in October 2020 that embedded the Plugin Update Checker library and pointed it at anadnet.com instead of WordPress.org. Versions 5.2.1 and 5.2.2, both released through the WordPress.org repository, shipped with the self-updater active. In February 2021, the author removed the update library from trunk, but existing installations continued checking anadnet.com for updates.

In March 2021, the author’s update server began distributing version 5.2.3, which included a content injection hook that fetched backlinks from a command-and-control domain and served them to Googlebot while hiding them from logged-in administrators. The C2 domain eventually went dark, leaving the backdoor dormant but still live on tens of thousands of sites.

The tampered version was never distributed via WordPress.org. Site owners who installed the plugin from the repository in 2020 or early 2021 were automatically upgraded to the malicious version through the plugin’s own update mechanism, a process that bypassed WordPress.org’s code review entirely.

A developer named Nico Martin posted the full backdoor code to the plugin’s support forum in January 2022, tagging the author directly. But the version on WordPress.org no longer contained the malicious code, as the author had already removed it. WordPress.org closed the plugin 13 days later, but for an unrelated cross-site scripting issue, not the backdoor. The plugin was reopened nine days after the author committed a sanitization fix. The backdoor was never addressed.

Ginder discovered the issue on April 11 after a routine security scan flagged version 5.2.3. He found that the file hash for the version installed on his fleet’s sites did’t match any version published on WordPress.org. His analysis of the tampered file revealed both the content injection hook and the self-updater pointing at anadnet.com.

Internet Archive snapshots from May 2022 showed the attacker’s update server had been serving the malicious 5.2.3 build, with file modification timestamps matching the installs on his fleet.

Ginder reported the issue to the Plugins Team on April 12, and the plugin was closed two days later, pending a review.

Francisco Torres, a co-rep of the Plugins Team, said Ginder was doing “fantastic work for the security of the ecosystem,” and emphasized that the correct reporting channel for plugin vulnerabilities is plugins@wordpress.org, not the public support forums.

“The Plugins Team doesn’t monitor the support forums,” Torres said. “Forums are great for feedback to plugin authors, but they aren’t a security reporting channel, and posting vulnerability details publicly can be harmful because it can alert other attackers and tip off the original attacker before action can be taken.”

He said the directory had hosted a clean version of the Quick Page/Post Redirect plugin since 2021, and the team was coordinating outreach to affected sites where possible.

The incident is the third WordPress.org plugin supply chain attack Ginder has disclosed in the past month. On March 31, he reported that Widget Logic, a plugin with more than 3 million downloads, had been acquired by a new owner who replaced its functionality with external JavaScript injection. On April 9, he disclosed that a buyer who acquired 31 plugins on Flippa had planted a backdoor across the portfolio and activated it eight months later.

The WordPress Plugins Team has permanently closed 31 plugins and is exploring new AI-assisted defenses after a buyer who acquired the portfolio on Flippa planted a backdoor across all of them and activated it last week — eight months after the purchase.

Austin Ginder, founder of managed WordPress host Anchor Hosting, disclosed the attack on April 9 after a client reported a security notice in their WordPress dashboard. His investigation found that a plugin called Countdown Timer Ultimate — part of a portfolio sold under the name Essential Plugin — had phoned home to an attacker-controlled server, downloaded a malicious file named to resemble a WordPress core file, and injected a substantial block of PHP into wp-config.php.

The injected code fetched spam links and fake pages from a command-and-control server, serving them only to Googlebot to avoid detection by site owners. Ginder found the C2 domain resolved through an Ethereum smart contract, a method designed to survive traditional domain takedowns.

“The buyer’s very first SVN commit was the backdoor,” Ginder wrote.

The Essential Plugin portfolio was originally developed by an India-based team that operated under the name WP Online Support starting around 2015 before rebranding. By late 2024, Ginder wrote, revenue had declined 35% to 45%. The original owner listed the business on Flippa, where a buyer identified only as “Kris,” with a background in SEO, cryptocurrency, and online gambling marketing, purchased it for six figures in early 2025. Flippa published a case study about the sale in July 2025.

According to Ginder, the backdoor was introduced in version 2.6.7 of Countdown Timer Ultimate, released August 8, 2025, with the changelog describing the update as a compatibility check for WordPress 6.8.2. Ginder’s analysis found the actual update added 191 lines of code, including a PHP deserialization vulnerability and an unauthenticated REST API endpoint. The code sat dormant until April 5 and 6, 2026, when the attacker’s server began distributing malicious payloads to affected sites.

On April 7, the Plugins Team permanently closed all 31 Essential Plugin plugins. The following day, WordPress.org pushed a forced auto-update to version 2.6.9.1, disabling the phone-home mechanism. At least 31 plugins, including sliders, galleries, countdown timers, testimonials, and other common functionality, were affected. The Essential Plugin’s website claims it had over 250,000 plugin users on WordPress.org.

The forced update didn’t clean wp-config.php. Ginder warned that sites where the backdoor had already activated before the patch was applied may still be serving hidden spam to search engines. He has published patched versions of 10 of the affected plugins with the malicious wpos-analytics module stripped entirely, along with instructions for cleaning compromised wp-config.php files.

The incident is the second WordPress plugin supply chain attack discovered in two weeks. Ginder reported on March 31 that a plugin called Widget Logic, which has more than 3 million downloads and dates to 2008, had been acquired by a new owner who replaced its original functionality with code that injected external JavaScript onto every page of sites running the plugin. WordPress.org closed that plugin within 20 minutes of receiving his report.

Both attacks followed the same pattern: acquire a plugin with an established install base, inherit WordPress.org commit access, and insert malicious code. In neither case did WordPress.org have advance visibility into the ownership change.

“WordPress.org has no mechanism to flag or review plugin ownership transfers,” Ginder wrote. “There is no ‘change of control’ notification to users. No additional code review triggered by a new committer.”

Francisco Torres, a co-rep of the WordPress Plugins Team, described the incident as “genuinely painful” and acknowledged it should not have happened. He compared it to the XZ Utils supply chain attack, adding that the WordPress ecosystem was no exception to that kind of threat.

“Community members identified and reported the issue quickly after the attack began, and within hours the teams involved had deployed a patch to stop it from spreading and warned affected users,” Torres said. “That kind of collective response is extraordinary, and it’s something we shouldn’t take for granted.”

He said the community’s quick response sent a message to anyone watching: “Buying trust (literally) only to gamble it away in pursuit of quick profit in such a despicable way does not look like a winning strategy. In this case, I guess that bet didn’t pay off.”

He said existing mechanisms to monitor and mitigate these types of risks were not foolproof and that there was room for improvement. The Plugins Team is now exploring proactive ways to handle situations like this in the future, including through AI, though Torres declined to share specifics.

“Community vigilance remains our most important defense,” Torres said, encouraging site owners to report anything unusual to plugins@wordpress.org.

The incidents come as plugin security has been under renewed scrutiny following Cloudflare’s launch of EmDash, a CMS pitched at solving the WordPress plugin security problem.

Site owners running any of the 31 affected plugins can find instructions for checking and cleaning wp-config.php in Ginder’s original disclosure.

A post-mortem published this week by WordPress Security Team rep John Blackbourn details how a missing verification step and a run of unexpected complications turned a routine security release into three unplanned updates in 48 hours.

Blackbourn, who’s the Director of WordPress Security at Human Made, published the retrospective on March 25. It covers the chain of events that began with the 6.9.2 security release on March 10 and produced 6.9.3, 6.9.4, and a mid-cycle 7.0 Beta 4.

6.9.2 patched 10 security vulnerabilities reported to the Security Team via HackerOne. 6.9.3 followed eight hours later after a blank screen issue emerged on sites using classic themes using an unusual approach to template loading. 

Three of the 10 commits made to trunk for 6.9.3 were never successfully merged into the 6.9 branch, which prompted the release of 6.9.4. Blackbourn put the mistake down to human error compounded by a gap in the release checklist.

“Sounds obvious in hindsight,” Blackbourn wrote, “but it’s a checklist oversight that’s never been spotted.” Adding that verification step is among the action points the team has committed to.

As of the retrospective’s publication, the WordPress 6.0 branch remains unprotected following an unresolved build issue. Version 6.0.12, the security backport for that branch, wasn’t shipped alongside the others, and Blackbourn noted it remains unprotected at the time of writing. Backports for all other eligible branches, going back to 4.7, were completed by March 13.

The build problem stems from a commit made to the 6.0 branch in early March that unintentionally changed the branch’s built files, despite the same commit leaving all other branches unaffected, according to a post on the Make WordPress Systems blog.

Blackbourn also raised concerns about the Security Team’s workload when backporting security fixes. The team historically backports fixes as a courtesy to sites on older versions of WordPress, and this cycle required fixes across 22 branches. The technical effort scales with a branch’s age, Blackbourn said, but “the bulk of the work is actually taken up by the human processes that are needed to manage such a large number of branch releases.” 

The team is in the planning stages of automation work aimed at reducing contributor overhead, and Blackbourn noted that the scope for backporting “continues to be a source of contention between the security team and project leadership.”

One process change did land well, Blackbourn said — the team’s decision to fully ship 6.9.2 to the current supported branch before starting backport work, rather than holding the release until all branches were ready. The team flagged it as worth keeping.

Longer term, Blackbourn noted that WordPress co-founder Matt Mullenweg has asked the team to look into what AI-assisted tooling could be used to review changes going into releases, with a view to assessing breakage risk and improving quality control across releases generally. 

Disclosure: Human Made is a sponsor of The Repository.

When a new WordPress vulnerability is made public, attackers are typically exploiting it within five hours. Nearly half of those vulnerabilities have no patch available at the time of disclosure. And if a site does get infected, there’s a good chance the malware will simply rewrite itself after cleanup.

That’s the picture painted by Patchstack’s State of WordPress Security In 2026, published in partnership with malware intelligence firm Monarx.

The headline stat: 11,334 new vulnerabilities were discovered in the WordPress ecosystem in 2025, a 42% increase from 2024’s 7,966. Even more eyebrow-raising is that highly exploitable vulnerabilities increased by 113% year-on-year. 

More high-severity vulnerabilities were found in 2025 than in the previous two years combined. Of the total, 1,966 (17%) were rated high severity, meaning they were likely to be targeted in mass automated attacks. Plugins accounted for 91% of all vulnerabilities, with just six found in WordPress core.

The patch gap is getting worse

Forty-six percent of vulnerabilities last year weren’t fixed in time for disclosure, meaning nearly half were made public while the affected plugin remained unpatched.  “This again shows why website owners can’t rely on plugin updates as a security measure,” the report adds.

Among heavily exploited vulnerabilities, Patchstack’s data shows that 20% were exploited within six hours of disclosure, 45% within 24 hours, and 70% within seven days. The weighted median time to first exploitation was five hours.

The report drives home what this means for site admins who rely on plugin updates: “Regular plugin updates are the second line of defence, but as attackers weaponize new vulnerabilities within mere hours, this is not a viable defence.” 

Patchstack’s data comes from RapidMitigate, its automated protection product, which deploys rules at the moment a vulnerability is disclosed, giving the company visibility into exploitation attempts in near real-time.

Adding pressure on the other side are AI-generated “slop” vulnerability reports, meaning incomplete or invalid submissions that create noise without adding signal, increased significantly in 2025. Security teams are being forced to triage more reports faster at “unprecedented levels” while attackers are moving quicker than ever to exploit the ones that are real.

Most hosting defences aren’t working

Patchstack conducted two pentesting studies in 2025 testing common security solutions including internal WAFs, Cloudflare, Imunify360, and ModSecurity against real WordPress vulnerability exploits. Traditional defences blocked just 12% of attacks when focused on known exploited vulnerabilities. A broader test raised that figure only to 26%.

Results varied widely across hosts. The best-performing non-Patchstack host (running Imunify360, SiteLock, and an internal WAF) blocked 60.7% of attacks. Several hosts using combinations of Cloudflare, ModSecurity, and Imunify360 blocked fewer than 17%. One blocked nothing. 

The report attributes the poor results partly to Broken Access Control, which accounted for 57% of attacks blocked by RapidMitigate and looks in practice like normal authenticated traffic, with no obvious injection patterns that generic rules can detect.

Premium plugins carry more risk than assumed

The report flags an ongoing blind spot in premium plugins and themes purchased from marketplaces like Envato, which receive less researcher scrutiny because their code is harder to access. Of 1,983 valid vulnerability reports Patchstack received for premium or freemium products in 2025, 76% were rated exploitable in real-world attacks. Premium products also had three times as many Known Exploited Vulnerabilities as free products.

The report also notes that only four of the 10 most exploited plugins of 2025 were made public. The rest were disclosed in 2023 or 2024. “This is an important reminder that attackers will also attempt to exploit older vulnerabilities, hoping to infect sites that are not properly kept up to date,” the report notes.

“Stealthy” malware designed to survive cleanup

The Monarx section of the report draws on nearly 9 trillion file signals processed in 2025 to examine what happens after compromise. Its central finding: “signature-based ‘delete-only’ security is no longer sufficient.”

The core problem is that attackers are increasingly injecting malicious code into legitimate WordPress files rather than dropping standalone malicious files. Unlike malicious files which can simply be deleted automatically, injected files are legitimate core, plugin or theme components that contain malicious snippets. Remove them and you break the site.

Monarx highlights the Lock360 malware family as an example of how far this can go. Its two top variants accounted for 38% and 32% of all injected file detections in 2025, and it runs malicious code in server memory, automatically rewriting cleaned files the moment they’re restored. The report describes the result: “support teams find themselves in a frustrating cycle — they clean an infection only for it to immediately rewrite itself because the malware is still running in the background.”

Parrot TDS was the most common malicious code injected into clean files, accounting for 64% of all injected sequences. It works like a traffic direction system: search engine crawlers see keyword-stuffed spam to manipulate rankings, human visitors get redirected to phishing sites or fraudulent stores, and security scanners see nothing. The report notes that newer variants have evolved to also detect AI training crawlers like ChatGPT and Google Gemini, serving them clean content while continuing to target human visitors.

Malicious file activity spiked sharply in November and December, a pattern Monarx attributes to high traffic coinciding with reduced IT staffing.

Meanwhile, uploader scripts surged in mid-2025 and stayed elevated through year-end. The report interprets the trend as a strategic shift as attackers are “moving beyond opportunistic, one-off compromises” and “investing in persistent infrastructure,” planting uploaders that enable multi-stage attacks and long-term access even after partial fixes.

The full State of WordPress Security In 2026 report is available on the Patchstack website, with extended malware analysis at Monarx.

Disclosure: Patchstack is a sponsor of The Repository.

Ten hosting providers have been certified under the Secure Hosting Alliance’s new Trust Seal program, marking the first round of companies to complete the independent verification process introduced earlier this year.

20i, Altushost, BigScoots, Blacknight, DreamHost, Green Olive Tree, Hostinger, Raksmart, Sharktech, and SiteGround are the inaugural recipients. Each has met the program’s four pillars for ethical and secure hosting: transparency, infrastructure misuse protocols, network resource reliability, and government request handling.

Together, the ten hosts represent nearly half of the Secure Hosting Alliance’s 24 participating members, which also include GoDaddy, Automattic, and Newfold Digital.

[yarpp]

Launched in February under the umbrella of the Internet Infrastructure Coalition (i2Coalition), the Secure Hosting Alliance (SHA) was formed to tackle the growing challenges around abuse mitigation, security, and trust in the hosting space. Rather than waiting for regulation, the group is taking a self-governing approach.

“The certification transforms trust from assumption into proof,” said SHA Director and i2Coalition co-founder David Snead.

“Companies and individuals looking for hosting platforms are no longer forced to rely on vague assurances that their host will engage in ethical practices. Rather, the SHA has replaced unenforceable promises with documented compliance that includes annual statements and regular oversight.

“Certification not only has immediate customer-facing benefits, it also reinforces ethical responsibility and legal compliance across the hosting ecosystem.”

For DreamHost, one of the charter members that helped shape the certification framework, the process has been about collaboration as much as compliance.

“As a charter member of the Secure Hosting Alliance’s certification program, DreamHost had a hand in shaping the certification’s requirements from day one,” said Brett Dunst, VP of Corporate Communications at DreamHost. “Our team worked alongside other web hosts over the past year to define what ‘secure hosting’ really means, and to make sure those standards protect both web creators and the communities they serve.”

BigScoots COO James Webb described the certification as “a public commitment that validates the secure and reliable foundation we built BigScoots on.”

“Achieving the SHA Trust Seal is not just an award, it’s a public commitment that validates the secure and reliable foundation we built BigScoots on,” said Webb. “In an age where data security and trust are paramount, this certification provides our Managed Hosting clients with verified, third-party assurance that their critical infrastructure is in the safest, most accountable hands in the industry. It’s a game-changer for businesses seeking true peace of mind.”

SHA certification isn’t permanent. Hosting providers must renew annually and remain compliant to retain the seal. More companies are expected to join in the coming months as the program continues to scale.

WordPress 6.8.3 was released yesterday, rolling out security fixes for two vulnerabilities in core. The update addresses a data exposure issue where authenticated users could access some restricted content, and a cross-site scripting (XSS) vulnerability affecting navigation menus.

If your site has automatic background updates switched on, the release has already been applied. Everyone else is advised to update immediately. The fixes have also been backported to earlier branches, going back to WordPress 4.7.

The release was led by Human Made–sponsored core committer John Blackbourn, who credited Mike Nelson, Abu Hurayra, Timothy Jacobs, Peter Wilson, and Phill Savage for independently and responsibly disclosing the vulnerabilities. Blackbourn also thanked 17 other people who contributed to the security release.

[yarpp]

The release comes after security company Patchstack accidentally published advisories about the two vulnerabilities in its database last week, catching the WordPress Security Team off guard. The advisories surfaced in Post Status Slack on September 23 as a PSA-type post shared by writer and developer Eric Karkovack, prompting Blackbourn to ask, “Where did you get these links?”

In a separate thread, GoDaddy engineer Scott Kingsley Clark asked, “Weird, is this normal for a vulnerability to be posted for core when there’s no release for it yet?” Patchstack’s Head of Threat Intelligence, Darius Sveikauskas, admitted the disclosures were due to “human (me) error,” while CEO Oliver Sild apologized and called it a reminder of “how small [the] room for errors” is in vulnerability disclosure.

Sveikauskas explained that the slip happened because Patchstack normally processes low-severity vulnerabilities via a semi-automatic workflow, but issues affecting WordPress core should have been filtered out and handled manually.

“Yesterday we have published 250+ vulnerabilities and due to human (me) mistake additional filtering … was not applied,” he posted, adding that the company was updating its processes to ensure it doesn’t happen again.

Sild backed up Sveikauskas’s track record of handling more than 10,000 disclosures and praised his transparency in owning the error. “Internal hugops going on,” he posted, adding that the Security Team had been “very understanding” and that the decision to republish the entries before the official patch was made together.

Blackbourn confirmed to The Repository that the advisories went live without any coordination with the WordPress Security Team, stressing that it wasn’t a planned early disclosure. The decision to keep them public came afterwards, with both teams noting the vulnerabilities were low severity and unlikely to be exploited in the wild.

The next major release of WordPress, 6.9, is due out on December 2 and is expected to include block commenting and a simplified editing mode alongside an early version of the admin redesign.

Almost every WordPress professional has faced a security incident, yet fewer than a third have a plan for what to do when things go wrong, according to Melapress’s 2025 WordPress Security Survey, published this week.

Now in its third year, the survey paints a picture of a community deeply aware of the security risks but struggling to translate concern into action. Ninety-six percent of respondents said they had experienced at least one past security incident, and 64% reported a full breach. Yet only 27% have a documented recovery plan.

The survey defined “security incident” broadly, ranging from minor events like phishing emails or automated login attempts to major ones like breaches to capture the reality that while not every incident leads to damage, nearly every site faces some form of attack.

Melapress founder and CEO Robert Abela said the gap reflected a misunderstanding of what “recovery” really means. “Many think that having a service that cleans up malware or restores a hacked website counts as a ‘recovery plan.’ That’s not really a breach recovery plan. That is damage control,” he told The Repository.

A proper plan, he said, should include reproducible processes, data recovery measures, and regular testing: “We clearly need more awareness and training.”

[yarpp]

A total of 264 people completed the survey — a modest sample, but one Abela described as a broad and experienced cross-section of the WordPress community. More than 100 respondents reported over a decade of experience, and participants included developers, site owners, admins, agencies, designers, and consultants working across ecommerce, blogs, membership platforms, client projects, and enterprise sites. 

Responses were gathered at WordCamp Europe, through virtual events, social media outreach, email campaigns, and YouTube promotion between May 14 and July 29, 2025.

When asked to choose their top concerns, respondents overwhelmingly prioritized website availability (60%), data theft or loss (53%), and website defacement (50%). Compliance ranked far lower, with just 26% considering it a top priority.

Abela said compliance’s low ranking wasn’t a surprise, citing complex regulations and inconsistent enforcement. “You rarely hear about an organization being penalized simply for not being compliant before anything goes wrong,” he said.

Even those worried about compliance often lack the basics: only 26% of those concerned about had a breach recovery plan in place.

The survey also found a mismatch between concern and action across several areas:

• Account security: 32% of respondents worried about data theft or defacement had not implemented two-factor authentication or login restrictions.
• Monitoring: 37% of those concerned about defacement didn’t use activity logs.
• Training: Only 27% of all respondents had implemented any form of security training, even though human error remains a leading factor in breaches.

Despite these gaps, Abela said there were signs of progress. WordPress is “more secure than ever,” thanks to features like automatic updates and Site Health. The rise in plugin vulnerabilities year over year is concerning but also “means more plugins are becoming secure; someone is finding those issues and they’re getting fixed,” he said.

Abela’s recommendations based on the findings are straightforward: create a recovery plan, take ownership of security even when outsourcing, implement key controls like 2FA, and invest in team training.

“Security should not depend entirely on people. We make mistakes, but awareness is still critical,” Abela said. “When your team is both informed and equipped, your website and your whole organization will have a much stronger security posture.”

The full survey results are available on the Melapress blog.

Feature image: Melapress.

Many hosting companies market themselves on security. Patchstack decided to put those claims to the test — and found most hosts failed. In a new case study, the security company found that 87.8% of plugin exploits sailed past network and server defenses before being stopped at the application layer.

The company spun up identical WordPress sites with 11 known plugin vulnerabilities — ranging from privilege escalation and SQL injection to arbitrary file upload — and ran the exploits. The goal was to see whether the hosts’ advertised defenses actually worked. Most didn’t.

Two hosts failed to block a single exploit. One stopped just one. Another blocked two. The best result came from Cloudflare’s WAF, used by one of the providers, which managed to stop four out of 11.

Patchstack didn’t name the five hosts it tested, referring to them only as Hosting Provider A through E. CEO Oliver Sild told The Repository they were chosen deliberately: “We looked for hosting companies that include security in their marketing and list different security tools they use to keep customers’ websites safe. Some of them were big players who host millions of websites, others were smaller managed WordPress hosting providers.”

[yarpp]

The blind spot in WordPress security

Patchstack’s test included 11 vulnerabilities: some already exploited in the wild, some in widely used plugins, a few that had recently made headlines, and three newly reported issues designed to test behavior-based defenses. To keep things fair, the exploits were run in their most obvious form — no evasion techniques — using older vulnerable versions of plugins including WooCommerce Payments, GiveWP, and LiteSpeed Cache.

Traditional defenses didn’t stand a chance, according to Sild. “Network-level WAFs are too generic with their protection, missing WordPress-specific vulnerabilities almost completely, and server-level security solutions mostly focus on post-exploitation,” said Sild. “There’s a huge blind spot on application security, and WordPress is a hard platform to protect when vulnerabilities can surface from any plugin.”

He pointed to a broader pattern. Earlier this year, Patchstack and Sucuri analyzed 500,000 hacked sites in 2024 for their State of WordPress Security In 2025. “How is this possible when we see most hosting companies claim to provide ‘secure WordPress hosting’?” he said. “Our testing really shows why those claims don’t match the reality.”

When “virtual patching” isn’t patching

The case study also tested two popular third-party patching providers, Imunify360 and Monarx, both marketed as solutions that automatically protect sites against plugin vulnerabilities — and both competitors to Patchstack.

Sild said the problem was twofold: a lack of application-level visibility and reliance on delayed public CVE data. “Put simply, you can’t protect against what you don’t know about,” he said. “RapidMitigate, which is the system we’ve built to provide fast mitigation, has by far the biggest vulnerability coverage in the WordPress ecosystem — over 12,000 vulnerability-specific mitigation rules. In comparison, generic solutions often have just 500 to 1,000 rules in total, and they need to keep the number as low as possible because every rule has to cycle through every request.”

Cloudflare as an outlier

Cloudflare’s results were the best of the lot, blocking four exploits including an SQL injection and a stored XSS attack. That was surprising, Sild said, because Cloudflare doesn’t position itself as WordPress-specific protection. 

“Blocking WordPress-specific vulnerabilities on a network WAF is one of the hardest things to do,” he said. “That Cloudflare did such a great job shows how much they’ve invested in their security team and threat intelligence.”

Even so, most attacks still made it through. “With just these solutions, the sites of these hosting companies’ users would have been exposed to real attacks,” Patchstack wrote in its analysis. In fact, before enabling Patchstack, the researchers were able to gain full administrative access on every test site.

For Sild, the findings point to the gap between what users are so often sold and what they actually get. “WordPress security cannot be solved on a single layer,” he said. “The website needs proper vulnerability management and mitigation in place.”

Reporting vs reputation

The case study follows recent remarks from WordPress co-founder Matt Mullenweg, who argued that security is largely handled by hosting companies at the network level and the “constant stream” of posts about vulnerabilities was “negative for WP adoption overall.”

You know most hosts protect against these at network level. The constant stream of posts about XX,XXX vulnerable websites I think is negative for WP adoption overall. Not unique to Patchstack but I’m curious your thoughts on how to shift that narrative.

— Matt Mullenweg (@photomatt) July 31, 2025

Sild challenged the notion that network-level defenses are enough, arguing that the honeypot results show otherwise. “It’s just not true,” he said. “It’s been proven over and over again in the past as well, and today we present just another example.”

Disclaimer: Patchstack is a sponsor of The Repository.

Patchstack has published its 2025 mid-year vulnerability report, revealing a sharp rise in both the volume and severity of security issues across the WordPress ecosystem. In the first six months of the year, 6,700 new vulnerabilities were reported, with 41.5% exploitable in real-world conditions — a jump the company says is concerning.

It’s a big increase from the same period last year, when 30.4% of vulnerabilities were considered exploitable. Nearly 58% of those disclosed so far in 2025 can be triggered without any authentication, highlighting the risks posed by automated, large-scale attacks.

The vast majority of vulnerabilities were found in plugins (89%), followed by themes (11%), with just one vulnerability discovered in WordPress core. The most common types remain familiar:  Cross-Site Scripting (XSS), Cross-Site Request Forgery (CSRF), Broken Access Control, and Local File Inclusion, together accounting for most reported vulnerabilities.

[yarpp]

Patchstack, which in April became the world’s top CVE coordinator, attributes the increase to its growing bug bounty program and researcher community. More than 3,400 valid reports were submitted in the first half of 2025, making the company responsible for nearly 67% of all known WordPress vulnerabilities so far this year.

The report also challenges the reliability of CVSS (Common Vulnerability Scoring System) scores as a sole indicator of severity. While only 22% of vulnerabilities were rated high or critical under CVSS, Patchstack’s own scoring, which accounts for exploitability, reach, and active attack data, placed 41.5% in the high-priority category. Patchstack explains in the report: “As a general system, the CVSS score doesn’t account for the specifics of the WordPress ecosystem.”

Hosting companies are urged to take a more proactive role. The report notes that plugin updates often lag behind disclosures, increasing the window of risk. Even when a vulnerability originates in a third-party plugin or theme, hosts may still face reputational fallout and a surge in demand for support.

Theme security is also getting closer attention this year, as more premium developers join Patchstack’s managed vulnerability disclosure program. That trend is expected to accelerate with the EU’s Cyber Resilience Act set to take effect in 2026. Once in force, plugin and theme developers will be legally required to address security vulnerabilities, or face penalties similar to those under the GDPR.

The full report is available for download on the Patchstack website.