baserCMS EUVD-2026-108986

Exploitable only against a mail form created in the baserCMS admin that contains a field of type 'Email' for which the separate optional 'VALID_EMAIL' server-side format check is NOT enabled - which is the default state for newly created email-type fields - and that form must be published publicly. The bundled 'Contact' form is explicitly NOT affected because its email field has VALID_EMAIL set and rejects comma-containing values server-side. The practical limiting factor is that the attacker must bypass the client-side HTML type=email validation by sending a crafted request directly (trivial with any HTTP tool); no authentication, no admin access, and no victim/user interaction are required. Observed recipient count reached at least 5 per submission; no hard code-level cap on recipients was confirmed by the reporter.

This is a genuine but moderate-severity abuse issue, not a system-compromise priority. The provided CVSS 3.1 vector (AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:L/A:N, 5.3) is internally consistent with the description: a remote, unauthenticated attacker can trigger it over the network against an affected public form with no user interaction, but the only impact is a low integrity effect (the site is coerced into sending unsolicited mail in its own name) with no confidentiality or availability loss. The vuln.today Decision label is 'this_month' (not act_now/emergency), which aligns with a mail-relay/spam-abuse problem rather than code execution. No CISA KEV entry and no EPSS score are present in the input, so there is no signal of active or widespread exploitation - exploitation status is therefore 'no public exploit identified' in the strict KEV sense, however the GHSA advisory itself documents concrete reproduction steps (confirmed by the reporter on 5.4.0, delivering to 5 recipients in one submission), so a public PoC reference exists; it is not verified as packaged working exploit code. The main conflicting/nuanced signal: CVSS rates integrity as Low and keeps scope Unchanged, yet the real-world harm (sender-domain reputation damage, third parties receiving site-branded mail) partly lands on systems outside the application, which some analysts would score as a scope change - treat the 5.3 as a floor for the reputational/business risk. Overall this is a 'patch on a normal cycle' issue, elevated only for sites running custom (non-bundled) mail forms.

An attacker finds a publicly published baserCMS mail form built in the admin with an 'Email'-type field that lacks the optional VALID_EMAIL server-side check (the default for new fields), and submits a crafted request - bypassing the browser's type=email check - with the email field set to 'victim1@a.com,victim2@b.net,victim3@c.org'. The server splits the value on commas and addresses a single auto-reply, sent from the site's own identity and domain with partially attacker-controlled body content, to all of those third parties. The GHSA advisory documents this reproduction (5 recipients confirmed in one submission), so a public PoC reference exists; it is not verified as packaged working exploit code.