php

PHP脆弱性でいち早くサービス停止、コドモン経営判断の舞台裏 実はオンラインイベントの真っ最中だった（1/4 ページ） 多くの情報セキュリティ担当者が対応に追われ、今なお爪痕が残るプログラミング言語「PHP」の脆弱性。さまざまなサービスが緊急メンテナンスを実施し、セキュリティアップデートを実施するに至ったが、その中でもいち早くサービス停止を判断し、注目を浴びた企業がある。保育施設や保護者向けSaaSを手掛けるコドモンだ。 同社は10月21日の午後2時過ぎ、他社に先駆け予防的なサービス停止を告知。保護者アプリを含む全サービスを順次停止した。実は当時、同社は保育関係者向けのオンラインイベントを開催している真っ最中でもあり、停止の判断は生半可なものではなかったという。果たして当時の心境は如何に。小池義則代表取締役に話を聞いた。 夜間停止のはずが一転……正午すぎに「日中停止」へ まず、コドモンがPHPの脆弱性にどのように対応したか、同社がテックブログに掲載しているタイムラインを基に、おおまかな流れを整理しておこう。 PHPの開発チームは10月21日午前4時33分（日本時間）、重大な脆弱性2件の存在と、同日午後11時に修正版を公開する予定を発表した。通称「PHP2Shell」と呼ばれるこの脆弱性の深刻度は10点満点中9.2で、最も重い「Critical」（緊急）に分類されていた。 コドモンが社内で把握したのは午前9時1分。当初は修正版の公開を待ってPHPを更新する方針だったが、公開前から脆弱性に関する情報が海外の掲示板などで広まっていたことから、午前11時37分には「修正版の公開に合わせ、事前に告知したうえで、公式サイトとヘルプページなどを除くほぼ全サービスを夜間に止める」方針が固まった。 状況が変わったのは正午すぎだ。原因箇所と修正方法とされる情報がSNSやエンジニアコミュニティーで広まり、修正版の公開を待たずに攻撃が成り立つリスクが出てきた。設定変更などで影響を抑える方法も検討したが、非公式に出回る対策が自社の環境で有効かを短時間で確かめるのは難しかった。 そこで午後0時37分、日中の緊急停止を決定。一部のサービスだけを止める、お迎えの時間まで動かし続ける、監視を強めて攻撃を検知した時点で止める──といった案も検討したが、いずれも十分にリスクを下げられないとして採らなかったという。 サービスは午後1時ごろから順次停止し、保護者向けサービスは午後1時46分、保育施設などの職員用管理画面は午後2時2分に止まった。最後のサービスが止まったのは午後2時49分。並行して午後2時ごろに、状況を公表する第1報を出した。 午後3時ごろには第2報を出し、復旧見込みを「未定」から「翌朝」に改めた。見通しのない状態が続けば利用者の不安が大きくなるとの考えからだ。具体的な目標は、施設での利用がピークを迎える午前7時より前、遅くとも午前6時の再開。当初は2時間ほどで作業を終えられると見込んでいた。 ところが、夕方になって計画の前提が揺らぐ。修正版が公開されても、各システムが利用する配布元からパッケージ（実行可能なファイル）が届くまでには、過去の例で数時間から数日の開きがあった。5時間以上かかれば翌朝の再開には間に合わない。 そこで同社は午後5時半ごろから、配布元を待つだけでなく、必要な情報が公開され次第、自分たちで完成品を組み立てる“自前ビルド”も並行して準備することにした。当初の計画にはなかった取り組みだが「待つだけになるのは避けたい」と考えた一部のエンジニアが自ら調べ始めたのがきっかけだったという。 夜間の作業は13人が担当した。午後10時38分に修正版と脆弱性の詳細が公開されたものの、やはり配布元のパッケージが届くまでには時間差があった。同社は主要サービスを自前ビルドで、外部連携用のサーバは配布元のパッケージで動かすことにし、22日午前3時22分、職員用管理画面などを再開。目標とした午前6時の約2時間半前で、脆弱性の把握からはおよそ18時間後のことだった。 その後、朝の利用ピークも大きな問題なく乗り切り、一部の機能を除く他のサービスも22日中に順次再開。同社によれば、本件に起因する不正アクセスや情報漏えいは確認していないという。その他、プロダクト開発部門から見た当時の状況は同社のテックブログも参照のこと。 Copyright © ITmedia, Inc. All Rights Reserved. 本記事は制作段階でChatGPT等の生成系AIサービスを利用していますが、文責は編集部に帰属します。

PHPの重大な脆弱性を巡り、多くの企業が緊急対応に追われました。一方、普段のパッチ適用やバージョンアップは、負担の大きさから先送りされがちです。「必要になったら更新する」という判断の裏に、「更新できない」問題が隠れていないでしょうか。IT部門が確かめるべき条件を考えます。

One cyber firm listed a half-dozen exploitations of the PHP2Shell bugs, and another identified a well targeted, suspected Chinese campaign that breached U.S. "government affiliated" servers.

Suspected Chinese attackers chained PHP2Shell with a Linux kernel privilege-escalation exploit to root 25 servers, including Palo Alto Networks firewalls linked to US government-affiliated organizations, according to Dream researchers. The snoops began exploiting these servers on October 23, targeting organizations across the US, Japan, Taiwan, and South Korea. The attackers also honed in on US government-affiliated firewalls. “Within hours of compromising a US government-affiliated firewall, they had tunneled into the internal network, compromised a third server using the same PHP2Shell exploit, and launched a full Active Directory attack campaign - all through a chain that started with a single unauthenticated HTTPS request to a management interface that should never have been exposed to the internet,” the Israeli AI cybersecurity startup said in a report. Plus, the attackers “likely still” have persistent, remote access to compromised organizations’ networks, Dream noted. The attackers rooted the first US government-affiliated firewall on October 23, but the device crashed shortly afterward, possibly due to around 900 MB of exploit traffic. According to Dream, it remained unresponsive despite 240 automated checks over two hours. They successfully exploited the second firewall a day later, on October 24. The compromised firewalls ran vulnerable versions of Palo Alto Networks' PAN-OS. Dream said it had been working with the vendor to investigate the compromises, and Palo Alto Networks' Unit 42 researchers independently verified the attacker's tooling and confirmed Dream's reported results. To break into the firewalls, the attackers built a custom exploit chain that includes PHP2Shell and a Fragnesia kernel flaw, and ran about 40 custom post-exploitation scripts once they were inside the targeted organizations. Total attack chain in under 15 minutes PHP2Shell, comprised of CVE-2026-109618 and CVE-2026-109619, came to light early last week, along with fears that attackers would abuse the bugs to take down most of the internet. Despite “hundreds” of PHP2Shell proof-of-concept repositories on GitHub, the first reports of successful attacks didn’t start until Saturday. Both bugs have CVSS scores of 9.2 and can be exploited without authentication to run code on vulnerable PHP servers. The PHP2Shell exploit recovered by Dream was not a copy of any known public exploit. It “appears to have been independently developed and tailored specifically for the targeted firewall platform,” the researchers wrote. The attackers combined PHP2Shell with Fragnesia (CVE-2026-46300), a high-severity local privilege-escalation vulnerability affecting the Linux kernel's XFRM ESP-in-TCP subsystem. The US Cybersecurity and Infrastructure Security Agency (CISA) added this Linux kernel bug to its catalog of Known Exploited Vulnerabilities on Wednesday. Both CISA and the FBI declined to comment. The miscreants developed a four-stage PHP2Shell exploit that allowed them to execute commands without authentication on vulnerable Palo Alto Networks firewalls. They then used Fragnesia to escalate their privileges and gain root access. The attackers targeted PAN-OS 12.1 and 12.2, which run PHP 8.0.30 with a high memory limit that enabled the exploit's memory-corruption stages. “The total chain - from unauthenticated HTTPS connection to persistent root webshell - completes in under 15 minutes,” the Dream team wrote. 4 steps to root Here’s how it works: First, they flood the servers with crafted multipart POST requests to corrupt PHP’s memory, and force a predictable memory layout. Then a second request forges the stale session ID length from the memory corruption part of the attack, forcing an out-of-bounds read and exposing the base address of libphp.so in the running process. The attackers then exhaust PHP's memory again to force mod_data=NULL, creating a stale reference they can forge in the final stage to execute commands as the nobody user. They use Fragnesia to escalate to root and plant a web shell in a publicly accessible directory on the firewall. After breaking in via the compromised firewalls, the attackers snooped around in Active Directory, stealing credentials and other sensitive information. With root access, the attackers also had the master key to decrypt the LDAP service account password, which they hardcoded into every subsequent script. They also enumerated every user and group in the domain via LDAP queries, and sprayed passwords against every user account. Attackers also tried to create backdoor AD accounts and attempted SAML signing key extraction - but Dream doesn’t know if these were successful. “The attack results - whether the password spray found valid credentials, whether the backdoor accounts were created, whether SAML keys were extracted - stayed on the management server's local filesystem and were not among the artifacts we recovered,” the researchers noted. AI tools in the attack The investigation also uncovered evidence that the attackers used AI tools, but noted that this was not a fully autonomous attack. The researchers found Anthropic's Claude Code installed, an AI-powered offensive security platform called aiscan configured with Chinese models DeepSeek and Kimi, and API keys for the FOFA reconnaissance service. FOFA is a Chinese internet asset search engine similar to Shodan. The attackers used it to identify about 19,000 internet-facing Palo Alto Networks firewalls worldwide. “The persistent tunnel into the US government organization is likely still running,” Dream warned. “And the attacker still has 19,000 fingerprinted targets they can revisit as they develop profiles for additional PAN-OS versions.”®

CVE-2026-109618 and CVE-2026-109619 are Critical vulnerabilities in PHP, a scripting language used globally for web servers and CMS systems. The post Threat Brief: Critical Vulnerabilities in PHP: CVE-2026-109618, CVE-2026-109619 (Updated October 29) appeared first on Unit 42 .

China-nexus threat actors have exploited a VMware ESX zero-day to hide their tracks and chained PHP2Shell flaws with the “Fragnesia” Linux kernel bug to root servers and firewalls, cybersecurity researchers claim. Cisco has also confirmed that attackers are crashing its firewalls with a newly disclosed vulnerability. VMware ESX zero-day helped Chinese spies cover their tracks Chinese APT group Warp Panda has leveraged an insufficient logging vulnerability (CVE-2026-41709) in Broadcom’s VMware ESX bare-metal hypervisor as a … More → The post Chinese hackers used VMware ESX zero-day; PHP2Shell and Fragnesia chained to root firewalls appeared first on Help Net Security .

Dos vulnerabilidades críticas de PHP afectan a servidores web 29/10/2026 Jue, 29/10/2026 - 15:47 Los primeros indicios del problema de memoria se identificaron durante una auditoría de PHP en 2024, pero las vías concretas de ejecución remota de código no se confirmaron hasta agosto de 2026, cuando varios equipos las comunicaron al proyecto. El primer intento de explotación registrado por telemetría se remonta al 17 de octubre, cuatro días antes de la divulgación pública y de las correcciones. El 20 de octubre, la difusión anticipada de los identificadores llevó al proyecto a adelantar un día la publicación. Las vulnerabilidades CVE-2026-109618 y CVE-2026-109619, con una valoración CVSS de 9,2, afectan al tratamiento de la memoria y del estado interno entre solicitudes, y pueden permitir que un atacante no autenticado ejecute código con los privilegios del servidor web . El riesgo alcanza a las instalaciones de PHP que procesan solicitudes web , incluidas PHP-FPM, Apache con mod_php , php-cgi, FrankenPHP y LiteSpeed. El proyecto publicó PHP 8.5.12, 8.4.27, 8.3.36 y 8.2.35, facilitó correcciones de código para algunas ramas antiguas y señaló que las mitigaciones temporales no sustituyen la actualización. El último estado oficial indica que ambas vulnerabilidades fueron incorporadas al catálogo de vulnerabilidades explotadas conocidas de CISA el 26 de octubre. Las versiones corregidas continúan siendo la medida principal, mientras que los sistemas que no puedan actualizarse deben aislarse de redes públicas hasta aplicar y verificar la solución. Referencias 20/10/2026 BleepingComputer PHP warns admins of two critical flaws, emergency patches coming tomorrow 21/10/2026 PHP Security advisory: Critical remote code execution vulnerabilities, update now 21/10/2026 The PHP Foundation Today's PHP Security Release, and How We're Strengthening PHP Security 21/10/2026 AWS Security Blog Amazon Threat Intelligence identifies PHP2Shell exploitation prior to public disclosure in MadPot 21/10/2026 ENISA Joint statement on critical PHP vulnerabilities 22/10/2026 RTVE Alerta mundial por dos fallos críticos en PHP: qué riesgos afrontan millones de servidores web 27/10/2026 Canadian Centre for Cyber Security AL26-026 - Critical vulnerabilities impacting PHP - CVE-2026-109618 and CVE-2026-109619 - Update 2

The U.S. Cybersecurity and Infrastructure Security Agency (CISA) warned federal agencies to patch a high-severity Linux kernel privilege escalation bug that attackers are chaining with the PHP2Shell flaws in the wild. [...]

The Federal Public Service Finance (FPS Finance), which oversees taxation and other financial administration, said Wednesday that it was investigating the extent of the attack and had temporarily suspended access to MyMinfin, the country's main online platform for managing tax and financial affairs.

