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)