[wp-trac] [WordPress Trac] #57465: WordPress AJAX Vulnerability

WordPress Trac noreply at wordpress.org
Sun Jan 15 18:24:22 UTC 2023


#57465: WordPress AJAX Vulnerability
---------------------------+----------------------
 Reporter:  allalbenaissa  |       Owner:  (none)
     Type:  defect (bug)   |      Status:  closed
 Priority:  normal         |   Milestone:
Component:  General        |     Version:  6.1.1
 Severity:  normal         |  Resolution:  invalid
 Keywords:                 |     Focuses:
---------------------------+----------------------

Old description:

> The file defines the DOING_AJAX constant, loads the WordPress bootstrap,
> and sets up headers for cross-domain requests. It then checks for a valid
> 'action' parameter in the request and loads the necessary WordPress
> Administration APIs and Ajax handlers.
>
> The file also defines two arrays, $core_actions_get and
> $core_actions_post, which contain a list of allowed actions that can be
> executed via GET and POST requests respectively. These actions include
> various core WordPress functionality such as fetching lists, searching
> for tags, handling image editing, and managing posts, comments, and
> users.
>
> A potential vulnerability in this code could occur if an attacker is able
> to pass an action parameter in the request that is not on the list of
> allowed actions, allowing them to execute arbitrary code on the server.
> However, it's not possible to confirm it without more context.
> Here is an example of how the exploit code from the previous response
> could be written in Python using the requests library:
>
> Copy code
> import requests
>
> url = "http://example.com/wp-admin/admin-ajax.php"
> data = {
>     "action": "eval",
>     "eval": "system('touch /tmp/hacked');"
> }
>
> response = requests.post(url, data=data)
> print(response.text)
>

> This code will send a POST request to the specified URL with the data
> payload containing the action "eval" and the code to be executed on the
> server. The response text will be printed, which could be used to check
> if the code was executed successfully.

New description:

 The file defines the DOING_AJAX constant, loads the WordPress bootstrap,
 and sets up headers for cross-domain requests. It then checks for a valid
 'action' parameter in the request and loads the necessary WordPress
 Administration APIs and Ajax handlers.

 The file also defines two arrays, $core_actions_get and
 $core_actions_post, which contain a list of allowed actions that can be
 executed via GET and POST requests respectively. These actions include
 various core WordPress functionality such as fetching lists, searching for
 tags, handling image editing, and managing posts, comments, and users.

 A potential vulnerability in this code could occur if an attacker is able
 to pass an action parameter in the request that is not on the list of
 allowed actions, allowing them to execute arbitrary code on the server.
 However, it's not possible to confirm it without more context.
 Here is an example of how the exploit code from the previous response
 could be written in Python using the requests library:

 Copy code
 {{{
 import requests

 url = "http://example.com/wp-admin/admin-ajax.php"
 data = {
     "action": "eval",
     "eval": "system('touch /tmp/hacked');"
 }

 response = requests.post(url, data=data)
 print(response.text)
 }}}

 This code will send a POST request to the specified URL with the data
 payload containing the action "eval" and the code to be executed on the
 server. The response text will be printed, which could be used to check if
 the code was executed successfully.

--

Comment (by SergeyBiryukov):

 Replying to [comment:2 allalbenaissa]:
 > Fix: To mitigate this vulnerability, the script should check that the
 action requested is one of the valid actions specified in the
 $core_actions_get and $core_actions_post arrays and only execute the
 action if it is in one of those lists.

 I might be missing something, but this would prevent any custom Ajax
 actions from being registered.

 As noted above, any Ajax actions in WordPress need a corresponding handler
 to be registered in code, which means that [source:tags/6.1.1/src/wp-admin
 /admin-ajax.php?marks=176-178,188,191-193,203#L172 WordPress only runs
 Ajax actions that were expllicitly registered] either by core or by a
 plugin or theme, so arbitratry code cannot be executed this way.

-- 
Ticket URL: <https://core.trac.wordpress.org/ticket/57465#comment:3>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform


More information about the wp-trac mailing list