Intelligence Insights: October 2026

Threat Detection Insights - October

This month's CTI Insights covers two developments at opposite ends of the attack surface. The first is PHP2Shell, a pair of critical memory-safety vulnerabilities in the PHP interpreter itself (CVE-2026-109618 and CVE-2026-109619) that can enable unauthenticated remote code execution and exposure of sensitive process memory on systems running vulnerable PHP versions. Discovered with the help of frontier AI models, made public ahead of coordinated disclosure and targeted by exploitation attempts even before its official public disclosure, it represents one of the most significant PHP security events in recent years and deserves the attention of organisations running PHP directly or through third-party products.

The second is the continued rise in voice phishing and social engineering conducted through Microsoft Teams. Rather than exploiting a software flaw, this technique exploits the trust organisations place in their collaboration platform, with attackers posing as IT support, flooding targets with spam to create a pretext, and then talking their way into a remote-access session. The technique has been adopted by multiple financially motivated threat actors and has been associated with ransomware operations.

PHP2Shell is the name given to a pair of critical memory-safety vulnerabilities in core PHP, tracked as CVE-2026-109618 and CVE-2026-109619, each carrying a CVSS v4.0 score of 9.2. The flaws lie in the PHP interpreter itself rather than in an application framework, meaning vulnerable deployments can potentially be exploited even when the application code running on top of PHP does not itself contain the underlying vulnerability. Wiz Research, which published the headline research and coordinated the disclosure, states that PHP powers around 70% of websites and has compared the potential significance of PHP2Shell to vulnerabilities such as Heartbleed and Log4Shell. Credit for the underlying findings is shared across several researchers. Calif and OpenAI independently reported the same core weakness during the same period.

What is PHP2Shell

The vulnerabilities can allow an unauthenticated attacker to execute code remotely on an affected server and, separately, to read raw memory from the PHP worker process. That leaked memory can contain passwords, authentication tokens, API keys and certificates belonging to other users' requests or to the server itself. PHP releases dating back to version 5.4 are affected by at least one of the vulnerabilities, with web-facing deployments including Apache's mod_php, PHP-FPM, php-cgi, FrankenPHP and LiteSpeed considered in scope. Exploitability and specific attack paths can vary depending on the deployment model and configuration. The primary concern is PHP runtimes serving HTTP requests, including those bundled inside container images, which may run a different PHP version or configuration from the command-line installation.

How PHP2Shell was disclosed

1. 19 Aug - First vulnerability discovered
2. 17 Oct - Exploitation attempt recorded
3. 20 Oct - Technical details became public
4. 21 Oct - Security release brought forward
5. 22 Oct - Originally planned disclosure

The research is notable for being substantially AI-assisted. Wiz used frontier models, including Google's Gemini 4 Argon and OpenAI's GPT-5.6 Sol, to help identify the vulnerabilities and develop and adapt working exploits across different environments. The underlying weaknesses had existed for years; what changed was the cost and complexity of turning them into reliable exploits, with frontier AI significantly lowering the barrier to adapting exploitation techniques across different PHP versions and configurations.

The coordinated disclosure did not go entirely to plan. Wiz discovered the first vulnerability on the 19th of August 2026 and subsequently reported its findings through coordinated disclosure. Technical details became public on the 20th October, ahead of the planned disclosure on the 22nd October, prompting the PHP team to bring its security release forward to the 21st October. Most significantly, exploitation attempts preceded public disclosure: Amazon's MadPot honeypot network recorded an attempt on 17th October, four days before patches became available. Exploitation activity escalated rapidly as details became public, with broad scanning and exploitation attempts subsequently observed in the wild.

How PHP2Shell works

Both vulnerabilities share a common underlying pattern: a fatal error, typically caused by memory exhaustion, interrupts PHP partway through an internal operation, and PHP later treats the incomplete or stale state as though it were valid.

To make the demonstrated RCE exploit reliable, an attacker must also overcome address-space layout randomisation (ASLR). Memory disclosure can substantially reduce this obstacle by leaking process memory through a URL-encoded PHPSESSID response cookie, potentially exposing pointers that remain valid within the targeted worker. Crucially, successful exploitation does not necessarily crash the worker: Datadog Security Labs demonstrated a refined exploit that returned HTTP 200 while the same Apache worker continued running after executing the attacker's command. A successful HTTP response is therefore no assurance that the request was harmless.

A successful HTTP response is no assurance that the request was harmless.

Recommendations

Detection opportunity

Hunt: suspicious child processes from PHP

Detects suspicious applications being run from PHP-related processes.

let PHPParents = dynamic([
    "php.exe", "php-cgi.exe", "php-fpm.exe",
    "httpd.exe", "apache.exe", "apache2.exe",
    "php", "php-cgi", "php-fpm", "httpd", "apache2"
]);
let SuspiciousChildren = dynamic([
    "cmd.exe", "powershell.exe", "pwsh.exe",
    "bash", "sh", "dash", "zsh",
    "curl", "curl.exe", "wget", "wget.exe",
    "python", "python3", "python.exe",
    "perl", "perl.exe", "nc", "ncat",
    "certutil.exe"
]);
DeviceProcessEvents
| where InitiatingProcessFileName in~ (PHPParents)
| where FileName in~ (SuspiciousChildren)
| project Timestamp, DeviceName,
    InitiatingProcessFileName,
    InitiatingProcessCommandLine,
    FileName, ProcessCommandLine,
    AccountName, FolderPath
| order by Timestamp desc

