LibreOffice 与 OpenOffice 电子表格漏洞:启用 Java 时打开文件即可无警告执行代码

安全研究人员披露 LibreOffice Calc 与 Apache OpenOffice Calc 存在高危代码执行漏洞（CVE-2026-63277 / CVE-2026-59265）。攻击者通过组合电子表格数据库范围刷新与 JDBC 驱动远程加载两项正常功能，在启用 Java 支持的前提下，无需用户交互或宏信任确认即可执行任意代码。

01 / 事实速览

02 / 合法功能的异常组合：无宏警告的代码执行机制

长期以来，办公文档安全防线的核心假设建立在“代码执行必然伴随宏”这一前提之上。无论是企业终端的组策略限制，还是用户日常的安全意识培训，都将宏运行前的信任警告视为最后一道人工拦截屏障。然而，LibreOffice Calc 与 Apache OpenOffice Calc 中暴露的 CVE-2026-63277 彻底打破了这一认知边界。通过分析 The Hacker News 于 2026 年 10 月 6 日披露的研究人员概念验证可以确认，当用户打开一份经过精心构造的恶意电子表格时，攻击者植入的代码会立即在宿主进程中执行，而整个触发过程完全不涉及宏引擎，自然也不会弹出任何宏式安全警告或活动内容提示。这意味着，依赖“禁用宏”或“提示用户确认宏运行”的传统文档安全策略，在面对该漏洞时将完全失效。

这种静默执行的根源并非某个单一组件存在内存破坏或逻辑越权，而是多个独立且合法的办公功能在特定条件下串联后，绕过了整体的信任检查机制。结合 SecurityOnline 核验的信息可见，该漏洞的类型被明确描述为经由 calcext:data-mappings、SQL provider 与 JDBC connector 实现的远程代码执行。这三个技术标识分别对应了电子表格中的数据库范围映射、底层 SQL 数据提供程序以及 Java 数据库连接驱动加载器。在正常的业务场景中，Calc 允许用户将单元格区域链接到外部数据源并在文档中保存该链接，以便在打开文件时自动刷新数据；同时，系统也支持通过指定 JDBC 驱动来连接各类关系型数据库。这些功能单独运作时均属于预期行为，但当攻击者将外部数据源的指向替换为由远程位置加载的 Java 数据库驱动时，程序的执行流便从“拉取业务数据”悄然滑向了“下载并执行任意 Java 代码”。研究人员在分析中指出，核心安全问题正是在于这些独立正常功能的组合缺乏统一的信任提示检查——系统在依次调用数据映射、SQL 提供程序和 JDBC 连接器时，并未在跨越功能边界的关键节点上向用户请求对当前文档的信任授权。

要理解这一机制为何能绕过防线，需要厘清其触发的严格前置条件。该攻击链的成立高度依赖于宿主环境是否启用 Java 支持。如果目标系统的 LibreOffice 或 Apache OpenOffice 未安装 Java 运行时环境，或者在软件设置中禁用了 Java 集成，那么 JDBC 驱动的加载路径将被直接阻断，后续的代码执行也就无从谈起。反之，只要 Java 支持处于开启状态，且用户在 Windows 或 Linux 操作系统上打开了包含恶意数据库范围引用的电子表格，程序就会按照预设的正常逻辑，自动完成外部文件的获取与驱动的实例化。由于这一系列动作被封装在文档打开时的数据刷新流程中，操作系统和办公软件的安全模块会将其视为常规的 I/O 操作与类加载行为，而非可疑的脚本执行。

从威胁情报的视角来看，尽管该漏洞的技术细节与 PoC 利用代码已由 V12 security 的 Rick de Jager 与 Codean Labs 的 Thomas Rinsma、Edoardo Geraci 等研究人员公开发布，但当前的实际威胁态势仍处于可控窗口期。根据 SecurityOnline 的核验结果，CISA 在其 CVE 记录中将利用情况标记为 none，表明目前尚无已确认的野外攻击活动。然而，PoC 的公开意味着攻击者复现该利用链的门槛已被大幅降低。对于防守方而言，必须认识到该漏洞的本质是“合法功能的异常组合”，因此传统的基于特征码或宏行为分析的检测手段难以奏效。防御重心的转移要求安全团队重新审视办公套件中非宏类自动化功能的潜在风险，特别是那些能够在后台静默发起网络请求并加载外部代码的机制。

