WP Engine Complaint Adds Unredacted Allegations About Mullenweg Plan via @sejournal, @martinibuster

WP Engine recently filed its third amended complaint against WordPress co-founder Matt Mullenweg and Automattic, which includes newly s allegations that Mullenweg identified ten companies to pursue for licensing fees and contacted a Stripe executive in an effort to persuade Stripe to cancel contracts and partnerships with WPE.

Mullenweg And “Nuclear War”

The defendants argued that Mullenweg did not use the phrase “nuclear war.” However, documents they produced show that he used the phrase in a message describing his response to WP Engine if it did not comply with his demands.

The footnote states:

“During the recent hearing before this Court, Defendants represented that “we have seen over and over again ‘nuclear war’ in quotes,” but Mullenweg “didn’t say it” and it “[d]idn’t happen.” August 28, 2025 Hrg. Tr. at 33. According to Defendants’ counsel, Mullenweg instead only “refers to nuclear,” not “nuclear war.””

While WPE alleges that both threats are abhorrent and wrongful, reflecting a distinction without a difference, documents recently produced by Defendants confirm that in a September 13, 2024 message sent shortly before Defendants launched their campaign against WPE, Mullenweg declared “for example with WPE . . . [i]f that doesn’t resolve well it’ll look like all-out nuclear war[.]”

Email From Matt Mullenweg To A Stripe Executive

Another newly unredacted detail is an email from Matt Mullenweg to a Stripe executive in which he asked Stripe to “cancel any contracts or partnerships with WP Engine.” Stripe is a financial infrastructure platform that enables companies to accept credit card payments online.

The new information appears in the third amended complaint:

“In a further effort to inflict harm upon WPE and the market, Defendants secretly sought to strongarm Stripe into ceasing any business dealings with WPE. Shocking documents Defendants recently produced in discovery reveal that in mid-October 2024, just days after WPE brought this lawsuit, Mullenweg emailed a Stripe senior executive, insisting that Stripe “cancel any contracts or partnerships with WP Engine,” and threatening, “[i]f you chose not to do so, we should exit our contracts.”

“Destroy All Competition”

In paragraphs 200 and 202, WP Engine alleges that Defendants acknowledged having the power to “destroy all competition” and were seeking contributions that benefited Automattic rather than the WordPress.org community. WPE argues that Mullenweg abused his roles as the head of a nonprofit foundation, the owner of critical “dot-org” infrastructure, and the CEO of a for-profit competitor, Automattic.

These paragraphs appear intended to support WP Engine’s claim that the “Five for the Future” program and other community-oriented initiatives were used as leverage to pressure competitors into funding Automattic’s commercial interests. The complaint asserts that only a monopolist could make such demands and successfully coerce competitors in this manner.

Here are the paragraphs:

“Indeed, in documents recently produced by Defendants, they shockingly acknowledge that they have the power to “destroy all competition” and would inflict that harm upon market participants unless they capitulated to Defendants’ extortionate demands.”

“…Defendants’ monopoly power is so overwhelming that, while claiming they are interested in encouraging their competitors to “contribute to the community,” internal documents recently produced by Defendants reveal the truth—that they are engaged in an anticompetitive campaign to coerce their competitors to “contribute to Automattic.” Only a monopolist could possibly make such demands, and coerce their competitors to meet them, as has occurred here.”

“They Get The Same Thing Today For Free”

Additional paragraphs allege that internal documents contradict the defendants’ claim that their trademark enforcement is legitimate by acknowledging that certain WordPress hosts were already receiving the same benefits for free.

The new paragraph states:

“Contradicting Defendants’ current claim that their enforcement of supposed trademarks is legitimate, Defendants conceded internally that “any Tier 1 host (WPE for example)” would “pushback” on agreeing to a purported trademark license because “they get the same thing today for free. They’ve never paid for [the WordPress] trademarks and won’t want to pay …”

“If They Don’t Take The Carrot We’ll Give Them The Stick”

Paragraphs 211, 214, and 215 cite internal correspondence that WP Engine alleges reflects an intention to enforce compliance using a “carrot” or “stick” approach. The complaint uses this language to support its claims of market power and exclusionary conduct, which form the basis of its coercion and monopolization allegations under the Sherman Act.

Paragraph 211:

“Given their market power, Defendants expected to be able to enforce compliance, whether with a “carrot” or a “stick.””

Paragraph 214

“Defendants’ internal discussions further reveal that if market participants did not acquiesce to the price increases via a partnership with a purported trademark license component, then “they are fair game” and Defendants would start stealing their sites, thereby effectively eliminating those competitors. As Defendants’ internal correspondence states, “if they don’t take the carrot we’ll give them the stick.””

Paragraph 215:

“As part of their scheme, Defendants initially categorized particular market participants as follows:
• “We have friends (like Newfold) who pay us a lot of money. We want to nurture and value these relationships.”
• “We have would-be friends (like WP Engine) who are mostly good citizens within the WP ecosystem but don’t directly contribute to Automattic. We hope to change this.”
• “And then there are the charlatans ( and ) who don’t contribute. The charlatans are free game, and we should steal every single WP site that they host.””

