airgeddon 安全策略深度解读：漏洞私有上报、安全公告机制与 master 稳定版支持范围

• 网络安全
• 渗透测试

本文以仓库根目录 SECURITY.md 为主体，结合 CONTRIBUTING.md、airgeddon.sh、.github/workflows/release.yml 等源码与配置，系统梳理 airgeddon 项目（Linux 无线网络审计多用途 Bash 脚本）的安全事务处理流程。读完本文，你将掌握：如何向维护团队私有上报漏洞并准备可复现的信息清单、安全公告（Security Advisories）的运作方式，以及哪些版本分支会被纳入安全修复范围，同时理解仓库在发布与数据完整性层面与上述策略相互印证的具体实现。

1. 文档定位：airgeddon 的安全策略是什么

airgeddon 是一个面向 Linux 系统的无线网络审计多用途 Bash 脚本，涉及抓包、WPS 攻击、Evil Twin 等敏感能力，因此其安全事务处理策略直接关系到使用者的部署信任与漏洞处置效率。仓库根目录的 SECURITY.md 全文仅三个小节，但每一条都对应着仓库中可验证的工程实践：

1. 漏洞上报（Reporting a Vulnerability）——要求私有上报而非公开 Issue，并附上报渠道与信息要求；
2. 安全公告（Security Advisories）——确认后的漏洞由维护者通过 GitHub Security Advisories 协调修复与发布；
3. 受支持版本（Supported Versions）——安全修复只覆盖 master 分支上的最新稳定版，开发版、beta、测试版、旧版及被修改的版本均不在保障范围内。

下文将逐节展开，并引入仓库源码作为支撑证据。

2. 漏洞上报流程：为什么要私有上报

SECURITY.md 的第一条核心规则是：如果你认为在 airgeddon 中发现了安全漏洞，请私下（privately）上报，而不是开一个公开 Issue。

这一要求的工程理由可以结合仓库现状理解：

• 公开 Issue 会让漏洞细节在修复完成前就暴露给潜在攻击者，而 airgeddon 本身即是攻击面很大的审计工具，其漏洞（例如处理畸形输入导致的命令注入、临时文件权限问题等）一旦公开披露，风险窗口会显著拉长；
• 仓库的 Issue 模板 面向的是普通 bug 的复现与 triage 流程，与安全漏洞的"先协调、后公开"节奏并不匹配，因此安全类问题被明确引导至私有渠道。

2.1 上报渠道

SECURITY.md 要求通过 wiki 的Contact 板块中列出的任一方式联系 airgeddon 工作人员（staff）。在仓库内可以找到对应的公开联系渠道佐证：CONTRIBUTING.md 中列出了与开发团队联系的方式，包括电子邮件、Twitter（X）账号、IRC 频道以及 Discord 服务器。对于安全上报场景，优先选择私密性更好的渠道（如邮件、私信），避免在 IRC/Discord 公共频道中贴出漏洞细节。

2.2 上报信息要求：尽量详细，以便审查与复现

SECURITY.md 明确要求"请包含尽可能多的细节，以便问题能被审查和复现"。虽然安全上报不强制使用 Issue 表单，但仓库的 Bug Report 模板 所要求的字段正是维护者判断"能否复现"的核心维度，可作为安全上报信息清单的参照：

另外，由于安全修复只覆盖特定版本（见第 4 节），上报时明确指出所用版本与分支（master / Dev）能帮助维护者快速判断问题是否落在受支持范围内。

3. 安全公告机制：确认后的协调与发布路径

SECURITY.md 说明：如果漏洞被确认，维护者可能使用 GitHub Security Advisories 来协调修复并在适当时机发布信息。

"可能"（may）一词表明披露节奏由维护者权衡决定，这与常见的 Responsible Disclosure（负责任披露）实践一致：先协调修复，再择机公开。从仓库的发布自动化可以反推这条"确认 → 修复 → 发布"链路的大致形态：

• 修复会进入开发分支 Dev，经过审查与测试后合入 master——CONTRIBUTING.md 的 Git Workflow Policy 规定：禁止直接 push 到 master、禁止对 master 提交 Pull Request，所有改动先在 Dev 分支开发，最终由维护者（v1s1t0r1sh3r3 / OscarAkaElvis）独家执行 Dev → master 的合并，该合并即构成一次新 release；
• master 上的每次合并会触发 release.yml 工作流：它从 airgeddon.sh 中提取airgeddon_version（当前仓库为12.01），校验版本号格式^[0-9]+\.[0-9]{1,2}$，生成形如v12.01的 Git tag，并从 CHANGELOG.md 截取对应版本的变更说明作为 release notes 发布。

也就是说，安全修复一旦合入 master，会以"新稳定版 release"的形式落地，这与 Security Advisories 中"修复完成后发布信息"的时机能够自然衔接。

4. 受支持版本范围：为什么只有 master 最新稳定版

SECURITY.md 的第三条规则最为关键，也最容易在社区使用中被误解：