CISA inserisce Fragnesia, una falla del kernel Linux, tra le vulnerabilità sfruttate attivamente e segnala la possibile concatenazione con PHP2Shell. La combinazione può trasformare un accesso al server web in privilegi root: patch, verifiche forensi e controlli per aziende e PA italiane L'articolo PHP2Shell e Fragnesia, CISA avverte: server Linux a rischio root proviene da Cyber Security 360 .

Palo Alto Networks on Wednesday warned that threat actors are exploiting the recently patched PHP2Shell vulnerabilities against publicly-accessible management interfaces. "Active exploitation has been observed targeting the Palo Alto Networks management interface exposed to the internet," the network security company said in an update to its advisory. The vulnerabilities, tracked as

GitHub announced a package firewall that checks npm packages against an enterprise’s policy before they install. It blocks known malware, critical vulnerabilities, and brand-new versions, and any developer can turn it on by pointing npm at the firewall. The checks run before a package reaches a laptop, a build, or a coding agent. GitHub says AI agents are helping developers build more software, faster, and the firewall is one of four security additions aimed at … More → The post GitHub’s npm package firewall can block brand-new versions before they install appeared first on Help Net Security .

Cybersecurity researchers have disclosed details of what appears to be an artificial intelligence (AI)-assisted attack orchestrated by a suspected China-nexus threat actor that has leveraged the PHP2Shell vulnerabilities to breach exposed systems. The activity, which was observed on October 25, 2026, involved an attacker combining PHP2Shell with a kernel privilege escalation exploit to root

UK to look at making software companies liable for cyber breaches The British government will consult on how to hold technology companies liable for cyber breaches caused by insecure products — potentially a landmark shift for a country that has for years relied on voluntary codes to encourage software vendors to improve security. The commitment, made in budget documents published on Wednesday, comes amid growing alarm in Westminster over the economic damage caused by cyberattacks. Last year's hack of Jaguar Land Rover alone is estimated to have cost the British economy £1.9 billion ($2.5 billion). According to the budget, the government “will consult next year on how to tackle insecure technology at source and consider where liability for cyber breaches should sit.” The work will build on an ongoing review of product liability law by the Law Commission of England and Wales. Although the pledge occupies just one bullet point in the 166-page document, it marks the first formal pledge by a British government to examine where liability for cyber breaches should sit. Significant questions remain, including which department will lead the consultation, when it will begin and whether ministers envisage a civil liability regime, statutory obligations on vendors, or both. HM Treasury did not respond to a request for comment. One option likely to be considered internally is expanding the Product Security and Telecommunications Infrastructure (PSTI) Act, which since 2024 has imposed basic security requirements on manufacturers of consumer smart devices. Officials are expected to ensure any new rules are compatible with the European Union’s own software cybersecurity regime, to avoid businesses facing heavy costs to comply with two separate sets of requirements. The move follows years of pressure from Britain's own cybersecurity authorities, particularly Ollie Whitehouse, the chief technology officer of the National Cyber Security Centre (NCSC), which is part of the cyber and signals intelligence agency GCHQ. The agency called publicly for a “strategic policy agenda” last year, after efforts to address insecure technology had stalled. Whitehouse had already warned, in a keynote address at the CyberUK conference in Birmingham in 2024, that the technology market was failing to reward companies for building resilient and secure products, while regulation and legislation struggled to keep pace. Last year, he wrote that “the reality is that in 2025, we know how to build secure products and services” but “the business and commercial incentives to encourage adoption and sustainment of secure solutions are not sufficient.” His argument echoed a debate in the United States, where proposals to make software makers liable for flawed code stalled for years amid disagreements over how to define the proper standard of care. The Trump administration has since rolled back several Biden-era secure-software requirements for federal suppliers. The political pressure in Britain intensified last November, when the House of Commons Business and Trade Committee, chaired by Liam Byrne, said a lack of liability for software vendors was among the most pressing issues putting Britain’s economic and national security at risk. It urged ministers to make the NCSC's voluntary software security code of practice legally binding, with penalties for companies that fail to comply. Byrne described the Jaguar Land Rover attack as a “cyber shockwave ripping through our industrial heartlands,” while the committee warned of “a huge increase in the private ownership of public risk.” The government's Cyber Security and Resilience Bill, introduced to Parliament that same month and now before the House of Lords, acknowledged some of the market failures identified by the NCSC in its impact assessment, which pointed to the “information asymmetry between vendors and buyers” making it difficult for customers to judge the security of the technologies they purchase. In its current form, the legislation stops short of imposing obligations on software developers, concentrating instead on operators of critical infrastructure and their suppliers. Arguments ahead The European Union’s Cyber Resilience Act allows regulators to fine manufacturers of insecure products up to €15 million or 2.5% of global turnover, whichever is higher, with its main obligations taking effect in December 2027. A separate overhaul of the bloc’s product liability rules, which member states must adopt by December, extends strict liability to software, including defects caused by missing security updates. Attempts in Britain to shift liability onto software vendors are likely to face resistance, with the Business Software Alliance — whose members include Microsoft, Oracle and Amazon Web Services — having lobbied against such measures and argued that they would stifle innovation. The proposals could also create friction with the United States, where the world’s largest technology vendors are based, and where successive administrations have regarded overseas regulatory efforts with suspicion when they appear to constrain the sector's commercial success. In Britain, the Law Commission consultation referenced in the budget opened on October 8 and runs until January 14. It proposes broadening the definition of a “product” under the Consumer Protection Act 1987 to include software and AI systems, which currently sit in a legal gray area because the law was written for physical goods. That review is sponsored by the Department for Business, Innovation, Science and Trade, but responsibility for national cybersecurity policy now lies with the Department for Culture, Media and Sport. The country’s cyber minister, Baroness Lloyd, holds posts in both departments, as Recorded Future News previously reported. £154 million for AI cyber defenses Alongside the liability consultation, the budget commits £154 million ($205 million) in new funding for cyber defenses, much of which the Treasury had announced ahead of Wednesday's statement. The largest allocation is £70 million ($93 million) for a National Exposure and Real-Time Vulnerability (NERV) Centre at the NCSC. The centre will, according to the budget, use artificial intelligence to identify vulnerabilities across critical infrastructure and the wider economy. The NCSC already scans internet-connected devices hosted in Britain, alerting organizations to exposed or vulnerable systems through its Early Warning and Proactive Notifications services. The budget does not explain how NERV will differ from those existing operations, and an agency spokesperson declined to comment. A further £60 million ($79 million) will support the first phase of the NCSC’s Cyber Shield, announced in April as “a national scale, sovereign defense capability” that would use agentic AI systems to discover and fix cybersecurity weaknesses across government networks and critical national infrastructure. Remaining funds will be used to strengthen the security of technology across the public sector, including systems operated by local authorities, hospitals and schools. Separately, the government has allocated £40 million ($53 million) to establish a National Agentic Security Unit, tasked with detecting, investigating and responding to rogue AI agents. The budget describes the unit’s ambitions as developing “world-first capabilities to detect and respond to misaligned agentic activity,” but does not identify which agency will host it nor how it will interact with similar projects associated with the NCSC. The AI Security Institute, transferred to the Cabinet Office in July, will receive another £120 million ($159 million) over four years to expand its testing of frontier AI models. The investments follow a week in which critical flaws in PHP, discovered using AI, forced websites offline around the world. The NCSC urged organizations to patch affected systems or consider taking them offline. Alexander Martin is the UK Editor for Recorded Future News. He was previously a technology reporter for Sky News and a fellow at the European Cyber Conflict Research Initiative, now Virtual Routes. He can be reached securely using Signal on: AlexanderMartin.79

Attackers are actively exploiting vulnerabilities across critical network infrastructure, and PHP flaws known as "PHP2Shell" put the web management interfaces of firewalls, VPNs, application delivery controllers, and other appliances at risk. [...]

PHP2Shell shows how quickly attackers can exploit critical vulnerabilities, often before organizations have time to patch. Token Security explains why limiting the access of service accounts, API keys, and AI agents is just as important as fixing vulnerabilities to reduce the damage from a breach. [...]

Facendo seguito alle precedenti comunicazioni sulle vulnerabilità critiche note come “PHP2Shell”, si richiama l’attenzione sulla necessità di verificare sulle istanze dei propri servizi offerti la presenza di prodotti di terze parti che integrano PHP.

The attackers chained PHP2Shell and Fragnesia exploits and hacked two servers of a US government-affiliated organization. The post China-Linked Hackers Exploit PHP2Shell to Root Firewalls appeared first on SecurityWeek .