Plan To Target At Least Ten Competitors

Paragraphs 218, 219, and 220 serve to:

  • Support its claim that WPE was the “public example” of what it describes as a broader plan to target at least ten other competitors with similar trademark-related demands.
  • Allege that certain competitors were paying what it describes as “exorbitant sums” tied to trademark arrangements.

WP Engine argues that these allegations show the demands extended beyond WPE and were part of a broader pattern.

The complaint cites internal documents produced by Defendants in which Mullenweg claimed he had “shield[ed]” a competitor “from directly competitive actions,” which WP Engine cites as evidence that Defendants had and exercised the ability to influence competitive conditions through these arrangements.

In those same internal documents, proposed payments were described as “not going to work,” which the complaint uses to argue that the payment amounts were not standardized but could be increased at Defendants’ insistence.

Here are the paragraphs:

“218. Ultimately, WPE was the public example of the “stick” part of Defendants’ “trademark license” demand. But while WPE decided to stand and fight by refusing Defendants’ ransom demand, Defendants’ list included at least ten other competitors that they planned to target with similar demands to pay Defendants’ bounty.

219. Indeed, based on documents that Defendants have recently produced in discovery, other competitors such as Newfold and [REDACTED] are paying Defendants exorbitant sums as part of deals that include “the use of” Defendants’ trademarks.

220. Regarding [REDACTED], in internal documents produced by Defendants, [REDACTED] confirmed that “[t]he money we’re sending from the hosting page is going to you directly”.

In return, Mullenweg claimed he apparently “shield[ed]” [REDACTED] “from directly competitive actions from a number of places[.]”.

Mullenweg further criticized the level of contributions for the month of August 2024, claiming “I’d need 3 years of that to get a new Earthroamer”.

Confronted with Mullenweg’s demand for more, [REDACTED] described itself as “the smallest fish,” suggesting that Mullenweg “can get more money from other companies,” and asking whether [REDACTED] was “the only ones you’re asking to make this change” in an apparent reference to “whatever trademark guidelines you send over”.

Mullenweg responded “nope[.]”. Later, on November 26, 2024—the same day this Court held the preliminary injunction hearing—Mullenweg told [REDACTED] that its proposed “monthly payment of [REDACTED] and contributions to wordpress.org were not “going to work,” and wished it “[b]est of luck” in resisting Defendants’ higher demands.”

WP Engine Versus Mullenweg And Automattic

Much of the previously redacted material is presented to support WP Engine’s antitrust claims, including statements that Defendants had the power to “destroy all competition.” What happens next is up to the judge.

Featured Image by Shutterstock/Kues

WordPress Publishes AI Guidelines To Combat AI Slop via @sejournal, @martinibuster

WordPress published guidelines for using AI for coding plugins, themes, documentation, and media assets. The purpose of the guidelines, guided by five principles, is to keep WordPress contributions transparent, GPL-compatible, and human-accountable, while maintaining high quality standards for AI-assisted work.

The new guidelines lists the following five principles:

  1. “You are responsible for your contributions (AI can assist, but it isn’t a contributor).
  2. Disclose meaningful AI assistance in your PR description and/or Trac ticket comment.
  3. License compatibility matters: contributions must remain compatible with GPLv2-or-later, including AI-assisted output.
  4. Non-code assets count too (docs, screenshots, images, educational materials).
  5. Quality over volume: avoid low-signal, unverified “AI slop”; reviewers may close or reject work that doesn’t meet the bar.”

Transparency

The purpose of the transparency guidelines is to encourage contributors to disclose that AI was used and how it was used so that reviewers can be aware when evaluating the work.

License Compatibility And Tool Choice

Licensing is a big deal with WordPress because it’s designed to be a fully open source publishing platform under the GPLv2 licensing framework. Everything that’s made for WordPress, including plugins and themes, must also be open source. It’s an essential element of everything created with WordPress.

The guidelines specify that AI cannot be used if the output is not licensable under GPLv2.

It also states:

“Do not use tools whose terms forbid using their output in GPL-licensed projects or impose additional restrictions on redistribution.

Do not rely on tools to “launder” incompatible licenses. If an AI output reproduces non-free or incompatible code, it cannot be included.”

AI Slop

Of course, the guidelines address the issue of AI slop. In this case, AI slop is defined as hallucinated references (such as links or APIs that do not exist), overly complicated code where simpler solutions exist, and GitHub PRs that are generic or do not reflect actual testing or experience.

The AI Slop guidelines has recommendations of what they expect from contributors:

“Use AI to draft, then review yourself.

Submit PRs (or patches) that are small, concise and with atomic and well defined commit messages to make reviewing easier.

Run and document real tests.

Link to real Trac tickets, GitHub issues, or documentation that you have verified.”

The guidelines are clear that the WordPress contributors who are responsible for overseeing, reviewing, and deciding whether changes are accepted into a specific part of the project may close or reject contributions that they determine to be AI slop “with little added human insight.”

Takeaways

