A critical GiveWP flaw lets unauthenticated attackers execute server commands. Version 4.16.7.2 fixes the PHP object injection chain.

A critical vulnerability in GiveWP, one of the most widely used WordPress plugins for online donations and fundraising, can let an unauthenticated attacker execute commands on the server. Patchstack disclosed the flaw on August 28, after researcher Udin Chan reported it on July 28, and GiveWP fixed it in version 4.16.7.2 released on August 27.

The issue, tracked as CVE-2026-82222 (CVSS score of 10.0), affects GiveWP versions through 4.16.7.1. An attacker doesn’t need an account or user interaction to exploit the underlying vulnerability.

“In versions 4.16.7.1 and below, GiveWP contains an unauthenticated PHP Object Injection vulnerability that can be chained into full remote code execution. On 4.16.5.1 and below a default installation is enough to exploit: it ships with an active manual (Test Donation) gateway and an active offline gateway, and only needs one published donation form.” reads the report published by PatchStack. “No Test Mode, open registration, debug mode, or administrator action is required.”

That description sounds severe because it is. The problem isn’t one isolated coding mistake. Patchstack found a chain involving unsafe handling of serialized PHP objects, a donation workflow that can carry attacker-controlled data into storage, and classes already included in GiveWP that can turn the injected object into command execution.

GiveWP is designed for nonprofits and other organizations that collect donations through WordPress. The plugin handles donation forms, payment gateways, donor information and reporting, so a server running it can hold data that attackers would have plenty of reasons to target.

The root cause of the problem is a helper that GiveWP created to make PHP’s unserialize() safer. It uses PHP’s allowed_classes => false option, which looks like a sensible defense at first glance.

There’s a catch. PHP doesn’t simply throw the serialized object away. Instead, it converts the object into an __PHP_Incomplete_Class placeholder while keeping the original class name and properties.

When GiveWP later serializes that placeholder again, those original object details go back into the serialized data. The application has effectively carried the attacker’s payload forward instead of removing it.

That distinction matters because the malicious object eventually reaches another part of GiveWP that reads the stored data without the same restriction. At that point, PHP can recreate the original object and the rest of the attack chain can continue.

The donation process gives the attacker a way to move that malicious data into GiveWP’s session storage. Patchstack found that the application reads donor information from the user’s account and sends the fields through the supposedly safe unserialization helper.

The attacker-controlled data can therefore survive the first check and reach the wp_give_sessions table. A later request reads the session and processes the serialized object again, this time without the protection that was supposed to stop it.

This is a classic example of why serialization bugs can be difficult to contain. Checking data at one point doesn’t help much if the application later stores that data and processes it differently somewhere else.

The object injection alone doesn’t automatically mean arbitrary command execution. An attacker also needs a gadget chain, meaning existing application code that can be manipulated to turn the injected object into a dangerous operation.

Patchstack found that GiveWP ships code that provides exactly that missing piece. The chain involves the TCPDF library and GiveWP’s own Give\TestData classes, eventually reaching a function call controlled by properties inside the injected object.

“Because loadedProviders is just an array property carried inside the injected object, the attacker sets it to any callable they like.” continues the report. “Pointing it at system() executes an arbitrary OS command as the web server user.”

That means the attacker can turn control of the object into control of what function the application calls. In the vulnerable code, that can lead to execution of an operating system command with the privileges of the web server.

At that point, this stops being a data-handling problem and becomes a server compromise problem. If the WordPress process has access to sensitive files, databases or other internal resources, the impact can extend well beyond the GiveWP plugin itself.

GiveWP’s registration feature ignores WordPress’s users_can_register setting, allowing attackers to create accounts even when registration is disabled. Version 4.16.6 added a nonce check, but attackers can still obtain and reuse the nonce on sites with the public registration shortcode.