The week leading up to October 25, 2026, was every cyber defender’s nightmare: a barrage of critical vulnerabilities in PHP and the Linux kernel, a compromised LiteLLM release, a maximum-severity flaw in GitLab, a Node.js Brotli flaw, and a certificate authority incident affecting TLS trust. A few years ago, a backlog like this would have filled a defender’s to-do list for a whole month. In the age of AI, all of this was reported within a single “Cybersecurity Black Week,” an exceptionally eventful seven-day period amid an already turbulent Black October. AI-assisted research helped uncover at least two of these flaws: PHP2Shell and the Brotli bug. On top of the breakneck patching pace, security teams faced mounting pressure to deliver status reports to other departments, management, customers, and the media. Beyond their severity, the issues stood out for the variety of responses they demanded. Some required emergency runtime patches and upgrades; others called for containment, credential rotation, or the replacement of outdated certificate trust bundles. In several cases, installing the latest version was only the beginning of a long remediation process. With so many problems landing at once, the main challenge was separating real risk from hype and prioritizing accordingly. Here is our assessment. PHP2Shell: The loudest headline, with real-world limits PHP2Shell generated the biggest media frenzy of the lot and, with it, a major headache for security teams, prompting many organizations to take their websites offline and look for emergency fixes. The name refers to two memory-safety vulnerabilities in PHP core, CVE-2026-109618 and CVE-2026-109619, affecting PHP versions 5.4 through 8.5.11. Both vulnerabilities received a CVSS v4.0 score of 9.2 and can allow unauthenticated remote code execution (RCE) on vulnerable PHP servers. In the highest-risk setups, a demonstrated exploit can trigger the vulnerability before application code runs, meaning application-level authentication offers no protection. With PHP powering an estimated 69% of websites whose server-side programming language is known, government agencies in the United States, Europe, and elsewhere urged organizations to patch immediately, with some advising that affected internet-facing systems be isolated or taken offline if they could not be patched promptly. Government websites in the Netherlands, Germany, France, and other countries were temporarily taken offline as a precaution. The PHP project released fixes on October 21 in versions 8.5.12, 8.4.27, 8.3.36, and 8.2.35, along with source-only backports for the end-of-life 7.4, 8.0, and 8.1 branches. The rollout was complicated by a premature public leak, which forced the coordinated disclosure timeline forward. While the flaws clearly belonged near the top of the patching list, early evidence suggested they were considerably harder to weaponize than initially feared. Successful exploitation requires specific conditions and knowledge of the target, and public proof-of-concept exploits did not work against a default PHP installation, according to Sansec. On October 22, ESET was among nine security companies that told NBC News they had not seen any successful attacks, even though more than 200 proof-of-concept exploits were circulating. The remediation challenge extends beyond obvious web servers: PHP can also be embedded in appliances, network devices, management interfaces, and third-party products, while end-of-life PHP branches do not receive normal upstream binary releases. Linux kernel: Reports went public before fixes were ready As if the PHP issues weren’t severe enough, on October 21, Trend Micro’s Zero Day Initiative (ZDI) sent several reports on unpatched Linux kernel vulnerabilities to the kernel’s private security address while also copying public mailing lists. As a result, technical details of vulnerabilities for which fixes were not yet generally available became public, prompting stable kernel maintainer Greg Kroah-Hartman to question why the reports had been sent to public lists without patches. The two most severe issues, both rated CVSS 9.0 by ZDI, affect KSMBD, the Linux kernel’s built-in SMB server. ZDI-CAN-33549 is an integer underflow in the SMB Direct path that could lead to RCE, while ZDI-CAN-33774 is a race condition that could also lead to RCE. Exploiting ZDI-CAN-33549 requires an RDMA-capable interface, a writable KSMBD share, and SMB Direct negotiation, significantly narrowing the number of systems exposed to that particular attack. Other reports concerned local privilege escalation vulnerabilities in the networking stack and the VMware graphics driver, as well as an information disclosure issue in the NVMe target code (NVMET). To remediate, security teams had to track each report independently, consult distribution advisories, and restrict exposed services where practical while awaiting verified fixes. Kernel updates also required rebooting into the patched kernel and checking the running version, not merely confirming that a new package had been installed. LiteLLM: Compromised, not merely vulnerable On October 21, attackers published a malicious version of LiteLLM, 1.107.0, to PyPI and pushed compromised images to the project’s official container registries. According to the project’s incident report, its release pipeline was breached using GitHub CLI credentials associated with three developers. One of the stolen tokens belonged to an owner of the project’s GitHub organization, allowing attackers to disable branch protections and modify the release workflow to point to a lookalike repository. LiteLLM, a Python proxy for LLM providers, has about 23 million weekly downloads, and the malicious version remained available on PyPI for roughly two hours before it was quarantined. It was the project’s second supply-chain compromise of 2026, after malicious versions 1.82.7 and 1.82.8 appeared in March. The payload combined a credential stealer with a second-stage remote access trojan (RAT). By abusing Python’s startup mechanisms, including a .pth file, it ran every time Python started, even if an application never imported LiteLLM. Execution therefore did not depend on exploiting an application flaw: simply running Python in an affected environment could be enough. Affected environments had to be treated as potentially compromised, not merely vulnerable. According to LiteLLM, these included environments that ran litellm==1.107.0 and containers that executed affected images distributed under the v1.107.0, latest, main-latest, or main-stable tags during the compromised intervals. Removing or replacing the package was insufficient: teams needed to determine whether the malicious code had run, contain affected systems, rebuild from clean sources, and rotate exposed secrets from a clean environment. Cloud, source-control, and CI/CD logs also had to be reviewed for unauthorized activity. Node2Shell: From Node.js to HTTP2Shell Node2Shell (CVE-2026-111497) is an out-of-bounds write in Google’s Brotli decoder, which Node.js bundles. Malformed compressed input can cause crashes, memory disclosure, or potentially RCE when an application decompresses attacker-controlled Brotli data. This can happen through explicit decompression, compressed request bodies, or automatically decompressed responses. Node.js rates the flaw as high severity, while the broader Brotli vulnerability carries a CVSS v4.0 score of 9.2. According to Aikido, researchers demonstrated code execution against the official, unmodified Node.js 24.22.0 image on Linux ARM64. Although the exploit did not work on every attempt, the demonstration showed that exploitation was practical, if not universally reliable. Node.js shipped fixes on October 21 in versions 22.23.4, 24.22.1, and 26.12.1, and Bun followed with version 1.4.4 or later. Node.js 25.x, 23.x, 20.x, and earlier releases are end-of-life and will not receive the fix. Within days, the story outgrew Node.js. The same decoder is compiled into the Python Brotli and brotlicffi packages as well as into other HTTP software, which led researchers to rename the issue HTTP2Shell. The operational challenge was therefore not simply upgrading a single runtime but identifying every container, serverless deployment, and library that bundles the vulnerable decoder. The issue was fixed upstream in Brotli 1.2.1. Notably, OpenAI’s Codex Security had reported the underlying bug, and the fix had been present in the Brotli source since February without being recognized as a security issue. GitLab: Credential leaks and authorization failures On October 21, GitLab shipped a critical out-of-band patch release (versions 19.5.1, 19.4.3, 19.3.6, 19.2.9, 19.1.9, 19.0.10, and 18.11.13) addressing 12 security vulnerabilities. The headline flaw, CVE-2026-110264, rated 10.0 under CVSS v3.1, is an integer overflow triggered when GitLab compiles a specially crafted regular expression. Under certain conditions, it could allow an unauthenticated attacker to execute arbitrary code on the server. The affected versions date back to GitLab 7.0. The other fixes addressed credential exposure, cache poisoning, authorization bypasses, and failures to enforce membership or merge-request approval policies. Reported unauthenticated attack paths included exposure of sensitive credentials through internal response headers and manipulation of a shared OAuth/OIDC discovery cache, while other issues required authenticated access. GitLab did not publish individual severity scores or exploitability details for these issues. GitLab.com and GitLab Dedicated were already patched, so the work fell on administrators of self-managed instances. GitLab strongly recommended upgrading immediately, but with a catch: the older backport releases (19.2.9, 19.1.9, 19.0.10, and 18.11.13) included only the critical fix, while the remaining 11 issues were fixed only in 19.3.6 and later. Administrators also had to verify that all deployment components had been updated and assess the potential exposure of credentials and private project data due to the fact that patching would not invalidate stolen credentials or reverse unauthorized changes. eMudhra/emSign: Compromised certificate trust The high-priority eMudhra/emSign incident involved no software vulnerability at all. Several eMudhra intermediate certificate authorities (CAs) had insecure private keys, meaning attackers could potentially create certificates that would be trusted through the affected emSign certificate chain. While browsers had updated their trust stores and revocation lists, some Python tooling continued to trust the compromised intermediate CAs through its own certificate bundles. This created a risk of man-in-the-middle (MITM) attacks against TLS connections, including those to python.org and pypi.org. The Python Software Foundation urged users to upgrade immediately to at least certifi 2026.10.19, pip 26.2.2, and uv 0.13.4, and the Python core team shipped expedited releases 3.15.2, 3.14.10, 3.13.18, 3.12.16, and 3.11.18 to update the bundled pip. The updates had to reach every host, application, and existing virtual environment. Container images had to be rebuilt with layer caching disabled to fetch the latest system certificates. The decisive check was whether deployed clients rejected the compromised trust paths; simply upgrading Python was not enough. Cutting through the noise Cybersecurity Black Week showed that a severity score rarely tells the whole story. A 9.2-rated PHP flaw that attackers struggled to exploit, a 10.0-rated GitLab bug, exposed kernel reports with no patches, and a poisoned package that ran at Python startup each called for a different response. What they all had in common was a window of exposure: the time between disclosure and when the last affected system is patched. For the leaked kernel flaws, that window opened before any fix existed, and for end-of-life PHP versions, it may never fully close. This is where ESET’s multilayered protection comes in, using behavioural detection and other security mechanisms to help block exploitation attempts and keep systems protected until patches are applied. At the same time, the signals defenders rely on were buried in noise, from scanning that was largely benign to a single behavioural rule firing hundreds of thousands of times in a week. What mattered most was quickly understanding which incidents actually affected an organization's environment and what each incident required. That is the problem ESET’s correlation engine, ESET LiveCortex, and its specialized cybersecurity model, ESET NeoCortex, are designed to solve: turning an overwhelming volume of raw data into understandable incidents so that defenders can act before attackers achieve their goals. To learn how they work, read Beyond the alert: How ESET is teaching AI to understand security incidents.

Modern phishing campaigns can compromise American businesses without relying on traditional credential theft. Attackers can abuse legitimate cloud services, authentication mechanisms, and trusted business workflows to gain access to corporate accounts while leaving fewer obvious signs behind. ANY.RUN's analysis of Skyw4lker, a device code phishing campaign primarily targeting U.S. organizations

