Published 29 October 2026
Indian businesses running PHP websites should check two things now: whether every internet-facing PHP runtime has its vendor’s fix, and whether suspicious activity may have occurred before patching. CERT-In issued a critical advisory to MSMEs on October 22, 2026, about PHP2Shell, a pair of PHP remote-code-execution vulnerabilities. The agency advises identifying PHP use, applying fixed releases or vendor packages, confirming the runtime is updated, and reviewing logs and files for signs of compromise.
This is especially relevant to WordPress, ecommerce and other PHP applications, but the runtime can also serve custom applications. Updating WordPress core alone does not update the PHP runtime running the site; those are separate layers.
What CERT-In says Indian website owners should know
The PHP project published fixes on October 21 for CVE-2026-109618 and CVE-2026-109619. Its listed fixed releases are PHP 8.5.12, 8.4.27, 8.3.36 and 8.2.35. CERT-In warns that unauthenticated remote attackers may exploit affected PHP systems and advises MSMEs to prioritise public-facing websites, verify the active runtime after updating, and investigate unusual requests or file changes.
There is also a reason not to treat the public release date as the start of all possible exposure: AWS says its threat-intelligence telemetry recorded an exploitation attempt on October 17, four days before public disclosure. That observation does not prove a particular Indian site was targeted or compromised; it does make a retrospective check sensible if the site was exposed and unpatched.
A successful version update is not the same as a compromise check. Patch first, then look for suspicious activity in the period before the fix was installed.
Find the PHP version your website actually uses
Do not rely on a remembered version or a server’s default command-line PHP version. Shared hosting can expose different PHP versions to different domains, and command-line PHP may not match the runtime serving web requests.
- List every public website and application. Include WordPress installs, ecommerce storefronts, staging sites that are internet-accessible, subdomains, and custom PHP applications.
- Check the active web PHP version for each site. In a cPanel account, look for the domain’s PHP version in the PHP Selector or MultiPHP interface if available. Ask your hosting provider to confirm the web-facing version and whether its package contains the fix.
- Record the implementation and package source where known. PHP-FPM, LiteSpeed and Apache configurations can use different runtime packages. A managed host may apply a vendor backport without adopting the upstream version number exactly.
- Prioritise the public production sites. If you manage servers, inventory every PHP handler and pool, not just the default version shown in one control panel.
For upstream PHP builds, the fixed versions above are clear reference points. Some Linux or hosting-vendor packages backport security fixes while retaining a lower-looking version string. In that case, ask the vendor how to verify the package changelog or advisory status; do not assume a lower version is vulnerable or safe without checking the package source.
Apply the fix, then verify the site
On managed hosting, contact the provider if the runtime selection or package status is unclear. On a server you administer, use the operating system or control-panel vendor’s supported update process, then restart the relevant PHP workers or web services as required. Updating files without restarting persistent workers may leave old processes running.
After the update, verify the active version again using the same method used for the initial inventory. Then test important public and administrative functions. For a shop, check product pages, cart, checkout, payment return handling, order emails and the customer account area. For a business site, check forms, uploads, login and any integrations. Review PHP and web-server error logs for update-related failures.
- Confirm each domain uses the intended patched runtime.
- Check that the update did not silently fail or leave a site on a different PHP handler.
- Test uploads and other application functions that rely on multipart form requests.
- Keep a fresh, restorable backup before making changes, particularly on a busy store.
A web application firewall or temporary configuration change may reduce some attack paths, but it should not be treated as a replacement for a fixed runtime. AWS likewise describes updating PHP as the complete remediation for these two issues. Avoid disabling uploads or changing PHP settings across a production account without first checking how applications depend on them.
Look for signs that pre-date the patch
If a public-facing site was running an affected package before it was updated, review available web-server and application logs for unusual POST requests, unexpected upload activity, PHP worker crashes or unfamiliar process activity. Inspect recently changed website files and administrator accounts, particularly accounts that were not created by your team. Compare changes against a known-clean backup or source repository where possible.
Do not block an IP address solely because it appears in an indicator list: AWS cautions that observed addresses may belong to shared anonymisation infrastructure and are not exclusive to malicious activity. Treat an indicator as a reason to investigate relevant log entries in context, not proof of compromise by itself.
If you find unexplained changes, preserve logs and evidence before cleaning up, restrict access where necessary, rotate affected credentials from a clean device, and seek incident-response help. CERT-In advises organisations that detect suspicious activity to preserve evidence and report incidents through its published channels.
What this means for hosting customers
For a website owner, the practical question is not simply “Which PHP version is selected in my dashboard?” It is “Which runtime served requests for every public site, was its vendor fix applied, and what evidence do I have that the site remained clean?” That distinction matters for agencies and resellers too: one account may contain many domains, and checking only the main website can leave another application overlooked.
HostCupid Web Solutions Private Limited is a Chennai-based provider of shared, WordPress, reseller and master-reseller hosting, and offers migration assistance. A customer who is unsure which PHP runtime serves a site can use the provider relationship to clarify the active version and update path; server administrators should verify package status with their own platform vendor. This is a practical support use case, not a guarantee that every package is patched automatically or that an update alone detects prior compromise.
Bottom line: inventory public PHP sites, verify the vendor-fixed runtime, restart and test the application, then review the pre-patch period for suspicious changes. CERT-In’s MSME guidance makes this a useful checklist for Indian businesses that rely on PHP-powered websites.
Sources
- CERT-In Advisory CIAD-2026-0052: Advisory to MSME — Remote code execution vulnerabilities in PHP (PHP2Shell) · 2026-10-22
- PHP 2026 News Archive: Security advisory and fixed PHP releases · 2026-10-21
- Amazon Threat Intelligence identifies PHP2Shell exploitation prior to public disclosure in MadPot · 2026-10-21
- PHP CVE-2026-109618 and CVE-2026-109619: CloudLinux Package Status and Imunify360 Protection · 2026-10-21
