Why PHP2Shell Became an Emergency Response: Risks Revealed by Generative AI and Government/Corporate Actions

About this article
This article was created using an automated generation workflow leveraging generative AI. Risks, discovery timelines, alerts, and countermeasures were compiled based on announcements from PHP developers, the PHP Foundation, OpenAI, security research firms, and public institutions domestically and internationally. Primary sources and official PHP supplementary notices were re-verified on October 25, 2026. Specific sites, individual server configurations, and operational logs are not included.

Verification Status: 🧪 Checked status displays using primary source materials, command syntax, and test data. Update procedures on a live Ubuntu instance and diagram rendering on WordPress remain unverified.

On October 21, 2026, the development team for the PHP programming language released patched versions addressing two critical vulnerabilities, collectively referred to as "PHP2Shell". The severity is rated at 9.2 on the CVSS v4.0 scale. Under certain conditions, attackers can execute arbitrary code on web servers without authentication. Because this affects PHP itself as the underlying platform rather than just individual web applications like WordPress, the potential impact is widespread. Sources include theofficial PHP security advisoryandthe explanation by the PHP Foundation.

This news has another major characteristic.Security research leveraging generative AI concretely demonstrated the severe attack potential of a previously known issue. We trace the process from discovery to mitigation to understand why fixes were expedited and why governments and enterprises were prompted to act.

What is PHP? A technology powering the global web for over 30 years

PHP is anopen-source programming language that runs on the web server side. For instance, when a user selects a product on an e-commerce site, PHP retrieves prices and inventory from the database, registers the order details, and returns the result to the user. Member logins, contact forms, and blog post rendering are also typical use cases. It plays the role of retrieving and processing information behind the screens displayed in the browser.The official PHP introductory documentationalso explains this server-side usage.

Its origins are1994. The developerRasmus Lerdorfcreated it as a small tool to track visits to his web page. It was called "Personal Home Page Tools",June 1995and its source code was released. Other developers participated in its improvement, and over the course of about 30 years, it grew into a language used worldwide. This history isdocumented in the official PHP manual.

Frameworks and systems built on PHP includeWordPress(for managing blogs and corporate websites),DrupalandJoomla(for content management on large-scale sites and more),MediaWiki(for wiki-based information sites). Even when using these services, regular visitors are rarely aware of the existence of PHP.

Just how significant is its impact on the world?

According to web technology adoption statistics fromW3TechsAccording toas of October 24, 2026, the display date of the reference page, 69.3% of websites whose server-side programming language could be identified used PHP.This is the figure shown in W3Techs usage statistics. Because a flaw was found in a common technology widely used around the world, this news was not an issue limited to Japan alone.

However,69.3% does not mean 'all sites worldwide are targeted' nor does it mean 'vulnerabilities remain in that 69.3%'. The denominator is websites whose language could be identified, and the PHP version, patch status, usage, and attack success conditions vary by site. Adoption rate and the proportion of vulnerable sites must be considered separately.

What kind of damage can occur?

PHP is a mechanism that runs web pages and APIs on the server, not a component for changing the appearance of a site. If a flaw inside PHP is exploited, risks can arise even if the site's program has not been modified.

The research team has demonstrated and explained the following impacts under configurations meeting the conditions.

• Site defacement: Execution of malicious code may alter page content or files.

• Theft of confidential information: Passwords, tokens, API keys, and other data contained in the server's processing memory may be read.

• Service outage: The PHP process may terminate abnormally, or web services may fail to respond properly.

• Spread of damage: Depending on server privileges and network connectivity, other assets may also be affected.

This does not mean that the same attack will necessarily succeed on all PHP sites. Attack success conditions and the processing that can be executed afterward vary depending on the PHP operation method, configuration, privileges, and application.Wiz research findingshave reported successful attacks in test environments using WordPress, Drupal, and Joomla, but that fact should not be confused with the compromise of individual production sites.

The root cause is internal PHP processing, not Web application bugs.

The two vulnerabilities relate to internal state issues when PHP handles errors or out-of-memory conditions.

