2026-10-22 12:43:13 网络安全文章来源：ZONE.CI 全球网 0 阅读模式

Drupal 网站可能被 “免登录接管”：这类 RCE 漏洞为什么要马上排查

汇能云安全

2026年10月20日 11:07
广东

去阅读

10月20日，星期二，您好！中科汇能与您分享信息安全快讯：

Drupal 网站可能被 “免登录接管”：这类 RCE 漏洞为什么要马上排查

Drupal 安全团队近期发布更新，修复核心 Field UI 模块中的严重远程代码执行漏洞 CVE-2026-108097，相关安全公告编号为 SA-CORE-2026-014，据披露，攻击者无需登录就可能利用该问题对受影响网站执行代码，最坏情况下直接取得网站控制权，当前摘要没有给出统一受影响版本清单，因此不能简单用一个版本号判断安全，实际部署必须对照官方公告逐项核验。很多单位把内容管理系统当成普通网站后台，认为即使出问题也只是页面被篡改。现实并不是这样，Drupal 往往连接用户账号、文件目录、数据库、插件模块和发布流程，一旦远程代码执行成立，攻击者拿到的可能是继续横向移动、植入后门、窃取配置和篡改内容的起点，对于承载政务、教育、医疗或企业业务的门户网站，网站被接管还可能影响公众信任和后续业务流程。处置时不要只做一次版本升级，先盘点所有 Drupal 实例，特别是被遗忘的旧站、测试站和外包建设站点；再按官方公告核对 Field UI 模块状态并完成更新。补丁完成后，应检查异常管理员、近期新增文件、可疑 PHP 脚本、计划任务和数据库账号变化，同时回看 Web 访问日志中是否出现异常参数或非正常命令执行迹象。暂时无法升级的系统，应限制管理入口和相关接口的公网访问，并加强 WAF、主机和文件完整性监控。漏洞修复解决的是入口问题，是否已经被利用还需要另做排查。

微软把 AI 代理当成 “内部人员” 管理，企业安全边界正在改变

微软在 10 月 19 日发布提醒，企业不能因为 AI 代理没有主观恶意，就把它们当成普通软件功能。一个被授权读取公司数据、调用应用、执行代码或操作业务系统的代理，实际上已经拥有了类似内部人员的行动能力，而且执行速度远超人工。一旦上下文被污染、权限配置过宽、工具调用缺少限制，代理就可能把错误指令迅速变成真实的业务动作，这个判断的价值，在于它把 AI 安全从 “模型会不会说错话” 推进到了 “模型能做什么事”。如果代理可以读取源代码、访问客户资料、调用云平台、发送邮件或创建账号，那么风险就不再局限于回答内容。提示词注入、恶意文档、被污染的知识库、第三方插件和泄露的会话令牌，都可能诱导代理跨越原本的业务边界。企业真正需要防的是权限被组合使用后产生的放大效应。部署代理时，建议把它纳入现有身份与访问管理体系，给每个代理配置独立身份、最小权限和明确的资源范围。读取敏感数据、修改生产环境、发起付款、发送外部邮件等动作，应设置人工确认或双重审批。代理调用的工具、输入来源、输出结果和异常行为要留下可检索日志，并对长期密钥改用短时令牌和轮换机制。还要定期用失控、越权和数据外传场景做演练。代理不是普通聊天窗口，谁能给它权限，谁就必须承担相应的审计责任。

STAR Fuzzer 推出 AI 辅助模糊测试能力，帮助发现高危内存安全问题

Bright Security 推出 STAR Fuzzer，利用演化引擎自动编写测试 harness 并验证崩溃、内存耗尽和内存安全问题。其首次开源研究测试覆盖的项目中，45% 发现了高危或严重问题，该工具不是攻击事件，但说明 AI 正在进入漏洞发现和验证环节。研发团队应把自动化测试纳入安全开发流程，并对发现的问题及时复现、修复和回归验证，这里的重点不是工具宣传，而是漏洞发现速度正在被自动化能力推高，企业不能再把安全测试放在发布前的最后一关。传统模糊测试往往需要安全人员手工理解接口、准备输入并编写测试 harness，成本较高，也容易遗漏复杂代码路径。能够自动生成测试逻辑的工具，可以把更多时间投入到高风险组件、解析器和内存管理代码上。对软件供应商而言，这意味着公开项目和依赖库可能更快暴露缺陷；对使用方而言，则意味着补丁窗口可能进一步缩短。自动发现并不等于自动修复，误报、重复问题和测试环境中的敏感数据泄露仍然需要人工治理。研发团队可以先把这类能力放在隔离的持续集成环境，明确测试代码、样本和崩溃文件的访问边界，避免把生产密钥、客户数据或内部源码无控制地交给外部服务。对每个发现的问题，应建立从复现、定级、修复、回归到发布通知的闭环，并检查问题是否同时存在于下游产品和分支版本。安全团队还应关注自动化工具生成的脚本和依赖，防止测试链路本身成为供应链入口。工具提高了发现速度，组织流程也必须同步提高响应速度。

