Tag: Cisco Talos Network Intrusion Prevention

Cisco Talos is aware of eight compromised intermediate certificates belonging to the intermediate certificate authority, eMudhra. Rather than possessing the mandatory 384 bits of pseudo-random security, several private keys evaluated single-digit and double-digit integers. This misconfiguration allows an attacker with the private key of any of the compromised intermediate CAs to impersonate any website or service. Six of the TLS certificates, trusted by Chrome, Mozilla, and Apple have been blocked by these vendors already. Two other certificates, used for codesigning by Microsoft, have also been blocked. Talos expects there will be additional patches available across a variety of technologies as software applications work to remediate the certificates’ exposure.

Following the disclosure, eMudhra has revoked the compromised certificates and stopped issuing new certificates under its G3 root.

Compromise details

The cause of this issue, originated during an April 30, 2025 key generation activity conducted by eMudhra under its emSign Root TLS CA – G3 and cross-signed Comodo AAA Certificate Services.  During a key generation ceremony for 24 subordinate CAs, a flaw in eMudhra’s key generation process created a second set of weak P-384 keys during a wrap/unwrap step. Those keys were mistakenly used for eight intermediate CA certificates. This flaw took the encryption from 384 bytes of entropy down to 3 – 8, making recovering the private keys trivial. The following are the impacted certificates, as illustrated in Mozilla’s bug report:

EM EV TLS CA - G3B (eMudhra BV), CCADB A012304
SHA-256 E7568FE6E12331F4FD7DE61DA4C7559D0F8EB192A218D4741A3BA75184333838
serial c7c41efe92d825f05eae841a4a82c1, issuer emSign Root TLS CA - G3

EM OV TLS CA - G3B (eMudhra BV), CCADB A012308
SHA-256 98B896625C0C230ADEEC3EB2CF6AAD5001ECF9156A68644E82374CE5833BC25B
serial 6cada367fb1c100088120ea202d568, issuer emSign Root TLS CA - G3

EM DV TLS CA - G3B (eMudhra BV), CCADB A012302
SHA-256 42C4ACCD12C4F59597925E1A08A7A90102608543809308D50EC427E118BA1493
serial a4aee678f23362b4c0e460b772f214, issuer emSign Root TLS CA - G3

EM EV TLS CA - G3C (eMudhra Inc), CCADB A012296
SHA-256 432EC25F0D28DE9006D97BF752F17BBB2CD41F669933FCB072D9A1148D0261F3
serial 8009928a64107601af05fa2f19f109, issuer emSign Root TLS CA - G3

EM OV TLS CA - G3C (eMudhra Inc), CCADB A012300
SHA-256 CB6E15165AC802E9B3F993F16C25D41F4E81C21EBDE71AE1B012AC00BF9C7C3F
serial 296926c227a3a1526392b19482a504, issuer emSign Root TLS CA - G3

EM DV TLS CA - G3C (eMudhra Inc), CCADB A012294
SHA-256 0164D7CEAE5BB909C272AF151FF44B1177AE9B47D9424B94F1D9558C30934D19
serial 588b2e3c2bb8cda13e1a1209254321, issuer emSign Root TLS CA - G3

EM OV CS CA - G3B (eMudhra BV), CCADB A012306
SHA-256 9E39DE2881273ACC225A149C72BA3E0F51424963669AB633EE1DC7DF5DB067B4
serial 7818933f8f85b4619a2b35fba83d0a, issuer emSign Root CS CA - G3

EM OV CS CA - G3C (eMudhra Inc), CCADB A012298
SHA-256 4B2460A466F95FD40113BCDCCA2CEB29B3B093921DE45474DA7DF48874C630B1
serial 544b7f922c31ae220a4a922916f6e6, issuer emSign Root CS CA - G3

CVE-2026-111943 

Unlike languages that defer entirely to external dynamic system libraries (like OpenSSL), the Go programming runtime implements its own X.509 chain verification engine in the standard library (crypto/x509). While Go usually queries platform certificates, several platforms or static container environments rely on embedded or legacy root certificate pools where certificate revocations are ignored. 

To eliminate exploitation across the entire cloud-native ecosystem including Docker, Kubernetes, Terraform, and Prometheus, the Go team designated the compromised certificates as a vulnerability, CVE-2026-111943, and released Go versions 1.27.3 and 1.26.10. 

 The fixed versions filter out chains containingthe SHA-256 hashes of the SubjectPublicKeyInfo (SPKI) for all eight compromised eMudhra intermediate certificates.