Patchstack says versions 4.16.5.1 and earlier are directly exploitable on default installations. Versions 4.16.6–4.16.7.1 reduce the attack surface but leave the underlying flaw exploitable through legacy forms. Version 4.16.7.2 fully fixes the issue.

GiveWP 4.16.7.2 takes a broader approach to fixing the RCE. It blocks serialized data before storage, limits where stored data can be deserialized, hardens the vulnerable gadget and sanitizes donor and billing metadata. It also scans existing database records and removes serialized objects that could contain malicious payloads.

This cleanup matters because updating the code alone cannot remove data already stored by an attacker. Patchstack also found that the earlier 4.16.6 fix could preserve malicious serialized data after detecting __PHP_Incomplete_Class; 4.16.7.2 rejects it instead.

Administrators should update to 4.16.7.2 or later, review logs and signs of compromise, and check older or imported donation forms. The separate registration issue remains unresolved, but Patchstack treats it as an access-control problem rather than part of the patched RCE chain.

Follow me on Twitter: @securityaffairs and Facebook and Mastodon

Pierluigi Paganini

(SecurityAffairs – hacking, GiveWP)

Two CVSS 9.8 miniOrange SAML WordPress plugin auth bypasses were exploited while paid editions never appeared in any vulnerability database. Manual patch required.

Two critical authentication bypass vulnerabilities in the miniOrange SAML 2.0 Single Sign On WordPress plugin, both rated CVSS 9.8, are under active exploitation.

Both CVE-2026-61979 and CVE-2026-15981 allow an unauthenticated attacker to forge a SAML authentication response and arrive in /wp-admin as any existing user, including administrators. The bugs are independent and both have been confirmed exploited in the wild.

CVE-2026-61979 is an algorithm confusion flaw. The plugin trusts the incoming SAML response to declare its own signature algorithm. An attacker sets that algorithm to HMAC-SHA1, which causes the plugin to use the identity provider’s RSA public key as the HMAC secret. The RSA public key is, by definition, public. That’s the whole attack: fetch the key from the metadata endpoint, sign your own forged assertion with it, and the plugin verifies it as genuine.

CVE-2026-15981 is a PHP bug caused by incorrectly handling different types of values. The openssl_verify() function can return three results: 1 when a signature is valid, 0 when it is invalid, and -1 when OpenSSL encounters an error.

The plugin treated the result like a simple true-or-false value. In PHP, -1 counts as true. An attacker can send a specially crafted signature that causes an OpenSSL error, making the function return -1. The plugin then treats it as a valid signature and allows the attacker to log in.

It is a basic coding mistake, but particularly serious because the plugin handles authentication for WordPress admin accounts.

The technical root cause is interesting. What happened around the bugs afterward is more interesting. The miniOrange SAML plugin ships under one WordPress slug, miniorange-saml-20-single-sign-on, but that one listing actually contains seven completely separate product editions, each with its own independent version numbering. Free runs from 3.x to 5.x. Premium runs 11.x to 13.x. Standard runs 15.x to 17.x. VIP editions start at 32.x and 35.x. No two editions share a version range.

When the public advisories were written, they covered only the Free edition, which is the one anyone can download from WordPress.org. The fix for the Free edition landed at 5.4.5.

“While that record is correct, when you apply it to the slug, every paid install carries a higher version number than 5.4.5, so every paid install reads as already patched.” reads Patchstack analysis. “Therefore, any WordPress site that was running a vulnerable version like 16.1.9 reported it as patched, along with every other (13.x, 20.x, 26.x, 32.x, and 35.x) vulnerable version.”

Every database, scanner, and dashboard in the WordPress security ecosystem was telling paid-edition administrators their sites were safe when the exploitable code was still running on their servers.

The update prompt problem makes it worse. Sites running a vulnerable Standard edition 16.x see no available updates in their WordPress admin panel because the fix is on the 17.x line, and WordPress’s built-in update mechanism doesn’t offer cross-line jumps automatically. The path from vulnerable to patched requires a manual plugin upload, which site owners can’t do if they don’t know they’re affected, and every system they rely on was telling them they weren’t.

