Which PHP version's security support expiration date should small and medium-sized websites keep an eye on

Which version of PHP should small and medium-sized websites pay attention to for the security support expiration date? They should monitor the actual branch currently running on the site, not the latest version listed on the official website.Two pieces of information are needed to determine: whether this branch is still within the security fix window, and what the specific closing date of the window is. According to the timeline checked in October 2026, the branches still under support are 8.2, 8.3, 8.4, and 8.5, with the latest batch of security fix versions released on the same day, among which the deadline for 8.2 falls on December 31, 2026, making it the closest one among the four.

How to read the support window and end date

After a branch enters the end date, the official will no longer produce security fixes for it. The site will still run on that version, but new disclosed vulnerabilities will no longer have corresponding patches. Therefore, the significance of the end date for the site is not 'version old', but 'risk no longer guaranteed'.

There are three details to fix when reading the timeline: first, the difference between the branch number and the actual small version, security fixes are released on the latest small version of the branch, and only listing the assets by branch number is not enough to judge whether the patch has been applied; second, the end date of each branch is aligned with the end of the year, so the end of the year is a concentrated processing window; third, a machine may have multiple PHP versions installed, and the actual version used by the site should be confirmed according to the virtual host configuration, not the version list installed in the panel.

The scope of the table and the release date are from the support timeline page cross-checked on the day, and the actual execution should be reviewed against the official release page.

Why the deadline is a security event rather than an upgrade event?

After the branch support is closed, there is no new code added to the site's exposure surface, but the speed of vulnerability disclosure will not stop. A common problem with small and medium-sized websites is that upgrades are pushed to the initial inventory and done together, resulting in the running environment being touched only once a year. The reasonable order of processing is: confirm the branch and minor version actually used by the site, complete an upgrade simulation with backup before the deadline, and write the rollback path for failed upgrades as fixed steps, rather than relying on temporary decisions.

Rollback path dependency backup coverage range. AnQiCMS's backup capability covers both data and static files, and it is particularly important to verify the whole site during recovery: if only the database is backed up, the version differences of themes, templates, and upload directories cannot be restored during rollback.

Include the operating environment in the asset list

The list must have at least four columns: site address, actual runtime version, person responsible for the upgrade, and the next review date. For teams with multiple sites, an additional column 'who shares the same runtime' must be added, as an upgrade of the runtime will affect all sites using it simultaneously, and the rollback window needs to be arranged together.

The review rhythm can be once every six months, but two types of events must trigger a temporary review: within three months of the branch deadline, and when there is a sudden increase in error reports related to the runtime code at the site.

What section is skipped in Go deployment?

The maintenance chain of a PHP site is in two segments: the runtime language itself needs a patch rhythm, and the application code needs to adapt to the new runtime. Systems developed in Go language integrate the first segment into the build product, AnQiCMS is based on GoLang and Iris framework, data access layer uses GORM, and it releases a binary with a built-in runtime, there is no step of 'upgrade the language runtime first and then verify compatibility' when deploying with Docker image anqicms/anqicms or Baota panel.

Eliminate this section does not mean there is no security maintenance: The application layer still needs to follow up with the fix version. v3.6.6 fixes two types of issues, list sorting parameter injection and credential forgery, which is the update prompt of the application layer, and operations and maintenance personnel need to separate 'application version security update' and 'runtime patch' and record them in the same ledger, to avoid only focusing on one chain of events.

Common questions

Question: If the site is running on a branch that has expired, is it necessary to immediately stop the station and upgrade?Answer: No need to stop at the station, but handle the risk: First confirm the exposure and whether there is available temporary mitigation, then complete the branch switch in a backup window, and verify login, form, and payment pages first after the switch.

Question: How to confirm which version the site is actually using?Answer: The site configuration on the server is the standard, use the runtime environment information page or command line to view the actual interpreter version, do not just look at the list of installed versions in the website panel, as the two are often inconsistent on machines with multiple versions in coexistence.

Question: What to do if compatibility issues arise after the upgrade?Answer: First run the template rendering and background key process in the test environment, keep the rollback package and database backup of the original version, and roll back the entire site if there is a problem, rather than just roll back the code directory.