https://www.php.net/ PHP 8.5.12, 8.4.27, 8.3.36 and 8.2.35 fix two critical vulnerabilities that can allow unauthenticated remote code execution. All PHP users are strongly encouraged to update immediately. Who is at risk: all PHP installations serving web requests, including PHP-FPM, Apache with mod_php, php-cgi, FrankenPHP and LiteSpeed. We consider the risk highest for mod_php, with a demonstrated exploit where an unauthenticated request can trigger the attack before any application code runs. The vulnerabilities: RCE via OOM corruption, CVE-2026-109618 (GHSA-w8hw-w9fx-j79w): out-of-memory handling can interrupt PHP while internal request data is only partially initialized. Request cleanup may then treat the invalid data as valid. RCE via stale global state, CVE-2026-109619 (GHSA-6wmf-4rv5-p3rp): request-owned internal state can survive after its backing memory has been freed. A later request handled by the same worker may use that stale state before normal initialization resets it. If you cannot update immediately: while only an update is a complete solution, the following measures reduce exposure to specific attack paths but do not make an installation safe. RCE via OOM corruption (CVE-2026-109618): • Set memory_limit=-1, preferably in a way applications can't override, such as php_admin_value in the FPM pool or Apache configuration, and check that no pool, directory or application setting puts a finite limit back. This removes the controllable PHP memory limit failure, but an underlying allocation failure can still reach the vulnerable path. • Set a low post_max_size. For applications that don't require file uploads, set post_max_size = 8M. If file uploads are necessary, set post_max_size = 32M. Keep upload_max_filesize below post_max_size. Consider enforcing limits at the web server or proxy level for decoded request size, input field count, multipart part count, header count, and nesting depth. These limits must also cover requests without a usable Content-Length. • Use a container or cgroup limit as an availability boundary, preferably with a policy that kills only the affected worker. Do not substitute RLIMIT_AS or RLIMIT_DATA, as these can cause the vulnerable allocation failure. RCE via stale global state (CVE-2026-109619): • Set session.upload_progress.enabled=0 and restart every worker. Use php.ini, an FPM pool or server configuration that applies before request parsing. Do not rely on ini_set() or FPM .user.ini. This blocks the confirmed session paths but not other variants. • On PHP 8.5, set fatal_error_backtraces=0 and restart every worker. This blocks the confirmed fatal backtrace path only. • Remove invalid or deprecated settings applied per request that emit diagnostics before initialization. Hiding diagnostics with error_reporting, display_errors or @ does not help. • Fix attacker-reachable fatal errors and execution timeouts, including failures in callbacks, upload or import processing and cleanup.

