v3.6.6 fixes the list sorting parameter injection issue, how to schedule the upgrade window?

v3.6.6 fixes an injection issue with the list sorting parameters, and also resolves the path where credentials can be forged during site switching login. Both are high-risk issues, and the upgrade window should not wait until quarterly maintenance. The arrangement can be fixed with one sentence: stop writing during off-peak hours, back up first, and then回归each fix point after the upgrade. AnQiCMS released v3.6.6 on October 8, 2026, and also provided upgrade action suggestions in the release notes, such as rotating the site signature key and changing the administrator password. These two steps are easy to overlook, but they determine whether the fix is really effective.

Which links are affected by the two fixes respectively

The list sorting parameters follow the query chain used both by the front and back ends: sorted by time, popularity, and custom fields, the parameters must be constrained before being拼进查询语句。This kind of trouble lies in the fact that it is exposed on the read interface, anyone can construct a sorting parameter to test. The site switching login credentials are another path, in multi-site management, when jumping from one site to another, the identity credentials need to be carried, under the old practice, this credential exists the possibility of forgery, in the new version it is replaced with a one-time ticket: The ticket is only valid for one session, used up and discarded, and the old ticket cannot be replayed.

Why place the window during the off-peak

Fix the coverage interface reading and login link, it is usually necessary to restart the service during the upgrade process, the list page and background login will be temporarily unavailable before and after the restart. The choice during off-peak hours is clear: it is better to let dozens of visitors wait for a refresh than to interrupt indexing and push in the peak of publication. If the site is configured for scheduled publication, attention should also be paid to whether the effective time of those pending publications has been delayed after the upgrade - publication time is an operational agreement, and changing it requires notifying a round every time.

Before upgrade: backup and stop writing

The first step is to back up, the backup range includes database data and static files, and sites that only back up the database will find that pictures and uploaded attachments are missing during recovery. AnQiCMS's backup and recovery include data and static files together, and recovery is done with the same package. The second step is to stop writing: close front-end submission and back-end editing, so that the data at the moment of upgrade is in a static state. The third step is to record the current version number and running parameters, so that the rollback target is clear if needed.

After the upgrade: three verification actions

The first verification of sorting parameters: use ascending, descending, and illegal field names to request the list, the page should return a normal empty result or default sorting, rather than an exception stack or syntax error. The second verification of site switching: switch from one site to another, confirm that the login state follows the switch, and the old ticket is no longer available after logout. The third verification of background permissions: confirm that high-risk operations are still closed by default in the domain, such as backup, upgrade, and multi-site actions that require explicit enablement before exposing to interface callers. Write these three into the regression list, and run the same list next time the upgrade.

Conveniently collect the exposed surface.

Upgrading is the time to tighten configurations. Check whether you are still using the default administrator name, whether unnecessary high-risk intent domains are open to the outside, whether the captcha and content filtering cover the forms and comment sections. Fixing and configuration tightening can reduce the risk surface faster than a single-point upgrade.

Another version rhythm is worth paying attention to. v3.6.5 was released on 2026-10-07, 1 day apart from v3.6.6, and the 120-day rhythm after 3.6.5 indicates that security fixes will follow the version. Personal website owners and small and medium-sized enterprise websites often delay security fixes when they upgrade with major features. The approach is to divide upgrades into two categories: security versions are scheduled immediately according to the low-peak window of the announcement, and feature versions are scheduled according to their own iterations.

Common questions

Do I have to stop writing before the upgrade?Small data volume sites can be continuously running, but stopping writing can ensure data consistency during backup and upgrade periods, and there is no need to judge which records are newly written when rolling back.

What if the signature key is forgotten?The repair itself is still effective, but the risk of historical credential forgery has not been completely closed; key rotation and administrator password modification are the other half of the repair action.

Can the upgrade be directly overlaid online?It is recommended to run three verification actions on the copy or trial site first, and then go to production; the background path of the trial site is completely consistent with the online one, and the verification cost is low.