凌晨三点，系统我盯着屏幕上那张被压扁成马赛克的漏洞图片，右下角一行小字提示“图片已损坏，图片无法预览”。系统这不是漏洞我第一次遇到这种情况，但这次不一样——这张图是图片从一个政府公开数据库里下载的，文件名规规矩矩，系统大小也正常，漏洞偏偏打开就废了。图片

起初我以为是系统下载中断。重新下了三次，漏洞换了两个浏览器，图片甚至用上了命令行工具wget。系统结果一致：文件大小分毫不差，漏洞字节数都对得上，图片可就是没法解码。我拿十六进制编辑器打开看了一眼，文件头是标准的JPEG标识FF D8 FF E0，但往后翻几百个字节，本该是图像数据的地方塞满了重复的0x20——空格字符。

这就有意思了。不是传输错误，不是存储损坏，是有人故意把数据替换成了空格。而且替换得很“干净”，文件头保留，文件尾的FF D9也在，中间全给你填上空格。普通用户打开一看，报错，只会觉得“哦，文件坏了”，然后删掉重下。没人会去查十六进制。

我把这个发现发到一个技术群里。有人回了一句：“你才知道啊？这叫图片马赛克漏洞，十年前就有人玩了。”他说得轻描淡写，但我嗅到了不一样的味道。十年前玩这个的是安全研究员，现在出现在政府公开数据里，说明什么？说明这套把戏已经下沉到运维层面了。

具体怎么操作的？我花了两个晚上复现了一遍。写个脚本，读取原始图片的二进制流，保留前1024个字节——这通常包含EXIF信息和缩略图，足够让系统识别为合法图片——然后把剩余部分全部替换成0x20。最后补上文件结束标记。整个过程不到二十行Python。生成的文件在Windows资源管理器里能显示缩略图，因为缩略图藏在头部那一千字节里。但双击打开？对不起，解码器读到空格就懵了。

更隐蔽的玩法是在PNG文件里做类似操作。PNG有多个数据块，IDAT块存图像数据。攻击者可以只破坏最后一个IDAT块，前面的块正常。这样有些解码器容错性强，会显示上半部分图像，下半部分灰掉或者花屏。用户以为图片本身就这样，根本不会怀疑文件被动了手脚。

我后来查了那个政府数据库的更新日志。发现三个月前有一次“存储优化”，把大量历史图片重新压缩了一遍。压缩工具是外包团队写的，源码没公开。我托人要到一份二进制，反编译后看到一段可疑逻辑：当图片大小超过2MB时，调用一个叫“shrink_image”的函数。这个函数内部有个判断，如果图片的EXIF里没有GPS信息，就直接把图像数据区清零再填空格。

为什么要这么干？我猜是为了节省存储空间。2MB以上的图片，清零后实际占用不到10KB。数据库里几十万张图，省下来的空间相当可观。但代价是这些图全废了。外包团队可能觉得反正没人会逐张打开看，能显示缩略图就够了。他们赌的就是用户的惰性。

这不是孤例。上个月某电商平台的商品详情图也出过类似问题。用户反馈“图片加载失败”，客服标准回复是“请清理缓存”。实际上呢？后台日志显示，图片处理服务在某个版本更新后，对超过4000像素宽的图片直接返回了一个1x1像素的透明PNG，但HTTP状态码还是200。前端拿到这个透明图，拉伸后就是一片白。用户以为网络卡，反复刷新，其实服务器早就放弃治疗了。

这些漏洞的共同点是：不崩溃、不报错、不触发监控。系统认为一切正常，用户觉得是自己运气不好。真正的问题被埋在二进制层面，只有拿十六进制编辑器扒开看才能发现。而绝大多数人一辈子都不会打开那个编辑器。

我把那张政府图片的十六进制截图发到了社交媒体上。第二天收到一封邮件，发件人自称是那个外包团队的运维。他说：“你发现的只是冰山一角。我们还有更狠的——把PDF里的文字层抽掉，只留图片层。你复制粘贴出来全是乱码，但打印出来看着一模一样。”他没留名字，邮件服务器在荷兰。

我关掉邮箱，又打开那张图片。缩略图里是一座桥，横跨在河上，桥墩清晰可见。点开大图，一片空白。桥还在那里吗？数据说它不在了。但缩略图说它曾经在过。这大概就是系统漏洞最讽刺的地方：它不摧毁信息，它只是让你以为信息还在。