搜索到
9
篇与
的结果
-
AutoCVE-一周30个CVE：这个Agent把CVE挖掘全流程自动化了 依靠手工去寻找CVE到底会有多么的困难？很多曾经有过相关经历去做过这件事的人内心之中都是非常清楚的很。筛选项目，寻觅开源仓库，对环境进行配置来运行SAST，手动去过滤很多误报情况，从Sink往回追溯SouRCE来分析数据流，撰写PoC来进行验证，整理英文方面的报告……这样一套流程走下来，短的时候是几天长的时候是几周，大部分的时间都花费在重复的劳动上面，留给思考的时间没有多少。最近我瞧见有一个刚刚发布出来的开源项目叫做 AutoCVE。该项目的作者，把CVE挖掘的那一系列的流程都交托给Agent去自动化地进行操作。这流程包含了选项目、导仓库、审代码、验漏洞、写报告这类步骤。这并非是 PPT 形式的项目。官方进行的测试是一周时间，并且是全自动运行的，获取到了 30 个 CVE 编号，还涉及 14 个开源项目。最高的 CVSS 评分达到了 9.9 ，整个过程可是完全没有人工干预的。在发布两周之后，GitHub 上的星数就突破了 1000 。它到底做了什么？AutoCVE并非是那种将代码随便扔给大模型进行胡乱聊天的套壳类型的项目。它是专门为CVE挖掘场景所设计的 Multi-Agent 审计平台。它具备完整的产品界面、工作流编排、沙箱隔离、工具权限控制这些东西。它进行了好多工程上面的优化，来解决LLM审计发散、不收敛、乱报漏洞这类的问题。整个流程是处于全自动化的状态。从项目的筛选起始，随后是仓库的导入，之后开展创建审计任务的操作，再之后实施Agent漏洞挖掘的行为，最终生成CVE申报报告。用户将报告的内容进行复制下来之后提交上去，便可以完成后续的CVE申请事宜。自动进行筛选项目的操作。你仅仅需要告知它需要挖掘多少个CVE，它自身就会从GitHub上面去寻找适合进行审计的开源项目。自动地将代码导入到仓库之中，接着自动地把代码拉取到本地的工作区域当中。依据项目的规模情况以及相应的配置状况去进行审计模式的选取，随后自动地开展审计任务的创建。存在着 5个专职的Agent 来开展多Agent协同审计工作，此5个Agent分别有着不一样的分工情况，并且各自去履行其自身所承担的职责。于沙箱之内运行PoC以动态验证漏洞，与此同时将误报状况予以过滤掉。自动地生成那CVE的报告，输出那种符合CVE申报格式的报告，能够进行复制粘贴然后提交。用户首先需要将模型进行配置操作完毕，随后便等待模型运行结束，紧接着把报告进行复制的动作完成，之后进行CVE的提交操作，这样就视为完成了相关的一系列流程。5个Agent怎么分工？通过Orchestrator统一调度Recon、Scan、Triage、Finding和Verification等Agent，协同完成信息收集、工具扫描、误报过滤、漏洞深挖与动态验证：整个工作流由Orchestrator统一调度，每个Agent只干自己擅长的事：Recon（侦察）：分析项目情况——什么语言、什么框架、入口文件在哪、哪些路径优先审计Scan（扫描）：调用Semgrep、Bandit这些现成SAST工具先跑一轮规则扫描Triage（分诊）：对Scan出来的结果做人工复核，把明显误报过滤掉，补充证据Finding（挖掘）：核心审计Agent，通过源码追数据流，构造攻击链，挖高价值0dayVerification（验证）：在Docker沙箱里动态运行PoC，验证漏洞是否真的能打，不靠猜AutoCVE当前支持 三种审计模式，可根据不同的审计目标选择：交互式审计与全过程追踪AutoCVE拥有着完备的交互能力。那完整的审计过程会被视作会话的上下文。用户可以围绕着审计的结果继续进行追问，让Agent去补充证据、去解释攻击链、去完善复现的步骤又或者是去扩展漏洞的分析 。可以展开查看每个工具调用的详细信息：输入$便可以显示出来并且调用相应的Skill。要是没有指定模型的话，系统会根据任务自动去匹配合适的Skill 。可视化审计追踪模块集中展示活动日志、Agent Tree、工具调用、阶段进度、初步报告和审计会话，方便复盘每次审计的执行路径与关键过程：智能化漏洞管理审计发现的漏洞由Agent调用工具自动提交，经过去重后以结构化形式入库，并在漏洞管理模块中统一维护：AutoCVE的漏洞报告会由Agent自动结构化生成，包含Summary、DetAIls、PoC、Impact、Remediation、Disclosure Notes、Affected products、CVSS、CWE、Suggested CVE description等字段，可复制用于从GitHub Advisory提交漏洞报告：还支持根据实际需求为不同Agent配置专属Skills，灵活扩展各Agent的能力边界：实际成果：一周30个CVE说再多不如看战果。官方一周测试，全自动跑下来共拿到 30个CVE，覆盖的都是真实有用户量的开源项目，不是靶场。CVE编号项目漏洞类型CVSSCVE-2026-48765typebot.io授权绕过9.9CVE-2026-43986TautulliSSRF9.9CVE-2026-43984Tautulli存储型XSS8.9CVE-2026-43985TautulliCSRF8.8CVE-2026-41235froxlor授权错误8.8CVE-2026-46372SillyTavernSSRF8.5CVE-2026-48763typebot.io权限缺失8.2CVE-2026-48764typebot.ioSSRF8.2CVE-2026-40904Chartbrew越权访问8.1CVE-2026-40600Chartbrew越权访问8.1CVE-2026-45260pimcore权限缺失8.1...还有19个SQL注入/RCE/硬编码密钥等3.7-8.1涉及的项目包含 xxl-job、JeecgBoot、o2oa、Lemmy、Chartbrew、BentoML、typebot.io、OpenReplay、SillyTavern、pimcore、froxlor、Tautulli、filebrowser、craftcms —— 14个项目，其中不少是数万Star的热门项目。部署和使用部署非常简单，一行Docker命令搞定，不需要自己搭环境：# Linux/macOS/Git Bash curl -fsSL https://raw.githubusercontent.com/larlarua/AutoCVE/v1.0.5/docker-compose.prod.yml | Docker compose -f - up -dWindows PowerShell/CMD也一样：curl.exe -fsSL https://raw.githubusercontent.com/larlarua/AutoCVE/v1.0.5/docker-compose.prod.yml | Docker compose -f - up -d启动完访问：前端界面：http://localhost:3000API文档：http://localhost:8000/docs流程实际上是挺简单的。首要的是配置你那个 LLM API Key ，它能够支持比如 OpenAI、DeepSeek 等各式各样的模型。随后可以挑选导入项目，或者开启一键 CVE 这个功能。紧接着就是等着 Agent 把流程给跑完。再之后到漏洞管理那边去查看相应的结果。最后导出报告并且提交 CVE 。一点感受AI代码审计并非是什么全新的事物。以往存在着不少类似的项目。但是大多数要么仅仅处于demo的水平，拿不上台面，要么就是弄一个空壳子来调用API，要是真的想要挖掘漏洞还是得依靠人去进行操作。AutoCVE比较难得的地方在于它是真真正正从产出CVE这个目标往回倒推来进行工程化打造的产品，并非是为了展示AI而去弄AI。多Agent分工、Triage过滤误报、Verification沙箱验证、Nudge纠偏、结构化输出这些细节方面，是实际运用LLM去审计代码的时候会碰到的坑，作者都想到了而且还给出了解决的办法。30个真实CVE的战果便是最好的证明——这玩意儿确实能挖出漏洞来。它并非是用来取代安全研究员的。恰恰相反——它将人从筛项目、跑工具、写报告这类重复劳动中解放出来，让人把精力投放到真正需要思考的复杂漏洞逻辑上去。对于很多想要去挖掘CVE但是效率比较低的人，又或者企业里很多要进行批量审计开源组件的团队而言，这个工具是值得去尝试一下的。项目地址GitHub：https://github.com/larlarua/AutoCVE项目才刚刚推出了v1.0.5版本，还在不断地快速进行更新迭代。要是你对它感兴趣的话，那就可以到上面去点一个Star、提出一个Issue相关的，或者自己把它运行起来，去尝试着找找CVE 。⚠️ 重要提醒：工具仅可用于授权安全研究，绝对禁止在未授权情况下扫描他人系统。提交漏洞时请遵循负责任披露规范。服务器推荐 -
纵深防御，雷池 + ModSecurity企业级双重 WAF 环境搭建 对于雷池的文章我还有这几篇，包括常见的https配置、雷池+frp反代，以及其他的试用方法都有https://mp.weixin.qq.com/s/3JLrkymD7d46IaWbQup4wQhttps://mp.weixin.qq.com/s/Nvkx7Qdacmm9wx6OpJbejAhttps://mp.weixin.qq.com/s/VBD12Ttwh8JS1oQLC_4gWAhttps://mp.weixin.qq.com/s/z0NU3V4RASBFoE_cG0js7A本篇文章主要讲解halo和雷池的搭建过程，以及防护流量走向，架构设计等等算上自己上班时间，这篇文章总耗时7天+，自认为是一篇非常不错的文章，建议收藏转发，共5k+字，防止后面找不到了在写这篇文章期间遇到过很多部署问题，不过已经被我小羽全部解决了通过本篇文章可以避免很多问题，帮助您搭建属于自己的防护环境，即使您没有任何WAF搭建的经历，也可以通过本篇文章来学习企业级WAF环境搭建的完整流程完整总体网络拓扑架构互联网流量 │ ▼ ┌─────────────┐ │ WAF-A │ 第一层（外层） │ (如雷池) │ └──────┬──────┘ │ 反代 ▼ ┌─────────────┐ │ WAF-B │ 第二层（内层） │ (如ModSec) │ └──────┬──────┘ │ 反代 ▼ ┌─────────────┐ │ halo │ 真实后端 └─────────────┘若读过我这篇文章的师傅们，2025最新教程，使用雷池搭建内网靶场，进行简单的WAF绕过搭配上本篇文章的教学，完全能搭建出如下架构的企业级防护环境，再牛逼点，自己再配个系统加固的防护应用为什么要采用这样的架构？不同的WAF产品拦截规则、检测的算法一般都是不同的，如果攻击者绕过了第一层WAF，那么第二层就不一定能绕过了，这才是核心价值，非常恶心的是，现实环境中还真有人这么干，层层防护，做系统加固一般这样的架构第一层WAF，用来拦截常见的攻击手法比如漏扫 / CC，第二层针对真实的业务进行定制拦截，两层分贝专注不同的威胁，如果不嫌流量太多，那你可以全开，这样做的好处就是减少日志分析的压力服务器选购
-
-
-