Impact

These compromised certificates could allow adversaries to impersonate servers and intercept or modify traffic. The impact of their exposure is far more than just web browsers. Other programs that check for TLS certificates might still be impacted since they may not check revocation lists. One clear example is related to virtual private networks (VPNs); these technologies will likely require software updates to mitigate the issue. Based on this guidance, Talos strongly recommends users update software using and handling TLS certificates as fixes become available.

Talos is actively monitoring the impact of these compromised certificates and has not seen any malicious incidents involving them in the wild yet (as of October 21, 2026 14:00 UTC / 10:00 a.m. ET).

Significance of this breach  

Public key infrastructure relies on trust being delegated through certificate chains: root CAs authorize intermediate CAs, which can issue certificates within the scope of their authority. An attacker who obtains an intermediate CA’s private key may be able to issue fraudulent certificates that clients accept, subject to the intermediate certificate’s constraints and each client’s validation controls. In this incident, six compromised intermediates were for TLS and two were for code signing.

 For TLS, an attacker able to intercept or redirect a connection could use a fraudulent certificate to impersonate a server and potentially read or modify traffic if the client still trusts the affected key and no applicable protection blocks it. Protections such as revocation, key distrust, certificate transparency enforcement, and certificate pinning can prevent or expose such an attack. Browser vendors have blocked the affected TLS keys, but other applications may rely on separate trust stores or validation paths:

Enterprise infrastructure and VPNs

Organizations should assess TLS-using software and appliances, including proxies, reverse load balancers, VPN clients, and gateways. Exposure depends on the certificate chain being validated and the trust store and revocation behavior in use. A stale or separately managed trust store may need an application, operating-system, firmware, or trust-bundle update; verify the required action for each product.

Software supply chains and CI/CD

Build runners and package managers may be exposed if they fetch content over TLS while still trusting an affected key and an attacker can intercept the connection. A fraudulent TLS certificate could enable registry impersonation, but it would not by itself bypass separate package integrity checks, such as lockfile hashes, checksums, signatures, or provenance controls. Assess the actual package-manager configuration and dependency path.

Industrial IoT and embedded systems

Review devices that use bundled or independently managed CA stores, especially where certificate revocation or trust-store updates may be limited. Some devices may require a vendor update or compensating control, but the necessary action depends on each device’s validation and update mechanisms.

Talos recommends updating affected software and trust stores as vendor fixes become available.

Coverage

The following SNORT® SIDs provide coverage for this threat: 67363 – 67374.

Talos would like to highlight the efforts of Chris Morrison for providing emergency coverage and mitigations for this threat.

Source: Cisco Talos Intelligence · 2026-10-21

Update 10/22: Added section detailing observations of in the wild exploitation and associated IOCs.

Cisco Talos is tracking the disclosure of two unauthenticated remote code execution (RCE) flaws in PHP core, dubbed “php2shell”, triggered by a plain HTTP request and exploitable before any application code runs, affecting every PHP build since 5.4. Based on the entities involved in the disclosure, artificial intelligence and associated technologies played a key role in the discovery of these vulnerabilities — yet another example of how these technologies are forcing change across the landscape, most notably on patching processes for organizations because of the wave of vulnerabilities being disclosed. 

Cisco customers are covered with the Cisco Talos Network Intrusion Prevention (SNORT®) signatures 67359, 67360, and 67375. These rules are also available in the Community Ruleset for open-source customers. Splunk Enterprise Security customers have an Enterprise Security Content Update with detections available. Please refer to the following recommendations, detection, and coverage guidance for more information.

Details

CVE-2026-109618 and CVE-2026-109619 are both critical vulnerabilities with a CVSS v4.0 score of 9.2.

• CVE-2026-109618 occurs when out-of-memory handling interrupts PHP while internal request data is only partially initialized. Request cleanup may then treat invalid data as valid.
• CVE-2026-109619 occurs when a stale internal state is reused after its backing memory has already been freed, before normal initialization resets it.

Impact

The potential blast radius is enormous and extends across the PHP ecosystem. The vulnerability sits in PHP core, so applications running affected versions — including WordPress, Drupal, Magento, Shopware, WooCommerce, and Laravel, plus PHP sites hosted through cPanel or Plesk — may be exposed. Note that many older branches will no longer receive fixes, so customers are urged to upgrade to a supported version as soon as possible.

Talos regularly investigates threat actor exploitation of vulnerabilities. State-sponsored and affiliated threat actors, as well as ransomware and other financially motivated groups, all employ tactics to exploit RCE. Talos assesses that all industries running PHP applications are at risk for exploitation if systems remain unpatched.

