LogChimp EUVD-2026-115905

Requires an authenticated LogChimp account with privileges to author posts (PR:L) - not exploitable unauthenticated. The attacker must also know or enumerate the UUID (id) of a victim's post. The attack is performed against the PATCH /api/v1/posts API by supplying mismatched body parameters: postId set to a post the attacker owns (which passes the ownership check in postExists.ts/updatePost.ts) and id set to the victim post's UUID, which pre-fix was used as the actual update target. Limiting factors: valid authentication plus ownership of at least one post, and knowledge of victim post UUIDs; affected deployments are LogChimp 0.9.0-alpha.1 through 0.9.2 (fixed in 0.9.3). There is no confidentiality impact - the flaw enables tampering/overwrite of other users' post fields only.

This is a genuine but not emergency-grade priority. The supplied CVSS 4.0 vector (AV:N/AC:L/AT:N/PR:L/UI:N/VC:N/VI:H/VA:L) scores 7.1 (High): network-reachable API, low attack complexity, no user interaction, and only low privileges needed, with high integrity impact and minor availability impact but no confidentiality impact. The barrier is PR:L - an attacker must hold an authenticated post-author account, which on any LogChimp instance that allows open self-registration is a trivially low bar, consistent with the vendor 'this_week' priority rather than 'act_now'. Countervailing signals point away from mass exploitation: the CVE is not listed in CISA KEV (no confirmed active exploitation), no EPSS score is present in the input so exploitation probability cannot be quantified, and no public exploit code is identified. The fixing commit and VulnCheck advisory do, however, fully document the mechanism (trusting req.body.id as the update target while authorizing on postId), lowering the effort to reproduce. Net: a credible authenticated-tampering/defacement risk warranting prompt patching, but absent KEV/EPSS data there is no evidence of widespread or automated exploitation.

An authenticated LogChimp user who owns at least one post enumerates another user's post UUID, then sends a PATCH request to the /api/v1/posts endpoint with postId set to their own post and id set to the victim's UUID; the server authorizes on the attacker-owned postId but writes to the victim post, overwriting its title, slug, content, boardId and roadmap_id. The attack is network-reachable with low complexity and no user interaction, needing only a low-privileged post-author account. No public exploit code is identified, though the vendor fixing commit and the VulnCheck advisory describe the mechanism in detail.