myCred CVE-2026-114698

Requires an authenticated low-privileged account on a WordPress site with the myCred plugin active (PR:L); on sites with open user registration, any registered subscriber qualifies. Exploitation hinges on supplying a user-controlled key/object identifier that the plugin uses to select a record without verifying that the record belongs to the requesting user, so the attacker references another user's object. Limiting factors: authentication is mandatory (not exploitable by fully anonymous attackers per the CVSS vector), impact is confined to integrity and availability of affected records with no confidentiality exposure, and only versions up to and including 4.0.0-beta.1 are affected. The exact feature/endpoint carrying the vulnerable parameter is not specified in the available sources.

This is a moderate-severity authorization/IDOR flaw (CWE-639) in the myCred WordPress plugin, scored CVSS 5.4 (CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:N/I:L/A:L). The signals are internally consistent and point to a real-but-not-urgent issue: the attack vector is network-based with low complexity and no user interaction, but it requires authenticated privileges (PR:L), which limits it to attackers who hold a valid low-privileged account on the target site. Impact is bounded - confidentiality is unaffected (C:N) with only low integrity and availability impact (I:L/A:L) - so this is not a site-takeover or data-exfiltration primitive. The vuln.today decision label is 'this_month' (not act_now/emergency), aligning with the moderate CVSS. No EPSS score, no CISA KEV listing, and no public exploit were provided in the input, so there is no evidence of active exploitation or weaponization; this is a priority to patch on a normal cycle rather than an emergency. The main gap is mechanistic: the description does not specify which exact object reference or endpoint is abused, so the precise exploitation surface should be confirmed against the Patchstack advisory.

An attacker who holds a low-privileged authenticated account (e.g., a subscriber on a site with open registration) manipulates a user-controlled identifier in a myCred request so that it references another user's object instead of their own, bypassing the intended access-control check. Because the key is attacker-controlled and the server fails to verify ownership, they can tamper with records tied to other users, producing limited integrity and availability impact (I:L/A:L). No public exploit code was identified in the input, so exploitation would require crafting the request from the described IDOR behavior.