Welcome to **_Part 1_** of the **WordPress Security Research Beginner Series**! If you haven’t had a chance, please review the [series introduction blog post]() for more details on the goal of this series and what to expect. Before diving into the security features of WordPress, it's critical to understand the underlying request architecture. WordPress is a dynamic system that processes and responds to user requests in various ways, depending on the nature of the request and the context in which it's made. By understanding this request-response pattern, we can better comprehend how plugins and themes integrate into WordPress core and how to access and trigger code that may contain vulnerabilities. We hope that by providing this beginner series on WordPress vulnerability research, you’ll in turn take the knowledge you’ve gained and use it to participate in the [Wordfence Bug Bounty Program](), where you can earn up to $10,400 for each vulnerability reported, with the mission of helping make WordPress a more secure ecosystem. ## Understanding Requests in WordPress WordPress is a web application. That means, at its core, it's built to handle HTTP requests and return responses. This interaction handles everything from rendering pages to performing administrative actions in the backend. ### The Request Lifecycle 1. **Initial Request:** Everything starts when the server receives an HTTP request. This could be a simple GET request for a page or a POST request submitting form data. 2. **WordPress Core Loading:** WordPress initializes its core, loading the necessary components to handle the request, including plugin and theme files. 3. **Routing:** WordPress determines what the request is trying to access—be it a post, a page, an admin panel, or an AJAX call—and routes the request accordingly. 4. **Hooks and Execution:** This stage of the WordPress request lifecycle is where the core, along with themes and plugins, actively engage with the incoming request. WordPress core and themes predominantly use hooks — actions and filters — to alter outputs and execute operations. These hooks are predefined points in the WordPress code where plugins and themes can intervene to modify behavior or add new functionality. 5. **Response:** Finally, WordPress sends a response back to the client, which could be an HTML page, a JSON payload, or a simple status code. ![The WordPress Request Lifecycle](https://www.wordfence.com/wp-content/uploads/2024/06/wordpress_request_lifecycle.png) The WordPress Request Lifecycle ### WordPress Core Request Handling When most requests hit a WordPress site, they are first intercepted by the `[index.php]()` file in the webroot directory. This file is the controller for all front-of-site WordPress requests. It loads the `[wp-blog-header.php]()` file, which in turn loads the `[wp-load.php]()` file to initialize the WordPress environment and template. All WordPress requests result in `[wp-load.php]()` being executed in some way or another. [![WordPress Request Flow](https://www.wordfence.com/wp-content/uploads/2024/06/wordpress_request_flow.png)]() WordPress Request Flow From here, WordPress decides what to do based on the request. #### Request Routing **Front-End Requests:** For front-end requests, WordPress uses the Rewrite API to interpret the URL and determine which content to serve. The [Rewrite API]() transforms user-friendly URLs into query variables that WordPress understands. **REST API Requests:** These requests are routed through index.php to the [REST API]() handler. The REST API allows external applications to interact with your WordPress site and allows functions to execute without WordPress requiring a page reload. **Admin Requests:** Admin requests are directed to files within the `wp-admin` directory. By default, these requests go to `wp-admin/index.php`, which handles the administration dashboard. Files in the `wp-admin` directory load `wp-load.php` independently from the front of site, either directly, or indirectly by including a file that then loads `wp-load.php`. For example, AJAX requests are processed by `wp-admin/admin-ajax.php` which loads `wp-load.php`. Each of these entry points uses hooks to allow plugins and themes to modify the request or the response. [![WordPress Request Routing](https://www.wordfence.com/wp-content/uploads/2024/06/wordpress_request_routing_final.png)]() WordPress Request Routing ## Hooks and How They Relate to Requests WordPress plugin architecture is largely based on its hook system. A **_hook_** (a.k.a. function hook) is simply a way to inject third-party functionality (like plugin code) into existing code so edits to core code do not need to be made. WordPress implements two types of hooks: **_actions_** and **_filters_**. These hooks allow WordPress plugin and theme developers to add functionality or change WordPress' default behavior without editing WordPress core files. ### Actions _[Actions]()_ are hooks that WordPress core launches at specific points during execution, or when certain events occur. If you're familiar with JavaScript, WordPress actions are similar to event listeners that you might add to elements on a webpage. Just as you can set up a listener to run a function when a user clicks a button, WordPress actions allow you to execute custom code at certain points in the WordPress request-response lifecycle, such as when a post is saved or a page is rendered. Plugins can register custom PHP functions to these hooks, which are executed when the hook is called. Here's how actions work: **Definition:** Actions are defined by the _do_action()_ function call in the WordPress core. When the core wants to allow an action to be hooked, it calls this function. **Registration:** Plugins and themes register their custom functions to hooks using the _add_action()_ function, specifying the hook name and the function to be called. **Execution:** When the _do_action()_ call is reached during WordPress's execution, all functions hooked to that action are executed in the order they were added. Here is what that looks like in action: In WordPress core code, specifically in [wp-settings.php](), on line `700` (at the time of this writing), the `init` action is called. /** * Fires after WordPress has finished loading but before any headers are sent. * * Most of WP is loaded at this stage, and the user is authenticated. WP continues * to load on the {@see 'init'} hook that follows (e.g. widgets), and many plugins instantiate * themselves on it for all sorts of reasons (e.g. they need a user, a taxonomy, etc.). * * If you wish to plug an action once WP is loaded, use the {@see 'wp_loaded'} hook below. * * @since 1.5.0 */ do_action( 'init' ); Line 700 of wp-settings.php in WordPress core In the following code example, a plugin hooks into the init action, which fires after WordPress finishes loading. ) attacks. ### Filters [_Filters_]() are similar to actions but are specifically used to modify data, for example, before it is sent to the database or the browser. When WordPress is about to display a title, content, or some other piece of data, it will first pass it through a filter hook if available. * **Definition:** Filters are defined by the apply_filters() function call in the WordPress core. This function passes data through all functions hooked to a filter, allowing them to modify the data. * **Registration:** Just like actions, filters are registered using the add_filter() function, which hooks a function to a specific filter. * **Execution:** When data is passed through the apply_filters() call, it is filtered by all hooked functions in sequence, each modifying the data before passing it onto the next. Here’s what it looks like in action: In WordPress core code, specifically in [wp-includes/post-template.php](), on line `256` (at the time of this writing), the `the_content` filter is called. // In the WordPress core wp-includes/post-template.php $content = apply_filters( 'the_content', $content ); ) that put hundreds of thousands of sites at risk. ## Examples Let’s take a look at some examples of how some of these actions might be hooked by plugin code and how a vulnerability might be introduced. ### **Example 1:** `wp_ajax_{action}` Hook in a File Upload Plugin **Scenario:** A plugin that allows users to upload files from the frontend might use the `wp_ajax_{action}` hook to handle the upload process. The plugin registers a function to this hook that processes the file upload. function handle_file_upload() { if (isset($_FILES['file'])) { $file = $_FILES['file']; // Vulnerability: The function does not properly check the file extension and MIME type. // An attacker could upload a malicious PHP file as a subscriber-level user'. // Another issue is the lack of directory traversal protection. // Example of insufficient validation: if ($file['size'] > 1000000) { echo 'Error: File size is too large.'; wp_die(); } // Assume the file is moved to a directory accessible via the web move_uploaded_file($file['tmp_name'], '/wp-content/uploads/' . $file['name']); echo 'File uploaded successfully!'; } else { echo 'No file uploaded.'; } wp_die(); // Required to terminate and return a response } add_action('wp_ajax_upload_file', 'handle_file_upload'); To access this function, a POST request would be made to `/wp-admin/admin-ajax.php` with the `action` parameter set to `upload_file`. POST /wp-admin/admin-ajax.php HTTP/1.1 Host: example-wordpress-site.com Content-Type: multipart/form-data; boundary=----WebKitFormBoundaryePkpFF7tjBAqx29L Content-Length: ... ------WebKitFormBoundaryePkpFF7tjBAqx29L Content-Disposition: form-data; name="action" upload_file ------WebKitFormBoundaryePkpFF7tjBAqx29L Content-Disposition: form-data; name="file"; filename="malicious.php" Content-Type: application/x-php <@INCLUDE *malicious PHP file content here*@> ------WebKitFormBoundaryePkpFF7tjBAqx29L-- 💡 Real-World Example Check out this [real-world example]() of an Arbitrary File Upload Vulnerability discovered in the WEmanage App Worker WordPress plugin that earned a $657 bounty. ### **Example 2:** `admin_init` Hook in a Plugin with a PHP File Inclusion **Scenario:** A WordPress plugin intends to allow administrators to include various PHP templates. However, It uses the `admin_init` hook and includes a PHP file based on a user-supplied input, leading to a potential LFI vulnerability that is exploitable by subscriber-level users. function plugin_template_includer_init() { // Vulnerability: Including a PHP file based on user input without proper validation // This could lead to Local File Inclusion (LFI) if an attacker manipulates the 'template' parameter. if (isset($_GET['template'])) { $template = $_GET['template']; // Example of a vulnerable include statement // An attacker could potentially execute arbitrary PHP code. include('/path/to/templates/' . $template . '.php'); } } // Hooking into 'admin_init' add_action('admin_init', 'plugin_template_includer_init'); As noted in the Key Routes and Their Hooks section, we can access this function via a simple GET request to the `/wp-admin/` endpoint. http://example-wordpress-site.com/wp-admin/?page=some_plugin_page&log_file=../../../../malicious 💡 Real-World Example Check out this [real-world example]() of a Local File Inclusion Vulnerability discovered in the MasterStudy LMS WordPress plugin that earned a $937 bounty ### Other Examples: Tracing a Request to a Hook Let's trace a typical request to see where vulnerabilities might be introduced: 1. **Frontend Page Load:** A user visits the homepage (`/`). * WordPress loads and parses the request. * The `template_redirect` action is triggered. * A plugin hooks into `template_redirect` to add custom redirection logic but fails to validate the URL properly, leading to an open redirect vulnerability. 2. **Admin Area:** A user makes a request to `/wp-admin/`. * The `admin_init` action is triggered. * A theme's `functions.php` file hooks into `admin_init` to add custom settings, but does not check user capabilities, allowing any logged-in user to change settings meant for admins only. 3. **AJAX Request:** A user submits a form that triggers an AJAX call to `admin-ajax.php`. * WordPress routes the request to the appropriate handler based on the `action` parameter. * A plugin handles the request but does not verify the nonce, making it susceptible to CSRF attacks. ## WordPress Plugin and Theme Loading and Request Mechanics While plugins and themes commonly hook into various WordPress actions and filters to implement their functionality, they can also directly handle requests and their parameters. Let’s review how plugins and themes are loaded, and how they can perform actions based on user-supplied request parameters. ### Plugin Loading All plugins have a main PHP file and it can be identified by a [header comment]() that typically looks something like this: ) for our [Bug Bounty Program]() and [join our Discord]() to engage with the Wordfence Threat Intelligence team and other security researchers! The post [WordPress Security Research Series: WordPress Request Architecture and Hooks]() appeared first on [Wordfence]().