关键判断： CVE-2026-63277 与 CVE-2026-59265 的根本威胁在于其执行路径完全脱离了宏引擎。攻击者利用数据库范围刷新与 JDBC 驱动加载这两项正常功能的组合，在启用 Java 支持的环境下实现了无警告的任意代码执行。这要求防守方必须摒弃“无宏即安全”的传统误判，将针对外部数据链接与远程类加载行为的监控纳入文档安全防线。

03 / 五步攻击链还原：从电子表格到进程内代码加载

承接前文对漏洞机制的定性，CVE-2026-63277 与 CVE-2026-59265 的核心威胁并非源于某个单一组件的内存破坏或解析溢出，而是由五个独立且完全合法的功能组件在特定执行序列下组合产生的逻辑缺陷。通过分析 V12 security 公开的概念验证代码以及 SecurityOnline 核验的技术细节可以确认，整个利用过程不需要用户点击“启用宏”或确认任何安全警告，只要目标系统启用了 Java 支持，打开一份精心构造的电子表格即可触发完整的代码执行路径。这五个组件分别是数据库范围刷新、外部 ODB 文件引用、自动网络下载、JDBC 驱动指定以及进程内 JAR 加载。它们各自在日常办公场景中均属于预期行为，但串联后却形成了一条绕过传统文档信任机制的攻击链。

攻击链的起点是 Calc 电子表格中的“数据库范围”（database range）功能。该功能允许用户将工作表中的特定单元格区域链接到外部数据源，并在文档中保存这一映射关系。当电子表格被打开时，程序会尝试根据保存的配置自动刷新这些范围以获取最新数据。在正常业务场景中，这是实现报表动态更新的基础能力；但在攻击场景下，它成为了无需用户交互即可触发后续动作的初始引擎。

第二步在于外部数据源的指向配置。攻击者在构造恶意电子表格时，将数据库范围的外部源指定为一个 ODB 数据库文件，并通过写入电子表格的 URL 引用定义该文件的获取位置。结合研究人员在 V12 security GitHub 仓库中公开的 PoC 信息可见，这个 URL 并不局限于本地路径或受信任的内部共享目录，它可以指向任意网络地址。这意味着电子表格本身只是一个轻量级的指令载体，真正的攻击载荷被解耦到了外部位置。

第三步是范围刷新触发的隐式网络请求。当受害者使用 LibreOffice Calc 或 Apache OpenOffice Calc 打开这份电子表格时，程序为了完成数据库范围的自动刷新，会直接根据内置的 URL 发起网络请求并下载 ODB 文件。SecurityOnline 的核验报告指出，这一下载行为是程序处理外部数据链接的正常逻辑分支，不会弹出类似“是否允许加载外部内容”的安全提示。由于缺乏信任检查环节，网络请求在静默状态下完成，ODB 文件被拉取至本地处理上下文中。

第四步涉及 ODB 文件内部的 JDBC 驱动配置。被下载的 ODB 文件并非普通的结构化数据存储，而是经过特殊构造的数据库描述文件。它在内部指定了连接所需的 JDBC 驱动，并将驱动代码的位置指向一个 JAR 文件。根据研究人员的推断，在真实的攻击场景中，这个 JAR 文件同样会被放置在攻击者控制的远程服务器上，从而形成二次网络拉取的条件。ODB 文件在此处扮演了“跳板”角色，将程序的执行上下文从单纯的数据读取引导至 Java 类路径的动态加载。

第五步即最终的代码执行阶段。程序在解析 ODB 文件并尝试建立数据库连接时，会根据其指定的路径下载对应的 JAR 文件，随后在自身的宿主进程内启动该 JDBC 驱动。由于 Java 代码直接在办公软件的进程空间中运行，它天然继承了当前用户的权限级别以及对本地文件系统、网络接口的访问能力。V12 security 的 PoC 演示中，该 JDBC 驱动仅启动了操作系统的计算器应用作为无害占位符，以证明代码执行的成功；但同一路径完全可以替换为执行任意 Java 代码的恶意载荷，例如部署后门、窃取凭据或进行横向移动。