“There was no advisory to read and no vulnerability database entry flagged the paid edition for these vulnerabilities. The plugin reported itself as fully up to date. In other words, every signal that normally warns of a problem suggested that everything was fine.” continues the report. “So, how did DigitalOcean catch the exploit? It had nothing to do with plugins or versions. An anomalous WordPress administrator session attempt appeared from outside their trusted network and was blocked. The attacker had already used the bypass to obtain a WordPress admin session cookie, but was stalled because the admin panel operations themselves sat restricted behind the trusted network. “

DigitalOcean, the team that found all of this, caught the exploit not through any of those systems but through a network anomaly: an authenticated WordPress administrator session arriving from outside their trusted network perimeter. The attacker had already used one of the auth bypasses to generate a valid admin session cookie. The cookie worked. The session was blocked because the admin panel itself was restricted to trusted network ranges. Defense in depth, doing exactly what it exists to do, on a system where every other detection layer had already failed.

DigitalOcean then traced both bugs to specific lines of code in the plugin and its bundled XML security library, confirmed the affected version ranges across all seven paid editions (which miniOrange had not published anywhere), wrote two narrowly scoped hotfixes to buy time, and handed the full analysis to Patchstack for publication. Patchstack worked with miniOrange to get the complete edition and version matrix, then updated its database with all seven affected ranges, the first time any public database held that information.

Attackers are actively scanning miniOrange SSO endpoints from six IP addresses in Belgium, Nigeria, the U.S. and Germany. The activity appears opportunistic, with attackers checking websites that use the plugin without first identifying the specific version or edition.

That makes the silent patch especially concerning. Attackers can probe systems without knowing what version they run, while website owners may not realize whether their plugin has received the fix.

“Vulnerability databases are only as good as the version data vendors publish publicly. When a vendor runs seven independently numbered editions under one slug and patches six of them without a public advisory, the entire ecosystem downstream of them goes blind at once: databases, scanners, dashboards, and the site admins relying on all three.” concludes the report.

For anyone running this plugin, the full version table per edition is in the Patchstack article. The short version: find your edition, compare your version against the patched column, and expect to do the upgrade as a manual upload rather than through the WordPress dashboard. If you can’t update immediately, two narrowly scoped hotfixes covering both CVEs are published there alongside the IPs to check in your logs for prior exploitation attempts. Check the passkey and admin account list while you’re in there.

Follow me on Twitter: @securityaffairs and Facebook and Mastodon

Pierluigi Paganini

(SecurityAffairs – hacking, miniOrange SAML WordPress Plugin)

StopAndProtect turned nearly 2,000 hacked WordPress sites into a criminal network for malware delivery, data theft, surveillance and ransomware.

Check Point Research uncovered a cybercrime operation, dubbed StopAndProtect, that has turned thousands of hacked WordPress websites into a shared platform for malware delivery, data theft, surveillance and ransomware. The operation is a good reminder that a compromised website isn’t just a problem for its owner. It can become part of someone else’s attack infrastructure.

“StopAndProtect is a newly identified operation that combines file encryption with data theft. The criminals abuse thousands of hacked WordPress websites as their infrastructure – using them to spread the malware, control infected machines, and store stolen documents, screenshots, and activity logs (records created by malware to track its actions, progress, or status during execution).” reads the report published by Check Point.

Researchers first identified the campaign in May 2026. The operation starts with a fake CAPTCHA based on the ClickFix technique: visitors are told to prove they’re human, but the instructions actually push them into copying and running a PowerShell command. From there, the infection unfolds through several downloaders and loaders before deploying different malware components.

StopAndProtect uses a toolkit of different malware rather than a single strain. Its components can encrypt files, steal documents, lock screens and even provide attackers with a chat channel to communicate with victims.