PHP 8.1 and older are end of life (EOL), and PHP 8.2 security support ends Dec. 31, 2026. Talos’ initial estimates based on open-source intelligence show a significant corpus of PHP systems that will not receive a patch (~50%). If your organization is running PHP 8.1 or older, Talos very strongly advises immediate update to PHP 8.2 or later. There is no patch for PHP 8.1 or older.

Talos is actively monitoring the impact of these CVEs and has not seen them being exploited in the wild yet (as of October 21, 2026 14:00 UTC/10:00 a.m. ET).

Observed Exploitation 

Cisco Talos began observing exploitation attempts within hours of the vulnerabilities’ disclosure. So far, most of the activity is scanning, along with some uncoordinated attempts to deliver various payloads. This is expected: scanning or basic exploitation with public proof-of-concept (PoC) code takes far less effort than integrating a vulnerability into an actor’s own tooling. We expect exploitation volume to grow in the coming days, and campaigns to become more sophisticated and coordinated as more capable groups finish updating their tooling and begin deploying it. 

Recommendations and detection guidance

Talos strongly recommends all PHP users to upgrade to the available fixed releases. There are no intermediate or temporary controls that provide comprehensive protection; however, PHP advises that the following measure may reduce exposure to specific attack paths:

CVE-2026-109618

• Set memory_limit=-1, preferably in a way applications can’t override, such as php_admin_value in the FPM pool or Apache configuration, and check that no pool, directory or application setting puts a finite limit back. This removes the controllable PHP memory limit failure, but an underlying allocation failure can still reach the vulnerable path.
• Set a low post_max_size. For applications that don’t require file uploads, set post_max_size = 8M. If file uploads are necessary, set post_max_size = 32M. Keep upload_max_filesize below post_max_size. Consider enforcing limits at the web server or proxy level for decoded request size, input field count, multipart part count, header count, and nesting depth. These limits must also cover requests without a usable Content-Length.
• Use a container or cgroup limit as an availability boundary, preferably with a policy that kills only the affected worker. Do not substitute RLIMIT_AS or RLIMIT_DATA, as these can cause the vulnerable allocation failure.

CVE-2026-109619

• Set session.upload_progress.enabled=0 and restart every worker. Use php.ini, an FPM pool, or server configuration that applies before request parsing. Do not rely on ini_set() or FPM .user.ini. This blocks the confirmed session paths but not other variants.
• On PHP 8.5, set fatal_error_backtraces=0 and restart every worker. This blocks the confirmed fatal backtrace path only.
• Remove invalid or deprecated settings applied per request that emit diagnostics before initialization. Hiding diagnostics with error_reporting, display_errors, or @ does not help.
• Fix attacker-reachable fatal errors and execution timeouts, including failures in callbacks, upload or import processing, and cleanup.

This is another vulnerability that owes its discovery to AI and its associated technologies. As we move through 2026, the wave of vulnerabilities and related patches is building. Talos advises organizations to work on a triaged process for prioritizing vulnerabilities with a specific focus on public-facing systems and vulnerabilities that are under active exploitation. The glaring need to prioritize vulnerabilities along with a streamlined process for rolling out patching strongly indicates that the historic trend of “baking in” patches before deployment is not going to survive the AI era.

The true impact of this vulnerability will take time to evaluate. These types of vulnerabilities that impact core technologies tend to cascade into other platforms and applications as they evaluate impact and provide associated patching, harkening back to the waves of exploitation that we saw after Log4J.

Coverage

SNORT® SIDs covering these vulnerabilities for subscribers: 67359, 67360, 67375. Free community rules are live through our Community Ruleset.

Splunk has released an Enterprise Security Content Update (ESCU) related to the ongoing PHP2Shell activity with additional detections. Splunk Enterprise Security customers are urged to download and apply.

Talos would like to highlight the efforts of Ankur Tyagi, Dalton Schaadt, Brandon Stultz, and Matt Killion for providing emergency coverage and mitigations for these threats.

In this video, Talos’ Nick Biasini explains what the vulnerabilities allow adversaries to do, how to assess your exposure, and what defenders should prioritize.

Indicators of Compromise (IoCs) 

5.191.140[.]240 
158.69.113[.]75 
94.154.43[.]149 
143.246.223[.]124 
45.198.224[.]169 
85.11.167[.]243 

Source: Cisco Talos Intelligence · 2026-10-21