MacCMS v10 CVE-2026-116214

Exploitation requires that MacCMS v10's member password-recovery flow be reachable - i.e., the findpass_msg/findpass_reset endpoints and an email or SMS code-delivery channel are configured and enabled - which is a standard part of the member system. No authentication, user interaction, or special privileges are needed (PR:N/UI:N). The only practical prerequisites are: the target must be an existing registered member, and the attacker must know the victim's registered email address or phone number to supply as the reset identifier. The defect is present in default behavior on all versions before 2026.1000.4054; upgrading to that build is the fix, as the patch adds the recipient-binding and single-use-code checks.

This is a genuine high-priority issue, not an inflated high-CVSS score. The vendor-supplied CVSS 4.0 vector (AV:N/AC:L/AT:N/PR:N/UI:N) describes fully remote, unauthenticated, low-complexity exploitation with no attack requirements, and the source diff confirms the mechanism: check_msg() never bound the recovery code to its intended recipient (msg_to), so any code the attacker legitimately receives validates against any victim. The vuln.today decision label is act_now and the flaw was reported by VulnCheck, both reinforcing priority. However, several real-world signals are MISSING from the input and should not be fabricated: no EPSS exploitation-probability score is provided, CVE is NOT listed as CISA KEV, and no confirmed public exploit code is indicated. So exploitation is highly plausible (the description is effectively a step-by-step recipe and the logic flaw is trivial) but not independently confirmed as occurring in the wild. The impact is scoped to account takeover (VC:H/VI:H, VA:N) - confidentiality and integrity of member accounts, with no direct availability impact. Net: treat as urgent because of trivial unauthenticated account takeover and a confirmed patch, while noting that widespread active exploitation is not evidenced by the supplied data.

An unauthenticated attacker with a working MacCMS v10 member-recovery endpoint requests a password-recovery code to their own email or phone via user/findpass_msg, receives a valid code, then calls user/findpass_reset supplying that same code together with a victim's email or phone. Because check_msg() does not verify the code was issued to the victim, the reset succeeds and the attacker sets a new password for the victim's account. No special skill or exploit tooling is required given AV:N/AC:L/PR:N/UI:N; no public exploit code is identified at time of analysis, though the advisory description fully details the technique.