xiaohack's Blog - Deno
type: channel
link: https://blog.xiaohack.org/tag/deno/
items: CVE-2026-24002：严重沙箱逃逸漏洞致格里斯电子表格沦为远程代码执行攻击工具
items: Hono 路由器为什么这么快？
items: HonoX：下一代全栈 Web 框架深度解析
items: Node.js 之父宣判“手写代码时代结束”！DHH 明确反对“结束论”：大模型还差口气，手写更有竞争力
items: 使用 deno 每天定时重部署 Render 项目（CLI Proxy API）
items: Deno 高危漏洞可导致密钥泄露（CVE-2026-22863）与代码执行（CVE-2026-22864）
items: 一个 cors 跨域网关代码生成器，支持 cloudflare 和 deno 数据，可以在线调试
items: Toolbaz 2api deno 版（假流）自动获取模型，去除末尾模型标记

CVE-2026-24002：严重沙箱逃逸漏洞致格里斯电子表格沦为远程代码执行攻击工具
type: item
date: 2026-01-30T11:40:20+08:00
description: 赛拉研究实验室在 Grist-Core 中发现的一处严重漏洞，让看似无害的电子表格公式，成为攻陷整个企业组织的关键。该漏洞编号为CVE-2026-24002，CVSS 评分高达 9.1 分，攻击者可利用其突破该平台的 Pyodide 沙箱防护，实现完全的远程代码执行（RCE）。Grist 作为 Excel 的可编程替代工具，在政府、教育及各行业中应用广泛，其核心优势是支持在单元格中运行 Python 代码以实现工作流自动化。但研究人员发现，这一 “可编程数据层” 的底层架构存在严重脆弱性。与依赖明显代码注入手段的传统攻击不同，该漏洞的利用方式是将合法的数据包武器化，攻击流量会沿着 Grist 解析公式的常规数据处理路径执行，让日常的电子表格更新操作，沦为悄无声息的系统接管行为。研究报告详细阐述了攻击者可突破沙箱边界的三种具体方式： 类层级遍历：利用 Python 的对象模型，访问os.system()等被禁用的内置函数； 直接调用 C 库：借助 ctypes 库，从内存中直接调用系统底层函数； 滥用 Emscripten 运行时：调用emscripten_run_script_string()函数，在宿主运行时环境中执行 JavaScript 代码。 该漏洞造成的后果极为严重：此次沙箱逃逸并非仅能实现本地服务器的远程代码执行，还可攻陷运行租户工作流的 SaaS 控制层，实现该层面的远程代码执行。Grist 安全团队已迅速采取行动修复该漏洞，此次修复涉及底层架构的根本性调整：将 Pyodide 公式的执行环节，默认迁移至 Deno 运行时环境中进行。这一调整的关键意义在于改变了漏洞的触发后果：此前的情况是 “一旦突破 Pyodide 沙箱，就会直接攻陷宿主系统”，而现在宿主运行时的权限完全由 Deno 的权限模型管控，从根源上降低了风险。研究人员敦促管理员立即将 Grist 升级至1.7.9 及更高版本，同时需注意切勿禁用新的防护机制。报告警示，若设置配置项GRIST_PYODIDE_SKIP_DENO=1，将会绕过此次修复，该操作应被视为主动选择使用防护能力更弱的隔离边界。研究人员指出：当一款自动化或数据平台成为受信任的执行环境时，其沙箱逃逸漏洞带来的就不再是单一服务器的故障，而是整个信任边界的崩塌。

