PHP Site AuditE-commerce
PHP security update checklist for online stores
An online store should treat the PHP runtime patch and order-flow checks as separate work. Confirm the PHP package or provider backport serving the storefront, restart the correct workers, then test low-risk paths for product pages, account access, cart, checkout, order notifications, and background jobs.
Start with the host and commerce platform
The October 2026 PHP2Shell vulnerabilities are in PHP core. Updating a store plugin or commerce application does not install the PHP fix. Ask the host which PHP runtime serves the shop, what package or build fixes CVE-2026-109618 and CVE-2026-109619, and when all relevant web workers restarted. If the platform uses a vendor backport, retain the vendor advisory and package version.
Before the runtime change, identify the store's most important transactions and any integration that depends on PHP extensions or configuration. Use the deployment window and backup/rollback process already defined by the store team.
Check commerce behavior without creating real orders
After deployment, verify product and category pages, sign-in, cart persistence, shipping and tax calculation, payment-provider handoff, confirmation pages, and order email generation using the platform's safe test mode where available. Confirm scheduled tasks and queue workers are healthy. Avoid test actions that charge a real card or email real customers.
If the store uses upload progress or custom session serialization code, ask its developer to review PHP's October 23 notice about CVE-2026-115560. PHP recommends disabling session.upload_progress.enabled until the next regular bug-fix release; test upload behavior if the store applies that setting.
Record the maintenance window, backup reference, test order or payment mode, and monitoring owner before the runtime change. Afterward, reconcile a small sample of completed orders and queued jobs so a technically successful page load does not conceal a fulfillment or callback failure.
Use a test environment or payment-provider test mode for non-production transactions, and confirm that webhooks and queued fulfillment complete without sending real customer notices.
Escalate unusual activity on evidence
A security patch addresses a software flaw but does not determine whether a store was previously compromised. Preserve relevant web, PHP, authentication, hosting, and commerce logs if monitoring reveals suspicious behavior. Ask a qualified incident responder to assess evidence before making customer or regulatory notifications; obligations depend on the facts and applicable rules.
Common questions
Which shop flows should be tested?
Test product browsing, cart, checkout, payment callbacks, account access, order email and scheduled fulfillment where applicable.
Does the PHP patch establish payment compliance?
No. Follow the payment provider's and your organization's compliance process separately.
What if checkout fails after the change?
Use the tested recovery plan and contact the host and developer; do not leave an unpatched runtime without an explicit risk decision.