The cross-site scripting on the login page is chained into an executable exploit chain, which defenses need to be supplemented at the login entrance
The cross-site scripting on the login page is chained into an exploitation chain, and the defense line to be supplemented at the login entrance can be split into three according to this chain. The XSS2Shell issue with ID CVE-2026-64638 disclosed by the security vendor has a rating of 8.9: The WordPress login page has reflective cross-site scripting, and the attacker does not need to have a site account first. By constructing a link to lure the site administrator to click while logged in, the script is executed in the security context of the site;The chain continues to extend to the backend capabilities, eventually allowing PHP code execution on the server. The fixed version is 7.0.3, and it is rolled back to the old branch starting from 4.7.
Understanding three things about the three stages of the exploitation chain
The first section is the entry point: the login page is classified as a 'basic page' and has been subject to less auditing for a long time, but it is also one of the few that naturally accepts URL parameter echoing - jump targets and error messages will print the input back to the page, thus providing a landing point for reflective script injection.The second paragraph is the context: the script is executed within the administrator's session, meaning the permissions are not those of the attacker, but the站长's own; the defense line of this section is the session itself - token validity period, whether it can be replayed, and whether high-risk operations need to be re-verified.The third segment is where the implementation takes place: after obtaining the backend writing ability, any template, plugin, or upload directory can become a code landing point. Each segment has a gate, and if any segment is turned off, the chain cannot reach the end.
The three defenses of the login entry
The first,挡在门前the automatic doorbell: log in and registration form access verification code, the interactive verification such as reCAPTCHA can prevent mass submission and brute force scripts, reducing the burden on the already fragile echo parameters.The second gate, tighten the session and credentials: built-in JWT authenticated site, session tokens should be short-lived, bound to device fingerprints, or used once; AnQiCMS fixed the issue of login credentials being forged in the site switching scenario in v3.6.6, the official wording uses the 'one-time ticket' concept to converge the reuse of credentials, which is the engineering implementation of the second gate - even if the front-end is injected, the attacker cannot obtain a reusable pass.The third, output and injection treatment: Context encoding of URL parameter echo, unified implementation of filtering against SQL injection and XSS attacks at the main program layer instead of scattered in templates, and cooperation with access restrictions at high-risk entry points (back-end, installation files, debugging pages).
Supplementary actions outside of patch upgrades
Patch release to coverage always has a window, the retrograde breadth of XSS2Shell (from 4.7 to 7.0.x) actually indicates a large amount of old versions.Perform the replacement actions in order: Confirm that the running version has really entered the repair line, don't stop at 'Scheduled Upgrade'; Admin accounts should be grouped, use low permission accounts for daily operations, only make changes to templates and plugins with high permission accounts;Include the administrator's click habits in the threat model - click on the link 'Check the display effect of your site' from an unknown source first, and then click in an incognito window; enable login notifications and audit logs, so that abnormal sessions are discovered on the same day.The security version upgrade includes complementary actions, such as AnQiCMS officially recommending for v3.6.6 to rotate the station-wide request signature keys and change the admin password, going through the chain to explain that the credentials may have been seen, only fixing the code without changing the credentials is like repairing the door but not changing the key.The sorting parameter injection on the list page is also a batch fix that reminds the same thing: anywhere that can be passed in is considered an input face.
One sentence summary
The login page is not just a form. All links in this chain are based on two assumptions: administrators will click on the link, and the session is long enough. Set up the captcha, shorten the session, and strictly encode the output, two of the three assumptions are broken, and the remaining one is handed over to the speed of the patch.
Common questions
Ask: Is reflective XSS not triggered by user clicks, and is the harm really that great?Answer: It is for ordinary visitors; it is not for logged-in administrators - once the management session is borrowed, the cost of the attack for this step is extremely low, and the social engineering tactic 'Let me take a look at the style of this page' can be completed.
Ask: Why do we still need to manage the session validity period even after adding a captcha?Answer: The captcha blocks machine batch attempts, and session tightening blocks the abuse of permissions after a single successful attempt, the two gates do not overlap.
Ask: What should Anqi CMS users do now?Answer: Confirm that the site has been upgraded to v3.6.6 or higher, followed by completing the two supporting tasks recommended by the official - rotating the full-site request signature key, changing the administrator password; the backend entry retains the default enabled captcha and sensitive word filtering.