Un’analisi indipendente ricostruisce l’evoluzione delle attività offensive associate a CVE-2026-109618 e CVE-2026-109619 . Tra tentativi pre-disclosure, infrastrutture di exploitation, malware Potassium e prove di esecuzione remota, la differenza essenziale è tra ciò che è stato osservato e ciò che è stato dimostrato. Di Agostino Pellegrino e Crescenzo Cuoppolo 27 ottobre 2026  ·  Cyber Threat Intelligence   ·  Vulnerability Research  ·  Detection Engineering Un’emergenza che richiede soprattutto accuratezza Il 21 ottobre 2026 il progetto PHP ha pubblicato aggiornamenti di sicurezza per due vulnerabilità critiche, identificate come CVE-2026-109618 e CVE-2026-109619 , collettivamente conosciute come PHP2Shell [1, 2]. Entrambe presentano un punteggio CVSS v4.0 pari a 9,2 e possono consentire, in determinate condizioni, l’esecuzione remota di codice senza autenticazione. Le vulnerabilità interessano il motore PHP, non una specifica applicazione, un plugin o un content management system. La natura delle debolezze rende particolarmente rilevante la superficie esposta attraverso applicazioni web, piattaforme CMS, servizi legacy e prodotti che incorporano un interprete PHP. La pubblicazione degli aggiornamenti ha coinciso con una rapida diffusione di proof of concept, scanner e tentativi di sfruttamento. Alcune attività erano state osservate persino prima della disclosure ufficiale [3]. Il problema non riguarda soltanto l’esistenza di vulnerabilità critiche o la disponibilità di strumenti per sfruttarle. La questione centrale è determinare quando un tentativo di exploitation possa essere considerato una compromissione effettiva. È da questo interrogativo che nasce il nostro rapporto indipendente di Cyber Threat Intelligence, dedicato alla raccolta, verifica e classificazione di indicatori tecnici associati a PHP2Shell. L’analisi, aggiornata al 27 ottobre 2026, consolida 67 osservabili , distinguendo evidenze di esecuzione, attività offensive documentate e informazioni contestuali utili alle indagini. Il risultato non è una lista di 67 sistemi compromessi, né un censimento di attacchi riusciti. È un insieme strutturato di elementi investigativi la cui interpretazione dipende dalla qualità delle evidenze disponibili. Le vulnerabilità: corruzione della memoria e stato globale non valido La prima vulnerabilità riguarda la gestione delle condizioni di esaurimento della memoria. PHP utilizza meccanismi di interruzione del flusso di esecuzione, tra cui longjmp(), per gestire determinati errori fatali. Quando l’esaurimento della memoria interrompe una fase in cui alcune strutture interne non sono state completamente inizializzate, la successiva procedura di cleanup può accedere a uno stato non valido. In condizioni sfruttabili, questa situazione può condurre a corruzione della memoria ed esecuzione di codice non autorizzato [1]. CVE-2026-109619: riferimenti persistenti a memoria già liberata La seconda vulnerabilità interessa la gestione di variabili e strutture globali che possono conservare riferimenti a memoria appartenente a richieste precedenti. Se lo stato globale non viene correttamente ripristinato, una richiesta successiva può accedere a regioni di memoria non più valide. Il problema può facilitare condizioni di accesso improprio alla memoria e, in scenari sfruttabili, esecuzione remota di codice [2]. Versioni interessate e correzioni Le release PHP corrette pubblicate il 21 ottobre sono: Le versioni precedenti alle rispettive release corrette risultano vulnerabili secondo gli advisory upstream. Le distribuzioni che utilizzano backport di sicurezza richiedono una verifica specifica del pacchetto installato. Per le versioni non più supportate dal progetto PHP occorre valutare gli aggiornamenti del distributore, eventuali servizi di supporto esteso oppure la migrazione. L’esposizione non è uniforme in tutte le architetture. Apache con mod_php rappresenta uno degli scenari di maggiore interesse, poiché sono stati dimostrati percorsi di sfruttamento che intervengono prima dell’esecuzione del codice applicativo. Altri modelli, tra cui PHP-FPM, PHP-CGI, FrankenPHP e LiteSpeed, richiedono una valutazione delle rispettive condizioni di sfruttabilità. La presenza di un runtime vulnerabile non dimostra che un sistema sia già stato attaccato o compromesso. La cronologia: dalle prime attività alla prova di esecuzione 17 ottobre 2026 — Attività precedente alla divulgazione Amazon Threat Intelligence individua attraverso la rete MadPot tentativi compatibili con PHP2Shell. L’attività precede di quattro giorni il rilascio pubblico delle correzioni. L’origine attraverso infrastrutture di anonimizzazione e la natura delle richieste indicano un’attività sospetta, senza consentire di stabilire come gli operatori avessero ottenuto le informazioni tecniche in anticipo [3]. 21 ottobre 2026 — Disclosure e aggiornamenti Il progetto PHP pubblica le release di sicurezza. Nelle ore precedenti e successive emergono strumenti di scansione, proof of concept e ulteriori tentativi osservati da fornitori di sicurezza e infrastrutture di monitoraggio [1, 2, 9]. 22 ottobre 2026 — Tentativi di distribuzione malware Sophos e Arctic Wolf descrivono attività offensive associate a payload riconducibili a Potassium, variante con caratteristiche derivate da Mirai. La presenza di payload e infrastrutture C2 non dimostra automaticamente l’installazione del malware sui sistemi bersaglio [5, 6]. 24 ottobre 2026 — Evidenza di esecuzione su honeypot Il ricercatore 0x4D31 pubblica un dataset che collega traffico HTTP, log Apache/PHP, PCAP e telemetria Tetragon. Vengono documentate 35 esecuzioni di /bin/sh su tre ambienti honeypot PHP intenzionalmente vulnerabili [4]. 25 ottobre 2026 — Rettifica dell’attribuzione Unit 42 ritira una precedente attribuzione che collegava un incidente presso un ente governativo europeo alle specifiche vulnerabilità PHP2Shell. L’incidente era osservato nel contesto di un’applicazione PHP vulnerabile, ma le evidenze non erano sufficienti per confermare che l’accesso iniziale fosse avvenuto attraverso le due CVE [11]. Anche Sophos aveva corretto il 22 ottobre una propria valutazione iniziale relativa a una compromissione presso un cliente, precisando che la telemetria disponibile documentava scansioni e tentativi falliti [5]. La solidità di un rapporto tecnico dipende anche dalla capacità di correggere le attribuzioni quando le evidenze non le sostengono. Le 35 shell: cosa dimostrano realmente gli honeypot Il rapporto tecnico pubblicato il 24 ottobre da 0x4D31 presenta una catena probatoria particolarmente interessante, basata su tre target PHP configurati come honeypot (T1, T2 e T3), con PHP 8.4.26, Apache mod_php e un limite di memoria PHP di 128 MiB [4]. La ricerca ha correlato 35 richieste HTTP della fase finale dell’ exploit con 35 eventi di avvio di /bin/sh, generati direttamente da processi Apache. Le esecuzioni sono documentate mediante packet capture e telemetria del sistema operativo. Il dataset include eventi di creazione dei processi, relazioni padre-figlio, richieste HTTP e informazioni temporali. In diversi casi i comandi eseguiti hanno invocato utility come id, PHP CLI e curl, producendo ulteriori elementi di conferma. Questo consente di superare la semplice osservazione di richieste anomale o di errori applicativi. Una richiesta HTTP sospetta non prova l’esecuzione remota di codice; un errore PHP di memoria esaurita non costituisce, da solo, prova di compromissione. Nemmeno un crash del worker Apache consente automaticamente tale conclusione. La presenza di una shell avviata dal processo web, temporalmente correlata alla richiesta di exploitation, costituisce invece un’evidenza endpoint molto più forte. Questi eventi riguardano sistemi honeypot deliberatamente vulnerabili, non ambienti produttivi di organizzazioni terze. I due indirizzi IP individuano due gruppi di traffico, non necessariamente due attori indipendenti. La somiglianza dei payload non basta ad attribuire un controllo comune. Il materiale è coerente con una catena di sfruttamento associata a CVE-2026-109618 . Non permette, da solo, di dimostrare lo sfruttamento di un percorso indipendente e specifico di CVE-2026-109619 . La sequenza tecnica osservata A1 — Memory pressure. Una richiesta HTTP multipart provoca una condizione di esaurimento della memoria nel processo PHP. B1 — Memory disclosure. Una seconda richiesta produce una risposta contenente dati anomali nel valore di sessione, utilizzabili per inferire informazioni sulla memoria del processo. A2 — Ulteriore memory pressure. Una successiva richiesta prepara lo stato necessario allo sfruttamento. B2 — Execution stage. Una richiesta finale, adattata alle informazioni raccolte, conduce all’avvio di una shell nei casi documentati. In alcune sequenze il worker Apache termina successivamente per segmentation fault. La combinazione tra disclosure della memoria e successivo adattamento del payload è significativa perché dimostra la possibilità di superare, in quelle specifiche condizioni sperimentali, ostacoli introdotti dalla randomizzazione dello spazio di indirizzamento. Le condizioni operative del test non autorizzano a generalizzare la stessa probabilità di successo a tutte le installazioni PHP [4]. Potassium: il malware collegato ai tentativi Parallelamente alla diffusione degli exploit, diversi ricercatori hanno osservato attività orientate alla distribuzione di malware. Un caso riguarda Potassium, famiglia con caratteristiche riconducibili all’ecosistema Mirai [5, 6]. I campioni analizzati presentano funzionalità di downloader, comunicazione con infrastrutture remote e capacità di condurre attacchi di interruzione del servizio. Tra gli indirizzi associati all’infrastruttura figurano 134.199.154.64 e 117.55.202.115. Ulteriori indicatori comprendono domini di staging e URL destinati al recupero di payload. L’interesse investigativo riguarda la possibile concatenazione tra accesso iniziale, esecuzione di codice, download di un componente secondario e successiva attività malevola. Nel caso documentato da Sophos, tuttavia, l’analisi successiva ha stabilito che il tentativo non aveva prodotto l’installazione del malware sul sistema cliente [5]. Gli hash pubblicati identificano campioni analizzati, non file necessariamente trovati su vittime compromesse. La disponibilità di un malware e l’osservazione di un tentativo di consegna non dimostrano il completamento della catena d’infezione. La nostra analisi CTI: 67 osservabili e tre livelli probatori Il consolidamento ha prodotto un dataset di 67 indicatori e artefatti tecnici, selezionati e contestualizzati attraverso fonti pubbliche. La classificazione non è costruita esclusivamente sulla reputazione dell’indirizzo, sull’origine dell’infrastruttura o sulla pericolosità presunta del contenuto: il criterio è la relazione documentabile tra l’osservabile e uno specifico evento. Livello A: evidenza diretta nell’ambiente osservato Comprende indirizzi sorgente associati alle 35 shell, un endpoint di callback, un boundary HTTP ricorrente e 16 digest dei corpi multipart della fase di esecuzione. Non rappresenta 20 compromissioni indipendenti. La classificazione descrive il collegamento dell’elemento a episodi di RCE documentati sui target di ricerca. Livello B: attività offensiva e infrastruttura Raccoglie IP di scansione, tentativi di exploitation, server associati a payload, domini e hash dei campioni Potassium. La presenza di questi indicatori in una rete richiede approfondimento, ma non certifica il successo dell’attacco. Livello C: contesto investigativo Include User-Agent, boundary multipart, marker di validazione, strumenti ospitati su server esposti e digest appartenenti a fasi preliminari dell’exploit. Sono elementi utili per riconoscere pattern di attività o collegare eventi, ma alcuni sono aspecifici e producono falsi positivi se interpretati isolatamente. La confidenza elevata attribuita alla pubblicazione di un osservabile indica che la fonte ne documenta l’esistenza; non significa che qualsiasi corrispondenza rappresenti un incidente . Dall’indicatore alla detection: il ruolo del SOC Una delle principali criticità operative è la tendenza a trasformare automaticamente gli indicatori CTI in regole di blocco. Un IP associato a una scansione può appartenere a un’infrastruttura condivisa, a un provider di hosting o a una rete di anonimizzazione. Una corrispondenza su un User-Agent può rappresentare una scansione autorizzata oppure una stringa imitabile. Un digest di payload HTTP può identificare una richiesta già osservata senza dimostrare che il comando associato sia stato eseguito. Il rapporto propone un approccio di detection engineering basato sulla correlazione tra rete, applicazione ed endpoint . Hunting sui log PHP Tra i segnali tecnici figura la combinazione tra errore fatale PHP, esaurimento della memoria e stringa Unknown on line 0. Un esempio preliminare KQL per Elastic Security, da adattare ai dataset disponibili, è: message: “PHP Fatal error” and message: “Allowed memory size” and message: “Unknown on line 0” Elastic ha pubblicato una regola denominata Potential PHP2Shell Exploitation Attempt, orientata al riconoscimento del caratteristico errore OOM. La regola identifica possibili tentativi, non costituisce una prova autonoma di esecuzione remota [10]. Hunting comportamentale su Linux La telemetria di processo può rilevare l’avvio di shell, interpreti o utility di rete da parte dei processi web. Esempio EQL: process where host.os.type == “linux” and   event.type == “start” and   process.parent.name : (“apache2″,”httpd”,”php-fpm*”,     “php”,”php-cgi”,”nginx”,”lsphp*”) and   process.name : (“sh”,”bash”,”dash”,”curl”,”wget”,     “python*”,”perl”,”nc”,”socat”) La logica ricerca comportamenti compatibili con attività post-exploitation e non è limitata a PHP2Shell. Hunting comportamentale su Windows Su Windows l’attenzione deve concentrarsi sulle relazioni tra i processi web e gli interpreti di comando o le utility utilizzabili per attività successive all’accesso iniziale. Esempio EQL: process where host.os.type == “windows” and   event.type == “start” and   process.parent.name : (“w3wp.exe”,”php.exe”,     “php-cgi.exe”,”httpd.exe”,”nginx.exe”) and   process.name : (“cmd.exe”,”powershell.exe”,”pwsh.exe”,     “certutil.exe”,”bitsadmin.exe”,”curl.exe”,”mshta.exe”) Entrambe le ricerche richiedono copertura EDR, normalizzazione ECS e validazione sui comportamenti legittimi dell’organizzazione. Il valore della correlazione Una sequenza investigativa di particolare interesse comprende: Richiesta HTTP multipart sospetta. Errore di memoria PHP durante l’inizializzazione della richiesta. Eventuale disclosure di dati di sessione o crash del worker. Creazione inattesa di una shell da parte del processo web. Esecuzione di comandi di ricognizione o utility di rete. Connessioni outbound e modifiche del filesystem. Maggiore è il numero di evidenze indipendenti temporalmente coerenti, più solida diventa la valutazione. Gli access log standard non contengono necessariamente gli header completi o i corpi multipart necessari a identificare i fingerprint descritti. Occorre verificare quali informazioni siano realmente disponibili tramite WAF, CDN, reverse proxy, log applicativi e sensori di rete. Il runbook proposto per SOC e CSIRT 1. Identificazione dell’esposizione. Inventariare runtime PHP, versioni, configurazioni web server, prodotti embedded e backport. Dare priorità agli asset Internet-facing. 2. Preservazione delle evidenze. Per eventi sospetti conservare log HTTP, PHP error, EDR, eventi processo, connessioni rete, file ed eventuali evidenze volatili. 3. Correlazione temporale. Ricostruire richieste, risposte, PID dei worker e processi figli. Verificare il client IP reale attraverso i proxy attendibili. 4. Classificazione dell’evento. Separare scansione, tentativo, possibile memory disclosure, RCE verificata e successivo impatto. 5. Remediation. Installare le versioni corrette o gli aggiornamenti con backport verificato. Impiegare WAF come controllo aggiuntivo, non sostitutivo delle patch. 6. Revalidazione. Verificare aggiornamenti, copertura dei sensori ed eseguire retro-hunt a partire almeno dal 17 ottobre 2026. Gli indicatori A meritano hunting prioritario, senza escalation automatica in assenza di riscontri locali. Gli osservabili B richiedono enrichment e correlazione, con blocchi selettivi previa valutazione del rischio. Gli elementi C costituiscono soprattutto supporto investigativo e per le ricerche retrospettive. Le infrastrutture complesse e il problema del patching La diffusione di PHP in applicazioni web, piattaforme legacy e prodotti embedded rende la gestione di PHP2Shell un problema trasversale. Non è sufficiente interrogare la versione del linguaggio installata sui server più visibili. Occorre considerare componenti applicative non censite, istanze secondarie, ambienti di test raggiungibili dall’esterno, dipendenze di terze parti e runtime distribuiti insieme ad altri prodotti. In ambienti complessi, tra cui organizzazioni pubbliche e infrastrutture con numerosi fornitori, il problema principale può essere la conoscenza incompleta della superficie applicativa. Il rischio è aggravato dalla differenza tra disponibilità della patch e applicazione effettiva. Le evidenze precedenti al 21 ottobre mostrano anche che la finestra investigativa non deve iniziare necessariamente dalla disclosure ufficiale: occorre includere eventi antecedenti quando esistono indicatori attendibili di tentativi osservati durante il periodo di embargo. Conclusioni: la CTI deve produrre evidenza, non soltanto allarmi PHP2Shell rappresenta un caso significativo non soltanto per la gravità delle vulnerabilità, ma per la rapidità con cui la comunità ha prodotto osservazioni, strumenti e valutazioni differenti. I tentativi offensivi sono documentati anche prima della divulgazione. Esistono infrastrutture e campioni malware collegati alle attività osservate. La ricerca su honeypot ha dimostrato esecuzioni remote di codice in specifiche condizioni sperimentali. Non è invece corretto trasformare queste evidenze in una dichiarazione generalizzata di compromissioni produttive attribuite alle due vulnerabilità. Le rettifiche dei ricercatori devono essere incorporate nelle analisi successive, evitando che informazioni superate continuino a circolare come fatti accertati. Il nostro dossier CTI nasce da questa impostazione: ogni osservabile deve essere accompagnato da contesto, provenienza e livello probatorio. Per un SOC , un CSIRT o un team di Incident Response, il valore dell’intelligence non coincide con il numero di IOC raccolti. Coincide con la capacità di utilizzarli per formulare ipotesi verificabili, individuare anomalie significative e ricostruire, quando possibile, una catena di evidenza. È questa la differenza tra identificare un tentativo di attacco e dimostrare una compromissione. Appendice tecnica — Dataset CTI PHP2Shell Snapshot del 27 ottobre 2026. Gli indicatori sono destinati ad attività di hunting, enrichment e correlazione; non rappresentano una blocklist da distribuire indiscriminatamente. Le classificazioni A/B/C si riferiscono agli eventi documentati, non a proprietà permanenti dell’indicatore. A. Indirizzi IPv4 B. Domini, URL ed endpoint Non visitare o eseguire gli URL da dispositivi di lavoro. Infrastrutture e indirizzi potrebbero essere stati modificati o riassegnati dopo il periodo osservato. C. Hash malware Potassium SHA-256 · Campione 1 0c5486f06620e26e316f4b33f318b0d646d5e1133789331aa2fed012360d1486 MD5 · Stesso campione b61a098fc62a2c2696e196dca78da71a SHA-1 · Stesso campione c472dab4ff7c16782a8037f988d4daa6d4bdb343 SHA-256 · Campione 2 e2529d4afa39ae4db2eb05d5176317c906289abf09660c75bdeec43e54c55aa3 I primi tre hash si riferiscono allo stesso campione. Gli hash di file sono indicatori di malware analizzato, non prova di installazione su un host produttivo. Tutti sono di livello B. D. Fingerprint HTTP e indicatori contestuali Il boundary CCCCCCCCCC è presente nel traffico che ha prodotto RCE sugli honeypot, ma è generico e, isolatamente, comporta alto rischio di falsi positivi. Header, marker e valori multipart possono non essere acquisiti dai normali access log. E. Digest SHA-256 dei corpi HTTP multipart I 19 SHA-256 che seguono riguardano corpi HTTP multipart decodificati e NON file malware. Il confronto richiede PCAP o telemetria WAF/reverse proxy con body completo e normalizzazione coerente con quella del rapporto originale [4]. Tre digest preliminari — livello C A1 · Memory pressure 8e8fc166e6b326d20bb7611d8ef3cee3bd5da46447985312c1492ab0a44d1eb6 B1 · Memory disclosure b6c547e0e9a2bb26607df1521de96f4d5c9adf4621c28b7ab491587b21ae40f2 A2 · Memory pressure 7af66c8f35c5fa6b47a539da6dca361d19543d9f62d61e4af891c2802bd5e236 Sedici digest della fase B2 — livello A 01   e538361aa02f01bb9e00f53d2107eb1369f778203033e08506496a767c0e4abc 02   aab24fa5ec0df76f731c1ea4bac9fd36aa350eef9a42c33315e485178e1e5892 03   b8a67dc5173272afd95cd603b2bd7b49bb6e0900af53237096b8caf9fd48ca97 04   567659d699213c360e4598c257c40260cf0d7b1377e4a25851ca3f59a427899c 05   a744539cce8295ac07ca70fd5eab9601ef79fb62f142749373d855033fb101e0 06   675647c9919681e3f6a58c54be30a22942b523e036ee53f0e4fdccf22a506408 07   d2d86024e947cbdcecb725e3dae4930579b28f23bff80eedaad6b3f11544bcff 08   dcb4e2b4f6879827222d0bb5efa14dc838357251880302401bc8702bb3085370 09   b8e69e39c49c986a6edae77f08b11be1ab1675d4fda6c05dcf0628149eefbd06 10   c1263f68fcb9565dc3b162481574ed6f64ad11436e654751a9da4644352bbcee 11   c61540651b07f744fa9d43ff326daa7a81c51f90ffdd05b28d1b552ade5320a4 12   c1fc4df4a886aff090471f27a40c29358444b3668257e1b2074577477ba2e36c 13   ff73391d30efd875a28c65178a59cacf6b933f911ae51654b2ffb4d4d3fe850a 14   23b0d9cb7dce28dbeb9749d2664eacd64474f7a4fab3c152747603c33214e58a 15   77afd5bf9c28069616b514a2955dbf52dc62e3b5c5c04c1e86c7a3c3fc5a5156 16   e5a9ca54352814eaefc2051013aa424d4e6fd780a2c0d1085fdd35eac392e5c4 Una corrispondenza su questi digest non certifica da sola l’esito RCE. Non convertirli in hash IOC file-based per EDR. F. Indicatori esclusi dal consolidamento Sono stati esclusi dieci elementi o categorie di elementi non sufficientemente specifici, non verificati indipendentemente oppure oggetto di rettifica. Tra questi figurano boundary sperimentali, indirizzi probabilmente riconducibili a scanner di ricerca, fingerprint confondibili con la distinta vulnerabilità WordPress WP2Shell e indicatori dell’incidente europeo per cui Unit 42 ha ritirato l’attribuzione. L’esclusione è parte integrante del metodo analitico: la presenza di un valore in una regola sperimentale o in una directory non basta a qualificarlo come IOC accertato. Bibliografia e fonti tecniche Riferimenti tecnici pubblici richiamati nell’articolo. Data di consultazione del dossier: 27 ottobre 2026. I collegamenti sono cliccabili; le date delle singole pubblicazioni sono riportate quando note. [1] PHP Development Team. (2026, 21 ottobre). RCE via OOM corruption (GHSA-w8hw-w9fx-j79w). GitHub Security Advisory. https://github.com/php/php-src/security/advisories/GHSA-w8hw-w9fx-j79w [2] PHP Development Team. (2026, 21 ottobre). RCE via stale global state (GHSA-6wmf-4rv5-p3rp). GitHub Security Advisory. https://github.com/php/php-src/security/advisories/GHSA-6wmf-4rv5-p3rp [3] Amazon Threat Intelligence. (2026, 21 ottobre). Amazon Threat Intelligence identifies PHP2Shell exploitation prior to public disclosure in MadPot. AWS Security Blog. https://aws.amazon.com/blogs/security/amazon-threat-intelligence-identifies-php2shell-exploitation-prior-to-public-disclosure-in-madpot/ [4] 0x4D31. (2026, 24 ottobre). PHP2Shell exploitation observed: Packet-to-process RCE evidence. GitHub. https://github.com/0x4D31/honeypot-data/blob/main/reports/php2shell/2026-10-24-confirmed-rce.md [5] Sophos. (2026, ottobre). Proof-of-concept exploit released for PHP vulnerabilities ( CVE-2026-109618 , CVE-2026-109619 ). https://www.sophos.com/en-us/blog/proof-of-concept-exploit-released-for-php-vulnerabilities-109618-109619 [6] Arctic Wolf Labs. (2026, 22 ottobre). PHP2Shell: Critical PHP vulnerabilities enable unauthenticated remote code execution . https://arcticwolf.com/resources/blog/php2shell-critical-php-vulnerabilities-enable-unauthenticated-remote-code-execution/ [7] SOCRadar Threat Intelligence Unit. (2026, ottobre). PHP2Shell exploit tooling found on exposed attacker server. https://socradar.io/blog/php2shell-exploit-tooling-attacker-server/ [8] Hunt.io. (2026, 22 ottobre). Hunting leaked PHP2Shell RCE across open directories. https://hunt.io/blog/php2shell- CVE-2026-109618 -109619-open-directories [9] Fastly. (2026, ottobre). PHP2Shell: Finding the needles in a 250,000 request haystack. https://www.fastly.com/blog/how-fastly-detected-and-built-a-coordinated-response-to-php2shell [10] Elastic. (2026). Potential PHP2Shell exploitation attempt. Elastic Security. https://www.elastic.co/guide/en/security/8.19/prebuilt-rule-8-19-36-potential-php2shell-exploitation-attempt.html [11] Palo Alto Networks, Unit 42. (2026, aggiornamento 25 ottobre). Threat brief: Critical vulnerabilities in PHP— CVE-2026-109618 , CVE-2026-109619 . https://unit42.paloaltonetworks.com/ CVE-2026-109618 - CVE-2026-109619 / [12] Amazon Web Services. (2026, 21 ottobre). Using AWS WAF to apply mitigations for PHP2Shell RCE vulnerabilities. AWS Security Blog. https://aws.amazon.com/blogs/security/using-aws-waf-to-apply-mitigations-for-php2shell-rce-vulnerabilities- CVE-2026-109618 -and- CVE-2026-109619 / [13] PHP Development Team. (2026). PHP release archive. https://www.php.net/archive/2026.php [14] CISA . (2026). Experimental SIGMA rule for PHP2Shell. GitHub. https://github.com/cisagov/SIGMA_Rules/blob/develop/CISA_SIGMA_261429_CVE_2026_109618-109619_PHP2Shell_TLP_CLEAR.yaml Nota metodologica Il presente articolo è una sintesi analitica indipendente basata su correlazione e classificazione di evidenze tecniche pubbliche. Non rappresenta un advisory ufficiale, non implica accesso diretto ai sistemi delle organizzazioni citate e non certifica compromissioni produttive in assenza di evidenze specifiche. Gli osservabili devono essere interpretati nel contesto temporale e tecnologico delle rispettive fonti. Il rapporto CTI originario e il dataset strutturato rimangono le fonti canoniche delle classificazioni. Autori: Agostino Pellegrino e Crescenzo Cuoppolo. Rapporto di riferimento: PHP2Shell — Dalla telemetria alla prova. IOC, catena di evidenza e detection engineering. Edizione indipendente del 27 ottobre 2026. L'articolo PHP2Shell: 67 indicatori, 35 esecuzioni di shell e il confine tra attacco e compromissione. L’analisi tecnica proviene da Red Hot Cyber .

