Last year, 90% of the newly discovered vulnerabilities came from plugins, how should the priority list of site updates be arranged?
WordPress added 91% new vulnerabilities last year from plugins, the update list should be rearranged: not by version newness, but by signs of in-the-wild exploitation, component exposure, and rollback cost. Patchstack's distribution in the 2026 WordPress Security Status whitepaper shows that in 2025, 11,334 new vulnerabilities were discovered, plugins accounted for 91%, themes for 9%, and the core only for 6; another key set of numbers from the same report is that the median time from disclosure to large-scale exploitation of severe vulnerabilities is about 5 hours.
What did the distribution numbers change the assumption for
This set of numbers changed the default assumption from 'Older program versions are more dangerous' to 'The subject of the list is the component rather than the kernel.' Only 6 cores were added, which means treating the upgrade of program versions as a monthly routine action can eliminate a very small portion of risks; the total of plugins and themes accounts for more than 90%, indicating that what really needs to be monitored is which extensions the site actually installed, and which ones are accessible anonymously on the front. The median exploitation time of about 5 hours also compresses the handling window outside the regular maintenance cycle: the arrangement of the next window does not apply to components that have already been actively scanned.
Sort by in-the-wild exploitation and exposure surface
The input is sorted into only three items. The first item is the presence of in-the-wild indicators: whether there is already an exploitation record in the vulnerability library or vendor announcement, whether there is already public verified code, components with signs are directly added to the daily list.The second item is the exposed surface: anonymously accessible interfaces, registration and login entry points, form and upload points, which are much more dangerous than components only available in the background. They should be prioritized over the former under the same rating.The third item is the disposable nature: components that can be temporarily disabled or uninstalled, with disposal costs lower than those requiring code changes. After scoring the three items, the list naturally divides into three categories: to be handled today, to be handled this week, and to be handled with the next maintenance window, with 90% of the workload falling into the first two categories.
Update in bulk first, then set up the rollback
The priority is arranged, and the execution order is still to backup first, then take action. The common failure of batch updates is not that the vulnerability has not been fixed, but that some extension is not compatible with the new version, and the site exposes another problem while solving one problem.AnQiCMS backup and restore cover data and static files, it is more practical to do a usable recovery exercise before scheduling batch updates, rather than treating backups as a punch card item in the process;The JWT authentication, sensitive word filtering, and anti-interference code for defense against SQL injection and XSS attacks are built-in and can reduce the impact of exploitation after extension updates lag, but do not replace the patch itself.
Make sorting into a routine mechanism
The list needs to be valid for a long time and needs three things to support it. The first is the component ledger: one row for an expansion, recording the name, current version number, last maintenance time, and whether it is accessible on the front desk. When sorting, refer directly to the ledger instead of relying on memory.The second is the announcement source: select one or two fixed subscriptions from manufacturer security pages, public vulnerability databases, and hosting service provider alerts to avoid the deviation of judgment criteria due to temporary searches.The third is the person responsible: who has the authority to bring a component to the day's file, who is responsible for executing a rollback after a problem occurs, make it clear after writing so that the list will not stop on paper. After the three items are in place, the monthly update work will change from re-evaluation to execution according to the file, and the time invested will also decrease significantly.
Common questions
Question: The list is too long and cannot be processed in a week, what should be done?Answer: Split according to the files. Only keep the components with in-the-wild signs and front-end accessibility in today's file; the rest go into this week's file. At the same time, directly disable the extensions that are not used, reducing the list base from the source.
Question: With so few new cores, can we ignore the program version?Answer: No. This standard only describes the new parts added last year, historical vulnerabilities, compatibility, and performance changes are still in the benefits of version upgrades, schedule according to quarters, no need to squeeze into today's file.
Question: How can we determine if a vulnerability of a certain extension has been exploited?Answer: Take the in-the-wild marking of the official announcement and vulnerability library entries as the standard, and then look at the abnormal request density of the component path in the on-site log; if either of the two is established, mention the file for that day.