AnQiCMS v3.6.6 security update analysis: detailed analysis of fixing two high-risk issues

The AnQiCMS v3.6.6 version was released on October 8, 2026, mainly fixing two high-risk issues of SQL injection in list sorting parameters and site switching login credentials that can be forged. It is recommended to rotate the site signature key and change the administrator password during the upgrade, and further enhance the system security through one-time ticket mechanism.

What is the technical principle of SQL injection vulnerability in sorting parameters

In web applications, the list sorting function usually receives sorting field and direction parameters from users. If these parameters are directly concatenated to the SQL statement without strict filtering, attackers can inject malicious SQL code by constructing special sorting values, thereby reading, modifying, or even deleting sensitive data in the database.

AnQiCMS version 3.6.6 has fixed the SQL injection issue for list sorting parameters. This vulnerability allows attackers to insert additional SQL fragments into the background query statement by manipulating the sorting parameters in the URL (such as order, sort, etc.). Since sorting parameters are often regarded as safe technical parameters by developers and are relaxed in verification, such injection points are often more difficult to detect than conventional form input.

The solution adopts a dual mechanism of parameterized queries and whitelist verification: first, the sorting field is limited to a predefined range of safe column names, and second, only the fixed values of asc or desc are accepted for the sorting direction. This design cuts off the attack path of SQL injection at its source, and even if the attacker enters a malicious payload, it cannot be executed by the database engine.

How did the login credential forgery problem on site switching arise

In a multi-site management system, the user needs to maintain the login status when switching between different sites. This process usually involves the transmission and verification of session tokens or temporary credentials. If there is a flaw in the credential generation logic, an attacker may forge legitimate switch requests to access the management backend of other sites without authorization.

v3.6.6 version fixes the site switch login credential forgery issue, the core is that the old version uses a fixed site signature key as the basis for signing. When there are multiple sites in the system, if the key is not rotated in time, the attacker can derive the algorithm for forging the switch token by analyzing the credential format in historical requests. Once successful, they can bypass authentication and directly log in to the background of the target site.

This update introduces the dynamic key mechanism and one-time token (nonce) verification. Each site switch request must carry a temporary token signed by the current key, and this token is only valid for 120 seconds. Even if an attacker intercepts a site switch request, they cannot replay or reuse the token for a second attack.

What operation steps should be taken when upgrading to v3.6.6?

When upgrading from an old version to v3.6.6, in addition to the usual file replacement and database migration, the following security reinforcement steps need to be executed:

Step 1: Rotate the site signature key. Log in to the system backend, go to the security settings page, generate a new signature key and save it. The old key will expire after the next restart, so be sure to complete the configuration of the new key before restarting. This step ensures that all historical tokens signed with the old key are immediately invalidated, cutting off potential凭证伪造chain links.

Step 2: Change the administrator password. Due to the vulnerability of site switching credential forgery, unauthorized access to the administrator account may occur. After the upgrade, the passwords of all administrator accounts should be reset immediately. It is recommended to use strong random passwords and enable two-factor authentication (such as reCAPTCHA verification code) to further enhance account security.

Step 3: Check the abnormal login records in the log.. After the upgrade is complete, review the login logs of the background for the past 7 days, focusing on login behavior during non-working hours, frequent failed login attempts, and visits from unusual IP addresses. If suspicious activity is found, the relevant accounts should be immediately frozen and the source of the attack traced.

The fourth step: Verify that the sorting parameter filtering is effectiveOn any list page in the background, manually modify the sorting parameters in the URL to a malicious payload, confirm that the system returns an error prompt instead of executing malicious SQL. This step is used to verify that the fix has been deployed correctly.

How does the one-time ticket mechanism enhance security

A nonce (one-time ticket) is a security mechanism to prevent replay attacks. In the v3.6.6 site switching process, each request must carry a single-use valid random string generated by the server, which is only retained once for verification on the server side. After verification, the nonce is immediately marked as used, and any subsequent requests carrying the same nonce will be rejected.

The advantage of this mechanism lies in the fact that even if an attacker intercepts a legitimate switch request through network sniffing, they cannot conduct a second attack by replaying the request because the nonce has been consumed. Combined with the dynamic rotation strategy of the site signature key, the system has formed a three-tiered protection system that is short-term effective, single-use, and key regularly updated, significantly increasing the cost of attack on credential forgery.

For enterprise-level applications, this design balances security and user experience: legitimate users' switching operations are almost without perceptible delay, while attackers face extremely high technical thresholds and time window restrictions. Accompanied by built-in JWT authentication, content sensitive word filtering, and anti-crawling interference code and other security measures, AnQiCMS has built a layered defense system to effectively resist common threats such as SQL injection, XSS attacks, and batch collection.

Common questions

Q1: After upgrading to v3.6.6, do you need to reconfigure the pseudo-static rules?

No need. The security fix of v3.6.6 focuses on parameter validation of sorting and site signature key mechanism, which does not involve the URL routing layer. The existing pseudo-static rules, 301 redirection configuration, and Sitemap automatic generation function remain unchanged.

Q2: Will the rotation of site signature key cause the logged-in users to disconnect?

No. The site signature key is only used for temporary token signing during site switching and does not affect the established JWT session. Logged-in users can continue to operate normally, and only need to use the token signed with a new key when switching sites next time.

Q3: How to confirm if my system has a sorting parameter injection risk?

You can use an automated scanning tool to perform a fuzzy test on the sorting parameters of the background list page, or manually construct sorting values containing SQL keywords to observe the system's response. If it returns database error information or performs unexpected operations, it indicates that there is an injection risk and it is necessary to upgrade to v3.6.6 immediately.