For details, refer tothe PHP Foundationandthe Ubuntu Security NoticeGenerally, remote code execution (RCE) refers to an attacker executing unintended programs on a target computer from a remote location. The fact that it is a PHP vulnerability does not necessarily mean it is identical to an OS command injection attack vector.

Did generative AI really participate in the discovery?

Generative AI was indeed used. However, the description that "AI discovered and fixed it entirely on its own" is not accurate.

According to the PHP Foundation, while PHP developers were fixinganother issueidentified during an external audit conducted by Quarkslab in 2024 under the coordination of OSTIF, signs of this out-of-memory issue were discovered.This does not mean that Quarkslab directly discovered these two issues back in 2024.However, at the time, the exact attack vector could not be determined, and deciding on a fix was difficult due to potential impacts on compatibility and performance.

In 2026, multiple security research efforts progressed using generative AI as an auxiliary tool.

• July 30Security firm Calif initiates a PHP audit in connection with OpenAI's "Patch the Planet".

• August 11Calif researchers report a severe remote code execution vector leading to the prior issue.

• August 19-24Wiz verifies the vulnerability and exploitability using AI-assisted research and reports it to the PHP security team.

• October 21The PHP development team releases patched versions.

The PHP Foundation explains that OpenAI also independently reported the same root cause and reported an additional attack vector on September 18. The date of OpenAI's initial independent report is not specified in the body of the document.

For the AI-driven investigation and the reporting history of each organization, refer toWiz's technical reportandthe PHP Foundation's chronology explanation.

AI assisted in verifying exploitability, which previously required extensive analysis and trial and error, and the clear demonstration of severity served as a major catalyst for taking action. Meanwhile,patch design, compatibility assessment, code review, and distribution were handled by human developers and security teams. The PHP Foundation explains that even now, with an increase in AI-generated reports, final decisions and patching are still performed by humans.

This event demonstrates that while AI accelerates defensive research, it can also make vulnerability analysis easier for attackers. Long-standing flaws may sometimes be brought to light as practical attack vectors for the first time due to the advent of AI.

Who are the individuals and organizations mentioned in the news?

This news is not about a vulnerability discovered by a single researcher and patched by a single company.Those who find, those who fix, those who distribute broadly, and those who raise awarenessshared these responsibilities.

The PHP development team(The PHP Group) consists of global developers who design and maintain the PHP language itself. They played a central role in implementing vulnerability fixes and releasing updated versions. Supporting this work financially and personnel-wise,the PHP Foundationis an organization comprising companies and individuals that supports the long-term development of PHP. In this instance, they also assisted by securing personnel for the patching work and coordinating stakeholders.the purpose of the PHP Foundationandthe background explanation.

Quarkslabis a French security research firm that audited the PHP source code in 2024.OSTIF(Open Source Technology Improvement Fund) is a non-profit organization that coordinates open-source security audits. The audit funding was provided by Germany'sSovereign Tech Agency provided. This audit reported another issue, and the remediation process led to the discovery of subsequent indicators.PHP Foundation audit results and OSTIF audit report contain the background details.

Calif is a US-based security research firm. They are a group of specialists who verify whether software contains any attack vectors.OpenAI is a generative AI development company that provided advanced AI and technical cooperation to researchers through Patch the Planet.Wiz is a security firm that investigates risks in cloud and AI environments, having researched the issue via a different path and reported it to the PHP team. In other words, Calif and Wiz were primarily on the discovery and verification side, while OpenAI was on the AI and investigation/coordination support side. For details from each organization, refer to Calif、, the PHP Foundation background explanation, and 、Wiz.

Canonical(Canonical) is the company responsible for developing and providing the Linux distributionUbuntu. It incorporated the fixes prepared by the PHP development team into Ubuntu's existing PHP packages, enabling Ubuntu users to apply updates. This places it in the role ofhandling distribution and updates, separate from security researchers.The official Ubuntu security noticeindicates the patched version numbers.

