拿到一份漏洞报告，原创第一反应不该是漏洞看它写了什么，而是证明看它能不能被复现。不能复现的原创漏洞，跟一封匿名举报信没什么区别——你说有，漏洞我说没有，证明最后谁也没法证明。原创安全圈子里有个不成文的漏洞规矩：没有PoC（概念验证代码）的漏洞，基本等于不存在。证明这话听着粗暴，原创但管用。漏洞

我见过太多“疑似漏洞”在邮件列表里飘来飘去，证明标题写得吓人，原创正文全是漏洞推测。有人丢出一个HTTP请求截图，证明说服务器返回了异常状态码，然后断言存在注入。你让他把请求发过来跑一遍，要么环境对不上，要么参数被过滤了，要么那个“异常”根本就是正常业务逻辑。这种报告浪费的是所有人的时间。

真正的漏洞证明得满足三个硬条件。第一，你得说清楚在哪个版本、哪个配置下能触发。第二，你得给出最小化的复现步骤，别塞一堆无关操作进去。第三，你得展示实际影响——不是“理论上可以获取权限”，而是你真的拿到了权限，或者真的读到了不该读的数据。

去年有个案例让我印象很深。某开源CMS被曝存在文件上传绕过，报告者贴了一段模糊的截图，说上传.php文件时前端校验被绕过了。但后端实际上做了二次检查，文件根本没落地。后来另一个研究员跟进了这个点，他发现真正的入口不在上传接口，而在一个老旧的缩略图生成函数里，那个函数直接拼接了用户可控的路径参数。他写了个不到二十行的Python脚本，上传一个特制图片，服务端就乖乖把shell写进了web目录。这个PoC一放出来，维护者当天就发了补丁。

你看，区别就在这里。前者是“我觉得有问题”，后者是“我让你看到问题”。漏洞证明的本质不是说服别人相信你，而是让别人自己动手验证你。你的PoC越短、越干净、依赖越少，可信度就越高。那些动辄需要特定浏览器版本、特定网络环境、特定时间窗口才能触发的“漏洞”，多半是研究者自己都没搞明白触发条件。

写PoC的时候有个小技巧：假设对方是个完全不懂你项目的人。他拿到你的代码，应该能直接粘贴运行，然后看到你描述的结果。如果你需要他先装三个依赖、改五个配置、再手动调整某个变量，那你的证明力度就打了折扣。我自己的习惯是，PoC里只保留最核心的那几行，注释写清楚每一步在干什么，剩下的全部删掉。

还有一点常被忽略：漏洞证明要包含“负面测试”。也就是说，你得证明在打补丁之后，同样的PoC不再生效。否则别人没法判断你到底是发现了漏洞，还是触发了某个未文档化的功能。负面测试不需要多复杂，通常就是同一个脚本跑两遍，一遍打补丁前，一遍打补丁后，对比输出结果。

最后说个现实问题。很多厂商收到漏洞报告的第一反应是否认，这时候一份扎实的PoC就是你的底气。你不用跟他们争论“这算不算漏洞”，直接把脚本甩过去，让他们自己跑。跑出来结果一样，争论就结束了。跑出来不一样，那说明环境有差异，再排查也不迟。安全研究说到底是个实证活儿，嘴皮子功夫没用，代码跑起来才算数。