Fat Free CRM EUVD-2026-105166

Requires a valid authenticated Fat Free CRM account (CVSS PR:L); any user role suffices, no admin or ownership relationship to the target data is needed, and no user interaction is required. The vulnerable code path is the default behavior in versions before 0.26.0 - no special feature flag or non-default setting is needed. Practical exploitation also requires a multi-user deployment where other users' comments exist to target, and comment IDs being sequential/enumerable (as noted in the description) makes discovery trivial. The authentication requirement is the primary limiting factor that keeps this out of the remote-unauthenticated category.

This is a CWE-639 insecure direct object reference rated CVSS 4.0 5.3 (Medium) via vendor-supplied vector CVSS:4.0/AV:N/AC:L/AT:N/PR:L/UI:N/VC:N/VI:L/VA:L. The signals are internally consistent and point to a genuine but bounded issue: attack is network-based with low complexity and no user interaction, but PR:L confirms a valid authenticated account is required, so this is not a remote-unauthenticated break. Impact is limited to integrity and availability of comment data (VI:L/VA:L) with no confidentiality loss (VC:N) and no scope change - an attacker tampers with or deletes other users' comments, not the underlying CRM records themselves. No EPSS score, no CISA KEV listing, and no public exploit were provided in the intelligence, so there is no public exploit identified at time of analysis and no evidence of active exploitation; however, the attack technique (enumerating sequential IDs and sending PUT/DELETE to /comments/:id) is trivial to weaponize for anyone with an account. Net: a real, easily-triggered authorization flaw but a moderate-priority one given the authentication requirement, limited blast radius, and low real-world deployment of the product - patch on a normal cycle rather than as an emergency unless running a multi-tenant instance with untrusted users.

A low-privileged but authenticated Fat Free CRM user iterates over sequential comment IDs and issues PUT or DELETE requests to /comments/:id, editing or deleting comments attached to contacts, accounts, leads, and opportunities owned by other users. Because CommentsController#update and #destroy call an unscoped Comment.find with no ownership check, the requests succeed. No public exploit was identified, but the technique requires only a standard HTTP client and ID enumeration.