Hono 路由器为什么这么快？
type: item
date: 2026-01-25T11:42:35+08:00
description: 从底层引擎优化角度，深入剖析 Hono 路由器的极致性能奥秘引言在众多 JavaScript Web 框架中，Hono 以其极致的性能表现脱颖而出。特别是在 Cloudflare Workers、Deno 等边缘计算环境中，Hono 的路由匹配速度在同类框架中名列前茅。这背后的秘密是什么？答案就藏在它的 RegExpRouter 实现中。⚠️ 重要提示：本文重点讨论 RegExpRouter 的核心原理。在实际应用中，Hono 使用 SmartRouter 自动组合多种路由器（RegExpRouter、TrieRouter、LinearRouter）以达到最佳性能。本文将通过一个精简的实现，深入剖析 Hono 路由器的核心原理，帮助你理解：为什么 RegExp 路由比传统路由快路由是如何预编译的参数提取的巧妙设计📌 关键要点项目说明核心原理将路由预编译为正则表达式，利用引擎底层优化性能优势减少 JS 层开销，一次原生调用完成匹配最佳环境Cloudflare Workers、Deno 等边缘计算平台实际架构SmartRouter + RegExpRouter + TrieRouter 组合权衡考虑Node.js 环境性能打折扣，路由注册较慢传统路由的性能瓶颈在理解 Hono 的优化之前，我们先看看传统路由的处理方式：// 传统路由的典型实现 function matchRoute(path, routes) { for (const route of routes) { // 1. 字符串分割 const pathParts = path.split('/'); const routeParts = route.path.split('/'); // 2. 逐段比较 if (pathParts.length !== routeParts.length) continue; const params = {}; let matched = true; // 3. JS 层面的循环和条件判断 for (let i = 0; i < pathParts.length; i++) { if (routeParts[i].startsWith(':')) { params[routeParts[i].slice(1)] = pathParts[i]; } else if (pathParts[i] !== routeParts[i]) { matched = false; break; } } if (matched) return { route, params }; } return null; }性能问题在哪里？❌ 大量的字符串操作（split、slice）❌ 多层循环和条件判断，全在 JavaScript 层面执行❌ 每个请求都要重复这些操作Hono 的解决方案：下沉到引擎层Hono 的核心思想非常简单却极其巧妙：将路由匹配逻辑从 JavaScript 层下沉到 JavaScript 引擎底层（C++ 实现的正则表达式引擎）1. 预编译阶段（应用启动时）在应用启动时，Hono 会将路由路径转换为正则表达式：// 路由路径：/user/:id/posts/:postId // 转换为正则：/^\/user\/([^/]+)\/posts\/([^/]+)$/ const paramNames: string[] = []; const regexPath = path.replace(/:([a-zA-Z0-9_]+)/g, (_, paramName) => { paramNames.push(paramName); // 记录参数名 return '([^/]+)'; // 替换为捕获组 }); const pattern = new RegExp(`^${regexPath}$`);关键点：:id → ([^/]+)：匹配除 / 外的任意字符参数名被保存在 paramNames 数组中这个"昂贵"的编译过程只在启动时执行一次2. 匹配阶段（请求到来时）当请求到来时，只需要一行代码：const match = pattern.exec(path);这行代码的魔法：✅ exec 是 JavaScript 引擎的原生方法，由 C++ 实现✅ 正则引擎在底层进行了高度优化（状态机、JIT 编译等）✅ 无需手动分割字符串、无需 JS 层循环✅ 参数提取通过捕获组自动完成3. 参数提取匹配成功后，参数提取也非常简洁：const params: Record<string, string> = {}; route.paramNames.forEach((name, index) => { params[name] = match[index…