In Japan,IPA(Information-technology Promotion Agency), acting as an independent administrative institution responsible for information security measures and IT human resource development, called for update preparations.JPCERT/CCis a neutral coordination body that collects information on cyberattacks and incidents, and coordinates with domestic and international organizations to prevent the spread of damage.JISA(Japan Information Technology Services Industry Association) is an industry association for IT service companies and others, which also played a role in delivering government security alerts to member companies. Information regarding the purposes of these organizations can be checked viaIPA、JPCERT/CC、and JISA.

The workflow from discovery to emergency updates

The discoverer and the person responsible for the fix are not the same. The identification of the indicators in 2024 occurred while PHP developers were fixing a separate issue reported by Quarkslab during an audit. The indicators of the out-of-memory issue were discovered, which does not mean both CVEs had already been identified at that time.PHP Foundation explanationandoriginal audit reportSee.

flowchart TB
    A["2024年：PHP開発者が<br/>メモリ不足問題の兆候を把握"]
    B["2026年：研究者が生成AIを活用し<br/>攻撃可能性を具体化"]
    C["Calif・OpenAI・Wizなどが<br/>PHP側へ報告・検証協力"]
    D["PHPのセキュリティチームが<br/>修正パッチを実装・テスト"]
    E["PHP開発元が修正版を公開"]
    F["OS配布元がパッケージを準備・配布"]
    G["IPA・JPCERT/CCなどが注意喚起"]
    H["各組織が更新・侵害兆候を確認"]
    A --> B --> C --> D --> E
    E --> F --> H
    E --> G --> H

Figures and sources in Figure 1

• *1 PHP Development Team / PHP Foundation: PHP maintenance and patching / support through development funding and personnel.Organizations and patch history。

• *2 Calif, OpenAI, Wiz: Investigating potential AI-driven attacks, reporting to PHP, and collaborating.PHP Foundation／Wiz。

• *3 OS Distributor: Enabling PHP patches to be updated across various operating systems and products.Example of distribution by Ubuntu。

• *4 IPA and JPCERT/CCGuidance on preparation, security advisories, and compromise assessments for domestic organizations in Japan.IPA／JPCERT/CC。

Discovery, proof-of-concept, and patching are distinct phases. AI assisted in validating the attack vector, while PHP developers implemented the patch. Furthermore, this does not imply that stakeholders queued up sequentially; patching, distribution preparation, and advisory issuance were partially concurrent.

Why administrative agencies and industry associations issued warnings

This incident is not limited to an outage at a single enterprise. Because it involves a widely used common technology, communications and countermeasures expanded from the PHP development team to OS distributors, cloud hosting providers, specialized organizations, government agencies, and industry associations.

• October 20 (UTC)The PHP development team published an advance notice of a critical security update. According to the PHP Foundation, the pre-release leakage of information, such as CVE identifiers, was also a reason for accelerating the schedule.

• October 21 (JST)IPA issued a preparatory advisory, urging organizations utilizing PHP to identify their systems and prepare for prompt updates.

• Around 23:00 on October 21 (JST)The release of patched versions and the disclosure of detailed information progressed.

• October 22JPCERT/CC urged prompt updates and investigations into potential compromises. Domestic industry associations also disseminated notifications based on requests from the Ministry of Economy, Trade and Industry and security advisories from the National Center of Incident Readiness and Strategy for Cybersecurity (NISC) of the Cabinet Secretariat.

This does not mean that the Japanese government issued a uniform legal patching mandate to all enterprises.Rather, given the critical severity and wide scope of use, information was widely disseminated so that each organization could make appropriate judgments and take corresponding actions.This is supported byIPA's advance notice、JPCERT/CC's security advisory、Information Services Industry Association guidanceis available at.

Furthermore,"critical risk", "proven attacks", and "confirmed actual damage" are distinct concepts. IPA, in its updated advisory of October 22,preparatory guidance, explicitly stated that it has not confirmed any exploits used by its own organization.The Canadian Centre for Cyber Securitystated in its updated notification on October 23 that while it was aware of reports regarding the publication of a PoC, the agency had not identified any actual exploitation at that time.Because publication dates, the observation scopes of each agency, and reported details differ, these should not be treated as a single definitive global damage status.

