Why would making a page into an HTML cache turn it into an entry point for executable code?
Why making the front-end page into an HTML static cache might反而 become an entry point for executable code? Because the cache turns the output that visitors can affect into a real existing file.The content with parameters rendered dynamically is only a flash in the response; after being written into the cache file, it becomes a source file that will be read again. If the cache directory is not filtered when written and treated as the script directory when parsed, the executable tags reflected in it will be executed by the engine, and this path to speed up becomes an entry point for code execution.There are only two boundaries: strip executable tags when writing, and do not treat the cache directory as the script directory when parsing. After the repair, you still need to clear the historical cache, check the pseudo-static rules, and make a backup before you start.
Why is the cache product dangerous
Risk comes from the superposition of reflection and disk falling. Reflection is the page echoing the parameters submitted by the visitor in their original form to the HTML, the address bar, forms, and the spider tags used by the crawler can all bring it in.This echo caching mechanism has been written into the file. Individually, each step is not fatal, the echo relies on output escaping to close, the writing to disk relies on parsing strategy to close, the danger lies in both sides thinking that the other is in charge.So the attacker uses a prepared parameter to request a page, triggering a cache write operation, pinning the content on the server; then, requesting the same cache product, this content is parsed and executed by the script engine.An input turns into persistent code, belonging to a storage-type execution path; anonymous access can trigger writing, the attack surface is equal to a public entry.
Repair instructions for the day's口径
Taking a similar publicly repaired example from the same category of domestic website construction programs: PbootCMS listed two security fixes in the update log of version 3.2.14 (built on 2026-06-15), one of which is to fix a code execution vulnerability caused by the reflection of access parameters through spider tags into HTML cache, and the other is to strip executable script tags when writing HTML page cache to prevent the cache from being executed as a script.Its value is to split the boundary in half: one half is responsible for the content written in, and the other half is about how the output file is treated. Similar domestic website building programs and purchased programs can only close at both ends when encountering similar problems, and adding an input filter does not count as finished.
Two write boundaries
The first is the write boundary. Before the cache is written to disk, executable tags, template expressions, and script fragments must be stripped off, leaving only plain text and whitelist tags; the parameters reflected in must be escaped uniformly;Perform filename and suffix constraints on the cached product, so that the request content does not determine its name. The meaning is that even if the upstream filtering is missed, the product stored on disk itself does not contain executable statements.The second is the parsing boundary. The cache directory should not have execution permissions: do not give it a script parser, do not let it inherit the rules of the upload or template directory, tighten the publicly accessible cache subdirectory separately, and only read according to the preset routing.The meaning is, even if the product mixes in suspicious bytes, the server will not treat it as code to run. The two boundaries complement each other, only one is done, and the other is the gap.
How to self-check for self-built programs
Self-built or twice-developed sites should be checked in this order. First, pull out the parameter reflection list and record the locations of all echo request content, including list filtering parameters, in-site search terms, and spider tags.Check the cache directory permissions and parsing strategy to confirm that it does not have execution rights and the product suffix is fixed. Before modifying the code, make a backup, and back up data and static files to a rollback position. The backup capability of Anqicms just covers these two aspects, and they can be rolled back together.After modification, all historical caches must be cleared, including incremental caches and temporary products; old caches are not cleared, and filtering only takes effect on newly generated files, the risk remains in place.Last check the rewrite rules for static links: The actual path after rewriting should be consistent with the cached products, Anqi CMS supports custom static link rules. If a rewrite rule parses the address to a script or cache directory, it is equivalent to creating an execution channel. After rewriting, you should verify the access results item by item, not just check if the page can be opened.
Common questions
Question: If the front-end has opened static cache, how to judge whether there is a risk of execution? Answer: Look at two points: where the cache product falls, whether there is script parsing rights; whether the page writes the parameters that the visitor can control into the cache in the original form. If both conditions are met, handle them immediately.
Ask: Will clearing the cache delete the website content? Answer: No. The main text is in the database and attachments, and the cache is just the rendering product. It will be regenerated after deletion. But still, make a backup before you start.
Ask: What is the relationship between the pseudo-static rules and the cache risk? Answer: The rewrite rules determine which real file the friendly URL will eventually fall into. When the rules and the cache directory overlap, the rewritten path may be handled by the script engine, so you need to check the parsing results one by one after changing it.
Ask: Is it okay to only add input filtering without directory isolation? Answer: It is not recommended. Filtering is on the write side, isolation is on the parse side, and missing either side is equivalent to handing over the defense line to a single misjudgment.