The new WordPress AI guidelines appear to be about preserving trust in the contribution process as AI becomes more common across development, documentation, and media creation. It in no way discourages the use of AI but rather encourages its use in a responsible manner.

Requiring disclosure, enforcing GPL compatibility, and giving maintainers the authority to reject low-quality submissions, the guidelines set boundaries that protect both the legal integrity of the WordPress project and the time of its reviewers.

Featured Image by Shutterstock/Ivan Moreno sl

WordPress Announces AI Agent Skill For Speeding Up Development via @sejournal, @martinibuster

WordPress announced wp-playground, a new AI agent skill designed to be used with the Playground CLI so AI agents can run WordPress for testing and check their work as they write code. The skill helps agents test code quickly while they work.

Playground CLI

Playground is a WordPress sandbox that enables users to run a full WordPress site without setting it all up on a traditional server. It is used for testing plugins, creating and adjusting themes, and experimenting safely without affecting a live site.

The new AI agent skill is for use with Playground CLI, which runs locally and requires knowledge of terminal commands, Node.js, and npm to manage local WordPress environments.

The wp-playground skill starts WordPress automatically and determines where generated code should exist inside the installation. The skill then mounts the code into the correct directory, which allows the agent to move directly from generated code to a running the WordPress site without manual setup.

Once WordPress is running, the agent can test behavior and verify results using common tools. In testing, agents interacted with WordPress through tools like curl and Playwright, checked outcomes, applied fixes, and then re-tested using the same environment. This process creates a repeatable loop where the agent can confirm whether a change works before making further changes.

The skill also includes helper scripts that manage startup and shutdown. These scripts reduce the time it takes for WordPress to become ready for testing from about a minute to only a few seconds. The Playground CLI can also log into WP-Admin automatically, which removes another manual step during testing.

The creator of the AI agent skill, Brandon Payton, is quoted explaining how it works:

“AI agents work better when they have a clear feedback loop. That’s why I made the wp-playground skill. It gives agents an easy way to test WordPress code and makes building and experimenting with WordPress a lot more accessible.”

The WordPress AI agent skill release also introduces a new GitHub repository dedicated to hosting WordPress agent skill. Planned ideas include persistent Playground sites tied to a project directory, running commands against existing Playground instances, and Blueprint generation.

Featured Image by Shutterstock/Here

The Hidden SEO Cost Of A Slow WordPress Site & How It Affects AI Visibility via @sejournal, @wp_rocket

This post was sponsored by WP Media. The opinions expressed in this article are the sponsor’s own.

You’ve built a WordPress site you’re proud of. The design is sharp, the content is solid, and you’re ready to compete. But there’s a hidden cost you might not have considered: a slow site doesn’t just hurt your SEO-it now affects your AI visibility too.

With AI-powered search platforms such as ChatGPT and Google’s AI Overviews and AI Mode reshaping how people discover information, speed has never mattered more. And optimizing for it might be simpler than you think.

The conventional wisdom? “Speed optimization is technical and complicated.” “It requires a developer.” “It’s not that big a deal anyway.” These myths spread because performance optimization is genuinely challenging. But dismissing it because it’s hard? That’s leaving lots of untapped revenue on the table.

Here’s what you need to know about the speed-SEO-AI connection-and how to get your site up to speed without having to reinvent yourself as a performance engineer.

Why Visitors Won’t Wait For Your Site To Load (And What It Costs You)

Let’s start with the basics. When’s the last time you waited patiently for a slow website to load? Exactly.

slow-website

Google’s research shows that as page load time increases from one second to three seconds, the probability of a visitor bouncing increases by 32%. Push that to five seconds, and bounce probability jumps to 90%.

Think about it. You’re spending money on ads, content, and SEO to get people to your site-and then losing nearly half of them before they see anything because your pages load too slowly.

For e-commerce, the stakes are even higher:

  • A site loading in 1 second has a conversion rate 5x higher than one loading in 5 seconds.
  • 79% of shoppers who experience performance issues say they won’t return to buy again.
  • Every 1-second delay reduces customer satisfaction by 16%.

A slow site isn’t just losing one sale. It’s potentially losing you customers for life.

Website Speeds That AI and Visitors Expect

Google stopped being subtle about this in 2020. With the introduction of Core Web Vitals, page speed became an official ranking factor. If your WordPress site meets these benchmarks, you’re signaling quality to Google. If it doesn’t, you’re handing competitors an advantage.

Here’s the challenge: only 50% of WordPress sites currently meet Google’s Core Web Vitals standards.

That means half of WordPress websites have room to improve-and an opportunity to gain ground on competitors who haven’t prioritized performance.

The key metric to watch is Largest Contentful Paint (LCP)-how qhttps://wp-rocket.me/blog/website-load-time-speed-statistics/uickly your main content loads. Google wants this under 2.5 seconds. Hit that target, and you’re in good standing.

What most site owners miss: speed improvements compound. Better Core Web Vitals leads to better rankings, which leads to more traffic, which leads to more conversions. The sites that optimize first capture that momentum.

The AI Visibility Advantage: Why Speed Matters More Than Ever

Here’s where it gets really interesting-and where early movers have an edge.

