访问该页面时，最先出现的是检查浏览器的提示。页面说明，为了保护尼特（Nitter）免受恶意机器人侵扰，访客需要点击其中的链接才能继续浏览。只有完成这一验证步骤，浏览器才会放行，并加载原本请求的内容，让用户看到后续页面。
正文
为了保护 Nitter 免遭恶意机器人侵扰，请点击此处继续。
评论
多数人借机质疑漏洞的严重性、CVE 披露质量和背后的安全营销，少数人核对代码库和运行时后认为服务端风险被夸大、客户端才需优先修补。真正的分歧在于：Brotli 的这个 CVE 对普通服务端究竟只是又一起被热炒的 C 语言内存 bug，还是像客户端那样必须连夜处理的真实威胁。
认为服务端风险被夸大、客户端才需优先修补
- 有人检查了两百多个 GitHub 仓库，Node、Python、C# 项目都没中招，因为平台默认没有在服务端启用 Brotli 解码，必须实际调用解码器且凑齐特定条件才会被利用，类似此前的 PHP 漏洞；即便 .NET 被点名，也只是因为它绑定了 Google 的漏洞参考实现，并不等于普遍中招。结论是客户端风险更大，应打补丁，服务端不必连夜修。（认可度：少数人） > 我查了 200 多个仓库，Node、Python、C# 都没事，因为服务端根本没调用 Brotli 解码器（@ataraxia937）
对又一个 C 语言缓冲区溢出感到麻木与讽刺
- 有人用“又一个 C 代码里的缓冲区溢出”来讽刺漏洞频发，也有人感叹漏洞怎么没完没了；这类情绪把此漏洞看作大公司 C 实现里又一次司空见惯的内存 bug。（认可度：少数人） > 又一个 C 代码里的缓冲区溢出，司空见惯了（@DogeGode）
质疑漏洞严重性、CVE 披露与安全营销
- 有人怀疑这只是一起普通问题，只因为大家正关注 Web 安全才显得有新闻价值；也有人指出实际 CVE 报告没透露多少信息，所谓“重大影响范围”可能言过其实，甚至嘲讽两句话的推特都要靠 AI 来写；还有人明确反感每个内存漏洞都被起一个耸动名字并配合安全营销。（认可度：较多人） > 这到底是个严重问题，还是只因为大家现在关注 Web 安全才成了新闻？（@hatthew）
认为 Brotli 是 Google 伪标准、早避开就躲过
- 有人一直避免使用 Brotli，认为它是大公司推的伪标准；理由是 RFC 里超过一半的“标准”内容其实是不透明二进制块，并不鼓励独立实现，因此这次等于是躲过一劫。（认可度：少数人） > Brotli 就是那种让我一路避开、又躲过一枪的伪标准，RFC 里大半是不透明二进制块，根本不鼓励独立实现（@userbinator）
受影响情况因版本和运行时而异，缓解需禁用或升级
- 确认 brotli <= 1.2.0 受影响，Python 包已升到 1.2.1；有人建议两侧禁用 br 内容编码作为缓解。Rust 服务器通常安全，因为其 brotli crate 不是 C 实现的绑定；.NET 被包含是由于微软模块绑定了 Google 的参考实现。还有人提问 Deno（默认启用 Brotli）和 Flask + Gunicorn + Apache 部署是否受影响，说明必须按实际运行时判断。（认可度：较多人） > brotli 1.2.0 及以下都有问题，Python 包已经更新到 1.2.1（@rvanlaar）
有价值的补充
- Brotli 中修复该问题的提交其实早在二月就有了，说明上游修复远早于这次公开披露。（@adzm）
- 由于没有公开的修复分析，有人推测 Chromium 的某个提交才是真正的修复：它把 BROTLI_BOOL 重构成 BrotliDecoderErrorCode，让原本只返回 false 的错误路径能传回更细的错误信息以便安全继续；另一处把判断从只比较前一个索引与当前索引，改成同时要求缓存的向后距离不超过最大向后距离，这处改动可疑，可能是相关或无关的加固。（@kccqzy）