紧急安全提醒：PHP2Shell CVE-2026-109618 / CVE-2026-109619 风险等级：Critical｜CVSS v4.0：9.2 发布时间：2026 年 10 月 21 日 当前状态：PHP 官方修复补丁尚未发布。 漏洞概况 10 月 20 日，PHP 安全团队提前预告两项严重漏洞的紧急修复版本，计划于 10 月 21 日 14:00 UTC（北京时间／新加坡时间 22:00） 发布。watchTowr 和 CERT-EU 的报告指出，两项漏洞可能允许未经身份验证的远程攻击者在受影响的 PHP 环境中执行任意代码（RCE）；watchTowr 声称已复现其中的 CVE-2026-109618。 PHP 被广泛用于 WordPress、Drupal、Magento、Laravel 等 Web 应用，也用于 WHMCS、Blesta、VirtFusion、Virtualizor、Paymenter 等托管、计费及虚拟化管理服务。风险重点在服务器使用的 PHP Runtime，不能仅靠更新网站主题、插件或上层应用排除影响。对于共享主机、托管面板及多版本 PHP 环境，应同时检查所有租户站点、PHP-FPM Pool 和独立容器，而非只检查主站。 紧急建议：优先暂停 PHP 网站的公网访问；无法停机时，在 PHP Runtime 之前全面阻断 multipart/form-data 请求，同时关闭 Session Upload Progress。 技术分析与影响范围 GMO Flatt Security、J4ck3LSyN 等研究者将疑似利用路径指向 PHP 的 session.upload_progress 和 multipart 请求处理。Session Upload Progress 是 ext/session 提供的上传进度跟踪功能，默认启用。符合条件的 multipart 请求可使 PHP 在应用脚本执行前向 Session 写入进度数据。 J4ck3LSyN 的 PHP-UP-2026 报告提出，上传进度处理中缓存的 post_bytes_processed、current_file_bytes_processed 指针可能因数据生命周期变化形成 Use-After-Free（UAF），并在特定条件下造成代码执行。该机制是目前公开的第三方技术分析，两个 CVE 的准确根因将在官方补丁公布后进一步明确。 攻击面不等同于网站的上传页面。 即使应用未提供专门的上传接口，或业务代码会拒绝未授权请求，multipart 解析及上传进度处理仍可能先于 PHP 应用代码执行。因此，单纯删除上传按钮、仅封锁 /upload 路径，或者由 PHP 返回维护页面，并不足以阻止相关底层请求处理。 此外，PHP 上游 PR #22113 指出，相关上传进度回调可从 POST 表单取得 Session ID；即使设置 session.use_only_cookies=On，也存在不依赖 Cookie 的处理路径。入口防护应同时覆盖有 Cookie 和无 Cookie 的请求。 根据 CERT-EU 的早期通报，漏洞可能影响 PHP 5 及之后的版本；Sansec 亦提及流出的利用工具声称覆盖 PHP 5.4+。建议将 PHP 5.x、7.x、8.x 全部列入应急排查，优先处理互联网可达的 PHP 服务。最终影响和修复版本以 PHP 官方公告为准。 立即采取的应急措施 1. 首选：暂停公网访问或隔离 PHP 服务 CERT-EU 建议：无法立即修复时，考虑将互联网暴露的应用与公网隔离，直到补丁可用。鉴于当前尚未发布正式补丁，建议暂时停止非必要 PHP 网站的公网访问；管理后台、客户面板、计费系统等可改为仅通过 VPN、可信 IP 或受控内部网络访问。 隔离必须在网络入口、WAF、反向代理或 Web Server 层实施，确保请求到达 PHP 之前已被拒绝。 如需展示维护公告，应由不经过 PHP 的静态页面直接返回，而不是依靠 PHP 应用判断维护状态。还应检查源站 IP、IPv6、备用端口及其他域名，防止绕过隔离措施。 2. 无法停机：直接阻断所有 multipart/form-data 请求 在 WAF、反向代理或 Web Server 配置 Block/Deny，拒绝进入 PHP 的所有 multipart/form-data 请求，包括含 boundary 参数的请求；规则应覆盖全部域名、端点及实际上可能触发 multipart 解析的方法，不能仅保护文件上传 URL，也不应只封锁含 Cookie 或默认上传进度字段的请求。 部署后应从公网测试阻断效果，并核对安全设备及后端日志，确认请求在 PHP Runtime 之前被拒绝。注意 Content-Type 的大小写、参数、重复 Header 与解析差异。全面阻断会影响正常文件上传及部分普通表单；不能接受该影响的业务，优先考虑临时限制为可信网络访问。 3. 同时关闭 Session Upload Progress 在实际处理 Web 请求的 php.ini 中设置： session.upload_progress.enabled = Off PHP-FPM 可在对应 Pool 配置中设置： php_admin_flag[session.upload_progress.enabled] = off 修改后重新加载或重启 PHP 服务，检查每个 PHP-FPM Pool、容器和实例是否生效。该配置应在 PHP 运行环境中调整，不应依赖业务脚本的 ini_set()；普通文件上传通常不受此开关影响，但原生上传进度查询功能可能停止工作。 4. 缩小权限与加强监控 检查 Web 服务账户的文件写入、外连和云平台权限；重点监控 PHP-FPM／Web Server 异常创建 Shell 子进程、Worker 崩溃、异常 multipart POST、PHP_SESSION_UPLOAD_PROGRESS 字段、Session 文件异常以及可疑外部连接。保留 WAF、访问日志、PHP 错误日志和主机行为记录。 5. 排查实际 PHP Runtime 确认 PHP-FPM、Apache mod_php、PHP-CGI、LiteSpeed／LSAPI，以及容器、多版本 PHP、独立 Pool 等实际运行环境。php -v 和 php --ini 仅反映 CLI 环境，还需检查真正处理 HTTP 请求的 PHP 版本及配置。 后续安全更新 PHP 官方计划于 2026 年 10 月 21 日 14:00 UTC 发布修复版本。补丁发布后，应从 PHP 官方或发行版维护渠道获取更新，升级全部运行实例，验证修复后再恢复公网访问与 multipart 业务。 PHP 8.1 及更早版本已结束 PHP 上游安全支持。 旧版本使用者应确认 Linux 发行版或商业维护商是否提供安全补丁回移（Backport）；无法获得可靠补丁的服务，应维持隔离并尽快迁移至受支持分支。 目前已有公开利用演示及实验性研究材料，部分研究者还声称利用工具正在流传。管理员应按高风险应急事件处理，并依据日志和主机遥测排查可疑活动。 以上措施属于补丁发布前的紧急风险控制，正式修复仍以 PHP 官方安全更新为准。 参考资料 PHP 官方：https://www.php.net/archive/2026.php#2026-10-20-1 watchTowr：https://x.com/watchtowrcyber/status/2112611507749982605 CERT-EU：https://cert.europa.eu/publications/security-advisories/2026-018/ GMO Flatt Security：https://blog.flatt.tech/entry/php2shell PHP Upload Progress：https://www.php.net/manual/en/session.upload-progress.php PHP 上游 PR #22113：https://github.com/php/php-src/pull/22113 J4ck3LSyN：https://jackalsyn.com/posts/php-up-2026.html Sansec：https://sansec.io/research/php2shell 显示全部内容 - Telegraph