The rise of AI-powered search tools like ChatGPT, Perplexity, and Google’s AI Overviews is fundamentally changing how people discover information. And here’s what most haven’t realized yet: page speed influences AI visibility too.

A recent study by SE Ranking analyzed 129,000 domains across over 216,000 pages to identify what factors influence ChatGPT citations. The findings on page speed were striking:

  • Fast pages (FCP under 0.4 seconds): averaged 6.7 citations from ChatGPT
  • Slow pages (FCP over 1.13 seconds): averaged just 2.1 citations

That’s a threefold difference in AI visibility based largely on how fast your pages load.

Why does this matter? Because 50% of consumers use AI-powered search today in purchase decisions. Sites that load fast are more likely to be cited, recommended, and discovered by a growing audience that starts their search with AI.

The opportunity: Speed optimization now serves double duty-it boosts your traditional SEO and positions you for visibility in an AI-first search landscape.

How To Improve Page Speed Metrics & Increase AI Citations

Speed, SEO, and AI visibility are now deeply connected.

Every day your site underperforms, you’re missing opportunities.

Your Page Speed Optimization Roadmap

Here’s your action plan:

  1. Audit your current speed.
  2. Identify the bottlenecks.
  3. Implement a comprehensive solution. Rather than patching issues one plugin at a time, use an all-in-one performance tool that addresses caching, code optimization, and media loading together.
  4. Monitor and maintain. Speed isn’t a one-time fix. Track your metrics regularly to ensure you’re maintaining performance as you add content and features.

Step 1: Audit Your Current Website Speed

To best identify where the source of your slow website lies and build a baseline to test against, you must perform a website speed test audit.

  1. Visit Google’s PageSpeed Insights tool.
  2. Compare your Core Web Vitals results scores to your industry’s CWV baseline.
  3. Identify which scores are lowest before moving to step 2.

Step 2: Identify Your Page Speed Bottlenecks

Is it unoptimized images? Render-blocking JavaScript? Too many plugins? Understanding the issue helps you choose the right solution.

In fact, this is where most of your competitors drop the ball, allowing you to pick it up and outperform their websites on SERPs. For business owners focused on running their company, this often falls to the bottom of the priority list.

Why? Because traditional website speed optimization involves a daunting technical website testing checklist that includes, but isn’t limited to:

  • Implementing caching
  • Minifying CSS and JavaScript files
  • Lazy loading images and videos
  • Removing unused CSS
  • Delaying JavaScript execution
  • Optimizing your database
  • Configuring a CDN

Step 3: Implement Fixes & Best Practices

From here, each potential cause of a slow website and low CWV scores can be fixed:

The Easy Way: Use The WP Rocket Performance Plugin

Time To Implement: 3 minutes | Download WP Rocket

Rather than piecing together multiple plugins and manually tweaking settings, you get an all-in-one approach that handles the heavy lifting automatically. This is where purpose-built performance technology can change the game.

The endgame is to remove the complexity from WordPress optimization:

  • Instant results. For example, upon activation, WP Rocket implements 80% of web performance best practices without requiring any configuration. Page caching, GZIP compression, CSS and JS minification, and browser caching are just a few of the many optimizations that run in the background for you.
  • No coding required. Advanced features such as lazy-loading images, removing unused CSS, and delaying JavaScript are available via simple toggles.
  • Built-in compatibility. It’s designed to work with popular themes, plugins, page builders, and WooCommerce.
  • Performance tracking included. Built-in tool lets you monitor your speed improvements and Core Web Vitals scores without leaving your dashboard.

The goal isn’t to become a performance expert. It’s to have a fast website that supports your business objectives. When optimization happens in the background, you’re free to focus on what you actually do best.

For many, shifting tactics can cause confusion and unnecessary complexity. Utilizing the right technology makes implementing them so much easier and ensures you maximize AI visibility and website revenue.

A three-minute fix can make a huge difference to how your WordPress site performs.

Ready to get your site up to speed?

optimize-site-speed-with-wp-rocke

Image Credits

Featured Image: Image by WP Media. Used with permission.

In-Post Images: Image by WP Media. Used with permission.

WP Go Maps Plugin Vulnerability Affects Up To 300K WordPress Sites via @sejournal, @martinibuster

A security advisory was published about a vulnerability affecting the WP Go Maps plugin for WordPress installed on over 300,000 websites. The flaw enables authenticated subscribers to modify map engine settings.

WP Go Maps Plugin

The WP Go Maps plugin is used by local business WordPress sites to display customizable maps on pages and posts, including contact page maps, delivery areas, and store locations. Site owners can manage map markers and map settings without writing code.

The plugin had four vulnerabilities in 2025 and seven vulnerabilities in 2024. Vulnerabilities were discovered in the previous years stretching back to 2019 but not as often.

Vulnerability

The vulnerability can be exploited by authenticated attackers with Subscriber-level access or higher. The Subscriber role is the lowest WordPress permission role. This means an attacker only needs a basic user account to exploit the issue but only if that account level is offered to users on affected websites.

