Milvus 会存在 SQL 注入攻击吗？别慌，它压根不用 SQL！ 最近有朋友问我：“Milvus 会不会被 SQL 注入啊？” 我一听就笑了——Milvus 根本就不吃 SQL 这一套！
你想想，SQL 注入的前提是什么？得有个能解析和执行 SQL 的引擎对吧？ 但 Milvus 压根没用 SQL 引擎，整个架构里连个 SQL 解析器都没有。所以，甭管你传的是 ' OR '1'='1 还是 DROP TABLE users--，在 Milvus 眼里都只是“看不懂的乱码”，直接报语法错误给你打回来，根本不会执行。
而且，Milvus 官方 SDK（比如 Java、Python）的设计也很讲究：你写的查询条件（比如 age > 30）并不会拼成字符串再发出去，而是被封装成 Protobuf 对象，通过 gRPC 直接传输。整个过程没有字符串拼接，自然也就没有注入的空间。
所以结论很明确：Milvus 天然免疫传统意义上的 SQL 注入。
但是！别高兴太早——它有别的坑 虽然不怕 SQL 注入，但 Milvus 并不是“绝对安全”。实际上，过去几个版本还真出过一些高危漏洞，比 SQL 注入还吓人。咱们得把注意力放在真正危险的地方：
1. 身份认证绕过（CVE-2025-64513） 在 2.4.24、2.5.21 和 2.6.5 之前的版本中，存在一个严重的身份认证绕过漏洞。 攻击者只要知道你的 Milvus 地址，就能绕过登录直接拿到集群控制权——读数据、删集合、改配置，想干啥干啥。这可比 SQL 注入狠多了！
-
远程表达式执行（REE）风险 有些老版本或者配置不当的部署里，Milvus 暴露了 /expr 这类调试接口。如果没关掉，攻击者可能通过构造恶意表达式，触发任意代码执行或造成服务崩溃（DoS）。虽然这不是 SQL 注入，但危害一点不小。
-
默认配置太“大方” 比如在 2.6.10 之前，Milvus 默认会开放指标端口（比如 TCP 9091），而且没开认证。如果你把它直接暴露在公网，等于给黑客留了个后门——人家可能通过这个端口绕过主服务的身份验证。
那怎么才能用得安心？这些加固措施必须做！ 别光看热闹，生产环境里这些事真得上心：
- 开启身份认证和权限控制 打开 milvus.yaml，把 common.security.authorizationEnabled 设为 true。 别再用默认的 root 账号跑业务！赶紧改掉默认密码。 启用 RBAC（基于角色的访问控制），给不同应用分配最小必要权限。比如只读用户就别给写权限。
- 锁死网络入口 用安全组或防火墙，只允许可信 IP 访问 Milvus 的端口（比如 19530）。 千万别把管理/调试端口（如 9091、9092）暴露到公网！这些端口本来就是给内部监控用的。
- 关掉不必要的功能 如果用不到调试接口（比如 /expr），就在配置里禁掉，或者至少加一层反向代理鉴权。 生产环境建议移除或混淆默认的请求头（比如 sourceID），减少信息泄露。
- 版本一定要跟上！ 这是最最最重要的！ 像 CVE-2025-64513 这种高危漏洞，官方已经在 2.6.5 及以上版本修复了。 所以，请务必：
定期关注 Milvus 官方 GitHub 的安全公告； 及时升级到最新稳定版，别为了“稳定”而一直用老版本——那反而更危险。 总结一下 Milvus 不会受 SQL 注入攻击——因为它压根不用 SQL。 但它有自己的一套安全风险：认证绕过、表达式执行、默认配置太松……这些才是真正的雷区。 安全不是靠“默认安全”，而是靠主动加固 + 及时更新 + 最小权限原则。 所以啊，别一听到“数据库”就只想到 SQL 注入。用 Milvus 的朋友们，把认证打开、端口锁好、版本升上去，这才是保命三件套！
希望这篇能帮到正在用 Milvus 的你。如果觉得有用，欢迎点赞收藏，也欢迎在评论区聊聊你们遇到的安全实践～
