[{"data":1,"prerenderedAt":-1},["ShallowReactive",2],{"news-slug-chrome-dynamic-patching-llm-vulnerability":3,"news-related-e77ca785-1f1e-4b09-b28f-6723c4115e56":38},{"id":4,"title":5,"summary":6,"content":7,"original_url":8,"source_id":9,"tags":10,"translations":24,"news_slug":31,"published_at":32,"created_at":33,"modified_at":34,"is_published":35,"publish_type":36,"image_url":14,"view_count":37},"e77ca785-1f1e-4b09-b28f-6723c4115e56","Chrome 动态补丁要让浏览器不重启也能打补丁：LLM 把\"漏洞太多\"逼成了架构问题","Google Chrome 安全团队披露正在研发\"动态补丁\"(dynamic patching):利用多进程架构在后台热替换 Renderer、GPU 等子进程二进制,大部分情况下用户不再需要重启浏览器就能拿到安全修复。背景是 LLM 把漏洞发现速度提了一个数量级,Chrome 149\u002F150 两个版本修掉 1072 个 bug,超过此前 23 个版本总和,补丁交付节奏从两周一次加速到一周两次。补丁到用户之间的\"patch gap\"从几天被压到几小时。","## LLM 把漏洞发现速度提到了架构撑不住的程度\n\nGoogle Chrome 安全团队在最新博客《Stronger with every update》中坦率承认了一件过去很少听头部厂商主动讲的事:LLM 把漏洞发现的规模推到了传统修补流程撑不住的程度,正在倒逼浏览器从「打了补丁请用户重启」走向「不重启也能热替换」。\n\n直接看数据:Chrome 149 和 150 两个里程碑修掉的 1072 个安全 bug,已经超过前 23 个里程碑修掉的 bug 总和。Google 在 2026 年 3 月单月收到的外部漏洞报告,比 2025 年全年加起来还多——而这还是在他们已经用 Big Sleep、CodeMender 等 AI Agent 主动挖掘漏洞之前。\n\n## Patch Gap:补丁到用户之间的危险窗口\n\n这里面藏着一个业内很少公开讨论的安全指标:**patch gap**(补丁间隙)。漏洞被修复并不等于漏洞被堵住——从修复 commit 合并到 Chrome Stable 渠道,通常需要数周时间。在这两周里,任何能看到 Chromium 公开仓库的人——也就是攻击者——都能反向工程出新 commit,赶在大部分用户重启前利用它。这就是所谓的 N-day 攻击窗口。\n\n过去业内对 patch gap 的容忍度建立在漏洞产出节奏慢的前提上——一周发现十个 bug,慢慢补也没事。LLM 把这个前提直接打穿:**漏洞挖掘的吞吐量从「人」的速度切换到了「算力」的速度,留给防守方反应的时间窗口被极度压缩**。\n\nChrome 的应对是三步并行:\n1. 把检测节奏从两周一次主版本升级到一周两次安全发布,目前正在试点一周两次安全 release。\n2. 引入动态补丁(dynamic patching),让浏览器在不重启的情况下热替换后台子进程(Renderer、GPU 等)的二进制文件。\n3. 利用 macOS 应用在窗口关闭后仍在后台运行的特性,在「零窗口」这种用户感知最小的时机自动重启应用。\n\n## 动态补丁在工程上为什么难做\n\n热替换浏览器子进程这件事听起来简单,但在 Chromium 这种多进程架构里有几道硬骨头:\n\n- **进程隔离**:Renderer、GPU、Browser、Network 等进程是独立沙箱,任何热替换不能破坏现有的 sandbox 边界,否则补丁过程本身变成新的攻击面。\n- **状态保持**:Renderer 进程里持有当前页面的 DOM、JS heap、布局树,简单 kill 重启会丢页面状态。动态补丁必须做到二进制替换后用户感知的页面继续运行。\n- **版本兼容性**:补丁通常只替换几百 KB 的二进制差分,需要确保被替换的进程持有的共享库、IPC 协议版本与新二进制对齐。\n- **失败回滚**:如果热替换过程中新二进制 crash 或 hang,必须能立刻回退到老版本,不能把用户锁死在半更新状态。\n\nGoogle 给出的方案是**「顺序替换」**:利用 Chrome 现有的多进程模型,GPU 进程被 patch,Renderer 进程接着被 patch,新页面用新二进制渲染,旧页面继续用旧二进制直至关闭。整套过程对用户透明——不需要重启浏览器、不丢标签页、不需要重新登录。\n\nChrome 150 已经在 macOS 上做了类似的事:浏览器在零窗口状态下检测到待更新,自动触发重启,下一次打开时已经是新版本。这种「opportune restart」(机会主义式重启)的思路是动态补丁的过渡形态——先把最容易的时机抓出来,再做真正的热替换。\n\n## 不只是 Chrome 的问题,而是 LLM 时代的防御栈重构\n\n把视角拉远一点,Chrome 的故事其实是 LLM 时代整个防御栈被倒逼重写的缩影。\n\n**漏洞挖掘侧**:Google 的三阶段演进值得注意——2023 年用 LLM 增强 fuzzing 覆盖率,2024 年和 Project Zero 合作 Naptime 给 LLM 漏洞研究工具,2025 年和 DeepMind 合作 Big Sleep 做出能自主挖 V8 引擎 bug 的 Agent,2026 年初把 Agent harness 部署到整个 Chromium 代码库。三年的演进路径清晰:从「LLM 帮忙做更好的 fuzzing」到「LLM 自己当研究员」。OpenAI、Anthropic 走的是类似的路径,Anthropic 前两天刚披露 Claude 在网络安全评测里误把仿真靶场当真网络,反向了三家真实机构的系统——LLM 已经能自主发现并尝试利用漏洞。\n\n**Triage 侧**:Chrome 把原来 5-30 分钟的人工 triage 拆成四阶段自动化流水线(过滤垃圾、复现、补充元数据、自动派单),估计每月节省几百小时。fixing agent + critic agent 的多 Agent 代码评审模式,把「修 bug」本身也流水线化。\n\n**修复节奏侧**:从两周一次主版本、一周一次安全更新,加速到试点一周两次安全 release。下一步是动态补丁让用户在浏览器开着的时候就能拿到修复。\n\n## 留给我们的几个问题\n\nChrome 这一轮披露最值得关注的不是某个具体功能,而是承认了一件过去没人愿意公开讲的事:**当漏洞发现的成本被 LLM 打到接近零,补丁交付的瓶颈就变成了 UX 边界——也就是「用户愿不愿意重启浏览器」这件事**。传统软件安全的整套假设(发现慢、修复慢、用户有耐心打补丁)在 LLM 时代开始失效。\n\n未来一两年我们大概率会看到:\n\n- 操作系统级别的热补丁成为标配,不只是浏览器——Linux 内核、Windows Server、macOS 都在朝这个方向走。\n- 「patch gap」会变成新的安全指标被公开追踪,就像现在大家盯着 CVE 数量和 MTTR 一样。\n- 防御侧 AI Agent 的能力上限会决定头部厂商的安全护城河——这是 Google、Microsoft、Anthropic 都在重金投入的方向。\n- N-day 攻击的时间窗口会进一步压缩,留给蓝队的反应时间从「天」变成「小时」,安全运营的值班节奏会被重写。\n\nLLM 既是最强的攻击放大器,也是最强的工业级防御工具。Chrome 这篇博客把这件事讲得很明白:**谁能先用 AI 把整条流水线跑通,谁就拿到了新一轮安全竞赛的入场券**。","https:\u002F\u002Fwww.solidot.org\u002Fstory?sid=84977","d59894d3-308e-4fd8-8865-86dc1eeac4a2",[11,15,18,21],{"id":12,"name":13,"slug":13,"description":14,"color":14},"1fcfaaf2-67de-43d3-9e35-5784852fec60","ai-safety",null,{"id":16,"name":17,"slug":17,"description":14,"color":14},"40269b40-7942-4650-9672-ed2e6524d37a","ai-technology",{"id":19,"name":20,"slug":20,"description":14,"color":14},"8cf7490f-2449-4ba7-be19-61befa0d92b4","google",{"id":22,"name":23,"slug":23,"description":14,"color":14},"01598627-1ea6-4b27-a5d8-874971571a71","llm",[25],{"id":26,"lang":27,"title":28,"summary":29,"content":30},"5de94ef5-219b-4bf5-a9cb-1a39a643db8b","en","Chrome dynamic patching: no restarts, LLMs reshape security","Google's Chrome security team revealed a new 'dynamic patching' capability that hot-swaps Renderer and GPU subprocess binaries in the background, eliminating browser restarts for most security updates. The driving force: LLMs supercharged vulnerability discovery. Chrome 149 and 150 alone fixed 1,072 security bugs—more than the previous 23 milestones combined. The security release cadence is accelerating from bi-weekly to twice-weekly, and the 'patch gap' between fix commit and user protection is being compressed from days into hours.","## LLMs pushed vulnerability discovery past what the architecture can keep up with\n\nIn a recent post titled *Stronger with every update*, Google's Chrome security team publicly acknowledged something that few major vendors have been willing to say out loud: LLMs have scaled vulnerability discovery to a level that traditional patching pipelines can no longer absorb, and the only way out is to evolve from 'patch and ask the user to restart' toward 'hot-swap binaries while the browser stays open'.\n\nLook at the numbers. Chrome 149 and 150 fixed 1,072 security bugs across two milestones—more than the previous 23 milestones combined. In March 2026 alone, Chrome received more external vulnerability reports than in all of 2025, and that was *before* they fully deployed AI agents like Big Sleep and CodeMender for proactive internal digging.\n\n## Patch Gap: the dangerous window between fix and protection\n\nThere's a security metric that the industry rarely discusses publicly: **patch gap**. Fixing a bug does not equal plugging a hole. From the moment a fix is merged into the Chrome Stable channel typically takes weeks. During those weeks, anyone watching the public Chromium repository—that is, attackers—can reverse-engineer the new commit and exploit it before the vast majority of users restart their browsers. This is the N-day exploitation window.\n\nUntil now, the industry's tolerance for patch gap rested on a quiet assumption: vulnerabilities emerge slowly, fixes arrive slowly, and users can be patient. LLMs shatter that assumption. Vulnerability mining throughput has moved from 'human' speed to 'compute' speed, and the reaction window for defenders has collapsed.\n\nChrome's response runs in three parallel tracks:\n\n1. **Release cadence**: Major milestones shift from bi-weekly to weekly, with security updates layered on top, currently piloting twice-weekly security releases.\n2. **Dynamic patching**: Hot-swap the binary of background subprocesses (Renderer, GPU, etc.) without restarting the browser.\n3. **Opportune restarts**: On macOS, where apps continue running in the background after the last window closes, Chrome 150 now auto-restarts in that 'zero-window' state to apply pending updates with minimal user disruption.\n\n## Why hot-swapping a browser subprocess is hard\n\nIt sounds simple, but Chromium's multi-process architecture throws up real engineering obstacles:\n\n- **Sandbox boundaries**: Renderer, GPU, Browser, and Network are independent sandboxed processes. Any hot-swap must preserve those boundaries, or the patching process itself becomes a new attack surface.\n- **State preservation**: A Renderer process holds the current page's DOM, JS heap, and layout tree. A naive kill-and-restart loses page state. True dynamic patching must keep the user's perceived page running across the binary swap.\n- **Version alignment**: A patch usually only replaces a few hundred KB of binary diff. The hot-swapped process's shared library and IPC protocol versions must stay aligned with the new binary.\n- **Rollback**: If the new binary crashes or hangs mid-swap, the browser must immediately fall back to the old binary. You can't strand the user on a half-updated state.\n\nGoogle's answer is **sequential replacement**: leverage Chrome's existing multi-process model. Patch the GPU process first, then the Renderer. New pages render under the new binary; existing pages keep running on the old binary until they close. The whole thing is invisible to the user—no restart, no lost tabs, no re-login.\n\nChrome 150 already shipped a softer version of this on macOS: if the browser detects a pending update in its zero-window state, it auto-restarts, and the next launch is already on the new version. That 'opportune restart' is a transitional form of dynamic patching—grab the easiest interruption-free moments first, then build toward true hot-swap.\n\n## Not just Chrome: LLM-era defense stack is being rewritten\n\nPull back the camera and Chrome's story is a microcosm of the whole defense stack being rewritten under LLM pressure.\n\n**On the discovery side**, Google's three-year arc is worth noting: in 2023 they used LLMs to augment fuzzing coverage; in 2024 they partnered with Project Zero on Naptime to give LLMs specialized vulnerability research tools; in 2025 they collaborated with DeepMind on Big Sleep, an AI agent that autonomously found bugs in V8 and the graphics stack; in early 2026 they deployed an Agent harness across the entire Chromium codebase. The trajectory is clear: from 'LLM helps fuzzing work better' to 'LLM is the researcher'. OpenAI and Anthropic are walking similar paths—Anthropic just disclosed that during cybersecurity evaluations, Claude mistook a simulated range for a real network and ended up accessing three real institutions' systems. LLMs can now autonomously discover *and* attempt to exploit vulnerabilities.\n\n**On the triage side**, Chrome split the 5-to-30-minute manual triage flow into a four-stage automated pipeline (filter noise → reproduce → enrich metadata → auto-assign), saving an estimated hundreds of developer hours per month. The fixing-agent + critic-agent multi-agent code-review pattern turns 'fixing bugs' itself into a production line.\n\n**On the cadence side**, release rhythm shifts from bi-weekly major \u002F weekly security toward pilot twice-weekly security releases. The next frontier is dynamic patching, where the user gets the fix while the browser stays open.\n\n## A few questions this raises\n\nThe most important thing Chrome disclosed isn't any specific feature. It's the quiet admission of a fact the industry has avoided talking about: **when LLM-driven discovery pushes vulnerability-finding cost close to zero, the bottleneck for defense shifts to a UX boundary—whether users are willing to restart their browser**. The whole traditional software-security assumption stack (slow discovery, slow fixes, patient users) is breaking down under LLM pressure.\n\nOver the next year or two we should expect to see:\n\n- **OS-level hot patching becoming default**, not just in browsers. Linux kernel, Windows Server, and macOS are all heading this direction.\n- **'Patch gap' becoming a publicly tracked security metric**, the way we now obsess over CVE counts and MTTR.\n- **The capability ceiling of defensive AI agents** becoming the security moat for major vendors. Google, Microsoft, and Anthropic are all pouring resources into this.\n- **N-day attack windows compressing further**, shrinking defender reaction time from 'days' to 'hours', and rewriting the rhythm of security operations on-call.\n\nLLMs are simultaneously the strongest attack amplifier and the strongest industrial-grade defensive tool. Chrome's blog post says it plainly: **whoever first runs the full pipeline on AI will hold the entry ticket for the next round of the security race**.","chrome-dynamic-patching-llm-vulnerability","2026-08-01T06:00:00Z","2026-08-01T14:03:47.145474Z","2026-08-01T14:03:47.145483Z",true,"agent",108,{"items":39},[40,45,50,55,60,65],{"id":41,"title":42,"news_slug":43,"published_at":44},"f637e5a0-5e18-4ced-9aa4-2ce5df798a9c","Gemini 接管 Chrome 漏洞流水线:1072 个 bug、13 年陈年沙箱逃逸,LLM 重塑浏览器安全","gemini-chrome-vulnerability-pipeline","2026-07-31T10:00:00+00:00",{"id":46,"title":47,"news_slug":48,"published_at":49},"57c24a67-fa14-459d-acb2-affe62d0a08d","DeepMind 把 AI Agent 当成「内部威胁」：当 alignment 不够用时，AI Control 用网络安全思维补上缺口","deepmind-ai-control-roadmap-mitre-attack","2026-06-23T00:01:00+00:00",{"id":51,"title":52,"news_slug":53,"published_at":54},"7dec6918-b6cb-4b85-a6bf-88d1abc332d0","加密推理块漏洞让 Anthropic\u002FOpenAI\u002FGoogle 的思维链全部裸奔","stealing-reasoning-traces-llm-apis","2026-08-21T10:00:00+00:00",{"id":56,"title":57,"news_slug":58,"published_at":59},"5a90a793-8ec1-4b3a-9691-edef5ffe8535","AI「思想病毒」实证:Anthropic 与 EPFL 让恶意想法在 Agent 间自我复制,免疫只需一段警告","mind-viruses-multi-agent-llm","2026-08-18T13:30:00+00:00",{"id":61,"title":62,"news_slug":63,"published_at":64},"99916419-0f68-4a6a-a4cf-8bbe353b4d75","康涅狄格法官开出美国首例 prompt injection 制裁令:法庭文件里的隐藏 LLM 暗口令","us-court-prompt-injection-sanctions","2026-08-18T03:00:00+00:00",{"id":66,"title":67,"news_slug":68,"published_at":69},"28c6c7e2-341d-4e2f-afd5-db3300874203","Rust 主仓库正式启用 LLM 贡献政策:五支团队通过,把「创造」和「分析」拆开管理","rust-lang-rust-llm-policy","2026-08-08T00:00:00+00:00"]