The vulnerability is caused by a missing capability check in the plugin’s processBackgroundAction() function. A capability check is used to verify whether a logged-in user is allowed to perform a specific action. Because this check is missing, the function processes requests from users who do not have permission to change plugin settings.

As a result, authenticated attackers with Subscriber-level access can modify global map engine settings used by the plugin. These settings apply site-wide and affect how the plugin functions across the website.

Wordfence described the vulnerability as an unauthorized modification of data caused by a missing capability check. In practice, this means the plugin allows low-privileged users to change global settings that should be restricted to administrators.

The Wordfence advisory explains:

“The WP Go Maps (formerly WP Google Maps) plugin for WordPress is vulnerable to unauthorized modification of data due to a missing capability check on the processBackgroundAction() function in all versions up to, and including, 10.0.04. This makes it possible for authenticated attackers, with Subscriber-level access and above, to modify global map engine settings”

Any site running an affected version of the plugin with subscriber level registration enabled is exposed to authenticated attackers.

The vulnerability affects all versions of WP Go Maps up to and including version 10.0.04. A patch is available. Site owners are recommended to update the WP Go Maps plugin to version 10.0.05 or newer to fix the vulnerability.

Featured Image by Shutterstock/Dean Drobot

BuddyPress WordPress Vulnerability May Impact Up To 100,000 Sites via @sejournal, @martinibuster

A newly disclosed security vulnerability waffects the BuddyPress plugin, a WordPress plugin installed in over 100,000 websites. The vulnerability, given a threat level rating of 7.3 (high),  enables unauthenticated attackers to execute arbitrary shortcodes.

BuddyPress WordPress Plugin

The BuddyPress plugin enables WordPress sites to create community features such as user profiles, activity streams, private messaging, and groups. It is commonly used on membership sites and online communities and is installed on more than 100,000 WordPress websites.

BuddyPress has a good track record with regard to vulnerabilities. There was only one vulnerability reported for the entire year of 2025, which was a relatively mild medium threat vulnerability, ranked at a 5.3 threat level on a scale of 1-10.

Unauthenticated Arbitrary Shortcode Execution

The vulnerability can be exploited by unauthenticated attackers. An attacker does not need a WordPress account or any level of user access to trigger the issue.

The BuddyPress plugin is vulnerable to arbitrary shortcode execution in all versions up to and including 14.3.3. That means that an attacker can execute shortcodes on the website. Shortcodes are used by WordPress to add dynamic functionality to pages and posts. Because the plugin does not properly validate input before executing shortcodes, attackers can cause the site to run shortcodes they are not authorized to use.

The vulnerability is caused by missing validation before user-supplied input is passed to the do_shortcode function.

Wordfence described the issue:

“The The BuddyPress plugin for WordPress is vulnerable to arbitrary shortcode execution in all versions up to, and including, 14.3.3. This is due to the software allowing users to execute an action that does not properly validate a value before running do_shortcode. This makes it possible for unauthenticated attackers to execute arbitrary shortcodes.”

This means that attackers can trigger a shortcode which in turn will carry out whatever action it is supposed to run, which in the worst case scenario could expose restricted site features or functionality. Depending on the shortcodes available on a site, this can enable attackers to access sensitive information, modify site content, or interact with other plugins in unintended ways.

The vulnerability does not depend on special server settings or optional configurations. Any site running a vulnerable version of the plugin is affected.

The issue was patched in BuddyPress version 14.3.4. Users of the plugin should update to version 14.3.4 or newer to fix the vulnerability.

Featured Image by Shutterstock/Login

10Web WordPress Photo Gallery Plugin Vulnerability via @sejournal, @martinibuster

A security advisory was published about a vulnerability in the Photo Gallery by 10Web plugin that has over 200,000 installations. The vulnerability affects how the plugin handles image comments, exposing some sites to unauthorized data modification by unauthenticated attackers (meaning that attackers do not need to register with the site).

The Photo Gallery by 10Web plugin is used by WordPress sites to create and display image galleries, slideshows, and albums in a variety of layouts. It is used by photography sites, portfolios, and businesses that rely on visual content.

About The Vulnerability

The flaw can be exploited by unauthenticated visitors, meaning anyone can trigger the issue without logging in. This significantly increases exposure because there is no barrier to entry such as having to register with the website or attain a higher permission level.

It is important to note that image comments, where the vulnerability exists, are only available in the Pro version of the plugin. Sites that do not use the comments feature are not affected by this specific issue.

What Went Wrong

The vulnerability is caused by a missing capability check in the plugin’s delete_comment() function.

The plugin does not verify whether a request to delete an image comment is coming from someone who is allowed to perform that action. Normally, WordPress plugins are expected to confirm that a user has the appropriate permissions before modifying site content. That check is missing with this plugin.

Because the plugin fails to perform this verification, it accepts deletion requests even when they come from unauthenticated users.

What Attackers Can Do

An attacker can delete arbitrary image comments from a site. This vulnerability has a severity level rating of 5.3, which is a medium threat level. This vulnerability does not enable a full website takeover or any other server compromise, but it does allow unauthorized deletion of image comments. For sites that rely on image comments for engagement, moderation history, or user interaction, this can result in data loss and disruption.