上述时序流清晰地展示了正常行为如何逐步演变为异常结果。前三个步骤（打开文件、读取 URL、下载 ODB）均属于电子表格处理外部数据的标准流程，而第四个步骤（解析 JDBC 配置）也是数据库连接组件的常规操作。漏洞的本质在于第五个步骤——程序在加载并执行外部 JAR 文件时，没有对代码来源进行信任校验，也没有将其隔离在受限的沙箱环境中。各独立正常功能的组合在这一环节彻底绕过了宏执行前的提示机制。

这种跨平台的一致性进一步放大了攻击链的影响面。研究人员已在 Windows 和 Linux 操作系统上分别测试并确认了该漏洞的触发能力，证明这条由数据库范围刷新到 JDBC 驱动加载的路径不依赖于特定操作系统的底层 API 差异，而是根植于 LibreOffice 与 Apache OpenOffice 共享的跨平台 Java 集成架构之中。对于防御方而言，理解这五个组件的级联关系是制定检测策略的前提：单一的 ODB 下载或 JAR 加载可能在日志中表现为正常的办公行为，但当它们在极短的时间窗口内由同一个电子表格打开事件顺序触发，且目标地址指向外部不可信域名时，便构成了高置信度的异常信号。

04 / 双分支修复态势：LibreOffice 已封堵与 OpenOffice 的暴露窗口

同一底层缺陷在 LibreOffice 与 Apache OpenOffice 两个代码库中分别被追踪为 CVE-2026-63277 与 CVE-2026-59265，但两者的修复进度呈现出截然不同的态势。通过分析 LibreOffice 官方安全公告可以确认，CVE-2026-63277 已于 2026 年 10 月 5 日发布正式修复，受影响范围覆盖 26.2.5 和 26.8.0 之前的所有版本。结合 SecurityOnline 核验的信息可见，该批次共包含六个漏洞，全部影响 LibreOffice 26.2 系列 26.2.5 之前的版本，其中 CVE-2026-63277 的 CVSSv4 评分达到 8.5（High），其余五个漏洞评级为 Medium（6.7 或 6.8）。这一评分差异直接反映了 JDBC 驱动加载路径导致远程代码执行的严重性远超同批次其他缺陷。LibreOffice 的修复由 Collabora Productivity 的 Caolán McNamara 编写，其核心逻辑包含两项关键约束：一是强制要求 Java class path 条目必须指向本地文件，从而切断了程序从远程 URL 下载并加载 JAR 文件的攻击链组件；二是将外部数据链接纳入常规链接更新控制机制，使得数据库范围的自动刷新行为受到用户信任策略的管辖。这两项修改从根本上阻断了“无宏警告代码执行”的前提条件，意味着升级至 26.2.5 或 26.8.0 后，即使系统启用了 Java 支持，攻击者也无法再利用 calcext:data-mappings、sql provider 与 jdbc connector 的组合实现进程内代码注入。

相比之下，Apache OpenOffice 的响应节奏明显滞后。根据 OpenOffice 官方安全公告页的记载，对应漏洞 CVE-2026-59265 被定级为 Critical，官方描述明确指出“打开恶意文档可导致系统被接管”。然而，截至当前发布的 4.1.16 版本（含）均未包含针对此问题的修复代码。结合 oss-security 邮件列表（2026/10/02/2）的信息可知，预计承载修复的 4.1.17 版本仍处于发布候选（RC）测试阶段，尚未进入正式发布流程。OpenOffice 此前已在 4.1.16 版本中集中修复了一批“无提示加载外部内容”类缺陷，包括 CVE-2025-64403（Calc 通过 external data sources 未经提示加载远程文档）、CVE-2025-64405（通过 DDE 函数未经提示加载远程文档）以及 CVE-2025-64407（URL 抓取可外泄任意 INI 文件值与环境变量）。这些历史修复表明开发团队已经意识到外部数据源自动加载带来的安全风险，但本次 JDBC 驱动加载问题并未被纳入 4.1.16 的修补范围，说明该攻击向量的发现时间晚于 4.1.16 的代码冻结节点，或者其利用机制的复杂性导致了更长的评估周期。这种修复断层使得 OpenOffice 用户在 4.1.17 正式发布前面临一个持续敞开的暴露窗口。

