Facebook
Twitter- Server operating system version
- Centos 6.10
- Plesk version and microupdate number
- 18.0.31
A PSA for anyone running older releases of Plesk with nginx, and older releases of Wordpress Toolkit (wp-toolkit) like: 5.8.1-5837.
I was auditing one of my older systems today for any rewrites that are vulnerable to the brand new nginx CVE-2026-42945 published a few hours ago today, that can result in a remote take over. More details here:
depthfirst.com
My system's nginx is vulnerable to this exploit, but I am somewhat safe as I already has kernel.randomize_va_space (ASLR) set to 2 for full randomization, which makes it harder, but not impossible to exploit. I did want to fully remediate but cant upgrade nginx, and I did find a few places where I was exposed with rewrites vulnerable as described in the CVE and the article above. They were easy to fix but the PSA is, older versions of WP-TOOLKIT are what kept injecting these vulnerable rewrite directives when the "enable hotlink protection" is checked and if you have "Block author scans" checked or enabled in the security audit. Any Wordpress instance that has completed the security status and mitigations, or has that checkbox enabled, that domain will get unsafe rewrites added anytime the configurations are re-generated or applied as long as it's checked. This includes other tools that regenerate like plesk repair web -domains-only -y, adding additional nginx or apache directives, /usr/local/psa/admin/bin/httpdmng --reconfigure-server, etc., etc.
Editing some of the templates and adding overrides can help, but if you want to leave those features on, they will keep injecting a vulnerable rewrite that is hardcoded into WP-Toolkit.
I fixed this partially by creating an override here:
/usr/local/psa/admin/conf/templates/custom/domain/nginxDomainVirtualHost.php
That looks for and fixes the rewrites by injection additional code at the tail end. This seemed to get most of it, but when I would regenerate things some still seemed to get through.
In the end what fixes things for me what to create a custom bash script that sanitizes those things across all of /etc/nginx/plesk.conf.d/vhosts conf files and the system files, checks the config for errors with nginx -t, and then reloads its. I trigger this with the Event Manager and the Physical Hosting updated event which fires the script. It waits a few seconds to make sure Plesk is finished, then does its thing to fix the rewrites (and looks for others that may have slipped in) and restarts nginx. I kick it off by just adding some blank comments to the nginx directive and applying that to trigger things. This is good enough for my needs. One other note, wp-toolkit will customize the injection rules based on the path where your Wordpress installation url starts - so you need to account for that as well to make sure you fix the rewrite rules properly if you follow my example. Here is that script with some of the custom elements of my environment left out, you may need to customize, especially if any of your Wordpress installs are not at the base path of your url:
(Too large for forum post or some other validation rule, so added this to pastebin as well):
pastebin.com
I have no plans to create new domains on this older system, especially Wordpress that would be impacted by the older version of WP-Toolkit injecting the vulnerable rewrites, so Im not worried about forgetting this or introducing it with a new domain, just wanted to make sure I am covered for now and when I make changes/regenerate the configs.
I am hesitant to share all testing and remediation scripts that are tailored to my old creaky system, just mainly wanted to give a heads up that not only is this lurking in older systems, but you may not even be aware of them unless you manually check. For anyone who needs a head start, here is one small bash script that should help scan and identify flawed rewrites in nginx configs - adapt to your pathing and needs as necessary:
This first two line bash, will find vulnerable nginx rewrite rules across the main areas the directives woulds be found:
For this second larger script it also wouldn't fit here or allow it as an attachment, so I shared it to pastebin:
pastebin.com
That bash script creates a dump/reconstruction of your overall nginx config (pulling it from memory with nginx -T wasn't working well on my system, hence this method) and then scans the resulting file for rewrites and then presents them to you with the vulnerable lines and then removes the temporarily created nginx config dump.
More specifically, it performs structural state analysis on the .conf file. Standard Linux utilities like grep cannot look ahead across multiple multi-line scoping blocks cleanly, so this script acts as a parser. It scans config paths, isolates blocks, tracks the scope state, and explicitly flags files containing vulnerable combinations (rewrite with ? AND an accompanying rewrite/if/set statement).
You might get some false positives, for example the fake-hotlink-stub rewrite that wp-toolkit also injects, looks flawed but it's not really vulnerable. The replacement target is a completely static, plain text string: "/fake-hotlink-stub". Because it lacks a ? delimiter, nginx does not trigger the argument length miscalculation logic, however the scanner script will flag it because it does have the (?:/) which the scanner is looking for. Anyway, hopefully it will help folks not get stung by this one, there were already too many vulnerabilities this week for nginx and others.... I imagine this might still be helpful for newer releases of wp-toolkit too if its still using the same rewrite lines that are vulnerable and need to be revised to replace unnamed positional captures with PCRE named captures.
AI discovery of bugs, flaws, exploits, is only going to rapidly accelerate - it's only gonna get worse fast - we can only hope for responsible disclosure, but we cant certainly cant count on that... Stay frosty muchachos!
I was auditing one of my older systems today for any rewrites that are vulnerable to the brand new nginx CVE-2026-42945 published a few hours ago today, that can result in a remote take over. More details here:
NGINX Rift: Achieving NGINX Remote Code Execution via an 18-Year-Old Vulnerability | depthfirst
We used the depthfirst system to analyze the NGINX source code, and it autonomously discovered 4 remote memory corruption issues, including a critical heap buffer overflow introduced in 2008. We further investigated the exploitability of the issues, and developed a working proof of concept...
depthfirst.com
My system's nginx is vulnerable to this exploit, but I am somewhat safe as I already has kernel.randomize_va_space (ASLR) set to 2 for full randomization, which makes it harder, but not impossible to exploit. I did want to fully remediate but cant upgrade nginx, and I did find a few places where I was exposed with rewrites vulnerable as described in the CVE and the article above. They were easy to fix but the PSA is, older versions of WP-TOOLKIT are what kept injecting these vulnerable rewrite directives when the "enable hotlink protection" is checked and if you have "Block author scans" checked or enabled in the security audit. Any Wordpress instance that has completed the security status and mitigations, or has that checkbox enabled, that domain will get unsafe rewrites added anytime the configurations are re-generated or applied as long as it's checked. This includes other tools that regenerate like plesk repair web -domains-only -y, adding additional nginx or apache directives, /usr/local/psa/admin/bin/httpdmng --reconfigure-server, etc., etc.
Editing some of the templates and adding overrides can help, but if you want to leave those features on, they will keep injecting a vulnerable rewrite that is hardcoded into WP-Toolkit.
I fixed this partially by creating an override here:
/usr/local/psa/admin/conf/templates/custom/domain/nginxDomainVirtualHost.php
That looks for and fixes the rewrites by injection additional code at the tail end. This seemed to get most of it, but when I would regenerate things some still seemed to get through.
In the end what fixes things for me what to create a custom bash script that sanitizes those things across all of /etc/nginx/plesk.conf.d/vhosts conf files and the system files, checks the config for errors with nginx -t, and then reloads its. I trigger this with the Event Manager and the Physical Hosting updated event which fires the script. It waits a few seconds to make sure Plesk is finished, then does its thing to fix the rewrites (and looks for others that may have slipped in) and restarts nginx. I kick it off by just adding some blank comments to the nginx directive and applying that to trigger things. This is good enough for my needs. One other note, wp-toolkit will customize the injection rules based on the path where your Wordpress installation url starts - so you need to account for that as well to make sure you fix the rewrite rules properly if you follow my example. Here is that script with some of the custom elements of my environment left out, you may need to customize, especially if any of your Wordpress installs are not at the base path of your url:
(Too large for forum post or some other validation rule, so added this to pastebin as well):
nginx config plesk helper for CVE-2026-42945 - Pastebin.com
Pastebin.com is the number one paste tool since 2002. Pastebin is a website where you can store text online for a set period of time.
I have no plans to create new domains on this older system, especially Wordpress that would be impacted by the older version of WP-Toolkit injecting the vulnerable rewrites, so Im not worried about forgetting this or introducing it with a new domain, just wanted to make sure I am covered for now and when I make changes/regenerate the configs.
I am hesitant to share all testing and remediation scripts that are tailored to my old creaky system, just mainly wanted to give a heads up that not only is this lurking in older systems, but you may not even be aware of them unless you manually check. For anyone who needs a head start, here is one small bash script that should help scan and identify flawed rewrites in nginx configs - adapt to your pathing and needs as necessary:
This first two line bash, will find vulnerable nginx rewrite rules across the main areas the directives woulds be found:
Bash:
find /etc/ /var/www/vhosts/system/ /usr/local/psa/ /etc/nginx/plesk.conf.d/ /etc/nginx/plesk.conf.d/ip_default/ -type f \( -name "*.conf" -o -name "*.ini" -o -name "*.php" \) -print0 2>/dev/null | \
xargs -0 grep -E -n 'rewrite[[:space:]]+.*[?].*' 2>/dev/null | grep -v '(?<'For this second larger script it also wouldn't fit here or allow it as an attachment, so I shared it to pastebin:
Scan for wp-toolkit injected/vulnerable rewrites in nginx conf - Pastebin.com
Pastebin.com is the number one paste tool since 2002. Pastebin is a website where you can store text online for a set period of time.
That bash script creates a dump/reconstruction of your overall nginx config (pulling it from memory with nginx -T wasn't working well on my system, hence this method) and then scans the resulting file for rewrites and then presents them to you with the vulnerable lines and then removes the temporarily created nginx config dump.
More specifically, it performs structural state analysis on the .conf file. Standard Linux utilities like grep cannot look ahead across multiple multi-line scoping blocks cleanly, so this script acts as a parser. It scans config paths, isolates blocks, tracks the scope state, and explicitly flags files containing vulnerable combinations (rewrite with ? AND an accompanying rewrite/if/set statement).
You might get some false positives, for example the fake-hotlink-stub rewrite that wp-toolkit also injects, looks flawed but it's not really vulnerable. The replacement target is a completely static, plain text string: "/fake-hotlink-stub". Because it lacks a ? delimiter, nginx does not trigger the argument length miscalculation logic, however the scanner script will flag it because it does have the (?:/) which the scanner is looking for. Anyway, hopefully it will help folks not get stung by this one, there were already too many vulnerabilities this week for nginx and others.... I imagine this might still be helpful for newer releases of wp-toolkit too if its still using the same rewrite lines that are vulnerable and need to be revised to replace unnamed positional captures with PCRE named captures.
AI discovery of bugs, flaws, exploits, is only going to rapidly accelerate - it's only gonna get worse fast - we can only hope for responsible disclosure, but we cant certainly cant count on that... Stay frosty muchachos!
