WP Manifestindependent plugin directory
manifest / developer / wp-fatal-handler

WP Fatal Error Handler WP RegistryHigh-severity findings · 1 findingOpen the reportC-

A better fatal error handler for WordPress.

by Sean Fisher · github.com/alleyinteractive/wp-fatal-handler · website

★ 1stars
345kcomposer installs
v0.1.3latest · 1 year ago

Install

Download source zip No release zip yet

This is the repository archive. It installs, but the folder name will carry the branch suffix and updates will not flow.

Install straight from GitHub with WP-CLI:

wp plugin install https://github.com/alleyinteractive/wp-fatal-handler/archive/refs/heads/develop.zip

On Packagist as alleyinteractive/wp-fatal-handler:

composer require alleyinteractive/wp-fatal-handler
No built-in updater. New versions won't appear under Dashboard → Updates. Install new releases yourself, or let Git Updater track the repository.
Readme github.com/alleyinteractive/wp-fatal-handler ↗

A better fatal error handler for WordPress powered by Whoops.

Screenshot of plugin

By default, WordPress' error handling provides limited information when dealing with fatal errors.

Screenshot of core

This plugin replaces the default WordPress fatal error handler with a Whoops error handler, which provides a much more useful error page with stack traces, code snippets, and more. It also provides a JSON response for API requests. The Whoops handler will only be applied to fatal errors where WP_DEBUG is set to `true.

Installation

You can install the package via Composer:

composer require alleyinteractive/wp-fatal-handler

Usage

Activate the plugin in WordPress and it will automatically register the Whoops error handler for fatal errors. It is recommended to load this plugin as early as possible (perhaps in mu-plugins), so that it can catch all fatal errors that occur during the WordPress bootstrap process.

Configuration

By default the plugin will register the Whoops error handler and only handle fatal errors (where core usually displays There has been a critical error on this website. ).

To disable the registration of the error handler, you can use the wp_fatal_handler_register filter:

add_filter( 'wp_fatal_handler_register', '__return_false' );

Note: this filter should be applied before the plugin is loaded.

Conflict with Query Monitor

By default Query Monitor will handle fatal errors which will prevent this plugin from displaying its error page. To allow this plugin to handle fatal errors, you can disable Query Monitor's error handling by using the following code:

define( 'QM_DISABLE_ERROR_HANDLER', true );

Changelog

Please see CHANGELOG for more information on what has changed recently.

Credits

This project is actively maintained by Alley Interactive. Like what you see? Come work with us.

License

The GNU General Public License (GPL) license. Please see License File for more information.

Releases

4 releases.

Tag
Published
v0.1.3 latest
Aug 14, 2025 1 year ago
v0.1.2
Jul 2, 2025 1 year ago
v0.1.1
Jun 30, 2025 1 year ago
v0.1.0
Jun 25, 2025 1 year ago

These releases are tags only. The author does not attach a packaged zip, so there are no download counts to report.

C- grade

Security

WP Fatal Error Handler 0.1.3 · audited by WP Registry

High-severity findings.

1 high
Audited release
0.1.3
Findings
1
Worst severity
high
Content hash
d93e71cf2167fee9200288bf…

Findings

  • high Whoops error page dumps source and environment to unauthenticated visitors

    information_disclosure

    On every request, wp-fatal-handler.php calls main(). If should_register_handler() is true it constructs PrettyPageHandler (default), JsonResponseHandler (URI contains /wp-json/ or Accept contains /json), or PlainTextHandler (WP_CLI), then Whoops\Run::register() installs PHP exception, error, and shutdown handlers. should_register_handler() is true whenever WP_DEBUG is true, unless VIP_GO_APP_ENVIRONMENT is defined and not 'local' or a test constant is set. It never checks WP_DEBUG_DISPLAY, wp_get_environment_type(), is_admin(), or current_user_can(). Silence is only applied to E_WARNING/E_NOTICE/E_DEPRECATED/E_USER_* under ABSPATH — uncaught exceptions and fatals still render. PrettyPageHandler::handle() (vendor/filp/whoops 2.18.4) prints GET/POST/FILES/COOKIE/SESSION/SERVER/ENV (hideSuperglobalKey used only for PHP_AUTH_PW) and ~40 lines of source per stack frame via file_get_contents, plus Symfony VarDumper output of frame arguments. WordPress core's fatal handler returns a generic 500 with no source or env tables. Because this plugin is a no-op without WP_DEBUG, every documented deployment exposes that dump to uid 0 on the next public fatal. Staging hosts that follow the WP_DEBUG=true / WP_DEBUG_DISPLAY=false logging pattern are included. The VIP-only environment check shows the authors treated non-local as unsafe but did not apply an equivalent gate for non-VIP production.

    src/main.php:19-119

    Recommendation

    Do not register Whoops for anonymous or low-privilege requests. Gate on WP_DEBUG && WP_DEBUG_DISPLAY (or wp_get_environment_type() in {local,development} only), and at handle time require current_user_can('manage_options'); otherwise leave WordPress's generic fatal template. Call PrettyPageHandler::hideSuperglobalKey() for wordpress_* / wp-settings-* cookies and common secret env names (DB_PASSWORD, AUTH_KEY, AWS_*, etc.). Keep the VIP non-local disable. Consider moving filp/whoops to an explicit local-only load path so production autoload never installs dump()/dd() either.

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.

Full report on WP Registry →