The U.S. Cybersecurity and Infrastructure Security Agency (CISA) on Tuesday added two vulnerabilities impacting Adobe Commerce and Magento, and Google's Brotli decoder library to its Known Exploited Vulnerabilities (KEV) catalog, citing evidence of active exploitation. The vulnerabilities are listed below - CVE-2026-111497 (CVSS score: 9.2) - An unchecked return value vulnerability in

I ricercatori hanno confermato lo sfruttamento riuscito di due vulnerabilità critiche PHP2Shell, che permettono di eseguire comandi remoti sui server vulnerabili senza autorizzazione preliminare. In precedenza, gli esperti avevano registrato tentativi di attacco, ma non erano riusciti a confermare che i malintenzionati fossero riusciti a far eseguire codice dannoso. La conferma è arrivata da Adeel Karimi, responsabile del settore di rilevamento delle minacce e risposta agli incidenti in Perplexity . Le sue honeypot hanno registrato un attacco riuscito su un sistema con Apache mod_php e PHP 8.4.26. Durante l’attacco, il malintenzionato ha ottenuto circa 800 KiB (kibibyte) di dati dalla memoria del processo, per poi utilizzare l’indirizzo della funzione estratto per preparare la fase successiva dell’attacco. Dopo l’invio dell’ultimo byte della richiesta corrispondente, il server ha eseguito il comando della shell in circa 1,6 ms. I risultati sono stati confermati anche dal ricercatore della società Expel Marcus Hutchins , che monitorava i messaggi relativi allo sfruttamento riuscito di PHP2Shell . Le vulnerabilità CVE-2026-109618 e CVE-2026-109619 , riunite sotto il nome PHP2Shell, sono state corrette dal team di sviluppo di PHP il 21 ottobre. Prima della pubblicazione degli aggiornamenti, le informazioni sulle vulnerabilità e alcuni exploit dimostrativi sono apparsi in pubblico, ma gli sviluppatori affermavano che le varianti pubblicate non funzionavano. Le aziende Cloudflare, Hadrian, watchTowr, Previdian e Patchstack hanno segnalato anche tentativi di attacco che, in quel momento, non portavano a uno sfruttamento riuscito. Gli esperti di Amazon Threat Intelligence hanno rilevato i primi tentativi di attacco già il 17 ottobre, quattro giorni prima della pubblicazione delle correzioni. PHP è utilizzato in circa il 70% dei siti web su Internet. Secondo le stime di VirusTotal , sono presenti in pubblico più di 5,1 milioni di host con PHP, di cui circa 3,8 milioni hanno almeno una porta accessibile per potenziali attacchi . Pertanto, al momento, lo sfruttamento riuscito di PHP2Shell rappresenta una minaccia per un numero significativo di server che utilizzano questa tecnologia. L'articolo PHP2Shell è ora sfruttato in attacchi reali: ora inizia la vera caccia! proviene da Red Hot Cyber .

The US government's cybersecurity watchdog has confirmed attackers are exploiting both critical PHP2Shell vulnerabilities, giving federal agencies three days to patch the bugs that have wreaked havoc across the web over the past week. CISA added CVE-2026-109618 and CVE-2026-109619 to its Known Exploited Vulnerabilities (KEV) catalog on Monday, setting an October 29 deadline for federal civilian agencies to address the flaws. The move marks a shift from last week, when the agency warned of the danger posed by PHP2Shell but said it had not yet observed successful exploitation in the wild. Both bugs are rated 9.2 on the CVSS scale and can be exploited without authentication to run code on vulnerable PHP servers. That's bad news given how much of the web still relies on PHP, and just how many sites could be left exposed. Patches landed on October 21, but attackers had already beaten the maintainers to it. AWS spotted attempts to exploit the flaws as early as October 17, four days before the bugs were publicly disclosed. CISA's confirmation comes amid growing evidence that attackers are doing more than simply knocking on the door. On October 24, Perplexity security researcher Adel Karimi recorded 35 successful shell executions across three honeypots running PHP 8.4.26 under Apache mod_php. The attacks came from two IP addresses and used memory exhaustion and disclosure to achieve remote code execution. The attackers then tried to contact external servers using PHP, curl, and wget, although no additional malware was successfully downloaded. Karimi's findings were consistent with exploitation of CVE-2026-109618, but he found no evidence that the second PHP2Shell flaw was involved. He also warned that the honeypots used a favorable single-worker configuration, so the results don't necessarily reflect how reliably the exploit works against production servers. Still, attackers appear to be giving it a good go. Delft University's Threat Intelligence Lab has tracked more than 50,000 PHP2Shell exploitation requests from over 600 IP addresses across 70 countries. Of those, 171 addresses went beyond probing for vulnerable servers and started sending exploit code or malware droppers. CISA's confirmation also comes after some of the earlier reports of successful PHP2Shell attacks turned out to be rather premature. Sophos walked back its initial assessment after determining that the activity it observed amounted to scanning and failed attempts, while Palo Alto Networks withdrew claims linking the vulnerabilities to an intrusion at a European government agency. CISA has not disclosed which organizations have been compromised or provided details of the attacks behind its decision to add the flaws to KEV. The listing confirms that the agency considers both vulnerabilities actively exploited, but it does not confirm how many production systems have been successfully breached. For federal agencies, the clock is now ticking. CISA is also urging organizations outside the federal government to prioritize the fixes, although the deadline does not apply to them. Admins should update to PHP 8.5.12, 8.4.27, 8.3.36, or 8.2.35, depending on their release branch. Those running older, unsupported versions face the added headache of upgrading or obtaining vendor-supported fixes, while systems that cannot be secured should be taken offline until the risk is addressed. And with CISA now officially acknowledging exploitation, anyone still waiting for more proof before patching may be waiting a little too long. ®

Le vulnerabilità PHP2Shell non colpiscono direttamente Android e iOS, ma possono esporre dati e servizi delle app mobili attraverso backend PHP vulnerabili. L'analisi di NowSecure evidenzia i rischi per API e componenti di terze parti e la necessità di aggiornare i server per proteggere anche gli utenti mobile L'articolo PHP2Shell minaccia anche le app Android e iOS: il rischio nascosto nei server proviene da Cyber Security 360 .