The official Wordfence advisory explains the vulnerability:

“The Photo Gallery by 10Web – Mobile-Friendly Image Gallery plugin for WordPress is vulnerable to unauthorized modification of data due to a missing capability check on the delete_comment() function in all versions up to, and including, 1.8.36. This makes it possible for unauthenticated attackers to delete arbitrary image comments. Note: comments functionality is only available in the Pro version of the plugin.”

Which Versions Can Be Exploited

The vulnerability affects all versions of the plugin up to and including version 1.8.36.The issue is tied specifically to the comment deletion functionality. Since image comments are only available in the Pro version of the plugin, exploitation is limited to sites running that version with comments enabled.

No special server configuration or user interaction is required beyond the plugin being active and vulnerable.

What Site Owners Should Do

A patch is available. Site owners should update the Photo Gallery by 10Web plugin to version 1.8.37 or later, which includes a security fix addressing this issue. If updating is not possible, disabling the plugin or the comments feature will prevent exploitation until the site can be patched.

Keeping the plugin up to date is the only direct fix for this vulnerability.

Featured Image by Shutterstock/Roman Samborskyi

NotificationX WordPress WooCommerce Plugin Vulnerabilities Impact 40k Sites via @sejournal, @martinibuster

A vulnerability advisory was published for the NotificationX FOMO plugin for WordPress and WooCommerce sites, affecting more than 40,000 websites. The vulnerability, which is rated at a 7.2 (High) severity level, enables unauthenticated attackers to inject malicious JavaScript that can execute in a visitor’s browser when specific conditions are met.

NotificationX – FOMO Plugin

The NotificationX FOMO plugin is used by WordPress and WooCommerce site owners to display notification bars, popups, and real-time alerts such as recent sales, announcements, and promotional messages. The plugin is commonly deployed on marketing and e-commerce sites to create urgency and draw visitor attention through notifications.

Exposure Level

The vulnerability does not require any authentication or acquire any user role before launching an attack. Attackers do not need a WordPress account or any prior access to the site to trigger the vulnerability. Exploitation relies on getting a victim to visit a specially crafted page that interacts with the vulnerable site.

Root Cause Of The Vulnerability

The issue is a DOM-based Cross-Site Scripting (XSS) vulnerability tied to how the plugin processes preview data. In the context of a WordPress plugin vulnerability, DOM-based Cross-Site Scripting (XSS) vulnerability happens when a WordPress plugin contains client-side JavaScript that processes data from an untrusted source (the “source”) in an unsafe way, usually by writing the data to the web page (the “sink”).

In the context of the NotificationX plugin, the vulnerability exists because the plugin’s scripts accepts input through the nx-preview POST parameter, but does not properly sanitize the input or escape the output before it is rendered in the browser. Security checks that are supposed to check that user-supplied data is treated as plain text are missing. This allows an attacker to create a malicious web page that automatically submits a form to the victim’s site, forcing the victim’s browser to execute harmful scripts injected via that parameter.

The end result is that an attacker-controlled input can be interpreted as executable JavaScript instead of harmless preview content.

What Attackers Can Do

If exploited, the vulnerability enables attackers to execute arbitrary JavaScript in the context of the affected site. The injected script executes when a user visits a malicious page that automatically submits a form to the vulnerable NotificationX site.

This can allow attackers to:

  • Hijack logged-in administrator or editor sessions
  • Perform actions on behalf of authenticated users
  • Redirect visitors to malicious or fraudulent websites
  • Access sensitive information available through the browser

The official Wordfence advisory explains:

“The NotificationX – FOMO, Live Sales Notification, WooCommerce Sales Popup, GDPR, Social Proof, Announcement Banner & Floating Notification Bar plugin for WordPress is vulnerable to DOM-Based Cross-Site Scripting via the ‘nx-preview’ POST parameter in all versions up to, and including, 3.2.0. This is due to insufficient input sanitization and output escaping when processing preview data. This makes it possible for unauthenticated attackers to inject arbitrary web scripts in pages that execute when a user visits a malicious page that auto-submits a form to the vulnerable site.”

Affected Versions

All versions of NotificationX up to and including 3.2.0 are vulnerable. A patch is available and the vulnerability was addressed in NotificationX version 3.2.1, which includes security enhancements related to this issue.

Recommended Action

Site owners using NotificationX are recommended to update their plugin immediately to version 3.2.1 or later. Sites that cannot update should disable the plugin until the patched version can be applied. Leaving vulnerable versions active exposes visitors and logged-in users to client-side attacks that can be difficult to detect and mitigate.

One More Vulnerability

This plugin has another vulnerability that is rated 4.3 medium threat level.  The Wordfence advisory for this one describes it like this:

“The NotificationX plugin for WordPress is vulnerable to unauthorized modification of data due to a missing capability check on the ‘regenerate’ and ‘reset’ REST API endpoints in all versions up to, and including, 3.1.11. This makes it possible for authenticated attackers, with Contributor-level access and above, to reset analytics for any NotificationX campaign, regardless of ownership.”