That last point is important because StopAndProtect doesn’t always behave like traditional ransomware. In many cases, the operators first collect file lists and then choose specific files to steal. Encryption or screen locking may come later, depending on what the attackers find and what they want to do with the victim.research.

The criminals used compromised WordPress sites for several jobs at once. The sites hosted malware stages, delivered commands, received logs and stored stolen files. Check Point discovered this because one of the servers exposed a directory listing through a PHP script, revealing more files, logs and open folders than the operators probably intended.

The campaign appears to have reached close to 2,000 compromised WordPress domains. Many of the sites were running old versions of WordPress or outdated plugins, and one site examined by researchers was still using a 2021 version with almost 40 known weaknesses, including SQL injection, authentication bypasses and arbitrary file upload issues.

“In one scenario, we suspect that the malware operator infected themselves and accidentally uploaded some of their desktop files to the collection server. This archive contains the source code of an automation tool for managing injected payloads at scale on compromised WordPress sites.” continues the report. “It also contains a few text files listing close to 2,000 compromised WordPress domains, giving us a hint about the size of the operation.” continues the report.

The infection chain is straightforward enough to understand, even if it becomes more complex after the first step. A visitor sees a fake CAPTCHA, follows the instructions, runs PowerShell, and downloads further stages written in .NET. The malware can then encrypt files, spread through SMB shares and USB devices, steal credentials, capture screenshots, collect selected documents or show a ransom message.

“We first noticed a ransomware family called StopAndProtect in the middle of May 2026. Further analysis of the infrastructure reveals that the infection chain starts with a ClickFix social-engineering technique, which prompts victims to execute a PowerShell command. This leads to two stages of additional downloaders and loaders written in .NET, followed by several main functional components, such as ransomware, SMB/USB worm, LockScreen, VBS spreader, chat utility and credential stealer.” continues the report. “Although the name StopAndProtect was originally given to the ransomware component, we decided to call the whole operation StopAndProtect, as it does not deploy ransomware on all its victims. In many cases, the attackers silently exfiltrate lists of files and later specific files from the infected machines.”

The operators also built tools to manage the infected websites at scale. Check Point found an automation utility that could upload and delete files, enable or disable fake CAPTCHA pages, change redirects and manage additional payloads across the compromised sites. It was written with Visual Basic 6, a technology old enough to have a pension plan, but apparently still useful when the job is mass-managing hacked servers.

The campaign also collected a remarkable amount of victim information. From mid-May to the end of July 2026, researchers found more than 700 archives containing stolen files, passwords, wallet information, screenshots and activity logs. One exposed directory held more than 20,000 screenshot files, while the researchers collected roughly 31,000 screenshots during the monitoring period.

Some of the captured images showed victims’ desktops, browser activity, antivirus windows, ransom messages and lists of encrypted files. The malware could also monitor WhatsApp activity, search for a contact name and capture the person’s details, including a phone number. That moves the campaign well beyond file encryption: it becomes a surveillance operation with a ransomware component attached.research.

Check Point counted more than 6,000 unique IP addresses associated with the campaign by 24 July 2026. The largest groups came from the United States, Russia and India, although IP location does not necessarily identify the victims’ real location or the operators behind the operation.

The WordPress side of the story is familiar. Sites are compromised because owners don’t update the core platform, plugins or themes, or because administrative accounts are protected badly. Once attackers obtain access, they can install hidden must-use plugins that load automatically and create file-upload functions capable of accepting PHP files, which may lead to remote code execution.

For website owners, the basic response is still the right one: update WordPress and every plugin, remove anything unsupported, protect administrator accounts with strong passwords and multi-factor authentication, review installed plugins and check for unexpected PHP files or unfamiliar administrator accounts. Web server logs, outbound connections and recent file changes deserve particular attention if a site may have been compromised.

