Six hours before the patch was released, someone was already hacking it, how should we prevent that round of PHP remote execution?

Six hours before the patch was released, someone was already hacking, it is the most memorable fact in this round of PHP remote code execution vulnerability: the fix fell on October 21, 2026, while the attack attempts appeared six hours earlier than the patch. The seriousness of the vulnerability lies in the fact that attackers can run their own code on the web server without logging in, and WordPress carries 39.6% of the world's websites. The longer the waiting window, the larger the exposed area. The real defense is not at the moment of the patch release, but whether you can complete the three steps of 'confirmation hit—temporary suppression—upgrade verification' within a few hours.

Why are the six hours before the patch even more dangerous?

Exploit code often circulates before and after the patch is released: manufacturers provide repair instructions, which is equivalent to publicly disclosing the triggering conditions. Attackers can reverse the differences in the patch into requests, allowing them to test their hands on sites that have not been upgraded. There are three characteristics in these six hours:

• The defense side does not have a downloadable version yet, and can only rely on configuration and rules to hold on;
• The requests appearing in the logs are from unknown sources and are often ignored as spider noise;
• The application release window of shared hosts and maintenance stations is fixed at night, and the six hours fall outside the window.

Therefore, the criteria for judgment is not 'whether the patch has been released', but 'whether the exploitation conditions have been publicly disclosed.' Public disclosure is considered as in-the-wild risk.

First confirm three things for sites running PHP.

The first is the running version. List the PHP version of the web server, the program itself, and the extension modules it carries one by one, and there is no basis for discussion and repair if the versions do not match. The second is the entry surface. Most remote executions go through unauthenticated entries: form processing, file upload, template rendering, and external interfaces. List the anonymous accessible paths, which is more effective than checking each page one by one. The third is historical traces. Screen the access logs before the patch according to the suspicious parameter form, focusing on abnormally long query strings, encoded expressions, and execution records in the upload directory.

What is the difference between temporary relief and complete repair?

The value of temporary mitigation is to buy time, not to solve the problem. Rule blocking should leave a rollback switch, otherwise no one can take over when the business is blocked by mistake.

Check which places need to be verified after the upgrade

After the upgrade is completed, at least four categories need to be verified: whether the login credentials and JWT session need to be forcefully re-issued; whether the list query and sorting parameters can still be used to generate SQL injection; whether the output filtering of cross-site scripting XSS covers the newly added fields; and whether the sensitive word filtering and content review rules have expired after the version change. The source IPs, abnormal scheduled tasks, and modified template files that have appeared in the logs need to be aligned item by item. If it cannot be confirmed to be innocent, reset the administrator password and rotate the signature keys of each site, which is faster than repeatedly checking.

How are similar high-risk issues in AnQiCMS repaired

The two items repaired in v3.6.6 (2026-10-08) are of the same approach: no 'construction space'. The list sorting parameter previously allowed a limited degree of SQL function expressions, the validation only looked at whether the first and last characters were quotes, which could be combined into a time blind note; now it has changed to a strict identifier whitelist, only accepting column names,表名.列名With ascending and descending order keywords, the rest are all discarded and fall back to default sorting. The original multi-site jump login used the password hash as the signature material, the random string can be repeatedly generated, and the ticket does not expire;Now it is replaced with a one-time ticket issued by the server, valid for 120 seconds, and it becomes invalid after one use, along with account status check and IP error locking.Upgrade prompts require the rotation of site signature keys and the modification of the administrator password - this is the same experience as 'Session must be checked after patching'. At the daily level, built-in JWT authentication, sensitive word filtering, content review, and anti-interference code for collection prevention narrow the scope that can be triggered anonymously, and backups (including static files) determine whether it is possible to roll back after an issue occurs.

Common questions

Should the service be stopped first when there is no official patch?First, check if the entry is anonymously accessible. If it is an entry such as upload, template rendering, or external interface, temporarily closing is safer than holding on; if only secondary functions after login are hit, you can first restrict the access range and wait for the fixed version.

Is it enough to just upgrade?Not enough. What the upgrade eliminates is the triggering condition, and all established sessions, scheduled tasks written, and template files modified need to be checked separately. If there is any doubt, reset the credentials.

How can you judge whether you have been hit?Compare the access logs before the patch time window with the file modification time, focusing on the execution records in the upload directory, abnormal length query parameters, and accounts with excessive permissions in the database.