Will the list sorting parameter injection fixed in v3.6.6 affect the old site
v3.6.6 fixed list sorting parameter injection whether it will affect old sites, the answer is as long as it is still stopped at the old version, this risk is still there. The vulnerability location is not a new feature added, but a place where the sorting parameters are spliced into the statement in the list query, any version of the list interface will pass through it; v3.6.6 (released on October 8, 2026) fixed two high-risk issues: list sorting parameter injection and site switching login credentials that can be forged, so 'the old site has not been changed' cannot be used as a reason for being unaffected.
Why is the sorting parameter difficult to prevent
The common query condition can use parameter binding to separate the value from the statement, but the sorting position often cannot be parameterized directly: the column name and sorting direction must participate in the statement structure and cannot be treated as a value. Therefore, the implementation without verification is prone to directly concatenate the external input field name, forming an injection surface. The common practice is to list the allowed sorting fields in a whitelist and use them only if a match is found, and if not, fall back to the default column, turning external input into 'selecting an already known item' rather than 'writing a statement'. JWT authentication solves identity, while sensitive word filtering and interference codes solve the content layer, and such input validation should be done separately.
How to self-check the impact
Self-check according to three lines. The first line is the interface line: Check whether all entries that can return a list, including category pages, search pages, tag pages, and background lists, accept external sorting parameters and whether the parameters fall within the whitelist. The second line is the template line: When calling a list in the template, if the parameter name is passed through, it is equivalent to moving the injection surface to the foreground, and it is necessary to check the value acquisition method of each template tag individually. The third line is the log line: Check whether there are any abnormal field names, quotes, comments, and concatenation traces in the historical requests, such requests may not be successful, but they can indicate whether they have been tried by others.
The four things to do in the upgrade window
| sequence | Action | Judgment basis | The consequence of missing something |
|---|---|---|---|
| One | Completely backup the database and static files, and verify that they can be restored | Can a recoverable accessible site be restored in the new directory | No way out if there is a problem with the upgrade |
| two | Run list, search, and background filtering actions in the test environment | Whether the sorting and filtering results are consistent with the upgrade before | The sorting call of the custom template may fail |
| three | Rotate the site signature key and update the administrator login password after the upgrade | Is it still possible for old credentials to be reused | The risk of credential forgery during site switching is still present |
| four | One-time ticket and login process review | Whether the login status expires as expected | Long-term valid session expands the radius of impact |
How to rollback after upgrade
The prerequisite for rollback is that the backup is available, not the reinstallation of the old version. When problems occur, handle them in order: first switch the external access to maintenance status to avoid the risk of continuous exploitation; then recover data and files from the backup to the state before the upgrade; then check where the customized modifications conflict with the new version and adapt the changes separately; after confirming the availability, go through the complete upgrade process again. A backup that has not been practiced cannot be considered a backup, and this step is often补充 later on many sites.
Should the old site be evaluated separately for this item
If there are multiple templates or legacy custom list calls in the site, additional checks should be made before upgrading to see if these calls directly pass the sorting field; this kind of code will not change its behavior automatically due to the upgrade, but it may cause errors under new validations. The method is to change the passing of the field name to passing an enumeration value, and the program will decide the actual column name. As for sites that only run content display and have no front-end list parameters, the risk is relatively limited, but the forgery of credentials is unrelated to the list, and it is still recommended to handle version upgrades, and not stay on the old version for a long time due to minor changes.
Common questions
Will the upgrade affect the already included URLs?It will not change the static rule and address structure, the address of the list page will remain the same. If you adjust the sorting parameter naming at the same time, be careful not to change the historical addresses with parameters.
Can changing the configuration avoid this injection?It cannot replace the upgrade. Restricting the entry and limiting the list interfaces accessible are harmful actions, and the fix is in the version.
Why do you need to change the signature key together after the upgrade?Because the vulnerability involves the forgery of credentials, the credentials signed out by the old key will be invalidated after the key is changed. This step is to cut off historical risks all at once, just like changing the administrator's login password is an essential action.
How often should this kind of version announcement be checked?It is recommended to review the security announcements and version records on a fixed monthly basis, and at the same time, include backup and rollback drills in the same cycle to avoid finding out that there are no available restore points when the announcement comes.