Originally published at https://monstermegs.com/blog/wordpress-plugin-security/
One WordPress plugin collected six separate vulnerability disclosures in a single month. Kirki, a page builder and customizer framework installed on more than 500,000 sites, has been bleeding advisories since May, and the newest one landed on July 27. If you pay any attention to WordPress plugin security, this is the case study worth reading, because it shows how a trusted, widely deployed plugin quietly turns into an open door.
The pattern matters more than any single bug. Kirki is not abandonware from a hobbyist repository. It is a mature project bundled inside commercial themes, and it still produced a critical account takeover flaw, an arbitrary file deletion flaw, a SQL injection flaw, and several others inside a twelve week stretch. That run sits at the uncomfortable center of WordPress plugin security in 2026.
A Steady Drip of Kirki Disclosures Through July
Patchstack's public database for Kirki reads like a changelog of trouble. On July 6 alone, three advisories went out: a PHP object injection issue affecting versions up to 6.0.12, a cross site scripting issue up to 6.0.11, and a SQL injection issue up to 6.0.12. On July 16 came an authenticated path traversal that let an Editor level account delete arbitrary directories in versions up to 6.0.13.
The drip kept going. July 23 brought an insecure direct object reference that leaked sensitive information to unauthenticated visitors in versions up to 6.0.14. On July 27, an arbitrary file deletion advisory hit versions up to 6.0.13. Six disclosures, one plugin, three weeks. For anyone tracking WordPress plugin security, that cadence is the actual headline, because it suggests a code base with systemic problems rather than one unlucky mistake.
The Flaw That Handed Over Admin Accounts
The July advisories were the aftershocks. The earthquake was CVE-2026-8206, a CVSS 9.8 privilege escalation bug in Kirki versions 6.0.0 through 6.0.6, and it remains the clearest WordPress plugin security incident of the year so far. Security researcher CHOIGYENGMIN reported it to Wordfence on May 4, 2026. The vendor was notified on May 16, and version 6.0.7 shipped on May 18. Roughly 150,000 of the plugin's 500,000 installs were running an affected version when the details went public.
How the password reset bypass worked
The flaw lived in the handle_forgot_password function inside the plugin's form handler class. The endpoint accepted a username and an email address as separate, unlinked inputs. An attacker could name any account on the site, supply their own inbox, and receive a valid password reset link for it. No authentication, no email verification, no rate limit worth mentioning. That is a textbook WordPress plugin security failure: a feature that trusted user supplied data it had no business trusting.
Exploitation started fast. According to BleepingComputer's reporting on the Kirki flaw, Wordfence blocked over 222 attempts against customer sites within 24 hours of public disclosure. Successful exploitation meant administrator access, which in practice means malicious plugin installs, injected backdoors, web shells, and database exfiltration. Once an attacker owns wp-admin, WordPress plugin security stops being the problem and incident response starts.
An Unpatched Bug Is Still Sitting in Version 6.1.1
Here is the part that should make site owners uncomfortable. Patchstack has disclosed a broken access control issue tracked as CVE-2026-57727 affecting Kirki versions up to and including 6.1.1, and the advisory currently lists no official patch available. Updating to the newest release does not close it, because the newest release is the affected release. That is the WordPress plugin security scenario nobody plans for.
It also breaks the standard advice everyone repeats. “Keep everything updated” assumes a patch exists. When it does not, your options narrow to virtual patching through a web application firewall, restricting access at the server level, or removing the plugin until a fix ships. Sites running Kirki through a bundled theme often cannot simply delete it, which is exactly why bundled dependencies deserve more WordPress plugin security scrutiny than they usually get.
Kirki Is Not the Only Plugin Under Attack
Kirki is the loudest example this summer, not the only one. Burst Statistics, an analytics plugin with more than 200,000 active installs, carried an authentication bypass in versions 3.4.0 through 3.4.1.1 caused by an incorrect return value in password validation. It let attackers impersonate users through the REST API. Version 3.4.2 fixed it. Defiant, the company behind Wordfence, reported blocking thousands of attacks against both plugins inside a single 24 hour window.
Earlier in June, WP Maps Pro was hit by CVE-2026-8732, another CVSS 9.8 flaw that allowed unauthenticated attackers to create new administrator accounts through an AJAX callback protected only by an ineffective nonce check. Defiant logged over 1,700 attacks against it in 24 hours. Three plugins, three different root causes, one shared WordPress plugin security lesson about missing capability checks on endpoints that change state.
The window between disclosure and attack
Notice how short the timelines are. Advisory publishes, automated scanners find vulnerable installs, exploitation begins, all inside a day. Site owners who patch on a weekly maintenance schedule are already losing that race. Effective WordPress plugin security in 2026 has to assume the gap between disclosure and mass exploitation is measured in hours, not weeks, and build the response around that assumption.
What This Run of Flaws Reveals About WordPress Plugin Security
The Kirki sequence is not an outlier, it is the ecosystem average made visible. Patchstack recorded 11,334 new vulnerabilities across the WordPress ecosystem during 2025, and its State of WordPress Security report found that 91 percent of newly disclosed WordPress vulnerabilities that year were in plugins rather than core. Wordfence counted 2,213 in the fourth quarter of 2025 alone.
Core is comparatively hardened, and the recent WordPress core vulnerability that made headlines in July was notable precisely because core flaws are rare. Plugins are where the volume lives. The practical implication for WordPress plugin security is that your risk scales with your plugin count, your plugin count usually grows without anyone deciding it should, and half of those plugins were installed for a feature you tested once and never used again.
Install base is not a proxy for safety either, which is the least intuitive part of WordPress plugin security. Kirki has half a million users. WP Maps Pro is a paid product. Popularity means more eyes on the code, but it also means a bigger payoff for whoever finds the bug first, and it means the exploit is worth automating and spraying across the entire internet.
New Disclosure Rules Are Reshaping WordPress Plugin Security
There is a regulatory angle developing alongside the technical one. Starting in 2026, commercial WordPress plugins sold to European users are required to operate a vulnerability disclosure program so researchers have a documented channel to report flaws. That formalizes something the WordPress plugin security community has done informally for years through Patchstack and Wordfence bug bounty channels.
The practical effect should be faster vendor response times and fewer advisories that sit unpatched, which is exactly the failure mode CVE-2026-57727 illustrates. For buyers, a published disclosure policy is now a reasonable WordPress plugin security check before you add a commercial plugin to a client site. A vendor with no reporting channel is a vendor who will hear about a flaw from an attacker instead of a researcher.
What to Do About Your Own WordPress Plugin Security Right Now
Start with Kirki specifically. If your site or theme bundles it, confirm the version, update past 6.0.7 at minimum, and treat 6.1.1 as still exposed to the unpatched broken access control issue. Audit administrator accounts for anything you did not create, check wp-content for unfamiliar plugin directories, and rotate admin passwords if you were running an affected build during the exploitation window in May.
Start with the plugins you forgot you installed
Then widen the review, because inventory is where WordPress plugin security actually begins. Deactivating and deleting unused plugins removes attack surface permanently, which beats patching it forever. Enable automatic updates for anything low risk, keep a real off site backup so a compromise is recoverable rather than fatal, and make sure your host runs a firewall capable of virtual patching. Server level controls buy you time when the vendor has not shipped a fix.
A tested backup strategy is the difference between a bad afternoon and a rebuilt site. It is also the one WordPress plugin security control that keeps working after everything else has already failed, which is why it belongs at the top of your list rather than buried at the bottom of it.
The Takeaway
Three things are worth carrying away from the Kirki story. Widely installed and well maintained are not the same thing, so install count should never substitute for a version check. The gap between an advisory going public and bots hitting your site is now roughly a day, which makes update cadence a genuine WordPress plugin security control. And when no patch exists, as with CVE-2026-57727, your firewall and your backups are the entire defense.
Good WordPress plugin security is mostly unglamorous maintenance, and it works best when the platform underneath it is doing part of the job for you. If you would rather not carry the firewall and update discipline alone, MonsterMegs managed WordPress hosting handles the server side so you can focus on the plugins that actually earn their place.
Top comments (0)