Detectado un acceso no autorizado a CAPCOM ID que afecta a 11,7 millones de registros 27/10/2026 Mar, 27/10/2026 - 14:26 El 19 de octubre de 2026, Capcom detectó actividad sospechosa en CAPCOM ID, bloqueó el acceso y confirmó ese mismo día que un tercero había accedido sin autorización. El 20 de octubre, la investigación determinó que parte de la información de clientes había sido filtrada y que algunas contraseñas se habían modificado sin autorización. La empresa constituyó un equipo interno de respuesta y notificó el incidente a la Policía de Osaka y a la autoridad japonesa de protección de datos el 21 de octubre. La filtración afecta a 11.7 millones de registros con direcciones de correo electrónico y datos técnicos de las cuentas, como fechas de creación y último acceso, número de inicios de sesión y dirección IP. En varios casos también incluyó la fecha de nacimiento, el sexo, el país o región y el alias. Un tercero modificó las contraseñas de varias cuentas, ya restablecidas, y accedió a datos personales y de compra de algunas cuentas de e-Capcom. Capcom descartó datos de tarjetas y no confirmó la exposición de las contraseñas originales. El último estado oficial, publicado el 23 de octubre de 2026, indica que la investigación sobre el alcance del incidente ha concluido y que Capcom mantiene la supervisión de CAPCOM ID y los servicios relacionados. La empresa completó las medidas de emergencia, identificó y corrigió el método de ataque, y confirmó que los servicios y los juegos seguían disponibles. También comenzó a informar individualmente a las personas afectadas, habilitó canales de atención y anunció medidas para evitar incidentes similares y reforzar su seguridad. Referencias 22/10/2026 Capcom Notice and Apology Regarding Customer Information Affected Through Unauthorized Access 22/10/2026 BleepingComputer Capcom confirms data breach affecting 11.7 million accounts 23/10/2026 Capcom Update to Notice and Apology Regarding Customer Information Affected Through Unauthorized Access 23/10/2026 TechRadar Capcom data breach confirmed — around 11.7 million accounts thought to have been affected

CISA warns of PHP bug exploitation attempts, gives federal agencies days to patch The federal cybersecurity agency confirmed that two PHP vulnerabilities are being targeted, and ordered all civilian agencies to patch them by Thursday. The Cybersecurity and Infrastructure Security Agency (CISA) added the bugs to the Known Exploited Vulnerabilities (KEV) catalog on Monday evening but declined to answer questions about the nature of the exploitation or potential victims. Within the federal government itself, it’s unclear how many systems might use PHP. The vulnerabilities — CVE-2026-109618 and CVE-2026-109619 — caused global alarm last Tuesday due to the ubiquity of the PHP programming language across the internet. But throughout the week and into the weekend, experts tempered concerns of mass exploitation due to the lack of viable proof-of-concept (PoC) exploits. A spokesperson for the agency directed Recorded Future News to a section of the KEV rules that said CISA considers “active exploitation” to include both attempted and successful exploitation of vulnerabilities. Both Sophos and Palo Alto Networks have in recent days posted and then retracted claims of successful exploitation but several experts were able to discover ways to exploit the bugs by Sunday. In an updated advisory about the vulnerabilities, CISA urged organizations to identify and inventory systems running any version of PHP, apply the patch or take PHP-based systems offline if they cannot be updated immediately. In some cases, web application firewalls may provide some level of protection for a period of time, CISA added. The advisory links to guidance from PHP as well as government cybersecurity agencies in Australia, Canada, New Zealand, the U.K. and others. Despite the lack of confirmed successful exploitation, dozens of cybersecurity and tech companies reported thousands of failed attempts to use the bugs in attacks. PHP is used to build and run web applications and the vast majority of websites. Some estimates show that more than 70% of all websites on the internet use PHP. Dozens of governments and businesses took their websites offline last week in an effort to address the vulnerabilities. Experts have expressed deep concern that millions of PHP-backed websites are still running ancient versions of the language that likely cannot be updated. Censys created a PHP2Shell dashboard that says of the 42 million Internet-facing PHP services, more than 10 million have been patched since October 21. Jonathan Greig is a Breaking News Reporter at Recorded Future News. Jonathan has worked across the globe as a journalist since 2014. Before moving back to New York City, he worked for news outlets in South Africa, Jordan and Cambodia. He previously covered cybersecurity at ZDNet and TechRepublic.

You recognize the website. You’ve visited it before. You may even have it bookmarked. Then it asks you to do something unusual: install an update, allow notifications, or run a command to prove you’re human. Stop and check first. A website you trust can still display instructions you shouldn’t follow. Our researchers have documented attacks in which criminals hacked legitimate websites and used them to deliver fake verification pages that trick visitors into installing malware. Within the same week, serious problems emerged in several parts of the web’s security infrastructure. Attackers were exploiting two flaws in PHP , researchers disclosed a critical flaw in Brotli software used by Node.js, and eight compromised security certificates raised concerns about how browsers and apps verify websites. The incidents have different causes and levels of risk, but their timing makes this an unusual cluster. PHP is used by about 7 in 10 websites whose underlying programming language is known. Node.js is used by 7.4% of websites with an identified web-server technology, according to W3Techs . Both run websites behind the scenes, so flaws in them can put the sites that rely on them at risk. Most browsers have blocked the certificates, though updates may still be needed for other software and devices. These problems don’t mean you need to stop browsing. But keep your software and security protection up to date, and be wary of unexpected requests. How to stay safe when browsing Check the website’s address, but remember that even the genuine site may have been compromised. The important question is whether the page’s instructions make sense. A familiar website may earn your visit, but that doesn’t mean you should automatically let it run software on your device. In documented campaigns, malicious instructions appeared on legitimate, hacked WordPress websites, not just lookalike domains . Safer. Cleaner. Ad-free browsing. INSTALL BROWSER GUARD A secure connection doesn’t guarantee that a page is safe, either. HTTPS protects the connection between your browser and the site. Browser protections against dangerous content are a separate layer. A page asking you to install software or enter sensitive information still deserves scrutiny, even when the connection is encrypted. Ask yourself: “Does this request make sense for what I came here to do?” Reading an article shouldn’t require opening PowerShell. Watching a video shouldn’t require following a website’s instructions to “repair” your computer. These are familiar themes in ClickFix attacks , which disguise malicious commands as routine verification or troubleshooting steps. You can’t patch someone else’s web server, but you can keep the software on your own device updated. Turn on automatic updates for your operating system, browser, and applications where available, and don’t repeatedly postpone installing them. Updates fix security flaws that criminals could otherwise use to access your files or accounts. Keep your browser’s phishing and malware protection enabled, too. Free browser extensions like Malwarebytes Browser Guard warn about known dangerous websites, malicious downloads, and clipboard hijacking. Treat those warnings as a reason to leave, not as another obstacle to get round. These checks are a useful layer of protection, but they can’t certify that every unflagged page is safe. Use strong, unique passwords stored in a password manager , and enable multifactor authentication on important accounts. These measures help protect your accounts from unauthorized access. If a request involves running code or making changes to your device, verify it independently. If a website claims your browser needs updating, close the prompt and check through the browser’s own settings. If it says an account or service needs attention, check through the official app, help page, or support channel that you open yourself. Criminals often present the harmful step as the thing that will let you do what you came to do: fix the connection, enable the player, or complete the security check. The frustration of being blocked can make it tempting to follow their instructions. Use up-to-date, real-time anti-malware protection on your devices to help stop malware from wreaking havoc or stealing your information. Watch for unexpected content, downloads, redirects, and repeated login requests, even on familiar sites. If something looks wrong, leave the page. If you’re unsure, use Malwarebytes Scam Guard to check whether a request may be a scam and get possible next steps. From reporting threats to removing them. Cybersecurity risks should never spread beyond a headline. Keep threats off your devices by  downloading Malwarebytes today .

The U.S. Cybersecurity and Infrastructure Security Agency (CISA) has added the PHP2Shell vulnerabilities to its catalog of actively exploited security flaws and ordered federal agencies to patch their systems by Thursday. [...]

The U.S. Cybersecurity and Infrastructure Security Agency (CISA) on Monday confirmed active exploitation of the recently patched PHP2Shell flaws by adding them to its Known Exploited Vulnerabilities (KEV) catalog. The PHP vulnerabilities, both rated 9.2 on the CVSS scoring system, facilitate unauthenticated remote code execution on affected deployments - CVE-2026-109618 - An out-of-memory

多くのWebサイトを支えるPHPに攻撃コードが存在する重大脆弱性が見つかり、2026年10月21日夕方から夜にかけて、各社が一斉に緊急メンテナンスへ踏み切りました。現職総理がSNSでパッチ適用を呼び掛ける異例の事態から、企業と個人は何を学ぶべきでしょうか。

An unknown threat actor has infected 953 online stores, most of them running Magento, as part of a long-running campaign active since July 2025. According to Dutch e-commerce security company Sansec, the activity is designed to add a small piece of code to the store's pages that, when visited by unsuspecting users, serves malicious JavaScript loader code through Magento CMS blocks. "When you

PHP has rebuilt its official Windows packages for PHP 8.2 through 8.5 to fix CVE-2026-111497, a flaw in the Brotli compression library that the packages include. The flaw can let an attacker corrupt memory and potentially run code. PHP says the flaw can be reached through the cURL extension when the extension decompresses HTTP responses automatically. cURL leaves that off by default, but

A UK-based developer and pentester has claimed a $2,000 Bitcoin prize for demonstrating the exploitability of the PHP2Shell vulnerabilities that melted the internet last week. Jaydip Modhwadia, 26, otherwise known as “Killa,” claimed the prize set by James Pavur, who launched the "Steal My Bitcoin" site on October 24. Pavur launched the CTF (capture the flag) challenge to prove that the PHP2Shell exploit was not as easy as those in the cybersecurity community claimed it to be, promising to award $2,000 in Bitcoin to anyone who could achieve Remote Code Execution (RCE) on his website. "My Bitcoin was stolen after 19.28 hours," the website now says, after Modhwadia claimed the prize, although the real time taken is thought to be less than three hours. Soon after Pavur launched the CTF on Saturday, prospective flag-catchers complained that the website he set up, which served only static HTML, was not built in a way that allowed the PHP2Shell exploit to achieve RCE. The web page was running a vulnerable version of PHP, but the exploit path required a vulnerable website to serve a PHP file for flag-catchers to use as a hook – something that Pavur seemingly updated at around 1300 UTC on October 25. Modhwadia achieved RCE on the website, exposing a PHP endpoint, at 1547 UTC. After an error from Pavur placing the wrong wallet key on the server, the CTF creator sent Modhwadia his award, which the community upped to $2,000 from Pavur’s initial $500. The pentester published a write-up of his method, a single-file Python script he says requires 20 HTTP requests "at most" to fully execute. Speaking to The Register, Modhwadia also confirmed that he got the flag in "around three or so hours in total." He said he followed the news about the competition, "but didn't attempt it until it gained significant notice." If he had attempted it before Pavur introduced the endpoint, he may have struggled. For hours, bug bounty hunters were trying to access the website to attempt the challenge, as news of the CTF had exploded across tech circles. "The fact that it took 19 hours was because after it went popular, the entire site became basically unusable for anyone at all," Modhwadia added. The challenge saw a huge number of attempts, despite Pavur's decision to introduce a prohibitive 1MB request limit on Nginx. Alon Gal, co-founder and CTO at Hudson Rock, commended Modhwadia's work, but added that his success achieved in just a few hours should not be taken to mean that the same attack could be automated at scale. He said: "Does this mean autonomous AI agents can now compromise arbitrary PHP servers at scale? No. This was a sophisticated, target-specific exploit. "But it does demonstrate that PHP2Shell can be weaponized against a live target, even with meaningful technical constraints." Modhwadia's proof of concept is not the first to prove PHP2Shell is exploitable, but it falls under the more advanced category. Early signs suggested that Address Space Layout Randomization (ASLR) on a vulnerable server would prove a significant barrier to real-world exploitation, and the pentester’s solution bypasses it, along with the others that were disclosed recently. Spencer McIntyre, director of exploit development at VulnCheck, told The Register last week that attackers are finding new ways to exploit PHP2Shell, and "are clearly spending time (and tokens) on this bug." Initially, experts said exploit code was being found online hours, or even days, before the vulnerabilities were disclosed publicly, which led to millions of exploit attempts, although it was too early to determine the efficacy of these on real-world systems. Scores of websites were taken down for maintenance last week as organizations raced to protect themselves from the attacks, which may or may not have proved successful. Modhwadia said he donated a portion of the prize he received to the Lupus Foundation to raise awareness about the condition, from which he also suffers. ®

