metasfresh CVE-2026-111351

Requires a valid authenticated low-privilege metasfresh account (PR:L) with access to the web backend REST API; the attacker then invokes the BoardRestController getBoard, getCard, addCard, removeCard, or patchCard handlers supplying board/card record identifiers belonging to other roles or organizations. Exploitation is limited by the need for valid credentials and knowledge or enumeration of out-of-scope record IDs; no user interaction is needed and default configurations are affected, but impact is confined to reading records and changing board card assignments within reach of the REST layer.

This is a genuinely low-priority issue, and the available signals are consistent rather than conflicting. The vendor-supplied CVSS 4.0 vector (AV:N/AC:L/AT:P/PR:L/UI:N/VC:L/VI:L/VA:N) yields a base score of 2.3 (Low), reflecting a network-reachable REST API that nonetheless requires an authenticated low-privilege account (PR:L) and some attack precondition (AT:P), with only limited confidentiality and integrity impact and no availability impact. CWE-639 (authorization bypass through user-controlled key / IDOR) aligns with the description of record-level access-control failure. No EPSS score, SSVC decision, or KEV entry was provided in the input; KEV status is absent and no POC flag was supplied, so exploitation status is: no public exploit identified at time of analysis. A detailed third-party technical write-up (hackmd) and a VulnCheck advisory exist with direct source-code line references, which raises the likelihood that working exploit steps could be reconstructed, but that is not the same as confirmed active exploitation or a published weaponized POC - do not conflate the two. Net: a real but low-severity authorization flaw affecting authenticated insiders, not a widespread remote-unauthenticated emergency.

A legitimate but low-privilege metasfresh user authenticates to the web backend and issues REST calls to the BoardRestController getBoard/getCard/addCard/removeCard/patchCard handlers referencing board and card record IDs belonging to other roles or organizations. Because record-level authorization is not enforced, the user reads data outside their scope and alters board card assignments. No public exploit code was identified, though a technical write-up with source-line references is publicly available.