【攻击检测规则与迹象排查】PHP 远程代码执行漏洞(CVE-2026-109618、CVE-2026-109619)安全风险通告

2026年10月26日00:24:06评论42 views字数 11602阅读38分40秒阅读模式

奇安信CERT发布PHP远程代码执行漏洞(CVE-2026-109618、CVE-2026-109619)安全风险通告，漏洞源于请求生命周期边界状态管理缺陷可致UAF，无需认证即可触发内存泄漏与远程代码执行，PoC已公开且发现在野利用，影响PHP 8.2/8.3/8.4/8.5多个版本，建议尽快升级并重启服务。

● 点击↑蓝字关注我们，获取更多安全风险通告

漏洞概述
漏洞名称	PHP 远程代码执行漏洞
漏洞编号	CVE-2026-109618、CVE-2026-109619
公开时间	2026-10-21	影响量级	千万级
奇安信评级	高危	CVSS 3.1分数	8.1
威胁类型	代码执行	利用可能性	高
POC状态	已公开	在野利用状态	已发现
EXP状态	已公开	技术细节状态	已公开
危害描述：可导致无需认证的堆 UAF、内存泄露和远程代码执行，攻击者以 Web worker 权限执行任意命令，写入 WebShell、窃取凭据和业务数据、横向移动并植入持久化后门。

漏洞详情

>>>>

影响组件

PHP 是一种广泛使用的开源服务器端脚本语言，主要运行于 Web 服务器端，支持 Apache mod_php、PHP-FPM（配合 Nginx、Apache mod_proxy_fcgi）、FrankenPHP、LiteSpeed LSAPI 等多种部署方式。W3Techs 统计显示，全球约四分之三的网站使用 PHP 作为服务器端编程语言，WordPress、Drupal、Joomla、MediaWiki、Magento、phpMyAdmin、Nextcloud、Laravel、Symfony、WHMCS 等主流应用均依赖 PHP。

>>>>

漏洞描述

近日，奇安信CERT监测到官方修复PHP 远程代码执行漏洞(CVE-2026-109618、CVE-2026-109619)，两个 PHP 漏洞都源于请求生命周期边界的状态管理缺陷，可导致释放后重用。攻击者无需认证，发送恶意 HTTP 请求即可触发内存泄漏乃至远程代码执行。目前该漏洞PoC和技术细节已公开。鉴于该漏洞已发现在野利用，建议客户尽快做好自查及防护。

本次更新内容：

新增攻击检测规则与迹象排查。

>>>>

利用条件

无需登录、无需用户交互、无需应用层漏洞；攻击面为可接收 HTTP 请求的 PHP 端点，包括静态站点中的简单 PHP 页面。

影响范围

>>>>

影响版本

PHP < 8.2.35

PHP < 8.3.36

PHP < 8.4.27

PHP < 8.5.12

仍在维护的分支：

PHP 8.5、8.4、8.3 仍处于现行维护期，应优先升级到对应修复版本或更高版本。8.2.35 是当前可用的修复版本，也是 8.2 分支最后的升级时间窗口之一；建议尽快规划升级到 8.3 或更高版本。

已停止维护的分支：

PHP 8.1、8.0、7.4 及更早版本已停止官方支持，PHP 官方不再发布修复版本。

PHP ≤ 7.3 / 5.x 同样已停止维护，官方不提供修复版本，应优先升级。

>>>>

其他受影响组件

以 PHP 为运行时的应用、框架与建站系统可能间接受影响，涉及 WordPress、MediaWiki、phpBB、Magento、Laravel、Symfony、Drupal 等，以及 mod_php、PHP-FPM（含 Docker PHP-FPM 镜像）等部署形态。

复现情况

目前，奇安信CERT已成功复现PHP 远程代码执行漏洞(CVE-2026-109618、CVE-2026-109619)，截图如下：

【攻击检测规则与迹象排查】PHP 远程代码执行漏洞(CVE-2026-109618、CVE-2026-109619)安全风险通告

处置建议

>>>>

安全更新

官方已发布安全补丁，请及时更新至最新版本：

PHP 8.5.12

PHP 8.4.27

PHP 8.3.36

PHP 8.2.35

下载地址：

https://www.php.net/downloads.php

1. 升级后必须重启 Apache、PHP-FPM 及所有常驻 worker，确保旧进程不再处理请求；仅替换二进制而不重启进程不能消除风险。

