授权与合规声明本文全部操作对象均为自建隔离靶场本机容器或隔离虚拟机涉及安全测试的环节必须以取得合法授权为前提。未经授权的渗透测试违反《中华人民共和国网络安全法》与《刑法》相关条款须承担相应法律责任。本文只讲环境配置、版本对照与靶场隔离不含任何攻击步骤、利用载荷与绕过手法请勿将文中环境指向任何非自有系统。一、为什么教程推荐和stars 数都不够用1.1 两样最常用的依据回答的都不是现在挑靶场这件事初学者最常看两样东西教程里的推荐清单和仓库页面上的星星数。这两样都不算错但它们回答的都不是这个项目现在是什么状态。教程的推荐清单有一个天然缺陷它本身有写作日期但被转载、被摘录、被收进合集之后日期常常丢了。你最后看到的是一句某某靶场推荐练一下而这句判断是什么时候下的、当时仓库是什么样都已经不在句子里了。清单不会告诉你从那个时间点到今天仓库里发生了什么。stars 数的问题更隐蔽。stars 是累计量它反映的是历史上被多少人关注过与现在还有没有人在改是两件事。一个 2020 年之后就没动过的项目stars 完全可能比一个 2026 年每天都在推送的项目更多——因为前者累积的时间更长。拿 stars 去做优劣排序本质上是拿一个存量指标去做增量判断。那能不能直接看最近有没有更新可以但仍然不够。同样一句最近没怎么动过落在不同仓库上可能是 3 个月没动也可能是 6 年 8 个月没动。这两件事对学习者的意义完全不同可是它们在最近没更新这句话里长得一模一样。1.2 三个信号全部可以自己核所以本文不给推荐排名只给三个可以自己动手核的信号。它们全部落在仓库元数据上——打开仓库页面或调一次官方接口就能看到不需要任何内部消息最后一次提交是什么时候要同时拿到核验日期和最后提交日期两个日期最近一次提交改的是什么提交信息这一栏写的是文档还是代码仓库自己标注了什么状态GitHub 的archived字段和 README 里的状态徽章。三个信号各自看什么、单看它会怎么误判先摆在下面信号去哪里看本文四个样本上的值核验日 2026-09-16只单看它会误判在哪信号一最后提交时间仓库提交历史或接口返回的pushed_at2026-09-16当天2026-09-072026-06-062020-01-15很久没动没有刻度3 个月和 6 年 8 个月会被同一句话盖住信号二最近一次提交改了什么最近一次提交的提交信息readme update文档改动b496a5d代码提交3a0ff86合并 PR“最后提交很新不等于代码很新”信号三仓库自标状态仓库页的archived字段README 顶部徽章archived falseREADME 自标status-asleep-red两个来源可能给出方向不一致的信号1.3 三条边界先说在前本文不评判具体项目的好坏不给推荐或不推荐的结论。后文出现的四个仓库作用只是用来演示怎么读信号的样本样本多少与项目优劣无关。仓库元数据的核验日期是 2026-09-16本文的基准日是 2026-10-01。你读到时这些数字可能已经变了引用前应自己复检一次。凡动态数字一律带日期写。凡取自官方动态接口的数字本文都会写明截至某日官方统计为多少不写死一个不带日期的数字。本章可以带走的一句教程推荐和 stars 数描述的是过去仓库元数据描述的是现在要判断还值不值得学先得能读到现在。二、信号一最后一次提交是什么时候2.1 要写两个日期不是一个最后提交时间这个信号单独扔出来是没有用的。“2020-01-15这个日期本身什么也不说明除非你同时知道今天是什么时候”。所以这里的第一条纪律是凡写最后提交时间必须把核验日期和最后提交日期一起写。有了这两个日期读者才能自己算出差了多久也才能在几个月后回看时知道这个数字最早取自哪一天。本文统一以2026-09-16为核验日。四个样本仓库在这一天的最后一次提交如下#项目仓库全名账号类型创建时间最后提交核验日 2026-09-16 时点距核验日archived1Vulhubvulhub/vulhubOrganization组织账号2017-04-092026-09-16T13:35:41Z核验日当天当天false2DVWAdigininja/DVWA本文未核本文未核2026-09-07commitb496a5d约 9 天本文未核3Pikachuzhuifengshaonianhanlu/pikachu个人账号非组织2018-07-242026-06-06T07:41:02Zcommit5e1e8d9约 3 个月false4upload-labsc0ny1/upload-labs本文未核本文未核2020-01-15commit3a0ff86Merge PR #33约 6 年 8 个月本文未核这张表本身就是信号一的全部用法四行放在一起差距才有刻度。第 3 行和第 4 行都算不上新但一个是约 3 个月、一个是约 6 年 8 个月第 1 行则是核验日当天仍在推送。顺带说一句账号类型这一列。Vulhub 的 owner 是Organization组织账号Pikachu 的是个人账号非组织。这一列不是优劣判断它只提示一件事这两类仓库的状态标注习惯往往不同——组织账号更容易走规范的归档流程个人账号更常把状态写在 README 里。这一点会在第四章用到。2.2 取这个数字的方式以 GitHub 为例pushed_at就是最后一次推送时间。下面这段是示例写法本文未在本机实测⚠️代码待验证forrepoinvulhub/vulhub digininja/DVWA zhuifengshaonianhanlu/pikachu c0ny1/upload-labs;docurl-shttps://api.github.com/repos/${repo}\|grep-E(full_name|pushed_at|archived|stargazers_count|forks_count|open_issues_count)done⚠️ 上面只是把几个字段挑出来看的示例不要拿第三方聚合站的数据替代官方接口——第三方站点的信息滞后这是这个方向上最容易踩的一个坑。2.3 stars 和 forks 该怎么摆本文只把 stars / forks / open issues 当作核验日 2026-09-16 的时点值写出来不用它们做任何排序或优劣判断项目starsforksopen issues口径Vulhub21,2444,80654核验日 2026-09-16 时点值Pikachu4,53879927核验日 2026-09-16 时点值DVWA / upload-labs本文未核本文未核本文未核—可以写的读法是stars 反映累计关注度与维护活跃度是两件事。不可以写的是拿 stars 数去排哪个更值得学。前一句是读法后一句是结论——而结论不在三个信号能支撑的范围里。2.4 一个必须带日期的动态数字Vulhub 的官方站点有一个统计接口会实时返回环境数量和关注数。截至 2026-09-16官方统计为 330 个漏洞环境。这个数字取自官方动态接口会随时间变化。所以写法上只有一种是对的“截至某日官方统计为多少”——写死一个数字不带日期等于给读者埋一个迟早会失效的坑。读者引用前应当自己复检一次接口当前的值。本章可以带走的一句最后提交时间要成对地写——一个核验日一个提交日只给其中一个读者都算不出结论。三、信号二最近一次提交改的是什么3.1 提交信息是这次改了什么的官方记录仓库的提交历史里每一条提交都带一行提交信息。它是维护者自己写的、说明这次动了什么的一句话。信号二就是把最后一条提交的信息读出来。为什么这一栏非读不可因为“最后提交很新不等于代码很新”。一次只改 README 的提交和一次改核心代码的提交在最后提交时间这一栏上长得完全一样——都显示为很新。要把它们分开只需要多看一眼提交信息。3.2 四个样本的这一栏项目最后一次提交commit提交信息这一栏读出来的Pikachu2026-06-06T07:41:02Z5e1e8d9readme update文档改动DVWA2026-09-07b496a5d本文未逐字核提交信息提交时间在核验日前约 9 天upload-labs2020-01-153a0ff86Merge PR #33一次合并提交Vulhub2026-09-16T13:35:41Z本文未核单条 commit—核验日当天仍有推送这一栏要守住一条线只陈述提交信息本身不外推作者意图。readme update就是更新了 readme它不等于作者放弃了代码维护也不等于项目已经停更。要判断代码层最后动过是什么时候必须往回逐条看提交历史。本次核验未逐条回溯更早提交所以本文不给出代码最后改动时间这个结论。这一步的结论缺口读者如果想补得自己去翻提交列表——但请记住翻出来的也只是提交记录不是项目有没有价值的判断。如果把信号一和信号二合起来读四个样本会分成四种情形最后提交当天 有推送Vulhub两项都指向活跃最后提交约 9 天前 代码提交DVWA两项都指向在维护最后提交约 3 个月前 文档改动Pikachu时间看着不算旧但改的那一层是文档最后提交约 6 年 8 个月前 合并 PRupload-labs时间这一项已经把距离拉得很开。注意第三种情形。它是最容易被读高的单看约 3 个月很多人会顺手归类为还在维护看完提交信息才知道最近这一次动的只是文档。这不是说项目不好而是说**最后提交时间这一项在这里被提交信息修正了一次**——两个信号合看比只看一个更接近事实。3.3 取最近一次提交的方式⚠️代码待验证curl-shttps://api.github.com/repos/zhuifengshaonianhanlu/pikachu/commits?per_page1\|grep-E(date|message|sha)|head-5这条命令读出来的三个值正好对应本节的三个字段date、sha本文表格中写作 commit 短哈希、message。注意date是提交时间不是代码最后一次改动时间——两者不是一回事这也是信号二最容易被读高的一处。本章可以带走的一句信号二不是看有没有提交而是看这次提交动了哪一层只看时间不看信息等于把一次文档改动读成了代码维护。四、信号三仓库自己标注了什么状态4.1 两个来源性质不同第三个信号是仓库自己标注的状态。这里其实有两个来源它们的性质并不一样GitHub 的archived字段这是平台层的标记。仓库被归档后平台会把它置为只读状态README 里的状态徽章这是仓库自己写在文档顶部的。它由维护者自己控制平台不会替它做判断。正因为来源不同两者完全可能指向不同的方向。这正是信号三最需要注意的地方不要默认它们一致。4.2 一个现成的不一致样本在本文的四个样本里Pikachu 就属于这种情况信号来源它看的是什么在 Pikachu 上的值核验日 2026-09-16单独读会得出什么GitHubarchived字段平台层的已归档标记false平台没有把这个仓库标为归档README 顶部状态徽章仓库自己写的状态status-asleep-red维护者自己标了一个沉睡状态两个信号指向了不同方向。README 顶部那段作者说明是逐字引用我实在是不忍心看到大家在这么老的PHP平台上进行学习以及给我发邮件问PHP的报错问题了……因此我给大家搞了一个基于javaspring主流技术框架的全新的靶场……让pikachu沉睡吧你需要 MadRabbit4.3 不一致时的处理原则两个都写出来遇到平台标记和自标状态不一致正确的处理原则只有一条把两个都写出来不做单一结论。具体到 Pikachu本文能写的只有三件事官方自标status-asleep作者在 README 中建议改用 MadRabbit最近一次提交为 2026-06-06 的文档改动。本文不能从这三条再往前推一步。原因很直接archived字段是false官方也没有发布过任何正式的停用声明。上面三条是事实这个项目已经不能用了是结论而结论在这里没有依据。这条原则可以推广到任何一个仓库当你看到一个项目看起来已经没人管了正确的动作不是替它下一个判断而是把它自己标的状态、平台标的状态、以及最近一次提交的实际情况三条并列写下来让读者自己看。本章可以带走的一句archived字段和 README 徽章是两个不同来源的信号不一致时不是二选一而是两个都摆出来。五、项目类型不同读法也不同5.1 先确认你读的是不是同一类东西用同一套三个信号去读不同的项目有一个前提要先确认你读的是同一类东西吗以 Vulhub 为例官方对自己的定位是逐字Vulhub 是一个开源的、即开即用的漏洞靶场环境集合。无需 Docker 基础只需一条命令即可快速启动用于安全研究、学习或演示的漏洞环境。关键词是集合英文版用的是collection。它不是一个靶场而是一批环境的集合。官方 README 还写明「每个环境目录下都包含详细的 README请参阅以了解复现步骤和使用说明。」对照 Pikachu 的官方定位逐字Pikachu是一个带有漏洞的Web应用系统在这里包含了常见的web安全漏洞。 如果你是一个Web渗透测试学习人员且正发愁没有合适的靶场进行练习那么Pikachu可能正合你意。它是一个 Web 应用系统——单一应用按漏洞类型分模块。DVWA 和 upload-labs 也属于这一类。5.2 两类项目的对照维度集合型以 Vulhub 为例单一应用型以 Pikachu / DVWA / upload-labs 为例官方自我定位「开源的、即开即用的漏洞靶场环境集合」Pikachu「一个带有漏洞的Web应用系统」组织方式一个目录 一个独立环境官方示例目录为vulhub/langflow/CVE-2025-3248可见按软件名 / CVE 编号组织一个应用内部按漏洞类型分模块或关卡文档位置「每个环境目录下都包含详细的 README」仓库根级 README本文是否核到统一版本要求否——官方 README 层面不存在统一的 PHP / 中间件版本要求Pikachu 官方未给版本号upload-labs 手装推荐 5.2.17读信号一时要注意仓库整体在推送不等于其中某一个环境目录也在更新仓库的活跃度基本就是这个项目本身的活跃度⚠️ 上表最后一行只是提示不是结论本文未逐一核验Vulhub 各环境目录的更新情况所以不能断言某几个环境很久没更新。要下这个判断必须逐个打开目录去看提交记录。5.3 定位句的两个用法官方定位句本身也不只是介绍它在两件事上有直接用处。第一它决定了你该期待什么。Vulhub 官方把它写成环境集合那你打开它时的预期就应该是一批各自独立、各自带 README 的环境而不是一套有通关顺序的关卡。Pikachu 写成一个 Web 应用系统预期才是一个应用里的若干模块。预期错位会让后面所有判断都跑偏。第二定位句里常常直接写着使用边界。顺带一提Vulhub 官方在 README 的注意事项里写明「所有环境仅供测试与学习严禁用于生产环境」——这是官方自己的定位说明也正好是本文开头那份授权声明的一个现成注脚。完整版靶场状态核对表本文用到的四个仓库其核验日字段最后提交、提交信息、archived、stars/forks/open issues我整理成了一张可以直接照着填的空表见本章与第七章的两张表。放在资料包里扫码即可获取本章可以带走的一句先用官方定位句确认这是一个集合还是一个应用再谈三个信号——类型不同同一个信号的含义也不一样。六、三个信号之外还要看什么6.1 文档和仓库可能对不上三个信号读的都是仓库但初学者实际上手时看的多半是文档。这两者有时候对不上而对不上的地方恰恰是最容易被带到沟里去的。6.2 几个文档与仓库不同步的实例项目文档侧写着的仓库侧的一手事实核对时要留意什么upload-labsREADME 正文写「目前一共20关」目录为 Pass-01 … Pass-21共21个首页显示数在 2020-01-15 提交49dcc6ca中由 20 改为 21文档没同步、仓库已改——两个都写出来upload-labs手装环境要求写「PHP版本推荐 5.2.17其他版本可能会导致部分Pass无法突破」官方docker/Dockerfile的基础镜像为php:5.5-apache容器内另装 gd、exif 扩展这是手装推荐与容器实际两个事实不是谁写错了sqli-labs官方 README未声明总关数只逐条列出覆盖类型并注明「Challenge Section added:Less-54 to Less-61」本文未核其目录数流传的共多少关没有官方出处不写PikachuREADME 徽章标version-1.0最近一次提交为 2026-06-06 的readme update徽章是维护者手写的与提交记录是两套东西别拿来互相推这四条有一个共同的处理方式当文档和仓库给出两个不同的事实把不一致本身写出来而不是挑一个顺手的使用。第四章讲的是两个信号不一致时都写出来这一节讲的是文档和仓库不一致时都写出来——是同一条原则用在两处。6.3 一个可以自己做的对照动作⚠️代码待验证curl-shttps://raw.githubusercontent.com/c0ny1/upload-labs/master/README.md|grep-n关curl-shttps://api.github.com/repos/c0ny1/upload-labs/contents/\|grep-oname: Pass-[0-9]*|wc-l第一行取的是文档侧的数字第二行取的是仓库侧的数字。对上了说明文档与仓库同步对不上就是上面那张表里的那种情况。注意这段只是示例写法本文未在本机实测另外接口返回的内容与仓库当前状态都可能随时间变化用之前请先确认核验日期。本章可以带走的一句文档是别人写给你看的仓库是事实本身两者对不上时两个都记下来。七、总结把三个信号压成一张自查表7.1 三个信号分别解决什么回到开头那个问题——“这个靶场项目还值不值得学”。三个信号不直接回答它但它们把这个大问题拆成了三个可以自己动手核的小问题最后一次提交是什么时候拿到核验日 提交日你才有差了多久这个刻度最近一次提交改的是什么看提交信息分清文档改动和代码改动仓库自己标注了什么状态archived字段 README 徽章两者不一致就都写出来。三个信号之外本文还补了两条先确认项目类型集合型还是单一应用型再确认文档与仓库是否对得上。这两条不改变信号本身但会改变你读信号时的预期。7.2 三个信号自查表步骤你要拿到的从哪里拿记下来时注意1核验日期 最后提交日期仓库提交历史或接口的pushed_at两个日期一起记只记一个没法判断2最后一次提交的提交信息最近一次提交写清是文档改动还是代码提交不外推作者意图3archived字段 README 自标状态仓库页 README 顶部不一致时两个都写不做单一结论4项目类型集合型 / 单一应用型官方 README 的定位句类型不同同一个信号的含义不同5文档数字与仓库事实README 正文 vs 目录 / 提交记录对不上就把两个都写下来6所有动态数字的日期官方统计接口等一律写成截至某日引用前复检7.3 一个把它跑成一行输出的写法⚠️代码待验证forrepoinvulhub/vulhub digininja/DVWA zhuifengshaonianhanlu/pikachu c0ny1/upload-labs;doprintf%s | $repocurl-shttps://api.github.com/repos/${repo}\|grep-E(pushed_at|archived)|tr-d \nprintf\ndone这段输出的每一行就是信号一 信号三的最小组合。本文未实测接口字段含义以 GitHub 官方文档为准且取到的每个值都应连同核验日期一起记录。7.4 最后一句本文没有给任何项目下值不值得学的结论因为那是读者自己该做的判断。本文只给了三个能在几分钟内自己核完的信号以及一条贯穿全文的原则两个来源给出不同的事实就把两个都写出来。靶场状态自查表上面那张三个信号自查表我另做了一份带空格、可以逐行填的版本直接拿去核任何一个仓库都可以。放在资料包里扫码即可获取附表 A本文引用事实与官方出处对照表#事实照口径一手出处核验日期本文位置1Vulhub 仓库vulhub/vulhubowner 为Organization组织账号官方描述「Pre-Built Vulnerable Environments Based on Docker-Compose」创建于 2017-04-09最近 push 2026-09-16T13:35:41Zarchived falsestars 21,244 / forks 4,806 / open issues 54https://api.github.com/repos/vulhub/vulhub2026-09-16第二章表、第二章 2.3 表2Vulhub 官方统计接口返回{environments:330,stars:21244,forks:4806}→截至 2026-09-16 官方统计 330 个漏洞环境动态数字引用前须复检https://vulhub.org/api/statistic2026-09-16第二章 2.43Vulhub 许可MIT同上README「License」 接口licenseMIT2026-09-16第二章表4逐字Vulhub 定位「Vulhub 是一个开源的、即开即用的漏洞靶场环境集合。无需 Docker 基础只需一条命令即可快速启动用于安全研究、学习或演示的漏洞环境。」英文版用collectionhttps://raw.githubusercontent.com/vulhub/vulhub/master/README.zh-cn.md2026-09-16第五章 5.1、5.25逐字Vulhub「每个环境目录下都包含详细的 README请参阅以了解复现步骤和使用说明。」同上2026-09-16第五章 5.1、5.26逐字Vulhub 注意事项「所有环境仅供测试与学习严禁用于生产环境」同上2026-09-16第五章 5.37Pikachu 仓库zhuifengshaonianhanlu/pikachu个人账号非组织创建 2018-07-24archived false主语言 PHP许可Apache License 2.0stars 4,538 / forks 799 / open issues 27https://api.github.com/repos/zhuifengshaonianhanlu/pikachu2026-09-16第二章表、第二章 2.3 表8Pikachu最近一次提交 2026-06-06T07:41:02Zcommit5e1e8d9提交信息「readme update」仅文档改动本次未逐条回溯更早提交https://api.github.com/repos/zhuifengshaonianhanlu/pikachu/commits?per_page12026-09-16第二、三、六章9Pikachu README 顶部徽章为status-asleep-red正文顶部有作者FBI WARNING逐字见第四章作者建议改用MadRabbithttps://raw.githubusercontent.com/zhuifengshaonianhanlu/pikachu/master/README.md2026-09-16第四章 4.2、4.310逐字Pikachu 定位「Pikachu是一个带有漏洞的Web应用系统在这里包含了常见的web安全漏洞。 如果你是一个Web渗透测试学习人员且正发愁没有合适的靶场进行练习那么Pikachu可能正合你意。」仓库描述「一个好玩的Web安全-漏洞测试平台」同上2026-09-16第五章 5.1、5.211Pikachu 官方版本号徽章version-1.0同上2026-09-16第六章 6.212DVWA 官方仓库为digininja/DVWA非 ethicalhack3r/DVWA后者是历史初始账号最近提交 2026-09-07commitb496a5dhttps://github.com/digininja/DVWA2026-09-16第二、三章表13upload-labsc0ny1/upload-labs最后提交 2020-01-15commit3a0ff86Merge PR #33此后处于停更状态核验日距最后提交约 6 年 8 个月https://github.com/c0ny1/upload-labs2026-09-16第二、三章表14upload-labs实际为 21 关目录 Pass-01…Pass-21官方 README 正文仍写「目前一共 20 关」首页显示数在2020-01-15 提交49dcc6ca中由 20 改为 21仓库目录树 README commit49dcc6ca— https://github.com/c0ny1/upload-labs2026-09-16第六章 6.215逐字upload-labs 环境要求「PHP版本 |推荐 5.2.17|其他版本可能会导致部分Pass无法突破」https://raw.githubusercontent.com/c0ny1/upload-labs/master/README.md2026-09-16第五章表、第六章 6.216upload-labs 官方docker/Dockerfile基础镜像 php:5.5-apache容器内另装 gd、exif 扩展与第 15 条并列写不择一https://raw.githubusercontent.com/c0ny1/upload-labs/master/docker/Dockerfile2026-09-16第六章 6.217sqli-labs 官方仓库Audi-1/sqli-labs 的 README 未声明总关数仅逐条列出覆盖类型并注明「Challenge Section added:Less-54 to Less-61」https://github.com/Audi-1/sqli-labs2026-09-16第六章 6.218未核到DVWA 与 upload-labs 的 stars / forks / open issues /archived字段值Pikachu 更早提交的逐条回溯即代码最后改动时间Vulhub 各环境目录的更新情况本文未核2026-09-16第二、三、五章本文未实测附表 B术语速查表术语一句话解释核验日本文所有仓库元数据统一取自2026-09-16这一天写任何动态数字都要带上它最后提交时间仓库里最后一次提交的时间点单独写没有意义必须和核验日成对出现pushed_atGitHub 接口里表示最后一次推送时间的字段是信号一最方便的来源提交信息每条提交自带的一行说明信号二就是读最后这一行的内容archived字段平台层的已归档标记由平台置位与 README 里的自标状态是两个来源状态徽章README 顶部由维护者自己写的一行状态标记如status-asleep-red、version-1.0环境集合collectionVulhub 官方的自我定位用词一个目录 一个独立可复现环境不是单一靶场单一应用型Pikachu / DVWA / upload-labs 这一类一个 Web 应用内部按漏洞类型分模块时点值 vs 累计量stars / forks 是累计量反映历史关注度活跃度看的是提交时间两者不是一回事两个日期原则凡写最新、最后、截至都要同时给出核验日与被描述的那一天不一致的处理两个来源给出不同事实时把两个都写出来不做单一结论——这是全文贯穿的原则写在最后这篇用到的资料写这篇时我把四个仓库的元数据在同一个核验日2026-09-16上并排核了一遍最费劲的不是取数而是决定哪些字段没核到就不写。顺手也整理了几份配套的东西靶场状态核对表最后提交、提交信息、archived、stars/forks/open issues 五个字段的空表可以直接照着核任何一个仓库Web 安全学习路线图从基础打牢到安全管理四个阶段各学什么常用靶场清单每个靶场练什么、适合哪个阶段资料是我自己整理的放在下面这个码上扫码即可获取添加时备注「靶场」优先通过。拿到之后建议先看靶场状态核对表那一份拿你正在犹豫的那个仓库当练习把三栏填一遍再决定。