So Outside Technology Security CMS
AnQiCMS
Online Demonstration

The open-source program announcement said that historical versions have been hacked, check which directories before upgrading.

📅 2026-11-01 👁️ 0

The open source program announcement says that historical versions have been hacked, check which directories before upgrading? Check in four categories: directories for writing and caching concentrated running, pseudo-static rules and site rewrite configuration, abnormal files in directories related to uploading and templates, as well as scheduled tasks and background login records.PbootCMS indicated in the security公告 on June 22, 2026, that the website owner reported issues including 'being attacked, abnormal file writing, page trojan', affected versions '3.2.5 and above', fixed version 'v3.2.14', and suggested cleaning the runtime directory, checking the rewrite pseudo-static rules.First, collect evidence and clean up, then update the version lastly, directly covering the upgrade will bring the malware files left together with the new version.

The three types of exceptions in the announcement.

The three phenomena named in the announcement correspond to three different levels: being attacked is an entry problem, abnormal file writing is a landing problem, and page hacking is a manifestation problem. Their time sequence is usually 'entry exploitation → file writing → page appearance of abnormal content', so the investigation should trace back from the writing痕迹, rather than just looking at whether the homepage has been changed.

When reading the announcement, grab three pieces of information: the affected version range, the fixed version number, and the official recommended directory for cleaning and inspection. PbootCMS's announcement provided all three items, so just check the list; if the announcement does not specify the directory, follow the general four categories below.

First check the running directory

The running directory is where cache and temporary write operations are concentrated, and it is also the place where abnormal files are most likely to appear. Method:

  1. Sort by modification time, filter out the newly added or modified files, and focus on script types that should not appear here.
  2. Check the file owner and permissions, files writable by the Web process with script suffixes should be marked separately.
  3. Before cleaning up, back up a complete directory first for easy comparison and evidence collection, do not delete directly.

AnQiCMS's backup and recovery supports backing up data along with static files, this step also serves as evidence material in emergency scenarios; after cleaning up, if you need to recover mistakenly deleted content, the documents saved in the recycle bin are the documents moved to the recycle bin, so as not to lose normal articles.

Check the pseudo-static rules again.

The static rewrite rule is often modified after an attack. The announcement of PbootCMS explicitly requires checking the rewrite static rule, usually for the following reasons: jumping links are inserted into the rewrite rules, which can lead visitors or search engines to third-party pages while the page itself looks normal.

Check two things. First, compare the current rules with the rules in the version library or the initial installation package text by text, and confirm the differences item by item; second, check if the rule file can be written by the Web process, and excessive permissions are the root cause of recurrence. AnQiCMS's pseudo-static rules are centrally managed in the background, support custom pseudo-static URLs, changes are recorded for verification, and it is easier to find anomalies than scattered in multiple configuration files on the server.

Version supplement and verification

Steps Action Complete judgment
Evidence collection Backup the database, static files, and suspicious directories There is a traceable original copy
Clear abnormal files Filter and remove suspicious files by time and type There is no unknown script in the directory
Check the rules Compare the pseudo-static and rewriting configuration Consistent with the initial rules
补充版本 Upgrade to the repair version specified in the announcement The version number is consistent with the announcement
Verify Check the page, form, and backend login Function is normal and there are no abnormal jumps
Review Check the file list again after a few days No new suspicious files have been added

The review after the upgrade is often overlooked: The vulnerability has been patched, but the residual files are still there, and the page will still be hacked. It is recommended to check the file list again for differences a few days after the version is updated, and at the same time, change the administrator password, rotate the site's signature key and other long-term credentials.

There are still two defenses on the content side that are worth confirming: sensitive word filtering and content review can discover the implanted abnormal text, and anti-crawling interference code and JWT authentication belong to daily configuration. After the emergency, it should be confirmed that they have not been temporarily changed.

Common questions

Why not just overwrite the upgrade files?Not enough. The replacement only replaces the files that come with the program, additional scripts written by attackers and modified configurations are not within the replacement scope and will be retained as is.

Should we shut down first?Check the extent of the abnormality. If it is confirmed that there is continuous writing or external jumping, pause the service first and then collect evidence for safety; if there is only the risk of historical versions and there are no abnormal traces, you can directly go through the upgrade process after backup.