Advanced Defense and Awareness Worldwide

Because PHP is used across borders, the response was also international. For example, providing services to protect web trafficCloudflareexplained that it prepared and distributed Web Application Firewall (WAF) mitigation rules prior to the public disclosure of the vulnerability information. A WAF is a mechanism that blocks suspicious web traffic, but it does not replace updating PHP itself.Cloudflare response reportSee.

In addition,the Canadian Centre for Cyber Securityalso issued an alert on October 21. While security alerts from various countries must be distinguished from the impact assessments of individual companies, this demonstrates that the current issue involves a global software infrastructure.

Information and Response Spreading Domestically – Tracked by Date and Time

The public announcement by the overseas PHP development team was notcommunicated serially through a single chain of command. Rather, organizations that received the official information proceeded with advance preparations, dissemination, service suspensions, and patch applicationsin parallel, according to their respective roles and responsibilities. For Japanese readers, the key takeaway is not 'who reports to whom,' but rather 'which organization communicated what information, and when each operations team took action.'

What is the domestic cybersecurity framework like?

The National Cyber Coordination Office(NCO, Cabinet Secretariat) is responsible for planning and coordinating Japan's cybersecurity policies, as well as providing advice and information to administrative agencies. Meanwhile,IPApublishes vulnerability and mitigation information that is useful for companies and general system users, whileJPCERT/CCcollects technical information, coordinates with domestic and international entities, and supports incident response.The Ministry of Economy, Trade and Industry (METI)is responsible for liaising with relevant organizations in its jurisdiction, and industry associations such asJISAdeliver the information to member companies. This is not a hierarchical list, but a division of labor among organizations with different roles. For details on this notification request, refer to thematerials published by JISA.

JISAreceived a request from METI to notify its member companiesexplicitly states,along with the alert materials from the National Center of Incident Readiness and Strategy for Cybersecurity (NISC)However, specific communication and instruction channels—such as "IPA submitted a report to the Cabinet Secretariat," "the Cabinet Secretariat issued simultaneous instructions to the media," or "a legally binding update order was issued to all enterprises"—cannot be confirmed from these materials. Media outlets also independently investigate announcements made not only by the government, but also by the official PHP site, security research companies, and individual service providers.

Figure 2: From overseas release to domestic notification and on-site response (primarily Japan Standard Time, with advance notices in UTC only)

flowchart TB
    subgraph T20["10月20日（世界協定時）｜海外の起点"]
      P["PHP開発チーム<br/>重大なセキュリティ更新を事前予告"]
    end
    subgraph T21["10月21日（日本時間）｜公開前の予防措置"]
      IPA["IPA：更新に備えた準備を呼びかけ"]
      SCI["東京科学大学：16時ごろ<br/>サーバーの暫定的な防護設定"]
      XS_STOP["エックスサーバー：16時から<br/>サービスサイト・管理画面等を一時停止"]
      RAK_STOP["ラッコ：19時ごろから<br/>一部サービスを予防的に停止"]
      PATCH["PHP開発チーム：23時ごろ<br/>修正版を公開"]
    end
    subgraph T2122["10月21日以降｜政府・業界の並行した周知"]
      NCO["内閣官房 NCO<br/>注意喚起文書を発出"]
      METI["経済産業省<br/>JISAへ会員企業向け周知を依頼"]
      JISA["JISA：注意喚起文書を掲載<br/>会員企業へ対策を案内"]
    end
    subgraph T22["10月22日（日本時間）｜パッチ適用と再開"]
      JC["JPCERT/CC：更新と<br/>侵害有無の調査を呼びかけ"]
      XS_FIX["エックスサーバー：6時45分<br/>PHP 8.2～8.5の修正適用完了"]
      RAK_FIX["ラッコ：8時43分<br/>全サービスを再開"]
      LOLI["ロリポップ！：13時ごろ<br/>サイト表示を再開"]
      MOF["財務省：一部コンテンツを<br/>安全確認後、順次再開"]
      PRESS["新聞・専門メディア<br/>対応状況を報道"]
    end
    subgraph T23["10月23日（日本時間）｜メンテナンス完了の公表"]
      SAKURA["さくらインターネット：17時30分追記<br/>緊急メンテナンス全件終了を公表"]
    end
    P --> IPA
    P --> PATCH
    XS_STOP -.-> XS_FIX
    RAK_STOP -.-> RAK_FIX
    METI -->|"周知依頼"| JISA
    NCO -.->|"注意喚起文書をJISAが掲載"| JISA
    PATCH --> JC
    PATCH --> XS_FIX
    PATCH --> RAK_FIX
    PATCH --> LOLI
    PATCH --> MOF
    PATCH --> SAKURA
    PATCH --> PRESS