For visitors, the warning is more specific. A CAPTCHA should not ask someone to open PowerShell, paste a command into a terminal or disable security controls. If a webpage tells you to leave the browser and run instructions on your computer, close it. The CAPTCHA isn’t testing whether you’re human. It’s testing whether you’ll do the attacker’s work for them.

Follow me on Twitter: @securityaffairs and Facebook and Mastodon

Pierluigi Paganini

(SecurityAffairs – hacking, WordPress)

WordPress XSS2Shell flaw enables admin takeover and remote code execution. Users should update to patched versions.

Researchers at Pwn just published a report on a vulnerability chain they’re calling XSS2Shell, and the entry point is quite simple: type a username that doesn’t exist, and WordPress echoes it back with a tiny formatting flaw baked into how two different sanitizers read the same string.

The bug lives in the login page’s error message. When someone submits a username that isn’t registered, WordPress builds an error using that submitted text, after running it through a function meant to strip out any HTML tags. That stripping function relies on PHP’s built-in strip_tags(), which only recognizes a tag if the opening bracket is immediately followed by a letter, no space in between.

That’s the whole crack in the wall. A payload like < area id=ajaxurl>, with a space right after the bracket, sails straight through strip_tags() untouched, because PHP’s parser doesn’t see it as a tag at all. But by the time that string reaches WordPress’s separate sanitizer, wp_kses_post(), a completely different parser that does tolerate that whitespace, it gets interpreted as a legitimate <area> element and rendered as real, live HTML.

“When JavaScript evaluates an identifier that has no binding in the current scope chain, the runtime eventually reaches the window object. The HTML specification (section 7.3.3) defines that the window object exposes “named properties”: any HTML element in the document with an id attribute becomes accessible as window.<id>.” reads the report. “The injected <area id="ajaxurl"> is now the value that the runtime returns for window.ajaxurl.”

From there the researchers found something already sitting on the login page that would interact with injected elements automatically, no click required from a victim. WordPress loads a script meant for the profile page, user-profile.js, on the login page too, purely because the login page also handles password resets. That script watches for a password-reset button and auto-clicks it, and thanks to the injected DOM elements, it finds one that isn’t supposed to exist.

The click event triggers a chain that eventually resolves an undefined JavaScript variable, ajaxurl, using a browser quirk: any HTML element with a matching id attribute automatically becomes accessible as a property on the window object.

The injected <area> element becomes the value assigned by the browser to window.ajaxurl, allowing the attacker to control how the script handles the request.

That’s DOM clobbering, and it’s the pivot that turns a rendering quirk into an actual network request originating from WordPress’s own script.

That request lands on WordPress’s REST API with parameters that trick it into responding as JSONP, wrapping the reply in a callback function name the attacker controls. Because that callback field accepts dots as well as letters, it isn’t limited to calling a single global function, it can walk a full property chain across browser windows. The researchers reused a technique first published in 2022 to turn that into a cross-window click, one that fires inside an actual logged-in administrator’s session rather than the attacker’s own.

Getting from there to full server compromise takes a specific, orchestrated sequence: open a hidden window, navigate the admin’s browser to WordPress’s own application-password approval screen, then trigger the cross-window click on the approve button using the admin’s real session cookies and nonces. That hands the attacker a valid Application Password for the admin account, which WordPress’s REST API happily accepts over HTTP Basic auth from any origin.

“Application Passwords authenticate REST API requests via HTTP Basic auth. WordPress’s REST CORS implementation reflects the requesting origin and permits Authorization and Content-Type headers. The attacker’s page can now make authenticated cross-origin API calls:

” continues the report. “Single-site WordPress administrators have the unfiltered_html capability by default. The script tags survive into the published page exactly as submitted.”

From there it’s a short hop to publishing a page containing attacker JavaScript, since single-site administrators have unrestricted HTML permissions by default, and using that script to upload and execute a plugin containing arbitrary PHP.

