pH7Builder EUVD-2026-97066

No special conditions beyond running a pH7Builder (pH7 Social Dating CMS) instance before version 19.3.0 - the flaw is reachable remotely and unauthenticated (PR:N) against default configurations because PFBC Form::isValid() trusts a client-chosen form ID (the $_POST submit field) rather than the actual target form. Exploitation specifically requires the attacker to first load any CAPTCHA-free form (e.g., login or search) to obtain a valid form ID, then submit that ID with contact, comment, forum, invite, or signup data. Limiting factors: impact is confined to bypassing CAPTCHA/anti-automation on these public forms (VI:L) - there is no resulting data disclosure, authentication bypass, or code execution, so realistic harm is spam and automated-abuse rather than system compromise.

This is a moderate-severity anti-automation control bypass, not a high-impact breach. The CVSS 4.0 vector (AV:N/AC:L/AT:N/PR:N/UI:N) confirms remote, low-complexity, unauthenticated reachability, but the impact is deliberately scoped low: VI:L with VC:N and VA:N means the only consequence is unauthorized integrity effects (automated form submissions / abuse), with no confidentiality loss and no availability impact - consistent with CWE-807 (reliance on an untrusted client-supplied form ID in a security decision). No EPSS score, KEV listing, or public POC was provided, so there is no signal of active or widespread exploitation; the only code artifact is the vendor FIX commit (4758d7d), which is a patch, not an exploit. Net: this is a real but low-urgency issue - easy to trigger and useful for spammers/scrapers against pH7Builder sites, but it does not grant account takeover, data access, or code execution. The 'Authentication Bypass' tag somewhat overstates it; the flaw bypasses CAPTCHA/form validation, not authentication itself, so decision-makers should treat it as an abuse/spam-prevention gap rather than an access-control breach.

An attacker programmatically requests a CAPTCHA-free pH7Builder form (such as login or search) to obtain a valid form ID, then replays that ID alongside signup, contact, comment, forum, or invite payloads so that PFBC Form::isValid() accepts the submission without a CAPTCHA check. This lets them script mass fake-account registration, comment/contact spam, and invite abuse against a default installation. No public exploit code was provided, but the technique is straightforward to automate given the low attack complexity.