The WordPress API has a huge learning curve, so you might miss authentication and authorization checks when you code your first plugin. This article will explain how an authentication failure allowed random web users to delete comments stored with images using the 10Web Mobile-Friendly Image Gallery Plugin for WordPress, exposed and published as CVE-2026-1036.
10Web Image Gallery and Permissions in WordPress
Before getting into the vulnerability, first a word about the way WordPress permissions work and the 10Web Mobile-Friendly Image Gallery comment features. The 10Web plugin lets site owners create mobile-friendly versions of their images. Site creators can upload images and edit them directly in the WordPress dashboard. Users can then comment on images.
WordPress has a few major user account types: super admin, admin, contributor, author, subscriber, and editor. These user roles have permissions. For every action a user can do from your plugin, you need to ensure the user has permission to do it. WordPress coding standards suggest checking for a nonce (number used once) assigned to a valid user. After checking for the nonce and user permissions, your plugin code can then perform the action.
In CVE-2026-1036, 10Web Mobile-Friendly Image Gallery Plugin failed to check both, so an attacker could execute functions without authorization. For this vulnerability, an authorized user could execute the function delete_comment, which allowed users to delete comments assigned to 10Web images.
10Web Plugin Code Vulnerability
Admins can add images to their site with 10Web, and then users can comment. The 10Web Mobile-Friendly Image Gallery Plugin then lets the user who made the comment or admins delete comments. Even though the buttons to delete comments aren’t displayed on the frontend, attackers can use server requests to execute the delete_comment function, which means users could delete comments that don’t belong to them.
Here is the code prior to the recent 10Web security patch:
public function delete_comment() {
global $wpdb;
$json = array();
$id_image = WDWLibrary::get('id_image', 0, 'intval');
$id_comment = WDWLibrary::get('id_comment', 0, 'intval');
if ( $id_image && $id_comment ) {
//delete query here
//.....snipped for brevity.....
}
//.....snipped for brevity.....
}
The single line to note in the code above is the if statement where the code validates that $id_image and $id_comment contains a value. This step ensures that the function can delete a comment, but it does not validate that the current user can delete the comment. It’s possible that the developer never thought that user permission validation was necessary if the function isn’t directly called from a user action, but even actions hidden in plugin code can be executed using WordPress hooks.
The 10Web Security Patch and New Plugin Code
After the vulnerability was found, 10Web published a patch. The patch is a good example of what WordPress developers should do to secure their code from unauthorized execution. Here is the new code for the delete_comment function:
public function delete_comment() {
global $wpdb;
$json = array();
//verify that the user is active and can edit comments
if (!wp_verify_nonce($_POST['bwg_nonce'], 'comment')) {
$error = true;
}
$id_image = WDWLibrary::get('id_image', 0, 'intval');
$id_comment = WDWLibrary::get('id_comment', 0, 'intval');
//added current_user_can function to check permissions
if ( $id_image && $id_comment && current_user_can('moderate_comments') ) {
//delete query here
//.....snipped for brevity.....
}
//.....snipped for brevity.....
}
The added code is in the snippet above. I’ve added comments to explain the new code, but the new authorization validation is in two sections.
The first section verifies that the user making a call to the delete_comment is active on the site. WordPress assigns a nonce (number used once) to every user. This statement verifies that the nonce exists and it’s for commenting on images.
An additional condition in the form of a function named current_user_can is then added to the if statement validating that $id_image and $id_comment have values. The current_user_can function is a WordPress API feature. It checks that the current user account can perform an action. The action is passed to the function as an argument. In this example, the moderate_comments parameter asks the function to verify that the user can edit comments stored with images. If the function returns false, then comments are not deleted.
What WordPress Coders Should Learn from Here
For any event in your WordPress plugin, always check that the user has a legitimate nonce and permission to perform the action. Without authorization checks, you code security issues into your plugin. Luckily, the WordPress API has built-in functions to validate user authorization, so use them frequently for every feature.
Check out some of my other examples of security failures found in other WordPress functions. You’ll see that there is a common mistake among developers assuming that a function cannot be executed by the general public. Even if that’s true today, it might not be true tomorrow. Remember the cybersecurity theory to “trust but verify” even in your WordPress code.