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
A critical unauthenticated command injection vulnerability (CVE-2025-9501) in the W3 Total Cache WordPress plugin allows attackers to achieve remote code execution by submitting malicious PHP code through public comments, affecting all versions prior to 2.8.13.
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
@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!)
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