Medium-severity findings.

Audited release

1.0.0

Findings

2

Worst severity

medium

Content hash

93516b902cd1e4b0a34281de… Copy

Findings

• medium Production kill-switch does not disable xrDebug on default WordPress production

  dev_tool_in_production

  wp_boot_xr() documents that xrDebug is disabled when the environment is production, but the gate is `defined('WP_ENVIRONMENT_TYPE') && wp_get_environment_type() === 'production'`. WordPress core's wp_get_environment_type() already returns 'production' when the constant is unset (the default for most live sites) and when only the WP_ENVIRONMENT_TYPE environment variable is set. In those cases the conjunction is false, so the plugin calls wp_xri() → getXr() which instantiates an enabled client (host localhost, port 27420) and walks from getcwd() up to the filesystem root looking for xr.php, then require()s it via FilePhpReturn::get(). Observable on a stock production install with the constant unset: xr()/xrr() still POST dumps to http://localhost:27420/messages; wp_xri()->showMails() still forwards full PHPMailer objects (recipients, HTML body, SMTP credentials on the mailer); showQueries() still defines SAVEQUERIES and ships SQL; leftover developer xr.php in a parent directory is executed and can retarget host/port/key. vd()/vdd() from the bundled var-dump autoload write HTML variable dumps to php://output and are not covered by this gate even when the constant is explicitly production. Subscriber/unauth visitors cannot flip the helpers on by themselves, but any request that runs documented debug calls (theme/plugin code, or an mu-plugin left from staging) now exfiltrates that request's data instead of no-op'ing.

  src/functions.php:20-36

  Recommendation

  Disable when wp_get_environment_type() === 'production' (do not require the constant to be defined). Default-deny unless WP_ENVIRONMENT_TYPE is explicitly local/development/staging. Do not walk parent directories to require xr.php on production. Gate or do not autoload vd()/vdd() in production. Fail closed if a debug server is not an explicit non-production opt-in.

• medium Web-accessible vendor demo scripts allow unauthenticated PHP worker exhaustion

  dos

  The release zip ships vendor/xrdebug/php/demo/*.php with no ABSPATH, CLI, or capability guard. A default WordPress install executes plugin PHP over HTTP. demo/autoload.php resolves ../../../../vendor/autoload.php (the plugin's Composer autoload), so the helpers run. GET .../demo/welcome.php calls xrr(), then xri()->pause() (ClientTrait::sendPause: if the debug server answers without a curl error, do { sleep(1); } while (isPaused($id)) with no iteration cap), then six unconditional sleep(5) calls (~30s). Observable: any unauthenticated visitor can pin a PHP-FPM worker for 30 seconds per request; if xrDebug is listening on localhost:27420 (the intended companion process), pause() holds the worker until the UI resumes/stops or max_execution_time. vdd.php dumps an HTML var-dump to the response and exit(0). error-handling.php registers the console throwable handler and throws, printing filesystem paths from the stack trace into the HTTP body. These files are not used by the WordPress plugin runtime.

  vendor/xrdebug/php/demo/welcome.php:14-64

  Recommendation

  Omit vendor/xrdebug/php/demo (and other non-runtime vendor bins/demos) from the WordPress release zip. If demos must ship, guard every file with `if (PHP_SAPI !== 'cli') { exit; }` or deny HTTP access via an .htaccess/index.php in that directory.

WP Registry hashes the installable build and reports on that exact bytes-for-bytes copy. Embargoed findings are withheld until they are disclosed, so a clean verdict means nothing public is outstanding. WP Manifest does not audit code itself.