SiteGuard 防火墙自身被打穿：CVE-2026-106931 已出现真实攻击

SiteGuard Server Edition 被曝存在命令注入漏洞 CVE-2026-106931，攻击者正在利用该漏洞发动攻击。根据公开摘要，问题位于产品统计功能，利用成功后可以执行操作系统命令，并可能获得 root 或 SYSTEM 权限。这里最值得警惕的不是一个普通 Web 组件出错，而是安全产品本身直接安装在被保护服务器上，一旦它被打穿，攻击者可能越过原本依赖的外围防线，进入主机内部。很多企业看到 “这是 WAF 漏洞” 时，第一反应是把它当作网络边界设备问题，重启设备或观察告警就结束了。但 SiteGuard Server Edition 的部署形态意味着它可能拥有较高的本机权限，并接触流量、配置、日志和管理接口。攻击者如果拿到服务器权限，后续目标可能包括凭据窃取、植入持久化任务、修改安全策略以及利用该主机继续访问内网。因此，受影响单位需要把它按主机入侵事件来核查，而不是只按配置缺陷处理。处置顺序应当清晰：先确认资产清单和暴露面，再根据厂商公告完成修复或采取临时隔离措施；限制统计、管理和远程维护接口，仅允许必要的管理来源访问；随后检查异常子进程、Shell 命令、计划任务、服务配置、启动项和外联地址。若主机上保存过管理员密码、API 令牌或证书，不能只升级软件，还要同步轮换凭据并检查其被使用的记录。已经观察到异常的设备应保留日志和磁盘证据，必要时从可信介质重建，避免带着后门重新上线。

仿冒 Teams 登录页的新域名出现，办公账号仍是钓鱼攻击的首要目标

安全研究人员发现，一个新注册的域名 teams-cloud [.] live 复制了 Microsoft Teams 的登录页面和界面，存在用于窃取办公账号的钓鱼风险。公开信息显示，该域名在被发现时仅注册约五天，研究人员建议组织尽快拦截。当前没有证据表明所有访问者都已受害，但 “新域名 + 高度仿冒登录页” 的组合，足以说明攻击者正在利用员工对日常协作工具的信任。这类攻击不一定需要复杂漏洞。攻击者只要把链接伪装成会议邀请、共享文件、团队通知或账号异常提醒，就可能把用户带到看起来很熟悉的页面。用户输入的账号、密码以及后续多因素认证信息，可能被转发给攻击者；即使企业启用了多因素认证，攻击者也可能进一步尝试会话劫持、实时中继或诱导用户批准异常登录。风险往往发生在工作节奏很快的时候，而不是发生在技术人员能够仔细分析链接的场景。企业应把该域名及相关解析记录加入邮件、DNS、代理和终端拦截策略，同时通过威胁情报持续关注同类新注册域名。对员工来说，登录 Teams 或其他办公平台应优先从已保存的官方入口进入，不要从临时邮件、聊天消息和二维码直接打开登录页面。安全团队还应检查近期是否出现异常登录、陌生设备、异常会话和多次认证失败；如果有人已经输入凭据，应立即重置密码、吊销会话、重新注册认证因子，并核对邮箱规则和文件共享权限。拦一个域名只能解决眼前问题，真正有效的是建立对仿冒登录流程的持续识别能力。

16 年前遗留的 Broadcom Wi-Fi 缺陷，附近攻击者无需密码也可能控制路由器

