CVE-2026-19613

This is an IDOR in the Elementor Custom Skin plugin's dynamic repeater feature — a function that accepts a post ID parameter and returns custom field values without verifying the requesting user has permission to read that post. The vulnerability affects any authenticated user with contributor role or above, allowing them to read custom fields from private posts, drafts, and other authors' content. The risk extends well beyond the CVSS 6.5 rating. Custom fields in WordPress deployments frequently store credentials — WooCommerce API keys, Mailchimp tokens, payment processor secrets, third-party service authentications. A contributor harvesting custom fields from private drafts isn't reading unpublished content; they're potentially exfiltrating the keys to every connected service the site uses. This creates lateral movement paths that the severity rating doesn't capture. The contributor role is precisely why this matters. Contributors can create posts but cannot publish — they exist in a liminal space where organizations extend trust for content creation while assuming they can't access others' work. The plugin's dynamic repeater bypassed this boundary entirely, treating 'authenticated' as synonymous with 'authorized.' This is a design failure: the function was built as an internal convenience API for fetching post metadata, optimized for developer workflow, and exposed to user-supplied input without translating WordPress's role-based permission model onto it. The fix in version 4.3.10 adds a capability check — likely `current_user_can('edit_post', $post_id)` — but the deeper concern is whether this was a one-off patch or a signal that the plugin's architecture now treats authorization as a first-class concern. The pattern of dynamic post reference retrieval without capability checks is a recurring vulnerability class in WordPress plugins, not an isolated incident. Organizations should audit other plugin features that accept dynamic post references, verify the permission model was explicitly designed rather than assumed, and treat contributor-level access as a meaningful trust boundary that requires independent validation — not just assume the plugin handles it correctly.

Reviewed through automated stages and approved by a human before publication.