HonoX：下一代全栈 Web 框架深度解析
type: item
date: 2026-01-25T11:29:17+08:00
description: 一个基于 Hono 的全栈 Web 框架，结合了 Islands 架构和边缘计算的强大能力引言在现代 Web 开发中，我们面临着一个永恒的挑战：如何在提供丰富交互体验的同时，保持快速的加载速度和优秀的性能？传统的单页应用（SPA）虽然交互流畅，但首屏加载慢、SEO 困难；而传统的服务端渲染（SSR）虽然首屏快，但缺乏现代前端框架的开发体验。HonoX 的出现，为这个问题提供了一个优雅的解决方案。它是基于超快的 Hono Web 框架构建的全栈框架，采用 Islands 架构，完美平衡了性能和开发体验。什么是 HonoX？HonoX 是一个全栈 Web 框架，它建立在 Hono 之上。Hono 是一个轻量级、超快速的 Web 框架，可以运行在任何 JavaScript 运行时（Cloudflare Workers、Deno、Bun、Node.js 等）。核心特性Islands 架构 - 渐进式水合，只在需要的地方加载 JavaScript文件路由系统 - 基于文件系统的直观路由边缘优先 - 为 Cloudflare Workers 等边缘运行时优化类型安全 - 完整的 TypeScript 支持零配置 - 开箱即用的最佳实践极致性能 - 继承 Hono 的超快性能Islands 架构：重新思考前端水合什么是 Islands 架构？Islands 架构是一种现代前端架构模式，最早由 Etsy 的前端架构师 Katie Sylor-Miller 提出，后来被 Astro、Fresh 等框架采用。想象一个网页是一片海洋，而需要交互的组件是海洋中的"岛屿"：┌─────────────────────────────────┐ │ 静态 HTML（服务端渲染） │ │ │ │ ┌─────────┐ ┌─────────┐ │ │ │ Island │ │ Island │ │ │ │ (交互) │ │ (交互) │ │ │ └─────────┘ └─────────┘ │ │ │ │ ┌─────────┐ │ │ │ Island │ │ │ │ (交互) │ │ │ └─────────┘ │ └─────────────────────────────────┘这种架构的优势在于：减少 JavaScript 负载 - 只加载真正需要的 JavaScript提升首屏性能 - 静态内容立即可见渐进式增强 - 交互组件逐步加载和激活更好的 SEO - 完整的服务端渲染内容HonoX 中的 Islands在 HonoX 中使用 Islands 非常简单：// app/islands/Counter.tsx import { useState } from 'hono/jsx' export default function Counter({ initialCount = 0 }) { const [count, setCount] = useState(initialCount) return ( setCount(count - 1)}>- {count} setCount(count + 1)}>+ ) }只需将组件放在 app/islands/ 目录下，HonoX 会自动处理：服务端渲染客户端代码分割按需水合在页面中使用：// app/routes/index.tsx import Counter from '../islands/Counter' export default function Home() { return ( 我的页面 这段文字是纯静态的，不需要 JavaScript <Counter initialCount={0} /> ) }文件路由系统：约定优于配置HonoX 采用基于文件的路由系统，让路由管理变得直观：app/routes/ ├── index.tsx → / ├── about.tsx → /about ├── blog/ │ ├── index.tsx → /blog │ └── [slug].tsx → /blog/:slug └── api/ ├── users.ts → /api/users └── users/ └── [id].ts → /api/users/:id动态路由使用方括号定义动态路由参数：// app/routes/blog/[slug].tsx import { createRoute } from 'honox/factory' export default createRoute((c) => { const { slug } = c.req.param() return c.render( 文章：{slug} ) })API 路由API 路由返回 JSON 数据…