研究人员披露，Broadcom Wi-Fi 软件中存在一个已经存续约 16 年的缺陷，攻击者在无线信号覆盖范围内，即使不知道网络密码，也可能利用它控制受影响路由器。该问题在巴黎 Hexacon 会议期间公开讨论，研究人员指出，旧代码长期存在于广泛部署的设备中。公开摘要没有提供统一的漏洞编号和完整设备清单，因此不能据此断言所有 Broadcom 芯片路由器都受影响，设备型号和厂商固件仍需逐项确认。它的现实风险在于，攻击者不一定需要先进入企业无线网络，只要靠近办公区、酒店、校园、仓库或家庭路由器，就可能把无线攻击变成设备接管入口。路由器一旦失守，攻击者可以观察流量、修改 DNS、劫持访问、设置代理或把设备纳入后续攻击基础设施。对于小型机构和分支机构来说，网络设备往往缺少持续监控，固件多年不更新，出问题后也不容易留下明显的终端告警。处置时不要只看路由器品牌，要同时确认芯片平台、硬件型号、固件版本和厂商安全公告。能升级的设备应安装厂商提供的修复固件，无法升级的旧设备应减少管理面暴露、关闭不必要的无线和远程管理功能，并考虑替换。企业还应核对 DNS 配置、管理账号、无线配置、端口映射和异常代理设置，检查设备是否存在陌生外联。无线网络应使用强认证和分区策略，管理平面只允许受控来源访问。由于该缺陷历史较长，不能把 “过去没有发现异常” 当成没有被利用的证明。

Google 为 Android 增加反诈骗保护，电话、短信和验证码都被纳入防线

Google 宣布推出一组面向 Android 的安全保护能力，用于应对电话、短信、聊天应用、网页链接和账号验证码中的移动诈骗。公开信息提到的风险包括伪造号码、假银行提醒、钓鱼页面、远程屏幕共享和 AI 生成语音等，攻击者的目标通常是诱导用户交钱、交出密码或提供一次性验证码。这是厂商层面的防护更新，并不代表所有设备会在同一时间获得相同能力，也不能替代用户和企业自身的安全控制。移动诈骗越来越少依赖单一恶意软件，更多时候是把电话、消息、链接、登录和支付串成一条社会工程链。受害者可能先接到一通冒充客服的电话，再收到一条 “风险通知”，随后被引导到仿冒页面，最后在紧张情绪中交出验证码。AI 生成的声音和更自然的聊天内容，会让传统的 “看语气辨真假” 变得不可靠。对企业来说，员工手机既是个人设备，也可能承载办公账号、支付工具和内部应用，移动端风险不能再被排除在安全运营之外。用户应及时安装系统和安全组件更新，不要把验证码、屏幕共享和远程控制权限交给陌生人。遇到 “马上处理”“否则封号”“不要告诉别人” 等高压话术，应通过官方号码独立回拨核实。企业则应在移动设备管理、邮件和身份系统中加强异常登录、风险链接和远程控制行为检测，并明确规定客服、财务和管理员不会索要密码或验证码。对安全团队而言，最重要的不是等待某个功能自动拦截，而是把手机、身份、支付和员工培训放到同一条反欺诈流程里。

Plex 媒体服务器漏洞被用于挖矿，公开利用链让家用设备进入攻击视野

研究人员观察到，攻击者正在利用 Plex Media Server 漏洞部署加密货币挖矿恶意软件，并在蜜罐环境中记录到成功攻击。公开摘要提到，活动发生在 Plex2Shell 公开利用工具出现之后，该利用链组合了四个漏洞，能够在无需登录的情况下尝试执行代码；后续观察还发现攻击者在系统中运行代理软件。受影响对象并不只限于大型企业，暴露在公网的家庭服务器、小型机构媒体服务器和实验环境同样可能成为目标。很多人把 Plex 当作娱乐软件，认为服务器里没有核心业务，遭到攻击最多就是播放中断。但公网服务器只要能够执行代码，就可能被用来挖矿、做代理、扫描其他目标或保存后续载荷。挖矿进程会消耗 CPU、内存和电力，代理程序则可能让受害主机的网络地址替攻击者发起连接。对于企业而言，这类 “非核心设备” 还可能与办公网、存储系统或管理员工作站存在连通关系，影响不会永远停留在媒体服务本身。使用 Plex 的单位应先确认是否存在公网暴露、是否开启了不必要的远程访问，以及服务器所在网段能访问哪些资源。按照厂商公告升级到修复版本，暂时无法升级时应关闭公网访问并限制来源。随后检查 CPU 异常升高、陌生进程、计划任务、代理配置、启动项和异常外联，重点关注与挖矿池、代理节点或陌生域名的通信。若设备已经出现命令执行或后门迹象，应隔离并从可信备份重建，同时轮换在该主机上使用过的凭据。家庭用户也应更新固件和系统，避免把媒体服务直接暴露在互联网。

