CamaleonCMS EUVD-2026-57412

Requires a low-privileged authenticated account on the CamaleonCMS instance (PR:L) and the ability to reach the contact-form edit endpoint, whose missing authorization control is the enabling defect. The injected payload only fires when a victim loads a page that renders the cama_contact_form with the poisoned before_html field, so victim interaction is required (UI:A) - a higher-privileged user such as an administrator must view the form for session-takeover impact to materialize. Limiting factors: the cama_contact_form plugin must be present and in use, the attacker must already possess a form-editing-capable account, and deployments that only grant such accounts to fully trusted staff, or disable the plugin, largely neutralize the risk.

The CVSS 4.0 score of 9.2 (AV:N/AC:L/AT:N/PR:L/UI:A/VC:H/VI:H/SC:H/SI:H) is high, but several signals temper the raw number and one inflates it. Real exploitation requires an authenticated foothold (PR:L) and a victim to actually load the contact form (UI:A/passive interaction), so this is not a drive-by unauthenticated compromise - it is a privilege-escalation/session-hijack primitive usable by anyone who already holds a low-privileged account on the CMS. That said, the impact is genuine: stealing or riding an administrator's session effectively yields full CMS control, which is why integrity and subsequent-system metrics are rated high. No EPSS score is provided, there is no CISA KEV listing, and no working exploit code is flagged - only a detailed public writeup - so weaponization is plausible but not demonstrated. The CWE-89/description mismatch means anyone triaging by CWE alone (e.g. a team hunting only for SQLi) could misroute this; treat it as XSS. Overall this warrants prompt patching for any deployment that grants form-editing or comparable low-tier accounts to semi-trusted users, while single-admin private installs face lower practical exposure.

A low-privileged authenticated user submits a crafted before_html value containing a script payload to the contact-form edit endpoint, which fails to enforce authorization, storing the payload in the database. When an administrator later opens the page where the contact form renders, the script runs in the admin's browser, exfiltrating session cookies or silently issuing authenticated requests against the admin interface. A public technical writeup describing the flaw exists, but no confirmed working exploit code is listed.