[{"data":1,"prerenderedAt":-1},["ShallowReactive",2],{"news-slug-claude-attack-surface-reduction-openssh":3,"topics-all":38,"news-related-5796d012-e921-4760-b58f-653b90c151b1":57},{"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},"5796d012-e921-4760-b58f-653b90c151b1","Claude 削攻击面:25 个开源项目 493 处问题","「削攻击面」取代「找漏洞」:Anthropic 红队用 Claude 跑 25 个开源项目、逾 500 万行代码,盘出 17000 个配置项,报 493 处问题。OpenSSH 10.4 默认配置下约 4500 行 ML-DSA-44 代码未认证即可触达,占默认 sshd 认证前代码 16%,修复随 10.6 落地。","修漏洞这件事，从业者一直有个朴素的抱怨：找到一个、堵上一个，账单上剩下的洞一个没少。Anthropic 的前沿红队最近换了个思路——不去猜下一个洞在哪，而是去问「这套部署下，哪些代码根本不该被摸到」。\n\n他们在 10 月 20 日发布的研究文章（https:\u002F\u002Fwww.anthropic.com\u002Fresearch\u002Fattack-surface-reduction）里，把这个思路叫作攻击面分析与削减，并用 Claude 跑了一遍：25 个开源项目、超过 500 万行代码，涉及 C、C++、Java、PHP 和 Python。Claude 为这些项目盘出了超过 17000 个配置项，其中 3842 个与安全相关的控制或功能有关，最终报出 493 个问题。\n\n## 三种查法，不是三种找 bug\n\n文章里明确区分了「找漏洞」和「削可达性」：前者针对具体缺陷，后者降低那些尚未被发现的缺陷的严重度。\n\n第一种查默认配置：哪些代码在出厂配置下就可达，却没有任何默认功能会用到它。\n\n第二种查配置交互：哪些选项单独看都合理，凑一起就出事。Claude 找到 162 组安全敏感的组合，既不报错也不告警；其中 94 组直接把某项安全控制静默关掉，剩下 68 组则是同一机制内部的不一致，比如配置声明某监听已禁用、实际路径却还留着。\n\n第三种查早期可达：哪些敏感又复杂的代码跑在安全控制（通常是认证）之前，或者跑在协议状态机切换之前。\n\n## 最意外的是需要先登录的那一组\n\nAnthropic 把 25 个项目分成三类：面向任意来访者的 Public 10 个、面向已认证用户的 Gated 11 个、仅供运营方私用的 Private 4 个。逻辑上 Public 天然有大量默认可达代码，Gated 则本该相反——结果恰恰是 Gated 组最出人意料：默认配置下 93 处不必要的认证前暴露面、37 处认证前就执行代码或记录状态的位置、61 组静默削弱认证前控制的配置组合。\n\n另有两个个案更能说明问题。一个反向 DNS 的 fail-open 模式在四个互不相关的项目里各自独立出现：管理员用主机名而非 IP 写访问规则，而反向 DNS 查询默认关闭，服务器只拿到 IP，主机名模式永远匹配不上 IP，于是拒绝规则永不触发。另一个是证书校验冲突，一个本意是「延迟校验」的选项实际把校验整个关掉，只接受可信客户端的服务器会接受任何人，而这组冲突的选项在软件里存在了 21 年。\n\n## OpenSSH：审计最狠的代码也漏了\n\nAnthropic 称，按代码行占比计，25 个项目里 OpenSSH 的攻击面降幅最大。10.4 版本中，Claude 沿 sshd 的输入路径追踪到约 4500 行 ML-DSA-44（后量子签名算法）的新实验代码，未认证客户端在默认配置下就能触达。ML-DSA 默认并未启用，甚至管理员显式排除该算法，代码照样可达——守护进程先解析客户端发来的密钥类型（证书还会验证内嵌 CA 签名），之后才去查这个类型是否被允许。那 4500 行约占默认 sshd 认证前代码的 16%。\n\n10.5 把检查挪到了解析之前，Claude 又指出两处遗留：一是检查看的是客户端宣称的算法名，而解析器由密钥内部的一个类型串决定，客户端可以宣称 ssh-ed25519 通过检查、却塞进一把 ML-DSA 密钥；二是证书路径没被挡住，攻击者提供的证书会让 sshd 对任意受支持算法跑完整验签，把二进制里每个公钥验证器都暴露出去。最终的修复把检查放进解析器内部，在反序列化和验签之前先比对允许列表。Anthropic 称这修掉了默认构建下未认证客户端可达代码的约五分之一。\n\n这一点在 OpenSSH 官方 10.6 发布说明里能对上：该版本确实加入了「在密钥解析期间就拿允许列表比对密钥与 CA 的签名类型」，并注明由 Chris Rohlf 联合 Claude 与 Anthropic Research 提出并提供了大量反馈（https:\u002F\u002Fwww.openssh.com\u002Freleasenotes.html）。官方还提到，近期收到大量安全报告，其中不少来自 AI 模型或其辅助，因此会改为更频繁地发版。\n\n## 怎么落地，以及我的看法\n\n这套方法被打包成一个 Claude skill，Anthropic 说正在整合进面向开源项目的自愿扫描服务 OSS-Scanner。skill 对代码库跑三趟，每趟都开干净的上下文窗口，只从上一趟继承一小段上下文；每趟都先盘出入口点，再用动态轨迹确认每条发现。涉及默认配置的改动会被一道闸拦住——跑项目自带测试套件加一套黑盒回归套件，要求改前改后结果一致；任何会动到非默认配置的改动则留给人类决定。\n\n我的看法是，这件事的价值恰恰不在「AI 又发现了多少洞」，而在它换了一个衡量单位。493 这个数字读起来平淡，也大概率不会单独构成什么安全事故；真正被改掉的是严重度的分母。当 OpenSSH 这样被审到教科书级别的代码都能默认露出 4500 行可达的实验性解析代码，那么「未被发现的漏洞」这个一直无法量化的东西，第一次有了可操作的替代指标：不修 bug，只让够不着的代码不够着。\n\n这条路子对运维和自研服务的负责人尤其现实——你未必需要买更大的扫描器，你需要的是知道自己这套部署到底暴露了什么。文中提到的把运行时日志与配置做比对，也是同一思路的延伸：关掉没人用的解析器、遗留协议和空面板，成本极低，安全收益直接。","https:\u002F\u002Fwww.anthropic.com\u002Fresearch\u002Fattack-surface-reduction","1001cead-0639-4c04-ab47-f19d863be5f2",[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},"23544f6a-eea1-4f05-aa8d-749ca862d5d2","anthropic",{"id":19,"name":20,"slug":20,"description":14,"color":14},"dca4d0ab-7994-43a7-839e-7756fc77344a","claude",{"id":22,"name":23,"slug":23,"description":14,"color":14},"02bfdc0f-5e23-4fbb-b31a-7cc03cdba1ee","security",[25],{"id":26,"lang":27,"title":28,"summary":29,"content":30},"bfbb4159-62bb-4203-8b09-81b4a6285086","en","Claude cuts attack surface: 493 issues in 25 projects","Claude found 493 attack surface issues in 25 projects, 5M+ lines. OpenSSH 10.4 exposed 4,500 lines of ML-DSA-44 pre-auth. Fixed in 10.6.","Ask anyone who has spent a career patching security holes and they will tell you the same thing: fix one, and the ledger of what is still open does not get any shorter. Anthropic's frontier red team recently took a different approach. Rather than hunting for the next bug, it asked a different question — in this particular deployment, which pieces of code were reachable that should never have been reachable in the first place?\n\nIn a research post published on October 20 (https:\u002F\u002Fwww.anthropic.com\u002Fresearch\u002Fattack-surface-reduction), Anthropic calls this attack surface analysis and reduction, and ran it with Claude across 25 open-source projects spanning more than five million lines of code, in languages including C, C++, Java, PHP and Python. Claude built an inventory of more than 17,000 configuration options across those projects, of which 3,842 related to the configuration of a security-relevant control or feature. It ended up reporting 493 issues.\n\n## Three techniques, and none of them are bug hunting\n\nThe post draws an explicit line between finding vulnerabilities and reducing reachability: the former targets specific defects, while the latter lowers the severity of defects nobody has found yet.\n\nThe first technique looks at default configuration: code that is reachable out of the box but that no default functionality actually uses.\n\nThe second looks at configuration interaction: options that each look reasonable alone but break when combined. Claude found 162 security-sensitive combinations that were accepted with neither an error nor a warning, and with no documentation of the expected behaviour of their interaction. In 94 of those, the combination silently switched off a security control. The remaining 68 were inconsistencies inside the same mechanism — a listener or login path that stays reachable even though the configuration says it is disabled, for instance, or two settings whose precedence depends on their order in the configuration file.\n\nThe third looks at early reachability: security-sensitive, complex code that runs before an appropriate control (usually authentication), without victim interaction, or before a protocol state transition.\n\n## The most surprising cohort was the one that requires you to log in\n\nAnthropic split the 25 projects into three categories: Public (10), built to serve anyone who can reach them; Gated (11), built to serve authenticated users; and Private (4), deployed for the operator's own environment. Logically, Public codebases should have plenty of reachable-by-default code, while Gated should be the reverse. Instead it was the Gated cohort that produced the most surprising results: 93 unnecessary pre-authentication surfaces in the default configuration, 37 locations where code executed or state was recorded before authentication, and 61 configuration combinations that silently weakened a pre-authentication control.\n\nTwo individual cases make the point even more sharply. One fail-open reverse-DNS pattern turned up independently in four unrelated projects: an administrator writes an access rule using a hostname or wildcard instead of an IP address, but reverse DNS lookups are configured off by default, so the server only ever has the IP. A hostname pattern can never match an IP address, so a deny rule never fires and the list fails open. Some projects document that hostname rules depend on DNS lookups being enabled, but none state that a deny list written this way would let traffic through. The other case was a certificate-check conflict: an option intended to delay verification actually disabled it entirely, so a server configured to accept only trusted clients would accept a connection from anyone. That conflicting pair of options had been present in the software for 21 years.\n\n## OpenSSH: the most heavily audited code in the world still leaked\n\nBy percentage of total lines of code, Anthropic says OpenSSH saw the largest attack surface reduction of the 25 projects. In the 10.4 release, Claude traced the input paths of the SSH daemon and found roughly 4,500 lines of new, experimental code for ML-DSA-44 — a post-quantum signature algorithm — that an unauthenticated client could reach under the default configuration. ML-DSA is not enabled by default, and the code stayed reachable even when an administrator explicitly excluded the algorithm: the daemon parsed whichever key type the client sent (and, for certificates, verified the embedded CA signature) before checking whether that type was allowed. Those 4,500 lines amount to about 16% of OpenSSH's own pre-authentication code in a default sshd.\n\nVersion 10.5 moved the check ahead of parsing. Claude then flagged two remaining gaps. The check inspected the algorithm name the client advertised, while the parser is chosen by a type string embedded inside the key blob — so a client could advertise ssh-ed25519, pass the check, and still send an ML-DSA key. And the certificate path was not gated: given a certificate supplied by an attacker, sshd would deserialize the embedded CA public key and run a full signature verification for any supported algorithm before consulting the configuration, exposing every public-key signature verifier in the binary. The eventual fix moved the checks inside the parser itself, comparing the encoded key type and the certificate's CA signature algorithm against the configured allowlists before the corresponding deserialization or signature verification. Anthropic says this removed roughly a fifth of the code an unauthenticated client could previously reach in a default build.\n\nThat part checks out against OpenSSH's own 10.6 release notes, which record the addition of checking key and CA signature types during key parsing against allowlists such as PubkeyAcceptedAlgorithms as early as possible, noting it reduces the attack surface presented by disabled algorithms. The notes credit Chris Rohlf in collaboration with Claude and Anthropic Research with the suggestion and extensive feedback (https:\u002F\u002Fwww.openssh.com\u002Freleasenotes.html). The same notes mention that the team has recently received a large number of security reports, many of them findings from AI models or made with AI assistance, and will therefore be releasing more frequently.\n\n## How to use it, and what I make of it\n\nAnthropic packaged the techniques into a reusable Claude skill that it says it is working to integrate into OSS-Scanner, its opt-in vulnerability-finding service for open-source projects. The skill runs three passes over a codebase, each starting fresh in an empty context window except for a short piece of context inherited from the prior pass. Each pass builds an inventory of entry points and confirms every finding with a dynamic trace of the program. Changes to default configuration are gated: the skill runs the project's own test suite alongside a black-box regression suite and requires identical results, while anything that would alter a non-default configuration is set aside for a human to decide.\n\nMy read is that the value here is not \"an AI found another N bugs\" but the change of unit. The number 493 sounds unremarkable, and on its own it is very unlikely to constitute any security incident. What actually changed is the denominator of severity. When code as heavily audited as OpenSSH can ship with 4,500 lines of experimental parsing code reachable by default, then the quantity security teams have never been able to measure — the unknown vulnerability — finally gets an actionable proxy: you do not need to fix the bug, you only need to make the unreachable code unreachable.\n\nThat framing is especially practical for whoever runs production infrastructure and internal services. You may not need a bigger scanner. What you need is to know what your own deployment actually exposes. The post's suggestion of comparing runtime logs against configurations is the same idea extended: shutting down unused parsers, legacy protocols and empty dashboards costs very little and buys security directly.","claude-attack-surface-reduction-openssh","2026-10-22T05:20:00Z","2026-10-22T05:09:45.089927Z","2026-10-22T05:09:45.089937Z",true,"agent",27,[39,48],{"slug":40,"tag_slug":40,"title_zh":41,"title_en":42,"intro_zh":43,"intro_en":44,"id":45,"is_active":35,"created_at":46,"modified_at":47},"ai-for-science","AI for Science 2026：从 UniPert 到 GPT-Rosalind 的硬核进化","AI for Science 2026: from UniPert to GPT-Rosalind","生命科学、化学材料、物理世界模型——AI 正在从\"语言工具\"变成\"实验伙伴\"。本专题收录 AI 在三大科学方向的关键节点：UniPert 统一基因与化学扰动空间、GPT-Rosalind 端到端生命科学推理、达摩院 AI 智能体 28 小时找到 4 种超导新材料、Anthropic Claude Science 把工作台做成标准品。","From language tool to lab partner — AI is reshaping life sciences, chemistry\u002Fmaterials, and physical world models. This topic covers the key milestones: UniPert unifying genetic-chemical perturbation spaces, GPT-Rosalind's end-to-end life-sciences reasoning, DAMO's AI agent discovering 4 superconducting materials in 28 hours, and Anthropic's Claude Science workbench going mainstream.","988a4300-5fab-41c4-b5d8-63711a2dc757","2026-09-10T01:34:15.296649Z","2026-09-10T01:34:15.296663Z",{"slug":49,"tag_slug":49,"title_zh":50,"title_en":51,"intro_zh":52,"intro_en":53,"id":54,"is_active":35,"created_at":55,"modified_at":56},"h3-series","MiniMax H3 系列：从开源权重到 35 倍吞吐","MiniMax H3 Series: from open weights to 35x throughput","MiniMax H3 自 2026 年 8 月开源以来节奏密集：官方把生成、参考与编辑收回一个模型；ComfyUI 当天压进 RTX 3060；摩尔线程 3 小时完成国产 GPU 适配；fal 后训练版把吞吐拉到 35 倍；FastH3 蒸馏再砍推理成本。本专题持续追踪 H3 的发布—开源—蒸馏—部署全链路。","Since MiniMax open-sourced H3 in August 2026 the pace has been relentless: one unified omni-modal model, same-day ComfyUI support down to an RTX 3060, a 3-hour Day-0 port to Moore Threads GPUs, fal's post-trained H3 Max at 35x throughput, and FastH3 distillation cutting inference cost further. This topic tracks the full H3 chain — release, open weights, distillation, deployment.","83ef0daa-3c31-4cb3-86ed-e5ee58654d5f","2026-09-08T07:33:19.942193Z","2026-09-08T07:33:19.942209Z",{"items":58},[59,64,69,74,79,84],{"id":60,"title":61,"news_slug":62,"published_at":63},"ac04da32-378f-403c-83c9-4cf2e29948e3","Claude半小时破解NSA曲线种子25年悬案","claude-nist-curve-seeds-lrand48","2026-10-17T19:20:00+00:00",{"id":65,"title":66,"news_slug":67,"published_at":68},"2c1d70a6-02aa-4b17-9413-a8663216baf6","Anthropic 网络验证改三层:Glasswing 并入","anthropic-glasswing-cyber-verification-tiers","2026-10-15T09:10:00+00:00",{"id":70,"title":71,"news_slug":72,"published_at":73},"acddc7d5-c389-4e90-8a7a-1001ce693395","Anthropic 反蒸馏到第三层:误拦也要收费,合法用户背成本","anthropic-distillation-shields-claude-paywall-blocks","2026-10-14T03:00:00+00:00",{"id":75,"title":76,"news_slug":77,"published_at":78},"25d2394f-b179-48f2-96c4-14e53738a95f","Claude Code 当了一回取证工程师:一次韩国银行攻击把攻击者简历都写出来了","claude-code-forensic-korean-bank-breach","2026-10-10T11:00:00+00:00",{"id":80,"title":81,"news_slug":82,"published_at":83},"6e2537e2-8be4-4d2f-860c-127a22c60e12","Anthropic 把 Claude 拉进基建与开源安全","anthropic-cyber-mission-oss-scanner","2026-10-08T09:00:00+00:00",{"id":85,"title":86,"news_slug":87,"published_at":88},"ed0e355a-bda4-40ba-bde7-7da9a6321dd9","Claude 聊天被转交警方:Anthropic 第三案","anthropic-claude-threat-referral-third","2026-10-07T11:15:00+00:00"]