各位客戶： 由於近期披露的 CVE-2026-109618 及 CVE-2026-109619 PHP 高風險遠端程式碼執行（RCE）漏洞，為保障管理平台及相關系統的安全，並保護客戶資料及私隱，我們已採取預防性措施，暫時關閉網站管理平台。 此措施僅影響管理平台的使用，現有服務將繼續正常運作，不受影響。 惟客戶暫時無法登入管理平台，亦無法透過平台管理或調整服務。 我們正持續關注 PHP 官方的安全更新及漏洞相關資訊，並核實目前由非官方渠道公開的臨時緩解措施是否有效。如確認相關措施可行，我們可能會在重新開放管理平台時，暫時停用部分功能（例如檔案上載功能），以進一步降低安全風險。 另外，如您正在任何服務中使用 PHP，請特別留意近期披露的相關安全漏洞。我們建議您檢查目前使用的 PHP 版本及相關配置，密切關注 PHP 官方發布的安全公告，並在適用的安全修補版本推出後，盡快安排更新。 在完成修補前，您亦可根據實際需要採取適當的臨時防護措施，例如限制不必要的公開連線、停用非必要功能，以及加強安全監察，以降低潛在風險。 我們將在完成必要的安全評估及臨時防護措施後，視乎實際情況逐步恢復管理平台的部分功能，包括檔案上載等功能。待相關 CVE 的官方修補程式發布，我們將全面恢復管理平台的正常運作。 對於管理平台暫時無法使用所帶來的不便，我們深表歉意，感謝您的理解與配合。 如有任何疑問，歡迎隨時透過 support@homura.network 與我們聯絡。 Homura Network Limited ——————————————— Dear Customers, Due to the recently disclosed critical PHP remote code execution (RCE) vulnerabilities, CVE-2026-109618 and CVE-2026-109619, we have taken precautionary security measures and temporarily suspended access to our management panel to protect our infrastructure, related systems, customer data, and privacy. This measure only affects the availability of the management panel. All existing services will continue operating normally and remain unaffected. However, customers will temporarily be unable to log in to the management panel or manage and modify their services through it. We are closely monitoring official PHP security updates and developments concerning these vulnerabilities, while evaluating the effectiveness of temporary mitigation measures publicly proposed by unofficial sources. If these measures are confirmed to be effective, we may temporarily disable certain features, such as file uploads, when reopening the management panel to further reduce potential security risks. Additionally, if you are using PHP in any of your services, please pay close attention to the recently disclosed security vulnerabilities. We recommend reviewing your current PHP versions and configurations, monitoring official PHP security advisories, and applying the appropriate security updates as soon as they become available. Until the necessary patches have been applied, you may also consider implementing suitable temporary security measures, such as restricting unnecessary public access, disabling non-essential features, and strengthening security monitoring to reduce potential risks. Following the completion of the necessary security assessments and temporary protective measures, we will gradually restore certain management panel features, including file uploads, where deemed safe to do so. Full functionality will be restored once official security patches addressing the relevant CVEs have been released. We apologize for any inconvenience caused by the temporary unavailability of the management panel and appreciate your understanding. If you have any questions or concerns, please feel free to contact us at support@homura.network. Homura Network Limited