# PyCharm 的代码补全会主动建议关掉 TLS 验证，这算不算安全漏洞？

> 原标题：Are insecure code completions in PyCharm a vulnerability?

- 来源：Hacker News 首页
- 发布时间：2026-06-11T01:26:03.000Z
- AX AI 日报：https://ai-daily.ax0x.ai/items/37439
- 原文：https://sethmlarson.dev/are-insecure-code-completions-a-vulnerability

## 摘要

Seth Larson 测试了 PyCharm 的“整行补全”插件，发现只要导入 urllib3，模型就会自动建议 cert_reqs='CERT_NONE' 和 disable_warnings，等于帮开发者写了一个中间人攻击的入口。他向 JetBrains 报告后，对方先说这不是直接的安全漏洞，又要求他按漏洞披露政策保密，等了 90 天没收到实质更...

## 推荐理由

作者亲自复现了 PyCharm 整行补全插件在导入 urllib3 后自动建议不安全代码的问题，并向 JetBrains 报告后遭遇 90 天拖延，证据完整、故事清晰。三条 HKR 都踩中了，但话题落在安全与工具链的交叉地带，不是纯行业大事件，所以重要性给 78、tier 给 featured 是合适的。

## 锐评

Seth Larson 的测试很直接：在 PyCharm 里写 import urllib3，整行补全插件立刻建议 cert_reqs='CERT_NONE' 和 disable_warnings，接受这段代码就等于给程序开了中间人攻击的后门。他向 JetBrains 报告后，对方先定性为“非直接安全漏洞”，转头又引用漏洞披露政策要求他保密，这种自相矛盾的处理让问题卡了 90 天没进展。最新版插件 v261.24374.152 依然给出同样的不安全建议。

Larson 的观点我基本认同：给这类问题发 CVE 确实不合适，但 IDE 厂商不能两手一摊。用户信任编辑器弹出的补全，模型却在最基础的 SSL 配置上反复踩坑，风险就转嫁给了写代码的人。正文没披露这个本地模型具体用什么数据训练，也没说明 JetBrains 内部有没有过滤不安全模式的机制，这两点恰恰是判断责任归属的关键。

对从业者来说，这条新闻提醒我们：本地补全不等于安全补全。如果团队在用 IDE 的代码生成功能，至少要对安全敏感库（如 urllib3、requests）的补全建议做一次抽查，别默认模型不会教坏习惯。