How to read Figure 2 and source notes

• Timeline: Arranged vertically from top to bottom in the chronological order of announcements, preparation, and patch application. Dates and times are inJapan Standard Time (JST)unless otherwise noted. Only the October 20 advance notice is expressed in Coordinated Universal Time (UTC).PHP Advance Notice／IPA Advance Notification。

• Domestic Notification: NCO, the Ministry of Economy, Trade and Industry (METI), and JISA have distinct roles, and no documentation confirms that information was transmitted in a linear chain.METI's notification request to JISAandthe publication of NCO documents on the JISA websitecan be confirmed through public statements.JISA Guidance。

• Pre-Release Actions: Tokyo Institute of Technology announced interim countermeasures, while Xserver and Lakko announced the preventive suspension of certain services and management consoles.Institute of Science Tokyo／Xserver／Rackto。

• After the release of the revised version: Reports on vulnerability patch applications and service resumptions by IT service providers were distinguished from JPCERT/CC alerts.JPCERT/CC／Lolipop!／Sakura Internet／Ministry of Finance。

• Meaning of the arrows: Conceptually shows the relationship between publicly available information and the timing of responses. The arrows do not indicate individual instructions or communications between organizations. Dotted lines represent the transition from suspension to resumption by the same provider or the referencing relationship between documents.INTERNET Watch reportSee also.

Where suspensions and updates actually occurred—Examples of announced recoveries

Preventive measures and the actual application of patches to resume services are distinctevents. Here, we exclude suspension information regarding financial institutions and general corporations from the list, focusing exclusively onofficial completion of responses and service resumption reports by IT service and hosting providersas well as cases publicly disclosed by universities and government agencies. The following information reflects disclosures as of October 25, 2026, and does not imply that all systems utilized by the listed organizations had vulnerabilities or suffered compromises.

The terms "restoration" and "response completed" used here refer tothe scope of services and functions covered by each official announcementis limited to. Even if operators address all versions, it does not mean that long-term use of unsupported PHP is secure. Furthermore, regarding individual organizations such as medical institutions, do not speculate on unverified damage or recovery statuses without official backing.

What we can learn from this incident is thatUpdate notice from the overseas developer -> Domestic preventive measures -> Application of patch -> Announcement of service resumptionprogressed in a short period of time. Each company's decision was made concurrently, and not all organizations responded at the exact same time or in the same order.

What companies and site administrators should check

First, identify whether PHP is used in websites, business systems, or services provided by external contractors. PHP may be used not only in applications but also inside hardware and products, and users may not always be able to check the version directly.

Second, check the updates published by the provider of the product or OS you are using. The official PHP site released8.2.35, 8.3.36, 8.4.27, 8.5.12on October 21, 2026. However, Linux distributions and product vendors may provide fixes under different package numbers.

Third, verify the service operation after the update. Check not only page rendering but also major functions such as logins, forms, APIs, and background processing. Also, examine logs before and after the update, as well as any suspicious communication or processes.Applying a patch does not prove that a system was not compromised in the past.Key points for investigating compromises are summarized inJPCERT/CC's security advisory.

Be sure to check the additional advisory from October 23

