评论帖子PHP 请求生命周期边界漏洞技术分析（CVE-2026-109618/109619）

太硬核懒得看。

评论帖子缴得不积极，因为发得有问题。有能力的退休前已经体现在工资上了，退休后人人平等

发的确实有问题。

评论帖子PHP 核心 RCE 漏洞（CVE-2026-109618/109619）泄露

@cnskis 是的那我也贴一下：官方的缓解措施
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.
The advisories linked above have the full technical details.

评论帖子PHP 核心 RCE 漏洞（CVE-2026-109618/109619）泄露

是 ai。但是我审过。官方发的内容也就是升级版本。

评论帖子PHP 核心 RCE 漏洞（CVE-2026-109618/109619）泄露

针对 2026 年 10 月 21 日 PHP 官方发布的紧急安全公告（修复 CVE-2026-109618 和 CVE-2026-109619 两个 CVSS 9.2 级的漏洞），整理的漏洞详情、修复及缓解方案如下：

1. 漏洞原理与危害简述

漏洞编号 / 名称	漏洞原理	攻击危害
CVE-2026-109618(OOM 内存损毁 RCE)	在处理 Web 请求时，若触发 PHP 内存不足（OOM）逻辑，请求会被中断。但在内部数据未完全初始化时中断，后续清理（Cleanup）流程会将无效数据误认为有效数据，造成内存损毁。	未经身份验证的远程代码执行（RCE）。攻击者可直接向服务端发送恶意构造的超大或复杂请求，在无任何权限的情况下控盘服务器。
CVE-2026-109619(残余全局状态 RCE)	请求占用的内部状态在后端内存释放后，依然残存在并发 Worker 进程中。当同一个 Worker 处理下一个新请求时，会在正常重置前使用残留的失效状态，引发越界或指针异常。	未经身份验证的远程代码执行（RCE）。利用特定路径（如文件上传进度追溯）稳定触发攻击。Apache mod_php 风险最高，攻击能在应用代码运行前触发。

2. 修复方法（彻底解决）

直接升级至官方已修复的 PHP 版本是唯一能消除风险的完整方案。

升级目标版本：

PHP 8.5 分支：升级至 8.5.12
PHP 8.4 分支：升级至 8.4.27
PHP 8.3 分支：升级至 8.3.36
PHP 8.2 分支：升级至 8.2.35

实操步骤：

复制

# Ubuntu / Debian 系统示例：
sudo apt-get update
sudo apt-get install --only-upgrade php8.3-fpm php8.3-cli php8.3-common # 根据实际使用的 PHP 分支修改版本号
# CentOS / RHEL / Rocky Linux 示例：
sudo yum update php php-fpm php-common
# 升级完成后必须重启 Web 服务与 PHP-FPM 服务：
sudo systemctl restart php8.3-fpm
sudo systemctl restart nginx # 或 apache2

注意：如果通过 Linux 官方源或 LTS 厂商安装，请确认包管理器获取到了 2026 年 10 月 21 日及以后发布的补丁包。若使用源码编译，需前往 php.net 下载对应分支最新的源码包重新编译部署。

业务影响：

重启短暂中断：重启 php-fpm 或 Apache 时会造成数秒的请求瞬断（建议在业务低峰期操作，或使用平滑重启 reload）。
兼容性影响：本次升级为小版本（Patch）安全更新，不会引入破坏性的 API 变更，对已有业务代码兼容性影响几乎为零。

waf 能拦吗

答案是：可以拦截部分攻击变种，但不能作为完全依赖的防御手段，无法做到 100% 免疫。

WAF（Web 应用防火墙）在本次安全事件中属于辅助缓解层，它的能力边界和局限性如下：

一、WAF 能拦住什么？（有效场景）

特定已知特征的载荷（CVE-2026-109619）：对于利用 session.upload_progress 或已知特定反序列化/全局状态篡改的攻击 payload，若 WAF 开启了最新的签名规则库（如包含相应漏洞正则的规则），可以在网关侧直接阻断该类 HTTP 请求。
超大/异常 Request 限制（CVE-2026-109618）：WAF 或入口 Nginx 可以强制限制 Content-Length、Multipart 嵌套深度、请求头数量及 Body 大小（如限制在 8M/10M 以内）。这能直接切断通过“超大 Post 请求触发 OOM”的特定攻击路径。

二、为什么 WAF 不能彻底替换补丁？（局限与绕过风险）

绕过风险高（Bypass）：RCE 漏洞的 Payload 往往可以通过编码（如 Base64、URL 编码、混淆）、分块传输（Chunked）或利用不同的 Content-Type/Multipart 格式绕过 WAF 的正则检测。
协议与底层解析差异：WAF 解析 HTTP 请求的 Engine 与 PHP 底层（Zend Engine / FPM）在解析极极端或异常报文时可能存在差异。如果攻击者构造了“WAF 认为是合法/无法理解、但 PHP 却能成功解析并触发 OOM/残余状态”的畸形请求，WAF 就会失灵。
针对 CVE-2026-109618 (OOM) 的固有缺陷：OOM 路径的根本问题在于“PHP 内部内存不足后的清理逻辑异常”。即便攻击者发送的请求体积符合 WAF 规则，只要目标服务器当时的系统内存紧张，或者通过组合正常业务接口消耗了服务器资源，同样可能触发 OOM 路径。这种流量在 WAF 看来完全是正常的合法业务流量。

评论帖子Windows邮箱客户端

我都用在线的。
都没用客户端。

评论帖子出一个V2EX的邀请码，需要的私我

v2 感觉都没啥人了，没有回复。

评论帖子万兆mac min 16 +256 25年3月现在[听歌]出二手多少钱合适

我挂了 4000 好几个月了没人要。同配置的 m4 万兆口最低配

评论帖子基于jev的魔法吟唱小游戏

什么是 jev

评论帖子offer收到，爽了，开心！

啥城市呀咋样嘞

评论帖子offer收到，爽了，开心！

我现在也是外包阿里的外包基本不加班。这个在入职前都可以和 hr 了解。