Day: October 21, 2026

  • Smashing Security podcast #489: How a brand new crypto wallet came with a spy inside

    Imagine buying a brand new hardware wallet for your cryptocurrency with the shrink-wrap still on… what could possibly be hiding inside? We break out a Geiger counter and a cat to find out.

    Meanwhile, malicious ads are targeting journalists with zero-click attacks.

    Plus, Origin’s Spencer Thompson reveals what AI agents are really getting up to on your employees’ laptops when nobody’s looking.

    All this and more in episode 489 of the “Smashing Security” podcast with cybersecurity expert and keynote speaker Graham Cluley, and special guest Lianne Potter.

    Source: Graham Cluley · 2026-10-21

  • Compromised eMudhra intermediate certificates

    Compromised eMudhra intermediate certificates

    Compromised eMudhra intermediate certificates

    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

  • New US law requires dating apps to include warnings on romance scams

    New US law requires dating apps to include warnings on romance scams

    A new U.S. law signed by President Donald Trump Tuesday will require online dating services to notify users when someone they’ve been talking to is banned from the platform for fraud.

    The bipartisan Romance Scam Prevention Act, backed by senators Marsha Blackburn of Tennessee (R-Ten) and John Hickenlooper of Colorado (D-Colo), was passed unanimously by the Senate in late September and went to the president for signature earlier this month.

    Romance fraud schemes accelerated during the COVID-19 pandemic when more seniors turned to dating sites for companionship, followed by scammers. Romance scams incurred record-high losses in 2025, with Federal Trade Commission data showing over 70,000 reports and a staggering $1.47 billion lost in the U.S. Losses also reportedly surged in the U.K., South Korea, Australia and across Africa.

    Some dating sites already remove fraudsters’ accounts but a victim may continue talking to a scammer off the app long after a scammer’s profile has been deleted. The Romance Scam Prevention Act aims to close that gap by requiring dating platforms to send a fraud ban notification to anyone who has communicated with someone with a fraudulent account.

    https://www.icij.org/news/2026/07/dating-app-scam-models-influencers-social-discovery-group/

    Accountability Inside the Matrix: How models, influencers and engagement quotas power the Social Discovery Group’s dating machine and global profits Jul 23, 2026

    https://www.icij.org/news/2026/09/tinder-swindlers-plan-for-a-dating-app-sparks-industry-backlash/

    Collaborative Journalism ‘Tinder Swindler’s’ plan for a dating app sparks industry backlash Sep 18, 2026

    https://www.icij.org/investigations/coin-laundry/crypto-giant-circle-rebuffed-efforts-to-help-scam-victims-police-say/

    CRYPTOCURRENCY Crypto giant Circle rebuffed efforts to help scam victims, police say Jul 08, 2026

    Recommended reading Accountability Inside the Matrix: How models, influencers and engagement quotas power the Social Discovery Group’s dating machine and global profits Jul 23, 2026 Collaborative Journalism ‘Tinder Swindler’s’ plan for a dating app sparks industry backlash Sep 18, 2026 CRYPTOCURRENCY Crypto giant Circle rebuffed efforts to help scam victims, police say Jul 08, 2026

    Source: ICIJ · 2026-10-21

  • The Missing Layer in Vulnerability Prioritization: Full Visibility Into Your Attack Surface

    Security teams have more vulnerability data at their disposal than ever. But even the best intelligence has limited value if teams can’t determine where those vulnerabilities exist within their own environment.

    For many organizations, that visibility remains a challenge. Asset inventories, scanners, and ticketing systems provide valuable information, but connecting those insights with real-world exploit activity isn’t always straightforward. And as environments evolve, undocumented assets, forgotten infrastructure, and newly exposed systems can introduce risks that traditional inventories may miss.

    Flashpoint External Attack Surface Management (EASM) helps close that gap by connecting continuous discovery of internet-facing assets with Flashpoint’s threat-informed Vulnerability Intelligence. With coverage of more than 480,000 vulnerabilities, including over 105,000 not found in NVD or CVE, Flashpoint provides context on active exploitation, exploit maturity, and ransomware risk through its patented Ransomware Risk model. Together, these capabilities help teams identify which exposures warrant the most immediate attention.

    What is EASM? External Attack Surface Management (EASM) is the continuous discovery and monitoring of an organization’s internet-facing assets, including domains, subdomains, IPs, and infrastructure that isn’t formally tracked. It gives security teams visibility into what’s exposed to the internet, whether or not that infrastructure was deliberately set up or documented.

    How EASM Extends Vulnerability Prioritization to Your Full Environment

    EASM continuously discovers internet-facing assets associated with an organization, including domains, subdomains, IP addresses, and infrastructure that may not appear in existing inventories. This could include a subsidiary’s infrastructure following an acquisition, a forgotten staging environment, or a cloud instance that remains active long after a project ends.

    With Flashpoint EASM, discovered assets enter a triage queue organized by relevance, helping teams focus on assets that warrant further investigation. Once ownership is confirmed, Flashpoint maps those assets against its Vulnerability Intelligence to identify vulnerabilities associated with the software versions running on them.

    Findings are prioritized using Flashpoint KEV, EPSS, and Ransomware Risk scores. Asset-level details also show the products and versions responsible for identified exposures, along with potentially high-risk open ports such as RDP and SSH. This gives teams the context they need to assess risk and determine where remediation should begin.

    Example Scenario

    Consider a development team that deploys a staging server running an outdated web framework. The project ends, but the server remains online and is never added to the organization’s asset inventory.

    Flashpoint EASM discovers the server and shows how it connects to the organization’s infrastructure. Once the team confirms ownership, Flashpoint Vulnerability Intelligence identifies an actively exploited CVE affecting the framework version.

    The team can now investigate an exposure that might otherwise have gone unnoticed and prioritize remediation based on evidence of active exploitation.

    Why This Matters More in Regulated Industries

    For organizations in heavily regulated industries such as financial services and healthcare, incomplete asset visibility can introduce additional compliance and security risks. Requirements under frameworks and regulations such as GLBA and HIPAA make maintaining appropriate safeguards especially important. An unknown, internet-facing asset with an exploitable vulnerability can create exposure regardless of whether it appears in the organization’s CMDB.

    Mergers and acquisitions can complicate this further. Acquired organizations bring infrastructure that security teams may have limited visibility into, including assets that have not yet been incorporated into existing monitoring processes.

    Continuous external asset discovery helps teams identify and assess that infrastructure earlier, reducing reliance on periodic audits or manual inventory updates to uncover potential exposures.

    Discovery and Prioritization, Built Into One Platform

    When attack surface discovery and vulnerability intelligence operate in separate systems, security teams may need to manually correlate asset inventories with vulnerability findings. That process becomes increasingly difficult as infrastructure changes and new vulnerabilities emerge.

    Flashpoint brings these capabilities together in one platform, an approach we call attack surface intelligence. Newly discovered assets can be evaluated against Flashpoint’s Vulnerability Intelligence, giving teams access to threat-informed prioritization within the same workflow.

    For teams already using Flashpoint Vulnerability Intelligence, EASM can be added as a module within the existing Ignite platform, with no separate console to manage. Contact your account team to learn more about adding EASM to your deployment. New to Flashpoint? Schedule a demo to explore how Vulnerability Intelligence and EASM work together to help your team identify and prioritize external exposures.

    Frequently Asked Questions

    How is EASM different from a vulnerability scanner? 

    Traditional vulnerability scanners scan assets you already know about and tell them to check, typically from inside the network perimeter. EASM continuously discovers internet-facing assets from the outside, including unknown infrastructure like forgotten test environments and acquired systems, then enriches them with vulnerability intelligence beyond public sources like NVD and CVE. The two are complementary: scanners provide depth on known internal assets, while EASM extends that visibility to what’s exposed externally.

    Can EASM help identify compound risk on a single asset? 

    Yes. The Vulnerable Assets view surfaces how many vulnerabilities are tied to a given asset, so teams can quickly spot assets carrying disproportionate risk and prioritize accordingly, rather than treating every finding as an isolated issue.

    If we’re already running Flashpoint Vulnerability Intelligence, do we need a new implementation to add EASM? 

    No. EASM is a module inside the platform you’re already using. It appears inside the same Ignite workflows your team relies on today, with no separate console or parallel rollout required.

    How is EASM priced?

    EASM is priced based on company size rather than asset count or seats, so costs are predictable and don’t scale up just because the attack surface grows.

    See Flashpoint in Action

    Source: Flashpoint · 2026-10-21

  • Citizen Lab Director Slams Trump Administration, ‘Techno-Fascist’ Executives

    Director Ron Deibert spoke to a crowd in his keynote address at SecTor 2026, warning that the threats that the Citizen Lab investigates are being “super-charged” thanks to AI. In particular, he criticized the United States’ “descent into authoritarianism” and use of AI to spread propaganda.

    Source: Citizen Lab · 2026-10-21

  • Kremlin payment firm A7 has been pumping billions in ‘untraceable’ cash into global financial system

    Kremlin payment firm A7 has been pumping billions in ‘untraceable’ cash into global financial system

    At the sprawling Sadovod market in southeast Moscow, among the 160 acres of clothing, jewelry and appliance booths, at least eight teams are spotted, working apart from the everyday hustle and bustle of the market.

    Throughout a business day, these teams, known in confidential records as “departments,” receive a steady stream of customers, almost always carrying bags of various shapes and sizes.

    And inside the bags are piles and piles of cash — Russian rubles. These departments, staffed by payment brokers, are a key intake point for one of the largest, and most secretive, cash-processing operations in the world.

    The inside of the sprawling, 160-acre market. Image: Natalia Senatorova / Wikimedia

    Welcome to the industrial cash machine that is A7, the payments giant backed by the Russian state.

    Between November 2024 and July 2025, A7 processed at least 283 tons of cash rubles, worth more than $14 billion, an investigation by the International Consortium of Investigative Journalists and Russian independent media outlet Proekt has found.

    For A7, ICIJ discovered, cash is king, the jet fuel for a firm now under scrutiny as a “shadow banking network” designed to evade Western sanctions at scale, according to U.S. authorities.

    On Oct. 1, the U.S. Treasury sanctioned A7 as a “significant transnational criminal organization,” which “utilizes money laundering methodologies to fraudulently move vast sums of money in violation of sanctions and other laws in the jurisdictions in which it operates.”

    But while Western governments and banks scramble to trace A7 money flows through the international financial system, ICIJ’s investigation reveals that the origins of the bulk of A7 transmissions are, in fact, untraceable.

    According to internal A7 records seen by ICIJ, and people familiar with the matter, a huge portion of A7’s payments do not stem from conventional bank transfers by clients inside Russia, but literally from hundreds of tons of cash rubles.

    Leaked internal records allowed ICIJ to identify that a handful of wholesale markets and other businesses around the Russian capital, including Sadovod, where much of the business is done in cash, made up a significant share of the cash A7 processed.

    The records show that while the source of the cash is untraceable, its destination is not: Most of the cash is bound not for Western markets, but for China.

    A fountain in Sadovod market in southeast Moscow. Image: Nikita Andreev / Wikimedia

    A7 did not return ICIJ’s requests for comment.

    In public statements, A7 has strongly rejected the U.S. allegations of wrongdoing, saying that it “employs a modern, multi-tiered compliance system” and that it was “established to ensure uninterrupted settlements for the Russian market, which has been subjected to unlawful restrictive measures.”

    “All clients undergo screening to identify risks and prevent the servicing of individuals or organizations whose activities violate regulatory requirements,” it continued.

    Experts say the fact that cash drives A7 raises the spectre of a money laundering operation limited only by the size of the market and A7’s capacity to physically handle the cash. As such, A7’s cash-based model presents challenges not previously understood both to the conventional banking system and to law enforcement.

    “Cash is considered one of the highest risk methods of payment and store of value because it’s anonymous, it can travel across borders, and it doesn’t attach to any specific individual or company,” George Voloshin, an expert at ACAMS, a global training body for anti-financial crime, told ICIJ in an interview.

    “The A7 network not only helps Russia circumvent Western sanctions and export controls,” Voloshin continued. The fact that A7 takes massive volumes of cash from Moscow’s wholesale markets suggests that the company “is also likely to facilitate cash-based money laundering by effectively legitimizing potential proceeds of crime,” he said.

    Voloshin added that international banks bear an additional burden of tracing payments emanating from A7. “The main risk is that [foreign] intermediary or beneficiary banks become complicit in [a] form of criminal activity that they know nothing about, because they don’t have any visibility into what’s happening in Russia where the money originates from.”

    Cash by the ton, bound for China

    On its launch in late 2024, A7 touted itself as a sanctions-proof payments system, and has come under increasing scrutiny for its role as one of the Kremlin’s principal channels for laundering billions of dollars worth of payments out of Russia and into the global financial system, via a global network of shell companies, often with accounts at major international banks.

    As part of its launch, A7 integrated into its business a hodgepodge of informal payment brokers at Moscow markets, including Sadovod, according to internal A7 records seen by ICIJ.

    “For [A7], Sadovod is simply a big client base — a big, aggregated pile of clients,” a person familiar with the matter, who requested anonymity due to security concerns, told ICIJ. “And that’s exactly what they go there for: the money and the profit.”

    For years, this ecosystem of market brokers converted importers’ cash into conventional bank transfers or crypto, most often bound for China. This informal system was upended by Western sanctions, which barred Russian businesses from the SWIFT system, the international messaging network that allows banks to exchange transactions. The threat of U.S. secondary sanctions — which target entities for doing business with sanctioned states or businesses — made Chinese banks more cautious when dealing with Russia.

    The informal cash payment system at Moscow’s wholesale markets “depends on trusted intermediaries, established relationships and confidence that money will arrive,” Ilia Shumanov, managing partner of Russia-focused due diligence firm Tri-Trace Investigations, told ICIJ. “Its international reach can be extensive, while outsiders have limited visibility into the underlying transactions.”

    Under A7’s new, supercharged system, a platoon of market brokers takes in the bags of cash brought by vendors and makes an initial count.

    The brokers then stuff the rubles into numbered bags to be loaded, along with clients’ payment orders, into vans bound for an A7 processing office elsewhere in the Russian capital, according to leaked internal payment and cash management records.

    A review of cash deposit and internal payment records shows that a small army of 50 or so A7 cashiers feeds the cash into a counting system where the amounts are verified; A7 enters the bag number, ruble amount and the client’s payment order into a bespoke payment management system, then trucks the cash on to Promsvyazbank, or PSB, the Russian state defense bank, a co-owner of the company. PSB puts it in a vault and credits A7 accounts. PSB acknowledged ICIJ’s request for comment, but did not provide a response.

    Photo of an industrial complex with tanks and pipes, including Gunvor's logo.

    https://www.icij.org/investigations/china-capital/gunvor-publicly-condemned-russias-war-but-continued-to-do-business-with-russian-energy-firms-records-show/

    CHINA CAPITAL Gunvor publicly condemned Russia’s war but continued to do business with Russian energy firms, records show  Oct 01, 2026

    https://www.icij.org/news/2026/09/trump-administration-gave-firm-with-ties-to-ballroom-donor-the-green-light-to-do-business-with-a-sanctioned-russian-bank/

    Accountability Trump administration gave firm with ties to ballroom donor the green light to do business with a sanctioned Russian bank Sep 21, 2026

    https://www.icij.org/news/2026/02/hong-kong-firms-feed-european-tech-to-russias-war-in-ukraine-report-says/

    SANCTIONS Hong Kong firms feed European tech to Russia’s war in Ukraine, report says Feb 18, 2026

    Recommended reading CHINA CAPITAL Gunvor publicly condemned Russia’s war but continued to do business with Russian energy firms, records show  Oct 01, 2026 Accountability Trump administration gave firm with ties to ballroom donor the green light to do business with a sanctioned Russian bank Sep 21, 2026 SANCTIONS Hong Kong firms feed European tech to Russia’s war in Ukraine, report says Feb 18, 2026

    Source: ICIJ · 2026-10-21

  • Widespread PHP Flaw May Cause Many Site Outages Today

    Widespread PHP Flaw May Cause Many Site Outages Today

    Expect to see quite a few websites serving error pages today: Nearly 70 percent of websites need to update their core software to fix a pair of vulnerabilities that allow an attacker to seize full control over affected servers. Experts say there are working exploits for the flaws, and that these critical bugs are already being exploited in the wild.

    Image: Shutterstock.com, Sashkin.

    The flaws at issue are present in PHP, the programming language that powers sites running on a large number of web publishing systems, including Drupal, Magento, Joomla and WordPress. Earlier today, PHP released an emergency security update to fix two critical bugs that can allow an attacker to execute code of their choosing on a vulnerable server.

    Reuters reports that government websites in Europe and elsewhere went offline today after the PHP vulnerabilities were disclosed. Cloudflare said it has already detected some exploitation of the flaw, and that at 3:02 am (UTC) it implemented web application firewall rules to protect websites from attack traffic seeking to exploit the bugs, which could cause a denial of service condition, remote code execution, and data exposure.

    OpenAI, which was involved in the vulnerability research and outreach, said “given the severity of these flaws and PHP’s widespread use, we consider this one of the most impactful security issues in recent memory.”

    Censys, a company that tracks the technology used by Internet hosts, said a recent scan identified approximately 2.58 million Internet facing hosts and 54.9 million web properties running PHP.

    Security experts at Wiz said every PHP version released in the last decade is affected by at least one of these vulnerabilities [full disclosure: Wiz is an advertiser on this blog].

    “These findings rank among the most severe vulnerabilities discovered in PHP, and arguably in software history,” reads a blog post published today by a team of researchers at Wiz, which was one of several organizations credited with discovering the vulnerabilities. “The underlying flaws had been present for decades, but demonstrating their exploitability required an exceptionally complex chain of steps, at the edge of what human researchers could practically achieve. Frontier AI models substantially reduced that barrier, turning a longstanding flaw into an exploit.”

    The Wiz researchers say it is likely the PHP vulnerabilities will be mass-exploited to install web-based backdoors or “web shells,” which give attackers a web-based panel that allows them to remotely control infected sites. Wiz said that prior to the PHP bugs being publicly disclosed, the company worked with the PHP team, Calif and OpenAI to measure the size of the problem and coordinate patch verification and disclosure.

    The PHP zero-day vulnerabilities are being tracked by their CVE numbers, CVE-2026-109618 and CVE-2026-109619, and they affect all web servers running PHP 5.4 or later. The bugs are fixed in PHP 8.5.12, 8.4.27, 8.3.36, and 8.2.35.

    According to Wiz, PHP is so deeply embedded in many web applications that we are likely to see organizations struggling to patch these vulnerabilities for some time to come, comparing this PHP vulnerability pair with the Log4Shell weakness that emerged in 2021 — a widespread, severe-as-it-gets security flaw in Log4j, a popular Java logging framework.

    “A vulnerability in core PHP reaches far beyond a single application,” the Wiz researchers wrote. “PHP runs across clouds, hosting providers, content-delivery networks and millions of independently managed servers. Reducing exposure before the technical details became public required coordinated work across that entire ecosystem.”

    The SANS Internet Storm Center is keeping an eye on major software platforms that are shipping updates to deal with these PHP flaws. For example, Ubuntu just released updated PHP packages. For a technical deep-dive on these vulnerabilities that tells the timeline of the discovery of these bugs in a comic book style, check out this post from Calif, another technology company credited with finding the PHP flaws.

    A snapshot of php2shell.censys.com, the website Censys set up to track the PHP vulnerabilities.

    This is a fast-moving story. Updates will be noted here with timestamps.

    Update, 2:30 pm ET: Add figures from Censys and a link to Calif’s writeup.

    Source: Krebs on Security · 2026-10-21

  • Critical RCE vulnerabilities in PHP (CVE-2026-109618, CVE-2026-109619)

    Critical RCE vulnerabilities in PHP (CVE-2026-109618, CVE-2026-109619)

    UPD 23.10.2026: added Kaspersky SIEM rules and events for developing custom detection rules or conducting threat hunting.

    UPD 22.10.2026: added a description of how the Kaspersky Managed Detection and Response service detects the described malicious activity.

    UPD 22.10.2026: added a description of how Kaspersky Vulnerability Management detects vulnerable versions of PHP.

    Vulnerability overview

    On October 20, 2026, the PHP security team published a preliminary notice regarding an upcoming emergency release that addresses two critical vulnerabilities (both rated 9.2 on the CVSS scale). The patches were released on Wednesday, October 21, 2026, at 14:00 UTC.

    The release was expedited after information about the vulnerabilities was leaked to the public before the scheduled embargo was lifted. In a post on Hacker News, a user reported two RCE vulnerabilities in PHP, allegedly affecting all versions starting with PHP 5.4.0.

    The vulnerabilities in question are CVE-2026-109618 and CVE-2026-109619. Shortly after the post appeared, researchers confirmed the existence of the vulnerabilities. Along with the leak of details, an exploit unofficially named PHP2Shell appeared online. In the leaked demo video, the exploit is shown in action on web servers running WordPress, MediaWiki, phpBB, Magento, Joomla, Laravel, Symfony, Drupal, and WHMCS — platforms that power many modern websites. The authenticity of the demonstration and the exact behavior of the exploit had not been independently verified at the time of publication.

    According to the researcher who published the PoC, the vulnerabilities are related to the handling of the multipart/form-data MIME type in conjunction with the session upload progress mechanism (session.upload_progress) in the PHP core and fall under the categories of use-after-free and memory corruption. This means that the flaws cannot be fixed via application code, and the only fix is to update PHP on the server. The attack requires no authentication: an attacker with network access to a PHP application can execute arbitrary code with the privileges of the PHP process without needing to authenticate. Security advisories issued by the PHP team on October 21 confirm this information.

    The vulnerabilities affect PHP versions 5, 7, and 8. As of this publication, branches 8.2 through 8.5 are supported. Older branches, including PHP 8.1, 8.0, 7.x, and 5.x, have reached the end of their lifecycle; however, due to the critical severity of the vulnerabilities, backported patches have also been released for versions 7.4, 8.0, and 8.1.

    Sansec experts estimate that widespread exploitation could begin within 15 minutes of the update’s release. We strongly recommend that administrators responsible for publicly accessible PHP web servers take the following steps before the patch is available:

    1. Take an inventory of all PHP-based systems in your infrastructure (such as web servers, control panels, and third-party software).
    2. Disable upload-progress: set session.upload_progress.enabled = Off using the php_admin_flag in PHP-FPM pools.
    3. Block multipart requests on nginx and Apache servers.
    4. Consider temporarily isolating PHP applications that connect to the Internet until fixes are released.
    5. Be ready to install the patch immediately upon its release.
    6. Plan to migrate servers running unsupported versions (8.1 and earlier) to the latest PHP branch.

    Detection by Kaspersky solutions

    Kaspersky solutions detect the described malicious activity at various stages of the attack. Possible detection scenarios are listed below.

    When an attempt is made to exploit these RCE vulnerabilities, Kaspersky Endpoint Detection and Response promptly alerts the user to suspicious actions performed in the context of a web server, on both Linux and Windows machines. This activity is detected by the following rules:

    Detection of the PHP2Shell vulnerability exploit by KEDR

    Detection of the PHP2Shell vulnerability exploit by KEDR

    Exploitation of the PHP2Shell vulnerability in network traffic is detected by Kaspersky Anti Targeted Attack (KATA). This solution detects such activity with the following verdicts: Exploit.CVE-2026-109618.HTTP.C&C and Exploit.CVE-2026-109619.HTTP.C&C.

    Detection of the PHP2Shell vulnerability exploit by KATA

    Detection of the PHP2Shell vulnerability exploit by KATA

    Kaspersky Endpoint Security, now available as Kaspersky Next, also detects malicious post-exploitation activity using the Behavior Detection component, with verdicts such as PDM:Exploit.Linux.Generic and PDM:Exploit.Win32.Generic.

    Our Kaspersky Vulnerability Management solution detects vulnerable software versions using the Vulnerability scanning and Agentless black-box scanning components.

    Detection of the PHP vulnerability in Kaspersky Vulnerability Management

    Detection of the PHP vulnerability in Kaspersky Vulnerability Management

    The Kaspersky Managed Detection and Response service detects the exploitation of the described vulnerabilities by monitoring activity characteristic of RCE:

    • Spawning of suspicious processes by the web server;
    • Creation of suspicious executable files in the web application directory;
    • Creation of suspicious scripts in the web application directory;
    • Creation of files with uncommon extensions in the web application directory;
    • Execution of reconnaissance commands by the web server process;
    • Execution of persistence commands by the web server process;
    • Delivery and launch of web shells on the web server.

    Moreover, MDR detects other malicious activity not directly related to remote code execution.

    To protect companies that use our Kaspersky SIEM system, the product repository includes rules that help detect the following malicious activity.

    • Execution of suspicious executable files by web server processes on Windows and Linux machines:
      • R300_04_Windows shell started by a web application
      • R152_08_A running Linux shell process has a suspicious parent process
    • Execution of reconnaissance commands by the web server process:
      • R286_05_Possible web-shell (Linux)

    We also recommend monitoring the creation of scripts or executable files in the web server directory when developing your own detection rules or conducting threat hunting:

    ((DeviceEventClassID = '4663' AND DeviceCustomString1 ilike 'WriteData') OR DeviceEventClassID = '11')
    AND match(FileName,'(?i).*\.(php|asp|aspx|ashx|jsp|js|jar|jse|dll|exe|bat|ps1|vbs|wsf|wsh|msi|msp|hta|cpl)$')
    AND match(DestinationProcessName,'(?i).*(php-cgi|nginx|httpd|w3wp)\.exe')
    Name = 'openat' AND has(SA.Nametype, 'CREATE')
    AND
    length(arrayFilter(x -> match(x, '(public_html|var/www|usr/local/apache2|usr/local/httpd|var/apache|srv/www|home/httpd/html|srv/http|usr/share/nginx/html|var/lib/pgsql/data|usr/local/mysql/data|var/lib/mysql|var/vsftpd|etc/bind|var/named)'), SA.FileName))>1
    AND
    length(arrayFilter(x -> match(x, '\.(aspx|asp|asmx|asax|ashx|jspx|jsp|js|phpt|php|phtml|pht|cfm|shtml|htaccess|fcgi|cgi|pl|py|sh)'), SA.FileName))>1

    Source: Securelist (Kaspersky GReAT) · 2026-10-21

  • Two critical RCEs in PHP core

    Two critical RCEs in PHP core

    Two critical RCEs in PHP core

    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

  • ‘This Is Not a Drill’: Critical PHP Vulnerabilities Are Setting the Internet on Fire

    ‘This Is Not a Drill’: Critical PHP Vulnerabilities Are Setting the Internet on Fire

    The PHP Foundation has revealed two serious vulnerabilities that could impact millions of websites. Security experts warn that failure to quickly patch the flaws could have dire consequences.

    Source: WIRED Security · 2026-10-21