On October 23, official PHP published additional notes regarding the session upload progress feature. When an application sets session.serialize_handler to php_binary or php_serialize, and switches to php during execution, then session_start() and pertains to a specific combination where the upload progress feature is also enabled.

The official PHP documentation advises keeping it as session.upload_progress.enabled=0 until the next regular bug-fix release. If you already disabled it as part of the October 21 mitigation, maintain that setting. Applications that do not change the serialization method during execution do not need to disable the feature for this additional advisory reason. Verify any configuration changes for effects on upload progress displays and apply them to the PHP settings actually used by the web tier.

This additional information is scheduled to be detailed in the next release as CVE-2026-115560. Do not assume that simply completing the updates for the two items on October 21 eliminates the need to check related supplemental guidance. Source:Official PHP: Advisory on Session upload progress dated October 23。

Example of checking for patched packages on Ubuntu

Update procedures vary depending on the operating system, PHP distributor, and installation method. As an example, we look at Ubuntu, one of the widely used Linux-based distributions. This is a general example for explanatory purposes and does not imply that any specific site runs on Ubuntu.

The patched PHP 8.3 package version advised by Canonical for Ubuntu 24.04 LTS is8.3.6-0ubuntu0.24.04.13.Official Ubuntu Security Notice USN-8948-1as explicitly stated.

Figure 3: From PHP core fix to Ubuntu update

Ubuntu developers do not need to rediscover vulnerabilities from scratch. Based on the fixes by the PHP development team, Canonical incorporates the patches so they function on existing Ubuntu versions and prepares the packages. This is the concept of backporting.

flowchart TB
    A["PHP開発チーム<br/>PHP本体の修正を作成・検証"]
    B["Ubuntuの提供元 Canonical<br/>修正を既存パッケージへ取り込む"]
    C["Ubuntu向けにビルド・検証<br/>修正版パッケージを配布"]
    D["システム管理者<br/>APTで修正版を取得・適用"]
    E["PHP-FPM等の稼働状態を確認<br/>必要なサービス再起動を確認"]
    F["パッケージ版数・サイト機能・<br/>エラーログを点検"]
    A --> B --> C --> D --> E --> F

Actors and sources in Figure 3

• *1 PHP Development Team: Designs the fix and incorporates it into a new version of upstream PHP.Explanation of fixes by the PHP Foundation。

• *2Canonical / UbuntuPerforms "backporting" to integrate fixes into existing Ubuntu versions and distributes verified update packages.Ubuntu Security Notice。

• *3Administrators of each site or enterpriseApply packages that match their environment and check for correct operation and anomalies.JPCERT/CC mitigation guide。

For example, in standard PHP 8.3 on Ubuntu 24.04 LTS, even if the base PHP version remains 8.3.6, the full package version8.3.6-0ubuntu0.24.04.13includes this fix. Verify separately which PHP is actually running. Basis:Ubuntu USN-8948-1。

For example, in a standard Ubuntu environment using PHP 8.3 CLI, FPM, and common packages, the installed version can be checked as follows.

php -v
dpkg-query -W -f='${db:Status-Status}\t${binary:Package}\t${Version}\n' \
  php8.3-cli php8.3-fpm php8.3-common
apt-cache policy php8.3-cli php8.3-fpm php8.3-common

This example is a check command to verify the version and does not execute a PHP update.dpkg-querydisplays "status, package name, and version". Confirm lines where the status isinstalledas installed packages.config-filesEven if a version appears on lines such asRefer to the official dpkg-query manual.

php -vchecks the PHP of the invoked CLI. It is not necessarily the same binary or version used by PHP-FPM or Apache modules for web sites.apt-cache policydisplays local APT information, so appearance of an update candidate is not proof that it has been applied, and outdated cache will yield outdated candidate information.Official PHP CLI documentationandofficial apt-cache manualRefer to these to check the installed version, update candidate, and the PHP version used for the web separately.