Microsoft Teams is abused for two related forms of social engineering. In message-based phishing, attackers use Teams chats to deliver lures such as malicious links, file-sharing lures or QR codes designed to redirect users towards fraudulent or credential-harvesting content. In voice phishing, or vishing, attackers go a step further and get the target onto a call, often posing as internal IT or helpdesk personnel to persuade them to grant remote access to their machine. Teams-based vishing has increasingly been adopted by financially motivated threat actors and has been associated with ransomware operations. Both techniques exploit the same underlying weakness: the trust an organisation places in its own collaboration platform. Where PHP2Shell attacks the software, Teams phishing and vishing attack the user.

The reported increase

The growth through 2026 is visible across multiple vendors’ telemetry, on both the voice and the message side. Microsoft reported that weekly malicious Teams call attempts had increased by roughly 80% since the beginning of 2026 and reached nearly ten times the mid-2025 baseline by late June. On the message side, Microsoft reported that Teams-based phishing detections increased 19% from March to April, remained broadly flat in May, and rose a further 10% in June. Sophos, which tracks the technique through its Managed Detection and Response cases, recorded a sharp rise in Teams vishing from January 2026, with further jumps in March and May. It assesses that while improved detection may explain part of the increase, the trend more strongly suggests growing adoption of the technique as an initial-access vector.

The technique is not new. Microsoft first publicly documented IT-themed Teams vishing in mid-2024, and similar activity has since been associated with ransomware operations including BlackBasta and 3AM. However, observed campaigns have become increasingly sophisticated. Zscaler ThreatLabz tracked a cluster of related attacks from January 2026 in which the tooling evolved over time, with more recent activity becoming increasingly selective and focused on corporate environments. A particularly clear example is the campaign Sophos tracks as STAC4749, which targeted dozens of North American organisations between February and June 2026, with approximately 94% of observed cases affecting organisations in Canada and the US. At least three compromises culminated in Chaos ransomware deployment, including one in which the attackers progressed from initial access to ransomware deployment in less than 17 hours.

Message-based phishing on Teams

The chat channel is a delivery vector, not just a means of establishing voice contact. Because Microsoft Teams supports communication with external users, attackers can contact employees directly from outside the organisation and deliver phishing lures through Teams chats. Microsoft has introduced specific protections against spam, phishing and impersonation from external contacts, while Microsoft Defender for Office 365 can provide time-of-click protection against malicious URLs in Teams.

Microsoft documented the financially motivated actor Storm-0324 using this approach as far back as July 2023, distributing phishing lures through Teams chats as part of its malware-delivery activity. Storm-0324 acts as a distributor that hands compromised access to other threat actors, with Microsoft reporting that these hand-offs frequently lead to ransomware deployment. More recent defensive changes also reflect the growing diversity of Teams-based phishing. QR codes embedded in messages can direct victims towards phishing or fraudulent content while concealing the destination behind an image. In October 2026, Microsoft Teams introduced protection that obscures QR-code images from external senders by default and requires users to explicitly reveal them before scanning. Message-based phishing should therefore be treated as a distinct Teams attack vector alongside the voice-based social-engineering activity described below.

Teams vishing attack sequence

The attack chain observed across multiple campaigns relies primarily on social engineering rather than exploitation of a software vulnerability:

Recommendations

Because these techniques target people and trusted tools rather than a patchable flaw, defence requires a combination of configuration, monitoring and training. Several of the controls below blunt both the message-based phishing route and the voice-based vishing route at once.

Lock down external Teams communication

Restrict or disable external Microsoft Teams chat and calls where the business does not require them, and allow-list only trusted partner domains where appropriate. Separately review external file-sharing policies in SharePoint and OneDrive. This reduces exposure to two delivery channels at once: the voice calls used in vishing and the malicious messages, links and file-sharing lures used in Teams phishing. Microsoft recommends limiting domains for external Teams access as part of reducing the platform's attack surface.

Filter malicious links and files inside Teams

Ensure Microsoft Defender for Office 365 protections are appropriately configured for Teams. Safe Links provides protection for URLs shared through Teams, including time-of-click checking, while Safe Attachments for SharePoint, OneDrive and Teams provides an additional layer of protection by analysing files and restricting access to those identified as malicious. Review external sharing policies in SharePoint and OneDrive, and treat QR codes, or quishing, as a live phishing lure. Teams began obscuring QR codes from external senders by default in October 2026, but users should still verify the sender before revealing or scanning them.

Control remote-support tools

Enforce application-control policies to restrict unauthorised use of Quick Assist, RemSupp, AnyDesk, DWAgent and similar RMM utilities. Attackers may switch to less commonly blocked tools when preferred options are unavailable, so approved-software policies and blocklists should be regularly reviewed and updated. In STAC4749, operators increasingly favoured RemSupp after initially using Quick Assist, which Sophos assesses was likely because it was less commonly included in application blocklists.

Train staff on the specific scenarios

Users should be taught to treat two kinds of unexpected contact with caution: an IT or helpdesk approach requesting remote access, particularly when it follows an unexplained flood of spam, and an unexpected message carrying a link, file-sharing notification or QR code, especially from outside the organisation. In both cases, employees should have a clear, rehearsed method for independently verifying the contact through a known internal channel before granting remote access, clicking links or running unfamiliar tools.

Monitor for the behavioural chain

Investigate suspicious external Teams calls and chats, particularly unexpected messages containing URLs, QR codes or file-sharing links. Alongside these, alert on abnormal PowerShell execution, unauthorised remote-access or tunnelling tools, and suspicious registry Run keys or Startup-folder entries. EDR and identity telemetry that correlates these behaviours can provide visibility into attacker activity before persistent access is established. The latter behaviours are consistent with the post-compromise activity observed by Sophos in STAC4749.

Audit persistence locations routinely

Regularly review registry Run keys, Startup-folder entries and other common persistence locations for suspicious entries masquerading as legitimate services or applications. This can help uncover established footholds and reduce the risk of persistence surviving remediation. STAC4749, for example, used registry-based persistence while masquerading as legitimate components.