文章总结： 文章分析B站UP主11集豆包辅助SRC挖洞视频，结论为前6集实用、后5集有4集凑数。豆包擅长代码审计类漏洞识别、批量初筛端点、生成测试用例及解释漏洞原理，但不擅长业务逻辑判断、漏洞真实性验证及跨会话状态管理。建议先学手工测试再用AI加速，所有测试须在授权范围内进行。
综合评分： 85
文章分类： SRC活动,AI安全,代码审计,渗透测试,安全工具
我用豆包挖了11集SRC漏洞，说句实话：有7集是真有用，有4集是凑数的
原创
KLSEC
KLSEC
昆仑AI安全实验室
2026年9月28日 00:30
广东
在小说阅读器读本章
去阅读
在公众号小说中沉浸阅读
B站上有个UP主做了11集“豆包+SRC纯手搓AI挖漏洞”系列。我花了一整个周末看完，然后自己拿授权目标跑了一遍。
结论很直接：前6集是真能省时间的，后5集里有4集是凑数的，只有一集例外。
不吹豆包，不黑豆包。今天把11集逐个拆开，说清楚豆包在SRC挖洞里到底能干什么、不能干什么。
前6集：豆包确实能帮上忙
第1集：豆包挖SQL注入漏洞
UP主的做法是把一个登录接口的源码片段贴给豆包，问它“这段代码有没有SQL注入”。豆包给出了正确的判断：用户输入直接拼接进SQL语句，没有使用参数化查询。然后它给出了payload示例和修复建议。
我实测下来，豆包在代码审计场景下的SQL注入识别能力是靠谱的。你给它一段拼接SQL的代码，它能准确地指出注入点、构造payload、给出参数化查询的修复方案。代价是你要先把代码给它——这意味着你需要能拿到源码，或者从报错信息、JS文件里推断出后端逻辑。
第2集：豆包挖SSRF漏洞——URL预览功能
这一集的做法很实在。UP主发现了一个URL预览接口，把请求和响应贴给豆包，问“这个接口会不会存在SSRF”。豆包分析了参数结构，建议尝试内网地址。UP主接着试了http://169.254.169.254/latest/meta-data/，服务器确实去请求了。
豆包在这集里的角色不是“发现漏洞”，是“帮你想到该测什么”。很多新手看到一个URL参数，不知道还能往内网地址试。豆包知道。
第3集：豆包挖XSS漏洞
同样是代码审计场景。UP主把一段前端渲染逻辑贴给豆包，豆包指出了未过滤的用户输入直接插入DOM的位置，给出了<img src=x onerror=alert(1)>的payload。
第4集：豆包挖RCE——零基础快速RCE完整
这一集是11集里最值得看的。UP主不是让豆包直接挖RCE，而是用豆包辅助理解一个已知的RCE漏洞原理，然后自己复现。豆包的作用是“解释漏洞”，不是“发现漏洞”。
第5集：豆包挖命令注入漏洞
和SQL注入类似，代码审计场景。豆包识别出命令拼接点，给出注入payload。
第6集：豆包挖未授权访问漏洞
这一集比较特殊。UP主的做法是把一堆API端点列表贴给豆包，问“哪些接口可能没有做认证”。豆包根据路径命名和参数特征，标出了几个“疑似管理接口”。然后UP主逐个手工测试，确认了其中一个确实未授权。
这一集的价值在于批量初筛。你手上有100个端点，豆包帮你标出最可疑的10个，你只需要测那10个。
后5集：4集在凑数，1集例外
第7集：豆包挖文件上传漏洞
UP主让豆包“分析文件上传接口的安全性”。豆包给了一堆通用建议：检查MIME类型、检查扩展名、检查文件内容。这些都是教科书内容，没有针对性的发现。这一集的实际操作是UP主自己手工测出来的，豆包只是事后“解释了一下为什么这个漏洞存在”。
第8集：豆包挖业务逻辑漏洞——零元购
这一集我重点看了。豆包在这个场景里几乎帮不上忙。
UP主的做法是把订单创建和支付的请求/响应贴给豆包，问“这里有没有业务逻辑问题”。豆包的回答是：“可能存在金额篡改风险，建议测试修改金额参数。”这是正确的通用建议，但没有任何实际价值——任何一个有基本安全意识的人都知道要测金额篡改。
真正的零元购漏洞，需要理解这个平台优惠券的叠加规则、积分抵扣的上限逻辑、以及订单状态机的流转条件。豆包不知道这些业务规则。它只能看到“金额参数可以被修改”，但看不到“修改后系统会不会在支付环节二次校验”。
第9集：豆包挖越权漏洞
和零元购一样的问题。UP主把两个账号的请求贴给豆包，问“有没有越权风险”。豆包识别出了user_id参数可以修改，建议测试。但UP主手工测试发现，修改user_id后返回的是403——后端做了归属校验。豆包没有能力判断“这个接口的越权是否真的存在”，它只能看到“参数可以改”。
第10集和第11集：豆包怎么快速测试登录页面
这两集合并起来看。UP主用豆包生成弱口令字典、分析登录接口的防爆破机制、建议测试点。这部分有一定价值，因为登录页面的测试高度标准化，豆包的“通用知识”在这里派得上用场。
豆包在SRC里的真实定位
看完11集，再结合我自己用豆包跑授权目标的体验，豆包在SRC挖洞里的能力边界很清楚：
豆包擅长的：
代码审计类漏洞。 SQL注入、XSS、命令注入、路径遍历——只要你能把相关代码贴给它，它识别得很准。这是豆包最强的场景，因为它是“读代码”，不是“理解业务”。
批量初筛。 把端点列表贴给豆包，让它标出“看起来像管理接口”或“参数名包含敏感词”的。这个任务豆包的召回率很高，你只需要复核它标出来的那几个。
生成测试用例。 针对一个已知的漏洞类型，让豆包生成不同变体的payload。比如测试SQL注入时，让它生成“大小写混淆、注释符混用、双写绕过”的payload列表。
解释漏洞原理。 复现一个已知CVE时，让豆包解释漏洞的触发条件、利用链、影响范围。这是学习工具，不是挖洞工具。
豆包不擅长的：
业务逻辑判断。 零元购、越权、状态机绕过——这些需要理解平台的业务规则。豆包不知道优惠券的叠加逻辑、不知道订单的状态流转条件、不知道多租户的隔离模型。它只能看到“参数可以改”，看不到“改了之后系统会不会在某个环节拦住你”。
漏洞真实性验证。 豆包说“可能存在SSRF”，你不能直接写报告。你必须手工构造请求、观察响应、确认服务器真的去请求了内网地址。豆包会被状态码骗、会被报错信息骗。
跨会话状态管理。 你在第一轮让豆包分析了JS文件，第二轮让它测漏洞时，它完全忘了第一轮的内容。你需要把中间结果写到文件里，每轮让豆包先读文件。
关于“豆包挖豆包”的题外话
这个系列视频有个有意思的地方：UP主在用豆包挖SRC的同时，字节SRC的规则里明确写了大模型相关产品的漏洞收取说明。
ByteSRC的公告说得很清楚：沙箱环境中的代码执行/命令执行本身是预期的产品功能，如果能逃逸或影响到其他用户容器，则正常评分。 非隐私数据泄露相关的AI服务风险（jailbreak、prompt leak等）暂不收取。
CN-SEC上还有一篇“豆包的xss漏洞复现(蹭热点版)”，作者通过在HTML中注入代码，利用豆包的预览和分享功能触发了XSS。这个漏洞能打，是因为它对产品造成了可验证的安全影响，不是纯粹的“模型说了不该说的话”。
这个边界很重要。你用豆包去测别人的系统，和用别人去测豆包的系统，是两回事。
给想跟着视频学的人几句实话
先学手工，再用豆包。 视频里所有“豆包挖出来的漏洞”，背后都是UP主先知道该测什么、怎么测，然后用豆包加速。如果你不知道SQL注入是什么，豆包告诉你“这里有注入”，你也不知道怎么验证。
豆包省的是“翻代码”和“写报告”的时间，不是“想漏洞”的时间。 它能帮你更快地读代码、更快地写报告，但它不能替你想“这个业务逻辑有没有问题”。
视频里的“一个月收获1w+”不是豆包的功劳。 UP主在11集里展示的漏洞，没有一个是因为豆包才发现的。豆包加速了流程，但发现漏洞的是UP主自己。
严正声明
本文所述豆包辅助SRC挖洞的方法和案例，基于B站公开视频及个人授权测试范围内的真实操作。所有测试必须在SRC平台或客户明确授权的资产范围内进行。未授权扫描、测试、攻击行为均属违法。豆包等AI工具的使用应遵守平台服务条款，不得将敏感数据上传至未经授权的第三方服务。AI是加速器，不是替代品。判断力是你的责任。
免责声明：
本文所载程序、技术方法仅面向合法合规的安全研究与教学场景，旨在提升网络安全防护能力，具有明确的技术研究属性。
任何单位或个人未经授权，将本文内容用于攻击、破坏等非法用途的，由此引发的全部法律责任、民事赔偿及连带责任，均由行为人独立承担，本站不承担任何连带责任。
本站内容均为技术交流与知识分享目的发布，若存在版权侵权或其他异议，请通过邮件联系处理，具体联系方式可点击页面上方的联系我。
本文转载自：昆仑AI安全实验室 KLSEC
KLSEC《我用豆包挖了11集SRC漏洞，说句实话：有7集是真有用，有4集是凑数的》