CVE-2026-65574 in the Abogado WordPress plugin is an unauthenticated PHP Object Injection vulnerability with a 9.8 CVSS score—the 'unauthenticated' qualifier is the critical detail that elevates this from a privilege escalation issue to a remote code execution vector reachable by anyone with network access to the site.
The vulnerability stems from the plugin calling unserialize() on data that an unauthenticated attacker can control. This is not a theoretical risk; PHP's unserialize() has been a documented exploitation vector since 2009, and the WordPress plugin ecosystem has seen countless instances of this exact pattern. The Abogado plugin—a legal practice tool handling potentially privileged communications—makes the blast radius particularly concerning: compromise of this plugin could expose attorney-client communications, litigation strategy, and case management integrations typical in legal software.
What you should do: First, verify whether the patch removes unserialize() entirely from the affected code path or merely adds input validation. A complete removal (refactoring to JSON or a safe serialization library) eliminates the vulnerability class architecturally. A sanitization layer leaves the door open for bypasses through different gadget chains. Second, audit the plugin for other unserialize() calls—even deprecated functions or legacy AJAX endpoints that appear 'replaced' may still exist in the codebase and be executable. Third, consider the plugin's position in your trust architecture: if Abogado sits adjacent to case management or client portals, treat a compromise as a pivot point rather than an isolated application breach.
The systemic pattern here matters. This is not an isolated failure but the latest entry in a seventeen-year lineage of PHP Object Injection vulnerabilities in WordPress plugins. The root cause—developers assuming stored data is pre-validated and safe for deserialization—persists because no forcing function in the plugin ecosystem stops it. Patching this instance is necessary; auditing your deployed stack for the same pattern is what actually reduces risk.