So Outside Technology Security CMS
AnQiCMS
Online Demonstration

Why do we need to tighten the registration entry first and then patch the multi-site user registration open?

📅 2026-11-01 👁️ 0

Why does a multi-site with open user registration need to tighten the registration entry before patching? Because the triggering conditions of this kind of risk are composite: the site network is open for registration, and ordinary users can come in; after entering, if they can create a new site, it constitutes a privilege escalation. The patch needs to fix the latter half, while the former half is in your hands. Shutting down the registration entry reduces the attack surface from 'everyone' to 'registered users', gaining a window for patching.

What is the triggering condition of this risk

The official fix list has written it very specifically. WordPress listed a privilege escalation issue on a multi-site network in version 7.0.3 released on August 6, 2026, the condition being that user registration was enabled, resulting in ordinary users being able to create a new site. The list also includes a server-side request forgery issue related to link verification, as well as several storage-based cross-site scripting and information leakage items, all part of the same security version release.

What does this combination condition mean: Not all deployments are affected, but the scope of the affected batch is not small. The multi-site network is itself a feature, and the open registration is an operational requirement, and both need to be叠加 to exist, so what if we only talk about 'quickly upgrade' and miss the window period?

Why does open registration matter

Registration is the starting point of this chain. After the registration is closed, the attacker cannot obtain the account with the lowest permissions, and the path for the construction of new sites also does not exist. This is not reducing the risk, but removing one link of the exploitable conditions.

Looking from the other side, relying solely on registration review is also unstable. In a multi-site network, the permissions for newly created sites often follow the default user group settings, and the user group grants site creation rights rather than content rights; review can only block bulk registration, but cannot block accounts that have already混进来的账号。So both gates need to be implemented together: registration entry and new site permission.

Two temporary gates before the patch

The first is to turn off or tighten the open registration, change it to an invitation system or manual review, and suspend related batch registration forms. The second is to tighten the user group permissions, remove the 'can create a site' item from the permission package of ordinary users, and only retain the ability to submit content.

Do a backup before the two gates. The idea of self-built programs like AnQiCMS can be directly referenced: backup the data and static files before changing the permission configuration, so that there is a fallback position; if changing permissions will affect the visible range on the front end, it is also necessary to reserve some time for verification.

After the upgrade, there is still a third step. The AnqiCMS in this v3.6.6 release fixed the injection issues related to the list sorting parameters, as well as the login credentials that could be forged during site switching. The upgrade recommendations also require the rotation of the site signature keys and the modification of the administrator password. The conclusion is the same for other programs: patching vulnerabilities does not mean they are completely patched, and credential rotation and permission review must follow.

What should be reviewed after the patch is applied?

First, check the sites created during the window period: the patch only repairs future requests and will not delete the sites that have already been created. You need to check in reverse order of creation time and confirm the attribution and content of each newly added site within the window period. Second, review the default values of the user group and access permissions to confirm that the temporary tightening has not rolled back to the original state. Third, review the credentials: whether the signature key and the administrator password have been rotated after the upgrade, and do not allow old credentials to remain valid.

It is essential to write this incident handling into the operation and maintenance record: what conditions triggered it, which two gates were lowered, when the patches were applied, and how the review results were. When dealing with similar issues again, this record is more reliable than memory.

Common questions

Q: Will closing registration affect normal users' entry? A: Yes, so temporary measures will be taken: the window period will be tightened, and registration will be restored in the required manner after the patch verification is passed.

Q: Is it okay to keep registration closed without upgrading? A: It cannot be a long-term solution. There are other entry points in the chain, and there are also cross-site scripting issues that can be triggered by unlogged-in users in the list of the same version.

Ask: What level of detail should be seen when checking the site back? Answer: Search for newly added sites within the window period by creation time, and confirm each one's ownership, content, and whether it has been used for external promotion.

Related articles

The new default intercept value only manages new domains, old domains need to be moved manually.

The new default blocking value on the platform only applies to newly connected domains, while the old domains already on the platform need to manually fetch and control this layer: first confirm the current effective values for training, proxy, and search categories separately, then merge them with the existing robots rules on the site, and finally verify with the real return status. The default value will not automatically overwrite existing configurations, assuming it has already taken effect is the most common judgment error.

2026-11-01

Is there any advertisement on the page, and will it change whether the AI crawler can read the content?

Whether there is advertising on the page will indeed change whether the AI crawler can read the content: the new platform default value treats whether to display advertising as a judgment condition, the pages with advertising are intercepted by default for training and proxy types, and the search type continues to pass. This rule is not in the robots file, but occurs on the platform side, so there may be two sets of visibility in the same site with advertising templates and without advertising templates, and it should be checked separately according to the template.

2026-11-01

Why would the proportion of different AI crawlers intercepted by the same site differ by a few points?

The same batch of sites intercepts AI crawlers from different manufacturers, and the intercept ratio differs by several points, mostly due to the rules being written according to the user group name, while each proxy's identifier is not just one: omitting one will result in a difference in the ratio. When checking, first distinguish between the three meanings of no file, empty file, and release, and then rewrite the rules by grouping for use, and finally verify the returned status of each one by using the site map entry and real crawling records instead of just looking at the configuration text.

2026-11-01

The proportion of AI crawler interception changed between two months, is it changed by the default value of the platform or the webmaster?

The same batch of domain names has changed the proportion of AI crawler interception in two months, most of which come from the launch of platform default values, not from webmasters changing configurations one by one. By looking at the direction of change, it can be distinguished: the displacement is concentrated on the training and proxy sides, while the search class has not moved much. When comparing, first lock the same caliber and the same industry level, and then confirm the configuration of robots files, platform classification switches, and in-site exit one by one, changing one and measuring one to attribute.

2026-11-01

Why is it necessary to limit server access to internal network addresses in the place where external links can be filled in the background?

The place where external links can be filled in the background needs to limit the server's access to the internal network address because the server will replace the user to retrieve this address: Once the link verification is bypassed, the request can be sent to the link-local address range, exposing the internal network service to external inputs. The verification should be done both at the time of writing and before the request, and then supplemented by the outgoing network limit, especially for entry points such as importing and remote image retrieval, which should be separately controlled.

2026-11-01

The alias of the article address can be listed externally, where should the list interface receive it?

The article address alias can be enumerated externally, usually requiring two conditions to be met: the alias can be guessed according to a regular pattern, and the list interface allows bulk pagination return. Therefore, the bottleneck is on the interface side rather than the page side, and it is necessary to limit the scale of single returns, set the exposure range according to the domain, and tighten the access to unpublic content. This article explains the conditions for enumeration, what list is exposed, and the location to be checked for internal interface.

2026-11-01

The confirmation process for members changing their email addresses is bypassed, and what else does the account side need to verify?

The confirmation process of changing the member's email binding is bypassed, which means the bypasser has obtained the password recovery channel. The account side needs to verify not only this logic. This article explains why property changes require two-way confirmation, how user groups and access permissions should be tightened, the role of email reminders in the process of handling, and provides four records to be checked after the repair.

2026-11-01

Allowing customization of the position of the style, why does the style content also need to be filtered?

The reason for filtering the style content at the position where custom styles are allowed is that styles are not just a presentation layer: attribute names and values can be used to change the page display or make external requests. Filtering needs to cover the three segments of selectors, attribute names, and values, and be coordinated with sensitive word filtering, content review, and background role permissions. This article uses the bypass of the style attribute filter in the official repair list as an entry point to explain the criteria.

2026-11-01