Black October 2026 and the risk of PHP vulnerabilities

What happened during Black October in 2026

One of the most significant disclosures involved PHP, which stands for PHP: Hypertext Preprocessor. It is a programming language used to run websites and web applications on a server, including platforms such as WordPress. Companies may rely on it through their hosting provider or other software without maintaining PHP code themselves. The PHP vulnerabilities arrived during a month that also brought enterprise security updates, compromised software releases, and a major cryptocurrency incident.

Key cybersecurity events in October 2026

The dates below distinguish when incidents occurred from when vendors published their findings or released fixes.

• October 10. LiteLLM access was compromised. According to the company’s investigation, an attacker used an exposed administrative key to access its Agent Platform and obtain credentials with broad GitHub permissions. This happened before the malicious release became public.

• October 14. F5 published an NGINX security advisory. The advisory described a vulnerability that could crash affected web servers and, under certain conditions, allow remote code execution. Exposure depended on the version and configuration.

• October 20. Oracle released its quarterly security update. The October Critical Patch Update included 1,295 new security patches across its product families. This scheduled release added to the work facing teams already handling urgent security issues.

• October 20. Python warned users about the eMudhra certificate incident. The Python security announcement called for updates to tools such as pip and certifi, as well as container rebuilds. The concern was that affected certificates could allow an attacker to impersonate a trusted service and intercept connections.

• October 21. Node.js released fixes for the flaw known as Node2Shell. Its security release addressed CVE-2026-111497 in the bundled Brotli decoder, which processes compressed data. Applications that decompress attacker-controlled data could crash, disclose memory, or allow remote code execution.

• October 21. PHP released critical security fixes. Its security announcement addressed CVE-2026-109618 and CVE-2026-109619, which could allow attackers to execute code without authentication. The PHP team urged users to update immediately.

• October 21. A compromised LiteLLM release reached public registries. As documented in LiteLLM’s incident report, version 1.107.0 was published through the compromised release pipeline. The affected packages and container images were subsequently removed or replaced. This was a separate software supply chain incident, with no established connection to PHP.

• October 23. PHP issued additional configuration guidance. Its follow-up notice on session upload progress described another potential remote code execution path tied to an unusual combination of application behavior and settings. It showed why teams needed to keep checking advisories after the initial update.

• October 25. Python released additional protection against the affected certificates. The expedited Python 3.15.2 release added checks in its SSL module to reject the compromised eMudhra intermediate keys, providing another layer of protection for Python applications and package downloads.

• October 27. CISA added the Node2Shell vulnerability to its KEV catalog. The entry for CVE-2026-111497 confirmed exploitation in the wild. Companies using affected software needed to check their exposure and prioritize the relevant vendor updates.

• October 29. Binance wallets experienced unauthorized transfers. TRM Labs reported approximately $6.36 billion moving out of Binance wallets.

These events had different causes, and the available evidence does not establish a connection between the PHP disclosures, LiteLLM compromise, and Binance incident. For companies reviewing their exposure, however, these raise related questions. What software are we running, who can access production, and how quickly can we investigate and apply a safe fix?

Why a flaw in PHP can reach beyond application code

The PHP disclosures are particularly relevant because the vulnerabilities affect the runtime, the software that executes PHP code on the server. An application can therefore be exposed even when the company’s own code has been carefully reviewed.
For example, the CVE-2026-109618 advisory describes a memory-handling flaw and documents remote code execution against mod_php, a way of running PHP through the Apache web server. Whether an exploit works depends on the build and deployment environment, so teams need to check how PHP is installed and used.
That review should include applications managed by hosting providers and other vendors. Updating a website’s plugins or reviewing its source code does not, by itself, confirm that the underlying PHP runtime has received the required fixes.

A vulnerability is different from a confirmed breach

Finding vulnerable software does not automatically mean an organization has been breached. A vulnerability is a weakness, an exploitation attempt is an effort to use it, and a confirmed compromise requires evidence that the attacker succeeded.
This distinction matters when headlines describe widespread scanning or millions of suspicious requests. Those figures do not tell us how many companies were compromised. Likewise, a researcher demonstrating a working exploit shows what is possible under the tested conditions.
The next step for a business is to establish whether the affected software is present, how exposed it is, and whether there are signs of unauthorized activity. That gives the team a basis for deciding what to fix first and whether an incident investigation is also needed.

How AI is changing vulnerability research

In its PHP2Shell research, Wiz describes how AI models helped investigate longstanding flaws and develop working exploits. The work involved analysis, testing, and adaptation across different environments.
That provides a concrete example of how AI can reduce the effort required for complex security research. It does not establish that every new vulnerability is easy to exploit or that every attack is automated.
From our perspective, the operational consequence deserves attention. If research and exploit development speed up, teams need a response process that can move from alert to deployment decision without spending days identifying owners and locating systems.

Companies need security engineers to review AI security gaps

AI can help analyze code, compare findings, and prepare changes. Engineers still need to validate the output and understand the environment where a change will run.
A customer portal, an internal tool, and an isolated test service can have different consequences if compromised. Teams also need to understand the data involved, the integrations that may fail during an upgrade, and the options available if a deployment causes problems. Those decisions require technical knowledge and business context.