漏洞的发现与报告过程揭示了开源办公套件安全生态中的协作与独立并存特征。LibreOffice 侧的 CVE-2026-63277 由 V12 security 的 Rick de Jager 与 Codean Labs 的 Thomas Rinsma、Edoardo Geraci 独立报告；而 Apache OpenOffice 侧的 CVE-2026-59265 则由 Codean Labs 单独报告。尽管报告主体存在重叠，且 OpenOffice 官方公告明确记载 LibreOffice 套件将同一问题报告为 CVE-2026-63277，但两个项目的补丁工程完全独立推进。这种双轨制意味着防御者不能假设其中一个项目的修复会自动惠及另一个项目，必须针对各自部署的软件版本进行独立的漏洞状态核查。目前 CISA 在 CVE 记录中将利用情况列为 none，尚无已确认的野外攻击，但这仅反映当前的威胁情报状态，随着技术细节与 PoC 利用代码已在 V12 security 的 GitHub 仓库公开发布，暴露窗口的持续时间越长，被武器化利用的概率就越高。

为了消除多源信息带来的认知混乱，下表横向对比了两款软件在 CVE 编号、严重性评级、受影响版本边界、当前修复状态及可用缓解措施上的关键差异。防御者在制定处置策略时，应首先确认环境中实际运行的软件分支与版本号，再对照表中对应的修复状态决定是执行补丁升级还是采取临时缓解。

对于仍在使用 LibreOffice 受影响版本的组织，预期处置动作是直接升级至 26.2.5 或 26.8.0，这是消除该攻击向量最彻底的方式。修复内容中对 Java class path 的本地化强制要求和对链接更新控制的统一收口，确保了正常业务功能不受影响的前提下封堵了异常组合路径。而对于 Apache OpenOffice 用户，由于 4.1.17 正式版发布时间尚不确定，环境处于事实上的无补丁暴露期。在此边界条件下，禁用 Java 支持成为唯一已知有效的临时缓解手段，因为攻击链的触发前提是程序必须启用 Java 支持以完成 JDBC 驱动的下载与进程内加载。若业务场景强依赖 Java 功能而无法执行禁用操作，则必须实施严格的输入控制，完全避免打开来自未知发件人或不可信来源的电子表格，尤其不应在存放敏感数据的系统上处理此类文件。这种基于软件分支和补丁可用性的差异化研判，构成了下一章分级处置策略的事实基础。

05 / 基于环境约束的研判与分级处置策略

CVE-2026-63277 与 CVE-2026-59265 构成的代码执行威胁并非无条件触发，其攻击链的起点严格依赖于一个明确的环境前置条件：目标系统上的 LibreOffice Calc 或 Apache OpenOffice Calc 必须已安装并启用 Java 支持。结合安全研究人员的声明可以确认，当且仅当程序启用了 Java 运行时环境，电子表格中的数据库范围刷新机制才能成功调用 JDBC 驱动加载路径，进而下载并执行远程 JAR 文件中的代码。这一前提条件直接决定了漏洞的实际影响边界，也为防御方提供了最关键的研判切入点。在评估组织内部风险时，首要动作并非盲目阻断所有电子表格流转，而是清点办公套件的安装版本及其 Java 集成状态。若环境中未部署 Java 运行环境，或者办公软件配置中显式禁用了该功能，则整个从 ODB 文件下载到进程内代码执行的链条将在第一步断裂，攻击自然失效。

