Loading today’s stories
Build1 publisher3 min readPublished
Patchstack logged 11,334 ecosystem vulnerabilities last year, and 46% had no developer fix when they went public. That turns a care plan built on clicking Update All into a plugin inventory problem.
The Engineer · Build desk
Compiled by The EngineerSomething wrong?How this is made
The percentage understates the change, so take the counts. Forty-six percent of 11,334 is about 5,214 disclosures that landed with nothing to click [12]. The 2024 equivalent, 33 percent of 7,966, is about 2,629 [13]. The no-patch population roughly doubled year over year while total disclosures rose 42 percent [14][2]. Averaged across the year, that is about 31 disclosures a day [15].
The dev.to writeup describes the mechanism that makes those counts operational. When a maintainer walks away, the code stops receiving security updates, and no update notification reliably appears in the client's dashboard [6]. The update queue is therefore a list of plugins whose authors are still working. Its length reports on their calendars. The abandoned plugin sitting next to them reports itself as current, because current means the last thing the author published [6].
One path in the article's abandonment taxonomy inverts the button altogether: attackers buy plugins that already carry install bases and push a malicious update through the normal channel [8]. The Essential Plugin portfolio was more than 30 plugins built over roughly a decade with a combined install history above 400,000 [9]. The article puts the backdoor's dormancy at about eight months before it activated on 5-6 April 2026, downloading a file dressed up as a genuine WordPress core file and writing malicious code into wp-config.php [10][11]. The backdoor was in the new owner's first commit, which does at least remove any ambiguity about why the portfolio was bought [10].
Two things do not carry as far as the framing wants. The dates do not reconcile: an early 2025 acquisition and an April 2026 activation is a gap of a year or more, not eight months [19]. More load-bearing for anyone planning the work, the article names abandoned and deprecated software as the primary cause of unpatched vulnerabilities [5] but gives no breakdown of how much of the 46 percent it accounts for [18].
For 46 percent to describe your sites, your installed plugin set would have to resemble the disclosure feed. These are shares of disclosure counts, and nothing in the source weights them by active installs [17]. A flaw in a plugin with 40 users counts the same as one in a plugin with four million. So the figure is a property of the stream, and your exposure is a property of your inventory: what you run, and when each item last shipped. That is the audit the article prescribes, an SOP for tracking abandoned plugins and client software lifecycles rather than a button [7]. The reason it cannot be automated into the dashboard is the same reason the vulnerability exists. Absent a maintainer there is no vendor patch to fetch, so remediation happens site-side, by removal, replacement, or maintaining a fork in-house [20]. Each of those is a priced conversation with the client.
Ranked by verification strength, evidence, and original report placement.
Patchstack's State of WordPress Security in 2026 report records 11,334 new vulnerabilities disclosed across the WordPress ecosystem in 2025, the highest total ever recorded.
The 11,334 figure for 2025 is a 42% jump from the 7,966 vulnerabilities recorded in 2024.
Of the 2025 disclosures, 91% were found in plugins, 9% in themes, and six low-severity issues in WordPress core itself.
46% of the 2025 disclosures had no developer patch available at the moment they were publicly disclosed, up from 33% the year before.
When a developer or company stops maintaining a plugin the code stops receiving security updates; because the software is abandoned, no update notification reliably appears in the client's admin dashboard, and the site sits on an unpatched exploit until bots compromise the database or inject SEO spam.
The article argues agencies need a systematic standard operating procedure to audit abandoned WordPress plugins, manage deprecated web software and track client software lifecycles, in order to protect clients and avoid liability.
Follow any of these and your For You feed starts watching them — no settings page required.
Evidence-backed comparisons of source perspectives and observed adoption signals. Read the methodology
Which Builder, Operator, and Investor concerns the observed source mix emphasized—not a truth score.
Evidence, demonstrated adoption, hype gap, incentives, and confidence are assessed independently, each on its own current evidence. How these are measured.
One relay of one vendor's tally
The 11,334 total, the 42% rise and the 46% no-patch share all come from Patchstack's own annual report as quoted by dev.to, without a link to the data or a second publisher checking any of it. The April case study is the sturdier half, naming the portfolio, the marketplace, the vulnerability class and the file that was written to, but the same account also supplies a dormancy figure its own dates contradict.
One documented compromise at scale
The supply-chain route is not hypothetical in this telling: 31 plugins pulled from the directory on 7 April 2026, a forced update that cut the backdoor's callback while leaving the malicious code on servers that were already infected, and researcher estimates above 20,000 compromised installs. A second named case in the same week suggests the pattern is not isolated. What is missing is the general picture, since nothing in the reporting counts how many live sites are running plugins nobody maintains.
The framing outruns the causal link
Moving from disclosure counts to the conclusion that update-based care plans no longer cover the risk depends on abandonment driving that 46%, and no figure in the reporting establishes it. The counts are also blind to install size, so a plugin with a dozen users weighs the same as one with 400,000. The underlying observation holds up; the confidence of the framing is borrowed from statistics that were not built to answer the question.
Vendor data, lifecycle-tracking author
Two interests sit behind this write-up. Every number is drawn from a WordPress security vendor's annual report, and it is published by the instarenewal account, whose argument lands on the point that renewal records tracking only whether a plugin updates miss this risk entirely. That is a sales-shaped conclusion, and the audit procedure and the statistics chosen to justify it come from parties with something to sell.
Single teller, checkable specifics
We can be reasonably firm about what was said and what it implies arithmetically, and much less firm about whether the numbers are right, because one publisher relays them all. The April incident is specific enough to verify elsewhere, and the unresolved timeline inside it is a reminder that this account has not been through anyone else's fact-check.
security
Five critical WordPress flaws hand attackers full site takeover1 publisher
security
Two loops, one blocklist bypass: Elementor Pro's upload field becomes unauthenticated RCE4 publishers
security
Two miniOrange SAML bugs under attack, and 30,000 paid installs were never told5 publishers
security
Attackers plant PHP web shells through two unauthenticated WordPress upload flaws1 publisher
Publishers with included, body-backed reporting in this cluster.
1 article · September 8, 2026