The CVSS 7.5 on CVE-2026-19728 is functionally misleading, and you should adjust your prioritization accordingly. This is an unauthenticated file access vulnerability in a WordPress plugin that exposes WooCommerce customer files—order-related uploads tied to product customization. The reason the score doesn't hold up is straightforward: the plugin ships a compensating control (.htaccess deny-all rules in upload directories) that neutralizes the vulnerability on Apache servers but does nothing on nginx defaults, misconfigured Apache, or any setup behind a reverse proxy or CDN.
Here's what actually matters for your environment. If you're running Apache with standard WordPress hosting, this vulnerability is effectively neutralized—the .htaccess file blocks the attack vector. If you're running nginx (particularly default configurations common in managed hosting), or if your WordPress instance sits behind Cloudflare, AWS CloudFront, or any permissive proxy layer, you're in the real exposure window. The attack isn't limited to guessing valid filenames either: WooCommerce order IDs follow predictable sequential or timestamp patterns. An attacker can enumerate order IDs systematically and harvest thousands of customer files without authentication—this isn't typical IDOR, it's identifier-discovery.
But the deeper problem is the remediation itself. The .htaccess file is not a code fix. It doesn't survive Docker rebuilds from Dockerfiles, it gets wiped during hosting migrations from Apache to nginx, it vanishes when managed hosting auto-scales, and no scanner tracks whether it still exists six months after the CVE is marked resolved. The underlying code still lacks authorization checking. The CVE closes, your scanner says mitigated, and the only thing standing between you and active exploitation is an orphaned config file that nobody is monitoring.
Your action items: verify whether your upload directories actually have .htaccess deny-all rules and confirm those rules are being honored by your server configuration. If you're behind a reverse proxy or CDN, the local .htaccess is irrelevant—you need to enforce access control at the proxy layer or implement proper endpoint authorization in the plugin itself. Audit your deployment pipeline to ensure .htaccess files survive infrastructure changes. If you've migrated hosting providers in the past two years, re-verify the protection is still in place. The EPSS score of 0.00216 suggests actual exploitation is rare, but that likely reflects the large Apache population already protected—not the absence of risk for the nginx and proxy-configured population where this remains exploitable.