CRMEB EUVD-2026-70481

Exploitation requires a valid authenticated user account on the CRMEB instance (PR:L). The attacker needs network access to the API endpoint at /api/v1/user/message/edit_message. No administrative privileges are required - any registered user account suffices. The vulnerability is present in all CRMEB deployments running version 6.0.0 or earlier and is not gated on any non-default configuration. Exploitation is limited to message metadata manipulation (soft-delete, read-status, uid reassignment) and cannot be leveraged directly for remote code execution or credential disclosure. The primary limit on impact is that the attacker must enumerate or guess valid message IDs, which the SSVC 'Automatable: no' rating reflects.

The CVSS 4.0 score of 5.3 (AV:N/AC:L/AT:N/PR:L/UI:N/VC:N/VI:L/VA:L) accurately reflects the constrained scope: exploitation requires a valid account (PR:L), and the impact is limited to integrity and minor availability disruption against messaging data - no confidentiality breach is achieved and no broader system compromise is possible through this vector alone. SSVC rates Technical Impact as 'partial' and Automatable as 'no', which is consistent with the need for authenticated account access and per-victim targeting. The GitHub issue #120 confirms POC exists, elevating the practical exploitation risk slightly above theoretical. No KEV listing is present. The combination of low barrier once authenticated, a public reproducer, and no available patch makes this a moderate-priority finding for multi-tenant or SaaS CRMEB deployments where untrusted authenticated users exist. Single-tenant private deployments face minimal real-world risk.

An authenticated CRMEB user registers a standard account, then iterates over plausible message IDs in crafted POST requests to the edit_message API endpoint, setting is_del=1 on each to soft-delete system notifications belonging to other users - for example, suppressing account-compromise alerts sent to an administrative user. The public GitHub issue #120 provides enough implementation detail to construct such a request without further reverse engineering.