微软确认 10 月更新可能影响 Exchange 邮件服务，修复漏洞后还要验证业务

微软确认，10 月 13 日发布的 Windows Server 安全更新可能导致部分本地部署的 Exchange Server 出现邮件服务异常。公开信息显示，受影响范围包括 Exchange Server 2016、Exchange Server 2019 和 Subscription Edition 的部分系统，症状可能表现为网页版邮箱无法访问、邮件无法正常投递。微软已经提供了处理建议，并明确建议管理员不要直接卸载安全更新。这个事件提醒企业，安全补丁上线不等于变更结束，补丁后的业务验证同样是安全运营的一部分，邮件系统一旦中断，影响的不只是收发邮件。企业的密码重置、告警通知、客户沟通、审批流和外部协作都可能依赖 Exchange。更麻烦的是，管理员如果为了恢复服务仓促回滚补丁，可能重新暴露已经修复的安全问题，形成 “业务恢复了，风险也回来了” 的两难局面。因此，处理这类兼具安全和兼容性影响的更新，不能只看服务器是否重启成功，还要看真实用户能否登录、邮件是否进出、队列是否积压以及审计记录是否完整。建议管理员先对照微软公告确认系统版本、更新编号和受影响条件，在变更窗口内验证 OWA、SMTP、内部投递、外部投递、移动端和管理接口。发现异常时，优先采用微软提供的临时方案或修复步骤，保留变更前后的日志和配置，不要未经评估卸载安全更新。同时检查邮件队列、服务状态、证书、连接器和身份验证错误，确认没有把兼容性问题误判为攻击。后续应在测试环境先完成补丁和 Exchange 联调，再推广到生产系统，并为关键邮件链路准备应急通信渠道。

OpenCode 披露安全事件，受影响工作区中的第三方 API 密钥可能暴露

OpenCode 披露，一起安全事件影响其 Console 用户中的约 1.4%，受影响工作区中保存的第三方 API 密钥可能已经暴露，公司在 10 月 17 日的说明中将事件与大规模模型蒸馏攻击联系起来，并表示正在与 Anthropic、OpenAI 和 Google 协作处理。公开摘要没有说明所有密钥都被使用或所有客户数据都已泄露，因此不能把 “可能暴露” 直接等同于 “全部被盗”，但只要密钥曾出现在受影响工作区，就应按凭据泄露风险处置。这类事件的关键，不只是某个开发工具本身出了问题，而是开发者已经把越来越多的云服务密钥、模型 API 密钥和第三方令牌放进 AI 工作空间。密钥一旦被读取，攻击者可能调用模型、访问代码仓库、消耗账户额度，甚至利用同一令牌进入生产系统，即使工具厂商没有更广泛的内部网络入侵，暴露的第三方凭据也可能把风险传导到多个供应商和项目。受影响比例看似不高，但被影响的账号是否拥有高权限，往往比人数更重要。使用 OpenCode Console 或类似 AI 开发工具的团队，应先确认自己的工作区是否落在厂商通知的受影响范围内，再立即轮换其中保存过的第三方 API 密钥、云访问令牌、仓库令牌和数据库凭据。轮换不能只生成新密钥，还要撤销旧密钥、检查调用日志、核对异常消费和访问来源，并确认新凭据没有再次写入聊天记录、提示词、代码仓库或共享工作区。企业还应采用短时令牌、密钥托管和按项目隔离权限，禁止 AI 工具直接持有不必要的生产级凭据。对 AI 开发平台来说，凭据治理必须和代码安全一样成为上线前置条件。

信息来源：人民网国家计算机网络应急技术处理协调中心国家信息安全漏洞库今日头条 360威胁情报中心中科汇能GT攻防实验室安全牛 E安全安全客 NOSEC安全讯息平台火绒安全亚信安全奇安信威胁情报中心 MACFEESy mantec白帽汇安全研究院安全帮卡巴斯基安全内参安全学习那些事安全圈黑客新闻蚁景网安实验室 IT之家IT资讯黑客新闻国外天际友盟