Core vulnerability reports in the wild exploitation, which part of the website should be patched first?
It is reported that this core vulnerability is already being exploited in the wild, and the website needs to patch which part first? Patch that entry point that can execute code without an account first. Taking the alert issued by the Singapore Cybersecurity Agency in September 2026 as an example, it states that attackers are exploiting a high-risk WordPress vulnerability under certain conditions to achieve remote code execution and requires immediate patching: The vulnerability is marked as CVE-2026-87902, with a rating of 8.1, affecting versions prior to 7.1.2. 'Already in the wild' means it is no longer an issue waiting for the maintenance window, but a matter of the day.
What has野外利用改变
Regular vulnerability handling can be scheduled into the plan: assess the impact, schedule in the maintenance window, and go live according to the change process. Once confirmed that there is an in-the-wild exploitation, the time budget for the first two steps is directly compressed because the exploitation method has been made public or scanned in bulk by automated scripts, and unpatched sites will be repeatedly probed within one or two days.
Determine which category it belongs to, see if there are these three types of statements in the notice: whether there is public exploit code, whether there has been observed attacks on real sites, and whether the wording 'patch immediately' is given. If one of the three is true, it will be arranged for handling on that day.
How to arrange the patch order
The sorting criteria is not based on the rating, but on whether it can be triggered anonymously and the extent of the fix. The following table shows the order of handling common situations.
| Situation | Disposal priority | Description |
|---|---|---|
| Remote code execution without login | On the same day | First fill the core, then supplement the extension of the same chain |
| Administrator privileges are required to trigger | This cycle | Scheduling after tightening the number of accounts |
| Information leakage class, lower rating | Scheduled | Focus on whether it can be combined for use |
| Unable to upgrade temporarily | Immediate relief | Hold up with restrictions and rules while queuing for upgrade |
For WordPress sites, the first step is to upgrade the core to version 7.1.2 and above, as the affected range falls within the core; plugins and themes are ranked second, but do not end after completing the core upgrade - the same batch of scans will continue to attempt to update un-updated plugins.
What can be done temporarily when it can't be fixed
When an upgrade cannot be done immediately, the means of alleviation should be clear in terms of boundaries: restricting the execution permissions of the upload directory, limiting the access sources of the background entry, and intercepting requests with obvious features at the gateway layer all belong to reducing the probability of being hit, but do not equal to fixing. If the path is on a public interface, any scheme that relies solely on outer layer interception cannot be relied on for a long time.
Temporary measures should record the effective time and invalidation conditions, and set a clear upgrade deadline. Many sites 'temporarily' lasted for half a year, and in the end, the program that was not upgraded was still hit.
There is another type of entry that is easy to miss on the program side. AnQiCMS fixed the SQL injection issue with the list sorting parameters in v3.6.6, and the same version also dealt with the defect that login credentials could be forged when switching sites. The official upgrade suggestions require rotating the site signature key and changing the administrator password. Such issues are similar to core patches: the injection point is hidden in the parameter concatenation, and patching only one place does not equal the entire chain is secure.
After completing it, check which items
The patch just closes the entrance, but sites that have been hacked still need to confirm that nothing was left behind. Four must-check items: Are there any unknown members in the admin account, are there any new scheduled scripts in the task schedule, are there any unfamiliar files in the upload directory and template directory, and have the site map and external links been altered?
Add two more verification items: Is the backup still usable and the timestamp earlier than the suspicious changes, and can the recovery process really be implemented. AnQiCMS backup and recovery cover data and static files, and this level of value in emergencies is to let you dare to clean up thoroughly, rather than make do in a polluted scene.
The final step is to leave a trace: record the version, time, verification results, and residual risks of this disposal. Next time, the same type of report can be reused directly as a judgment basis.
Common questions
Is it okay to only upgrade the core and not the extension?It covers the current report, but the extension vulnerabilities that are being scanned at the same time will not disappear due to the core upgrade. It is recommended to deal with them together.
Can we take a break if there is no publicly available exploit code?Highly rated and anonymous triggers are defects, and public exploitation is usually just a matter of time. Patching and repairing is betting on time differences.
Can changing the configuration file replace the upgrade?No. Configuration layer means only change the trigger conditions, and the defects in the code still exist.
How often should you check for new bulletins?At least monthly, and combining with the security bulletin subscriptions of the programs and extensions you use, passive event notifications are often late.