Description

The Frontend Admin by DynamiApps plugin for WordPress is vulnerable to Privilege Escalation in all versions up to, and including, 3.29.9. The vulnerability exists because `ActionUser::conditions_logic()` gates the `current_user_can('edit_user', $user_id)` authorization check behind an `is_numeric()` test, causing the check to be skipped entirely when `$user_id` is a non-numeric string — a condition that can be induced by passing a crafted value such as `1one` through the unvalidated `item_id` parameter of the unauthenticated `wp_ajax_nopriv_frontend_admin/forms/change_form` AJAX endpoint. This makes it possible for attackers to escalate privileges to administrator by obtaining a server-signed `_acf_objects` payload carrying the non-numeric user ID, which WordPress subsequently coerces to integer 1 (the default administrator), allowing the attacker to overwrite that account's password or email address. Exploitation by unauthenticated users requires a public-facing frontend user form to be configured; in all other cases a subscriber-level account is sufficient.

Executive Summary

Technical Details

Mitigations

References

Additional Metadata

{
  "score": "9.8",
  "pubDate": "2026-08-16T05:16:48.307Z",
  "pubdate": "2026-08-16T05:16:48.307Z",
  "executiveSummary": "The Frontend Admin by DynamiApps plugin for WordPress is vulnerable to an arbitrary privilege escalation flaw affecting all versions up to, and including, 3.29.9.\nThe security defect stems from improper input validation and type coercion handling within the authorization logic of the plugin.\nAn unauthenticated or low-privileged attacker can exploit this vulnerability to modify administrative account details, such as passwords or email addresses, effectively achieving full administrative takeover of the WordPress site.\nThe vulnerability manifests through the unauthenticated wp_ajax_nopriv_frontend_admin/forms/change_form AJAX endpoint, which passes an unvalidated item_id parameter.\nDepending on the configuration, exploitation may require a public-facing frontend user form or a subscriber-level account.\nGiven the severity of potential account takeovers and system compromise, immediate remediation is critical to prevent malicious privilege escalation.",
  "technicalDetails": "The vulnerability resides in the ActionUser::conditions_logic() function within the Frontend Admin by DynamiApps plugin, which handles authorization checks for user modification actions.\nThe root cause of the vulnerability is flawed conditional logic that gates the execution of the critical current_user_can('edit_user', $user_id) authorization check behind an is_numeric() validation test.\nWhen a non-numeric string, such as a crafted value like 1one, is supplied via the unvalidated item_id parameter of the unauthenticated wp_ajax_nopriv_frontend_admin/forms/change_form AJAX endpoint, the is_numeric() check fails.\nBecause the check evaluates to false, the authorization verification is bypassed entirely, allowing unauthorized execution to proceed without validating whether the requesting user possesses administrative privileges.\nThe attack flow proceeds as follows: an attacker interacts with the unauthenticated AJAX endpoint, injecting a carefully crafted non-numeric string into the item_id parameter.\nThis manipulates the internal handling of the target user identifier, allowing the attacker to obtain a server-signed _acf_objects payload carrying the non-numeric user ID.\nSubsequently, WordPress performs type coercion, casting the non-numeric string to integer 1, which typically corresponds to the default primary administrator account.\nThis coercion allows the attacker to execute unauthorized administrative actions, specifically overwriting the targeted account's password or email address.\nAuthentication requirements vary based on site configuration; exploitation requires a public-facing frontend user form to be configured for unauthenticated users, while a baseline subscriber-level account is sufficient in all other deployment scenarios.\nThe network exposure is broad due to the reliance on a publicly accessible AJAX endpoint, and the post-exploitation impact results in complete administrative compromise of the underlying WordPress installation."
}