The PHP security team released emergency security patches for two critical remote code execution (RCE) vulnerabilities (CVE-2026-109618 and CVE-2026-109619) tracked collectively as PHP2Shell. The two unauthenticated RCE flaws were discovered by Calif, Wiz, and OpenAI security researchers, and affect all PHP installations that serve web requests, including PHP-FPM, Apache with mod_php, php-cgi, FrankenPHP, and LiteSpeed. "We consider the risk highest for mod_php, with a demonstrated exploit where an unauthenticated request can trigger the attack before any application code runs," the PHP security team said. Both flaws stem from the same underlying problem: PHP can leave its memory in a corrupted state when a request ends abnormally, and both can be exploited to achieve remote code execution. CVE-2026-109618 can be used to gain remote code execution as the web worker account by exploiting a chain of weaknesses that trigger out-of-memory corruption, while the CVE-2026-109619 stale global state vulnerability enables unauthenticated heap use-after-free, memory disclosure, and remote code execution with the web worker's privileges.
An investigation into a threat actor bypassing AI safety controls to coordinate credential theft, VoIP fraud planning, and database exfiltration. The post “Next Exploit Opportunities”: How a Threat Actor Used AI to Help Plan and Execute Multiple Types of Cybercrime Activities appeared first on Unit 42.
ClickFix attacks are surging as cybercriminals use fake AI installers, malicious search results, and trusted chatbot platforms to trick users into executing malware. Push Security examines how these attacks evade traditional defenses and why AI tools have become increasingly effective lures.
CVE-2026-109618 and CVE-2026-109619 are Critical vulnerabilities in PHP, a scripting language used globally for web servers and CMS systems. The post Threat Brief: Critical Vulnerabilities in PHP: CVE-2026-109618, CVE-2026-109619 appeared first on Unit 42.
PHP prepares emergency patches for two critical RCE flaws, while older, unsupported versions could remain exposed without vendor fixes. The U.S. government ordered federal civilian agencies to remove DeepSeek products from their IT systems and stop buying them. The order also reaches third-party tools and services built with DeepSeek implementations, which is the part most organizations should notice. The notice doesn’t explain exactly what counts as a “DeepSeek implementation.” Agencies will need to ask suppliers whether their products fall under the ban. “The Department of Homeland Security is publishing notice of the Secretary of Homeland Security’s issuance of an order (1) excluding information technology products and services developed by Hangzhou DeepSeek Artificial Intelligence Co., Ltd (DeepSeek), to include affiliated entities as defined in applicable regulations, from federal civilian agency procurements; and, (2) removing all DeepSeek and DeepSeek-affiliate products, and third-party products and services developed using DeepSeek implementations, from civilian agency information technology.” reads the order. Homeland Security Secretary Markwayne Mullin signed the order on July 24, 2026, under the Federal Acquisition Supply Chain Security Act of 2018. DHS published it in the Federal Register on October 20 as document 2026-21447, under docket DHS-2026-0628. The order cites national-security concerns. According to reporting on the notice, DHS said DeepSeek’s models could transfer sensitive data to China and may contain malware or other security weaknesses. “In a notice made public on Monday, the Department of Homeland Security also barred agencies from acquiring DeepSeek products and services, including those developed by affiliated entities.” South China Morning Post reports, “The notice said that using the company’s products “may result in the transfer of sensitive data to the PRC if used by US government employees or vendors”, adding that the models “themselves may contain malware or other security vulnerabilities”.” DeepSeek’s own privacy policy says it collects, processes, and stores personal data in the People’s Republic of China. That does not prove wrongdoing, but it explains why U.S. agencies treat data residency and foreign legal access as material risks. The ban doesn’t apply to private companies or ordinary users, but government contractors may also be affected. They generally can’t use covered products or services for federal contracts unless they receive a waiver. The goal is to catch hidden uses of DeepSeek, including AI models built into apps, services and development tools. Agencies need to check their systems, while suppliers must disclose which AI models they use, where the models process data and whether information leaves the customer’s environment. The ban took effect when issued, but existing contracts are covered only after the contracting officer formally updates them. Agencies can request an exception, but they must provide a strong justification. DHS signed the order on July 24 but didn’t publish it until October 20, 87 days later. The rules don’t set a deadline for public release, but they require officials to notify the company and relevant congressional committees and review the order at least once a year. This delay meant affected organizations had to comply before they could read the public explanation or see the signed order. China pushed back. Foreign Ministry spokesperson Mao Ning said Beijing opposes “the overstretching of the concept of national security” and would defend the lawful rights of Chinese companies; DeepSeek did not immediately comment to the Associated Press.[apnews] Follow me on Twitter: @securityaffairs and Facebook and Mastodon Pierluigi Paganini (SecurityAffairs – hacking, AI)
PHP will release emergency fixes for two critical RCE flaws rated 9.2, as researchers warn of potential risks to exposed and unsupported systems. PHP is preparing an emergency security release for two critical vulnerabilities that could let attackers execute code remotely on affected servers. The update is scheduled for today, October 21 at 14:00 UTC, after details of the flaws leaked online ahead of their planned disclosure. I have successfully recreated & lab/field tested CVE-2026-109618 / CVE-2026-109619 > Two heap use-after-free primitives in PHP's `session.upload_progress` handler (`php_session_rfc1867_callback`, ext/session/session.c)…#CyberSecurity #infosec #php #C4b1NKr3W #php2shell pic.twitter.com/WlIAC5kW4S — Jλckλι (@J4ck3LSyN) October 21, 2026 The PHP security team confirmed both vulnerabilities carry a CVSS v4.0 score of 9.2. It hasn’t yet published their technical details, confirmed the affected versions, or identified the releases that will fix them. The official PHP announcement says the full information will accompany the security updates. “The PHP security team would like to give advance notice of an upcoming security release. It is scheduled for Wednesday, 21 October 2026 at 14:00 UTC. It addresses two critical vulnerabilities, both rated CVSS v4.0 9.2.” states the announcement. “All PHP users are encouraged to prepare now so they can upgrade as soon as the release is available. We reserve the right to release earlier should details of either vulnerability become public, or should evidence of active exploitation appear in the wild. Full details, affected versions, and the fixed versions will be published with the release.” Researchers dubbed the vulnerabilities as php2shell, using the identifiers CVE-2026-109618 and CVE-2026-109619. The identifiers and the claim that the flaws allow remote code execution come from reports outside PHP’s initial advisory, rather than from a published technical analysis by the project. According to the Hacker News, the two critical PHP vulnerabilities would be disclosed on October 22. The post described them as remote code execution flaws with CVSS scores of 10.0 and said they affected versions dating back to PHP 5. Researchers at watchTowr subsequently confirmed that the vulnerabilities were real and said the information had leaked before the agreed disclosure date. The company also reported that it had reproduced one of the flaws, CVE-2026-109618, but withheld technical details while patches remained unavailable. PHP published its advance security notice later that day, setting the release for Wednesday, October 21, one day before the date reported in the leak. The team also reserved the right to release the fixes earlier if technical details became public or it found evidence of active exploitation. The difference between the reported severity scores matters. The leaked information cited CVSS 10.0, while PHP officially rated both vulnerabilities 9.2 under CVSS version 4.0. Until the vendor publishes its technical advisory, the official score is the one administrators should use when describing PHP’s assessment. The main concern is the possibility that the flaws affect a wide range of PHP installations. Reports have suggested that versions from PHP 5 onward could be vulnerable, but watchTowr’s FAQ explicitly notes that the scope hasn’t been confirmed by an official vendor advisory. “The report claims the vulnerability affects every PHP version from PHP 5 onward, though this scope has not been confirmed by an official vendor advisory. No specific configuration or feature requirement has been described in the available report.” states watchTowr. “Until PHP publishes an official advisory, security teams cannot determine which specific deployments face the greatest exposure; every organization running PHP in production should prepare to act quickly once a fix is confirmed.” Administrators also don’t yet know which PHP components are involved or whether exploitation depends on a particular configuration or deployment mode. Those details will determine how attackers could reach the vulnerable code and which systems need the most urgent attention. PHP’s supported versions policy adds another complication. The project currently supports four release branches, PHP 8.2 through 8.5, while older branches no longer receive security updates from the PHP project. The anticipated fixes are PHP 8.5.12, 8.4.27, 8.3.36 and 8.2.35, according to tracking by Mallory. These version numbers were predictions ahead of the release, not confirmed package versions in PHP’s advance notice. If the vulnerabilities affect older releases, organizations running PHP 8.1, 8.0, 7.x or 5.x may not receive an upstream fix. They may need to upgrade to a supported branch, apply any security updates provided by their operating system vendor, or restrict access to affected systems until they can remediate them. Research by Mallory highlights the scale of the potential problem. Using Shodan data collected on October 20, the company identified about 884,000 internet-facing hosts reporting PHP 8.1 or an older version, representing roughly 59% of the 1.5 million hosts that disclosed a PHP version in their HTTP banners. These figures don’t establish that every host is vulnerable. The count identifies systems running older PHP versions that may not receive a direct fix from the PHP project if the reported scope is confirmed. Another 740,000 hosts reported PHP without revealing a version, making it harder to assess the full exposure. The numbers also count hosts, not individual websites or organizations. Shared hosting can place many websites on the same server, while software vendors and hosting providers may bundle PHP into products that administrators don’t recognize as PHP installations. That makes asset discovery an important first step. Security teams should check web servers, Windows systems, vendor appliances, hosting control panels such as cPanel and Plesk, and applications that include their own PHP runtime. PHP hasn’t published a workaround in its advance notice. Until the fixes become available, organizations should identify their PHP installations and prepare to install the correct update as soon as the vendor publishes it. Internet-facing systems should take priority, particularly servers running business-critical applications or processing sensitive information. Administrators should also check with their Linux distribution and hosting provider, since vendors sometimes backport security fixes without changing the upstream version number in the way expected. For installations running end-of-life PHP, the options are less comfortable. Organizations should plan an upgrade or reduce exposure by taking vulnerable services offline, restricting access through a VPN or IP allowlist, or placing them behind a web application firewall while a longer-term fix is prepared. CERT-EU’s security advisory recommends considering the isolation of internet-facing applications from public networks when immediate patching isn’t possible. “CERT-EU strongly recommends identifying PHP-based applications and preparing to patch as soon as fixed versions become available.”states CERT-EU. “Where immediate remediation is not feasible, organisations should consider isolating internet-facing applications from public networks until a fix can be applied.” This is a precautionary measure, not a confirmed workaround for either PHP vulnerability. Monitoring process activity can also help identify suspicious behavior. On Linux, security teams should investigate PHP-related processes such as php-fpm, php-cgi, httpd or apache2 launching unexpected shells, interpreters or download utilities, including sh, bash, python, curl and wget. Florian Roth’s open-source process-watcher can log programs launched by PHP processes and record their command lines. It provides visibility into process activity, but it doesn’t block an exploit or prevent a malicious command from running. If an investigation uncovers suspicious activity, teams should isolate the affected server, preserve PHP and web server logs, and check for newly created files in web roots, web shells, unexpected scheduled tasks, cron jobs and user accounts. Those steps can help determine whether an attacker has already gained access, rather than simply whether a server was exposed. As of October 21, Huntress said it hadn’t observed exploitation in attacks against its partner environments and hadn’t developed or reproduced a proof of concept. watchTowr’s FAQ also listed no reported exploitation and no vendor patch at the time of its update. That doesn’t mean administrators can safely wait to assess their exposure. Once technical details and fixes become public, attackers may be able to develop working exploits more quickly, particularly if the vulnerabilities affect widely deployed versions of PHP. A previous PHP flaw illustrates how quickly the situation can change. When CVE-2024-4577, which affected PHP running in CGI mode on Windows, became public in June 2024, Akamai reported exploit attempts against its honeypot servers within 24 hours. The scheduled release should answer the questions administrators still face: which versions are affected, which components contain the flaws, whether exploitation requires a particular configuration, and which updates fix each issue. Until then, the priority is straightforward: know where PHP runs, prepare the updates, and avoid leaving internet-facing systems on unsupported versions without additional protection. Follow me on Twitter: @securityaffairs and Facebook and Mastodon Pierluigi Paganini (SecurityAffairs – hacking, PHP)
This story is developing and was written before PHP's scheduled 14:00 UTC release on October 21. Once the release is out, the affected and fixed versions below are confirmed by the official advisory. PHP will ship an out-of-cycle security release at 14:00 UTC today, October 21, for two critical vulnerabilities that its security team has rated 9.2 on the CVSS v4.0 scale but has not described.
Unknown threat actors breached TeamUpdraft's website and potentially gained unauthorized access to customers' connection keys for UpdraftCentral, UpdraftVault, and UpdraftClone, using them to backdoor WordPress sites. TeamUpdraft is the developer behind UpdraftPlus, a popular WordPress backup plugin with over four million active installations. The vendor also offers UpdraftCentral, a remote
U.S. federal civilian agencies must remove DeepSeek products from their information technology systems, along with any third-party products or services "developed using DeepSeek implementations," under a Department of Homeland Security order. They may also no longer buy information technology products or services from the Chinese AI developer or its affiliates Homeland Security Secretary
State Bank of India has identified 3,897 customer records containing personal information in a set of about 375,000 records available on the dark web, and it does not yet know where the data came from. The state-owned bank, India's largest, said in a stock-exchange filing dated October 21 that it "has experienced an incident involving the loss of certain data." The count is
Confirm this action.
Leaving now will discard your changes.