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)
U.S. Cybersecurity and Infrastructure Security Agency (CISA) adds Collabora Online flaw to its Known Exploited Vulnerabilities catalog. The U.S. Cybersecurity and Infrastructure Security Agency (CISA) added a Collabora Collabora Online – Built-in CODE Server flaw, tracked as CVE-2026-110447 (CVSS score of 9.2), to its Known Exploited Vulnerabilities (KEV) catalog. Collabora Online – Built-in CODE Server is an app for Nextcloud that lets you open, edit and collaborate on documents, spreadsheets and presentations directly in your browser, without needing Microsoft Office installed on your computer. It is based on Collabora Online and LibreOffice technology. CVE-2026-110447 is a critical OS command injection flaw in Nextcloud’s proxy.php that affects Collabora Online Built-in CODE Server before 26.4.303. Unauthenticated attackers can execute commands when the built-in server is stopped. Standalone Collabora servers are not affected. Update immediately. In versions up to 26.4.302, proxy.php included request data in a Bash command without proper sanitization, allowing attackers to execute OS commands as the web server user. Exploitation is possible only when the local CODE server is stopped, such as during a restart, upgrade or crash. The script runs directly through the web server without loading Nextcloud’s code. Exploitation has been reported since September 2026, with attackers deploying PHP web shells and stealing configuration files containing credentials and application secrets. Three administrators reported the vulnerability on GitHub, while the first recorded attack dates back to September 10. The first attack was reported by a Nextcloud administrator whose servers had been compromised. Logs showed malicious requests on September 10 and 11, 2026, from the same IP, targeting proxy.php on version 26.4.302. The attackers deployed a PHP web shell and searched one server for credential stores and cryptocurrency wallets. Although reviewed logs showed no file exfiltration commands, data accessible to the web server account must be considered potentially exposed. Two other administrators reported similar incidents, but none found evidence of root access. After updating to 26.4.303, one administrator recorded another attempt on September 14, but no new shell appeared. Project maintainer mmeeks urged users to update and remove leftover shx*.php files. The CVE record confirms exploitation in September and October 2026, but the total number of compromised servers remains unknown. The flaw affects only the Development Edition’s Built-in CODE Server deployment. According to Binding Operational Directive (BOD) 22-01: Reducing the Significant Risk of Known Exploited Vulnerabilities, FCEB agencies have to address the identified vulnerabilities by the due date to protect their networks against attacks exploiting the flaws in the catalog. Experts also recommend that private organizations review the Catalog and address the vulnerabilities in their infrastructure. CISA orders federal agencies to fix the flaw by October 26, 2026. Follow me on Twitter: @securityaffairs and Facebook and Mastodon Pierluigi Paganini (SecurityAffairs – hacking, CISA)
U.S. Cybersecurity and Infrastructure Security Agency (CISA) adds Arista VeloCloud Orchestrator flaw to its Known Exploited Vulnerabilities catalog. The U.S. Cybersecurity and Infrastructure Security Agency (CISA) added a critical Arista VeloCloud Orchestrator flaw, tracked as CVE-2026-114625 (CVSS score of 9.4), to its Known Exploited Vulnerabilities (KEV) catalog. VeloCloud Orchestrator (VCO) is the central management system for VMware SD-WAN, a technology that helps companies securely connect offices, data centers, cloud services, and remote sites over wide-area networks. It is now associated with Arista Networks, which acquired VMware’s SD-WAN business. The orchestrator gives network administrators a central place to configure, monitor, and manage the network. The flaw is a SQL Injection issue that affects on-premises VeloCloud Orchestrator (VCO). It allows an authenticated user to gain operator privileges and impersonate a local superuser operator account. This could give a remote attacker access to internal functions that should not be remotely available, potentially compromising the system and the data it manages. Hosted VCO versions, including Dedicated, were also affected but have already been patched. “VeloCloud Orchestrator (VCO) on-prem has a security issue where this issue may allow a remote attacker to access privileged internal functionality and impact the VCO host. Successful exploitation may compromise the confidentiality, integrity, and availability of the orchestrator and data managed by the orchestrator.” reads the advisory. “On an affected system, any authenticated user can gain operator privileges and masquerade as a local “superuser operator” user. This includes access to functionality that is intended for internal use only and which is not intended to be remotely accessible.” VeloCloud Orchestrator (VCO) is vulnerable by default. An attacker needs access to its web interface and a valid account. Even an account with the lowest permission level, Enterprise Read Only, is enough. No configuration change can prevent this exposure. Administrators should check web access logs for unusual requests, encoded text, attempts to access internal services, or an unusually high number of requests. They should also block these IP addresses linked to attacks: 74.82.197.86 38.54.50.151 If an attack is suspected, administrators should save web, application, system and database logs, along with relevant file timestamps, before starting recovery, if possible. According to Binding Operational Directive (BOD) 22-01: Reducing the Significant Risk of Known Exploited Vulnerabilities, FCEB agencies have to address the identified vulnerabilities by the due date to protect their networks against attacks exploiting the flaws in the catalog. Experts also recommend that private organizations review the Catalog and address the vulnerabilities in their infrastructure. CISA orders federal agencies to fix the flaw by October 26, 2026. Follow me on Twitter: @securityaffairs and Facebook and Mastodon Pierluigi Paganini (SecurityAffairs – hacking, CISA)
PHP warns of a new, unlikely code execution flaw, CVE-2026-115560, and advises disabling session upload progress until a fix is released. PHP has warned of a new code execution vulnerability, tracked as CVE-2026-115560, just two days after releasing emergency patches for the critical PHP2Shell flaws. The vulnerability affects only a specific PHP configuration that PHP says is unlikely to be used in practice. An application must meet several conditions: it must configure session.serialize_handler as php_binary or php_serialize, change it to php at runtime using ini_set(), and make this change before calling session_start(). Session upload progress must also remain enabled. In an advisory published on October 23, the project recommended disabling session upload progress until a fix becomes available in a regular release. The vulnerability is separate from PHP2Shell and is not fixed by the October 21 updates for PHP versions 8.2.35, 8.3.36, 8.4.27 and 8.5.12. “The issue can only occur under an unusual combination of configuration and application code. An application must set session.serialize_handler to php_binary or php_serialize in its configuration and then switch it to php at runtime with ini_set() before calling session_start(). Session upload progress must also still be enabled.” reads the advisory. “Applications that never change the serialize handler at runtime can keep the feature enabled. Since this setup is unlikely in practice, we are handling it in the regular release cycle and will publish a full advisory for CVE-2026-115560 with the next release.” Applications that do not change the serialization handler while running are not exposed through this attack path, even if session upload progress is enabled. PHP recommends a simple temporary fix: set session.upload_progress.enabled=0 until the next routine bugfix release. This is the same mitigation already recommended in the October 21 advisory for CVE-2026-109619. Administrators who applied this setting and have kept it in place do not need to take further action for this issue. Session upload progress is enabled by default and allows applications to track the progress of file uploads. Disabling it reduces exposure to this specific vulnerability path. PHP will fix CVE-2026-115560 through its regular release cycle because the vulnerable setup is uncommon. It plans to publish a full advisory with the next release. PHP has not yet identified affected versions, confirmed when the fix will arrive, assigned a severity score, or explained whether the flaw shares a root cause with CVE-2026-109619. No attacks targeting this new issue have been reported. On October 21, PHP released emergency patches for two critical vulnerabilities tracked as CVE-2026-109618 and CVE-2026-109619 (CVSS score of 9.2), affecting every PHP version that handles web requests. The bug code dates back to PHP 5.4 from 2012, lives in the PHP engine itself rather than in any application, and allows unauthenticated remote code execution via crafted HTTP requests. Cloudflare researchers observed tens of thousands of exploit attempts within 45 minutes of public disclosure, hundreds of thousands within two hours, and millions by October 22. Follow me on Twitter: @securityaffairs and Facebook and Mastodon Pierluigi Paganini (SecurityAffairs – hacking, PHP)
The PHP security team has shared mitigation measures for a new remote code execution vulnerability that affects systems with non-default configurations and has no patch. PHP is an open-source web development language used by nearly 70% of all websites on the Internet. According to VirusTotal estimates, more than 5.1 million PHP hosts are exposed online, and roughly 3.8 million have at least one port open to attacks. According to a Friday advisory, this security flaw (tracked as CVE-2026-115560) can only be exploited when targeting systems "with an unusual combination of configuration and application code." "An application must set session.serialize_handler to php_binary or php_serialize in its configuration and then switch it to php at runtime with ini_set() before calling session_start(). Session upload progress must also still be enabled," the PHP team explained.
PHP has warned of another way an attacker could run code on a web server, two days after it shipped emergency fixes for the critical PHP2Shell flaws. The new issue, assigned CVE-2026-115560, affects only web applications configured in an unusual way, and PHP considers it an unlikely risk.The project is not issuing an emergency fix for it. Instead, it recommends turning off a feature called
Attackers are exploiting a zero-day SQL injection flaw in Arista's VeloCloud Orchestrator (VCO), the central management system for VeloCloud SD-WAN networks, the company said in an advisory on October 22. The flaw lets anyone who can log in to the orchestrator, even with a read-only customer account, gain operator privileges, the top level of control over it. For
A critical Signal flaw could keep calls active after hang-up, exposing microphone or camera. Update to a fixed version immediately. A critical vulnerability, tracked as CVE-2026-113380 (CVSS score 9.3 of 10), in Signal ’s calling library could allow a malicious caller to interfere with call termination, potentially leaving the victim’s microphone and camera active after they believe the conversation has ended. The flaw affects versions before 2.72.0 of the library RingRTC, which the messaging app uses to provide voice and video calling. It highlights a security problem that deserves attention beyond a single messaging application: ending a call should be an immediate control action, not something that can be delayed by traffic coming from the other participant. According to the technical report published on GitHub, the vulnerability stems from how RingRTC handles events in the finite-state machine (FSM) that manages a call. The application places events in a queue for processing, but a malicious peer can flood that queue with events and prevent the local hang-up operation from being handled in a timely manner. “A local hang-up is not a kill switch: it is just one more event placed at the back of the call’s finite-state-machine event queue. The remote peer is trusted with that queue — there is no rate limit on peer-originated events and no priority lane for hang-up.” reads the technical report published on GitHub, “Flood the queue with junk and the hang-up waits behind attacker noise forever, so the call (microphone, possibly camera) is never torn down.” People expect that pressing the hang-up button ends the call and turns off the microphone and camera. But if the system is too busy processing other events, it may delay the command to end the call, leaving the audio or video active longer than expected. The report explains that someone taking part in a call could exploit this weakness by sending enough events to overload the system’s queue. This could stop the other person from ending the call properly, potentially keeping the microphone active and possibly the camera too. The underlying problem is not that Signal’s end-to-end encryption has been broken. Rather, it concerns the handling of call state and the reliable termination of a session. Encryption cannot protect users from every flaw in the software that controls when a communication session begins or ends. The vulnerability concerns RingRTC versions earlier than 2.72.0 and can affect Signal clients that embed a vulnerable build of the library. According to the CSIRT Toscana advisory, the affected application versions are Signal for Android before 8.27.0, Signal for iOS before 8.30.0, and Signal Desktop before 8.29.0. The official RingRTC fix and the comparison between versions 2.71.0 and 2.72.0 document the software changes. Users should install the latest available Signal release for their device rather than relying on the library version alone. The technical report also includes a conceptual Python proof of concept. It models the difference between a queue in which a flood can bury a hang-up event and one in which critical events receive priority. The demonstration is synthetic and offline, with no network activity or real calls, so it illustrates the underlying logic rather than providing a working exploit. This is an important distinction. The fact that the vulnerability has been made public does not mean attackers are already exploiting it. However, because it could expose private conversations, updating Signal promptly is a sensible precaution, especially for people who use it to discuss sensitive matters. Follow me on Twitter: @securityaffairs and Facebook and Mastodon Pierluigi Paganini (SecurityAffairs – hacking, mobile)
This week has already been rough for cybersecurity. Critical PHP and GitLab RCE flaws, serious Linux security bugs, compromised eMudhra certificates, a Node.js RCE flaw, a hacked LiteLLM release, and hundreds of hijacked Tor relays. That's a lot to deal with in just a few days. And the week isn't even over yet. But those big headlines are only half the story. Stolen passwords, exposed
Arista Networks released security updates to patch an actively exploited zero-day vulnerability affecting VeloCloud Orchestrator (VCO) On-Prem deployments. VCO is a web-based management portal that helps administrators configure, monitor, and manage VeloCloud SD-WANs (Software-Defined Wide Area Networks) and associated edge devices. Tracked as CVE-2026-114625, this critical-severity flaw can allow attackers with basic privileges, access to the VCO web interface, and a valid authenticated session to escalate privileges through low-complexity SQL injection attacks that don't require user interaction. "VeloCloud Orchestrator (VCO) on-prem has a security issue where this issue may allow a remote attacker to access privileged internal functionality and impact the VCO host. Successful exploitation may compromise the confidentiality, integrity, and availability of the orchestrator and data managed by the orchestrator," Arista said.
Confirm this action.
Leaving now will discard your changes.