CVE-2026-16282

The CVSS 5.3 score for CVE-2026-16282 badly understates the real risk. This isn't a parameter tampering issue—it's a complete collapse of server-side price authority in a booking plugin that treats pricing as client-submitted data rather than server-controlled configuration. The plugin knows what each service costs through its own configuration, yet it accepts whatever number the client transmits. One POST request with a modified price parameter is all it takes. No authentication, no account compromise, no prerequisites. The 'corrupting booking and payment records' language in the CVE description is the analytically important part that the CVSS misses. When an attacker can write arbitrary values to the authoritative price field, they don't just steal a single booking—they compromise the data integrity of the entire record-keeping system. Financial reports become unreliable. Audit trails become worthless. More critically, this corrupted booking data feeds downstream systems: payment processor reconciliation, accounting ledgers, tax reporting pipelines. Each of those systems treats the booking record as trusted input. A single manipulated entry creates inconsistency across every system that touches it. This multiplicative effect on the transaction ledger is what makes this vulnerability architecturally significant, not just the individual fraud opportunity. The unauthenticated attack surface amplifies this into a scalable fraud pipeline. Attackers don't need to compromise accounts or socially engineer anyone—they automate the POST request and book unlimited services at zero cost. The pattern is well-established in the attacker community; shopping cart price manipulation, tip jar exploits, and event registration tampering all follow the same genetic sequence. This isn't a novel exploit for anyone who's seen one instance. Detection is difficult precisely because the corruption is structural. Transaction-level anomaly detection misses this because the system expects to receive prices—the anomaly is the intended behavior. Negative or zero price flags help, but the reliable detection mechanism is reconciliation against server-side service configuration: does this price match what the plugin itself knows this service costs? That check was never implemented, and it needs to happen both at booking time and retrospectively across historical records. Post-incident reconciliation catches damage after the ledger is already corrupted. For immediate action: audit your booking plugins to confirm they perform server-side price lookup by service ID and reject any client-supplied price field entirely. If you're running this specific plugin, disable it or implement compensating controls until a patch materializes—and be aware that many WordPress booking plugins exist in states of abandonment with no security updates coming. The vulnerability doesn't need a sophisticated attacker; it needs a single automated request.

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