EspoCRM CVE-2026-109959

Requires an authenticated EspoCRM account (PR:L) that already holds stream access to the parent record carrying the audit notes; the attacker must be able to enumerate or know the individual Note record IDs and call GET /Note/{id} directly. Exploitation only yields data for fields protected by field-level (field-level security) restrictions on audited fields - it is meaningful only in deployments that actually use field-level security to hide audited fields from lower-privilege users. Limiting factors: no anonymous/unauthenticated access, impact confined to reading historical 'was'/'became' values of restricted fields (no write or availability impact), and affected versions are EspoCRM 4.0.0 up to but not including 10.0.7.

This is a moderate, authenticated information-disclosure flaw (CVSS 4.0 base 5.3, confidentiality-only VC:L with VI:N/VA:N). The vendor-supplied CVSS 4.0 vector (AV:N/AC:L/AT:N/PR:L/UI:N) indicates a network-reachable attack by a low-privileged but already-authenticated user against default behavior, with no user interaction and low attack complexity - consistent with the description, which requires an authenticated account that already has stream access to the parent record. Exploitation status: publicly available exploit code exists (GitHub Security Advisory GHSA-mr36-xx82-qf6h is marked as an exploit reference); this is NOT the same as active exploitation - the CVE is not listed in CISA KEV and no EPSS score was provided, so widespread or automated exploitation cannot be inferred. The signals are internally consistent rather than conflicting: low CVSS, authenticated-only access, limited (single metric) impact, and POC-but-no-KEV all point to this being a real-but-not-urgent issue - a targeted confidentiality leak useful to an insider or a compromised low-privilege account, not a mass-exploitation candidate. Priority should be elevated for deployments where field-level security is actively relied upon to hide sensitive audited fields (e.g., salary, PII) from lower-tier users, and routine otherwise.

An authenticated EspoCRM user who has stream access to a parent record but is not authorized to see certain field-level-secured fields issues GET /Note/{id} directly for an audit stream note. Because this endpoint skips the NoteAccessControl filter, the response returns data.attributes.was and became values, disclosing the restricted field's old and new values. Public exploit/advisory code exists, lowering the skill needed to reproduce.