凌晨两点十七分，远程监控大屏上那串十六进制地址像根刺一样扎进眼里。代码攻击载荷在内存里画了个完美的执行圆，绕过了所有WAF规则，漏洞直捣黄龙——我们的修复订单系统被人用一段curl命令捅穿了。

修复远程代码执行漏洞，远程说白了就是代码跟黑客抢时间。他们利用的执行是FastJSON反序列化那个老坑，1.2.68之前的漏洞版本都带着原罪。攻击者构造一个恶意JSON，修复服务端解析时就会执行任意命令，远程像变魔术一样。代码但魔术师靠手法，执行黑客靠的漏洞是我们代码里那些不经意的信任。

第一件事，修复封堵入口。找到所有接收外部JSON的接口，在网关层加白名单过滤。别指望正则表达式能拦得住，那些绕过手法比老太太的裹脚布还长。直接粗暴点，把`@type`字段值跟预定义类列表比对，不在名单里的统统拒绝。这招笨，但有效。

第二件事，升级依赖。把FastJSON从1.2.68直接跳到1.2.83，中间隔着十几个安全补丁。但光升级不够，还得翻代码。有个同事写的工具类里，用`JSON.parseObject`解析了前端传来的所有参数，这等于把家门钥匙挂在门口。改成`parseObject`加`Feature.SupportNonPublicField`，再把autoType彻底关掉。改完那刻，感觉像给服务器穿了件防弹衣。

真正让我后背发凉的是排查过程。翻日志时发现，攻击者三天前就试过payload，被拦了。但昨天换了个变体，绕过了我们的黑名单规则。这说明什么？说明规则永远慢半拍。所以我把修复思路从“拦截已知攻击”换成“限制未知行为”。所有外部输入都当不可信数据对待，用白名单类加载器，禁止加载不在安全列表里的类。宁可误伤业务，也不能让任意代码执行。

还有个细节容易被忽略——临时文件。攻击者上传的webshell往往藏在`/tmp`目录下。我写了段脚本，每小时扫描一次临时目录，新建的可执行文件直接隔离。虽然有点土，但确实拦住了第二波攻击。那是个PHP后门，用冰蝎加密流量通信，要不是提前埋伏了文件监控，还真发现不了。

修复完成后，我盯着服务器日志看了整整一天。没有异常请求，没有奇怪的进程，CPU占用率平稳得像心电图上的直线。但我知道，这只是暂时的平静。黑客手里可能还有别的0day，我们手里只有不断补丁的盾牌。

那晚走的时候，我在运维群里发了条消息：“所有Java服务必须启用安全管理器，JDK版本低于8u191的明天全部升级。”没人回复，但第二天早上九点，服务器列表里所有节点都变成了最新版本。团队里的人嘴上不说，心里都明白——跟黑客赛跑，输一次就全完了。

远程代码执行漏洞修复不是技术活，是态度活。你信不过自己的代码，就得信不过所有输入。把每个参数都当敌人对待，把每段JSON都当攻击载荷解析。这样虽然累，但至少能睡个安稳觉。

(责任编辑：百科)