The NotificationX WordPress plugin includes two REST API endpoints called “regenerate” and “reset.” These endpoints are used to manage campaign analytics, such as resetting or rebuilding the stats that show how a notification is performing.

The problem is that these endpoints do not properly check user permissions for modifying data. In this case, the plugin only checks whether a user is logged in with Contributor-level access or higher, not whether they are actually allowed to perform the action. Even though users with the Contributor level role normally have very limited permissions, this flaw lets them perform actions they should not be able to do.

In this case, the damage that an attacker can do is limited. For example, an attacker can’t take over a site. Updated to version 3.2.1 or higher (same as the other vulnerability) will patch this vulnerability.

An attacker can:

  • Reset analytics for any NotificationX campaign
  • Do this even if they did not create or own the campaign
  • Repeatedly wipe or regenerate campaign statistics

Featured Image by Shutterstock/Art Furnace

WordPress Advanced Custom Fields Extended Plugin Vulnerability via @sejournal, @martinibuster

An advisory was published about a vulnerability in the popular Advanced Custom Fields: Extended WordPress plugin that is rated 9.8, affecting up to 100,000 installations.

The flaw enables unauthenticated attackers to register themselves with administrator privileges and gain full control of a website and all settings.

Advanced Custom Fields: Extended Plugin

The Advanced Custom Fields: Extended plugin is an add-on to the popular Advanced Custom Fields Pro plugin. It is used by WordPress site owners and developers to extend how custom fields work, manage front-end forms, create options pages, define custom post types and taxonomies, and customize the WordPress admin experience.

The plugin is widely used, with more than 100,000 active installations, and is commonly deployed on sites that rely on front-end forms and advanced content management workflows.

Who Can Exploit This Vulnerability

This vulnerability can be exploited by unauthenticated attackers, which means there is no barrier of first having to attain a higher permission level before launching an attack. If the affected version of the plugin is present with a specific configuration in place, anyone on the internet can attempt to exploit the flaw. That kind of exposure significantly increases risk because it removes the need for compromised credentials or insider access.

Privilege Escalation Exposure

The vulnerability is a privilege escalation flaw caused by missing role restrictions during user registration.

Specifically, the plugin’s insert_user function does not limit which user roles can be assigned when a new user account is created by anyone. Under normal circumstances, WordPress should strictly control which roles users can select or be assigned during registration.

Because this check is missing, an attacker can submit a registration request that explicitly assigns the administrator role to the new account.

This issue only occurs when the site’s form configuration maps a custom field directly to the WordPress role field. When that condition is met, the plugin accepts the supplied role value without verifying that it is safe or permitted.

The flaw appears to be due to insufficient server-side validation of the form field “Choices.” The plugin seems to have relied on the the HTML form to restrict which roles a user could select. For example, the developer could create a user sign up form with only the “subscriber” role as an option. But there was no verification on the backend to check if the user role the subscriber was signing up with matched the user roles that the form is supposed to be limited to.

What was probably happening is that an unauthenticated attacker could inspect the form’s HTML, see the field responsible for the user role, and intercept the HTTP request so that, for example, instead of sending role=subscriber, the attacker could change the value to role=administrator. The code responsible for the insert_user action took this input and passed it directly to WordPress user creation functions. It did not check if “administrator” was actually one of the allowed options in the field’s “Choices” list.

The Changelog for the plugin lists the following entry as one of the patches to the plugin:

“Enforced front-end fields validation against their respective “Choices” settings.”

That entry in the changelog means the plugin now actively checks front-end form submissions to ensure the submitted value matches the field’s defined “Choices”, rather than trusting whatever value is posted.

There is also this entry in the changelog:

“Module: Forms – Added security measure for forms allowing user role selection”

This entry means the plugin added server-side protections to prevent abuse when a front-end form is allowed to set or select a WordPress user role.

Overall, the patches to the plugin added stronger validation controls for front-end forms plus made them more configurable.

What Attackers Can Gain

If successfully exploited, the attacker gains administrator-level access to the WordPress site.

That level of access allows attackers to:

  • Install or modify plugins and themes
  • Inject malicious code
  • Create backdoor administrator accounts
  • Steal or manipulate site data
  • Redirect visitors or distribute malware

Gaining administrator access is a full site takeover.

The Wordfence advisory describes the issue as follows:

“The Advanced Custom Fields: Extended plugin for WordPress is vulnerable to Privilege Escalation in all versions up to, and including, 0.9.2.1. This is due to the ‘insert_user’ function not restricting the roles with which a user can register. This makes it possible for unauthenticated attackers to supply the ‘administrator’ role during registration and gain administrator access to the site.”

As Wordfence describes, the plugin trusts user-supplied input for account roles when it should not. That trust allows attackers to bypass WordPress’s normal protections and grant themselves the highest possible permission level.

Wordfence also reports having blocked active exploitation attempts targeting this vulnerability, indicating that attackers are already probing sites for exposure.

Conditions Required For Exploitation

The vulnerability is not automatically exploitable on every site running the plugin.

