CVE-2026-66447

This CVE is an unauthenticated SQL injection in file upload functionality at CVSS 9.3, but the severity rating is the least interesting thing about it. What's值得关注 is that this vulnerability class has been documented in WordPress plugins since at least 2011-2012, and the same $_FILES-to-SQL pattern keeps appearing. You're not looking at a novel attack — you're looking at a failure of knowledge transfer that has persisted across a decade of published advisories, WPScan entries, and security blog posts explaining exactly how not to handle uploaded filenames in database queries. The practical implications break down into two tiers. First, immediate detection: audit your WordPress plugins for any upload handler that constructs queries using $_FILES data without $wpdb->prepare() or parameterized statements. The vulnerable pattern is trivial to spot — direct concatenation of $_FILES['upload']['name'] or related superglobal indices into query strings. Second, understand the blast radius. One SQL injection in a WordPress plugin doesn't just compromise that plugin's data — WordPress's shared-namespace architecture means database access often reaches wp_options, wp_users, and serialized plugin configurations used by other plugins on the same installation. The typical escalation path runs SQL injection → database write access → plugin settings modification → stored XSS in admin panels → credential harvesting on the next admin login. That's three CVEs worth of chained impact from a single entry point, none of it requiring sophistication. The ecosystem-level concern is the temporal gap. This plugin reached version 5.1.7 without anyone catching the flaw, which suggests the vulnerability shipped in an earlier minor version through refactoring that stripped out or broke parameterization — a disturbingly common pattern in plugin development where upload handlers get modified to support new metadata fields without re-examining the query layer. The 'workflow failure' framing is accurate: no static analysis, security linting, or peer review step was rigorous enough to catch direct query construction with file upload data. If you're maintaining WordPress plugins: treat every byte of uploaded content as adversarial, extend your input sanitization mental model beyond $_GET and $_POST to include $_FILES, and audit any legacy upload handlers for dynamic table names or serialized metadata that might complicate prepared statement usage — that's usually where parameterization gets dropped.

Reviewed through automated stages and approved by a human before publication.