U.S. Cybersecurity and Infrastructure Security Agency (CISA) adds Google Brotli and Adobe Commerce and Magento flaws to its Known Exploited Vulnerabilities catalog.
The U.S. Cybersecurity and Infrastructure Security Agency (CISA) added Google Brotli and Adobe Commerce and Magento vulnerabilities to its Known Exploited Vulnerabilities (KEV) catalog:
Below are the flaws added to the catalog:
CVE-2026-111497 (CVSS score: 9.2) – An unchecked return value vulnerability in Google Brotli th
U.S. Cybersecurity and Infrastructure Security Agency (CISA) adds Google Brotli and Adobe Commerce and Magento flaws to its Known Exploited Vulnerabilities catalog.
CVE-2026-111497 (CVSS score: 9.2) – An unchecked return value vulnerability in Google Brotli that could allow a remote, unauthenticated attacker to corrupt decoder memory, expose sensitive information, cause a denial-of-service, or potentially execute arbitrary code by sending a specially crafted Brotli-compressed stream.
CVE-2026-48356 (CVSS score: 9.3) – An unrestricted file upload vulnerability in Adobe Commerce and Magento that could allow an attacker to execute arbitrary code with the privileges of the current user, potentially gaining elevated access or taking control of the victim’s account or session.
Brotli is a data-compression algorithm developed by Google.It reduces the size of web content, such as HTML, CSS, JavaScript, and other text-based resources. Security researchers have observed exploitation attempts targeting CVE-2026-111497 (aka Node2Shell), a critical flaw in Google’s Brotli library. Previdian recorded one attempt by October 27, while ELLIO researchers recently detected traffic carrying a public exploit that could execute code on vulnerable systems. The activity may indicate attempts to exploit the flaw on a larger scale, but its scope remains unclear. An attacker can trigger the vulnerability to cause crashes, expose sensitive memory or remote code execution when applications decompress attacker-controlled Brotli data. Because Brotli is widely used, multiple projects and vendors have released security updates, including Node.js, PHP, Bun, and Microsoft .NET. Cybersecurity firm Wiz warned that 91% of cloud environments contain resources vulnerable to the flaw, while 82% have publicly exposed Node.js instances.
The second flaw added to the catalog is an unrestricted file upload vulnerability tracked as CVE-2026-48356, dubbed PolyShell. Recently WordPress security firm Sansec warned of attacks exploiting CVE-2026-48356 to infect at least 953 of online stores. The attackers reportedly used a Magento CMS block to insert a malicious loader capable of retrieving and executing a payload hosted under their control.
So far, researchers have not recovered the subsequent payload, leaving the campaign’s ultimate objectives unclear. The activity is believed to have been underway since at least July 2025 and remains ongoing.
U.S. Cybersecurity and Infrastructure Security Agency (CISA) adds PHP flaws PHP2Shell to its Known Exploited Vulnerabilities catalog.
The U.S. Cybersecurity and Infrastructure Security Agency (CISA) added the PHP PHP2Shell vulnerabilities to its Known Exploited Vulnerabilities (KEV) catalog:
CVE-2026-109618 – PHP Memory Corruption Vulnerability
CVE-2026-109619 – PHP Stale Internal Request-State Vulnerability
On October 21, PHP released emergency patches for two critical vulnerab
CVE-2026-109619 – PHP Stale Internal Request-State Vulnerability
On October 21, PHP released emergency patches for two critical vulnerabilities, CVE-2026-109618 and CVE-2026-109619 (CVSS score of 9.2). The flaws affect all PHP versions that handle web requests.
The vulnerable code dates back to PHP 5.4, released in 2012, and resides in the PHP engine itself rather than in individual applications. Attackers can exploit the flaws to execute code remotely by sending specially crafted HTTP requests, without authentication.
Exploitation attempts increased rapidly after the vulnerabilities became public. Cloudflare researchers reported tens of thousands of attempts within the first 45 minutes, hundreds of thousands in just two hours, and millions by October 22.
Cyfirma reported that a group of North Korea-linked group has identified 216 hosts that may still be vulnerable to PHP2Shell. The operators communicate through a private I2P channel that Cyfirma has monitored since October 22. On October 24, they reported that 216 hosts appeared to be unpatched or only partly protected, earlier than Cyfirma expected.
They are checking the systems from 21 compromised machines. At the time Cyfirma captured the conversation, the operators had already checked about one-third of the targets.
“Two handles active since March 2026, coordinating in a closed I2P channel; staging infrastructure shared in-channel.” states the cybersecurity firm. “Target set and scan nodes. “On 24 October the operators reported 216 unpatched or partially mitigated hosts and named 21 scan nodes; the same addresses were seen performing web-shell tooling and upload-progress session-poisoning attempts.”
The scanning is slow on purpose. Volume stays low, the machines rotate, and any node that shows filtering or rate limiting gets pulled and never reused. That’s why a rate-based alert will probably stay quiet.
Sansec tracks a Magento skimmer campaign that infected 953 stores, using five domains, bot filtering and malicious code hidden in CMS blocks.
A criminal group has infected 953 online stores since July 2025, mostly Magento shops, according to Sansec researchers. The attackers add a small piece of code to store pages. When someone visits a shop, their browser contacts the attackers’ server to get further instructions. The server checks whether the visitor is a real shopper or a security scanne
Sansec tracks a Magento skimmer campaign that infected 953 stores, using five domains, bot filtering and malicious code hidden in CMS blocks.
A criminal group has infected 953 online stores since July 2025, mostly Magento shops, according to Sansec researchers. The attackers add a small piece of code to store pages. When someone visits a shop, their browser contacts the attackers’ server to get further instructions. The server checks whether the visitor is a real shopper or a security scanner. If it detects a scanner, it hides the malicious activity.
“deepveindrilling.com is the newest web address of a criminal group that breaks into online stores. The group adds a small piece of code to the store’s pages.” Sansec’s analysis states. “The group has done this to 953 stores since July 2025, mostly Magento shops. It moves to a new address every few months.”
The group’s latest domain is deepveindrilling.com. Sansec found it in the CMS blocks of 83 stores, almost all running Magento. CMS blocks are content sections that Magento adds to store pages. The domain was registered on October 6, 2026, and the first stores began loading it the following evening.
This is the fifth domain linked to a campaign that Sansec has tracked since July 2025 and reported in March as the PolyShell mass attack. Most stores using the latest domain had already been targeted. Of the 83 stores, 60 had previously loaded one of the group’s malicious scripts, and 34 had been doing so since October 2025.
The domain sits behind Cloudflare, and its front page returns a 404. It only answers script requests from visitors of infected stores. The loader code lives in the cms_block table, and Sansec’s scanner, eComscan, found it there on 148 server installs over the campaign, never in core_config_data or theme files.
eComscan first found the new loader at 21:54 UTC on October 7. By the end of October 8, Sansec’s crawler had found it on 74 stores, as two scripts. The first reads a value called fpCode from the visitor’s browser storage, and when the value is set, the script puts the stored code in an invisible div and clicks it. The browser then runs the code as an event handler, without using eval().
Nothing in the block writes fpCode, so the script from deepveindrilling.com has to set it. A visitor who received the payload once runs it again on every later page view, even when the domain is offline or blocked. The March version deleted its stored payload after one run.
On October 23 the operator rewrote the blocks again, and the loader appeared on 9 more stores. All 71 stores Sansec re-crawled by October 24 run the new version. It replaces the plain script tag with an inline loader that sends a browser fingerprint to https://deepveindrilling.com/?s=49b7ca5f&fp=.
The fingerprint flags automated browsers through navigator.webdriver, Selenium globals and ChromeDriver’s cdc_ properties. It also adds the GPU name from WebGL, CPU cores, memory, screen size, time zone, languages and client hints. The server picks its response from all of that.
The filter works. When urlscan.io loaded an infected store with an automated Chrome browser, it got HTTP 200, and Sansec found no added content in the page. Sansec hasn’t captured the final payload yet.
Older payloads give a hint of what real visitors get. Sansec Watch, the firm’s monitoring service for content security policies, shows what the earlier stage served. On December 12, 2025, a customer logged in to an infected store got a script from manulfie.click that loaded https://crypto-insider.top/ssl/ and, five minutes later, https://leqdger.click/ssl/.
On December 15 and 16, neswnsssn.click inserted the same leqdger.click script on two more stores. leqdger.click is a misspelling of the crypto wallet brand Ledger. It was registered on September 12, 2025 and has since expired.
Before October, the second script was the “Script (async)” integration of Keitaro, a commercial ad tracker that doubles as a traffic distribution system, a tool that sorts visitors. It sends the referrer, page title and query string to a base64 encoded URL such as https://additionalver.com/Mb2z8J?&se_referrer=, where the path is the Keitaro campaign alias. The system then decides per visitor whether to return a payload, a redirect or nothing.
“When Sansec requested the additionalver.com script as a Windows desktop visitor on October 24, it returned QWE=123;, a statement that does nothing, and set a cookie that marks the visitor for 24 hours. deepveindrilling.com drops Keitaro and moves the bot filtering into the loader.” continues the report.
Here are the five loader domains over 15 months:
Domain
Registered
First seen on stores
Stores
manulfie.click
before July 2025, re-registered 2026-05-23
2025-07-09
863
neswnsssn.click
before December 2025, re-registered 2026-05-22
2025-12-12
494
lanhd6549tdhse.top
2026-03-25
2026-03-30
355
additionalver.com
2026-06-07
2026-06-08
246
deepveindrilling.com
2026-10-06
2026-10-07
83
Two other domains were found on a small number of stores: hdfdsi84j3h.top, registered three minutes after lanhd6549tdhse.top, and c85grt98sd.com.
Two older domains, neswnsssn.click and manulfie.click, expired and were registered again in May 2026. Both now use the nameservers of abovedomains.com, a domain parking service. Between August and October 2026, Sansec still found the manulfie.click loader on nine stores and the neswnsssn.click loader on six. When visitors open these stores, their browsers send information about the previous page and the current page title to the new domain owner. The browsers also run any script returned by that domain.
Sansec Watch received reports of visitors’ browsers connecting to all four earlier domains. One domain, additionalver.com, was linked to around 52,000 reports.
The October activity did not rely on a new vulnerability. Of the 83 affected stores, 60 had already been infected. Earlier attacks appear to have exploited file upload flaws in Magento. In March, the group injected its malicious code into 471 stores in just one hour by uploading webshells through PolyShell (CVE-2026-48356).
Some infected Magento stores had files uploaded through PolyShell or SessionReaper (CVE-2025-54236). In a separate group of 3,024 stores affected by another skimmer, the infection rate was 32%.
One Magento 2.4.7-p1 store contained PolyShell webshells disguised as PNG images, alongside malicious code in a CMS block. The code switched from additionalver.com to deepveindrilling.com on October 7. The store had not installed Adobe’s PolyShell fix, APSB26-73.
However, installing all patches does not guarantee a store is safe. Another store running Magento 2.4.7-p10 had no missing core patches but was infected on October 23. Earlier scans had already found a rogue admin account and a GSocket backdoor.
Sansec recommends checking CMS content for malicious code, including base64-encoded domains. Administrators should search both the cms_block and cms_page tables for suspicious patterns such as fpCode and se_referrer. They should also inspect uploaded files for webshells, check for unknown admin accounts, and look for suspicious processes. Removing the malicious scripts is not enough: store owners must also identify and fix the vulnerability or backdoor that allowed the attackers in.
After cleanup, change the database, admin and API integration passwords. Install APSB26-73 for PolyShell and APSB25-88 for SessionReaper. Sansec Shield blocks both attacks while you schedule the upgrade.
Sansec lists the indicators of compromise at the end of its report.
“If your store loads any domain from the indicators of compromise, the attacker can write to your database. Deleting the script does not remove that access. See How to check your store.” concludes the report.
Cyfirma links PHP2Shell scans of 216 vulnerable hosts to a suspected North Korean campaign using AI to rank public exploits.
On October 21, PHP released emergency patches for two critical vulnerabilities, CVE-2026-109618 and CVE-2026-109619, both rated 9.2 on the CVSS scale. The flaws affect all PHP versions that handle web requests. The vulnerable code dates back to PHP 5.4, released in 2012, and resides in the PHP engine itself rather than in individual applications. Attackers can exploit
Cyfirma links PHP2Shell scans of 216 vulnerable hosts to a suspected North Korean campaign using AI to rank public exploits.
On October 21, PHP released emergency patches for two critical vulnerabilities, CVE-2026-109618 and CVE-2026-109619, both rated 9.2 on the CVSS scale. The flaws affect all PHP versions that handle web requests. The vulnerable code dates back to PHP 5.4, released in 2012, and resides in the PHP engine itself rather than in individual applications. Attackers can exploit the flaws to execute code remotely by sending specially crafted HTTP requests, without authentication.
Exploitation attempts increased rapidly after the vulnerabilities became public. Cloudflare researchers reported tens of thousands of attempts within the first 45 minutes, hundreds of thousands in just two hours, and millions by October 22.
Cyfirma reported that a group of North Korea-linked group has identified 216 hosts that may still be vulnerable to PHP2Shell. The operators communicate through a private I2P channel that Cyfirma has monitored since October 22. On October 24, they reported that 216 hosts appeared to be unpatched or only partly protected, earlier than Cyfirma expected.
They are checking the systems from 21 compromised machines. At the time Cyfirma captured the conversation, the operators had already checked about one-third of the targets.
“Two handles active since March 2026, coordinating in a closed I2P channel; staging infrastructure shared in-channel.” states the cybersecurity firm. “Target set and scan nodes. “On 24 October the operators reported 216 unpatched or partially mitigated hosts and named 21 scan nodes; the same addresses were seen performing web-shell tooling and upload-progress session-poisoning attempts.”
The scanning is slow on purpose. Volume stays low, the machines rotate, and any node that shows filtering or rate limiting gets pulled and never reused. That’s why a rate-based alert will probably stay quiet.
Who’s behind it? Cyfirma assesses with moderate confidence a link to the Lazarus family of North Korean groups, based on language, operating style and old habits with PHP web shells and hijacked web servers. It has no shared malware or infrastructure to point to yet, and it admits that a Korean-speaking criminal crew without state backing would fit the same facts. Its confidence in the campaign itself is high.
Government agencies and banks come first. Next in line are logistics, ports, airports and aviation, manufacturing, and online transaction and trading platforms. The countries named are the US, Japan, South Korea, Thailand, Indonesia, Australia, Taiwan, India, Singapore, the UAE, Saudi Arabia and the EU.
Cyfirma has not named any victims or seen the full list of targeted systems. The operators have not announced when they plan to launch attacks, and the researchers have not confirmed that this group has compromised systems on a large scale. Cyfirma gives the campaign an imminence score of 78 out of 100. The operators plan to check all 216 hosts, select the most promising targets, and decide which publicly available exploits to adapt.
The group does not appear to be developing new exploits. Instead, its members use a local AI model to rank public exploit repositories, then test the results manually in a lab. Cyfirma believes this approach could help attackers turn newly disclosed vulnerabilities into working attacks more quickly. However, researchers warn that some proof-of-concept exploits shared online are fake and may contain malware, so downloading and running them can be dangerous.
Technical details leaked on October 20, ahead of coordinated disclosure, and the PHP project shipped fixes on October 21. Apache mod_php with default settings and prefork is the confirmed worst case for 109618, with full unauthenticated code execution. For 109619, PHP-FPM is validated through the upload-progress path.
One correction matters for your temporary controls. Early coverage tied the session upload-progress field to 109618, but PHP’s advisories put it under 109619 only. Disabling upload progress does nothing for 109618, so the two bugs need different stopgaps.
Triggering the bug is easy, but reliable code execution isn’t. The attacker has to land a follow-up request on the same worker and shape heap data into the freed space, otherwise the worker crashes or answers normally. VulnCheck reports working code execution on x86-64 with ASLR enabled against PHP 8.4.10 to 8.4.26, while ARM64 only leaks memory so far.
Short of code execution, attackers have already shown worker crashes, arbitrary file reads through OPcache and a leak of about 67 KB of process memory. The fixed releases are PHP 8.5.12, 8.4.27, 8.3.36 and 8.2.35. PHP 8.1, 8.0 and 7.4 get only minimal backports, and vendors such as cPanel EasyApache, CloudLinux, TuxCare and Plesk carry their own builds, so confirm coverage with yours.
Anything from PHP 5.4 to 7.3 has no fix, so migrate or isolate it. Restart every worker after patching, because a reload that keeps old workers alive leaves the stale state in place. Isolate anything internet-facing that you can’t patch within hours, starting with Apache mod_php.
If you suspect a host is compromised, capture memory and logs before you patch, since a restart destroys the CVE-2026-109619 state. Then rebuild the host from a trusted image and rotate every secret the PHP worker could reach. Hunt back to October 17, the earliest known exploitation, and use long time windows.
The strongest single signal is a PHP or web server process spawning something it never normally spawns. Application logs will usually show nothing, because the bug fires before application code runs. Look for odd multipart POSTs to endpoints that never take uploads, bursts of worker crashes and memory errors, new PHP files in web roots, and new cron jobs, local users or SSH keys.
Cyfirma includes Sigma, Splunk and YARA content, though it says the YARA set hasn’t been tested on real application code yet. It also lists 21 scan-node addresses, 17 source addresses from October 23 and 15 staging addresses, all defanged. Some scan nodes are described as compromised and may belong to victims, so hunt for prior contact before assuming who owns them.
If you can’t patch yet, the advisory suggests limits such as a low post_max_size and disabling session upload progress for 109619. Cyfirma is clear that none of it replaces patching. The operators’ own selection rule is the most useful detail in the whole advisory, because they dropped every host that showed a fixed version or sat behind heavy filtering. That makes a current version string a cheap filter against you, and for once being boring pays off.
“Hosts still bannering older PHP are the ones the operators kept.” Cyfirma states.
Pierluigi Paganini answers questions about the PHP2Shell vulnerability, early exploitation, AI-assisted attacks, and the risks to businesses, servers, and personal data.
1. Your latest report reveals that hackers began exploiting the PHP2Shell vulnerability four days before it was publicly disclosed. First, can you explain what PHP is, how widely it is used across the internet, and why this particular security flaw is so serious?
PHP is a programming language widely used to build websites
Pierluigi Paganini answers questions about the PHP2Shell vulnerability, early exploitation, AI-assisted attacks, and the risks to businesses, servers, and personal data.
1. Your latest report reveals that hackers began exploiting the PHP2Shell vulnerability four days before it was publicly disclosed. First, can you explain what PHP is, how widely it is used across the internet, and why this particular security flaw is so serious?
PHP is a programming language widely used to build websites and web applications. It powers a significant share of the web. PHP2Shell is serious because it can allow attackers to execute commands on a vulnerable server remotely. Depending on the configuration and the server’s privileges, this could give threat actors access to sensitive data, applications and other systems.
2. According to AWS researchers, attacks were already underway before the vulnerability became public. How did researchers uncover this early exploitation, and what does it tell us about the ability of hackers to identify security weaknesses before developers can fix them?
AWS researchers detected exploitation attempts against their honeypot network four days before public disclosure and the release of patches. This shows that attackers can discover or weaponize vulnerabilities before defenders have time to respond. AI-assisted analysis may accelerate this process, helping attackers turn technical information into working exploits in hours rather than days. However, detected attempts do not automatically mean successful compromises.
3. The vulnerability could potentially allow attackers to execute malicious commands on affected servers. What does that mean in practical terms, and what risks does it pose to websites, businesses and the personal information of their users?
Remote command execution means an attacker may be able to make a server run commands without authorization. Depending on the attacker’s access, they could steal data, install malware, change website content, or use the compromised server to attack other systems. Businesses could face service disruption, financial losses and reputational damage. Users may also be exposed if their personal information is stored on an affected system. The actual impact depends on the server’s configuration and security controls.
4. The latest findings raise concerns about the gap between discovering a vulnerability and protecting systems against it. How quickly can attackers exploit these weaknesses, and are businesses adequately prepared to respond when critical security flaws emerge?
The window can be extremely short. In some cases, attackers can develop or adapt an exploit within hours, leaving organizations little time to react. Many businesses still rely on patching schedules that are too slow for internet-facing systems. Organizations need continuous monitoring, rapid patching, tested incident response plans and clear visibility into exposed assets. They should also investigate suspicious activity dating back to before a vulnerability was publicly disclosed, because attacks may already be underway.
5. With PHP powering a significant portion of the internet, could we see further attacks exploiting this vulnerability? What should website operators do immediately to protect their systems, and should ordinary internet users be concerned about their data?
Further attacks are possible, particularly against systems that remain unpatched or exposed. Website operators should apply the relevant security updates, check whether their PHP applications are vulnerable, and review logs for suspicious activity dating back to October 17. They should also restrict access and investigate signs of compromise. Ordinary users do not need to panic, but they should keep their accounts protected with unique passwords and multi-factor authentication where available. Whether personal data is at risk depends on which services they use and whether those systems were compromised.
AI-assisted tools are increasingly being used to analyze code and identify vulnerabilities. How much of a role could artificial intelligence play in helping attackers discover and exploit flaws like PHP2Shell, and can defenders use the same technology to their advantage?
AI can help analyze code, identify suspicious patterns and speed up the process of turning a vulnerability into a working exploit. This lowers some of the technical barriers for attackers and may shorten the time between discovering a flaw and exploiting it. However, AI is not the only factor, and we should not assume that every attack is AI-driven. Defenders can use the same capabilities to review code, prioritize vulnerabilities, analyze logs and detect suspicious behavior. The real advantage comes from combining AI with reliable data, skilled security teams and effective response processes.
This case shows that attackers may exploit a vulnerability before a patch is available. Does this mean traditional vulnerability management is no longer enough, and how should organizations rethink their security strategy?
Traditional vulnerability management remains essential, but patching alone is not enough when attackers may act before a fix becomes available. Organizations need to know which internet-facing systems they operate, understand their exposure and have additional controls in place. These include limiting access to vulnerable services, monitoring suspicious activity, applying temporary mitigations and preparing incident response procedures. They should also investigate whether systems were targeted before the vulnerability was disclosed. The goal is to reduce the opportunity for exploitation and detect attacks quickly, even when a patch is not yet available.
Below is another interview I gave to TRT World discussing critical PHP vulnerabilities, the risks they pose to web servers, and the growing number of exploitation attempts. I explain why rapid patching and effective security measures are essential to minimize potential damage.
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-
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
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.
Attackers exploit Plex2Shell flaws to install crypto miners and proxy software. Admins should update their Plex Media Server.
Plex Media Server is designed to make movies, music, and other media available across devices. But when a server is exposed to the internet and runs vulnerable software, it can become an entry point for attackers who have little interest in your film collection.
On October 16, 2026, security researcher Zach Main published technical details and proof-of-concept (PoC
Attackers exploit Plex2Shell flaws to install crypto miners and proxy software. Admins should update their Plex Media Server.
Plex Media Server is designed to make movies, music, and other media available across devices. But when a server is exposed to the internet and runs vulnerable software, it can become an entry point for attackers who have little interest in your film collection.
On October 16, 2026, security researcher Zach Main published technical details and proof-of-concept (PoC) code for a vulnerability chain dubbed Plex2Shell. Within a day, researchers had observed attackers using the exploit against an internet-facing honeypot, deploying cryptocurrency-mining malware and proxy software. The incident is a reminder of how quickly a public exploit can be weaponized by threat actors.
The chain combines four vulnerabilities in Plex Media Server: CVE-2026-96652, CVE-2026-96654, CVE-2026-96655, and CVE-2026-96656. Together, they can allow attackers to execute arbitrary code on vulnerable servers without valid credentials, provided the required conditions are met. The code runs with the privileges of the Plex service, giving attackers an opportunity to install additional software and abuse the host.
The technical details are available in Main’s original analysis, Plex2Shell. Plex had been notified of the vulnerabilities on July 27 and acknowledged the report on August 4, awarding a bug bounty. The company released fixes in September, before the exploit code became public.
The loader does not check the library’s name, executable permissions, digital signature, or symbols. As a result, the library’s ELF constructor can run with the same privileges as the Plex service.
“It doesn’t check for a lib prefix, doesn’t require the execute bit, doesn’t verify any signature, and doesn’t look for any specific symbol.” reads the report published by zmain.com. “When dlopen loads a shared object, it runs the ELF’s DT_INIT_ARRAY (constructor functions) before doing any symbol resolution. A .so that only has a constructor and no exported symbols will still execute its code on load. We then trigger a second transcode. The codec directory gets re-enumerated, the .so we wrote in Stage 4 gets loaded, and the constructor runs as uid=1000(plex).”
That detail matters because the final stage can exploit how Plex loads shared libraries. The chain uses a setting related to transcoding to influence execution, allowing a specially crafted library to run when Plex loads it. The result can be code execution under the service account, without requiring the attacker to obtain an interactive login first.
The first confirmed activity appeared on October 17, when a researcher monitoring a vulnerable Plex honeypot reported seeing exploitation in the wild.
“My honeypot mostly saw scanning and generic exploitation attempts. As of this morning (Oct 17th), I finally saw in the wild exploitation.” reports the researcher on BoredHackerBlog. “So by default, I don’t allow outbound traffic from my honeypots but due to how this vuln works, I had to go modify my settings later on so sadly I didn’t get payloads for all the attacks. It’s possible that I have partial data. I haven’t gone through pcaps and I had to modify settings for tcpdump anyway. The attacker could be using slightly modified code & technique too.”
The attackers used the publicly available exploit to deploy an XMRig-based cryptocurrency miner. Later that day, the researcher found a second payload named myawesomeproxy, which turns the compromised system into a proxy node and may allow others to use its internet connection.
Cryptomining consumes computing resources and electricity, while proxy software creates a different risk. Attackers can route traffic through compromised residential or business connections, potentially using their reputation and IP addresses to reach services or networks that might otherwise block suspicious infrastructure. A Plex server can therefore become more than a source of unwanted costs: it can provide an attacker with a foothold for further activity.
Plex released patched versions in September, and administrators should ensure they’re running Plex Media Server 1.43.3.10861 or later. This includes installations running on NAS devices, virtual machines, and Docker containers. Updating the application is the immediate priority, particularly for servers exposed directly to the internet.
Administrators should also investigate unexpected child processes launched by Plex, unexplained CPU usage, unfamiliar files in the Plex Codecs directory, and outbound connections to unrecognized IP addresses. The appearance of cryptocurrency miners or proxy processes deserves particular attention. Because attackers can change filenames, infrastructure, and payloads, detection shouldn’t depend on a fixed list of indicators alone.
The honeypot findings provide evidence of exploitation, but they don’t establish how many real-world systems have been compromised or identify the operators with certainty. Organizations should treat the activity as a warning to check exposure and patch promptly, rather than assume that every vulnerable server has already been attacked.
“I wouldn’t be surprised if threat actors deploy more sophisticated things. Plex may be hosted on residential IP and I think threat actors would love to have residential IP proxy to access corporate VPNs and emails. (edit: see update at the bottom. i do see proxy being deployed now)” the researchers adds.
Entrar
