The U.S. Cybersecurity and Infrastructure Security Agency (CISA) has added two critical PHP vulnerabilities collectively tracked as PHP2Shell to its catalog of actively exploited security flaws. Threat actors without privileges can exploit the two security issues (CVE-2026-109618 and CVE-2026-109619) in high-complexity attacks to gain remote code execution (RCE) on unpatched systems. The PHP security team patched the two flaws on Wednesday, October 21, one day after urging security teams to install the security updates as soon as they became available. Although details on the PHP2Shell security flaws (including the CVE IDs and mitigation measures shared with critical infrastructure providers) leaked and some proof-of-concept (PoC) exploits were published online before patches went live, the PHP security team said that none were functional.
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: DomainRegisteredFirst seen on storesStoresmanulfie.clickbefore July 2025, re-registered 2026-05-232025-07-09863neswnsssn.clickbefore December 2025, re-registered 2026-05-222025-12-12494lanhd6549tdhse.top2026-03-252026-03-30355additionalver.com2026-06-072026-06-08246deepveindrilling.com2026-10-062026-10-0783 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. Follow me on Twitter: @securityaffairs and Facebook and Mastodon Pierluigi Paganini (SecurityAffairs – hacking, Magento)
DreamHost has forced password resets for email and FTP/SFTP users following an incident that disrupted connections to the File Manager interface. The latest update from the web hosting provider notes that all affected account owners have received recovery instructions. Users will be unable to log in until their account owner sets new credentials. DreamHost is a U.S. web hosting provider and domain registrar that offers WordPress hosting, business email, virtual private servers, dedicated servers, and cloud services. According to the company page, it serves over 400,000 customers in more than 100 countries and supports at least 1.5 million websites and applications, including 750,000 WordPress installations. DreamHost initially reported connectivity problems affecting its File Manager interface on October 23, but the impact quickly expanded to other services.
Author: Len Noe, Solutions Architect, BeyondTrust The first question on any incident bridge isn’t about why it happened--it’s whose credentials were used. In my experience, whoever can answer that credential question in the first hour sets the pace for everything after it: what to isolate, what to revoke, whom to notify, and how far the damage could have spread. The teams that can’t answer it spend the first day reconstructing their answer from logs that were never designed to provide it. That discipline is about to be tested by a new kind of actor. On October 16, 2026, the National Institute of Standards and Technology (NIST), the Cybersecurity and Infrastructure Security Agency (CISA), and the National Security Agency (NSA) jointly published ten voluntary practices for incident readiness and response when AI agents act in ways nobody directed.
uCreater is Android spyware disguised as trusted apps, stealing credentials, messages and wallet data through a rentable platform. uCreater is a rentable Android spyware platform that hides inside repackaged legitimate apps, targeting messaging services and mobile wallets. Its YingGai framework can intercept one-time passwords, steal account and chat data, collect contacts, manipulate sessions and spoof camera feeds to bypass identity checks. Victims may install modified versions of Telegram, WeChat or GCash through sideloading or social engineering. Researcher Ovi found stolen data on a control server, but the number of victims and links between operators and customers remain unconfirmed. “The repackaged APK can be relatively thin: target-specific instrumentation is retrieved after installation from the operator’s Alibaba OSS and MinIO infrastructure, including buckets and paths named Huuk_<target> and fengzhuang-app (literally, “packaging”). Distribution hosts include telegram-apk.uzyzx.com.” researcher Ovi states. “I could reconstruct much of the post-installation execution chain from the recovered code, but I could not directly establish the initial delivery mechanism for every victim.” Ovi rebuilt most of the chain from recovered code but couldn’t establish how every victim got the first install. The product is older than the samples. The package com.ucreater.autotool dates to about 2014, Windows tools tied to ucreater.com were signed between 2016 and 2019, and the YingGai mobile line shows up in records from September 2021. The samples Ovi studied run from 2024 to 2026: uip.exe builds from February to December 2024, Telegram repacks from July and November 2024, the WeChat host and Telegram framework from December 2024, and the Onion Box client from March 2026. The control server’s ICP filing, 湘ICP备2024061212号, dates to 2024. The infrastructure hints at scale, though not at victim numbers. Ovi counts about 20 target apps with confirmed code support, six operator domains with dozens of subdomains, three Redis buses, two MQTT buses, and a cloud-phone cluster in Changsha spread across several ISPs. A Censys search for the operator’s Tengine gateway fingerprint returned roughly 48 hosts. It looks like a multi-year product sold to many downstream operators, but he can’t say how many customers used it or how many devices fell. Attributing the platform to a specific legal entity is more difficult. Hunan Youchuang Technology is linked to the ucreater.com brand and a self-signed certificate on videoflow.cn. Changsha Sukai Network holds the ICP filing for the control server’s main domain, qianxuncc.cn, while Changsha Zhuoqing E-commerce appears as the signing identity on uip.exe, using a DigiCert certificate. A common owner is plausible but unproven. Another lead involves hunanzhijing.com, a domain belonging to the Hunan Intelligent Police Public Safety Technology Research Institute. It shares the same gateway fingerprint, and an official Hunan document connects the institute to an intelligent-policing research project. However, shared cloud infrastructure establishes only co-tenancy, not ownership or operational involvement. There is no evidence that the police developed or operated uCreater. Other infrastructure links also require caution. A Thailand-based relay used by the Telegram component, hosted on Huawei Cloud, also served gambling websites, an advertising-account service and an SMS service. The cloud-phone web client displayed a certificate for another vendor, while the gateway served a Vue application titled 舆情交易, meaning “public-opinion trading”. These observations are leads for further investigation, not proof of common ownership. uCreater relies on app virtualization, a technique already identified by Zimperium as a growing mobile threat. VirtualApp runs another application inside a container, LSPatch merges code hooks into repackaged apps without requiring root access, and Pine hooks Android’s runtime. Together, these components allow malicious code to operate inside a legitimate app while it is signed in and has access to decrypted data. “uCreater is notable because it turns these techniques into a reusable, remotely managed product.” the researchers continues. Operators distribute modified versions of Telegram-X, Telegram-Web and other messaging apps, integrating modules through LSPatch or loading them from an asset called TgJarPine.dex. WeChat can instead run inside a VirtualApp container, including the va_vx or Onion Box host. LSPatch also stores the original APK under cache/lspatch/origin/*.apk. The presence of this path or the specific asset can help identify an infected device. The approach differs from GodFather, a banking trojan documented by Zimperium that runs apps in a virtual container and displays fake overlays to capture credentials. uCreater operates inside the real application without relying on an overlay. It uses XposedBridge hooks, reflection and access to the app’s own database interfaces. This allows it to reach beyond login screens and potentially support any application for which the vendor develops a module. Ovi found no evidence linking the two platforms. One distinguishing feature is a local command server embedded in each hooked application. It exposes around 40 numbered handlers, with descriptions and parameters that allow operators to discover available functions. The code supports device monitoring, contact and SMS collection, installed-app enumeration, message sending, chat-history retrieval, session management and account-related actions. The Telegram module can execute SQL queries directly against the application’s live database through its own interface. Its Db_MessagesStorageRawQuery handler accepts operator-supplied SQL and returns results through compatibility classes that recreate Telegram objects. This can expose information that would otherwise be protected in the app’s encrypted or locally stored data while the application is running. The module also hooks Telegram’s SRPHelper.getX routine, capturing the two-step verification password in cleartext before hashing and storing it for exfiltration. The code provides functions to list or reset sessions, change or confirm a linked phone number, delete an account and lock users out. It can also remove its own session from the victim’s device list, potentially concealing the operator’s access. Ovi stresses that the source code demonstrates these capabilities, not that every action has been successfully performed against victims. The implant retrieves its control-server address from Redis using the Domain key, optionally selecting a value for a particular channel. It caches the address and can fall back to a hardcoded value, explaining why callback domains differ between builds. Signed JSON beacons report to endpoints under /api/callback/Tg*, while command requests include a device fingerprint and signature and use retries with increasing delays. Updates and additional code arrive through Alibaba Object Storage Service (OSS) and MinIO. The Telegram module retrieves an update manifest and hooks from designated storage paths, while a contacts.vcf file can supply contact information. The WeChat component subscribes to a Redis channel identified by a device-specific machine ID, with its host and credentials embedded in a child code file. The WeChat module focuses on account access rather than chat-history collection. Its _2_0_UploadAppLoginInfo command retrieves login identity information, after which the app data can be packaged, uploaded to OSS and used in account cloning. Ovi found no evidence that the examined sample accessed WeChat’s encrypted database. Ovi tested uCreater on a Pixel 10 Pro running Android 17 and found that its bundled Pine engine fails because of changes to Android’s internal APIs. The latest sample, dated July 29, 2026, still uses the outdated engine. Although this creates obstacles for operators, updating Pine could restore functionality, and other devices remain untested. Ovi also identified five samples that successfully contacted the control server, confirming active deployments targeting Telegram, Telegram-X and WeChat. Ovi and researcher Jurre discovered the platform’s source code after finding an exposed GitLab server. Other infrastructure was protected by IP allowlists, but this server contained the control platform’s source code, configuration and operational details. The repositories revealed Spring Cloud services for command dispatch, authorization capture, data collection, backups and message bridging, alongside a Vue-based administration console. Thirteen repositories contained commit histories identifying roughly three dozen developers, with activity timestamps consistent with China time. At least one commit used a corporate email domain associated with Tanzhou, a Changsha software firm. uCreater’s backend is a rented, multi-tenant platform that lets operators manage infected devices, steal account data and automate contact collection. Kafka, RocketMQ, Redis and Nacos coordinate commands and schedule activity to avoid triggering security controls. The infrastructure runs on Aliyun and Huawei Cloud, with control services and storage hosted in China. Although GitLab records identify developers behind key components, Ovi stresses they are not confirmed operators. The recovered backend did not appear to support Telegram, and some callback domains are no longer active. Ovi attributes the platform to a vendor in Changsha and Hunan operating through three companies, each linked to a different technical or infrastructure artifact. The reseller model, focus on mobile wallets and theft of authentication codes suggest financially motivated crime, but the researcher presents this as an assessment rather than a proven fact. The technical findings show that uCreater goes beyond a conventional banking trojan or a tool that merely steals credentials. By embedding code inside legitimate applications, it can manipulate sessions, access account data, collect contacts and potentially take control of messaging accounts. Its rented, multi-tenant architecture also allows different operators to use the same underlying platform. The scale of the infrastructure indicates a substantial operation, but neither the number of customers nor the number of compromised devices has been established. Likewise, infrastructure overlaps and developer records provide investigative leads, not conclusive proof of who operated the spyware or who was responsible for individual attacks. “Mapping points to a commercial resale structure, and targeting driven by wallets and OTPs. My assumption is financially-motivated crimeware.” concludes the report. Follow me on Twitter: @securityaffairs and Facebook and Mastodon Pierluigi Paganini (SecurityAffairs – hacking, newsletter)
Official websites use .gov A .gov website belongs to an official government organization in the United States. Secure .gov websites use HTTPS A lock (LockA locked padlock) or https:// means you’ve safely connected to the .gov website. Share sensitive information only on official, secure websites. Share: Opens in a new window Opens in a new window Opens in a new window Press Release CISA Unveils New Strategy to Strengthen National Cyber Defense and Critical Infrastructure Security CISA 2030: Defend, Harden, Prevail Released October 26, 2026 Related topics: Cybersecurity Best Practices , Critical Infrastructure Security and Resilience WASHINGTON – The Cybersecurity and Infrastructure Security Agency (CISA) today released its new strategy, CISA 2030: Defend, Harden, Prevail, which advances President Trump’s Cyber Strategy for America and National Resilience Strategy while strengthening the security and resilience of the nation’s critical infrastructure.
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. Follow me on Twitter: @securityaffairs and Facebook and Mastodon Pierluigi Paganini (SecurityAffairs – hacking, PHP2Shell)
Two critical RCE vulnerabilities (CVE-2026-109618 and CVE-2026-109619), collectively tracked as PHP2Shell, have been successfully exploited in the wild. The malicious activity was caught by Adel Karimi, detection and response lead at Perplexity, whose honeypots recorded evidence of confirmed remote code execution against an Apache mod_php installation running PHP 8.4.26. "This is now confirmed RCE with usable memory disclosure, not just a crash followed by a suspicious process. The response delivered an 800 KiB decoded cookie dump, and a function address derived from that dump using the public exploit's offsets appears in the subsequent execution payload," Karimi shared. "The client acknowledged the full response; the shell command then ran about 1.6 ms after the execution request's final captured byte."
Researchers found a malicious AGENTS markdown instruction file in a customer’s Downloads folder that tricked an AI coding agent into installing a rogue npm package. They reproduced the attack against OpenAI Codex and demonstrated a related technique against Claude Code to leak OAuth tokens and hijack the account using only the malicious instructions. Markdown files such as AGENTS.md are plain-text files that contain project-specific instructions for AI coding agents, such as the tools to use, how to run tests, and the coding conventions to follow. Researchers at Forever Security, a company that monitors for risks introduced by AI agents and autonomous software, discovered the tactic on a customer’s computer, where a coding agent attempted to install the malicious npm package ‘function-color.’
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. Follow me on Twitter: @securityaffairs and Facebook and Mastodon Pierluigi Paganini (SecurityAffairs – hacking, newsletter)
Confirm this action.
Leaving now will discard your changes.