{"id":2244,"date":"2026-02-28T15:05:36","date_gmt":"2026-02-28T15:05:36","guid":{"rendered":"https:\/\/nicktailor.com\/tech-blog\/?p=2244"},"modified":"2026-03-02T19:38:47","modified_gmt":"2026-03-02T19:38:47","slug":"wp-tool-kit-deeper-look","status":"publish","type":"post","link":"https:\/\/nicktailor.com\/tech-blog\/wp-tool-kit-deeper-look\/","title":{"rendered":"Security Hole Cpanel – Wp-tool-kit: Deeper Look…\ud83e\udd26\u200d\u2642\ufe0f"},"content":{"rendered":"

<\/p>\n

I run security audits regularly. I’ve seen misconfigurations, oversights, and the occasional lazy shortcut. What I found in cPanel’s WordPress Toolkit is unbelievable\u2026<\/p>\n

This doesn’t appear to be a bug. This is a deliberate architectural decision that gives unauditable code unrestricted root access to your server. By default. Without your consent. \ud83d\ude2e\ud83e\udd26\u200d\u2642\ufe0f<\/p>\n

Millions of production servers are running this right now.<\/strong><\/p>\n

\n

Finding #1: Passwordless Root Access \u2014 Deployed Automatically<\/h2>\n

Open this file on any cPanel server running WordPress Toolkit:<\/p>\n

cat \/etc\/sudoers.d\/48-wp-toolkit<\/code><\/pre>\n
Here’s what you’ll find:<\/p>\n
wp-toolkit ALL=(ALL) NOPASSWD:ALL\nDefaults:wp-toolkit secure_path = \/sbin:\/bin:\/usr\/sbin:\/usr\/bin\nDefaults:wp-toolkit !requiretty<\/code><\/pre>\n
NOPASSWD:ALL<\/code><\/p>\n
The wp-toolkit user can execute any command as root<\/strong> without a password. No restrictions. No whitelisting. Complete access to everything.<\/p>\n
You didn’t enable this. You weren’t asked. It’s baked into the RPM install script:<\/p>\n
rpm -q --scripts wp-toolkit-cpanel 2>\/dev\/null | grep -A 20 \"preinstall scriptlet\"<\/code><\/pre>\n
Every time WP Toolkit is installed or updated, this sudoers file gets created. Automatically. Silently.<\/p>\n
\n
Finding #2: It’s Actively Executing Root Commands<\/h2>\n
This isn’t sitting dormant. It’s running. Right now. On your server.<\/p>\n
grep wp-toolkit \/var\/log\/secure | tail -20<\/code><\/pre>\n
Here’s what I found in logs that made me dig deeper\u2026.<\/p>\n
Feb 28 12:11:17 sudo[1911429]: wp-toolkit : USER=root ; COMMAND=\/bin\/cat \/usr\/local\/cpanel\/version\nFeb 28 12:11:17 sudo[1911433]: wp-toolkit : USER=root ; COMMAND=\/bin\/sh -c 'whmapi1 get_domain_info --output=json'\nFeb 28 12:11:18 sudo[1911442]: wp-toolkit : USER=root ; COMMAND=\/bin\/sh -c 'whmapi1 listaccts --output=json'<\/code><\/pre>\n
Look at that pattern: \/bin\/sh -c '...'<\/code><\/p>\n
Arbitrary shell commands. As root. Constant execution.<\/p>\n
\n
Finding #3: You Cannot Audit What It’s Doing<\/h2>\n
I wanted to see what these scripts actually do. Here they are:<\/p>\n
ls \/usr\/local\/cpanel\/3rdparty\/wp-toolkit\/scripts\/\n\ncli-runner.php\nexecute-background-task.php\nread-files.php\nwrite-files.php\ntransfer-files.php<\/code><\/pre>\n
Read those filenames again:<\/p>\n
    \n
  • read-files.php<\/code> \u2014 reads files as root<\/li>\n
  • write-files.php<\/code> \u2014 writes files as root<\/li>\n
  • transfer-files.php<\/code> \u2014 moves files as root<\/li>\n
  • execute-background-task.php<\/code> \u2014 executes tasks as root<\/li>\n<\/ul>\n
    So let’s look at the source code:<\/p>\n
    file \/usr\/local\/cpanel\/3rdparty\/wp-toolkit\/scripts\/*.php\n\ncli-runner.php: data\nexecute-background-task.php: data\nread-files.php: data\nwrite-files.php: data\ntransfer-files.php: data<\/code><\/pre>\n
    They’re not identified as PHP files. They’re data<\/code>.<\/p>\n
    Because they’re ionCube encoded<\/strong>:<\/p>\n
    head -5 \/usr\/local\/cpanel\/3rdparty\/wp-toolkit\/scripts\/cli-runner.php\n\n<?php\n\/\/ Copyright 1999-2025. Plesk International GmbH. All rights reserved.\n\/\/ PLESK:\/\/PP.2500101\/C4OLIU+C...\n@__sw_loader_pragma__('PLESK_18');<\/code><\/pre>\n
    Binary encoded. Obfuscated. The source code is hidden.<\/strong><\/p>\n
    You cannot read what these scripts do. You cannot audit them for vulnerabilities. You cannot verify they’re secure.<\/p>\n
    But they have root access to your entire server.<\/p>\n
    \n
    Finding #4: This Is Official Code \u2014 Verified and Signed<\/h2>\n
    I wanted to be absolutely sure this wasn’t some compromise or modification. So I verified it:<\/p>\n
    rpm -qi wp-toolkit-cpanel | grep -E \"Signature|Vendor\"\n\nSignature   : RSA\/SHA512, Wed 14 Jan 2026 05:56:56 PM UTC, Key ID ba338aa6d9170f80<\/code><\/pre>\n
    Digitally signed by cPanel. Official package.<\/p>\n
    rpm -V wp-toolkit-cpanel 2>&1 | head -10<\/code><\/pre>\n
    All scripts match the official package. No modifications. No tampering.<\/p>\n
    The script headers explicitly state:<\/p>\n
    \/\/ Copyright 1999-2025. Plesk International GmbH. All rights reserved.\n\/\/ This is part of Plesk distribution.\n@__sw_loader_pragma__('PLESK_18');<\/code><\/pre>\n
    This is Plesk’s WordPress Toolkit, distributed through cPanel’s official repository, digitally signed, running on millions of servers worldwide.<\/strong><\/p>\n
    \n
    Finding #5: It Restores Itself\u2026 Every Night \ud83e\udd26\u200d\u2642\ufe0f<\/h2>\n
    So I removed the sudoers file. Problem solved, right?<\/p>\n
    Nope.<\/p>\n
    There’s a cron job:<\/p>\n
    cat \/etc\/cron.d\/wp-toolkit-update<\/code><\/pre>\n
    This runs daily at 1 AM (with random delay) and executes:<\/p>\n
    yum -y update wp-toolkit-cpanel<\/code><\/pre>\n
    When the package updates, the preinstall script runs. The preinstall script recreates \/etc\/sudoers.d\/48-wp-toolkit<\/code>.<\/p>\n
    Your fix gets silently undone. Every night. Automatically.<\/strong><\/p>\n
    So removing the sudoers file alone doesn’t work. You have to disable the cron too, or you’ll wake up tomorrow with the same problem.<\/p>\n
    \n
    So\u2026.<\/h2>\n
    cPanel ships WordPress Toolkit with:<\/p>\n\n\n\n\n\n\n\n\n\n
    What They Ship<\/th>\nWhat It Means<\/th>\n<\/tr>\n
    NOPASSWD:ALL<\/code> sudo access<\/td>\nUnrestricted root access, no authentication<\/td>\n<\/tr>\n
    Deployed automatically<\/td>\nNo consent, no warning, no opt-in<\/td>\n<\/tr>\n
    ionCube-encoded scripts<\/td>\nSource code hidden, cannot be audited<\/td>\n<\/tr>\n
    Scripts that read\/write\/execute<\/td>\nComplete filesystem and command access<\/td>\n<\/tr>\n
    Digitally signed official package<\/td>\nThis is intentional, not a compromise?<\/td>\n<\/tr>\n
    Nightly auto-update cron<\/td>\nRestores sudo access if you remove it<\/td>\n<\/tr>\n
    No security scanner detection<\/td>\nFlying under the radar on millions of servers<\/td>\n<\/tr>\n<\/table>\n
    This is a “trust us”<\/strong> security model:<\/p>\n