2. 容器环境应重新构建镜像，避免沿用包含旧 PHP 的 layer；Kubernetes 环境应滚动重启所有 Pod，并确认没有旧 ReplicaSet 继续服务。

3. 发行版仓库（Ubuntu、Debian、RHEL、Alpine 等）和集成环境（宝塔、phpStudy、XAMPP、Docker 官方镜像等）可能存在同步延迟，请以 `php -v`、`php-fpm -v` 的实际输出为准，不要仅核对包管理器版本号。

4. PHP 8.1 及更早版本已停止支持，官方不再提供补丁，建议迁移至 PHP 8.2 或更高版本；若使用发行版长期支持分支，请以厂商 backport 公告为准。

5. 共享主机和虚拟主机用户应联系服务商确认 PHP 版本；多租户环境需确认所有租户实例均已升级。

注意：

不要使用 RLIMIT_AS 或 RLIMIT_DATA 作为缓解措施。这些限制会导致 mmap() 失败，从而触发 CVE-2026-109618 所依赖的 longjmp() 路径。

>>>>

缓解措施

1.关闭 fatal backtrace

fatal_error_backtraces = 0

只阻断 109619 已确认的 backtrace 路径，不影响其他变体。

2.限制请求形态

post_max_size = 8M ; 不需要上传时；需要上传可设 32M

upload_max_filesize = 8M ; 必须小于 post_max_size

max_input_vars = 200 ; 默认 1000，按业务调整

max_input_nesting_level = 10 ; 默认 64

max_multipart_body_parts = 20 ; PHP 8.1+，默认可能较大

max_file_uploads = 5 ; 默认 20

3.阻断 multipart/form-data （适用于不需要上传的站点/路径）

Nginx：

map $http_content_type $mp_block {    default 0;    "~*multipart/form-data" 1;}server {    if($mp_block) { return 403; }}

Apache：

RewriteEngine OnRewriteCond %{HTTP:Content-Type} multipart/form-data [NC]RewriteRule ^ - [F]

Caddy：

@multipart header Content-Type *multipart/form-data*respond @multipart 403

注意：

会破坏后台上传、商品图、结算表单；可只对特定 vhost/路径启用，或把上传接口单独放到一个受控 vhost。

对需要上传的业务，改用“限制 + 认证 + 监控”，不要直接全站阻断。

>>>>

产品解决方案

奇安信网神云锁服务器安全管理系统（椒图）检测方案

奇安信网神云锁服务器安全管理系统（椒图）默认已有RCE规则支持检测，无需升级特征库。

奇安信天眼检测方案

奇安信天眼新一代安全感知系统已经能够有效检测针对该漏洞的攻击，请将规则版本升级到3.0.1021.15155或以上版本。规则ID及规则名称：

0x10022A87，PHP 远程代码执行漏洞(CVE-2026-109618/CVE-2026-109619)。奇安信天眼流量探针规则升级方法：系统配置->设备升级->规则升级，选择“网络升级”或“本地升级”。

临时检测方案：分析中心->日志检索->网络日志->Web访问日志，过滤语句：data: ("PHP_SESSION_UPLOAD_PROGRESS")。如果请求体中包含大量垃圾字符或PHP反序列化数据，说明受到该漏洞攻击。

奇安信网神网络数据传感器系统产品检测方案

奇安信网神网络数据传感器（NDS5000/7000/9000系列）产品，已具备该漏洞的检测能力。规则ID为：8259、8260，建议用户尽快升级检测规则库至2610221013或以上。

奇安信开源卫士已支持

奇安信开源卫士20261022.1527 版本已支持对 PHP 远程代码执行漏洞(CVE-2026-109618、CVE-2026-109619)的检测。

奇安信网站应用安全云防护系统已更新防护特征库

