This week in cyber · October 26–30, 2026
Know where PHP runs. Verify the fixes. Protect the credentials that can turn a software compromise into a much larger incident.
That is the practical takeaway from a week of continued PHP2Shell warnings and recovery updates following Railway’s security incident. AI is part of the story, but the response still comes down to knowing your exposure, closing it, and checking what happened before the fix.
Riley Brown’s October 26 interview with Vibecode co-founder Ansh Nanda brought these issues to a wider audience. We checked the underlying advisories and incident reports to separate confirmed findings from commentary. The original PHP disclosure and Railway incident began before this reporting week; the developments below explain why they still demand attention.
What changed this week?
- October 26: PHP2Shell entered CISA’s exploited-vulnerability catalog. The Canadian Centre for Cyber Security’s October 27 update confirms that CISA added CVE-2026-109618 and CVE-2026-109619 to its Known Exploited Vulnerabilities catalog. This is an active remediation priority, not simply a hypothetical exposure. Read the government advisory.
- October 26: PHP published refreshed Windows packages. These include a Brotli security fix, separate from the two PHP2Shell flaws. A runtime update and a dependency rebuild are different checks. Read PHP’s Windows-build notice.
- October 29: Railway continued its recovery updates. Its status page described recovery from the October 21 incident, with new signups still paused. Railway explicitly said this was not another incident. Follow Railway’s recovery status.
PHP2Shell: update the runtime, then verify the deployment
On October 21, PHP released fixes for two vulnerabilities that can allow an unauthenticated attacker to run code on affected servers. The initial fixed releases were 8.2.35, 8.3.36, 8.4.27, and 8.5.12. Use a supported release containing the fixes, or a vendor package with a confirmed backport. PHP identifies Apache with mod_php as its highest-risk deployment. Read the maintainers’ advisory.
A WordPress or application update alone does not establish that the underlying PHP runtime was patched. Ask your hosting provider or infrastructure team which runtime is actually serving requests, whether its package includes the fixes, and whether workers and containers have been restarted or redeployed.
PHP also issued an October 23 notice about CVE-2026-115560, a separate issue requiring an unusual combination of configuration and application behavior. The recommended precaution is to disable session upload progress until the regular fix is available. Keep that measure in place if you already applied it. Check the follow-up notice.
For systems that cannot be updated promptly, the NSA recommends assessing additional mitigations, including taking the system offline until it can be fully mitigated. Coordinate that decision with the system owner and your response team. Read the NSA guidance.
Railway: credentials can be the target
Railway’s preliminary report describes unauthorized access to internal systems and potential exposure of customer secrets. It says the campaign appeared to target AI-provider API keys. Railway recommended revoking and replacing sensitive environment variables stored before October 21, alongside reviewing connected-account activity. Its report distinguished interrupted builds and deployments from existing customer deployments, which remained running. Read Railway’s incident report and updates.
An API key may authorize paid model usage, access to data, or actions in another service. Treat it as an operational credential with an owner, a defined purpose, limited access, and a revocation plan.
Our recommendation: separate development and production credentials, remove unused keys, keep secrets out of browser-delivered code, and monitor usage by application. If exposure is suspected, replace credentials through a controlled process and verify that the old credentials no longer work. Changing a login password does not necessarily revoke an API key.
Set billing alerts and enforce spending caps where supported. Verify which setting you enabled: an alert is not a cutoff. OpenAI’s current documentation distinguishes alerts from hard limits and notes that enforcement can lag; Anthropic documents workspace spend limits. Test the behavior your incident plan depends on. OpenAI spend controls · Anthropic workspace controls.
Where AI fits—and where the evidence stops
OpenAI reports that AI-assisted research contributed to discovering the PHP vulnerabilities, with maintainers and security partners coordinating fixes. Railway’s preliminary assessment says the attacker appeared to have access to models with safeguards removed and substantial computing resources. Those accounts describe AI’s potential on both sides of security; they do not establish that a particular model or country caused every incident discussed in the interview. Read the disclosure-coordination account.
Amazon Threat Intelligence separately reported PHP2Shell exploitation attempts in its MadPot sensors dating to October 17, before public disclosure. It cautioned that whether those attempts would have succeeded on real systems was unclear. Attempted exploitation, confirmed compromise, and estimates of worldwide impact should not be treated as interchangeable. Read Amazon’s telemetry findings.
Our assessment: faster discovery increases the value of a response process that already works. Use AI to assist analysis and triage, with appropriate access controls and human review. Do not assume a prompt or an unattended agent has made an application secure.
Check the rest of the development stack
PHP was not the only component with October 21 fixes. The Node.js security release addressed issues including a Brotli decoder flaw affecting the 22.x, 24.x, and 26.x lines. GitLab’s critical patch release addressed an unauthenticated code-execution vulnerability under certain conditions; GitLab said its hosted GitLab.com service was already patched.
Review production services, CI runners, base images, and self-managed development tools. Use each vendor’s current advisory to select an appropriate fixed release. These are separate vulnerabilities, not evidence of one shared attack.
Five questions to take into your next security check-in
- Where are we exposed? Include vendor-managed applications and bundled runtimes, not just the systems your team built.
- What proves the fix is running? Record the deployed package or image, applicable vendor advisory, verification result, and owner.
- Which credentials could extend the impact? Map keys to services, permissions, billing, and downstream access.
- What happened before remediation? Preserve relevant logs and investigate suspicious activity. A successful patch does not establish that a system was never compromised.
- Who can act after hours? Confirm who can isolate a service, revoke a key, approve downtime, and bring in responders.
Bring the exposure into focus
You do not need every answer before taking the next step. SEVN-X can help assess application exposure, review cloud and data security, and test whether controls hold up under pressure.
Talk with a SEVN-X practitioner. If you suspect an active compromise, contact an incident coach.
Watch the conversation that prompted this briefing
Riley Brown and Ansh Nanda discuss PHP, stolen API keys, and AI-assisted attacks. The interview provides context; the linked primary advisories above support this article’s technical findings and current guidance.
Watch “The Most Terrifying Week in AI History…” on Riley Brown’s YouTube channel.
Source check: October 30, 2026. Recovery status reflects Railway’s October 29 update available when checked. Vulnerability and incident guidance can change; follow the linked maintainers and providers for subsequent updates.