BugShield Scout identifies 2,243 potential vulnerabilities across 1,465 WordPress plugins

How the plugin research was scoped

The plugin study follows our earlier theme vulnerability research and uses the same approach: automated source review that surfaces code worth a closer look. The cohort was not the whole plugin directory. We stored 34,781 plugins from WordPress.org, selected newest-updated first and limited to plugins updated within the previous 365 days. Scout scanned 34,751 of them on 18th October 2026, while the remaining 30 were unavailable or unset at scan time.

Coverage was not complete for every plugin either. Scout had complete coverage for 32,263 plugins and partial coverage for 2,488, meaning it did not read every source file in those, while the 30 unscanned plugins have no coverage. Because the cohort leans towards recently updated software, the figures describe this group alone and give no reliable picture of every plugin you can install.

What 2,243 WordPress plugin security findings actually means

Scout's output is a list of leads for people to check, and every total below should be read that way. Across the scanned cohort, Scout stored 92,200 findings in 22,344 plugins, including targeted review leads, all recorded as research leads rather than confirmed vulnerabilities. After earlier automated screening, 5,627 of those findings went on to the final model review, while the other 86,573 were not sent to it. The stored report shortlist now holds 2,243 findings across 1,465 plugins. All 2,243 are candidates for disclosure; the figure does not count reproduced vulnerabilities, distinct root causes or confirmed unpatched flaws.

Each shortlisted finding carries an internal review score from 2 to 10. We use the score to decide what to examine first. CVSS, the industry's standard severity scale, plays no part in it, so a high number does not mean a confirmed critical vulnerability. Together, the shortlisted plugins account for about 12 million installations, a sum of the WordPress.org figures stored at scan time on 18th October 2026 rather than a fresh live count. Because one site can run several of these plugins, the total cannot be read as a count of distinct websites, and it tells you nothing about which sites run an affected version or have been compromised.

An empty result carries its own limit. Scout found no static lead in 13,785 plugins, yet an automated read that finds nothing gives no evidence that a plugin is safe. Absence from the shortlist therefore says nothing about whether a plugin is clean.

Published fixes following developer outreach

The published Scout advisories below are examples of fixes released following our reports to developers. Each describes a review of the affected and fixed source packages rather than an independent functional retest in WordPress. Every advisory confirms one affected version, while earlier versions were not assessed.

In AWcode Toolkit 1.0.24, the supplier search accepted requests from logged-out visitors and placed their text straight into a database query, a flaw known as SQL injection. Version 1.0.25 removes the logged-out handler and builds the query safely. Flexible Shipping 6.13.4 let a low-privilege logged-in user, such as a subscriber, download an existing shipping manifest, which can contain customer and shipment details. Version 6.13.5 requires WooCommerce management permission and a valid security token before releasing a manifest.

Two further fixes protect payment and identity settings. The payOS 1.0.75 gateway accepted settings submissions from visitors without an account. New credentials were stored only when payOS accepted them at registration, but a failed registration still changed the stored status and related metadata, and either change can disrupt payments; 1.0.76 adds permission and token checks, and 1.0.77 keeps them. In Shufti 1.1.7, a directly reachable script let anyone replace the identity verification client ID and secret key. Shufti 1.1.8 removes that script and checks permissions before saving.

Another published fix concerns Link Invoice Payment for WooCommerce 2.13.2. With email one-time password login switched on, the six-digit code had no limit on failed guesses, so a correct guess signed the visitor in as the account owner, including an administrator where the login mode allowed it. The developer told BugShield that the first fix shipped in 2.13.3, a release we could not inspect, and 2.14.0 is the version we reviewed. Its entry in the WordPress.org changelog corroborates that inspected fix, listing email OTP security changes covering an attempt limit, temporary lockout and hashed codes. Install 2.14.0 or later.

Steps to take on your own site

The WordPress Advanced Administration Handbook says the most important thing for WordPress security is keeping WordPress itself and all installed plugins and themes up to date. For the plugins covered here, keeping up to date means checking which version your site runs and moving to the fixed release listed in the steps below. Our guide to updating plugins safely covers backups, staging and recovery if an update breaks something.

1. Open Plugins > Installed Plugins and note the installed version of AWcode Toolkit, Flexible Shipping, payOS, Shufti or Link Invoice Payment for WooCommerce.
2. Take a backup you know you can restore before changing anything.
3. Update to the fixed release or later: AWcode Toolkit 1.0.25, Flexible Shipping 6.13.5, payOS 1.0.76 (1.0.77 was available at publication), Shufti 1.1.8 and Link Invoice Payment for WooCommerce 2.14.0.
4. If you cannot update Link Invoice Payment straight away, switch off its email OTP login feature until the update is complete.
5. After updating Shufti, open its KYC settings and click Go Live to reactivate the verification button, as the developer's changelog instructs.
6. For payOS and Shufti, confirm the stored keys and credentials belong to your own account, and reconnect the payOS webhook if needed.

Checking your site after updating

Once the update is in, test the workflow each flaw touched. Place a test payment through checkout with payOS, run a verification with Shufti, sign in with email OTP on Link Invoice Payment, and confirm that staff who can edit products still get supplier search results in AWcode Toolkit. On Flexible Shipping, check that a WooCommerce manager can still download a manifest while a subscriber account cannot.

A working checkout shows that the tested workflow still runs, but it says nothing about features you did not test or about the fix itself. The version number on the plugins screen is the stronger evidence that the patched code is present, and neither check reveals whether someone used the flaw before you updated. For that question, compare stored payment and verification credentials against your own records and review any available access logs, particularly for unexpected manifest download requests on Flexible Shipping sites.

For other plugins on your site, the plugin vulnerability lookup takes a slug and installed version and returns available records, while the vulnerability database lists published reports with affected versions and fixes. An empty result means no matching record exists, not that the plugin is clean.

Why the remaining plugin names stay private

Shortlisted findings sit at different stages, and some are still candidates awaiting confirmation. Naming plugins at that stage would expose owners before any update exists and would attach a label to software over leads that still need checking. The shortlist is a local research list rather than a count of outstanding unpatched flaws, and it has not been reconciled against the published advisories to produce a remaining total. As more developers respond and release updates, new advisories will appear in the database and on our security blog.