AI服务安全现状扫描揭示百万暴露风险触目惊心

继ClawdBot事件（这款自托管AI助手因日均曝出2.6个CVE高危漏洞而引发业界震动）之后，我们决定对当前AI基础设施的真实安全状况进行一次深度剖析。

软件行业过去数十年在安全交付产品方面积累的经验与规范，如今正面临前所未有的冲击。企业正竞相构建自有的大语言模型基础设施，这背后既有对AI作为核心生产力工具的迫切需求，也源于快速抢占市场先机的巨大压力。然而，这种对“速度”的极致推崇，往往是以系统性安全为代价的。

通过对证书透明度日志的分析，我们获取了超过200万台主机及100万项暴露服务的数据。最终的调查结果令人警醒——我们所扫描的AI基础设施，其脆弱性、暴露面广度以及配置混乱程度，远超以往调查过的任何传统软件系统。

默认不设防的认证机制

一个普遍且危险的模式迅速显现：大量主机直接采用了开箱即用的默认配置，完全没有启用任何身份验证。追溯根源，问题往往出在项目源代码层面——许多流行的AI项目在默认状态下，认证功能本身就是关闭的。这意味着，真实的用户数据、企业内部工具乃至商业逻辑，就这样毫无防护地暴露在公网之上，其后果轻则导致数据泄露与声誉受损，重则可能引发全面的系统入侵。

以下是几种暴露最严重、风险最高的典型场景：

门户大开的聊天机器人

我们发现了多例基于OpenUI等框架构建的聊天机器人，其完整的用户对话历史记录直接对外暴露。表面上这只是聊天记录，但在企业环境中，这些对话很可能包含大量未脱敏的敏感商业信息与内部数据。更为严重的是，部分支持多模态功能的通用聊天机器人竟然可以被任意调用。恶意攻击者完全可以尝试进行“提示词注入”或“越狱”，突破模型的安全限制——例如生成违规内容或获取不当指导——而且由于调用的是他人的计算资源，自身无需承担任何成本与风险。这并非理论推演：我们已经实际观测到有人通过企业暴露的聊天机器人接口，免费调用高性能模型，并且所有操作痕迹都不会关联到个人账户。

某些涉及大量个人隐私对话的机器人情况更为严峻。更有甚者，部分由Claude API驱动的机器人，其API密钥竟以明文形式存储在配置中并暴露出来。

无防护的AI Agent管理平台

在n8n、Flowise这类低代码自动化工作流和AI Agent管理平台中，我们也发现了大量暴露在公网的实例。许多实例被误认为仅限内网访问，却因配置错误而直接面向了互联网。其中最触目惊心的一个案例是，某个Flowise实例完整暴露了其背后大语言模型聊天机器人服务的全部业务流程与商业逻辑。虽然Flowise的界面没有向未认证访客直接展示API密钥等凭据的具体数值，但攻击者依然可以利用其集成的工具和开放的接口进行数据窃取与权限提升。

这类平台的极高风险在于，当前AI应用普遍缺乏完善的访问控制链条。一旦成功入侵某个集成了多个第三方系统的智能体（Agent），往往意味着能横向移动并掌控其关联的所有资源与权限。在另一个案例中，暴露的配置包含了网络扫描工具以及高风险的本地功能（如文件系统写入和代码解释执行），这使得在服务器端执行任意代码成为可能。

我们在政府、数字营销、金融服务等多个关键领域发现了超过90个此类暴露实例。所有聊天机器人的工作流设计、核心提示词（Prompt）以及外部API访问权限都处于门户大开的状态。攻击者可以轻易地篡改业务流程、劫持数据流量、泄露用户隐私信息或污染模型输出结果。

裸奔的Ollama API接口

最令人意外的发现，是大量Ollama模型的API接口在已加载模型的情况下，竟然完全无需任何认证即可调用。我们向5,200多台显示已连接模型的服务器发送了简单的“Hello”测试请求，其中高达31%的服务器直接返回了模型生成的响应。这些回复生动地揭示了这些API接口的实际应用场景（出于安全研究道德，我们未进行深入探查），例如：

“遵命，主人。您的命令就是我的法则。请直言您的需求，我将毫不犹豫地执行。”
“我将协助您解决健康问题，无论是焦虑、睡眠障碍还是其他困扰。”
“欢迎访问云管理系统集成AI助手，可处理运维任务、基础设施部署及服务查询。”

虽然Ollama本身不直接存储对话历史数据，但许多实例背后封装接入了Anthropic Claude、Deepseek、Moonshot、Google Gemini以及OpenAI GPT系列等需要付费的前沿大模型。在所有被扫描的服务器中，我们共发现了518个封装了此类知名商业模型的暴露实例。

原生设计缺陷与安全隐患

深入分析这些暴露案例的背后成因，普遍存在以下几类典型的安全隐患与设计缺陷：

• 草率的部署与运维实践：普遍使用不安全的默认配置、错误的Docker网络设置、硬编码的敏感凭证、以及以root等高权限身份运行应用容器。
• 全新安装即开放高权限：多个AI项目在初始安装完成后，默认会授予首个用户完整的管理员权限，且无强制修改提醒。
• 硬编码的静态默认凭证：直接将配置示例和docker-compose文件中的默认用户名密码嵌入项目源码，而非在安装时动态生成或强制要求修改。
• 新型技术栈引入的未知漏洞：仅在实验室进行短期分析，就在某个流行AI应用框架中发现了可导致远程任意代码执行的高危漏洞。

当AI智能体（Agent）具备代码解释、文件操作等高级工具调用能力时，上述配置失误所带来的危害将被指数级放大。如果底层沙箱（Sandbox）防护薄弱，且整个AI基础设施未部署在网络隔离区（DMZ），那么一次成功入侵的“爆炸半径”将急剧扩大，可能波及整个内网。

速度至上，安全失守的行业现状

眼下，部分大语言模型基础设施项目显然为了追求极致的快速交付与易用性，几乎搁置了过去数十年软件开发所积累的基础安全实践与“安全左移”原则。当然，这不仅仅是开源项目或供应商单方面的问题。整个生成式AI应用浪潮带来的巨大市场竞争与资本压力，才是根本驱动力。企业都在拼命追赶技术迭代，生怕在AI落地的竞赛中慢人一步。

最后需要强调的是，切勿坐等攻击者率先发现您那些暴露在公网上的AI应用接口。主动进行安全扫描、及时发现并修复配置错误与暴露面，才是防患于未然、保障AI系统安全的关键所在。