Balbooa Forms CVE-2026-67363

The Balbooa Forms Joomla extension must be installed at a version below 2.4.3.2 with at least one form configured to use Stripe (via the stripeCharges endpoint) or Authorize.net (via the payAuthorize endpoint) for live payment processing, and that form must be published and accessible to unauthenticated visitors. No authentication, valid session, or CSRF token is required - exploitation is open to any anonymous visitor on the public internet. There are no platform-specific, OS-specific, or non-default Joomla configuration requirements. Exploitation is limited to financial fraud (arbitrary charge amounts, forged line items, quantities, and shipping); it does not grant server access, code execution, or data exfiltration. Sites without any payment-enabled Balbooa forms are not affected.

The CVSS 4.0 vector (AV:N/AC:L/AT:N/PR:N/UI:N/VC:N/VI:N/VA:N/SC:N/SI:H/SA:N, score 7.7) accurately captures the risk profile: fully remote, no complexity, no privileges, no interaction, with high integrity impact on the downstream payment system (subsequent system). The VC/VI/VA:N metrics correctly reflect that the Joomla host itself is not directly compromised - the damage is purely financial, manifesting as fraudulent transactions against the merchant's payment processor account. No EPSS score, KEV listing, or POC code was included in the intelligence data. Despite the absence of a KEV entry, the practical exploitation risk is elevated: the attack requires no authentication, no special tooling, and is directly financially motivated - conditions that historically attract automated fraud tooling. The CSRF tag indicates this was reported partly in the context of session-based forgery, but the primary and more severe risk is the unauthenticated price-tampering path, which does not require CSRF at all. The score of 7.7 is appropriate; a merchant running this plugin on a live storefront faces direct revenue loss with zero barriers to exploitation.

An attacker browses to a Joomla site running Balbooa Forms < 2.4.3.2, adds a product to a payment form, and intercepts the outbound POST request using a proxy tool such as Burp Suite. The attacker modifies the charge amount parameter to 0.01 (or any arbitrary value) and replays the request directly against the stripeCharges or payAuthorize endpoint - no session token, CSRF token, or authentication header is required. The payment gateway processes the tampered total and the attacker receives the purchased item having paid a fraction of a cent.