For the latest discoveries in cyber research for the week of 26th October, please download our Threat Intelligence Bulletin. TOP ATTACKS AND BREACHES Japanese cloud hosting provider Onamae Desktop Cloud has confirmed a cyberattack in which intruders compromised its infrastructure and installed malware on customer servers. More than 26,000 servers were potentially affected. The provider began shutting down customer environments on October 21 to contain the intrusion and prevent further unauthorized activity. India’s state-run State Bank of India, serving more than 500 million customers, disclosed a data breach after 3,897 customer records appeared online. The exposed information reportedly included contact details, residential addresses, birth dates, bank profiles, loan records, and identity-verification documents. The bank reported no disruption to core services. WordPress backup developer TeamUpdraft has suffered a cyberattack after intruders accessed its website and potentially exposed customer information and management-service connection keys. Attackers subsequently abused compromised UpdraftCentral keys to install backdoors on WordPress websites during an 18-hour campaign on October 18 and 19. LiteLLM, a widely used open-source AI gateway, confirmed an October 21 supply-chain attack in which attackers used stolen developer tokens to publish malicious packages and Docker images. The compromised version 1.107.0 was designed to steal cloud credentials and AI service secrets, with attackers subsequently testing stolen AWS credentials. AI THREATS Check Point Research uncovered how AI-enabled antidetect browsers allow operators to manage thousands of deceptive accounts while evading platform safeguards. Tools including Kameleo, AdsPower, and MultiLogin facilitate account takeovers, financial fraud, and automated distribution of AI-generated content, supporting large-scale influence operations across social media platforms. Researchers observed affiliates of INC and The Gentlemen ransomware groups using AI agents to conduct human-approved cyberattacks. The operation targeted 62 organizations by exploiting remote-access systems and compromised credentials. Victims were concentrated in the manufacturing, energy, healthcare, and pharmaceutical sectors, primarily in the United States. Researchers analyzed a cybercriminal operation that used multiple AI assistants to plan and execute different types of malicious activity. The attacker relied on AI-generated scripts and reconnaissance reports to develop attack capabilities. Exposed operational records revealed how AI tools supported campaign planning, technical execution, and adaptation across different targets. VULNERABILITIES AND PATCHES Critical PHP vulnerabilities CVE-2026-109618 and CVE-2026-109619 have been used in widespread exploitation attempts that could enable remote code execution. Attack traffic reportedly increased from thousands to millions of attempts following disclosure. As of October 23, approximately 97.5% of publicly visible PHP instances did not indicate patched versions. Check Point IPS provides protection against this threat (PHP Remote Code Execution (CVE-2026-109618, CVE-2026-109619, CVE-2026-115560(( Oracle has released its October 2026 Critical Patch Update, addressing 1,209 unique vulnerabilities through 1,295 security patches across 33 product families. The update includes 95 critical CVEs and affects widely deployed enterprise products, including Fusion Middleware, E-Business Suite, MySQL, and Java SE. GitLab has fixed CVE-2026-110264, a critical vulnerability with a CVSS score of 10.0 affecting Community and Enterprise Editions. The integer overflow flaw could allow unauthenticated attackers to execute arbitrary code remotely on affected servers. The vulnerability affects versions before 18.11.13 and several 19.x releases. A critical privilege-escalation vulnerability, CVE-2026-114625, affects on-premises Arista VeloCloud Orchestrator deployments. The flaw carries a CVSS score of 9.4 and allows authenticated users, including those with read-only access, to obtain operator-level permissions. Successful exploitation can expose restricted management functions, and the vulnerability has been exploited in attacks. THREAT INTELLIGENCE REPORTS Check Point Research has profiled Aokigahara, a newly identified infostealer targeting credentials and session data associated with AI applications, developer tools, and cloud platforms. Targeted applications include Claude, ChatGPT Desktop, Cursor, and GitHub Copilot. Stolen information may include authentication tokens, account credentials, and other sensitive application data. Researchers revealed that U.S. federal investigators suspect an executive at a ransomware negotiation company assisted the ShinyHunters extortion group in operating its victim disclosure website. The site reportedly listed nearly 100 organizations between May and October 2026. Researchers mapped Lazarus’s Operation FlashHole, a cyberespionage campaign targeting organizations in South Korea’s software, construction, and telecommunications equipment sectors. Attackers used tailored phishing messages and fraudulent portfolio websites to deliver malware. The campaign exploited trusted financial-security software to execute malicious components. Researchers have uncovered a large-scale campaign by threat actor k0t targeting Fortinet FortiGate, FortiWeb, and Palo Alto Networks GlobalProtect devices. Attackers exploited vulnerabilities and weak credentials to establish persistent access and steal information. The operation exposed more than 70,000 credentials and showed possible connections to ransomware groups. The post 26th October – Threat Intelligence Report appeared first on Check Point Research .

Siemens, Schneider Electric, ABB and others have confirmed that some of their products are affected by the PHP2Shell vulnerabilities. The post Industrial Vendors Check Products for PHP2Shell Vulnerabilities appeared first on SecurityWeek .

Disponibili pacchetti di aggiornamento e istruzioni di mitigazione per IceWarp Server, suite di posta elettronica aziendale e collaborazione, al fine di fronteggiare le vulnerabilità critiche note come "PHP2Shell" (CVE-2026-109618, CVE-2026-109619 e CVE-2026-115560) presenti nell'interprete PHP integrato nel prodotto.

This2Shell, That2Shell, Everything2Shell. That's pretty much how the last week went. Critical bugs that let attackers run code remotely are showing up everywhere. Hackers are scanning for targets, some flaws are already being used in attacks, and security teams have more urgent patches than they can keep up with. And that's not even the full story. A leaked key led to a software supply-chain

Attackers successfully exploited the PHP2Shell flaws against honeypots, launching 35 shells from two IP addresses on October 24. The post PHP2Shell Exploitation Moves From Probes to Working Shells  appeared first on SecurityWeek .

We've spent the past several decades using duct tape, string, and chewing gum to chain the world's computers together into this thing we call the internet, so there's really no good reason to be surprised that most of it is full of software containing vulnerabilities that are practically just as old. You can listen to the latest episode of The Kettle right here on this page, as well as on Spotify, Apple Music, or YouTube. Those platforms also let you subscribe to Kettle, so you are always notified when the latest episode goes live. The world is still reeling from the PHP2Shell revelations that hit the news cycle this week, and on The Kettle there's no better topic for host Brandon Vigliarolo, cybersecurity editor Jessica Lyons, and FOSS reporter Liam Proven to tease apart. Join us to discuss what exactly is going on, how AI was key to finding another issue no human likely ever would have discovered on their own, and why exposing more bad code in the backbone of the world's computers might be just what we need to rethink the whole thing for the better. A lightly edited transcript follows: Brandon (00:01) Hi everyone, and welcome to the latest episode of The Register's Kettle podcast. I'm your host, Reg reporter Brandon Vigliarolo. And hey, there's only one thing we could focus on for this week's episode, given all the hubbub around it, and that's the PHP apocalypse. It turns out most of the internet is running software that could allow remote code execution on host systems via a pair, or as of today apparently three, vulnerabilities that have come to collectively be known as PHP2Shell. So that's not great. With me to talk about this is our security editor Jessica Lyons and open source reporter Liam Proven, who has a few things to say about PHP itself and why it's probably not surprising we're finding ourselves in this mess. Thanks to you both for coming on. Liam Proven (00:43) Absolute pleasure. Jessica Lyons (00:43) Nice to be here. Brandon (00:44) So Jess, let's start with the basics. What is this? How big of a problem is it? And where do we stand on getting things fixed? Jessica Lyons (00:51) Great. The short answer is it's a very big problem. So we have these two related memory safety vulnerabilities, and they are in the PHP core. Collectively they're called PHP2Shell, and they affect every version that's been released in the last decade affected by one or both of these, going back to about version 5.4. So the general consensus is this is about 70 percent of all of the websites on the internet are running this code. So it basically affects everyone at this point. What happened here is that this dates actually back to August. An independent researcher first spotted this, and then we can talk a little bit more later about who found more of the exploits and what the (PHP) Foundation did with that. But so he found this vulnerability. There was a coordinated disclosure process with the PHP Foundation, and then that broke a little bit starting over the weekend, and then onto Monday, there were some leaks. There was a video posted that purported to show this exploit. And so we get this emergency warning from the PHP Foundation late Monday saying, "Hey, we are going to be releasing these emergency patches, so everybody get ready so you can implement them as soon as possible. It's very serious." So by Wednesday, they did release these, and there's this mass attempt to patch before any of the attackers get a hold of this and are able to attack websites with it. And one of the issues too is that some websites are running really, really old versions and so they aren't able to patch. So they're just sitting there, these legacy servers are still vulnerable. Brandon (02:52) So there's no direct update path for those old versions, right? It's basically shut this down and reinstall it kind of thing. Jessica Lyons (02:59) Exactly. So basically they're both these memory corruption vulnerabilities and by exploiting them, an attacker can kind of shape the memory that PHP trusts. And then they can use that to hijack what happens next. And that can mean remote code execution. They can take over the websites, they can steal data. And so people are visiting these websites they trust and they don't realize that the underlying code is stealing their data or delivering malware to their computer. And again, this is potentially 70 percent of the internet. So it's a big deal. Brandon (03:36) Quite a few sites were offline. I know even some big services. I stopped playing because I had a baby, but I used to play Final Fantasy XIV pretty religiously. And I know that the entire login server was offline a couple days ago Jessica Lyons (03:50) Right. Brandon (03:50) They were like, "You've got to fix this. Sorry, no one can play the game. If you're not logged in right now, you're not getting logged in for the foreseeable future." It's just insane how much of the internet was affected by this. Now It's under exploit, is that correct? But maybe not successfully exploited yet? Jessica Lyons (04:11) Right. So after the patches were released on Wednesday, later Wednesday, AWS came out and said, "We've seen exploitation attempts at least four days before the patches were released." So that kind of caused another frenzy that, "My God, it's under attack, the whole internet is on fire." There haven't been any successful attacks to date. There's been a ton of attempts. There's a lot of POCs; some work, some don't. But as of Friday, according to the Foundation and according to all of the security experts that I've spoken to, we haven't seen any evidence of successful exploitation. I don't think that means we're in the clear. I think it just means it's taking a while for people – and honestly AIs – to develop successful attacks, but that's where we are right now. Brandon (05:06) Because it's a complicated attack chain, correct? Jessica Lyons (05:10) Right. Yes. Brandon (05:11) So basically, right. This is not working yet, but especially with some of these older websites that are running older versions of PHP that are going to have to take a more thorough approach to getting this fixed and possibly going down for some time, this could be one of those problems that remains serious for a while. And let's not forget, 70 percent of the websites on the internet, that's almost three-quarters of the entire internet. I don't know how many hundreds of thousands or millions of sites that is, but some of those are probably never going to get patched. Jessica Lyons (05:41) Right. Exactly. Brandon (05:43) Just the way it goes. Right. This is going to be the sort of thing that we end up hearing about months or years from now. Jessica Lyons (05:49) I would say years. Brandon (05:53) I'm sure there'll be some bank somewhere that eventually ends up getting – we'll hear about some breach disclosure letter from the state of Maine in four or five years. Jessica Lyons (06:02) And local governments, federal and state governments, I think these are the ones that we're going to be hearing about quite a while from now. Brandon (06:09) Because that's one of the things I was thinking about even for me in my tiny little town in northern Michigan. I wonder if my township or the county is going to be all over it to update their PHP server. Does their IT guy, who probably is a retired dude who lives in the area, even know this is a problem? It really is one of those things that is a big deal, but if you're not kind of following the news on this, it could probably go completely unnoticed. And for many websites, I'm sure it will. Jessica Lyons (06:37) Right. Exactly. Brandon (06:37) So, it's pretty crazy. Liam, you're working on a story, I think, as we are recording this, about some of the history of PHP and how it really probably wasn't very well designed or intended to become so ubiquitous on the internet. What's going on there? Liam Proven (06:53) I've seen one angle on this, which is people saying, "This is 1990s code and it has 1990s problems," which is one way to look at it. But I'm a 1980s internet guy; that's when I started exploring it. My primary email address is older than the web, and it still works. My gods, it gets a lot of spam, but it still works. I've watched the rise and rise of PHP since the first releases. Now, I have no personal interest in web development. I can program, but I don't because I'm really bad at it and nobody needs to have my code inflicted upon them. The guy that wrote PHP in the first place, Rasmus Lerdorf, is my age. I've never met him; I'm sure he's a nice guy. But he said in a very early interview about it, "I really don't like programming. I built this tool to program less so that I could just reuse code." And that was about 1993. He built a little tool that allowed him to put macros in HTML for his own website, and it's just grown. In a later interview, he said something along the lines of, "I don't know anything about writing programming languages. I'm just improvising this as I go and people seem to like it." It originally stood for "Personal Home Page," I think, and later was given a recursive acronym of "PHP: Hypertext Preprocessor." This is a programming language that you mix in with the HTML of a website. It predates the modern model of building websites where a database contains the text and a content management system of some kind assembles on the fly the pages that each person sees. This is an older model where you're running programs that are part of the markup language, which was not a good idea, but that was how he did it. There was a lovely blog post. I've got an old friend who's an extremely skilled and talented programmer who has built a career on PHP, and he said to me, "Look, those criticisms that you've mentioned are of the really early versions and it's changed now." And if he hears this, he's going to be cross with me. But my favorite summary was from a blog called Eev.ee way back when that called PHP "a fractal of bad design." Whatever level you look at it, it was done badly. If you look at the whole plan of "let's just intermingle program code in with the markup language," not a good idea. If you look at the details of how it was implemented, not a good idea. If you look down at low-level details of how the functions return values, not a good idea: inconsistent syntax, inconsistent functions, functions that do really weird things, by default no stack traces, not great error reporting. Now, I'm sure a lot of this has been papered over now, but really there is one reason PHP is still around and still so big: Zuck. Facebook was built in PHP. And Facebook makes lots and lots of money and it's been throwing money at making PHP faster and more reliable and more scalable for decades. Brandon (11:03) Have they been big contributors to it? Liam (11:06) Yeah. They even built a compiler for it, which I suspect is still in use. Now, how much of Facebook today is in PHP? I don't know, possibly none, but for a long time basically the world's biggest and busiest public-facing website that wasn't owned by Google – only because Google have failed to ever make a successful social network – was built on PHP. And it's big, it's complicated. Like Linux itself, nobody fully understands how the whole thing works anymore and hasn't probably for decades. And now people have got bots that they can throw against it and ask them to analyze it. I think this is probably just the first, and I think there's going to be many more. A friend of mine who's a senior developer had a look at the patch, and he's not a C guy, but he said – I'm quoting from comments on Mastodon – that the patch to the current version is 13,000 lines of C. That's a doozy of a patch. Brandon (12:17) That's huge. Liam Proven (12:20) A bunch of people have been working like crazy for quite some time. Some people who've looked at this say it looks handwritten to me. Others have said, "No, I think this is bot-generated." I think the truth is probably a bit of both: some from one, some from the other. Brandon (12:32) Bit of both. I mean, you can't pump out thirteen thousand lines that quickly and have it tested. God, I hope they tested it. Liam Proven (12:41) Right. But that's just for the current version, and this hole affects every published version. So if they do manage to fix this one, how long till the next one comes along? Because I think there's going to be – Brandon (12:56) Especially with the speed at which vulnerabilities are being discovered now. I feel like every time I turn around, I've written one Patch Tuesday article in the past few months, and that one broke the previous two records. And I think since then every month has included more patches, and a lot of those are probably – Jessica Lyons (13:14) October at this point is the record: over a thousand for Microsoft alone. So, yep. Brandon (13:21) That's insane. Like you said, it is a fractal of bad design all the way down, and is going to probably have more vulnerabilities discovered. Jessica Lyons (13:32) Right. Brandon (13:32) Seventy percent of all websites on the internet are using this. What can we do? Are we stuck? Liam Proven (13:35) Well, there's a reason for that, and it's one that doesn't get talked about an awful lot: Facebook aren't the only people that use it extensively, because WordPress is also built on PHP, and it's far from alone. Another senior Linux techie friend of mine gave me a free shell account on the machine that he runs for a few friends years ago, and I thought of resurrecting my old 1990s hand-coded HTML webpage for fun. So I found it on the Internet Archive and found a tool to scrape it and turn it back into HTML again. I looked at some CMSes and asked him if there was any CMS on the machine. He went, "No." And I went, "Well, would you install one?" He went, "No." "Well, why not?" He said, "Well, all the big ones are implemented in PHP, and I won't let that near any server I run." "Well, that's a bit dramatic, isn't it?" And he goes, "No, that's pragmatic. I run a bunch of public-facing servers on my own, and this is how I keep them secure. No containers, no Docker, no PHP, nothing built in any of these technologies." And I went, "Wow, what about..." So I went looking for non-PHP CMSes. There are a lot of CMSes out there. I got a commission about a decade ago to write a comparative assessment of the CMS market versus a company's proprietary Windows product. I went and did a survey and came back and said, "I've found 1,300 so far." And they said, "OK, we can give you five thousand words instead of a thousand words." And I said, "You realize I'm going to have to go and look at 1,300 pieces of software here. Even if I only write three or four words about each one, 'Mostly harmless,' I'm still going to have to look at over a thousand bits of software. It will take me a year." And they went, "Well, how can how can we do it quicker?" And I said, "You can't. I cannot do this survey you want. Give me a full-time job and I'll get it back to you in a couple of years' time." I found a few CMSes that weren't built in PHP. Most of those were built in Ruby instead. And he went, "Yeah, I'm not keen on having that on my server either." So it's not even a case of people that have PHP deployments needing to update. They don't know. They built it on something else which was built on something that was built in PHP. Jessica Lyons (16:15) I was just going to say, Liam, you said, "How long until the next one happens?" And we found out today from the PHP Foundation that there is a third one. They won't be pushing an emergency release for this. They said it'll be published with the next regular release cycle. The Foundation told me that this one, quote, "requires a very unlikely combination of configuration and specific PHP application code, which we do not expect to occur in practical use." So, there's already another one. Liam Proven (16:45) So weeks then. Brandon (16:47) Yeah. Jessica Lyons (16:48) I mean, and even with this, it's hard to exploit. You can mitigate it with a configuration setting. But that was part of the thing we've heard with these other two. And then we did have researchers yesterday who developed this new exploit; this was Vulncheck. And that shows how even ASLR can be bypassed to attack these vulnerabilities on x86 machines. So saying it can be fixed with a configuration setting isn't always a guarantee. Brandon (17:25) That brings me kind of to the elephant in the room of this whole story: AI. because of course it all comes back to AI nowadays. OpenAI and two other security firms reported this. I think Jess, one of your stories or one of the ones Lindsay wrote said that they all used AI to find this, right? Jessica Lyons (17:49) Right. So the companies: Calif, they are a newer startup doing AI pen testing and they're part of OpenAI's partner program, so they used OpenAI models working with OpenAI to find this. And then independently, Wiz, which is owned by Google, also did. So this happened back in August, and then they have been all working with the PHP Foundation on the patch since that point. They have all said these are vulnerabilities that probably wouldn't have been found by humans alone. By all accounts, they've existed for decades and wouldn't have just been found by human researchers. Brandon (18:34) Right. So either these are things that have never been discovered and would have never been exploited theoretically – the exploit path is complex, they're not obvious vulnerabilities, so they needed an AI to find them – or perhaps this is the kind of thing that was known about but was privately held in the hands of some bug hunting company that sells exploits to governments. Who knows? Maybe that's the case. I remember talking to a guy one time at Black Hat who basically said his company's in the business of finding really sensitive vulnerabilities and then selling them to the highest bidder. So there are companies like that that exist. So there's probably plenty of vulnerabilities in software that are not well known that governments and high-level functions are aware of. But in this case, this probably wasn't the case. This is an incredibly difficult-to-find vulnerability. I've seen a lot of chatter online in the past few days about how the internet's on fire and the AI bug-pocalypse has arrived. It seems like we're having another case of people getting all freaked out because this is the end of time, history is over, and AI is going to kill us all. It just seems to me like this is another example of: well, maybe not. This has been getting hammered by potentially bad actors or pen testers, and no one's managed, as far as we know, to successfully use this yet. Is this as serious as it seems, or is this another case of a serious vulnerability that is so complicated and convoluted that it's not really going to be that big of a deal? Liam Proven (20:25) I want to note parenthetically that you described OpenAI as a security company, and if I had been drinking coffee, that would have been very bad for my keyboard. Brandon (20:32) Okay, whoops. Let me take that back. Jessica Lyons (20:31) Ha ha ha. Liam Proven (20:36) Calif is interesting because I just wrote about them. They found a hole in OpenBSD, and there aren't many of those. And only about a week ago, they found a hole which they dubbed "Big Fish" in OpenBSD, and it was just days before OpenBSD 8 shipped. It looks like that had been there for 37 years, which is a neat trick because OpenBSD was founded 30 years ago. So this is in – going to pronounce this carefully – Berkeley Software Distribution Unix in the eighties. But there are doubtless more, and I'm an arch AI skeptic. Some people will claim that this will be the sort of problem that you can solve with AI by getting it to rewrite your stack. Well yes, but then you'll replace it with a new stack that nobody ever understood any of. But there are ways to design, host, and run websites, forums, and chat channels without using any of this stuff. And it could be a net positive if holes like this keep getting found that people will be forced to go back to – sounds crazy, but – static websites serving pre-written code off a disk. One of my favourite websites – recently I discovered there's a whole chain of them, and I hope you won't mind me swearing; maybe you have to beep me. But there's a marvellous website called "This Is a Motherfucking Website and It's Perfect." And recently somebody rewrote it and the new one looks almost identical: "This Is a Modern Motherfucking Website and It's Perfect." He's written it with more CSS or something, but apparently there's a whole chain of these things and they are extremely low on programming code. They contain interactive elements that you can do with just HTML, and you don't need a whole web framework behind it. And the same AI companies are busily scraping the whole web multiple times a day to feed their training engines. Maybe we just have to suck it up, scrape some of these big websites, and redo them as simpler tech with fewer interpreted languages. We are all collectively victims of the sunk cost fallacy. We've got millions of websites. We spent billions and trillions of dollars building all this. We can't just throw it all away. Well, maybe you have to. Brandon (23:27) Sunk cost was something that kept coming to my mind as I was writing up the script for this episode and just thinking about this. It seems like a whole big case of, "Well, all the websites in the world are now on PHP, so I guess we're stuck." Liam Proven (23:42) We have a script? Brandon (23:46) Well, not a formal script, just notes. Liam Proven (23:48) Haha. Well I didn't get the memo. Jessica Lyons (23:50) I think that's part of the problem though: it illustrates this larger issue with AI in general. AI bug hunting and exploit detection kind of illustrates this bigger problem about the internet, especially these legacy systems that underpin government services and critical infrastructure. It is literally held together by duct tape and string. So it's a massive problem. Again, it takes some work to actually make anything of these vulnerabilities and chain them together. AI is getting better at that. So whether or not this ends up being the end of the world for the internet as we know it, it does illustrate a real problem. Brandon (24:42) Like Liam said, maybe this is the sort of catalyst that the wider internet community needs to realize that these systems – this duct tape and string – simply won't keep working forever. We need to maybe modernize all the underlying infrastructure and make it simpler and less kludged together with all these different things over the years. PHP is poor design all the way down, right? It's like: well, maybe we need to tear it out and start over. Even if these vulnerabilities are impractical to exploit and hard to find, the fact that they're being discovered does illustrate that most of our code is a mess. Liam Proven (25:28) I am reminded , the other day I was talking in the comments about A/UX, Apple's original Unix for the Mac, and Apple paid another company to develop A/UX because the US military had a tick box on the form that said to buy systems, they have to be able to run POSIX. The US Army at one point hosted its website on Classic Mac OS. And it wasn't exactly security by obscurity. They said virtually all web server attacks in the mid-1990s were based on getting a remote shell, and Classic macOS didn't have a shell at all, anywhere. There was no way to get a remote shell because you couldn't get a shell if you were sitting in front of it. So they said, "They try and inject bits of x86 code: well, it's not an x86. They try and get a shell: it hasn't got one. They try and get it to run scripts: it doesn't run scripts." They said, "We just sit there and watch people throwing themselves at it. All the best attacks, and none of it works because the operating system's kind of too primitive to do any of that stuff." I don't believe many customers actually ever used A/UX, but it got Apple some lucrative deals. Maybe we're going to see a new trend of super primitive, super basic websites. There'll be a new difficulty in trying to scale the things because Kubernetes expects a lot of this to be dynamically generated by microservices. But bring it on; I'd love to see that. Brandon (27:09) That's a Kubernetes problem, right? Liam Proven (27:12) Yeah. Brandon (27:14) I feel like I would love a simpler internet. It would be amazing if I could just wake up in the morning, go to a news site, and just get the headlines. So often, I feel like – and I think The Register is good at having a relatively simple design, but – so often I feel like the news aggregators that I go to... I look for ones that are as minimal as possible. I look for websites that are simple. I don't need all this in-your-face stuff; it's not necessary. I think we probably are all pretty sick of it in a lot of ways. Jessica Lyons (27:49) But do we really think this is going to happen though? Brandon (27:52) No. Jessica Lyons (27:53) I feel extremely pessimistic about this. I think it's much more profitable to just keep marketing solutions to the problem as opposed to a safe coding overhaul. Brandon (28:04) Unfortunately. Liam Proven (28:06) Geopolitics might yet get in the way. I wrote a piece about OpenEuler, one of the big Chinese enterprise server Linuxes, and one of only two companies actually showing off an OS at the Open Source Summit. The other was also Chinese: OpenKylin, which is more desktop focused. China makes its own chips, China makes its own operating systems, and it's got its own programming languages. They're all open source, taken from European and American developed software by and large, but they could still invade Taiwan and cut off much of the world's chip supply. And suddenly it won't just be that memory is way more expensive than it used to be; it will be that you can't get more memory anymore and you have to keep using 10-year-old chips. And people will be potentially forced to find ways to keep getting more out of the same hardware until we can build new chip fabs, which will take a lot of time and a lot of money. And then quite possibly they'll get blown away in a climate-change-induced hurricane and then we'll have to start again. So, I hope they're going to start building them in the north of Norway and places like that. But yeah we've got bigger problems coming down the pipe and it's all a giant snowball of superficially unrelated things: AI attacks on overcomplicated stacks on one side, and the other kind of attack which involves whistling noises and large explosions on the other side, which cuts off the hardware market. It's hard to plan for this, but nobody's even trying yet. Brandon (29:52) Who would have thought a talk about a PHP vulnerability would have turned into geopolitical chaos and the endof modern technology as we know it? Break out the sundial, people. Liam Proven (30:07) Excuse me, I've just got to go and wind the web server. Hang on. Brandon (30:11) All right, guys. Thanks for coming on. I think this was a really valuable discussion and it shows just how interconnected all these issues in tech are right now. I mean, it is interesting how we're kind of hurtling toward something in a lot of ways. AI will surely be a part of it, as will expensive chips and lots and lots of vulnerabilities being found every day. Hopefully we'll still be here to cover it as that continues to happen. Jessica Lyons (30:40) If AI doesn't kill us. Brandon (30:41) Right. If AI doesn't kill us all. Well, if it doesn't, we'll be here on the Kettle to talk about it. And we hope that you, from whatever bunker you're hiding in, will join us on future episodes. Liam Proven (30:53) Yeah, we'll be publishing a telephone number so you can phone into future Kettle episodes. Brandon (30:59) All right, folks, we'll talk soon. ®