The SQL injection in the shipping rate calculation endpoint is severe, but the privilege context is the story. A subscriber-level account — essentially a customer with a registered account — can trigger this injection. In WooCommerce's mental model, subscribers are throwaway users, so developers treat any code path they can reach as low-risk surface area. The actual shipping calculation function gets exposed as a universal AJAX handler because no developer expects a customer to manually POST shipping rate requests. The validation lives in the UI flow, not the endpoint. An attacker who understands the request structure — discoverable through source review — walks past the threat model entirely.
This isn't an isolated failure. The pattern (shipping rate endpoint, subscriber context, missing capability check on AJAX handler) has appeared in at least four comparable WooCommerce-related CVEs over the past three years. The fix is consistently the same: add a permission gate like current_user_can('manage_woocommerce') after the fact. That the fix lineage mirrors the vulnerability lineage is diagnostic — we're not discovering novel failure modes, we're rediscovering the same one with different variable names.
The CVSS 8.5 is accurate but masks the real concern. A successful exploit pulls the wp_users table: hashed admin passwords, email addresses, session tokens. In a commerce environment, that data has direct financial value and enables lateral movement to admin accounts controlling payment processing. The EPSS score of 0.00342 doesn't mean this is niche — it reflects that automated tooling doesn't bother fuzzing subscriber-accessible AJAX handlers with SQL payloads because the ecosystem assumes customers aren't threat actors. The absence of mass exploitation is a mapping failure in our scanners, not evidence that the surface is small.
What to do: First, verify whether your WooCommerce installation runs any shipping or calculator extensions and confirm they're on version 2.16.13 or later. Second, audit every subscriber-reachable AJAX handler and REST endpoint in your active plugins — don't assume that because a feature has no subscriber-facing UI, the endpoint itself is protected. Third, add explicit capability checks at the endpoint level for any shipping, pricing, or calculation logic, even if it feels like internal code. The fix pattern is predictable, which means the attack pattern is too.