The researchers’ proof of concept ended with a plugin file returning a JSON response confirming code execution as the web server user, then cleaned up every trace: the application password revoked, the published page deleted, the plugin directory removed. Nothing persisted, but the point had already been made. This chain works pre-authentication, needs zero user interaction beyond visiting a link, and reliably ends in remote code execution on a stock WordPress install.

“Our proof used a minimal PHP file that wrote a JSON marker and returned a custom header:” concludes the report.”After verification, the PoC went sent WordPress cleaned up after itself: the Application Password was revoked, the published page was deleted, and the plugin directory was removed. Nothing persisted.”

WordPress moved fast once notified. The researchers reported the chain on July 27, and WordPress shipped version 7.0.3 on August 6, backporting the fix all the way to WordPress 4.7 to cover every still-maintained branch. If you’re running WordPress and haven’t updated yet, this isn’t a “get to it next sprint” patch, it’s a “do it before you finish reading this sentence” patch, given how little an attacker actually needs to pull the whole chain off.

Follow me on Twitter: @securityaffairs and Facebook and Mastodon

Pierluigi Paganini

(SecurityAffairs – hacking, XSS2Shell)

U.S. Cybersecurity and Infrastructure Security Agency (CISA) adds DD-WRT, Langflow, and WordPress flaws to its Known Exploited Vulnerabilities catalog.

The U.S. Cybersecurity and Infrastructure Security Agency (CISA) added DD-WRT, Langflow, and WordPress flaws to its Known Exploited Vulnerabilities (KEV) catalog.

Below are the flaws added to the KeV catalog:

• CVE-2021-27137 (CVSS score of 8.1) DD-WRT Stack-Based Buffer Overflow Vulnerability
• CVE-2026-0770 (CVSS score of 9.8) Langflow Inclusion of Functionality from Untrusted Control Sphere Vulnerability  
• CVE-2026-63030 (CVSS score of 9.8) WordPress Core Interpretation Conflict Vulnerability  
• CVE-2026-60137 (CVSS score of 5.9) WordPress Core SQL Injection Vulnerability

The first issue added to the catalog is CVE-2021-27137, a buffer overflow vulnerability affecting DD-WRT before version 45724. The flaw exists in the UPnP handling functionality (ssdp.c) due to an unsafe strcpy operation in the ssdp_msearch function. An unauthenticated remote attacker could exploit the issue by sending a specially crafted M-SEARCH request to trigger a buffer overflow and potentially execute arbitrary code. Exploitation requires UPnP to be enabled, as it is disabled by default and typically limited to internal interfaces.

The second issue added to the catalog is CVE-2026-0770, a critical remote code execution vulnerability affecting Langflow. The flaw exists in the handling of the exec_globals parameter in the validate endpoint, where the application improperly loads functionality from an untrusted control sphere. An unauthenticated remote attacker can exploit the vulnerability to execute arbitrary code with root privileges on affected systems.

Regarding WordPress issues added to the catalog, public proof-of-concept exploits are now available for the critical wp2shell vulnerabilities affecting WordPress Core. The flaws, tracked as CVE-2026-63030 and CVE-2026-60137, can be chained to achieve pre-authentication remote code execution on default WordPress installations running versions 6.9.x and 7.0.x.

CVE-2026-63030 is a REST API batch-route confusion bug introduced in WordPress 6.9. CVE-2026-60137 is a high-severity SQL injection flaw in the author__not_in parameter of WP_Query, affecting.

“The 7.0.2 security release addresses one critical and one high severity security issue.” reads the WordPress announcement.

“Because this is a security release, it is recommended that you update your sites immediately. Due to the severity, the WordPress.org team have enabled forced updates via the auto-update system for sites running affected versions.”

Cybersecurity researchers at Searchlight Cyber discovered the flaws that can allow remote attackers to compromise vulnerable sites without valid credentials, making immediate patching essential.

