Critical vulnerabilities, compromised software and weaknesses in digital trust have dominated cybersecurity headlines.
“Black October” gained attention last month following a cluster of critical cybersecurity incidents. No public evidence links them into one coordinated attack, and some issues began months before the recent headlines. What connects them is the challenge facing security teams: establishing what happened, whether they’re affected and what to do next.
PHP2Shell: Where are we exposed?
On 21st October 2026, the PHP project released fixes for two critical vulnerabilities, CVE-2026-109618 and CVE-2026-109619, known as PHP2Shell. Under certain conditions, they could allow unauthenticated remote code execution. Both received a CVSS v4.0 score of 9.2, according to the NHS England Digital security alert.
PHP is widely used. W3Techs’ figures from 10th August 2026 put it at 70.5% of websites whose server-side programming language was known. That doesn’t mean those sites are vulnerable, but it illustrates the potential reach of a flaw in widely used software.
Amazon reported an attempted exploit against a honeypot on 17th October 2026, four days before public disclosure. Reuters reported that Cloudflare saw thousands of exploitations attempts before disclosure, rising to millions afterwards. These were attempts, not millions of confirmed compromises.
The immediate question for organisations is where affected PHP versions are running, including in third-party products. Our dedicated PHP2Shell article covers affected versions and remediation.
Four other risks demanding attention
GitLab: A separate critical vulnerability, CVE-2026-110264, could allow unauthenticated code execution on affected self-managed servers. It received a CVSS v3.1 score of 10.0. On 22nd October 2026, Singapore’s Cyber Security Agency advised administrators to update affected installations.
LiteLLM: A compromised release pipeline led to a malicious Python package and affected container images being distributed on 21st October 2026. The package was available for under two hours. Users who ran it were advised to investigate, rebuild affected environments where appropriate and rotate potentially exposed credentials. (LiteLLM’s incident report)
eMudhra: Weak cryptographic keys affected eight intermediate certificate authorities. Browser operators blocked the affected certificates. eMudhra said none had issued end-entity certificates, its infrastructure had not been compromised, and no data had been breached. (Mozilla’s response)
Railway: On 21st October 2026, the platform reported that an unauthorised third party may have accessed customer environment variables containing sensitive information, such as API keys and database credentials. Railway advised customers to rotate potentially exposed secrets and review logs while its investigation continued. (Railway’s disclosure)
These incidents aren’t connected, but they illustrate how risk can arise in different places: vulnerable software, compromised releases, digital trust and sensitive credentials.
The hard part starts after discovery
When several security incidents compete for attention, knowing where to start can be difficult.
Three questions can help organisations cut through the noise:
- Are we affected? Organisations need to know which systems they operate, what software they rely on and whether the affected components are present. Dependencies and third-party products can make that harder than it sounds.
- What response will address the risk? Patching a vulnerability is different from investigating a compromised package. Exposed credentials may need replacing and checking for misuse. The response must fit the problem.
- Have we dealt with the consequences? An update may fix a vulnerability, but it won’t establish whether malicious code has already run or credentials have been misused. Further investigation or remediation may be necessary.
When several incidents compete for attention, acting quickly matters. So does understanding where to act and what the action needs to achieve.
Where vulnerability management fits
PHP2Shell illustrates the importance of knowing where vulnerabilities exist. AppCheck can identify both CVEs through version matching in authenticated infrastructure scans. Web application detection depends on PHP version information being disclosed in HTTP responses, so it isn’t a complete inventory of affected installations.
Organisations that know they run an affected PHP version should apply the relevant update without waiting for a scan.
Vulnerability assessment helps teams identify affected systems and inform remediation decisions. It doesn’t replace software supply-chain controls, credential management or certificate security. Those risks need their own responses.
The point isn’t to use one tool to solve every problem; it’s to understand the risk, identify where it affects you and choose the right response.
Beyond the headlines
The incidents grouped under “Black October” don’t have one cause or one solution. They show how different security problems can demand attention at the same time.
We can’t predict every vulnerability disclosure or supplier incident. We can improve our understanding of the systems we depend on and be better prepared to respond when something changes.
Knowing a security problem exists is only the beginning. What matters is understanding what it means for your organisation and what needs to happen next.
—
Further reading
PHP2Shell
Other incidents