Node.js 之父宣判“手写代码时代结束”！DHH 明确反对“结束论”：大模型还差口气，手写更有竞争力
type: item
date: 2026-01-21T16:34:55+08:00
description: Ryan Dahl 在 1 月 20 日给软件工程下了结论：“人类写代码的时代已经结束。”留下的工作里，不包括继续手写语法。 如果这话出自某个科技网红，大概刷过去就算了。但 Ryan Dahl 不一样——他不仅写出了 Node.js，后来还“推倒重来”做了 Deno。你可以把他的意思理解为：写代码这部分会越来越自动化，而人的价值会更多落在判断、取舍和责任上。 而在 Ryan Dahl 这次“宣判”之前，1 月 3 日，Ruby on Rails 作者 DHH 也在 X 上连发多条，语气罕见地偏“乐观派”： “别让那些粗制滥造和尴尬翻车，遮住你对 AI 的惊叹。自从我们把计算机连上互联网以来，这是我们让计算机做到过的最令人兴奋的事。如果你在 2025 年一直对 AI 悲观或怀疑，不如在 2026 年的开端，用一点乐观和好奇再试试看？” 于是，社区里迅速冒出一种更夸张、但传播力极强的解读：“DHH 都松口了。”“连最不买账的人都开始给 AI 站台——你还有什么理由不用？”甚至有人干脆把它说成：“DHH 也扛不住了，最终还是向 AI 屈服低头了。” 但你真去听 DHH 的原话，会发现所谓“DHH 屈服论”，并不是那么回事儿。 在最新一期播客中，他说在 37signals，AI 没有在写真实产品，更谈不上“从零写出什么东西”。 他在用 AI，而且每天都用，但更多是做那种“一发入魂”的小实验；一旦进入真工程：要持续演进、要迭代、要打磨，他就会觉得：“这在浪费我的时间，到这一步我自己写更快。” 所以他们的新产品 Fizzy 里 95% 的代码，还是人类亲手敲出来的。 他还补了一句：我们离那种“AI 让一切始终更好、更快、更省心”的明显拐点，还差一点。 “就现在而言，我仍然在意代码的样子。我在意它的美感。我在意打磨、推敲、润色。” 更关键的是，他不是在怀旧。他明确说：“手写代码依然有竞争力。”“至少在此时此刻，这是一个仍然有竞争力的选择。” 而且他的判断正好和 Ryan Dahl 相反：“我们并没有到 AGI，没有到那种‘人类写代码的时代死了’的程度。” 挺好玩的是，DHH 还说要远离 Anthropic 的 CEO：他一听到那种“再过五分钟就不需要程序员了”的口吻就火大，直接开喷：“你们到底用的啥模型啊？”反正他自己用的是 Opus 4.5（或当下版本），但在他的体验里，这种“程序员马上下岗”的说法完全不符合现实——尤其是那些要长期维护、持续迭代、不断演进的真实工程，离“五分钟结束”差得十万八千里。 以下是 DHH 播客整理全文翻译： “如果浏览 Web 的不再是人类” 主持人：欢迎大家来到《Next Token》。今天这期节目对我来说有点特别，可能要追溯到 25 年前。很高兴请到 DHH——David Heinemeier Hansson。欢迎你。DHH：很高兴来，谢谢邀请。 主持人：我猜你可能是刚从赛车里下来（笑）。DHH：现在是休赛期，正好歇一歇。 主持人（Torsten）：那我就先来点“热血沸腾”的话题。我从 2010 年左右就开始关注你，你可能是对我影响最大的前五位程序员之一。如果没有你，我可能不会走到今天。我职业生涯中有七八年都在写 Rails，看了你所有的书、博客。我们其实从没见过面，但有一次“交集”让我印象极深——我发过一条关于 Cookie Banners 的吐槽推文，那是我人生中传播最广的一条推文。那天中午我被 Cookie Banners 气疯了，随手发了一条，然后彻底炸了。第二天你转推并评论说：“这就是为什么人们不再浏览 Web，而是开始用 ChatGPT。” 所以我想直接问你：欧盟最近说要“取消 Cookie Banners”，你觉得这真的能改善什么吗？还是说——已经太迟了？ DHH：我认为 Cookie Banners 是 Web 体验变得糟糕的一个主要原因。它们几乎比早期那种弹窗广告还要糟糕——你知道的，“打地鼠”“打猴子”那种 2000 年初的弹窗。当年浏览器还能通过技术手段封杀弹窗，但 Cookie Banners 没有一个统一、有效的技术解决方案。我知道有插件能挡，但大多数人不会装。结果就是：Cookie Banners 成了互联网的一场瘟疫。 我是丹麦人，所以我觉得我有资格狠狠吐槽欧盟。Cookie Banners 最初的出发点是“高尚的”——限制数据收集、提高透明度。但这套东西在第一个 Cookie Banners 出现 5 分钟后，就已经被证明是失败的。可欧盟花了整整 15 年，才开始承认这个问题。现在他们说要“移除”Cookie Banners。但“移除”是什么意思？你以为这就能抹掉你对互联网造成的破坏吗？不可能。接下来30 年，仍然会有大量网站继续保留 Cookie Banners——因为删掉…

