Work out your PHP patch deadline and support date

Identify the requirement that applies to you

A store may have payment-card security obligations, a client contract and an insurance policy at the same time. Each can define its own scope and timing. Start by naming the affected server, who controls PHP and who is responsible for interpreting each applicable requirement.

PHP's October 21, 2026 announcement urged an immediate update. That release date is a useful record, but it does not establish every organization's contractual deadline. PHP's security announcement.

Keep patch deadlines separate from support dates

Scroll sideways to see all columns.

The November examples assume October 21 is the applicable release date. They are calculations, not a determination that either deadline governs your system. A maximum permitted interval is not a reason to defer an available urgent update.

Sources: Cyber Essentials v3.3, PCI SSC FAQ 1597 and PHP support dates.

Record the release that starts the calculation

Save the supplier's advisory, affected operating-system release, fixed package revision and release timestamp. Record when your administrator could obtain the package and whether a subscription or repository setting was required. If the wording does not resolve which release counts, ask the certification body, assessor, client or insurer to confirm it.

Where a supplier has no fixed build, record its current status and when you checked. Assign interim protections and an update owner. Do not quietly reset a deadline to the day someone finally notices the alert.

For Cyber Essentials, qualifying updates include vendor-rated critical or high-risk fixes, CVSS v3 scores of at least 7, and updates whose vendor gives no severity detail. Keep the rating and its source with the notice rather than treating different scoring versions as interchangeable.

Do not turn an insurance example into your deadline

Chubb describes a Neglected Software Exploit Endorsement that it may add to a policy. Its summary describes a 45-day grace period and later changes in risk sharing. That page does not identify your issued policy or establish a PHP2Shell calendar date. Chubb's coverage summary.

Coalition's July 2025 article discusses an unnamed carrier's three-week exclusion. It is commentary about another carrier, not policy wording for the reader. Coalition's discussion of CVE exclusions.

Find your declarations, policy wording and endorsements. Ask your broker or insurer which clause applies, what starts its timing, how days are counted, and whether a proposed temporary control changes the obligation. Keep that answer. Do not calculate a Chubb deadline from NVD publication without wording that supports that trigger.

Government alerts and catalogs require the same care. Check the current CISA catalog and applicable directive or contract before recording a government due date. This guide makes no claim about a current PHP2Shell listing. Incident-reporting duties also require a separate applicability check; a reporting interval is not automatically a patch window.

For a store, document the PCI decision

PCI SSC says organizations assign vulnerability rankings for their own environment under Requirement 6.3.1. External ratings inform that decision but need not be accepted unchanged. Its guidance distinguishes the one-month critical-patch rule from risk-based timing for other applicable updates. PCI SSC's explanation.

Have the person responsible for your PCI assessment confirm system scope, applicable assessment requirements and how the patch date is recorded. Save the rationale, supplier notice and installation evidence. A PHPFixes report does not issue a compliance certification.

Record a web firewall separately from package installation. Its rules do not establish that the serving PHP build contains a fix. Test store behavior on staging and track any required scans or follow-up assessment work with the responsible assessor.

Plan who maintains PHP 8.2 after December

December 31, 2026 is PHP 8.2's upstream support end, not permission to leave a current vulnerability unfixed until then. A supplier can maintain its own packages longer, but you need exact package and architecture coverage.

Debian says Debian 12 LTS runs until June 30, 2028. That release-level date should be checked against package-specific limitations rather than treated as a guarantee about every PHP extension. Debian's LTS announcement.

Ask your host for the covered build, maintenance end date and an upgrade path. Include application testing and any hosting change in the schedule. The older-PHP guide compares those options.

Keep the dates someone will need to review

• Applicable requirement or policy clause, its owner and any written interpretation.
• Risk ranking and affected systems.
• Supplier advisory, full package version and release date.
• Installation, restart and running-PHP verification times, including timezone.
• Application checks, failed tests and remaining work.
• Supplier gaps, temporary restrictions and their review dates.

If compromise is suspected, preserve logs and investigate separately. Installing a package does not establish what happened before the update. Follow any applicable incident-notification process without waiting for a routine patch ticket to close.

Assign the update and interpretation tasks

The administrator should establish package availability and install the supported fix. The application owner should confirm business-function tests. The person responsible for certification, contracts or insurance should resolve any timing ambiguity. Give each unfinished task a named owner and next check date.

Online ordering for paid PHPFixes services is paused. Free guides and the version lookup remain available; neither determines compliance or insurance coverage.

Sources and scope

PHP, PCI SSC, NCSC, Debian, Chubb and Coalition links were checked on October 23, 2026. Insurance pages describe published examples; no reader's policy was reviewed. The CISA link is a destination for a current check, not evidence of a listing status in this article.