Note that the three packages shown in the example are not necessarily installed in all Ubuntu environments. Errors related to the display of uninstalled packages do not inherently indicate an update failure. Identify your PHP execution method (FPM, Apache module, CLI, etc.) and the packages in use before checking.

Even if the firstphp -vdisplays "8.3.6", you cannot determine that it is unfixed based on that alone. This is because Ubuntu and other distributions performbackportsto incorporate security fixes while maintaining the original version. What you should check is the distribution'scomplete package versionand the official vendor notification.

What can be inferred from the actual query results

Next isan example where only the parts necessary for the article's assessment are extracted and formatted from the verification results on Ubuntu 24.04 LTSInformation that identifies individual environments, such as hostnames, usernames, CPU architecture, APT repositories, and build timestamps, is not included. This is not the result of a package update or configuration change, but ratherread-only command output.

php -v: PHP 8.3.6 (cli)

状態         パッケージ        インストール済み版数
installed    php8.3-cli       8.3.6-0ubuntu0.24.04.13
installed    php8.3-common    8.3.6-0ubuntu0.24.04.13
installed    php8.3-fpm       8.3.6-0ubuntu0.24.04.13

APTの候補版数（上記3パッケージ）:
8.3.6-0ubuntu0.24.04.13

In this example,three packages (CLI, FPM, and common packages) are installed and match the PHP 8.3 patched version in Ubuntu official notice USN-8948-1The currently displayed PHP 8.3.6It is a mistake to judge that it is "before a fix" based solely on this. Meanwhile, APT "candidates" are based on acquired repository information and do not always guarantee future up-to-date states.Canonical's list of fixed versionsto cross-check.

What could be confirmed here is up to the package versions corresponding to CVE-2026-109618 and CVE-2026-109619 published on October 21, 2026. These three commands alone cannot determine whether the web server is actually using PHP-FPM from that package, whether the updated process has been restarted, or whether the additional notes from October 23 need to be addressed. Operating status and service impact must be verified separately.

When performing an update, verify backups, dependencies, and the impact of service restarts in advance. Because update procedures vary for containers, custom builds, PPAs, and hosting services, do not run the exact same commands universally. Also, distinguish between fixes to PHP itself and updates to web applications or CMSs.

For repeating the same check,read-only sample, specified packages are checked in order, distinguishing between uninstalled packages, query failures, and missing candidate information. It does not display APT repository URLs or raw diagnostic text, nor does it perform package updates or service operations. An exit code of 0 simply means information was retrieved successfully and does not indicate the completion of vulnerability mitigation.

A simplified version of thePHP package state check sampleoutputs execution resultsdirectly to the terminal.It does not create automatic log files. By organizing the code into short functions and avoiding top-level exit, pasting the entire text into the terminal will not terminate the login shell.

Usage is simply running bash check-php-package-status.sh in the directory where the sample is saved. The package status, complete version, and APT candidate version will be displayed on the screen. Immediately after execution, typing echo $? allows you to check the exit code as well.An exit code of 0 only indicates successful information retrieval and does not guarantee safety. The user copies and saves the terminal output only when necessary. No package updates, service operations, or external transmissions are performed.

This sample verified Bash syntax, simulated package data, direct pasting into the terminal, and error handling. Users reported that on actual Ubuntu, three package versions were displayed correctly and the terminal did not close. However, this does not automatically verify PHP updates or the operational status of web-side PHP.

Conclusion: Even if AI accelerates discoveries, humans and operational responsibility remain paramount.

PHP2Shell demonstrated that flaws lurking in the foundations of widely used software can lead to unauthorized external code execution and information leakage, and that generative AI accelerates the elucidation of such risks.

In this research, signs of the problem identified by human developers in 2024 were materialized as deeper attack possibilities by AI-assisted research in 2026. Patching and disclosure were led by the PHP development team, prompting public agencies and operators to issue advisories and prepare for updates.

As AI discovery capabilities increase, the defensive side requires:Understanding deployed systems, applying trusted patches, and continuing to monitor for anomalies afterward.Basic operations.

References and Citations

Below are the sources verified at the time of writing, along with what each source supports.