使用 deno 每天定时重部署 Render 项目（CLI Proxy API）
type: item
date: 2026-01-20T10:04:35+08:00
description: CLI Proxy API 的核动力驴一天 3 个小版本，每天打开电脑都是打开 render 更新部署。于是搓了这样一个用 Deno Deploy 的 cron 触发 Render deploy hook 的小工具每天凌晨 4 点自动更新 render 部署的 cpa（你也可以用来更新其他 render 项目）去这里复制一下 Deploy Hook 就好了，改一下代码里面占位的 RENDER_HOOK_URL非常简单的小工具/** * Project: render-auto-deploy (sanitized, hardcoded URL version) * Purpose: 用 Deno Deploy Cron 定时触发 Render Deploy Hook（自动 redeploy） * * ✅ 你需要改的地方（部署时只改这两处）： * 1) 把 RENDER_HOOK_URL 改成你自己的 Render Deploy Hook URL（包含 service id + key） * 2) 如果想换时间，把 CRON_SCHEDULE 改成你要的 cron（注意：Deno.cron 用 UTC） * * ✅ 验证方法： * - 打开 "/"：看到 running + 当前 UTC 时间 + schedule * - 打开 "/trigger"：立刻触发一次 Render 部署（返回 deploy.id） * - 去 Render Events：会出现 “Triggered via Deploy Hook” * * 🔥 时区提醒： * - Deno.cron 的 cron 表达式按 UTC 解释 * - 例：UTC 20:00 = 北京时间次日 04:00 */ // ======================【部署时改这里 1】====================== // Render Deploy Hook（占位符，换成你自己的） // 形如：https://api.render.com/deploy/<YOUR_SERVICE_ID>?key=<YOUR_DEPLOY_KEY> const RENDER_HOOK_URL = "https://api.render.com/deploy/<YOUR_SERVICE_ID>?key=<YOUR_DEPLOY_KEY>"; // ======================【部署时改这里 2】====================== // Cron 表达式按 UTC 解释： // - "0 20 * * *" => 每天 UTC 20:00（北京时间次日 04:00） // - 测试用： "*/1 * * * *" => 每分钟触发一次（用来验证 cron 是否生效） const CRON_SCHEDULE = "0 20 * * *"; function nowIso() { return new Date().toISOString(); } async function triggerRenderDeploy(source: "cron" | "http") { const runId = crypto.randomUUID(); console.log(`[${nowIso()}] [${source}] runId=${runId} ⏰ trigger start`); // 超时：避免网络卡住导致任务悬挂 const controller = new AbortController(); const timeout = setTimeout(() => controller.abort(), 30_000); try { const resp = await fetch(RENDER_HOOK_URL, { method: "POST", // Render deploy hook 通常 GET/POST 都可，这里用 POST signal: controller.signal, headers: { "user-agent": "render-auto-deploy/deno" }, }); const text = await resp.text().catch(() => ""); if (!resp.ok) { // 抛错 => 让 cron 的 backoffSchedule 生效，自动重试 throw new Error( `Render hook failed: ${resp.status} ${resp.statusText} body=${text.slice(0, 500)}`, ); } console.log( `[${no…

Deno 高危漏洞可导致密钥泄露（CVE-2026-22863）与代码执行（CVE-2026-22864）
type: item
date: 2026-01-20T00:02:08+08:00
description: 以 “默认安全” 架构闻名的现代 JavaScript/TypeScript 运行时 Deno 近期曝出两个重大安全漏洞。这两个漏洞分别影响运行时的加密兼容性层和 Windows 平台的命令执行机制，可能导致敏感服务器密钥泄露，并允许攻击者执行任意代码。 CVE-2026-22863：高危密钥泄露漏洞（CVSS 9.2） 两个漏洞中最严重的是 CVE-2026-22863，CVSS 评分 9.2。该漏洞存在于 Deno 的 node:crypto 兼容层 —— 一个用于让 Deno 运行 Node.js 代码的模块。 根据安全公告，node:crypto 的实现没有正确终结（finalize）加密器（cipher）。在标准的加密流程中，final() 方法应结束加密过程并清理内部状态。然而在受影响的 Deno 版本中，该方法没有真正关闭 cipher，导致加密器处于 “可无限加密” 的异常状态。 这一缺陷的影响极为严重。报告指出，这种状态管理错误 “可能导致攻击者进行暴力破解，或发起更高级的攻击以窃取服务器密钥”。分析中提供的 PoC 显示，调用 cipher.final() 后返回的是一个仍处于激活状态的 Cipheriv 对象，其内部缓冲状态仍然可被访问，而非预期的已关闭 CipherBase。 CVE-2026-22864：Windows 命令执行绕过（RCE） 第二个漏洞 CVE-2026-22864 影响 Deno 在 Windows 上启动子进程的能力。研究人员发现，这是一个 “对已修补漏洞的绕过”，涉及在执行批处理文件时使用 Deno.Command API。 Deno 原本包含防止 shell 注入的安全机制。当用户尝试直接运行 .bat 文件时，Deno 会抛出 PermissionDenied 错误，并提示开发者 “使用 shell 执行 bat 或 cmd 文件”，以确保参数被安全处理。 然而研究人员找到了绕过方法：通过修改文件扩展名的大小写（例如使用 .BAT）或操控传入命令的参数，攻击者可以绕过 Deno 的安全限制。报告中包含的 PoC 截图显示，一个脚本通过在批处理执行上下文里注入参数 ["&calc.exe"]，成功执行了 Windows 计算器（calc.exe），从而在目标机器上实现任意代码执行。 建议与修复 官方强烈建议用户立即升级到 Deno v2.6.0 或更高版本以修复这两个漏洞。

