The total number of vulnerability libraries is increasing day by day, should the webmaster pay attention to the total amount or the increase?

📅 2026-11-01 👁️ 0

The total number of vulnerability libraries is increasing day by day, should the webmaster focus on the total amount or the new ones? The answer is to focus on the new ones, but to pay attention to the 'new ones related to this site'. The total amount answers the ecological level question - the scope of collection is expanding, and vulnerability mining is accelerating;It cannot answer the specific situation of any site because more than 90% of the entries in the library have nothing to do with what you have installed. The page of the vulnerability library reviewed that day states: This vulnerability library for the WordPress ecosystem has a cumulative total of over 55,900 entries, including over 18,000 entries with缓解 rules already established, over 13,000 entries marked as having no official patch, and over 900 entries still in the diagnosis stage.

What questions do the two口径 respectively answer

The total amount is suitable for viewing once a quarter. Its changes indicate three things: whether the collection range of the library has expanded during this period, which type of component is covered more, and whether the relative proportion of official patches and mitigation rules has changed. These are trend information, not action instructions.

Add suitable for scanning every day or every two days, but only look at one question: Whether the component name appears in your list, and whether the version you installed falls within the affected range. The rest are irrelevant to this week's work. Mixing the two together is easy to make two mistakes: seeing an increase in total and panicking to upgrade in bulk, or ignoring the truly hit new entries because 'they are all old entries.'

Why can't the total be used directly as a risk indicator

Three reasons. Firstly, the library is cumulative across versions, and many entries correspond to old branches that have been eliminated; secondly, the same defect may be collected repeatedly from multiple sources, and the number of entries does not equal the number of independent risk items; thirdly, the entries contain a large number of paths that require specific conditions to be established, and theoretical feasibility and those already in the wild are two completely different levels of handling priority. The proportion of the triage stage and the absence of official patches should also be taken into consideration: even if there are a large number of entries without patches, all that can be done is to tighten the access scope and add alerts, which should not be queued in the same column as entries with patches that can be installed immediately.

How to filter out related entries on this site

The premise of filtering is to have a list. The list should be able to be exported regularly: the main version of the program, the name and version of each component in use, and the anonymous accessible address. Manual flipping of the background will miss, and a more stable approach is to go through the interface for batch verification - The AnQiCMS (AnQi CMS) interface document covers high-frequency capabilities such as document list and details, categories and tags, system and settings reading, etc. API calls can retrieve the in-use components and versions at one time, and then compare them with the search results of the vulnerability library; this step can also be配合 with the full-text search entry on the site, to check suspicious wording and old drafts at one time.

After filtering, only three fields are retained: component name, current version, and impact range. Only when the three fields match will it enter the disposal queue.

After filtering, what order should be disposed of?

Sort by whether it can be triggered anonymously, not by the entry time of the item. The first tier is anonymous and has been in the wild, to be handled on the day; the second tier is anonymous and theoretically feasible, to be scheduled into the nearest maintenance window; the third tier requires a background account or privileged role, to first tighten the account and permissions, and then wait for the window; the fourth tier requires custom code to be established, to be recorded and observed.

No matter which level, there must be an available backup before taking action - ensuring that data (including static files) is backed up and can be restored is the premise for making 'take a look first' a safe practice. Measures such as SQL injection and XSS protection at the program level, JWT authentication on the interface side, and sensitive word filtering and anti-crawling interference code on the content side can reduce the scope of impact, but they cannot replace the upgrade and rollback plan.

Common questions

Should I subscribe to all vulnerability updates?No. Subscribe to the results pushed according to the component list matching, and the unmatched entries are just noise.

What does a sudden jump in the total amount indicate?Generally, the library confirms whether there are components from this site in the newly added ones before complementing the historical collection or expanding the coverage range, and then judges whether it affects itself.

Should entries without official patches be followed separately?Yes. They should enter the tracking list and be handled uniformly after the patch is released, during which access restrictions and log alerts are used.

Related articles

