In October 2026, two critical vulnerabilities were disclosed in PHP, the programming language that powers a significant portion of the web. They were identified by researchers from Calif, OpenAI, and Wiz, with the aid of AI models, and their disclosure immediately raised concerns across the cybersecurity community.
Between October 20 and 22, 2026, PHP2Shell went from rumors to a security patch, followed almost immediately by lists of indicators of compromise (IoCs).
Over the following days, multiple security vendors released lists of IP addresses, domains, and hashes linked to exploitation of the vulnerabilities.
(Free access, no subscription required)
In this article, we analyze what publicly available sources reveal about patching progress across Latin America and the Caribbean and provide recommendations for mitigating and remediating these vulnerabilities.
What Is PHP2Shell and Who Is Affected?
PHP2Shell refers to two vulnerabilities affecting the PHP interpreter itself: CVE-2026-109618and CVE-2026-109619. Both carry a CVSS v4.0 score of 9.2 (9.8 under CVSS v3.1) and enable unauthenticated remote code execution (RCE) via HTTP requests.
Severity, however, is only one factor to consider when prioritizing vulnerabilities. Considering two additional indicators provides a more complete picture:
In this article, we analyze what publicly available sources reveal about patching progress across Latin America and the Caribbean and provide recommendations for mitigating and remediating these vulnerabilities.
What Is PHP2Shell and Who Is Affected?
PHP2Shell refers to two vulnerabilities affecting the PHP interpreter itself: CVE-2026-109618and CVE-2026-109619. Both carry a CVSS v4.0 score of 9.2 (9.8 under CVSS v3.1) and enable unauthenticated remote code execution (RCE) via HTTP requests.
Severity, however, is only one factor to consider when prioritizing vulnerabilities. Considering two additional indicators provides a more complete picture:
Indicator
CVE-2026-109618
CVE-2026-109619
What it measures
CVSS v4.0
9.2
9.2
Technical severity if exploited
EPSS (FIRST, 26/OCT)
99,981%
99,997%
Probability of exploitation within the next 30 days
Catálogo KEV (CISA, 26/OCT)
Not listed
Not listed
Confirmed exploitation
According to CVEdetails’ historical data, the EPSS score for CVE-2026-109618 rose from 11.84% to 99.98% on October 25. As of October 26, FIRST’s public API assigns an EPSS score of 99.981% to CVE-2026-109618 and 99.997% to CVE-2026-109619, placing both in the highest percentile among all scored vulnerabilities. However, as of October 26, neither vulnerability appears in CISA’s Known Exploited Vulnerabilities (KEV) Catalog, which includes only vulnerabilities with confirmed exploitation. CISA issued an alert on October 21 urging organizations to apply patches, although it had not observed exploitation, as summarized by Tenable.
Because the vulnerabilities affect PHP itself rather than a specific application, their potential reach is substantial. Any website running a vulnerable version of PHP may be exposed, whether it uses WordPress, Drupal, Joomla, or a custom-built application. The patched versions are 8.2.35, 8.3.36, 8.4.27, and 8.5.12, released on October 21. PHP 8.1 and earlier branches no longer receive official patched releases.
Details of the vulnerabilities leaked ahead of the scheduled disclosure date, prompting the PHP team to release the patch earlier than planned. In addition, Amazon reported that its honeypot network recorded an exploitation attempt on October 17, four days before the patch became publicly available.
It is important not to confuse these vulnerabilities with CVE-2026-115560, disclosed on October 23, which some lists group under the same name. According to The Hacker News, this is a separate issue that requires an uncommon configuration and has no reported exploitation.
Patch Adoption Across the Region
Censys provides a public dashboard that tracks Internet-exposed PHP services running vulnerable or patched versions, with hourly updates and country-level breakdowns. We used these data to analyze 21 countries across the region.
As of October 26, only 12.8% of PHP services with identifiable versions in Latin America and the Caribbean were running patched releases, compared with 25.1% globally. The region’s patch adoption rate is roughly half the global figure.
Both figures include servers running PHP versions that no longer receive security fixes, such as PHP 7.4 and earlier, in the unpatched category. These systems remain vulnerable, with no patches available for their current versions. Since Censys does not provide a country-level breakdown of unsupported releases, it is impossible to determine how much of the region’s remaining 87% can be addressed through patching and how much requires migration to a supported version.
Additional Data That Help Explain the Situation
Unsupported PHP branches: worldwide, 73% of vulnerable services run PHP branches that no longer receive security fixes. This includes PHP 7.4.33, the most widely observed version on the Internet. These servers cannot be remediated by simply applying a patch; they must migrate to a supported release. An independent analysis by Cisco Talos points to a similar conclusion, estimating that nearly half of PHP systems will not receive patches.
Patching pace: most patch deployments took place on October 22 and 23, after which the adoption curve began to plateau.
What Indicator Lists Reveal
Comparing indicators across sources revealed several findings:
Each source captures only part of the picture: all six IP addresses identified by Amazon also appear in FortiGuard’s list, along with four of the six reported by Cisco Talos. Yet there is no overlap between Amazon’s and Talos’s IP addresses. Each vendor captures a different subset of the activity, and some indicator lists appear to aggregate intelligence from other sources.
There is no single attacker: the 82 IP addresses listed by FortiGuard are distributed across 56 different autonomous systems, with no single autonomous system accounting for more than five addresses. These include cloud infrastructure, low-cost hosting services, and residential and mobile access networks, which may correspond to compromised devices.
Domains registered shortly after the news: All three .com domains on the list, each containing “php2shell” in its name, were registered on October 22, between 14 and 24 hours after the patch was released.
Recommendations
Update: Upgrade to PHP 8.2.35, 8.3.36, 8.4.27, or 8.5.12, or install the patched package provided by the Linux distribution in use.
Migrate unsupported branches: PHP 8.1 and earlier releases are no longer eligible for official security patches and must be migrated to a supported version. Although PHP 8.2 users can apply the available fix, they should also plan an upgrade, as security support for that branch ends on December 31, 2026.
Mitigate in the meantime: follow PHP’s recommended mitigations for each CVE, including restricting POST request sizes and disabling session.upload_progress, followed by a restart of the PHP processes. These are temporary risk-reduction measures, not substitutes for applying security updates.
Check for compromise: For servers that were Internet-exposed and remained unpatched before October 21, review logs and server artifacts for signs of compromise. Indicators to investigate include unusually large POST requests containing a PHP_SESSION_UPLOAD_PROGRESS field and unexpected files in the PHP session directory.
Conclusions and Call to Action
Cross-referencing public lists of indicators provides context that no single list offers on its own: each vendor observes a different part of the activity, the IP addresses span dozens of different networks, and some indicators emerge just hours after the news breaks. Before blocking or attributing activity, it is important to examine the source of each data point.
For the region, the challenge goes beyond applying patches: a significant proportion of servers run PHP versions for which security fixes are no longer available. For these systems, migration is the only solution, with all the effort that entails.
We encourage CSIRTs, security researchers, and network operators throughout the region to correlate these indicators with their own web server and network logs, prioritize migration away from unsupported PHP branches, and share their findings with the wider community.