Deno 高危漏洞可导致密钥泄露（CVE-2026-22863）与代码执行（CVE-2026-22864）
type: item
date: 2026-01-19T18:24:43+08:00
description: 以 “默认安全” 架构闻名的现代 JavaScript/TypeScript 运行时 Deno 近期曝出两个重大安全漏洞。这两个漏洞分别影响运行时的加密兼容性层和 Windows 平台的命令执行机制，可能导致敏感服务器密钥泄露，并允许攻击者执行任意代码。 CVE-2026-22863：高危密钥泄露漏洞（CVSS 9.2） 两个漏洞中最严重的是 CVE-2026-22863，CVSS 评分 9.2。该漏洞存在于 Deno 的 node:crypto 兼容层 —— 一个用于让 Deno 运行 Node.js 代码的模块。 根据安全公告，node:crypto 的实现没有正确终结（finalize）加密器（cipher）。在标准的加密流程中，final() 方法应结束加密过程并清理内部状态。然而在受影响的 Deno 版本中，该方法没有真正关闭 cipher，导致加密器处于 “可无限加密” 的异常状态。 这一缺陷的影响极为严重。报告指出，这种状态管理错误 “可能导致攻击者进行暴力破解，或发起更高级的攻击以窃取服务器密钥”。分析中提供的 PoC 显示，调用 cipher.final() 后返回的是一个仍处于激活状态的 Cipheriv 对象，其内部缓冲状态仍然可被访问，而非预期的已关闭 CipherBase。 CVE-2026-22864：Windows 命令执行绕过（RCE） 第二个漏洞 CVE-2026-22864 影响 Deno 在 Windows 上启动子进程的能力。研究人员发现，这是一个 “对已修补漏洞的绕过”，涉及在执行批处理文件时使用 Deno.Command API。 Deno 原本包含防止 shell 注入的安全机制。当用户尝试直接运行 .bat 文件时，Deno 会抛出 PermissionDenied 错误，并提示开发者 “使用 shell 执行 bat 或 cmd 文件”，以确保参数被安全处理。 然而研究人员找到了绕过方法：通过修改文件扩展名的大小写（例如使用 .BAT）或操控传入命令的参数，攻击者可以绕过 Deno 的安全限制。报告中包含的 PoC 截图显示，一个脚本通过在批处理执行上下文里注入参数 ["&calc.exe"]，成功执行了 Windows 计算器（calc.exe），从而在目标机器上实现任意代码执行。 建议与修复 官方强烈建议用户立即升级到 Deno v2.6.0 或更高版本以修复这两个漏洞。

一个 cors 跨域网关代码生成器，支持 cloudflare 和 deno 数据，可以在线调试
type: item
date: 2026-01-11T08:37:08+08:00
description: 主要用来解决纯前端发起 api 请求时的 cors 跨域问题，直接透传给目标 api cors-gw-generator.252035.xyz CORS Gateway Generator 支持在线调试，为了防止大串 base64 干扰，Body 里会显示高亮占位符，真实请求时自动替换为图片 base64📌 转载信息来源： https://linux.do/t/topic/1427560原作者： fish2018转载时间： 2026/1/11 08:37:04

Toolbaz 2api deno 版（假流）自动获取模型，去除末尾模型标记
type: item
date: 2026-01-08T17:39:30+08:00
description: Toolbaz 2api Python 版（仅非流）支持：Gemini 2.5 Pro、GPT-5、Claude Sonnet 4 开发调优，Lv1直接运行就可以对话，注意不支持流式传输！ #!/usr/bin/env python3 # -*- coding: utf-8 -*- """ Toolbaz.com AI Writer API 对话脚本 支持多轮对话和流式响应 """import json import base64 import time import random import string import reques…在佬的基础上改了个 deno 版的加了自动获取模型和去除末尾模型标记单 ip 每天限制 150 次好像每分钟 5 次📌 转载信息来源： https://linux.do/t/topic/1420271原作者： zzzx9转载时间： 2026/1/8 17:39:20