1. PHP Official: Notice on Critical Vulnerability of October 21, 2026 — CVE, severity, patched versions.

2. PHP Foundation: Timeline from Discovery to Patching (October 21, 2026) — 2024 indicators, 2026 reports, human patching.

3. Wiz: PHP2Shell Research Report (October 21, 2026) — AI utilization, proof of exploitability, technical impact.

4. IPA: Preparations for PHP Security Release (October 21, 2026) — Distinction between preparation requests and exploitation confirmation in Japan.

5. JPCERT/CC: Advisory on PHP Vulnerabilities (October 22, 2026)— Domestic countermeasures and compromise investigation points.

6. Information Services Industry Association: PHP2Shell Advisory from the Ministry of Economy, Trade and Industry, etc.— Notice from government authorities to industry associations.

7. Ubuntu: USN-8948-1 (October 21, 2026)— Patched package versions for the distribution.

8. PHP Official Manual: Introduction— The role of PHP and server-side mechanisms.

9. PHP Official Manual: History of PHP— Creation in 1994, release in 1995.

10. W3Techs: Global PHP Usage Statistics— The 69.3% adoption rate shown on the referenced page as of October 24, 2026, and its denominator.

11. PHP Foundation: Mission— The role of the organization supporting PHP developers.

12. Calif: Company Overview— The role of the security research company.

13. Wiz: Company Overview— The role of the cloud security research company.

14. IPA: Organization Overview— The role of the IPA domestically.

15. JPCERT/CC: Organization Overview — Coordination of incident response domestically and internationally.

16. JISA: Association Overview — Purpose of the industry association.

17. Cloudflare: WAF Mitigations for PHP2Shell — Examples of international mitigation strategies.

18. Government of Canada: Warning Regarding Critical PHP Vulnerability — Initial report on October 21 and update on October 23, status of confirmed exploitation, and cautions regarding additional vulnerabilities.

19. PHP Foundation: PHP Core Security Audit Results (April 10, 2025) — Collaboration with OSTIF and Quarkslab, which conducted the 2024 audit, and audit funding.

20. OSTIF: PHP Audit Complete! (April 10, 2025) — Background of the audit implementation, scope of verification, and work performed by Quarkslab.

21. Institute of Science Tokyo: Interim Measures for WWW Server Proxy Service (October 21) — Interim measures on October 21, and the update regarding patch application and partial resumption on October 22.

22. Sakura Internet: Response Status to PHP Vulnerability (Updates on October 22 and 23) — Target PHP fixes, completion of related maintenance, and scope of disclosure.

23. Xserver: Status of Management Console Suspension and PHP Patch Application/Resumption — Application times by PHP version and incomplete older versions.

24. Lolipop!: Report on Response and Resumption of Operations for PHP Vulnerability (October 22) — Resumption of site display and management console, and fixes applied to older versions.

25. Rakko: Report on PHP2Shell Response and Resumption of All Services (October 22) — Stop start, resumption time, and PHP patching.

26. Ministry of Finance: Resumption of public access to some content (October 22) — Resumption after safety verification.

27. INTERNET Watch: Domestic response to PHP vulnerability (October 22) — Summary of the domestic situation by news media.

28. IPA: Follow-up on vulnerability countermeasures for PHP2Shell (October 22) — Target versions, fixed versions, and decision guidelines when mitigation is difficult.

29. Official PHP: Additional notes on Session upload progress (October 23) — Additional mitigation for limited configurations and guidance until the next release.

30. Official Ubuntu Manual: dpkg-query — Retrieval and display format of status, package name, and version number.

31. Official PHP Manual: CLI Options — php -v Information indicated by .

32. Official Ubuntu Manual: apt-cache — Verification based on local cache and handling of update candidates.

GitHub Sample

• Daily-Code-Samples — Checking PHP package status and version

• Usage, prerequisites, input/output, and notes

• Complete code: check-php-package-status.sh

Links are pinned to the verified commit. Verify the content and the distributor's latest notifications before applying to a production environment.