基于上述因果逻辑，针对不同软件生态的处置策略呈现出显著的分化态势。对于 LibreOffice 用户而言，官方已于 2026 年 10 月 5 日发布了针对 CVE-2026-63277 的修复补丁。通过分析 LibreOffice 官方安全公告可知，受影响范围为 26.2.5 和 26.8.0 之前的所有版本，因此预期的标准处置动作是立即将软件升级至 26.2.5 或 26.8.0。此次修复从根本上改变了程序的信任校验逻辑，强制要求 Java class path 条目必须指向本地文件，同时将外部数据链接的刷新行为纳入了常规的链接更新控制体系。这意味着即使 Java 支持处于开启状态，恶意电子表格也无法再静默拉取远程服务器上的 JAR 载荷。在补丁全面部署完成前的过渡期内，SecurityOnline 的核验信息建议采取保守策略：谨慎处理来自未知发件人的电子表格，并严格避免在存放敏感数据的终端系统上打开此类文件。

Apache OpenOffice 面临的处境则截然不同。通过查阅 Apache OpenOffice 官方安全公告可见，对应漏洞 CVE-2026-59265 被定级为 Critical，描述为打开恶意文档可导致系统被接管，但截至当前的 4.1.16 版本（含）均未包含修复代码。预计承载修复的 4.1.17 版本仍处于发布候选（RC）测试阶段。在这种缺乏官方补丁的暴露窗口期内，禁用 Java 支持成为了唯一已知且有效的临时缓解措施。具体的操作路径为：在 Windows 或 Linux 系统中依次进入 Tools → Options → OpenOffice → Java，在 macOS 系统中则为 OpenOffice → Preferences → OpenOffice → Java，随后取消勾选“Use a Java runtime environment”选项。如果特定业务场景下绝对无法关闭 Java 支持，官方给出的底线建议是完全避免打开任何不可信文件。

风险提示： 对于依赖 Apache OpenOffice 且尚未能升级至 4.1.17 正式版的组织，禁用 Java 支持是当前阻断 CVE-2026-59265 利用的唯一有效防线。然而，这一操作具有明确的业务兼容性风险边界：禁用 Java 会同时导致所有依赖 Java 运行时的正常宏、扩展组件及数据库连接功能失效。安全团队在执行此缓解措施前，必须与业务部门协同评估 Java 功能的依赖程度，防止因安全加固引发核心办公流程中断。若评估后确认无法全局禁用，则必须在网络层或终端管控层对 OpenOffice 的文件输入源实施严格的白名单限制。

为了将上述复杂的研判条件转化为可落地的操作指引，以下决策树根据软件类型、版本状态以及 Java 支持的业务必要性，构建了分级处置的分流逻辑。该结构帮助运维与安全人员在面对不同终端环境时，快速定位应采取的验证步骤与最终处置动作。

该决策树的执行前提是准确识别终端上安装的办公软件分支与具体版本号。对于 LibreOffice 分支，若版本低于 26.2.5 或 26.8.0 且启用了 Java 支持，系统即处于高危状态，首选动作必须是执行补丁升级；仅在升级失败或存在兼容性阻碍时，才退而求其次选择禁用 Java 支持作为临时缓解。对于 Apache OpenOffice 分支，由于当前不存在可用的正式补丁，只要版本小于等于 4.1.16 且启用了 Java，系统便处于极高危的无防护暴露期。此时的分流依据转变为业务对 Java 的依赖程度：若不依赖，应立即执行禁用操作以切断攻击链；若强依赖，则只能通过管理手段严格限制文件输入源，并持续跟踪 4.1.17 版本的发布进度。无论走哪条分支，最终的验收标准都是确认攻击链的五个组件中至少有一个被可靠阻断。

06 / 安全运营闭环：检测、遏制、恢复与持续监控

漏洞机理与处置策略的明确只是安全响应的起点，要将防御动作转化为可验证的运营成果，必须建立覆盖检测、遏制、恢复、复测与持续监控的完整闭环。由于 CVE-2026-63277 与 CVE-2026-59265 的执行路径完全避开了宏引擎，传统的文档安全扫描工具极易漏报，防守方需要将观测重心转移到网络流量、进程行为与配置基线三个维度。