奇安信网神网站应用安全云防护系统已全局更新所有云端防护节点的防护规则，支持对PHP 远程代码执行漏洞(CVE-2026-109618、CVE-2026-109619）的防护。

奇安信自动化渗透测试系统检测方案

奇安信自动化渗透测试系统已经能够有效检测针对该漏洞的攻击，请将插件版本和指纹版本升级到202610222579以上版本。规则名称：PHP 远程代码执行漏洞(CVE-2026-109618、CVE-2026-109619)。奇安信自动化渗透测试系统规则升级方法：系统管理->升级管理->插件升级（指纹升级），选择“网络升级”或“本地升级”。

奇安信天擎终端安全管理系统检测方案

天擎终端安全管理系统已具备针对 PHP 进程异常启动及可疑进程行为的云端检测能力，建议用户开启云查功能，可对相关异常行为进行检测、告警或拦截。

同时，天擎 EDR 支持通过自定义检测规则对相关可疑攻击行为进行监控，用户可根据实际业务场景灵活配置检测规则。

针对 CVE-2026-109618、CVE-2026-109619 漏洞，天擎正在进一步完善相关 EDR 检测规则，计划于近期通过规则库更新提供。建议用户保持天擎规则库及时更新，以获取最新的安全检测能力。

奇安信SaaS 天戟AI智能渗透测试平台检测方案

该平台支持对对外暴露的业务系统网站进行自动化扫描，可快速精准识别 PHP 远程代码执行等漏洞，并全面掌握站点的整体漏洞风险。企业注册默认赠送积分，该积分支持扫描1-2个站点。

使用流程：

1.登录 https://ai.qianxin.com，注册企业账号；

2.提交站点归属授权函；

3.授权通过后即可开始扫描。

服务器核查手册

>>>>

远程排查

远程检测参考链接如下：

https://github.com/Ademking/php2shell-nuclei-templates/tree/main/templates/php2shell
https://github.com/ikow/php2shell-poc/tree/main/detection

1. 找全入口

测所有端口（80/443/8080/8443 等）、所有 vhost、IPv6、CDN 源站直连。

示例：

for p in 80 443 8080 8443; do  curl -sS -k -D - -o /dev/null --max-time 8 "https://目标:$p/" | grep -iE '^(HTTP/|server:|x-powered-by:)'done

2. 被动看响应头

curl -sS -D - -o /dev/null https://目标 | grep -iE '^(server:|x-powered-by:|set-cookie:)'

看到 `X-Powered-By: PHP/x.y.z` 且低于修复版 → 高度怀疑受影响

什么都没有 → 不能判安全（按受影响处理）

PHP 8.2.35

3. 结论：

版本可见且低于修复版 → 按受影响处理。
版本可见且达标 → 可能已修，仍需本地确认。
版本不可见 → 按受影响处理。

注意：在线 checker（Aikido / Flawfence 等）可能打挂 worker，只在授权 + 低峰使用；“未检出”不等于安全。

>>>>

本地排查

1. 找正在跑的 PHP 二进制

ps -eo pid,lstart,args | grep -E 'hp-fpm|[a]pache2|[h]ttpd|[l]sphp'sudo readlink -f /proc/$(pgrep -f php-fpm | head -1)/exe

2. 看版本 + 构建日期

php-fpm8.3 -v          # 换成实际二进制名

3. 看包是否有 backport

Debian/Ubuntu：

zgrep -i CVE-2026-1096 /usr/share/doc/php*/changelog* 2>/dev/null

RHEL 系：

rpm -q --changelog php83-php | grep -i CVE-2026-1096

4. 确认 SAPI 与实际生效版本

在网站根目录放：

<?phpheader('Content-Type: text/plain');echo 'PHP_VERSION=', PHP_VERSION, "n";echo 'SAPI=', php_sapi_name(), "n";

访问后删除。

SAPI=apache2handler` → mod_php（最高危）
SAPI=fpm-fcgi` → PHP-FPM

5. 确认已重启生效

sudo systemctl restart php8.3-fpm apache2   # 或对应服务ps -eo pid,lstart,cmd | grep -E 'hp-fpm|[a]pache2'

进程启动时间必须晚于补丁安装时间，再访问探针确认版本已变。

容器/K8s/面板：必须重建镜像或滚动 Pod，不能只 docker restart；cPanel/Plesk/宝塔要分别查各自的 PHP 路径。

>>>>

判定结论

本地证据	结论
任一在用 SAPI 的二进制低于修复版，且无 CVE backport	受影响
版本达标 + 进程启动时间晚于补丁安装	已修复
版本达标 + 进程启动时间早于补丁安装	未生效，立即重启
≤8.1 且无厂商 backport	升级或隔离
无法确认	按受影响处理

>>>>

修复验证

验证步骤：重启服务 → 确认进程启动时间 → 再访问探针看版本 → 多 vhost/多容器逐个确认。

攻击检测规则与迹象排查

适用场景：nginx + PHP-FPM、Apache mod_php、Apache + proxy_fcgi 等常见部署。

影响版本：PHP < 8.5.12 / 8.4.27 / 8.3.36 / 8.2.35。

检测规则参考链接如下：

https://gist.github.com/Blevene/472692937d05145d29d17dc3c6edc2a0

>>>>

攻击原理

攻击针对同一个 PHP worker，通常分两步：

1.ARM（武装）：发送畸形 multipart/form-data POST（超长内容、大量文件字段、超长重复字符文件名），在解析阶段触发内存耗尽（OOM）。错误表现为 in Unknown on line 0 的 fatal，导致 session 等全局状态残留。

2.FIRE（触发）：同源再发一次 multipart POST，利用残留状态造成 UAF，可能导致 worker SIGSEGV，或在成功时返回干净 200 并执行代码。

关键结论：

•不看请求体也能检出（长度 + 状态码 + 错误日志）。

•成功与否必须下沉到进程层判断，HTTP 2xx 不等于成功。

>>>>

检测前准备

1.确认错误日志位置

php-fpm -i | grep -E 'log_errors|^error_log|fastcgi.logging'grep catch_workers_output /etc/php/*/fpm/pool.d/*.conf

•nginx + FPM：fastcgi.logging=On → nginx error log；catch_workers_output=yes → FPM 主日志。

•官方 PHP-FPM 镜像默认 log_errors=Off，错误可能只出现在容器 stderr，需额外关注进程层与 access log。

2.确认 PHP worker 运行用户（进程层规则必须用 uid）

ps -o user= -C php-fpm | sort -u# 常见：33=www-data，48=apache

后续 auditd / Falco 规则请按实际 uid 配置，不要按 pid（worker 会轮转）。

>>>>

核心检测

R1·ARM：脚本外内存耗尽 fatal（最高精度，全栈通用）

采集点：PHP error log / nginx error log / Apache ErrorLog / FPM 主日志。

匹配逻辑（token 组合，避免整句匹配，因 display_errors=1 可能被 HTML 包裹）：

"Allowed memory size of" AND "exhausted"AND ("in Unknown on line 0" OR "in <b>Unknown</b> on line <b>0</b>")

•in Unknown on line 0 是关键判据：正常业务 OOM 会指向具体脚本路径与行号。

•无大文件上传业务的站点可直接视为 critical；有上传业务的站点视为 high。

R2·FIRE：FPM worker 段错误 / 崩溃

采集点：FPM 主日志、kern.log、journalctl -k。

匹配示例：

•FPM：exited on signal 11 (SIGSEGV) 或 exited with code 70

•内核：segfault at ... in php-fpm[pid:

•nginx 伴随现象：upstream prematurely closed connection while reading response header 或 upstream sent unexpected FastCGI record: 3，状态码多为 502（而非 500）。

R3·Access log 关联（无需解密 HTTPS，生产环境最强信号）

仅用请求长度 + 状态码即可。nginx 示例（$request_length 含 body）：

同一 $remote_addr、10 分钟内出现：

•(a) POST multipart 且 $request_length ≥ 2 × memory_limit，返回 5xx → ARM

•(b) POST multipart 返回 502 → FIRE

•(a) 后紧跟 (b) → 高度可疑武装攻击，立即深入排查

单次超长 POST 可能是扫描；AB 成对且多轮重复通常为真人调参攻击。

建议日志格式增加 SID 便于后续关联：

log_format php_sid '$remote_addr [$time_local] "$request" $status$request_length sid=$cookie_PHPSESSID';

Apache（需 mod_logio）：

LogFormat "%a%t "%r" %>s %I sid=%{PHPSESSID}C" php_sid

R4·结构指纹（能查看 body 时精度极高）

一次请求中出现数百个文件名由同一字符重复构成、且同名字段数组化的 file part → 几乎可判定为攻击（正常表单不会出现）。

R5·官方缓解项反用作检测（零误报，前提是已加固配置）

已配置项	出现即视为攻击
`session.upload_progress.enabled=Off`	任何 POST 带 `PHP_SESSION_UPLOAD_PROGRESS` 字段
`memory_limit=-1`	任何 “Allowed memory size … exhausted”
已打补丁且 `fatal_error_backtraces=0`	日志中出现 backtrace

ModSecurity 示例（注意：multipart 下 REQUEST_BODY 为空，旧规则永远不触发）：

SecRule ARGS_POST_NAMES|FILES_NAMES "@streq PHP_SESSION_UPLOAD_PROGRESS"   "id:2026106183,phase:2,deny,status:403,log,msg:'PHP2Shell probe'"

R6·post_max_size / max_file_uploads 绕过检测（补丁前视同恶意）

•绕过一：multipart + (Transfer-Encoding: chunked | 无 Content-Length | 代理解码后大小不符)

•绕过二：单 body 内 filename="" 的 part ≥ 10

SecRule MULTIPART_PART_HEADERS "@rx (?i)^content-disposition:.*;s*filename="""   "id:2026106186,phase:2,pass,nolog,setvar:tx.php_cve_empty_fn=+1"SecRule TX:php_cve_empty_fn "@ge 10"   "id:2026106185,phase:2,deny,status:403,log,msg:'PHP2Shell max_file_uploads bypass'"

R7·PHPSESSID 内存泄露（响应侧）

正常 PHPSESSID 应为 32 位小写 hex（若修改过 session.sid_length / sid_bits_per_character 需同步调整）：

SecRule RESPONSE_HEADERS:Set-Cookie "@beginsWith PHPSESSID="   "id:2026106184,phase:3,deny,status:403,log,msg:'PHP2Shell stale PS(id) leak',chain"  SecRule MATCHED_VAR "!@rx ^PHPSESSID=[0-9a-f]{32}(?:;|$)"

>>>>

成功判定

成功的 FIRE 往往返回干净 200，失败也可能返回 200。因此需结合以下内核/进程痕迹：

1.worker 产生 shell 类子进程（php-fpm 正常几乎从不 exec）

2.无文件执行：memfd_create + execveat(AT_EMPTY_PATH)，表现为 /proc/<pid>/exe -> /memfd:xxx (deleted)

3.worker 向非常规端口/地址外连（C2/stager）

4.延迟崩溃：污染请求返回 200，崩溃落在同一 worker 的后续请求（需按 worker 关联，而非单请求）

5.会话污染：同一 PHPSESSID 反复出现 “Failed to decode session object” + 段错误；或 sess_<sid> 文件体积异常/含非 UTF-8 垃圾。

判定建议：单 SID 24 小时内 ≥3 次 decode 失败 + 一次段错误 → 按已被攻陷处理（删除会话、轮换、进入 IR）

进程层检测示例

Falco（需支持 proc.is_exe_from_memfd 与 memfd_create）：

- macro: php_worker  condition: (proc.pname startswith php-fpm or proc.pname startswith lsphp or proc.pname in (php, php-cgi))- rule: PHP worker spawned shell or downloader  condition: >    spawned_process and php_worker and    (proc.name in (sh, bash, dash, zsh, curl, wget, perl, nc, ncat, socat, base64, chmod, chown)     or proc.name startswith python)  priority: CRITICAL- rule: PHP worker fileless exec from memfd  condition: spawned_process and php_worker and proc.is_exe_from_memfd=true  priority: CRITICAL- rule: PHP worker called memfd_create  condition: evt.type=memfd_create and evt.dir=< and             (proc.name startswith php-fpm or proc.name in (php, php-cgi))  priority: CRITICAL

auditd（按池用户 uid，示例为 33）：

-a always,exit -F arch=b64 -S execve,execveat -F euid=33 -k php-child-a always,exit -F arch=b32 -S execve,execveat -F euid=33 -k php-child-a always,exit -F arch=b64 -S memfd_create -F euid=33 -k php-memfd-a always,exit -F arch=b32 -S memfd_create -F euid=33 -k php-memfd

先建立基线：部分环境会合法调用 sendmail、图像处理工具等。

>>>>

快速排查

1.错误日志：grep 'Unknown on line 0' + grep 'exited on signal 11'，按源 IP / 时间窗对齐，确认 ARM/FIRE 是否成对。

2.Access log：查找同 IP 的异常长度 multipart POST 与 5xx/502，观察是否多轮重复。

3.进程：ps -ef | grep -E 'php-fpm' 检查是否有 shell/curl/wget 子进程；ls -l /proc/*/exe 查找 memfd:。

4.网络与崩溃：ss -tp | grep php-fpm 查外连；journalctl -k | grep segfault；coredumpctl list php-fpm。

5.会话：定位单个 SID 的重复 decode 失败。

6.任一出现 exec / memfd / 异常外连 → 按已入侵响应（worker 进程内存是现场，不要只删 webshell）。

7.无论结论，立即升级到 PHP 8.5.12 / 8.4.27 / 8.3.36 / 8.2.35 并重启所有 worker。

>>>>

收敛判定表

观测	判定	建议动作
仅 access log 有超长 multipart POST	探测/扫描	封 IP，复查 WAF
+ OOM fatal（Unknown on line 0）	已武装（attempt）	追踪同 worker 数小时内的 FIRE
FIRE 502 / SIGSEGV	attempt（未遂或被拦）	关注重试洪水，观察是否出现干净 200
ARM 后出现干净 200	可疑（失败也会 200）	立即检查进程层三条痕迹
worker 有 exec 子进程 / memfd / 异常外连	确认 RCE	完整事件响应（IR）
单 SID 反复 decode 失败 + segv	很可能成功（会话污染）	删除会话、轮换、进入 IR

>>>>

高风险做法

•依赖 payload 字节签名或单请求字节偏移：填充无意义且偏移随编译变化。

•仅做限速：一发即可完成 ARM，FIRE 紧随其后。

•使用 REQUEST_BODY "@contains PHP_SESSION_UPLOAD_PROGRESS"：multipart 下 REQUEST_BODY 为空，永不触发。

•不要使用 RLIMIT_AS / RLIMIT_DATA（ulimit）作为缓解：官方明确会诱发分配失败，反而助攻；可用性边界应使用 cgroup/容器限额。

>>>>

优先级建议

0.打补丁 + 重启 worker（唯一根治）；

1.未打补丁时：设置 session.upload_progress.enabled=Off + 启用 R5 检测规则；

2.部署 R1 + R2（错误日志 + FPM 崩溃）——精度最高、无需 body；

3.部署 R3 access log AB 关联（并给日志加 SID）；

4.补充 R6 绕过检测 + R7 cookie 泄露检测；

5.部署进程层监控（Falco / auditd）——唯一能确认“成功”的一层；

6.边界 Suricata 结构规则（需 TLS 终结点）。

参考资料

[1]https://github.com/php/php-src/security/advisories/GHSA-w8hw-w9fx-j79w

[2]https://github.com/php/php-src/security/advisories/GHSA-6wmf-4rv5-p3rp

[3]https://calif.io/php2shell/#writeup

时间线

2026年10月21日，漏洞公开披露：CVE 信息已公开，可据此核对受影响产品与版本并启动修复。

2026年10月22日，奇安信 CERT已复现该漏洞，发布安全风险通告。

2026年10月22日，该漏洞已发现在野利用，发布安全风险通告第二次更新。

2026年10月22日，新增受影响核查、临时解决方案，发布安全风险通告第三次更新。

2026年10月25日，新增攻击检测规则与迹象排查，发布安全风险通告第四次更新。

原文始发于微信公众号（奇安信 CERT）：【攻击检测规则与迹象排查】PHP 远程代码执行漏洞(CVE-2026-109618、CVE-2026-109619)安全风险通告

免责声明:文章中涉及的程序(方法)可能带有攻击性，仅供安全研究与教学之用，读者将其信息做其他用途，由读者承担全部法律及连带责任，本站不承担任何法律及连带责任；如有问题可邮件联系(建议使用企业邮箱或有效邮箱,避免邮件被拦截，联系方式见首页)，望知悉。

左青龙
微信扫一扫

右白虎
微信扫一扫

【攻击检测规则与迹象排查】PHP 远程代码执行漏洞(CVE-2026-109618、CVE-2026-109619)安全风险通告

PostgreSQL pg_restore 代码执行漏洞（CVE-2026-116314）

WordPress插件爆出未授权代码执行漏洞(POC已公开)，暂无补丁CVE-2026-115252

【高危漏洞预警】Apache HTTP Server mod_http2竞态条件远程代码执行漏洞（CVE-2026-119618）

派拓网络披露PAN-OS RCE漏洞，攻击者可获root权限执行任意代码

安全预警：Chrome 0day 漏洞来袭，附本地版本检测脚本，快速自查风险

Palo Alto 修复PAN-OS RCE 漏洞，可导致任意代码执行

赛博安全狗：XWEB EVO 5.6.2之前版本存在严重命令注入漏洞CVE-2026-124010 (11.13)

【已复现】7-Zip LZX 解码器堆越界写入漏洞(CVE-2026-125742)安全风险通告

Apache OFBiz 任意代码执行漏洞(CVE-2026-83542)通告【已复现】

N-able 紧急发布多个 0day 漏洞的热修复方案

发表评论

在线咨询

微信