安全修复只提供给 master 分支可获得的最新稳定版。开发版（development）、beta、测试版（testing）、旧版（legacy）或任何被修改过的版本（modified）均不在覆盖范围内。

仓库源码从两个层面印证了这一政策：

4.1 分支即版本语义：master = 稳定，Dev = 开发

airgeddon.sh 中定义了默认分支变量branch="master"，脚本自身的在线更新、数据文件下载等 URL 均基于该变量拼接（例如urlscript_directlink、urlscript_pins_dbfile、urlscript_pins_dbfile_checksum），说明脚本默认行为即锚定 master 稳定版。而 CONTRIBUTING.md 则明确：正式版从 Master 分支获取，beta 测试版从名为 Dev 的开发分支获取，特定功能的临时分支也可能存在用于测试。

从源码结构可以推断：Dev 分支与临时分支上的代码处于高频迭代状态，未经过 release 工作流的版本校验与完整测试，因此不承诺安全修复是合理且可操作的边界——维护者无法为任意中间提交维护安全补丁。

4.2 "被修改的版本"同样不受保护

"Modified versions" 被明确排除，意味着基于 airgeddon 自行改动（如修改攻击逻辑、替换语言文件、打补丁）的部署，一旦出现问题不会获得官方安全支持。对使用者而言，这提示了三点：

• 部署应优先采用 master 上的最新 release 版本，并保持更新；
• 二次开发版本应自担安全维护责任；
• 审计自己使用的脚本内容，避免"半官方"的修改版混淆来源。

5. 仓库内的安全相关实现佐证：PIN 数据库完整性校验

SECURITY.md 本身不涉及具体功能实现，但仓库中存在一个与"供应链安全"主题高度呼应的机制——known_pins.db 的校验和（checksum）验证，它可以作为理解该安全策略工程背景的补充材料。

WPS 攻击依赖 known_pins.db（已知 PIN 数据库）与 pindb_checksum.txt（当前内容为76f30738dda9bd852d7d09009cc21462）配合使用。脚本在启动 WPS 相关攻击前会执行完整性检查，相关函数定义于 airgeddon.sh：

• check_pins_database_file：检查本地数据库是否存在；若存在则比对本地与远程校验和，不一致时触发重新下载；若不存在则直接尝试下载；
• get_local_pin_dbfile_checksum：用md5sum计算本地文件校验和；
• get_remote_pin_dbfile_checksum：通过curl从 master 分支拉取远程校验和文件（timeout -s SIGTERM 15限制 15 秒，并支持代理回退）；
• download_pins_database_file：校验和不一致或文件缺失时，从urlscript_pins_dbfile下载并覆盖本地文件。

多语言提示文本也围绕该流程展开，例如 language_strings.sh 中的提示 381（"尝试访问远程 PIN 数据库的校验和文件时出错"）、382（"本地与远程文件校验和匹配，你的 PIN 数据库文件已是最新"）等。

这一机制的意义在于：脚本在运行关键攻击前，会确认本地数据文件与 master 分支上的官方文件一致，从而降低"本地文件被篡改或过期"带来的误用风险。它与 SECURITY.md 中"只信任 master 最新稳定版"的立场在逻辑上是自洽的——官方维护的唯一事实源就是 master 分支。

6. 给安全研究者与使用者的操作建议

综合 SECURITY.md 与仓库证据，可整理出一份可执行的实践清单：

1. 发现疑似漏洞时：不要开公开 Issue，通过 CONTRIBUTING.md 列出的私密渠道（优先邮件）联系维护团队，描述中注明 airgeddon 版本、运行 OS、虚拟化环境、无线网卡芯片组以及最小复现步骤；
2. 等待协调期：维护者确认后可能通过 GitHub Security Advisories 协调修复；在此窗口内请勿对外披露细节，以免放大风险；
3. 使用与升级：只使用 master 分支的最新稳定 release（当前仓库版本号为12.01），避免在生产环境长期停留在旧版或使用 Dev / 临时分支版本；
4. 检查数据完整性：运行涉及 WPS 的功能前，留意脚本输出的 PIN 数据库校验和比对提示（参见 language_strings.sh），确认本地known_pins.db与官方文件一致；
5. 自维护的边界：如果你对脚本做过二次修改，请明确该版本已脱离官方安全支持范围，自行承担漏洞修复责任。

7. 小结

airgeddon 的 SECURITY.md 虽然篇幅精炼，但勾勒出了一条完整的安全事务闭环：私有上报 → 维护者审查确认 → Security Advisories 协调修复 → 合入 master 形成新稳定版 → 对外发布。仓库中的 CONTRIBUTING.md 分支策略、release.yml 自动化发布流程，以及 PIN 数据库校验和机制，分别从流程、工具与数据完整性三个层面为这一策略提供了可验证的工程支撑。理解这套策略，既能帮助安全研究者合规、高效地提交漏洞，也能帮助使用者明确自己应当部署与维护的版本边界。

• 网络安全
• 渗透测试