Among the more than 10,000 new vulnerabilities in a year, only six are core, and 90% are plugins. How should this statistic be used?

Out of tens of thousands of new vulnerabilities each year, the core accounts for only six, while plugins account for ninety percent. How should this statistic be used? The correct usage is to treat it as an attack surface map, not as a quality score. This set of numbers indicates where vulnerabilities appear, not how well the code in that layer is written. The reading should focus on three points: whether the denominator is the total number of plugins or the total number of sites, how large the exposure area corresponds to the ninety percent figure, and how much response time you have between disclosure and widespread exploitation.

The numerator and denominator of this set of numbers.

The scope of the security report is: More than 11,000 new vulnerabilities were added to the WordPress ecosystem in 2025, of which plugins accounted for 90%, themes accounted for 9%, and the core had only six. The absolute number looks terrifying, but the denominator is completely different - the number of WordPress plugins and themes that can be installed is in the tens of thousands, and the core code is in only one repository. Therefore, 'the core only accounts for six' truly indicates that attackers are not queuing at the core gate, but at the gate of the long-tail expansion.

The same report also provides another number that has a greater impact on the handling process: the median time for large-scale exploitation is 5 hours. That is to say, the window between vulnerability disclosure and in-the-wild scanning can be as short as a lunch break, which is more decisive than any percentage number in determining how your patching process should be arranged.

plugins account for ninety percent what

it means 'extension is attack surface'. Each third-party package installed is equivalent to introducing a code repository that is not in your field of vision, along with its update pace, dependencies, and the author's maintenance willingness. The more prosperous the ecosystem, the thicker the tail, and statistically, the more vulnerabilities disclosed, which are irrelevant to the core quality.

The two truly executable inferences are as follows. First, try to choose built-in capabilities to reduce the number of things mounted outside; secondly, when it is necessary to mount outside, consider 'who is maintaining, is there a vulnerability response process' as a selection criterion, rather than just looking at the feature list.

In line with the thinking of an independent content system, the approach is not to add more, but to integrate common needs into the system. AnQiCMS takes the approach of building JWT authentication, content sensitive word filtering, and anti-crawling interference code into the system, used to defend against SQL injection and XSS attacks; sensitive word filtering also undertakes keyword replacement and content review, while anti-crawling interference code is responsible for protecting content from being bulk-crawled. If these capabilities were to be assembled externally, each one would become an additional update source and risk point.

Median 5 hours for response process requirements

To transform statistics into action, it requires three steps. First, determine 'who reads the notice': without a fixed person responsible, the notice is as if it was not issued. Then determine 'how fast to make decisions': under the premise that there are only a few hours in the window, the assessment process must be able to be compressed into one meeting, such as according to the three questions of 'whether it is publicly accessible, whether it affects the core link, and whether there is a temporary mitigation' to determine the level. Finally, determine 'how to roll back': when a patch causes a failure, can it be restored to a known usable state within ten minutes.

The in-site update should also be checked according to the same logic. Taking AnQiCMS v3.6.6 (2026-10-08) as an example, this release fixes the SQL injection in the list sorting parameters, as well as two high-risk issues where login credentials can be forged during site switching. The upgrade suggestions also require the rotation of the entire site's request signature key and the change of the administrator's password, which is a typical case of 'beyond patching and dealing with the leaked surface'. Such version announcements should be included in fixed inspection items, rather than being aware of them through information streams.

Determine if your process is available, there is a simple self-check: randomly select an announcement that has been in use recently, and see how long it has taken from the announcement time to the actual handling at your site. If the answer is a few days or even a few weeks, the problem is with the process rather than the number of announcements.

Is the defense line inside the system or mounted outside?

The difference between the two routes does not lie in the 'absolute safety level', but in the allocation of maintenance burden. The external assembly route distributes the cost to daily life: the more you install, the more you need to keep up with each package update; the built-in closure route front-loads the cost to the selection: a one-time decision on the capability boundary, followed by only one release source. For small teams without dedicated security personnel, the latter is usually easier to maintain the baseline in the long run.

It should be reminded that built-in does not mean maintenance-free. The core still needs to follow patches, credentials and keys still need to be rotated, and the content layer still needs to follow review rules. Statistics can help you focus your attention in the right place, but cannot replace you in completing the disposal actions.

Common questions

Plugins occupy ninety percent, does that mean we shouldn't install plugins?No. It means that for every one installed, there should be corresponding maintenance responsibilities: confirm the maintenance party, confirm the update channel, and confirm whether there is a vulnerability response process. Install only when there is no alternative solution, and record it in the asset list.

How do we use the number of median 5 hours in practical work?Use it as the time baseline for announcement grading and rollback drills: if your handling process usually takes several days, then you need to compress the decision-making levels and fix the backup recovery drills to ensure that you have the ability to roll back before the emergency patch.

Can this kind of ecosystem statistics be directly compared horizontally across different CMSs?Cannot. The denominator aperture is different, and the expansion quantity and the number of sites are not on the same level. What can be compared is the annual trend of the same ecosystem, as well as the long-term maintenance burden brought by integrating or externalizing capabilities in different architectures.