Will changing the directory permissions affect normal functionality?Yes. Uploading, caching, and temporary writing all require writable directories. It is recommended to only give write permissions to the subdirectories that truly need to be written, and the rest of the directories should be changed to read-only and verify the functionality item by item.

Related articles

What order should be checked before upgrading the website when a planned-out-of-scope security version occurs in the running environment?

The release of a security version out of the normal release cycle for the operating environment indicates that the problem is not within the regular release period. Before upgrading, check in the following order: first, confirm that there is an available rollback point and complete the backup of static files; then, verify the current version with the affected range in the announcement; then, run the form, backend login, and key pages in the test environment; finally, peak load online for observation, and record the results in the version ledger.

2026-11-01

How much of the operation and maintenance hours will be occupied by the patching frequency of self-hosted sites?

Based on the day's self-hosted operation standards, mainstream self-hosted content systems need to process patches from high to medium risk levels every six to eight weeks, accumulating eight to ten times a year. Each time, it involves announcement verification, assessment, backup, update and regression, plus on-site and backup drills, the hidden labor cost is often higher than the monthly fee of the host. This article provides the breakdown of working hours and the sections that can be saved.

2026-11-01

When the system email cannot be sent out, should we first look at the bounce rate or the complaint rate

When the system email cannot be sent out, should we first look at the bounce rate, which directly reflects the quality of the address and whether the delivery is rejected; the complaint rate reflects whether the content has been judged as spam, usually after the delivery is successful. This article gives the troubleshooting sequence according to the delivery index threshold verified on the day and explains the division of labor in maintaining the email reminder and email subscription list triggered by the event

2026-11-01

When the form is flooded by robots, should we add human verification first or collect fields first?

When forms are flooded by bots, the field collection is done first followed by human verification. According to the samples checked that day, in the first eight days, the proportion of real people among the hundreds of contact form submissions was very low. The pricing of captcha service at a scale of thousands indicates that bypassing verification has already become industrialized, while edge-side condition filtering can block about three to five percentage points of the bottom flow. The order of processing is to tighten fields and condition filtering, then integrate reCAPTCHA, and finally leave a content review.

2026-11-01

The major version should include a new default theme, and what should be tested before the old site is upgraded?

When the major version includes a new default theme, the template and style references of the old site are the primary test objects. Before the upgrade, run the template rendering checklist in the test environment, check if the custom template depends on the style and structure of the old theme; then check for value failure caused by renaming or reducing content fields; finally, prepare backups and rollback points that include static files, confirm that you can roll back to the original version on the same day.

2026-11-01

AI crawlers are not just the leading few, should the budget for crawling be redistributed?

The flow of AI crawlers is no longer concentrated in just a few major ones, the proportion of the part outside the head has increased to about five times the original within a year. This article uses the current day's verified crawling distribution data to explain why assigning robots.txt to just a few old faces is no longer enough, and provides the order of redistributing crawling budgets by crawler group, as well as the division of labor between robots.txt and llms.txt, and the verification method after the modification.

2026-11-01

How much difference is there in the pass rate of mobile performance on mainstream website building platforms?

In the data checked on the day, the difference in the pass rate of mobile performance between the high and low positions is about thirty percentage points. Under the same criteria, the mobile end of the entire station is about nine percentage points lower than the desktop end. This article breaks down the gap into two parts: platform layer and site layer, explains that platform selection determines the baseline, and page optimization determines whether you can reach the top of the platform, and gives the sequence of acceleration actions.

2026-11-01

The natural flow decreases week by week, when should we go back and modify the old article?

The average speed of content attenuation is cumulative on a weekly basis. The statistics checked on the day show that the article loses about 0.12% of the traffic each week, and it is halved after about fifty weeks. This article gives the judgment line for triggering the revision of the article: if the natural traffic of a single page drops by more than 20% in 90 days, it is considered a signal, and explains how to arrange the review order, why it is necessary to use the time factor to make the update time visible after the revision is completed, as well as the use of the keyword library in the topic review.

2026-11-01