“Searchlight Cyber’s security research team has discovered a pre-authentication RCE in WordPress Core. The attack has no preconditions and can be exploited by an anonymous user in a stock install of WordPress with no plugins.” reads the advisory. “It is estimated that over 500 million websites use WordPress.”

Researchers withheld technical details to give organizations time to patch, but released an online tool to help administrators check whether their WordPress instances are vulnerable.

According to Binding Operational Directive (BOD) 22-01: Reducing the Significant Risk of Known Exploited Vulnerabilities, FCEB agencies have to address the identified vulnerabilities by the due date to protect their networks against attacks exploiting the flaws in the catalog.

Experts also recommend that private organizations review the Catalog and address the vulnerabilities in their infrastructure.

CISA orders federal agencies to fix these flaws by July 24, 2026, except for CVE-2026-60137, which must be fixed by August 4.

Follow me on Twitter: @securityaffairs and Facebook and Mastodon

Pierluigi Paganini

(SecurityAffairs – hacking, CISA)

Public exploits are now available for two critical WordPress flaws that attackers can chain to gain remote code execution without authentication.

Public proof-of-concept exploits are now available for the critical wp2shell vulnerabilities affecting WordPress Core. The flaws, tracked as CVE-2026-63030 and CVE-2026-60137, can be chained to achieve pre-authentication remote code execution on default WordPress installations running versions 6.9.x and 7.0.x.

CVE-2026-63030 is a REST API batch-route confusion bug introduced in WordPress 6.9. CVE-2026-60137 is a high-severity SQL injection flaw in the author__not_in parameter of WP_Query, affecting.

“The 7.0.2 security release addresses one critical and one high severity security issue.” reads the WordPress announcement.

“Because this is a security release, it is recommended that you update your sites immediately. Due to the severity, the WordPress.org team have enabled forced updates via the auto-update system for sites running affected versions.”

Cybersecurity researchers at Searchlight Cyber discovered the flaws that can allow remote attackers to compromise vulnerable sites without valid credentials, making immediate patching essential.

“Searchlight Cyber’s security research team has discovered a pre-authentication RCE in WordPress Core. The attack has no preconditions and can be exploited by an anonymous user in a stock install of WordPress with no plugins.” reads the advisory. “It is estimated that over 500 million websites use WordPress.”

Researchers withheld technical details to give organizations time to patch, but released an online tool to help administrators check whether their WordPress instances are vulnerable.

Searchlight Cyber’s security research team estimated that over 500 million websites use WordPress. They are releasing a checker so admins can determine whether their instance is vulnerable.

WordPress has enabled forced automatic security updates for affected supported versions because of the severity of the flaws. The full RCE exploit chain affects WordPress versions 6.9.0–6.9.4 and 7.0.0–7.0.1, according to WordPress security advisories.

Site owners should update immediately to WordPress 7.0.2 or 6.9.5, which prevent the exploitation of the wp2shell attack chain.

If patching is not possible, administrators can temporarily reduce risk by blocking anonymous access to the REST API batch endpoint through a security plugin or WAF rules targeting /wp-json/batch/v1 and ?rest_route=/batch/v1.

Searchlight states that these measures are only temporary and may affect legitimate site functions, so updating remains the preferred solution.

Follow me on Twitter: @securityaffairs and Facebook and Mastodon

Pierluigi Paganini

(SecurityAffairs – hacking, newsletter)

Attackers backdoored ShapedPlugin Pro updates, deploying malware that steals credentials, 2FA secrets, and grants full site access.

If you installed a ShapedPlugin Pro plugin between April and June 2026 and kept it updated, your site may be compromised. Not because you did something wrong, but because the vendor’s own build and distribution pipeline was breached. Cybersecurity firm Wordfence confirmed the attack on June 12th after obtaining a backdoored copy of Real Testimonials Pro 3.2.5 directly from ShapedPlugin’s official update endpoint.