在网络层，该攻击链必然伴随两次由办公软件进程主动发起的外部 HTTP/HTTPS 请求：第一次用于拉取 ODB 数据库描述文件，第二次用于下载 JAR 格式的 JDBC 驱动。安全团队应在代理服务器或终端防火墙日志中，检索由 soffice.bin（LibreOffice）或 soffice.bin / openoffice 相关进程在短时间内连续发起的、指向非常规域名的外部连接。若发现此类成对出现的网络请求，且目标 URL 不属于企业内部已知的数据源白名单，即可作为高置信度的疑似入侵信号转入人工研判。在终端层，由于恶意 JAR 文件是在 Calc 宿主进程内直接加载执行的，端点检测与响应（EDR）系统应重点监控办公软件进程是否派生了异常的子进程。V12 security 的 PoC 演示中，JDBC 驱动启动了系统计算器应用；在真实攻击中，这可能表现为派生 PowerShell、cmd.exe、bash 或其他命令行解释器。一旦检测到 soffice.bin 衍生出此类子进程，应立即触发告警并隔离主机。

在确认终端可能遭受利用后，遏制动作需同步在网络与终端两侧展开。网络侧应立即阻断涉事终端对外部可疑 IP 或域名的访问，防止攻击者通过已建立的通道进行横向移动或数据外传。终端侧需挂起或终止相关的办公软件进程，并断开网络连接以固化现场。对于 LibreOffice 环境，在完成取证后应尽快推送 26.2.5 或 26.8.0 版本的补丁；对于 Apache OpenOffice 环境，则需通过组策略或配置管理工具批量下发禁用 Java 支持的配置变更。

恢复阶段的验收标准不仅是软件版本的更新或配置的修改，更要求确认系统状态已回归安全基线。对于已升级的 LibreOffice 终端，恢复成功的标志是版本号确认为 26.2.5 或 26.8.0，且 Java class path 的远程加载行为已被底层代码强制拦截。对于采取了禁用 Java 缓解措施的 OpenOffice 终端，恢复成功的标志是配置文件中的“Use a Java runtime environment”选项已被可靠置为未勾选状态，且重启软件后该设置依然生效。此外，由于恶意代码是在当前用户权限下执行的，恢复过程中必须排查攻击者是否利用该权限植入了持久化机制，例如修改注册表启动项、创建计划任务或释放隐藏的后门文件。只有在确认无未授权变更后，方可解除终端隔离并恢复业务接入。

复测是验证修复与缓解措施有效性的关键环节。安全团队应使用与 PoC 原理一致的测试样本（例如构造一个指向内部受控服务器的 ODB 与 JAR 链接的电子表格），在已完成补丁升级或禁用 Java 的终端上进行打开测试。预期结果为：在 LibreOffice 26.2.5 及以上版本中，程序拒绝从远程 URL 加载 JAR 文件，或者在尝试刷新外部数据链接时弹出标准的信任警告提示；在禁用了 Java 的 OpenOffice 中，数据库范围刷新直接失败，且不产生任何网络下载行为。若测试样本仍能成功触发外部请求或代码执行，则说明补丁未正确应用或配置变更未生效，必须回退至遏制阶段重新排查。

残余风险的评估需要根据环境的具体变更窗口和业务容忍度来确定。即便完成了补丁部署或 Java 禁用，仍需关注历史遗留的恶意电子表格是否潜伏在文件服务器或员工邮箱中。一旦员工在未修补的旧设备上打开这些文件，攻击链仍可能被激活。因此，持续监控的指标应包括：办公软件进程的异常子进程派生频率、指向外部未知域名的 ODB/JAR 文件下载请求趋势，以及终端 Java 支持配置状态的合规率。安全团队应将这些指标的波动趋势纳入定期复盘输入，一旦发现偏离基线的异常峰值，需立即启动新一轮的调查与响应循环。

行动建议： 安全运营团队应立即盘点内部 LibreOffice 与 Apache OpenOffice 的资产分布及版本清单，优先推动 LibreOffice 升级至 26.2.5 或 26.8.0。对于短期内无法升级的 OpenOffice 终端，需在变更窗口内统一下发禁用 Java 支持的配置，并在 EDR 与网络代理中补充针对 soffice.bin 异常子进程派生及连续外部 ODB/JAR 下载行为的监控规则，确保攻击链的任一环节均可被观测与阻断。

07 / 参考链接

• securityonline.info
• www.openoffice.org