Unknown ajax actions

1194820 – Added. Detect undefined XHR actions in admin area

Thank you.
AFAIK self::report_error_event() does not block the event.
Please consider stopping these attacks.

I am very sorry!
It turned out there is a filter called admin_post_thumbnail_html. And actions are basically filters.
So you have to check $wp_actions also.
It is set here
https://github.com/WordPress/WordPress/blob/4.2-branch/wp-includes/plugin.php#L456-L459
just before doing “all”.

public function all_action( $tag ) {

       global $wp_filter;
       global $wp_actions;

        // Actions only (not filters)
        // <code>admin_post</code> or <code>wp_ajax</code>
        // Not registered
        if ( is_array( $wp_actions )
            && array_key_exists ( $tag, $wp_actions )
            && ( 'admin_post_' === substr( $tag, 0, 11 )
                || 'wp_ajax_' === substr( $tag, 0, 8 ) )
            && is_array( $wp_filter )
            && ! array_key_exists( $tag, $wp_filter )
        ) {
            $this->trigger_instant( 'wpf2b_admin_action_unknown', $tag );
        }
    }

Please pay attention to this.
I’ve already corrected it in my WAF.

Okay I will take a look at your code, thanks.

Suggestion included in changeset 1209752 [1] note that I also wrapped the code around a condition at changeset 1209886 [2] after multiple notices of people reporting a detriment in the performance of their sites, now to make this code work one have to explicitly enable the option from the “General Settings” panel located in the plugin’ settings page through an option named “Allow XHR monitor”.

[1] https://plugins.trac.www.ads-software.com/changeset/1209752
[2] https://plugins.trac.www.ads-software.com/changeset/1209886

multiple notices of people reporting a detriment in the performance of their sites

Could you please explain what is actual factor that slows down WP execution?

Could it be that this tiny if runs on all?

To be fair the issue has nothing to do with your code, the problem was with the implementation that I wrote following the base that you provided.

What I wrote caused the slowness because before I block the request an event message was sent via HTTP to keep the report remotely. It seems that the condition was incomplete so many requests were being sent (mostly because of the WordPress Heartbeat) so I decided to disable this option and allow the users to enable it on their own discretion.

And now that I think about it, this could be even be used by a malicious person to either spam or even (depending on his/her resources) take down the site, like a mini-DDoS tool. I am thinking to remove the event report but want to investigate these assumptions first.

Thank you!

So normal usage does not cause detriment in the performance.
Providing filters are not checked (and reported).