ShapedPlugin is a WordPress software company that develops premium and free plugins for WordPress and WooCommerce websites. Founded in 2015, it offers plugins for carousels, galleries, testimonials, weather widgets, accordions, product displays, team showcases, and other website functions. Its products are used by hundreds of thousands of websites worldwide.

The WordPress plugin vendor has over 400,000 active free plugin installations

“During our investigation, we discovered that attackers compromised the vendor’s build and distribution pipeline, injecting backdoor code into Pro plugin releases distributed through official licensed update channels.” reads the report published by Wordfence. “As with all supply chain compromises, this attack is particularly insidious because affected site owners followed security best practices: they purchased legitimate licenses and installed updates directly from the vendor’s official update system. Supply chain compromises are becoming significantly more common in all software, including WordPress software.”

The researchers confirmed that at least three Pro plugins were compromised: Product Slider Pro for WooCommerce, Real Testimonials Pro, and Smart Post Show Pro. Free plugins on WordPress.org were left clean, which was almost certainly deliberate.

The infection runs in two stages. The first is a loader file called LicenseLoader.php that downloads a payload from an attacker-controlled server, installs it as a fake plugin, reports the victim domain back to the attacker, and then deletes itself.

“This self-deleting behavior means the initial infection vector disappears after first execution, complicating forensic analysis for site owners who notice the infection later.” continues the report.

The dropped payload disguises itself as WooCommerce-related plugins, using names like “woocommerce-subscription” in the singular form, one letter away from the legitimate plugin name.

What that payload does once installed is extensive. It hides itself from the WordPress admin plugin list, registers a REST API backdoor that accepts arbitrary file writes, bundles Tiny File Manager and Adminer for direct GUI access to files and databases, and installs a webshell that accepts commands via URL parameters. There’s also a hardcoded login bypass: a single MD5 hash lets the attacker authenticate as any administrator without knowing their password. That’s not a subtle intrusion; that’s a full set of keys.

The malware steals credentials in a more sophisticated way than typical threats.

“What makes this variant particularly concerning is its targeted exfiltration of two-factor authentication secrets. The malware specifically searches for TOTP seeds from multiple 2FA plugins.” continues the report.

Attackers send the stolen passwords and 2FA to generate.2faplugin.org, a domain that blends in with legitimate two-factor traffic. If an attacker has your password and your TOTP seed, changing your password after discovery doesn’t help.

The forensic evidence points to a CI/CD pipeline compromise rather than someone manually tampering with ZIP files. Only four files were modified on May 21st within a two-hour window, consistent with an automated build step. The compromised package also contains git SHA references confirming it was built from a private repository. The attacker had access to deploy updates to both WordPress.org and the Pro distribution system, but only injected malware into some Pro builds — either because WordPress.org scans for malware or because paying customers are higher-value targets. Possibly both.

The C2 infrastructure is registered to AEZA GROUP LLC, tied to Russian-based entities. The exfiltration domain 2faplugin.org was updated on May 10th, about eleven days before the backdoor was injected into Pro builds. Anyone who installed any ShapedPlugin Pro product between April and June 2026 should scan immediately, check for fake plugins under wp-content/plugins/woocommerce-subscription/ or woocommerce-notification/, rotate all WordPress admin passwords, database credentials, and API keys, and, critically, revoke and regenerate 2FA secrets for every user on the site, since existing TOTP seeds should be considered stolen.

“This supply chain attack demonstrates the evolving threat landscape facing WordPress site owners. The attackers did not exploit a vulnerability in the plugin code itself: they compromised the vendor’s build and distribution infrastructure, turning legitimate licensed updates into malware delivery vehicles.” concludes the report. “The inclusion of 2FA secret exfiltration marks a concerning evolution in WordPress-targeted malware.”

Follow me on Twitter: @securityaffairs and Facebook and Mastodon

Pierluigi Paganini

(SecurityAffairs – hacking, ShapedPlugin)