The plugin layer accounts for ninety percent of the vulnerabilities, isn't it more worry-free for a website system with fewer plugins?
It is said that 90% of the vulnerabilities are in the plugin layer, then isn't the website system with fewer plugins easier to maintain? This statistic actually points out the source of the maintenance burden: the risk is concentrated in the extension layer, not the program itself. Fewer plugins indeed reduce a batch of update sources that need to be tracked individually, but the premise of being hassle-free is replaced by another thing - whether the features you need are already in the system. If not, you still have to rely on code补, just changing 'wait for the plugin author to release' to 'schedule it yourself or outsource it.'
What is this number of 90% vulnerabilities saying?
For example, the annual security white paper of the WordPress ecosystem recorded 11,334 new vulnerabilities in 2025, of which 91% fell in the plugin layer, the theme layer accounted for the majority of the remainder, and the core reported only 6. The same statistics also provided a more attention-worthy number: the median time from the public disclosure of vulnerabilities to their exploitation is on the order of hours.
These two numbers together can lead to a selection conclusion: The core layer being compromised is a low-probability, high-impact event, and the extension layer being compromised is a high-probability, single-point impact event. The difference in selection does not lie in 'whether an accident will happen' but in 'how many release sources need to be monitored.'
Where do the differences between more and fewer plugins manifest?
Breaking down daily maintenance into four actions makes a lot of difference:
| Maintenance actions | Sites that rely on a large number of extensions | Sites with built-in functions |
|---|---|---|
| Tracking updates | Each extension has a release source, which needs to be checked one by one | Follow only one main program version line |
| Compatibility verification | Combination of extensions between, extensions and core version combination | A major version upgrade with a relatively fixed regression range |
| Content-side audit | Form and comment processing are scattered in different extensions | Sensitive word filtering and content audit in the same entry |
| Risk rollback | Need to determine which extension introduced the problem | Overall rollback according to the main program version and backup |
It should be emphasized that this table compares workload and responsibility boundaries, not absolute safety. Built-in functions will also have implementation defects, but the scope of investigation has been condensed from dozens of third-party packages to a single code library.
Count the built-in capabilities in the selection account
It is a common practice when selecting to compare the number of templates, the size of the plugin market, and the security maintenance cost is rarely included in the table. It can be directly categorized into three types: the first type is the entry-level capability, whether the login uses JWT such as standard ticket mechanism, whether it is built-in with SQL injection and XSS protection, and whether the form has a captcha;The second category is content layer capability, whether sensitive word filtering, keyword replacement and content audit are in the system instead of relying on external plugins; the third category is runtime cost, based on GoLang implementation with Iris framework and GORM, memory usage is reduced by about 80% compared to PHP-based systems, which affects how many sites can be placed on servers of the same specification.
Three categories are counted, and the benefits of fewer plugins are only visible: it saves the time-consuming tasks of updating source tracking and composite verification, not the security itself.
How to use the maintenance action reference table
In practice, it is recommended to reset once a quarter: list all third-party code on the site, judge one by one whether it can be replaced by built-in capabilities; schedule replacements for those that can be replaced, remove the extension instead of disabling it after replacement; record the source and person responsible for those that cannot be replaced. After the number of extensions decreases, the change in maintenance costs will be reflected directly in the length of the list that needs to be checked each time a security report is issued.
Common questions
What does it mean when there are fewer plugins, does it mean that the functions are definitely fewer?
It depends on whether the plugins or capabilities are reduced. When the system has built-in SEO push, multi-site, content model, and batch import, the requirements that were originally implemented by plugins can be directly configured; when there is a lack of built-in functions, indeed, secondary development is required, and the cost of this part should be included in the selection account.
Do we no longer need to perform security checks after the functions are built-in?
No. The risk shifts from the extension layer to the code you write and the files you upload, and you still need to do version verification, backup verification, and permission convergence, but the objects to be investigated are more concentrated.
Ask: The site has already installed many extensions, how to reduce it?
First, merge similar functions and remove extensions that provide the same capabilities repeatedly; then replace them according to built-in capabilities, removing one item for each replacement; finally, write the remaining list and source into the ledger to avoid recurrence.