2019年那次jQuery爆出的跨站CVE-2019-11358，让一堆老项目连夜加班。脚本问题出在$.extend()上，漏洞攻击者能通过它污染对象的修复原型链。你以为是跨站传个普通参数，结果人家把__proto__塞进去了，脚本整个应用的漏洞对象行为直接失控。这种漏洞不是修复弹个框吓唬你，而是跨站能篡改页面逻辑、偷用户数据、脚本甚至劫持会话。漏洞

修复思路其实不复杂，修复核心就一句话：别让不可信的跨站数据触碰$.extend()的深拷贝逻辑。但现实里，脚本很多项目直接引用的漏洞老版本jQuery，改动源码不现实，升级版本又怕兼容性炸了。我见过一个后台管理系统，所有表单验证都依赖jQuery 1.7的$.ajax和事件委托，升到3.x直接白屏，最后只能打补丁。

最直接的修法，升级到jQuery 3.4.0以上。官方在3.4.0里改了$.extend()的行为，不再拷贝__proto__属性。但如果你项目里用了大量插件，比如老版jQuery UI，升级后可能样式错乱、方法失效。这时候别硬扛，用第二种方案——自己封装一个安全的extend。写个函数，遍历对象时跳过__proto__、constructor、prototype这些危险键。说白了，就是手动过滤，简单粗暴但有效。

还有种情况，你压根没直接用$.extend()，但第三方库内部用了。比如某个轮播插件，把用户配置项和默认配置合并，用的就是jQuery的extend。这种隐蔽依赖最坑人。排查方法也简单，全局搜一下$.extend或者jQuery.extend，看哪些文件在调。如果数量不多，逐个改；如果泛滥了，那就直接拦截jQuery的原生方法——在加载jQuery之后，立刻覆盖$.extend，改成安全版本。

我处理过一个真实案例。一个金融后台的报表模块，用户能自定义图表颜色和标题，前端把配置存进localStorage，下次加载时用$.extend(true, { }, defaultConfig, userConfig)合并。攻击者伪造一条localStorage数据，里面带__proto__.isAdmin = true，结果用户权限判断直接被绕过，能看到别人的交易记录。当时修复就是加了个白名单校验，只允许合并预定义的几个字段，其他一律丢弃。别偷懒，别想着“用户不会这么干”，安全对抗里，攻击者永远比你想象的执着。

另外注意，别只盯着$.extend()。$.ajax()的dataType为jsonp时，如果服务器返回的响应被注入恶意代码，同样能执行XSS。虽然这不算jQuery本身的洞，但很多开发者习惯性信任返回数据，直接插入DOM。修复方法：所有从外部拿来的数据，先经过text()或者textContent赋值，别用html()。如果你非要拼接HTML，那就用$.parseHTML()，并且第二个参数传false，禁止脚本执行。

最后说个容易忽略的点。就算你把jQuery升到3.7，如果页面里还混着老插件，比如那个经典的jquery-migrate，它为了兼容老API，可能会重新引入一些不安全行为。所以升级完，测试别只点主流程，把边缘功能都过一遍。我见过有团队升级后忘删migrate，漏洞照样存在，白忙活。

修这个漏洞，本质是别让用户的输入直接变成代码。你写代码时多问一句：这个数据能信吗？不能信就过滤、转义、白名单。jQuery的洞只是冰山一角，现代前端框架的虚拟DOM、模板注入，原理都相通。别指望一劳永逸，每次依赖更新都瞄一眼变更日志，比出事再补救省心得多。