When 90% of the extension plugins are having problems, the site should first tighten which layer?

Where should the site first tighten the layer when 90% of the problems come from extension plugins? The public data verified on the day is very indicative for the WordPress ecosystem: about 90% of the vulnerabilities come from plugins rather than the core, there are tens of thousands of sites attacked every day, and the weighted median time from vulnerability disclosure to mass exploitation is only 5 hours. These three points together show that the focus of governance is not on the core version, but on the extension layer - first tighten the quantity and source of extensions, and then talk about patch speed.

Where is the risk concentrated?

The security aspects of the content system can be divided into four layers: core program, extension and template, content and form entry, and runtime environment and account. The issues at the core layer are of greatest concern, but they are covered by the release process and testing; the number of extension layers is determined by the site itself, and an extension that is 'temporary convenient' will permanently leave an attack surface on the server. Ninety percent of vulnerabilities come from plugins, and this perspective is important because it shifts the governance responsibility back to the site maintainers.

Another piece of data that is easily overlooked is that attackers will inject code into legitimate core files and plugin files. This means that just looking at new files is not enough to detect anomalies, and the change time and content hash also need to be compared.

From public patches to bulk exploitation window

A window of several hours determines the order of actions. After the patch is publicly released, it relies on manual scheduling to update, and most sites are unable to keep up. The feasible approach is to break down the 'block first, then upgrade' into two steps: first, use access control, disable corresponding functions, or temporarily limit entry to reduce the attack surface, and then complete the version update in the next release window. Monitoring within the window period should look for abnormal logins, abnormal registrations, and new administrators, as these signals appear earlier than file changes.

Discuss the speed of the patch after collecting the number of extensions.

Follow this order when implementing on the ground:

• List all current extensions and templates, mark their use, the latest update time, and whether they are under maintenance;
• Extensions that can be directly unloaded by the system's built-in capabilities can reduce the number of objects that need to be tracked long-term;
• Extensions retained have a fixed source, only obtained from official channels, and modified versions from unknown sources are disabled;
• Record the version and disclosed status of each extension, and incorporate them into the monthly check;
• High-risk extensions are first verified for updates in the test environment before going into production;

After the number of extensions decreases, the workload of patch tracking will fall to an executable level. Conversely, while promising to 'follow up on patches first time', retaining dozens of extensions, the actual execution rate is usually very low;

What segment does the built-in filtering and backup cover?

The default defense line at the program level is responsible for reducing the consequences of single-point defects. AnQiCMS is built-in with JWT authentication and protection against SQL injection and XSS; the content layer also has sensitive word filtering and keyword replacement, content review, and anti-crawling interference code. These capabilities correspond to the bottom line when the extension is bypassed or the form entry is misused, but do not replace the extension governance itself.

The last part is about recovery capabilities. AnQiCMS's backup and recovery cover data and static files, in the sequence of handling after being attacked, it is necessary to isolate and verify the files first, and use a trustworthy backup instead of continuing to patch in the infected environment. The backup point should be saved outside the site, otherwise the same attack may simultaneously clear the site and backup.

Common questions

Question: Is it worth doing an expanded inventory for small sites?Yes, there are fewer people in small stations, and expanded inventory is exactly the action to reduce the long-term tracking burden. One-time organization can save subsequent multiple emergencies.

Question: Can the free expansion be used?Look at the source and maintenance status, not the price. Official channels, with update records, and those that clearly support the current version can be used; integrated packages with unknown sources have high risks.

Question: Is it okay to only update the core and not the extension?No, the vast majority of vulnerabilities come from the extension layer, and core updates do not cover this part.

Question: Is content review and anti-spam considered a security item?It is part of entry management. Forms and comments are common entry points that are frequently exploited, and review and filtering can reduce the probability of these entry points being used as a bridge.