The website itself was not hacked, but the server control panel could be attacked by a regular account to the highest privileges, let's see which layer first.
The website itself was not hacked, but the server control panel could be accessed by a regular account with the highest privileges. The sequence of investigation for such events is: first, check the account and permission group layer, because the triggering condition is a 'logged-in regular account';Check if the high-risk operation at the entire site level is in the default closed state; finally, confirm whether the backup and rollback path can be used. This notice (corresponding to CVE-2026-65643) included in the national vulnerability library states that the backend of the WebPros cPanel server before version 11.110.0.141 has a dynamic code injection flaw in the process of handling domain-related parameters, allowing an attacker with a regular cPanel account to execute arbitrary code as root after logging in.
Why is the control panel more important than a single site
If a site is hacked, the impact is usually this content, this database; if the control panel is hacked, the impact is all sites on the same machine, all account login credentials, DNS and backup files. It is responsible for the 'site management privileges', once root is obtained, each site on the same machine must be treated as leaked.
So the judgment criteria in the event response should be changed: do not infer that 'the server is okay' from 'this site has not been compromised'. The interface calls of the control panel will not leave any traces on your site's page, the logs are on the panel and the system level.
Look at the triggering conditions in the notice separately
This vulnerability has three prerequisites, each corresponding to a category of positions that can be tightened.
The first is the account: it requires holding a regular account, indicating that the attack surface is after 'able to log in'. The account source needs to be reviewed - past employees, outsourced colleagues, shared test accounts, and leaked third-party application authorizations, each one needs to be asked whether it is still in use. The second is the interface: the vulnerability is in the processing flow of domain-related parameters, the caller is the panel API rather than the site front-end, and conventional Web application protection cannot see this kind of request. The third is the version: whether affected is only determined by the version after the repair in 11.110.0.141, and the configuration can only reduce the probability.
Which layer should the account and permission group be received first
First receive the group, then the number. Break down the matter of 'being able to log in' by responsibility: only give the background editing permissions to content editors, operate separately for operation and maintenance, and do not merge financial or order-related permissions with other roles. AnQiCMS's user management and VIP group support setting access permissions for different user groups, giving capabilities to groups instead of individuals for accounts, and reducing the situation of 'giving full permissions casually when temporarily needed.'
Suggested cleaning order: List all active accounts and their last login time; shut down accounts that have not logged in for more than a quarter; change shared accounts to personal accounts and enable two-factor authentication; mark the use and responsible person for retained high permission accounts.
Why should site-wide operations be turned off by default?
The stronger the multi-site management capability, the higher the cost of a single误operation. AnQiCMS's interface sets the exposure range by intent domain, and operations such as backup, upgrade, and multi-site are set to be disabled by default, requiring explicit enablement (DefaultOff). External AI clients can only act within the domains you open, and will not gain all capabilities just because a token is valid. This is not a lack of functionality, but a limitation on how far a 'normal account' can go after being compromised.
The sequence of fallbacks after an incident
Firstly, block the entry: disable suspicious accounts and revoke panel access; then secure evidence: export the panel and system logs, do not reinstall before evidence collection; then restore from backup. The backup and recovery of AnQiCMS cover data and static files, only when the recovery point is available can we talk about making the reconstruction of the site a controlled action. In terms of deployment, for those using the one-click deployment of Baota Panel or aaPanel, pay attention to the version of the panel itself; for those deploying via Docker image anqicms/anqicms, the control panel is on the host machine, and the container needs to be updated separately when running, not just relying on the panel prompts.
Common questions
Is the control panel login not open, do I not have to worry about it?Check if the operation and construction parties share the same machine and if there are any historical accounts. The 'normal account' in the attack conditions is likely to come from a third-party collaboration party.
Can changing the password replace the upgrade?No. The credential rotation only affects the subsequent login, whether the vulnerability can be triggered is determined by the version, and the two things should be recorded separately.
How can you determine if it has been exploited?Pay attention to the abnormal calls of the panel API, domain and account changes during non-working hours, and the new scheduled tasks appearing at the system level; export the logs first and then deal with the abnormal situation.