JohnPerifanis/CryptPad-Plugin-Loading-Hardening-Advisory

# CryptPad 插件加载加固建议 ## 不受限制的插件加载导致服务端代码执行及对提供给客户端的 JavaScript 的持久篡改 **研究人员：** John Perifanis **产品：** CryptPad **测试版本：** CryptPad 2025.3.1 **测试部署环境：** `cryptpad/cryptpad:version-2025.3.1` Docker 部署 **状态：** 存在争议 / 未被 CISA 分配 CVE **相关已接受 CVE：** CVE-2025-51846 **研究人员评估：** 具有安全显著性的加固问题，存在改变影响范围的潜在可能性 **CISA 立场：** 未对技术发现提出异议，但由于供应商威胁模型解释而未分配 CVE | CISA 在协调期间还表示，如果另一个 CNA 根据其自身范围和评估标准得出不同结论，它不会对另一个 CNA 分配该问题提出异议。 ## 执行摘要 在对 CryptPad 2025.3.1 进行独立安全测试期间，发现 CryptPad 的服务端插件加载机制会自动加载放置在 `lib/plugins/` 目录下的 JavaScript 模块，而无需进行签名验证、允许列表检查、沙箱处理或完整性校验。 一旦加载，插件便会在 CryptPad 的 Node.js 服务器进程内执行。它可以访问服务器环境，包括 `Env.curvePrivate` 等敏感服务端值，并能与内部服务器功能进行交互。测试进一步证实，CryptPad 服务用户可以修改提供给客户端浏览器的 JavaScript 文件（包括 `/cryptpad/www/common/boot.js`），并且此类修改在容器重启后依然存在，且按字节原封不动地提供给客户端。 该问题通过 CISA VINCE 进行了协调，并由 CISA 漏洞响应与协调部门进行了审查。CISA 并未对技术发现提出异议，但拒绝了 CVE 的分配，因为该场景超出了 CryptPad 声明的“诚实但好奇”威胁模型，被视为等同于恶意管理员场景。 本建议旨在为 CryptPad 运维人员和安全社区记录此行为。其中包含了技术发现、供应商和 CNA 的立场、研究人员的评估以及实用的加固建议。 ## 重要声明 本建议并不声称 CryptPad 的端到端加密在其声明的“诚实但好奇”威胁模型下已被攻破。 CryptPad 记录在案的模型假设服务器不会主动修改提供给用户的应用客户端代码。此处描述的问题涉及通过插件加载机制将代码执行引入 CryptPad 服务器进程时可能发生的情况。 安全隐患在于，插件一旦加载，便可以在服务器进程内运行，并可以修改提供给客户端浏览器的 JavaScript。这将场景从被动的服务器观察转变为主动的服务端修改——CryptPad 本身在其文档中也明确指出此场景超出了其安全保障范围。 ## 受影响的组件 该问题涉及 CryptPad 服务端的插件加载路径以及 CryptPad 服务用户的运行时权限。 相关组件： - `lib/plugin-manager.js` - `server.js` - `lib/env.js` - `/cryptpad/lib/plugins/` - `/cryptpad/www/` - `/cryptpad/www/common/boot.js` - `/cryptpad/customize/` 测试版本： ``` CryptPad 2025.3.1 Docker image: cryptpad/cryptpad:version-2025.3.1 ``` ## 技术总结 CryptPad 的插件管理器会枚举 `lib/plugins/` 目录并自动加载插件模块。此加载行为并未强制执行： - 插件签名、 - 插件允许列表、 - 完整性验证、 - 沙箱处理、 - 运行时的显式管理员批准。 如果将一个 JavaScript 模块放入预期的插件目录并且服务重启，CryptPad 会将其作为服务器进程的一部分进行加载。 主要的安全隐患不仅在于插件可以执行服务端代码。更重要的是，插件以 CryptPad 服务用户的权限运行，并且能够修改提供给用户浏览器的 JavaScript 文件。 这一点至关重要，因为 CryptPad 的安全模型依赖于浏览器接收到可信的客户端代码。如果服务器提供了被修改过的 JavaScript，浏览器可能会在加密发生之前执行受攻击者控制的代码。 ## 证据 1 - 插件加载器自动加载 `lib/plugins/` 中的 JavaScript CryptPad 的插件加载行为在 `lib/plugin-manager.js` 中实现。 相关逻辑： ``` const fs = require('node:fs'); const plugins = {}; try { let pluginsDir = fs.readdirSync(__dirname + '/plugins'); pluginsDir.forEach((name) => { if (name === "README.md") { return; } try { let plugin = require(`./plugins/${name}/index`); plugins[plugin.name] = plugin.modules; } catch (err) { console.error(err); } }); } catch (err) { } module.exports = plugins; ``` 唯一被明确排除的文件是 `README.md`。`lib/plugins/` 下的任何其他目录都会被处理，并通过 `require()` 加载其 `index.js`。 在加载插件之前，没有执行任何签名验证、允许列表检查、沙箱隔离或完整性校验。 ## 证据 2 - 插件获得对服务器环境的访问权限 CryptPad 的环境对象包含敏感的服务端值。 摘自 `lib/env.js`： ``` bearerSecret: void 0, curvePrivate: curve.secretKey, curvePublic: Util.encodeBase64(curve.publicKey), ``` 摘自 `server.js`： ``` Object.keys(Env.plugins || {}).forEach(name => { let plugin = Env.plugins[name]; if (!plugin.initialize) { return; } try { plugin.initialize(Env, "main"); } catch (e) {} }); ``` 这意味着如果插件实现了 `initialize()` 函数，它将接收到完整的 `Env` 对象。其中包括 `curvePrivate`，即服务器的私钥签名。 这并不意味着 `curvePrivate` 可以直接解密用户文档。然而，它仍然是敏感的服务端材料，将此对象暴露给未经验证的插件代码会增加插件执行所带来的影响。 ## 证据 3 - 插件可以注册服务器命令 CryptPad 还允许插件在服务器命令映射中注册命令。 摘自 `server.js`： ``` Object.keys(Env.plugins || {}).forEach(name => { let plugin = Env.plugins[name]; if (!plugin.addMainCommands) { return; } try { let commands = plugin.addMainCommands(Env); Object.keys(commands || {}).forEach(cmd => { if (cmd !== cmd.toUpperCase()) { return; } if (typeof(commands[cmd]) !== "function") { return; } if (COMMANDS[cmd]) { return; } COMMANDS[cmd] = commands[cmd]; }); } catch (e) {} }); ``` 检查仅限于： - 命令名称必须大写、 - 命令值必须是函数、 - 命令名称不能已存在。 对于哪个插件可以注册此类命令，没有签名验证或允许列表机制。 ## 证据 4 - CryptPad 以非 Root 服务用户运行 测试过的 Docker 部署以专用的非 root 用户运行 CryptPad： ``` uid=4001(cryptpad) gid=4001(cryptpad) groups=4001(cryptpad) ``` 从加固的角度来看，这是积极的，因为插件不会自动以 root 身份执行。然而，插件会以 `cryptpad` 服务用户的所有权限执行。 ## 证据 5 - `lib/plugins/` 可由 CryptPad 服务用户写入 在测试的部署环境中，插件目录可由服务用户写入： ``` PLUGINS_WRITABLE ``` 目录所有权： ``` 755 cryptpad cryptpad /cryptpad/lib/plugins ``` 这意味着任何以 CryptPad 服务用户身份运行的进程都可以在插件目录中放置文件。一旦服务重启，插件管理器就会加载它们。 ## 证据 6 - 插件加载已在实验室部署中得到验证 在以下位置放置了一个测试插件： ``` /cryptpad/lib/plugins/SUPPLY-CHAIN-TEST/index.js ``` 重启服务后，检查了插件管理器： ``` Loaded plugins: [ '_extensions', '_styles', 'SUPPLY_CHAIN_TEST' ] ``` 这证实了插件已被 CryptPad 的插件管理器自动加载。 ## 证据 7 - 已演示服务端代码执行 一个受控的 PoC 插件注册了一个自定义的质询命令，并通过 CryptPad 现有的 `/api/auth` 质询流程进行了触发。 该 PoC 通过读取 `/etc/passwd` 并在响应中返回其内容，演示了服务端代码执行。 为了避免提供可直接重用的漏洞利用工具，本建议中故意未包含完整的可执行 PoC。重要的技术要点是： - 放置在 `lib/plugins/` 中的插件在重启后被加载、 - 该插件注册了一个服务端处理器、 - 该处理器可以通过 CryptPad 现有的 API 流程访问、 - 演示了服务端文件读取功能。 这证实了在放置插件并重启之后，CryptPad 服务器进程内部发生了代码执行。 ## 证据 8 - 提供给客户端的 JavaScript 可由服务用户写入 测试部署证实，CryptPad 服务用户可以写入 `/cryptpad/www/common/boot.js`： ``` BOOT_JS_WRITABLE ``` 文件权限： ``` perms:644 owner:cryptpad group:cryptpad /cryptpad/www/common/boot.js ``` 这非常重要，因为 `boot.js` 是提供给客户端浏览器的 JavaScript。 ## 证据 9 - 磁盘上的 JavaScript 按字节原封不动地提供给客户端 将磁盘上 `/cryptpad/www/common/boot.js` 的 SHA256 哈希值与通过 HTTP 检索到的文件进行了比较。 在磁盘上： ``` 354f06d2e787fbe68a4fd166c9d43aa38b3cdf4d6e566e7f8b55026c9bd93967 /cryptpad/www/common/boot.js ``` 通过 HTTP 提供： ``` 354f06d2e787fbe68a4fd166c9d43aa38b3cdf4d6e566e7f8b55026c9bd93967 /tmp/served-boot.js ``` 哈希值匹配。这证实了存储在磁盘上的文件被逐字节地传送给客户端。 在此路径中未观察到任何服务端转换、签名或完整性验证。 ## 证据 10 - JavaScript 修改在重启后依然存在 在 `/cryptpad/www/common/boot.js` 中追加了一个无害的标记： ``` // persistence test marker XYZ123 ``` 重启容器后，该标记依然存在： ``` }); // persistence test marker XYZ123 ``` 修改后的文件也通过 HTTP 被检索到： ``` }); // persistence test marker XYZ123 ``` 这证实了： - 修改在容器重启后依然存在、 - 构建过程没有覆盖该文件、 - 修改后的文件被提供给了客户端。 验证后已移除了测试标记。 ## 证据 11 - 重启可由 CVE-2025-51846 强制触发 一个相关的漏洞 CVE-2025-51846 已被 CISA 接受并发布。该问题允许远程未经身份验证的攻击者通过洪泛 CryptPad 的 WebSocket 处理路径来降级或拒绝服务。 实际上，这非常重要，因为放置在 `lib/plugins/` 中的插件会在服务重启时被加载。如果服务由 Docker、systemd、Kubernetes 或类似的编排工具管理，崩溃或 OOM（内存不足）终止可能会导致自动重启。 因此，一旦插件文件存在，攻击者不一定需要等待管理员手动重启。强制重启可以与 CVE-2025-51846 结合使用。 ## 证据 12 - npm Postinstall 机制已测试 使用受控的私有 npm 注册表进行了单独的机制测试。一个带有 `postinstall` 脚本的测试包被发布到本地的 Verdaccio 注册表，并安装在 CryptPad 容器中。 `postinstall` 脚本将插件写入： ``` /cryptpad/lib/plugins/SUPPLY-CHAIN-TEST/ ``` 重启后，该插件被 CryptPad 加载。 这证明了当在 CryptPad 运行时环境中执行时，npm 生命周期脚本可以将文件放入 `lib/plugins/`。 重要限制： - 此测试使用的是私有本地注册表，而非公共 npm 注册表。 - 未公开发布任何恶意软件包。 - 未发现现有的 CryptPad 依赖项包含 `postinstall` 脚本。 - 这并不能证明当前的默认依赖树是可直接利用的。 该测试展示了一种现实的机制，而非默认的零点击利用途径。 ## 已证实的内容 测试证实了以下几点： 1. CryptPad 会自动从 `lib/plugins/` 加载插件。 2. 插件加载不强制执行签名、允许列表、沙箱隔离或完整性校验。 3. 已加载的插件可以接收完整的服务器 `Env` 对象。 4. `Env` 对象包含敏感的服务端值，如 `curvePrivate`。 5. 插件可以注册服务器命令。 6. PoC 插件演示了服务端代码执行。 7. CryptPad 服务用户可以写入提供给客户端的 JavaScript。 8. `/cryptpad/www/common/boot.js` 按字节原封不动地提供给客户端。 9. 对 `boot.js` 的修改在容器重启后依然存在。 10. 一个已被接受的相关 DoS 问题 CVE-2025-51846 可以强制服务重启。 11. 如果在运行时环境中安装了此类软件包，npm 生命周期脚本可以将文件放入插件目录。 ## 未证实的内容 为了准确起见，以下几点未被证实： 1. 未发现针对 `lib/plugins/` 的独立未经身份验证的文件写入漏洞。 2. 未发现直接写入 `lib/plugins/` 的路径遍历、Zip Slip 或任意上传原语。 3. 未发现现有的 CryptPad 依赖项包含 `postinstall` 脚本。 4. 未向公共 npm 注册表发布任何恶意软件包。 5. npm postinstall 测试演示了该机制，而不是默认的可利用的供应链入侵。 6. 该问题仍然取决于攻击者能否在插件目录中放置 JavaScript 文件或以其他方式影响插件放置这一前提条件。 ## CryptPad 威胁模型背景 CryptPad 记录在案的安全模型基于“诚实但好奇”的服务器假设。在该模型下，服务器可以观察存储的加密数据，但不会主动修改提供给用户的客户端应用。 CryptPad 自己的威胁模型声明： CryptPad 的安全博客进一步声明： CryptPad 的“恶意 JavaScript”用户故事也描述了相同的场景： 这些声明非常重要，因为它们证实了服务器提供恶意 JavaScript 不仅仅是理论上的。CryptPad 自己的文档将其认定为一种会瓦解该应用安全保障的场景。 ## 供应商立场 CryptPad 在协调披露过程中的立场是，安装插件需要服务器访问权限，并且有能力写入插件目录的人已经可以篡改 CryptPad 的代码库。 CryptPad 表示，此场景超出了“诚实但好奇”的模型，因为它代表了一种主动的服务端攻击。在他们看来，恶意管理员或拥有同等服务器写入权限的人已经超出了安全模型的范畴。 本建议并不否认 CryptPad 的威胁模型排除了主动的恶意服务器行为。本建议的重点是记录该边界的运维和加固含义。 ## CISA 立场 CISA 通过 VINCE 审查了该问题，并未对技术发现提出异议。 CISA 在协调期间还表示，如果另一个 CNA 根据其自身范围和评估标准得出不同结论，它不会对另一个 CNA 分配该问题提出异议。 CISA 拒绝分配 CVE，因为该场景超出了 CryptPad 声明的威胁模型，被视为等同于恶意管理员。CISA 的立场是，恶意管理员已经可以篡改服务器，因此插件机制并没有为攻击者的能力提供实质性的净增长。 CISA 实质上表示，技术发现已被接受，但该问题不符合 CISA 的 CVE 分配标准## 研究人员关于威胁模型排除的观点 研究人员的立场是，供应商威胁模型的排除不应被自动解释为缺乏安全相关性。威胁模型定义了产品声明要防御的内容。这并不一定意味着该模型之外的行为没有安全影响或没有运维加固价值。 在这种情况下，CryptPad 的文档明确指出，如果服务器提供修改过的客户端 JavaScript，则无法建立安全保障。技术证据表明，加载的插件可以修改提供给客户端浏览器的 JavaScript。因此，即使此场景超出了 CryptPad 声明的“诚实但好奇”威胁模型，由此产生的影响对运维人员而言仍具有安全显著性。 研究人员接受 CISA 作为 CNA 可能会裁定这不符合其分配 CVE 的门槛，因为供应商并未声明防御恶意管理员或主动的服务器修改。然而，研究人员的评估是，该行为仍然在 CryptPad 最重要的信任边界处构成了有意义的加固隐患：即提供应用代码的服务器与执行客户端加密的浏览器之间的边界。 ## 研究人员技术评估 技术上的隐患不仅在于插件可以在 CryptPad 服务器上执行代码。更重要的是该代码加载后可以做什么。 插件加载机制提供了一条确定性的执行路径：放置在 `lib/plugins/` 下的任何 JavaScript 模块都会在启动时由 `lib/plugin-manager.js` 加载。加载后，插件在 CryptPad 的 Node.js 进程内执行，并通过 `plugin.initialize(Env, "main")` 获取对服务器环境的访问权限。这包含了诸如 `Env.curvePrivate` 等敏感的服务端值。 测试还证实，CryptPad 服务用户可以写入提供给客户端的 JavaScript 文件，包括 `/cryptpad/www/common/boot.js`。对该文件的修改在容器重启后依然存在，并按字节原封不动地提供给 HTTP 客户端。这意味着加载的插件不局限于服务端操作；它还可以修改传送给用户浏览器的 JavaScript。 这一点至关重要，因为 CryptPad 的安全模型依赖于浏览器接收到可信的客户端代码。如果服务器提供了被修改的 JavaScript，该代码可以在加密发生之前在用户的浏览器中运行。在这种主动的恶意服务器场景中，攻击者可能会在正常的端到端加密保护生效之前，捕获明文、加密密钥、会话材料，或改变加密行为。 因此，尽管供应商将主动的服务端修改置于其声明的“诚实但好奇”威胁模型之外，研究人员仍认为该行为具有安全显著性。该问题为运维人员指出了一个实际的加固边界：插件目录和提供客户端的 JavaScript 路径应被视为高度敏感的执行面，而不是普通的可写应用目录。 ## 研究人员 CVSS 评估 如果尽管有供应商威胁模型的排除，仍将其作为漏洞进行评分，研究人员的评估为： ``` CVSS:3.1/AV:N/AC:L/PR:H/UI:N/S:C/C:H/I:H/A:H = 9.1 Critical ``` 理由： - `AV:N` - 一旦加载插件，相关的服务器功能便面向网络。 - `AC:L` - 加载后的执行路径是确定性的。 - `PR:H` - 对 `lib/plugins/` 的文件写入前提条件被保守地视为高权限。 - `UI:N` - 放置插件后的利用不需要用户交互。重启可以通过正常的编排发生，或者与 CVE-2025-51846 联动。 - `S:C` - 影响可以通过修改提供的 JavaScript 从服务器跨越到客户端浏览器。 - `C:H/I:H/A:H` - 在主动的恶意服务器场景中，可能产生完全的机密性、完整性和可用性影响。 此分数仅反映研究人员的评估。CISA 未分配 CVE，也没有发布此分数。 更保守的解释可以保留 `PR:H`，并仍将此问题视为高影响的加固隐患，而不是正式分配的 CVE。 ## 实用解读 运维人员不应将缺乏 CVE 视为没有运营风险。 该问题记录了一个重要的加固边界：如果攻击者可以在 `lib/plugins/` 中放置文件，服务器可能会加载未经验证的代码，从而修改提供给客户端的 JavaScript。运维人员应据此对插件路径和提供的 JavaScript 路径进行加固。 这对于以下情况尤为重要： - 自托管的 CryptPad 部署、 - 使用自定义插件的部署、 - 使用可以写入应用目录的自动化或 CI/CD 的部署、 - 运行时路径保持可写状态的 Docker 部署、 - 在发生故障后可以自动触发重启的环境。 ## 给运维人员的缓解建议 ### 1. 在运行时将 `lib/plugins/` 设为只读 如果不需要插件，`lib/plugins/` 目录在正常运行期间应为只读。 如果需要插件，运维人员应仅允许通过受控的部署管道进行更改。 ### 2. 将提供给客户端的 JavaScript 路径设为只读 除非出于受控的构建或部署过程的需要，否则以下路径在运行期间不应保持可写状态： ``` /cryptpad/www/ /cryptpad/www/common/boot.js /cryptpad/customize/ ``` 运行时服务通常不需要修改提供给客户端的 JavaScript 包。 ### 3. 使用文件系统完整性监控 运维人员应监控敏感路径的更改： ``` /cryptpad/lib/plugins/ /cryptpad/www/ /cryptpad/customize/ ``` 可能的工具包括： - auditd、 - AIDE、 - Tripwire、 - Wazuh、 - EDR 文件系统监控、 - 容器镜像完整性控制。 ### 4. 分离构建时和运行时权限 构建过程可能需要对应用文件的写入权限。而运行时则不需要。 更安全的部署模式是： 1. 在受控的构建阶段构建应用资产、 2. 将它们打包成不可变镜像、 3. 以只读方式挂载应用代码来运行服务。 ### 5. 避免在运行时容器中安装 npm 软件包 运维人员应避免在运行中的 CryptPad 运行时容器内运行 `npm install`。任何依赖项的安装都应在受控的构建过程中进行。 这可以减少暴露给 `postinstall` 等 npm 生命周期脚本的风险。 ### 6. 使用不可变容器镜像 在可能的情况下，从不可变容器镜像运行 CryptPad，并避免在容器内使用可写应用目录。 可写卷应仅限于确实需要持久化的数据路径。 ### 7. 监控服务重启 由于插件加载在重启时发生，因此应对意外的服务重启进行监控和调查。 这一点尤为重要，因为 CVE-2025-51846 可以在受影响的版本中强制服务降级或重启。 ## 给 CryptPad 上游的缓解建议 以下更改将降低风险： 1. 默认禁用插件加载。 2. 需要显式配置才能启用插件。 3. 实施插件允许列表。 4. 要求插件签名或完整性验证。 5. 在访问 `Env` 受限的沙箱环境中运行插件。 6. 除非明确需要，否则避免将敏感的服务端秘密传递给插件初始化。 7. 在运行时将提供给客户端的 JavaScript 设为只读。 8. 为提供的客户端包添加完整性验证。 9. 支持经验证的客户端机制（如 WEBCAT）。 10. 在运维文档中清楚地记录插件信任假设。 ## 披露与协调时间线 以下时间线总结了协调过程。 - **2025 年 5 月 25 日** - 向 CryptPad 安全团队进行初步私下披露。 - **2025 年夏季** - 与 CryptPad 保持持续沟通。 - **2025 年 10 月 21 日** - 研究人员跟进，请求提供修复时间表。 - **2025 年 11 月 15 日** - 供应商回应，对严重性提出异议，并根据声明的威胁模型对该问题进行定性。 - **2025 年 11 月 19 日** - 研究人员向 CISA VINCE 提交该案例。 - **2026 年 2 月 5 日** - CISA 开始审查。 - **2026 年 2 月 12 日** - CryptPad 加入 VINCE 协调。 - **2026 年 2 月 16 日 – 2026 年 3 月 20 日** - 供应商与 CISA 的讨论继续进行。 - **2026 年 4 月 24 日** - 相关的 CVE-2025-51846 WebSocket DoS 由 CISA 发布。 - **2026 年 4 月 29 日** - MITRE 确认 CVE-2025-51847 被拒绝，并指示研究人员进入 CISA 争议处理流程。 - **2026 年 5 月 1 日** - 研究人员向 CISA 提交了关于插件加载、提供的 JavaScript 修改、持久性及范围更改的额外技术证据。 - **2026 年 5 月** - CISA 确认其未对技术发现提出异议，但基于 CryptPad 的威胁模型和恶意管理员解释，坚持不分配 CVE。CISA 还表示，如果另一个 CNA 得出不同结论，它不会对另一个 CNA 分配该问题提出异议。 ## 相关问题 - CVE-2025-51846 CVE-2025-51846 是一个涉及无限制 WebSocket 帧洪泛导致拒绝服务的独立漏洞。它已被 CISA 接受并发布。 它与本建议相关，因为它可以强制服务重启，而插件加载恰好发生在重启时。 然而，CVE-2025-51846 和插件加载行为是两个独立的问题。 ## 研究人员立场 研究人员尊重 CryptPad 定义自身威胁模型的权利，也尊重 CISA 作为 CNA 的裁量权。 本建议的目的不是重新争论 CVE 的决定，而是记录经过技术验证、对运维人员具有实际安全相关性的行为。 核心观点是： 即使没有分配 CVE，这也是重要的运维安全信息。 ## 结论 CryptPad 2025.3.1 中的插件加载机制提供了一条强大的服务端扩展路径。在测试的部署中，该路径缺乏签名、允许列表、沙箱隔离和完整性验证。通过此机制加载的插件在服务器进程中执行，可以访问敏感的服务器环境值，并且可以修改提供给每个客户端浏览器的 JavaScript。 CISA 没有分配 CVE，因为该场景被认为超出了 CryptPad 声明的威胁模型，等同于恶意管理员行为。研究人员接受这是 CISA 的决定。 然而，技术行为对运维人员仍然很重要。CryptPad 自己的文档指出，如果服务器提供了修改过的客户端 JavaScript，就无法建立安全保障。所执行的测试证实，加载的插件可以准确制造出这种状况。 因此，运维人员应将 `lib/plugins/`、`/cryptpad/www/` 和 `/cryptpad/customize/` 视为敏感执行面，并对其进行相应的加固。 ## 参考文献 CryptPad 威胁模型： ``` https://blueprints.cryptpad.org/document/threatmodel/ ``` 归档： ``` https://web.archive.org/web/20260501123704/https://blueprints.cryptpad.org/document/threatmodel/ ``` CryptPad 恶意 JavaScript 用户故事： ``` https://blueprints.cryptpad.org/document/user-stories/malicious-javascript/ ``` 归档： ``` https://web.archive.org/web/20260406213307/https://blueprints.cryptpad.org/document/user-stories/malicious-javascript/ ``` CryptPad 安全博客： ``` https://blog.cryptpad.org/2024/03/14/Most-Secure-CryptPad-Usage/ ``` 归档： ``` https://web.archive.org/web/20260501124243/https://blog.cryptpad.org/2024/03/14/Most-Secure-CryptPad-Usage/ ``` CryptPad 白皮书： ``` https://blog.cryptpad.org/images/whitepaper.pdf ``` 归档： ``` https://web.archive.org/web/20260501124512/https://blog.cryptpad.org/images/whitepaper.pdf ``` CryptPad 用户安全文档： ``` https://docs.cryptpad.org/en/user_guide/security.html ``` 归档： ``` https://web.archive.org/web/20260418181447/https://docs.cryptpad.org/en/user_guide/security.html ``` CryptPad 源代码，版本 2025.3.1： ``` https://github.com/cryptpad/cryptpad/blob/2025.3.1/lib/plugin-manager.js https://github.com/cryptpad/cryptpad/blob/2025.3.1/server.js https://github.com/cryptpad/cryptpad/blob/2025.3.1/lib/env.js ``` 归档： ``` https://web.archive.org/web/20260501124645/https://github.com/cryptpad/cryptpad/blob/2025.3.1/lib/plugin-manager.js https://web.archive.org/web/20260501125027/https://github.com/cryptpad/cryptpad/blob/2025.3.1/server.js https://web.archive.org/web/20260501125050/https://github.com/cryptpad/cryptpad/blob/2025.3.1/lib/env.js ``` 相关 CVE： ``` CVE-2025-51846 https://www.cve.org/CVERecord?id=CVE-2025-51846 ``` ## 最终说明 本建议的发布是为了提高运维人员的意识并提供加固指南。 技术发现是通过协调披露审查的。CISA 并未对技术证据提出异议，但根据其对供应商威胁模型和恶意管理员边界的解释，未分配 CVE。 研究人员的观点是，无论 CVE 状态如何，该行为都具有安全显著性，因为它影响了 CryptPad 服务器与负责加密的客户端代码之间的信任边界。 👤 研究人员 John Perifanis | 联系方式: https://www.linkedin.com/in/ioannis-p-9081842b9

标签：CISA, CISA项目, CryptPad, CVE-2025-51846, DNS 解析, Docker, GNU通用公共许可证, JSONLines, MITM代理, Node.js, Web安全, XSS, 代码执行, 协议分析, 威胁模型, 安全漏洞, 安全防御评估, 插件加载, 文件完整性, 暗色界面, 权限提升, 沙箱逃逸, 漏洞情报, 端侧安全, 蓝队分析, 请求拦截, 零信任