Booking Package CVE-2026-105997

The site must run the Booking Package plugin at a version before 1.7.33 with its booking verification-code email workflow reachable, which is the default behavior of the booking feature. Exploitation requires no authentication, no user interaction, and no non-default configuration (AV:N/AC:L/PR:N/UI:N). What limits real-world impact: the attacker gains no code execution, data access, or site modification - the only outcome is the site sending templated verification-code emails to attacker-chosen recipients, so harm is confined to email abuse, sender-reputation damage, and mail-resource consumption rather than compromise of the host.

This is a genuinely low-to-moderate priority issue, and the signals are consistent rather than conflicting. The CVSS 3.1 vector (AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:L, base 5.3) correctly reflects remote, low-complexity, unauthenticated access with no confidentiality or integrity impact and only a limited availability/resource impact - the flaw lets an attacker make the server send templated verification-code emails, not compromise the site. EPSS reinforces low real-world risk at 0.15% (4th percentile), and there is no CISA KEV listing (not actively exploited) and no confirmed public exploit code. The vuln.today decision label is 'this_month', i.e. a routine patch item rather than act_now/emergency. The one caveat worth flagging: the PR:N / 'unauthenticated' claim rests on the vendor-supplied CVSS vector, which aligns with the description's 'unauthenticated users' wording, so authentication status is confirmed by that vector. Overall this is a high-reach-but-low-impact abuse-of-functionality bug (missing authorization, CWE-862), not a high-CVSS-but-overrated critical.

An attacker remotely and without authentication sends crafted requests to the plugin's booking verification-code endpoint, supplying arbitrary recipient email addresses and causing the victim's site to deliver templated verification-code emails to those addresses. Because the recipient is not bound to server-side state, this can be abused to send unsolicited email from the trusted site (spam/annoyance, potential phishing lure, or sender-reputation damage) or to exhaust mail-sending resources. No public exploit identified at time of analysis; the trigger mechanism beyond 'triggering verification-code emails' is not detailed in the available sources.