Exploitation requires that:

  • The site uses a front-end form provided by the plugin
  • The form maps a custom field directly to the WordPress user role

Patch Status and What Site Owners Should Do

The vulnerability affects all versions up to and including 0.9.2.1. The issue is addressed in version 0.9.2.2, which introduces additional validation and security checks around front-end forms and user role handling.

The entry for the official changelog for ACF Extended Basic 0.9.2.2:

  • Module: Forms – Enforced front-end fields validation against their respective “Choices” settings
  • Module: Forms – Added security measure for forms allowing user role selection
  • Module: Forms – Added acfe/form/validate_value hook to validate fields individually on front
  • Module: Forms – Added acfe/form/pre_validate_value hook to bypass enforced validation

Site owners using this plugin should update immediately to the latest patched version. If updating is not possible, the plugin should be disabled until the fix can be applied.

Given the severity of the flaw and the lack of authentication required to exploit it, delaying action leaves affected sites exposed to a complete takeover.

Featured Image by Shutterstock/Art Furnace

Head Of WordPress AI Team Explains SEO For AI Agents via @sejournal, @martinibuster

James LePage, Director Engineering AI at Automattic, and the co-lead of the WordPress AI Team, shared his insights into things publishers should be thinking about in terms of SEO. He’s the founder and co-lead of the WordPress Core AI Team, which is tasked with coordinating AI-related projects within WordPress, including how AI agents will interact within the WordPress ecosystem. He shared insights into what’s coming to the web in the context of AI agents and some of the implications for SEO.

AI Agents And Infrastructure

The first observation that he made was that AI agents will use the same web infrastructure as search engines. The main point he makes is that the data that the agents are using comes from the regular classic search indexes.

He writes, somewhat provocatively:

“Agents will use the same infrastructure the web already has.

  • Search to discover relevant entities.
  • “Domain authority” and trust signals to evaluate sources.
  • Links to traverse between entities.
  • Content to understand what each entity offers.

I find it interesting how much money is flowing into AIO and GEO startups when the underlying way agents retrieve information is by using existing search indexes. ChatGPT uses Bing. Anthropic uses Brave. Google uses Google. The mechanics of the web don’t change. What changes is who’s doing the traversing.”

AI SEO = Longtail Optimization

LePage also said that schema structured data, semantic density, and interlinking between pages is essential for optimizing for AI agents. Notable is that he said that AI optimization that AIO and GEO companies are doing is just basic longtail query optimization.

He explained:

“AI intermediaries doing synthesis need structured, accessible content. Clear schemas, semantic density, good interlinking. This is the challenge most publishers are grappling with now. In fact there’s a bit of FUD in this industry. Billions of dollars flowing into AIO and GEO when much of what AI optimization really is is simply long-tail keyword search optimization.”

What Optimized Content Looks Like For AI Agents

LePage, who is involved in AI within the WordPress ecosystem, said that content should be organized in an “intentional” manner for agent consumption, by which he means structured markdown, semantic markup, and content that’s easy to understand.

A little further he explains what he believes content should look like for AI agent consumption:

“Presentations of content that prioritize what matters most. Rankings that signal which information is authoritative versus supplementary. Representations that progressively disclose detail, giving agents the summary first with clear paths to depth. All of this still static, not conversational, not dynamic, but shaped with agent traversal in mind.

Think of it as the difference between a pile of documents and a well-organized briefing. Both contain the same information. One is far more useful to someone trying to quickly understand what you offer.”

A little later in the article he offers a seemingly contradictory prediction of the role of content in an agentic AI future, reversing today’s formula of a well organized briefing over a pile of documents, saying that agentic AI will not need a website, just the content, a pile of documents.

Nevertheless, he recommends that content have structure so that the information is well organized at the page level with clear hierarchical structure and at the site level as well where interlinking makes the relationships between documents clearer. He emphasizes that the content must communicate what it’s for.

He then adds that in the future websites will have AI agents that communicate with external AI agents, which gets into the paradigm he mentioned of content being split off from the website so that the data can be displayed in ways that make sense for a user, completely separated from today’s concept of visiting a website.

He writes:

“Think of this as a progression. What exists now is essentially Perplexity-style web search with more steps: gather content, generate synthesis, present to user. The user still makes decisions and takes actions. Near-term, users delegate specific tasks with explicit specifications, and agents can take actions like purchases or bookings within bounded authority. Further out, agents operate more autonomously based on standing guidelines, becoming something closer to economic actors in their own right.

The progression is toward more autonomy, but that doesn’t mean humans disappear from the loop. It means the loop gets wider. Instead of approving every action, users set guidelines and review outcomes.

…Before full site delegates exist, there’s a middle ground that matters right now.

The content an agent has access to can be presented in a way that makes sense for how agents work today. Currently, that means structured markdown, clean semantic markup, content that’s easy to parse and understand. But even within static content, there’s room to be intentional about how information is organized for agent consumption.”

His article, titled Agents & The New Internet (3/5), provides useful ideas of how to prepare for the agentic AI future.

Featured Image by Shutterstock/Blessed Stock