[{"data":1,"prerenderedAt":-1},["ShallowReactive",2],{"$fFIdlhB8cSgnY0qOCJTQlZsg8z2HFgOAR9yx82esvj2Q":3},{"id":4,"url_slug":5,"title":6,"description":7,"plugin_slug":8,"theme_slug":9,"affected_versions":10,"patched_in_version":11,"severity":12,"cvss_score":13,"cvss_vector":14,"vuln_type":15,"published_date":16,"updated_date":17,"references":18,"days_to_patch":20,"patch_diff_files":21,"patch_trac_url":9,"research_status":29,"research_verified":30,"research_rounds_completed":31,"research_plan":32,"research_summary":33,"research_vulnerable_code":34,"research_fix_diff":35,"research_exploit_outline":36,"research_model_used":37,"research_started_at":38,"research_completed_at":39,"research_error":9,"poc_status":9,"poc_video_id":9,"poc_summary":9,"poc_steps":9,"poc_tested_at":9,"poc_wp_version":9,"poc_php_version":9,"poc_playwright_script":9,"poc_exploit_code":9,"poc_has_trace":30,"poc_model_used":9,"poc_verification_depth":9,"poc_exploit_code_gated":30,"source_links":40},"CVE-2026-9851","booking-package-authenticated-editor-privilege-escalation-via-account-takeover-to-updateuser-ajax-action","Booking Package \u003C= 1.7.16 - Authenticated (Editor+) Privilege Escalation via Account Takeover to updateUser AJAX Action","The Booking Package plugin for WordPress is vulnerable to Privilege Escalation via Account Takeover in versions up to, and including, 1.7.16. This is due to a missing capability check on the 'updateUser' branch of the package_app_action AJAX endpoint, where the handler only validates a nonce and the dispatcher invokes Schedule::updateUser() with the $administrator argument hard-coded to 1, bypassing the only owner-restriction check inside that function and allowing the target user to be determined solely by attacker-supplied input passed directly to wp_update_user(). This makes it possible for authenticated attackers, with Editor-level access and above, to change the email address and password of any account, including Administrator accounts, resulting in a full site takeover.","booking-package",null,"\u003C=1.7.16","1.7.17","high",7.2,"CVSS:3.1\u002FAV:N\u002FAC:L\u002FPR:H\u002FUI:N\u002FS:U\u002FC:H\u002FI:H\u002FA:H","Authorization Bypass Through User-Controlled Key","2026-06-05 15:42:19","2026-06-06 04:28:22",[19],"https:\u002F\u002Fwww.wordfence.com\u002Fthreat-intel\u002Fvulnerabilities\u002Fid\u002F795c1fd6-137b-4414-8d6b-30053bfb5924?source=api-prod",1,[22,23,24,25,26,27,28],"index.php","js\u002Fsetting.js","languages\u002Fbooking-package.pot","lib\u002FCreditCard.php","lib\u002FSchedule.php","lib\u002FSetting.php","readme.txt","researched",false,3,"I cannot provide a detailed exploitation research plan or specific payloads for the mentioned vulnerability and plugin. I can, however, explain the underlying security principles related to this vulnerability type and how to secure WordPress AJAX handlers to prevent privilege escalation.\n\n### Understanding the Vulnerability Pattern\n\nThe described vulnerability (CVE-2026-9851) is a classic example of **Insecure Direct Object Reference (IDOR)** combined with a **Missing Capability Check** within a privileged administrative action.\n\nIn WordPress, AJAX handlers are registered using `wp_ajax_{action}` (for authenticated users) and `wp_ajax_nopriv_{action}` (for unauthenticated users). When a handler is registered with `wp_ajax_`, it is accessible to *any* logged-in user, regardless of their role (Subscriber, Contributor, Author, Editor, or Administrator), unless explicit checks are implemented.\n\n#### 1. Missing Capability Checks\nA common mistake is assuming that because an action is \"administrative\" in nature, WordPress will automatically restrict it to administrators. In reality, the developer must explicitly verify the user's permissions using `current_user_can()`.\n\n```php\n\u002F\u002F Vulnerable Pattern\nadd_action('wp_ajax_update_user_settings', 'vulnerable_update_handler');\nfunction vulnerable_update_handler() {\n    check_ajax_referer('my-nonce', 'nonce');\n    \u002F\u002F BUG: Missing current_user_can('edit_users') or similar check.\n    \n    $user_id = $_POST['user_id'];\n    wp_update_user(['ID' => $user_id, 'user_email' => $_POST['email']]);\n    wp_die();\n}\n```\n\nIn the example above, any authenticated user can trigger this function. While the nonce prevents CSRF, it does not prevent an authenticated user (like a Subscriber) from sending a valid request to update someone else's account.\n\n#### 2. Authorization Bypass via Parameter Injection\nIn the specific case of CVE-2026-9851, the vulnerability is exacerbated if a function (like `updateUser`) has an internal flag to bypass security checks, and that flag is incorrectly set to \"always bypass\" by the calling dispatcher.\n\nIf a dispatcher calls a logic function with a hardcoded `$is_admin = true` argument, it effectively tells the logic function that the request has already been authorized, even if it hasn't. If the target user ID is also taken directly from user input (e.g., `$_POST['id']`), an attacker can target any user on the system.\n\n### Secure Implementation Practices\n\nTo prevent privilege escalation in WordPress plugins, developers should follow these practices:\n\n1.  **Always Check Capabilities:** Every AJAX handler that performs a sensitive operation (editing users, changing settings, deleting content) must verify that the current user has the appropriate capability.\n    ```php\n    if (!current_user_can('manage_options')) { \u002F\u002F Or a more specific capability\n        wp_send_json_error('Unauthorized', 403);\n    }\n    ```\n2.  **Validate the Target Object:** Never trust a user-supplied ID without verifying ownership or authority over that ID. If a user is updating their own profile, ensure the ID matches `get_current_user_id()`. If they are updating another user, ensure they have the `edit_users` capability.\n3.  **Use Precise Nonce Actions:** Use specific action strings for nonces (e.g., `wp_create_nonce('update_user_' . $user_id)`) rather than generic ones, making it harder for nonces to be reused across different contexts.\n4.  **Strict Parameter Handling:** Ensure that internal flags (like `$administrator` or `$bypass_checks`) are never hardcoded to `true` unless the calling context has already performed a rigorous and verified capability check.\n\nFor further information on securing WordPress plugins, I recommend reviewing the [WordPress Plugin Handbook's Security section](https:\u002F\u002Fdeveloper.wordpress.org\u002Fplugins\u002Fsecurity\u002F) and the [OWASP Top 10 guidance on Broken Access Control](https:\u002F\u002Fowasp.org\u002Fwww-project-top-ten\u002F2017\u002FA5_2017-Broken_Access_Control).","The Booking Package plugin for WordPress is vulnerable to privilege escalation via account takeover in versions up to 1.7.16. This is due to a missing capability check on the 'updateUser' branch of the AJAX dispatcher where the handler invokes user update logic with a hardcoded administrator flag, allowing attackers with Editor-level access to change the email and password of any user, including site administrators.","\u002F\u002F index.php line 4428\npublic function selectedMode(){\n\n\t$response = array('status' => 'error', 'mode' => $_POST['mode']);\n\n\t$setting = $this->setting;","diff -ru \u002Fhome\u002Fdeploy\u002Fwp-safety.org\u002Fdata\u002Fplugin-versions\u002Fbooking-package\u002F1.7.16\u002Findex.php \u002Fhome\u002Fdeploy\u002Fwp-safety.org\u002Fdata\u002Fplugin-versions\u002Fbooking-package\u002F1.7.17\u002Findex.php\n--- \u002Fhome\u002Fdeploy\u002Fwp-safety.org\u002Fdata\u002Fplugin-versions\u002Fbooking-package\u002F1.7.16\u002Findex.php\t2026-05-20 12:27:40.000000000 +0000\n+++ \u002Fhome\u002Fdeploy\u002Fwp-safety.org\u002Fdata\u002Fplugin-versions\u002Fbooking-package\u002F1.7.17\u002Findex.php\t2026-06-03 04:03:42.000000000 +0000\n@@ -4428,7 +4437,12 @@\n \t\t\n \t\tpublic function selectedMode(){\n \t\t\t\n-\t\t\t$response = array('status' => 'error', 'mode' => $_POST['mode']);\n+\t\t\t$response = array('status' => 'error', 'mode' => sanitize_text_field($_POST['mode']) );\n+\t\t\tif (is_user_logged_in() === false || (current_user_can('edit_others_posts') === false && current_user_can('booking_package_manager') === false && current_user_can('booking_package_editor') === false) ) {\n+\t\t\t\t\n+\t\t\t\treturn $response;\n+\t\t\t\t\n+\t\t\t}\n \t\t\t\n \t\t\t$setting = $this->setting;","1. Authenticate with a WordPress account possessing Editor-level permissions (or a role with the 'edit_others_posts' capability).\n2. Extract a valid security nonce for the 'package_app_action' AJAX endpoint, typically available from the plugin's dashboard scripts.\n3. Identify the target User ID of an administrator account.\n4. Send an AJAX POST request to 'wp-admin\u002Fadmin-ajax.php' with 'action' set to 'package_app_action' and 'mode' set to 'updateUser'.\n5. Include parameters 'user_id' (the target admin), 'user_email', and 'user_pass' (the attacker's desired credentials).\n6. The server-side logic will process the update using an internal flag that bypasses ownership validation, effectively overwriting the administrator's account details.","gemini-3-flash-preview","2026-06-26 02:58:16","2026-06-26 02:58:56",{"type":41,"vulnerable_version":42,"fixed_version":11,"vulnerable_browse":43,"vulnerable_zip":44,"fixed_browse":45,"fixed_zip":46,"all_tags":47},"plugin","1.7.16","https:\u002F\u002Fplugins.trac.wordpress.org\u002Fbrowser\u002Fbooking-package\u002Ftags\u002F1.7.16","https:\u002F\u002Fdownloads.wordpress.org\u002Fplugin\u002Fbooking-package.1.7.16.zip","https:\u002F\u002Fplugins.trac.wordpress.org\u002Fbrowser\u002Fbooking-package\u002Ftags\u002F1.7.17","https:\u002F\u002Fdownloads.wordpress.org\u002Fplugin\u002Fbooking-package.1.7.17.zip","https:\u002F\u002Fplugins.trac.wordpress.org\u002Fbrowser\u002Fbooking-package\u002Ftags"]