Checked as of 5 November 2026. Two WordPress plugin notices published on 4 November deserve attention from a specific group of site owners: WooCommerce shops that use LiteSpeed Cache, and organisations that take donations through GiveWP. Neither notice we reviewed establishes that attackers are exploiting these issues in the wild. That is not proof that nobody is, so treat both as routine but time-sensitive maintenance.

1. LiteSpeed Cache: shoppers’ cart and checkout data served from a shared cache

What it is. Wordfence published CVE-2026-93389 on 4 November for the LiteSpeed Cache plugin (slug litespeed-cache). It affects versions up to and including 7.9.1 and is fixed in 7.9.2. Patchstack lists the same affected and fixed versions. The vendor’s readme now shows 7.9.3 (3 November) as the stable release, but 7.9.2 remains the minimum safe version for this issue. Its 20 October entry for 7.9.2 describes hardened visitor isolation and cache control for private and authenticated responses. That general changelog corroborates cache hardening; the Wordfence notice is the source that ties the fix to this CVE.

Who is actually exposed. You are in scope when all three conditions hold: the plugin is at 7.9.1 or earlier, a working LSCache public cache layer sits in front of the site with the Cache REST option on (it ships enabled), and WooCommerce is installed. Under those conditions, WooCommerce Store API cart and checkout GET responses were stored as public cache objects without varying on the Cart-Token or WooCommerce session. A later visitor with no cookie and no token could receive another shopper’s cached response. Not every installation of the plugin meets all three conditions. Equally, having the plugin installed neither proves nor rules out that responses were shared in the past, and cache objects created by an affected version can remain until they are purged.

Business impact. The cached response can include the other shopper’s billing and shipping name, company, street address, email and phone, their cart contents and totals, a live Cart-Token and nonce that allow hijacking their cart or checkout session, and the order_key on the checkout endpoint. The notice does not describe payment card data as exposed.

What to do.

  • Verify the installed version, and whether your host’s LiteSpeed or QUIC.cloud cache layer actually serves REST routes from cache.
  • Take a backup, check compatibility, then update to 7.9.2 or later.
  • Purge the cache after updating so entries created by the affected version do not linger.
  • Using only your own test accounts, confirm that a cart or checkout response from one session is not returned to a fresh, cookie-less session.
  • If you find evidence that responses were shared, review retained access and cache logs and ask your provider to rotate or invalidate affected sessions under their procedure.

These are prudent owner steps, not vendor-certified remediation or a clearance for every site.

2. GiveWP: a delegated manager could make every new donor an Administrator

What it is. Wordfence published CVE-2026-118193 on 4 November for GiveWP (slug give). It affects versions up to and including 4.19.1 and is fixed in 4.19.1.1, released on 3 November. The vendor’s readme changelog names the CVE and describes added validation for the donor default user role setting.

Who can use it. This requires an authenticated account holding the manage_give_settings capability, which the GiveWP Manager role carries, or higher. Ordinary donors and Subscribers in a default setup do not have this capability and cannot trigger it. Because capabilities can be granted to custom roles, check who actually holds the capability rather than relying on role names alone.

Business impact. Through the normal settings screen, a manager could set the default role for new donors to an elevated non-Administrator role such as Editor. Through the Tools > Import JSON path, validation was skipped entirely, so Administrator could be stored. Donor accounts created after such a change would receive that role. Existing donors are not promoted retroactively.

What to do.

  • Take a backup, check compatibility, then update to 4.19.1.1 or later.
  • Review who holds Manager or higher, and whether each person still needs it.
  • Check the current default donor role setting and any recent settings imports.
  • Review privileged accounts created in recent weeks for anything unexpected.
  • Run a synthetic new-donor registration with your own test account and confirm it lands in the intended low-privilege role. The patch fixes the validation; it does not audit accounts that already exist.

Keeping this routine

Both fixes have been available for days. A tested backup before updating gives you a known-good point to return to if an update misbehaves, and monitoring that goes beyond uptime and pays attention to roles and new accounts gives you something concrete to review against. Neither guarantees that every change will be noticed. If a review turns up something you cannot explain, our guide on what to do when a site is hacked covers the first steps.