服务器
该标签下有 15 篇文章
Linux内核CVE-2026-98432：可通过网络触发的TCP释放后使用漏洞（CVSS 9.8）；请安装已修复的内核、重启并检查MPTCP
CVE-2026-98432是Linux内核IPv4 TCP代码中的一个释放后使用漏洞，于2026年10月15日公布。内核项目的CNA给出CVSS v3.1 9.8分（网络、无需权限、无需用户交互）。据报道，一家AI公司的研究人员在实验室中、依据其自身报告，演示了针对带有Multipath TCP（MPTCP）监听器的服务器以root身份远程执行代码。BleepingComputer称，针对普通TCP服务器的远程代码执行尚未公开展示，也未确认有在野利用，本站于11月1日在CISA的KEV目录中没有找到该CVE。上游修复包含在5.10.272、5.15.223、6.1.190、6.6.159、6.12.113、6.18.56和7.2.10及之后的版本中。截至11月1日，Debian已有修复的内核，SUSE有部分，Ubuntu和Red Hat将修复列为进行中。仅禁用MPTCP并不是完整的修复。本站的结论是：随着修复发布，更新面向互联网的Linux服务器并重启，仅在此之前使用厂商的临时缓解措施。
紧急PHP更新后该检查什么：Web PHP与命令行PHP、set -e与diff退出码，以及入侵复查
在2026年10月应对严重PHP漏洞期间，本站运营者管理的一个站点已更新了Web端PHP，但cron使用的命令行PHP仍指向旧版本。应分别检查Web和CLI。使用set -e时，diff和grep以退出状态1表示“发现差异”或“无匹配”，这会使脚本停止；应分别处理0、1和2。补丁之后，对每台服务器运行相同的入侵检查清单；对于可疑的日志条目，通过将实时文件与已知良好的部署副本进行比较来确认。
VMware ESX CVE-2026-41709（CVSS 2.7）：CISA将这一低危日志漏洞列为已被利用；请修补整份VMSA-2026-0006并检查主机
CVE-2026-41709是VMware ESX中的日志记录不足漏洞（CVSS 2.7，低危）：已经拥有管理员权限的攻击者可以执行某些操作而不被记录到日志中。Broadcom已于2026年7月29日在公告VMSA-2026-0006中修复，没有变通方案。2026年10月28日（美国时间），CISA将其加入已知被利用漏洞（KEV）目录，美国联邦机构的截止日期为11月11日。一家安全公司的威胁报告称，一个与中国有关联的组织在对美国多个组织的入侵中将其作为零日漏洞使用，最晚到2026年初，SecurityWeek将其目的描述为降低审计痕迹的可见性；本站尚未独立核实该报告。该漏洞本身不提供入口，但意味着受影响主机的日志可能无法显示入侵者做了什么。同一公告还包含两个评级为9.8的vCenter漏洞，其中之一（CVE-2026-59310）已于8月18日被CISA列为已被利用，因此只修补ESX漏洞会让入口依然敞开。本站的结论是：把ESX和vCenter更新到整份公告对应的修复版本，把主机日志发送到另一台服务器，并查找入侵迹象，而不是只相信日志。
Linux内核Fragnesia（CVE-2026-46300）：CISA列为已被利用，截止日期为10月31日；请修补PHP和内核，然后重启
CVE-2026-46300，绰号Fragnesia，是Linux内核中的一个漏洞，可让低权限的本地用户获得root权限（CVSS v3.1 7.8，本地攻击向量）。内核在网络缓冲区之间移动数据片段时，可能丢失一个标记，该标记表示这些数据与内存中的某个文件共享，随后IPsec ESP代码可能在该只读文件的缓存副本上直接解密并覆盖。内核项目于2026年5月23日发布了该CVE，修复包含在内核5.10.257、5.15.208、6.1.174、6.6.141、6.12.91、6.18.33和7.0.10及之后的版本中。2026年10月28日（美国时间），CISA基于存在活跃利用的证据，将其加入已知被利用漏洞（KEV）目录，美国联邦机构的截止日期为10月31日。CISA的描述称，它可与PHP漏洞CVE-2026-109618和CVE-2026-109619串联，植入PHP webshell并以root身份执行命令。一家安全公司报告称，这条利用链被用于攻击25台服务器（大多是防火墙），SecurityWeek转述了该报告；本站未独立核实这些数字。Ubuntu、Red Hat和Debian已发布修复内核，而内核更新只有在重启后才会生效。本站的结论是：如果您在Linux上运行PHP网站，请更新PHP和内核，重启，并检查是否有webshell。
Nextcloud 内置 Collabora CODE 服务器漏洞 CVE-2026-110447 被利用：受影响范围与应对措施
2026 年 10 月 14 日，Collabora Online 开发者披露了 CVE-2026-110447，这是 Nextcloud 应用 Collabora Online - Built-in CODE Server（应用 ID richdocumentscode）中的一个未认证操作系统命令注入漏洞。通过该应用的 proxy.php，命令可以以 Web 服务器用户身份运行。前提条件是内置 CODE 服务器未在运行，这种情况可能出现在容器重启、升级或崩溃之后。26.4.303 之前的版本受影响；26.4.303 于 9 月 11 日发布。开发者称，禁用该应用无法解决问题，建议用户更新或移除该应用。对于已停止维护的 Nextcloud 29 及更早版本，需要更新 Nextcloud 或移除该应用。开发者称，独立部署的 Collabora Online 服务器、Docker 镜像、RPM/DEB 软件包和 Nextcloud All-in-One 不受影响。CVSS v4.0 评分为 9.2。CISA 于 10 月 23 日将该漏洞加入已知被利用漏洞（KEV）目录，截止日期为 10 月 26 日。用户在开发者代码仓库中报告了约自 9 月 10 日起的攻击，据媒体报道，攻击者植入了 Web Shell。本站结论：如果安装了内置 CODE 应用，即使已禁用，也请立即检查版本，更新或移除该应用，然后检查自 9 月 10 日以来的入侵痕迹。
GitLab CVE-2026-110264（CVSS 10.0）与已被利用的 CVE-2026-97229：如何检查并更新自托管 GitLab
2026 年 10 月 21 日，GitLab 为社区版（CE）和企业版（EE）发布了关键补丁版本 19.5.1、19.4.3、19.3.6、19.2.9、19.1.9、19.0.10 和 18.11.13。其中最严重的漏洞 CVE-2026-110264（CVSS 10.0）是在编译经过特殊构造的正则表达式时出现的整数溢出，在某些条件下可能使未经身份验证的用户在 GitLab 服务器上执行任意代码。自 7.0 起几乎所有版本都受影响。10 月 29 日，CISA 将与之相近的漏洞 CVE-2026-97229（CVSS 10.0，CWE-190）列入已知被利用漏洞（KEV）目录，处置期限为 11 月 1 日。它是同一类漏洞（CI/CD 正则表达式编译器中的整数溢出，未经身份验证的用户即可触及），GitLab 已于 10 月 12 日在 19.4.2、19.3.5 和 19.2.8 中修复，仅影响 19.2.0 至 19.2.7、19.3.0 至 19.3.4 和 19.4.0 至 19.4.1。仍低于 19.4.2、19.3.5 或 19.2.8 的实例，暴露在一个已被利用的漏洞之下。升级到本文推荐的版本（19.5.1、19.4.3、19.3.6、19.2.9）同样可以修复 CVE-2026-97229。GitLab.com 已完成修补，自托管实例需要升级。10 月 21 日的同一版本还修复了两个高危漏洞（CVSS 8.2 和 7.5）以及其他漏洞，但这些修复仅在 19.3.6、19.4.3 和 19.5.1 分支中提供。该问题的根源在于 Ruby 的正则表达式引擎（Onigmo），Ruby 于 10 月 23 日发布了 4.0.9、3.4.12 和 3.3.13。从攻击者可控字符串编译正则表达式的应用会受影响，而 Regexp.timeout 无法防范这些漏洞。GitLab 的公告未说明 CVE-2026-110264 已被利用，截至 10 月 30 日它也不在 KEV 中。Alpine Linux 报告称，其自己的 GitLab 在 10 月 20 日和 21 日遭到通过 CVE-2026-97229 的攻击尝试，并且只升级 GitLab（到 19.3.6）没有堵住该漏洞，因为修复还需要打过补丁的 Ruby；它重建了该实例，并未发现攻击者代码被运行的证据。本站的结论：核对必须经过的升级节点后，今天就升级自托管 GitLab，最终升级到 19.3.6 或更高版本；如果您自行构建 GitLab 或运行自己的 Ruby，也请确认 Ruby 为 3.3.13、3.4.12 或 4.0.9 或更高版本。Ruby 应用应升级到已修复的 Ruby，并停止从用户输入构建正则表达式。
SiteGuard Server Edition 漏洞 CVE-2026-106931 已被利用：哪些用户受影响，该怎么做
2026 年 10 月 14 日，EG Secure Solutions 披露了 CVE-2026-106931。这是其主机型 Web 应用防火墙（WAF）SiteGuard Server Edition 统计功能中的操作系统命令注入漏洞，并称已确认存在利用。利用该漏洞，可能以 root 或 SYSTEM 权限在运行该产品的服务器上执行任意操作系统命令。受影响的是启用统计功能（默认启用）的 Ver2.20 及以后版本：Ver8.00 Update5 之前的 Apache、Nginx 和 IIS 版，以及 Ver7.00 Update6 之前的 FreeBSD Apache 和 Nginx 版。IIS 版 Ver3.10 至 Ver4.00 Update4 不受影响。修复版本为 Ver8.00 Update5 和 Ver7.00 Update6；无法升级的系统可使用补丁，包括已终止支持的版本。厂商将该漏洞评为本地攻击向量、需要低权限（CVSS v3.0 7.8，v4.0 8.5）。JPCERT/CC 发布了警示，称已确认该产品在日本被广泛使用，并称关闭统计功能可规避该问题。CISA 于 10 月 20 日将该漏洞列入已知被利用漏洞（KEV）目录，截止日期为 10 月 23 日。本站结论：如果您运行 Server Edition，请今天就确认版本和统计功能，更新前先保存诊断数据，然后应用修复版本或补丁。
【突发】PHP 漏洞 CVE-2026-109618 与 CVE-2026-109619 已遭利用，被列入 CISA KEV 目录：请立即更新至 8.5.12、8.4.27、8.3.36 或 8.2.35
2026年10月21日，PHP 安全团队发布了 PHP 8.5.12、8.4.27、8.3.36 和 8.2.35，修复了两个可能允许未经认证的远程代码执行（RCE）的严重漏洞，并敦促所有用户立即更新。CVE-2026-109618 涉及内存耗尽时的处理，CVE-2026-109619 涉及请求之间残留的过期内部状态；两者在 CVSS v4.0 下均被评为 9.2。所有处理网页请求的 PHP 安装都有风险（PHP-FPM、Apache mod_php、php-cgi、FrankenPHP、LiteSpeed）。该团队认为 mod_php 风险最高，并援引了一个已演示的利用方式：未经认证的请求会在任何应用代码运行之前触发攻击。PHP 8.1 及更早版本不会获得官方更新；该团队为 7.4、8.0 和 8.1 提供了最小化的源代码回移补丁。Linux 发行版提前收到了补丁。目前没有完整的缓解方案，更新是唯一安全的选择。10月22日，日本 IPA 与 JPCERT/CC 发布警报，JVN 发布了 JVNVU#99905564。CISA 在首次发布警报时尚未观察到利用，但已于10月26日将这两个漏洞列入其已知被利用漏洞（KEV）目录，并为美国联邦民事机构设定了10月29日的期限。据媒体报道，一名安全研究人员运行未打补丁的 PHP 8.4.26（mod_php）的蜜罐于10月24日遭到成功的远程代码执行。一家大型云服务商的蜜罐在披露前四天（10月17日）就已监测到利用尝试。据本站所查，截至10月27日，尚无蜜罐以外的入侵被公开。日本大多数主要共享主机服务商已宣布修复已应用，但部分服务商（如 KAGOYA）尚未宣布。10月23日，PHP 团队披露了第三个问题（CVE-2026-115560），该问题未被10月21日的版本修复。它只有在特定的配置和应用代码组合下才可能导致代码执行；该团队认为实际中不太可能出现，将在下一个常规版本中发布修复和完整公告，并建议在此之前设置 session.upload_progress.enabled=0。受影响的版本和 CVSS 评分尚未公布，也未报告任何利用行为。截至10月29日（在 php.net 上查看），该问题的修复版本尚未发布。10月28日，CISA 还将 Linux 内核漏洞 CVE-2026-46300 列入 KEV（美国联邦机构的期限为10月31日），并表示它可以与这两个漏洞串联，用于植入 PHP webshell 并以 root 身份执行命令。本站观点：利用现已得到确认，请确认你或你的服务商是否为每个站点更新 PHP，并立即升级到修复版本。同时请检查10月17日起的日志，查找入侵迹象。在共享主机上，请在服务商官方网站上查看其完成通知。
网站安全会影响 SEO 吗？依据 Google 官方文档，梳理漏洞、网站被黑、HTTPS 与搜索排名的关系
Google 没有把漏洞列为排名因素。真正的损害发生在漏洞被利用之后。被黑后出现的垃圾页面会让搜索结果显示「This site may be hacked」（此网站可能已遭到入侵）标签；恶意软件或网络钓鱼会触发 Chrome 的「Dangerous site」（危险网站）警告（其他浏览器也会显示各自的 Safe Browsing 警告）；违反垃圾内容政策的网站，排名可能下降，甚至完全不出现在结果中。HTTPS 在 2014 年被宣布为「非常轻量」的信号，而 Google 现行的页面体验文档说明，除 Core Web Vitals 外，其他页面体验方面并不会直接帮助网站提高排名。本站的看法：从 SEO 角度，与其花时间提高安全评分，不如把精力放在不被入侵、以及被入侵时尽快发现。
如何检查网站或服务器是否被入侵：共享主机、WordPress 和 VPS 的逐步检查，以及发现问题后最先做什么
检查站点是否被入侵，要同时看外部可见的迹象和服务器内部留下的痕迹。迹象：Search Console 的「Security issues」（安全问题）报告、搜索结果中的「This site may be hacked」（此网站可能已遭到入侵）标签、主机商的通知、陌生的管理员、只在手机上或只从搜索进入时才发生的跳转。痕迹：管理员用户、被修改的核心文件（wp core verify-checksums）、登录记录、authorized_keys、cron、监听端口、最近被修改的文件。本站的看法：什么都没找到并不能证明是干净的。如果发现了问题，先保全证据再清理，从干净的设备更换所有凭据，从入侵前的备份恢复或重建，堵住入口，最后再申请审核。
是否把密钥文件遗忘在了公开目录里：webroot 盘点
放进 webroot 的文件，任何人都能通过 URL 取走。令牌或认证凭据的 JSON、.env、备份一旦遗忘在那里，就会立即暴露；如果源自共用模板，所有站点都带着同一个文件。对策：公开目录只放可以公开的东西，密钥放在 webroot 之外并设为权限 600，一旦发现一处，就排查所有站点和主机。
安全资产盘点：个人运维多台服务器时最易忽略的 7 项检查
个人运维多台服务器的事故，往往源于「没掌握的状态」而非「缺少防护」。要守的边界是放置密钥的电脑。2FA 按「哪个账号能恢复其他账号」排定优先级（邮箱最先），列出哪把 SSH 密钥能打开哪台服务器，并删除重复、未使用和残留的注册，明文密码从云端清除，整改要可逆且逐项进行，台账里不写机密。比起花哨的新工具，盘点更优先。
自建 Git 服务器和 GitHub，从安全角度看哪个更安全
自建 Git 不是『变安全』，而是『转移风险』。误公开这一类事故确实会消失，但服务器补丁、备份、提交前密钥检测的责任会转移到你身上。能持续做好这些工作就是好选择，放任不管则比 GitHub 更危险。本站视角＝自建运营必须连同补偿性对策一起，否则无法成立。
SSH 密钥的最小权限：别把生产的 root 密钥放进可能被入侵的临时环境
从可能被入侵的临时环境（GPU pod、CI runner、一次性 VM）向生产登记 root 密钥，那个环境一旦被入侵，攻击者就能拿到生产的 root 权限。对策：不在临时环境放 root 密钥；不用了就删掉；再次需要时，用非 root 用户加上把密钥限定为一个操作的 command 限制密钥。把复用的密钥当作最重要的资产，绝不要搭出漏一把密钥就能打开所有服务器的结构。
在虚拟主机上避免 .env 被公开的目录布局与配置
核心是『把应用主体放在 docroot 之外，只公开 public/』。先用 .htaccess 拦截访问，再通过结构改造实现长期防护，最后自我检查。本站的看法：这不是个人的疏忽，而是危险的目录布局在行业里成了标准，所以要靠机制而不是注意力来防御。bootstrap-redirect 比 symlink 更稳。