Binance also got breached in October 2026

In its October 30 security update, Binance estimated the incident’s impact at approximately $6.3 billion and reported that about $3 billion in affected assets had been frozen on-chain. Its preliminary investigation pointed to a potentially compromised DevOps engineer’s laptop, followed by access to a service container and unauthorized withdrawal transactions. Binance said it had found no evidence of a wallet private key leak.
The company said it would cover losses using its SAFU fund and company resources. Its updated notice clarified that deposits remained operational while withdrawals were temporarily suspended. These were company-reported findings as of October 30, 2026, with a technical post-mortem still pending.
The sources reviewed do not establish a connection to the PHP vulnerabilities or confirm that AI was used in this incident. Its relevance here is the wider question of how access from an engineering environment can reach sensitive business operations.

What security gaps companies should review

Start by identifying affected applications, the components they use, and the people or providers responsible for maintaining them.

• Check who can access production. Review device protection, privileged sessions, service identities, and approval controls around sensitive actions. Determine what a compromised device could reach and make sure access can be revoked quickly. These are review priorities, not conclusions about which controls failed at Binance.

• Confirm what is running and who owns the update. Record the PHP build, package source, and responsible team or provider. Check the vendor’s advisory and installed package revision, since some vendors backport security fixes without changing the upstream version number.

• Fix the highest-risk exposure first. Start with internet-facing systems that handle sensitive data or support critical operations. Our article on vulnerability management in an airline environment explains how teams prioritize findings and verify fixes.

• Update and check the result. Install a supported package with the required security fixes. Test critical features and confirm the update is running across affected systems. Check for signs of compromise too, since patching does not undo an earlier attack.

• Check the dependencies your application trusts. Review certificate bundles, package managers, and container images alongside application code. An operating system update may not refresh every bundled certificate store or library your application uses.

• Set a deadline for temporary protections. If you cannot update immediately, work with security engineers to reduce exposure using current vendor guidance. Assign an owner and a deadline for the full fix. A WAF or access restriction may help, but neither replaces the update.

What needs to change beyond this update

Rigid update calendars and occasional reviews make it difficult to respond when a critical issue appears between planned maintenance windows. Teams need a way to handle urgent changes while preserving the testing and operational checks their services depend on.

• Prepare for urgent updates before an incident. Agree in advance who evaluates exposure, approves emergency changes, and validates the deployment. Test critical business flows and maintain a recovery plan. After remediation, retain the affected asset list, deployed package details, validation results, and any remaining exceptions.

• Limit what a compromised application can reach. Review workload permissions, network access, and available secrets. Segmentation and least privilege can limit the impact, while useful logs and tested response procedures help teams investigate and contain suspicious activity.

How Ewents AppSec teams help remediate PHP vulnerabilities

Ewents builds dedicated Application Security engineering teams across Latin America for U.S. businesses. Our AppSec engineers work with your developers to identify affected applications, review code and dependencies, and prioritize remediation based on exposure and business impact.
For PHP vulnerabilities and other critical disclosures, the team helps implement fixes, test essential features, and verify the changes in production. If unresolved findings are growing faster than your team can address them, Ewents can help define the AppSec support you need.

Frequently Asked Questions

• What is Black October in cybersecurity?

  Black October is an informal name for the wave of cybersecurity incidents and critical vulnerability disclosures reported during October 2026. It covers separate events affecting applications, development tools, and infrastructure, rather than one coordinated attack.

• Could my business be affected if we use PHP through WordPress or a hosting provider?

  Yes, your business could be affected even if your team does not maintain PHP directly. Ask your hosting provider which PHP version and security fixes are running, and who is responsible for updates. Using PHP warrants a review, but it does not mean your systems have been compromised.

• How is AI changing vulnerability research?

  AI can help researchers analyze code, investigate complex flaws, and test possible exploits more quickly. Engineers still need to validate the findings and understand their impact. AI’s role in one investigation does not establish that it was involved in every incident reported during Black October.

• What should we check beyond PHP?

  Review other application runtimes, dependencies, certificate bundles, and development tools. The eMudhra incident prompted security guidance for Python users, while Node2Shell affected software using a vulnerable Brotli decoder. The review needs to cover the components your applications actually use.

• Does a WAF replace the PHP security update?

  No. A web application firewall may block certain attack attempts, but it does not fix the underlying PHP vulnerability. Temporary protections should support a plan to apply and verify the update, following the vendor’s guidance.

• How can we apply urgent security updates without unnecessary downtime?

  Test critical business functions, check compatibility, and prepare a deployment and recovery plan. After deployment, verify that the fixed software is running across affected systems. Use evidence of exploitation, including entries in CISA’s Known Exploited Vulnerabilities Catalog, to help prioritize the work.

• When should we bring in additional AppSec engineers?

  Consider additional support when your team cannot quickly identify affected applications, critical findings remain unresolved, or remediation regularly competes with product delivery. AppSec engineers can work with your developers to investigate findings, implement fixes, and verify the results in production.