Just last month a client called me in a panic. They had pushed a minor update to their custom WooCommerce extension, nothing major, just some styling tweaks and a small feature. It looked fine on staging. A few days later they got an email from WordPress.org flagging a security issue. It was minor, but it was enough to pull the plugin and cost them developer time to fix something that should have been caught much earlier. That is what maintaining WordPress plugin security looks like now.
For years the WordPress ecosystem has leaned on manual reviews by the Plugins Team, and they do a hard job well. But the volume of new plugin submissions and updates has outgrown what human reviewers can keep up with. Catching every security, compatibility, or compliance issue by eye alone is no longer realistic. If you are still counting on the review team as your last line of defense, that is a risky bet. I made the same mistake early in my career: a quick local test, then push.
That is why the Plugin Check plugin was so welcome. It is a piece of infrastructure built by the Plugins Team, Performance Team, and Meta Team, and it runs automated checks on your plugin, producing a detailed report before the plugin reaches a human reviewer. It has already improved the quality of new submissions by telling developers exactly what needs fixing.
It did not stop there. As of October 27, according to the make.wordpress.org/plugins blog, Plugin Check now runs automatically on all plugin updates, both new and existing. Every time you push an update to WordPress.org, it gets scanned for security vulnerabilities, compatibility issues, and compliance problems. The reports are internal to the team for now, but the plan is to send the security reports straight to authors after an update. This extends the AI support already used in manual reviews, which has let the team handle more than double the plugin submissions without the queue backing up.
WordPress plugin security: a practical example
This is a common pitfall. Say you are building a settings page for your plugin and saving user input straight to the database without sanitizing it. That is a classic SQL injection waiting to happen. Here is a simplified version of the bad code:
<?php
function bbioon_save_settings() {
if ( isset( $_POST['bbioon_setting'] ) ) {
// BAD PRACTICE: Directly saving unsanitized input
update_option( 'bbioon_plugin_setting', $_POST['bbioon_setting'] );
}
}
add_action( 'admin_post_bbioon_save_settings', 'bbioon_save_settings' );
?>Plugin Check flags that right away. It looks for functions that handle user input like $_POST or $_GET without proper sanitization and validation. It is far better to catch these during development or in an automated check than after someone exploits them.
<?php
function bbioon_save_settings_safe() {
if ( ! current_user_can( 'manage_options' ) ) {
return; // Always check capabilities
}
if ( isset( $_POST['bbioon_nonce_field'] ) && wp_verify_nonce( $_POST['bbioon_nonce_field'], 'bbioon_settings_action' ) ) {
if ( isset( $_POST['bbioon_setting'] ) ) {
$setting_value = sanitize_text_field( wp_unslash( $_POST['bbioon_setting'] ) );
update_option( 'bbioon_plugin_setting', $setting_value );
}
}
}
add_action( 'admin_post_bbioon_save_settings', 'bbioon_save_settings_safe' );
?>Notice the current_user_can, wp_verify_nonce, wp_unslash, and sanitize_text_field calls. Those are the basics of safe input handling, and Plugin Check enforces them automatically.
So what is the takeaway for developers?
- Build security in early: do not wait for a human reviewer, or worse a security researcher, to find the issues in your plugin.
- Run Plugin Check locally: make it part of your workflow. It is free and gives you the report before you upload anything.
- Keep up with best practices: attack vectors change as the ecosystem does, so follow the current WordPress security recommendations.
This stuff gets complicated fast. If you are tired of debugging someone else’s mess and just want your site to work, drop my team a line. We have probably seen it before.