After AI capabilities entered CMS, why does the background also need to be managed as an attack surface?

The AI ability makes the background go from 'viewing content' to 'being able to act': one conversation can write libraries, change configurations, and adjust interfaces, making the login state and interface credentials high-value targets. The management method is to tighten three types of login-free interfaces separately, set exposure ranges according to ability domains, retain operation approvals, and pay attention to security changes at the version level. The two types of high-risk issues fixed in the current version exactly illustrate that the input on the backend side and the login tickets should be treated as attack surfaces.

2026-11-01

When connecting a large model, should it be done using a third-party module or the built-in capability, and where do the risks differ?

The risks of the two routes differ in who holds the key and permissions, and whether the entry point of the capability is controlled. The third-party module packages the model key, write permissions, and call links into the extension, and needs to be upgraded in bulk once the upstream issues an announcement; the built-in capability converges the entry point within the program, and can set the exposure range by domain and perform operation approval by round. The selection should consider the density of announcements and the boundary of permissions, not just whether this feature exists.

2026-11-01

Where does the difference lie in a self-built program that can run with 1GB of memory and 256MB?

The difference in memory threshold of self-built programs mainly comes from the running mode rather than the number of functions: the stack of resident application servers and databases consumes more memory than the combination of single-process running and lightweight storage. The criteria reviewed that day clearly divides the two types of thresholds, and the selection should be judged by three factors: concurrency, whether multiple sites are shared, and whether expansion is necessary, rather than ticking off the feature list. Memory usage belongs to the official approximate criterion and cannot be taken as an exact multiple.

2026-11-01

The major versions of the program are all released in the first week of December, how to stagger the upgrade window?

Mid-December, that week was busy with two things: the release of a new major version and the discontinuation of the old version, with human resources and verification windows overlapping. The solution is to group sites by exposure, starting with small stations and then the main stations, leaving time for re-examination between batches, and scheduling content release outside of the window using timed publishing. When multiple sites share a single backend, grouping and batching is the premise of continuous business, and the rollback speed depends on the deployment method.

2026-11-01

After the release of LLMs.txt, ninety percent of the files were not requested, is this number looking at the access log?

Yes, these extremely low transaction rate numbers come from the site's own access logs: first, filter out the domains that have placed files, and then check the server logs for corresponding crawling requests. The two sets of criteria reviewed that day need to be read separately, one is the adoption rate, which measures how many domains have placed files; the other is the read rate, which measures whether there are requests after placement. The two cannot be mixed into one sentence.

2026-11-01

To what extent has the number of times the site blocking the training crawler has been cited by AI dropped?

The sample reviewed on the day is over a thousand domain names, the proportion of blocked training crawlers varies from 17% to 14%; the sites blocked by search crawlers have a difference of two orders of magnitude in the number of times cited compared to those not blocked. This does not mean that the entire site should be allowed to pass, but rather that it is more cost-effective to grade by page type: product and document pages are allowed to pass, while draft and low-value archived pages are blocked.

2026-11-01

AI referral sessions only account for 1% but have higher conversion rates, which two indicators should you believe first

Believe in the conversion rate first, but use it to test the reception ability, not directly as an expansion basis. The review on the day was: across more than ten thousand domain names, AI recommendation on average only accounts for about 1% of the total sessions, but the conversion rate of recommended visitors is much higher than that of natural search sources. The share index fluctuates greatly and is affected by the entry; the quality index is more suitable for long-term baseline, ensuring that a small number of highly interested visitors do not lose interest first.

2026-11-01

About one in ten sites that are directly rejected by the crawler, should we check robots or service configuration first?

A nearly 10% of the sites return a denial status code to the crawler, the troubleshooting sequence is to first check the server configuration rather than change the robots file: robots is just a polite guideline, a denial code means the intercept occurs at the service layer. Locate by grouping status codes for rules, firewall, or pseudo-static, and verify layer by layer, changing only one layer at a time, so that the robots file is changed but the denial code remains the same.

2026-11-01