Kritische Befehls‑Injection‑Lücke im WordPress‑Plugin W3 Total Cache

Eine schwerwiegende Sicherheitslücke (CVE‑2025‑9501, CVSS‑Score 9.0) wurde im beliebten WordPress‑Caching‑Plugin W3 Total Cache entdeckt. Sie ermöglicht Remote‑Code‑Execution – das heißt, Angreifer können beliebige Befehle auf dem Server ausführen, ohne sich vorher authentifizieren zu müssen.

#wordpress #plugin #w3totalcache #infosec #infosecnews #RemoteCodeExecution

https://beyondmachines.net/event_details/critical-command-injection-flaw-reported-in-w3-total-cache-wordpress-plugin-c-x-1-7-2/gD2P6Ple2L

Security researchers reveal a severe flaw in the #W3TotalCache plugin for #WordPress

The vulnerability is tracked as CVE-2024-12365, and when exploited, can expose potentially sensitive data. The plugin is believed to be installed on over 1 million WordPress sites.

Administrators are advised to patch ASAP

#cybersecurity

https://www.bleepingcomputer.com/news/security/w3-total-cache-plugin-flaw-exposes-1-million-wordpress-sites-to-attacks/

#WordPress-Plug-in #W3TotalCache: Potenziell 1 Millionen Websites attackierbar | Security https://www.heise.de/news/WordPress-Plug-in-W3-Total-Cache-Potenziell-1-Millionen-Websites-attackierbar-10246228.html #WordPressPlugin #CMS #ContentManagementSystem #Patchday

Encore une #faille dans un plugin #WordPress : 1 million de sites exposés à des fuites de données.
Une #vulnérabilité importante a été découverte dans le plugin #W3TotalCache, module très utilisé par les abonnés #WP pour améliorer les performances de leurs #sitesweb.
https://www.clubic.com/actualite-550556-encore-une-faille-dans-un-plugin-wordpress-1-million-de-sites-exposes-a-des-fuites-de-donnees.html

The results of a deep dive, spending probably way too much time in this, but that's what we do when the stakes are low: #WordPress #ActivityPub and #caching, in particular #W3TotalCache. https://gergely.imreh.net/blog/2023/02/when-wordpress-caching-is-not-what-it-seems/

Plot thickens with #WordPress #ActivityPub and #W3TotalCache #W3TC plugins interactions. Seems like W3TC's #nginx config is subtly wrong for me multiple ways so it didn't actually direct caching (and it was red herring to modify it, wasting me a an hour or two), but W3TC's internal code redirects to the right generated on-disk file after all (so that's why the "caching" seemed to have worked even with emptied nginx config).

@arnandegans so the plugin would need to tell somehow the whole #WordPress instance (or just #W3TotalCache?) not to cache the authors' about page. (when it receives a regular query, return the HTML version, if "application/activity+json" type the the plugin take care of it.

It's an interesting proposition whether that plugin could set up that behaviour. I wonder if it's something down this line: https://wordpress.org/support/topic/disable-caching-for-a-specific-page/ (and thanks for the hint, it seems promising!)

@evantd what sort of settings change this would be? I'm using #nginx and #W3TotalCache adds its own config to it (as a generated file that is imported by the main nginx setup). Looking at it, no headers or accepted file types related logic in there.
Any other hints about what do you mean?

Using #WordPress with the #ActivityPub plugin and seems like it's not playing well with #W3TotalCache, as the author page that should return an ActivityPub author JSON for an author page, just being cached (not bothering about the "Accept" header).

Solved it by just exempting the `/author/.+` paths from caching, but it is not satisfying, the cache plugin should be able to handle these things.

Also, I have no clue whether it will make any difference for @gergely at all :P

This weird #W3TotalCache #WordPress bug cropped up again on another new post. https://arnesonium.com/2022/09/wordpress-returning-404-errors