SerpBear EUVD-2026-114110

No authentication, user interaction, or special privileges are required (PR:N/UI:N) - any remote party who can reach a SerpBear instance earlier than 3.1.1 can POST to /api/notify against a default configuration. The key LIMITING factor is that meaningful impact (SMTP exhaustion, provider abuse flags, recipient flooding) only materializes when the instance has working email/SMTP notification settings configured and the endpoint is network-reachable (e.g. internet-exposed); an instance with no SMTP configured or one isolated behind authentication-gating infrastructure yields little effect. Impact is confined to availability and email-abuse (VA:L); there is no path to data disclosure or modification.

This is a genuine but moderate-priority issue, not a high-severity emergency. The CVSS 4.0 score of 6.9 (Medium) reflects an availability-only impact (VA:L) with no confidentiality or integrity loss (VC:N/VI:N) - the flaw is a missing-authentication abuse-of-functionality bug, not code execution or data exposure. The attack is trivially easy on paper: AV:N/AC:L/AT:N/PR:N/UI:N means a remote, unauthenticated attacker can hit the endpoint over the network against a default install with a simple HTTP POST, and the root cause is confirmed by the patch diff (verifyUser() was not called in pages/api/notify.ts). Countervailing signals keep real-world risk contained: there is no CISA KEV listing and no EPSS score in the supplied data, so there is no evidence of active or widespread exploitation; the vuln.today decision label is 'this_month' (routine patching), not act_now/emergency; and no public exploit code is referenced. The practical ceiling on damage is that the worst outcome is SMTP rate-limit exhaustion, email-provider abuse flags, and recipient inbox flooding - a nuisance/denial-of-service and reputational-abuse problem rather than a compromise. Net: patch on a normal monthly cadence, prioritizing instances that are internet-exposed and have working SMTP/notification settings configured.

An attacker who can reach an internet-exposed SerpBear instance below 3.1.1 sends repeated unauthenticated POST requests to /api/notify (optionally with a domain parameter), each of which triggers notification emails because authentication is never enforced. By looping these requests the attacker exhausts the configured SMTP account's sending limits, trips the email provider's abuse detection, and floods the configured recipients' inboxes. No public exploit code is referenced, but the trigger is a single trivial HTTP request requiring no special tooling.