基萌（Jimeng）的基萌iOS端App在去年11月的一次更新后，悄悄把用户生成图片的安全本地缓存路径从沙盒容器改到了共享的/Library/Caches目录下。这个改动没有写进更新日志，漏洞也没人注意到。基萌直到今年3月，安全一位叫“猫饼”的漏洞用户在论坛发帖说，自己用基萌生成的基萌几张私人头像，居然在另一台没登录过她账号的安全iPad上通过文件App直接看到了。

问题出在基萌对iOS数据保护API的漏洞调用方式上。正常情况下，基萌App应该用NSFileProtectionComplete级别保护用户数据，安全这样设备锁屏后文件就不可读。漏洞但基萌为了提升图片加载速度，基萌把缓存目录设成了NSFileProtectionNone。安全任何拿到设备的漏洞人，哪怕没解锁，都能通过连接电脑或利用某些文件管理器漏洞读取这些图片。

更麻烦的是，基萌的分享功能会生成一个带token的公开链接，有效期标称24小时。但测试发现，token的校验逻辑写反了——过期后不是拒绝访问，而是返回一个包含原图URL的JSON错误信息。这意味着只要有人保存了分享链接，哪怕过了半年，依然能通过修改请求头拿到原图。我在2月14日提交了这个漏洞，3月1日收到回复说“已记录”，到现在5月了，线上版本还是老样子。

基萌的Android端也没好到哪去。它的本地数据库用了SQLCipher加密，但密钥硬编码在BuildConfig里。反编译APK就能看到类似DB_KEY = "jimeng_2023_fixed"的字符串。任何拿到APK的人，都能解密用户的生成记录、提示词历史，甚至绑定的手机号。我试过用jadx打开最新版，密钥还是没变。

官方Discord群里有人问过安全更新的事。客服的回复是“我们更关注生成质量和模型迭代”。这话听着耳熟——很多AI工具团队都这么想。但基萌的用户里有不少人用它做商业设计稿、未公开的角色设定，甚至身份证翻拍件的背景替换。这些内容一旦泄露，不是“换个密码”能解决的。

有个做独立游戏的朋友，用基萌生成了整套角色立绘。他习惯把提示词写在备注里，包括项目代号和上线时间。上个月他发现这些备注出现在某个爬虫训练数据集里。他没证据说是基萌泄露的，但时间线对得上——他只在基萌里存过这些内容。

基萌的隐私政策第4.2条写着“我们采用行业标准加密技术保护您的数据”。行业标准没错，但实现方式偷懒了。iOS的NSFileProtectionNone、Android的硬编码密钥、分享token的逻辑错误——这三个漏洞任何一个单独出现都不致命，凑在一起就是完整的攻击链：先通过分享链接拿到图片URL，再用设备文件访问权限读缓存，最后用硬编码密钥解密本地数据库。

修复方案不复杂。iOS改回NSFileProtectionCompleteUntilFirstUserAuthentication，Android把密钥移到Keychain或Keystore，分享token加个签名校验。工作量大概两天。但基萌的迭代节奏是两周一个模型版本，安全更新排不上号。

写这些不是要唱衰基萌。它的中文理解确实比同类产品好，生成速度也快。但安全漏洞就像厨房里的蟑螂——你看到一只的时候，角落里已经有一窝了。用户能做的有限：别在基萌里存敏感信息，生成完就删，分享链接用完立刻失效。至于官方什么时候修，只能等下一次“重大更新”的公告里，看有没有夹带一句“优化了数据安全”。