This vulnerability isn't an oversight—it's a design failure. Pluck CMS's file upload handler uses a blacklist approach to block dangerous PHP extensions, checking only the last 4-5 characters of filenames. When PHP 8 shipped, '.php8' naturally slipped through because the blacklist predated it. But here's what makes this worth your attention: the code requires developers to enumerate every dangerous extension that exists now and will exist in the future, perfectly and perpetually, against attackers actively searching for what they missed. That's not achievable human work—it's structurally impossible, and the pattern of '.php3', '.php4', '.php5', '.php6', '.php7', '.php8' across CMSes proves it.
The authenticated-admin prerequisite changes the severity assessment in ways that cut both ways. On one hand, it means this isn't an unauthenticated remote entry point—exploitation requires compromising an admin account first. On the other hand, admin credentials are routinely obtained through credential stuffing, XSS, session hijacking, and plugin vulnerabilities across CMS platforms. If you're already treating admin compromise as a realistic attack path (and you should), this CVE simply provides the execution vehicle once they arrive. The CVSS 7.2 rating reflects the technical access requirement but may understate the cascade risk in multi-site or multi-admin deployments where admin access is a pivot point to broader systems.
What you should do: First, patch this specific gap by ensuring '.php8' and related variants ('.phar', '.pht') are blocked. Second, recognize that application-level blacklisting is a losing strategy long-term—it will fail again with '.php9' or new variants. The durable fix is architectural: store uploads outside the webroot entirely, serving them only through authenticated, access-controlled application endpoints. This moves your security model from "enumerate every dangerous extension" to "ensure your access control logic is correct," which is a much more tractable problem. If that's not feasible in your deployment, at minimum configure your web server to deny PHP execution in upload directories—but be aware this may not be possible on shared hosting where you lack config access.
The broader lesson: any system that relies on maintaining a comprehensive threat blacklist under sustained adversarial pressure is already compromised by design. Consider whether whitelist-based file handling fits your workflow, even if it imposes stricter constraints on legitimate users.