红队视角：Gitlab已知攻击面与潜在风险

漏洞类型分类与关键案例

GitLab 历年来曝出过大量安全漏洞，涵盖远程代码执行（RCE）、提权、SSRF、XSS、任意文件读取、CI/CD 注入以及各种逻辑缺陷等。在红队视角下，这些漏洞尤其值得关注，因为它们往往能被利用实现对GitLab服务器或敏感数据的控制。下面按漏洞类型对关键历史 CVE 和研究案例进行分类梳理，并提供漏洞描述、影响版本、触发点、利用方式等细节。

远程代码执行（RCE）

远程代码执行漏洞允许攻击者在服务器上执行任意命令或代码。GitLab的RCE漏洞既有未经认证的（Pre-auth）也有需要低权限用户认证的（Post-auth）漏洞，利用手法多样，包括文件解析漏洞、导入功能注入、路径遍历写入、不安全的Markdown渲染等。以下汇总了一些重要的RCE漏洞：

CVE编号	影响版本范围	触发点/根因	认证要求	PoC公开情况
CVE-2021-22205	11.9 至 13.8.7、13.9.0-13.9.5、13.10.0-13.10.2 (Action needed by self-managed customers in response to CVE-2021-22205)	图像文件ExifTool解析（GitLab对上传的图片元数据清理时未正确验证文件） (Action needed by self-managed customers in response to CVE-2021-22205)	无需认证	有公开EXP（ExifTool RCE）
CVE-2021-22192	13.2 至 13.9.3（在13.9.4修复） (GitLab Critical Security Release: 13.9.4, 13.8.6, and 13.7.9)	Wiki页面Markdown渲染中的Kramdown选项注入（不安全的内联选项导致执行Ruby代码） (GitLab Critical Security Release: 13.9.4, 13.8.6, and 13.7.9)	需要登录（任意低权用户）	有PoC (Gitlab 13.9.3 – Remote Code Execution (Authenticated) – Ruby webapps Exploit) (GitLab-Wiki-RCE/README.md at main · CsEnox/GitLab-Wiki-RCE · GitHub)
CVE-2022-2884	11.3.4 起至 15.1.5、15.2至15.2.3、15.3至15.3.1 (GitHub – m3ssap0/gitlab_rce_cve-2022-2884: Exploits GitLab authenticated RCE vulnerability known as CVE-2022-2884.)	“从GitHub导入”API反序列化漏洞（利用Sawyer客户端覆写to_s导致Redis命令注入） (Remote Command Execution via Github import (#371884) · Issues · GitLab.org / GitLab · GitLab)	需要登录（低权项目成员）	有PoC脚本公开（GitHub Import RCE）
CVE-2022-2185	14.x 至 15.1.x （在15.1.2修复）	项目导入功能漏洞（导入归档处理不当，结合Pipeline配置可执行任意命令） (Gitlab Project Import RCE Analysis (CVE-2022-2185) )	需要登录（导入权限）	有PoC视频/分析 (Gitlab Project Import RCE Analysis (CVE-2022-2185) )
CVE-2018-18649	11.3 至 11.4.2（在11.4.3修复） (GitLab Security Release: 11.4.3, 11.3.8, and 11.2.7)	Wiki API 输入校验缺陷（具体细节未公开，报告描述为输入验证问题导致RCE） (GitLab Security Release: 11.4.3, 11.3.8, and 11.2.7)	需要登录	无公开细节		（H1报告）Path Traversal to RCE	影响 12.x (例：12.4.2)	包管理Maven API路径遍历写文件漏洞（可写入authorized_keys获得服务器SSH权限） (Path traversal, to RCE (#36029) · Issues · GitLab.org / GitLab · GitLab) (Path traversal, to RCE (#36029) · Issues · GitLab.org / GitLab · GitLab)	需要登录（任意用户Token）	PoC已公开 (Path traversal, to RCE (#36029) · Issues · GitLab.org / GitLab · GitLab)

上述列表中，CVE-2021-22205 是一起无需认证的严重漏洞：GitLab在调用ExifTool处理图片元数据时存在命令注入，导致攻击者通过特制图片即可在服务器上执行代码 (Action needed by self-managed customers in response to CVE-2021-22205)。该漏洞最初被认为需要认证，但后来提升为未认证即可利用，CVSS评分从9.9升至10.0 (GitLab Unauthenticated RCE CVE-2021-22205 Exploited in the Wild ) (GitLab Unauthenticated RCE CVE-2021-22205 Exploited in the Wild )。漏洞影响GitLab 11.9及以后所有版本，官方在13.10.3、13.9.6、13.8.8修复了此问题 (Action needed by self-managed customers in response to CVE-2021-22205)。在野利用中，攻击者常向GitLab上传恶意Exif带Payload的图片以获取反弹Shell (Action needed by self-managed customers in response to CVE-2021-22205)。

另一值得关注的是 CVE-2021-22192，这是一个经过认证的RCE，攻击者需要对任意项目wiki有推送权限即可利用。GitLab允许Wiki页面使用特定扩展名（如.rmd）并支持Kramdown扩展的内联选项。研究者发现通过构造特殊的 {::options ... /} 标记，可以注入恶意参数触发服务端执行任意Ruby代码 (GitLab-Wiki-RCE/README.md at main · CsEnox/GitLab-Wiki-RCE · GitHub)。例如，利用不安全的语法高亮选项，指定formatter或driver为某些类，再结合反引号执行命令，实现命令执行 (Gitlab 13.9.3 – Remote Code Execution (Authenticated) – Ruby webapps Exploit)。该漏洞影响13.2及以上版本，在13.9.4中作为严重漏洞修复 (GitLab Critical Security Release: 13.9.4, 13.8.6, and 13.7.9)。社区公开了Expolit脚本 (Gitlab 13.9.3 – Remote Code Execution (Authenticated) – Ruby webapps Exploit)并在漏洞报告 (GitLab Critical Security Release: 13.9.4, 13.8.6, and 13.7.9)中详细记录了该漏洞。

CVE-2022-2884 则涉及GitLab的导入GitHub仓库功能。攻击者（需登录）设置一个恶意的GitHub项目或API响应，使其中包含特殊JSON字段名。GitLab使用Sawyer库处理GitHub API响应，会根据JSON字段动态创建Ruby方法 (Remote Command Execution via Github import (#371884) · Issues · GitLab.org / GitLab · GitLab)。攻击者可以设置字段名为to_s等特殊方法，从而在后续调用中劫持其行为。GitLab导入流程会将这些对象传给Redis客户端，Redis在拼接命令时调用了被覆写的to_s和bytesize，结果导致任意Redis协议注入 (Remote Command Execution via Github import (#371884) · Issues · GitLab.org / GitLab · GitLab) (Remote Command Execution via Github import (#371884) · Issues · GitLab.org / GitLab · GitLab)。通过此手法，攻击者可以向内部Redis发送恶意指令，实现进一步攻击（如写入Rails缓存数据触发代码执行）。该漏洞影响GitLab 11.3.4起多个版本段，在15.3.1修复 (GitHub – m3ssap0/gitlab_rce_cve-2022-2884: Exploits GitLab authenticated RCE vulnerability known as CVE-2022-2884.)。研究者vakzz报告了此漏洞并给出了利用方法，使其成为链式攻击的一环 (Remote Command Execution via Github import (#371884) · Issues · GitLab.org / GitLab · GitLab)。目前已有公开的利用脚本和Exploit-DB收录。

除了上述漏洞，GitLab还出现过路径遍历结合文件写入导致RCE的案例。例如某HackerOne报告（编号#733072）披露，GitLab的Maven私有包仓库API中存在路径遍历漏洞，可将攻击者提供的文件写入服务器任意可写路径 (Path traversal, to RCE (#36029) · Issues · GitLab.org / GitLab · GitLab)。攻击者利用该漏洞上传自己的公钥到~git/.ssh/authorized_keys，随后通过SSH登录git账户获取Shell (Path traversal, to RCE (#36029) · Issues · GitLab.org / GitLab · GitLab)。这一漏洞相当严重，CVSS预计接近10，但需要攻击者拥有项目访问Token（低权限即可）。开发者nyangawa报告了此问题并称其“与另一相似漏洞相比更简单” (Path traversal, to RCE (#36029) · Issues · GitLab.org / GitLab · GitLab)，表明GitLab在文件路径校验方面曾有缺陷。这类利用链可以概括为：路径遍历写文件 -> 写入后门公钥 -> 服务器提权进入Shell。

服务端请求伪造（SSRF）

SSRF 漏洞允许攻击者诱使服务器发送请求到任意目标，包括内部网络资源。GitLab作为一个自托管的DevOps平台，内部集成了各种服务（数据库、Redis、内部API等），因此SSRF漏洞常常成为攻击者探测和利用内网的入口。例如，通过SSRF可以访问AWS/GCP元数据服务获取凭证，或者访问GitLab内部的服务端口（如Redis、Gitaly等）执行未授权操作。以下是GitLab中具有代表性的SSRF漏洞案例：

CVE编号	影响版本范围	漏洞位置/成因	影响与利用	PoC公开
CVE-2018-18646	5.3 起至 11.4.2 ( GitLab Security Release: 11.4.3, 11.3.8, and 11.2.7)	集成的HipChat通知插件（Webhook URL未过滤） (GitLab Security Release: 11.4.3, 11.3.8, and 11.2.7)	攻击者可让GitLab请求内网任意地址 (GitLab Security Release: 11.4.3, 11.3.8, and 11.2.7)	无公开PoC
CVE-2018-19571	8.18 至 11.5.0 (在11.5.1修复) (CVE-2018-19571 – Mitre)	Web钩子（Webhook）URL处理存在SSRF	攻击者可利用Webhook功能请求内部服务或公网	有PoC（与CRLF链式利用）
CVE-2022-0249	12.0 起所有版本，修复于15.x (Server-Side Request Forgery (SSRF) in gitlab )	CI Lint API 对某些网络地址缺乏过滤 (Server-Side Request Forgery (SSRF) in gitlab )	盲SSRF：可对内部保留地址发起请求	无公开细节
（H1）FogBugz Import SSRF	不详（影响旧版）	FogBugz 项目导入功能（导入URL可被篡改）	攻击者通过导入指向内网的FogBugz附件URL，实现内部服务探测	公开报告
（H1）Grafana integration SSRF	不详（示例）	第三方集成Webhook（如Grafana钉钉等URL）	攻击者利用弱过滤的URL字段，访问内网	/

GitLab 早期版本中的 SSRF 主要出现在第三方服务集成上，例如 HipChat、Jira、FogBugz 等集成功能。这些功能通常允许管理员配置一个URL用于发送通知或导入数据，但如果URL校验不严格，攻击者可以提交内网地址。上述 CVE-2018-18646 就是HipChat集成的漏洞：攻击者能通过构造恶意URL，使GitLab服务器向本地网络资源发送请求 (GitLab Security Release: 11.4.3, 11.3.8, and 11.2.7)。这可能用于访问敏感的内部HTTP接口或非HTTP服务（有报告称可探测内网开放端口）。

Webhooks也是一个SSRF重灾区。GitLab支持项目Webhooks，将事件POST到用户提供的URL。在CVE-2018-19571中，Webhooks功能存在SSRF漏洞，影响GitLab 8.18至11.5 (CVE-2018-19571 – Mitre)。虽然细节未完全公开，但NVD描述该漏洞可使未授权攻击者利用Webhook URL访问内网资源 (CVE-2018-19571 – Mitre)。研究者Algafix将此漏洞与另一个CRLF注入漏洞（CVE-2018-19585）组合，实现了RCE链条 (GitLab_File_Read_Remote_Cod…)：首先利用SSRF访问GitLab本地的Redis服务端口，然后通过CRLF注入精细构造Redis协议数据，最终向Redis写入恶意payload执行代码 (GitLab_File_Read_Remote_Cod…)。这条链充分体现了红队利用SSRF的威力：SSRF -> 内部服务（Redis）利用 -> RCE。

GitLab近年的SSRF更多地与新功能相关。例如CI/CD Lint API曾被发现可以对外部URL加载YAML配置，从而引入SSRF（CVE-2022-0249）。GitLab本应禁止访问保留IP（如169.254/localhost等），但有报告指出某些“共享地址空间”未被拦截 (Server-Side Request Forgery (SSRF) in gitlab )。因此攻击者可通过CI Lint功能让GitLab后端请求内部地址，实现盲SSRF (Server-Side Request Forgery (SSRF) in gitlab)。虽然这类请求可能看不到响应，但可通过时延或错误推测内网服务存在与否。

总的来说，SSRF在GitLab中的利用目标通常有：云元数据服务（窃取临时凭证）、内部HTTP API（如内部Admin API端点）、数据库/缓存服务（Redis、ElasticSearch）等。防御上，GitLab在不断改进URL过滤策略（例如默认禁止localhost和RFC1918 IP）。但攻击者仍会寻找绕过，如利用DNS rebinding、整形URL（十进制IP、混合协议）等技巧 (GitLab Security Release: 11.4.3, 11.3.8, and 11.2.7)。对于红队而言，任何能够提交URL的功能都是潜在的SSRF入口，应重点关注。

跨站脚本（XSS）

GitLab作为复杂的Web应用也曾爆出多起跨站脚本漏洞。其中不少是存储型XSS，攻击者利用GitLab的项目内容或配置，将恶意脚本存储在服务器，诱导其他用户访问时执行。虽然XSS通常不能直接控制服务器，但在GitLab这样的平台上，XSS可以窃取管理员Token、执行API操作，从而间接取得敏感数据甚至仓库控制权。

典型的XSS案例包括：项目描述、合并请求、工单评论、Wiki页面等富文本区域缺乏充分过滤。比如，有报告称在项目主页的存储型XSS：攻击者修改某Group的默认分支名称为恶意payload，可导致访问项目主页时执行JS (Stored XSS in main page of a project caused by arbitrary script …)。另一个案例是Merge Request讨论中的XSS (Report #977697 – Stored-XSS in merge requests – HackerOne)。

这里重点介绍一个近年的实例 CVE-2023-0050：该漏洞与GitLab的Kroki图表集成功能有关。Kroki允许在Markdown中插入架构图，GitLab会将描述发送给Kroki服务生成SVG。然而研究发现，通过构造特殊的图表数据，可以在返回的SVG中植入恶意脚本。由于GitLab对用户插入的Kroki图并未充分清理，导致低权限用户也可存储XSS (GitLab Cross-Site Scripting (XSS) Vulnerability (CVE-2023-0050) – NSFOCUS, Inc., a global network and cyber security leader, protects enterprises and carriers from advanced cyber attacks.)。根据公告，攻击者可以借此以受害者身份执行任意操作 (GitLab Cross-Site Scripting (XSS) Vulnerability (CVE-2023-0050) – NSFOCUS, Inc., a global network and cyber security leader, protects enterprises and carriers from advanced cyber attacks.)（如执行API、更改设置等）。该漏洞影响13.7以后的多个版本，在15.9.2等版本修复 (GitLab Cross-Site Scripting (XSS) Vulnerability (CVE-2023-0050) – NSFOCUS, Inc., a global network and cyber security leader, protects enterprises and carriers from advanced cyber attacks.)。这一例子表明，即便是看似安全的第三方可视化组件，仍可能引入XSS风险，需要对返回内容做严格的过滤或使用Content Security Policy。

此外，GitLab还修复过Mermaid图表的原型污染导致XSS、MathJax渲染的XSS等漏洞 (hackerone-reports/tops_by_program/TOPGITLAB.md at master · reddelexc/hackerone-reports · GitHub)。很多XSS漏洞是由前端富文本渲染引起，但能否成功利用取决于GitLab对输出的转义。红队在测试GitLab时，可重点关注Wiki、Issue、Snippet等支持渲染用户内容的地方，尝试各种Markdown、HTML绕过手段。虽然GitLab默认启用了严格的Content Security Policy，但已有攻击利用漏洞实现CSP Bypass来执行恶意脚本 (GitLab CE and EE Kroki Diagram Stored XSS Vulnerability – SonicWall)。因此，不能掉以轻心。

任意文件读取/写入

文件读写类漏洞也是GitLab历史上经常出现的问题，特别是通过路径遍历或不安全的归档提取导致。任意文件读取漏洞允许攻击者读取服务器上的敏感文件（如配置文件、密钥等），常作为进一步攻击的铺垫。任意文件写入则可能直接构成RCE（例如写入钩子脚本、写入公钥等）。

CVE-2023-2825 是最近非常关键的一个案例：它是一个未经认证的任意文件读取漏洞，CVSS评分达到10.0 (GitLab Arbitrary File Read (CVE-2023-2825) Analysis)。攻击者利用GitLab对附件下载接口的路径处理缺陷，通过构造特殊URL，对GitLab 16.0.0版本实现路径遍历，读取任意文件 (GitLab Arbitrary File Read (CVE-2023-2825) Analysis)。此漏洞要求目标项目满足“位于至少5级分组嵌套下的公共项目且存在附件” (GitLab Arbitrary File Read (CVE-2023-2825) Analysis)。研究人员分析了这一怪异条件背后的原因：GitLab在拼接附件路径时，每一层分组名都会形成路径的一部分，漏洞在于未正确规范化带有编码的路径 (GitLab Arbitrary File Read (CVE-2023-2825) Analysis)。利用..%2f（URL编码的“../”），可以突破目录限制 (GitLab Arbitrary File Read (CVE-2023-2825) Analysis)。分组嵌套层数越多，URL路径段越长，可利用的“../”次数越多 (GitLab Arbitrary File Read (CVE-2023-2825) Analysis)。实验证明，嵌套9层分组即可遍历到系统根目录并读取诸如/etc/passwd等文件 (GitLab Arbitrary File Read (CVE-2023-2825) Analysis)。WatchTowr 实验室对此漏洞进行了深入复现和分析，还给出了完整的curl POC (GitLab Arbitrary File Read (CVE-2023-2825) Analysis)。该漏洞仅影响16.0.0版本，在16.0.1紧急修复 (GitLab Arbitrary File Read (CVE-2023-2825) Analysis)。

另一个典型案例是 Bulk Import 文件处理漏洞（H1 报告“UploadsPipeline 任意文件读取”，对应CVE-2022年）。GitLab引入“组导入”功能，可将整个GitLab实例的数据导入另一个实例。攻击者如果有权限导出群组数据，可以生成一个包含恶意符号链接的uploads.tar.gz附件包。当目标实例导入这个压缩包时，GitLab后端会提取其中的文件但未移除符号链接 ([GitLab] Arbitrary file read via the bulk imports UploadsPipeline)。随后导入流程会尝试读取这些上传的文件，结果跟随符号链接读取了服务器上的任意文件 ([GitLab] Arbitrary file read via the bulk imports UploadsPipeline)。该漏洞由安全研究员vakzz提交，赏金高达$29,000 (The State of Vulnerabilities in 2022 – Bishop Fox)。影响范围是在Bulk Import功能开启的情况下，版本14.7左右。其利用链路相对复杂，但要点在于压缩包解压+符号链接。这一模式在其他软件（如Struts2文件上传）也曾出现，是典型的归档提取安全问题。

GitLab 还存在文件写入漏洞，例如前述 Path traversal RCE 案例（写authorized_keys）。还有一些导入/导出功能的漏洞允许写文件到不应有的位置。例如早期版本的GitLab项目导入曾允许附带.git目录，可能覆盖目标仓库的数据，甚至写入钩子脚本，从而在GitLab运行钩子时执行代码 (Remote Code Execution after cloning a malicious repository … – GitLab)。尽管具体CVE不详，但我们推测这是2020年前后的漏洞。

总的来说，这类漏洞往往发生在文件上传/下载相关的功能上，如附件、导入/导出、CI artifact、备份还原等。红队在审计时，可以关注以下模式：

• 路径遍历：凡是URL或接口中有文件路径参数，或根据用户输入拼接文件路径的地方，都可能存在未正确规范“..”等路径的风险 (GitLab Arbitrary File Read (CVE-2023-2825) Analysis)。
• 归档提取：导入项目、组、文件时，如果使用系统解压而未严格过滤，需测试压缩包包含../、符号链接、长路径等手法，验证是否能逃逸出目标目录 ([GitLab] Arbitrary file read via the bulk imports UploadsPipeline)。
• 文件下载：如GitLab提供原始文件/附件下载的URL，尝试在URL中注入路径遍历来读取别的文件（正如CVE-2023-2825所示）。
• 文件写入：有些API允许写文件（如文件上传、编辑Wiki附件等），测试能否通过路径遍历写到敏感位置。

权限绕过与逻辑缺陷

除了上述技术漏洞，GitLab也曝出过权限控制不当和业务逻辑缺陷，往往导致提升权限或账户接管。这类漏洞利用起来“无声无息”，但后果严重，红队应予以重视。

CVE-2022-1162 是一个惊人的逻辑漏洞：GitLab在整合 OmniAuth （OAuth/LDAP 单点登录）时，引入了硬编码密码的后门 (CVE-2022-1162 flaw in GitLab allowed threat actors to take over …)。当用户通过第三方OAuth注册账户时，GitLab意外地为该账户设置了一个静态已知的初始密码 (CVE-2022-1162 flaw in GitLab allowed threat actors to take over …)。攻击者无需知道用户的OAuth凭据，只要知道其用户名，就可以使用硬编码密码直接登录该用户账户。这相当于一个后门账户接管漏洞，影响14.7到14.9的多个版本 (CVE-2022-1162 Detail – NVD)。GitLab官方在14.9.2等版本紧急修复，并提供脚本供管理员排查受影响账户 (GitLab Critical Security Release: 14.9.2, 14.8.5, and 14.7.7)。这个案例警示我们：集成第三方认证时若处理不慎，可能无意间削弱了本地安全措施。

另一类漏洞涉及越权访问。例如近期某次更新修复了未授权用户可以访问内部项目的漏洞（CVE-2025-2242，假设场景为外部用户通过API能够读取内部可见度项目） (GitLab.com: Latest updates – Release Overview)。还有此前的一个H1报告显示，攻击者可以绕过邮箱验证机制，以未验证邮箱的账号执行本应仅限内部域用户的操作（例如访问内部实例资源） (hackerone-reports/tops_by_program/TOPGITLAB.md at master · reddelexc/hackerone-reports · GitHub)。类似地，GitLab的项目模板功能曾被滥用：本意是允许从公开模板创建项目，但有漏洞使攻击者可以指定任意私有项目作为模板，从而复制其中内容，包括私有代码仓库、机密Issue等 (hackerone-reports/tops_by_program/TOPGITLAB.md at master · reddelexc/hackerone-reports · GitHub)。这种漏洞属于逻辑绕过，通常出现在新功能或复杂权限判断场景中。

权限提升（Privilege Escalation）也是值得关注的类型。GitLab的权限模型包括 Guest/Reporter/Developer/Maintainer/Owner 等角色，不同角色在项目、组中的权限不同。历史上一些漏洞使低权限用户能够执行超出其权限的动作。例如：“通过Project Import导入仓库时，系统使用后台Worker以管理员权限处理导入文件”，如果攻击者巧妙构造导入内容，可能让后台以更高权限执行了恶意操作（这是前述 CVE-2022-2185 的思路）。再如，GraphQL 接口曾存在IDOR（不正确的对象引用控制），导致普通用户能查询本不属于自己的数据 (hackerone-reports/tops_by_program/TOPGITLAB.md at master · reddelexc/hackerone-reports · GitHub)。

逻辑漏洞往往没有现成的Exploit脚本，但红队可通过代码审计和功能测试来发现苗头。例如：

• 检查用户注册/验证流程：是否存在绕过验证、重复利用令牌等问题。
• 测试访问控制：登录低权限账号，尝试直接访问高级功能的URL或GraphQL查询，观察是否缺少权限检查。
• 关注新集成功能：第三方集成（OAuth、外部Issue导入等）往往涉及信任边界转换，容易出现疏漏。
• 多步骤流程（如项目导入、CI运行审批等）：确保每一步都正确校验权限，尤其是后台任务执行敏感操作时，是否验证提交者权限。

一个教科书式的逻辑链是：利用信息泄露或低权访问获取一些管理员Token或敏感数据，然后进一步滥用GitLab的信任机制扩大成果。例如有报告提及查看HackerOne漏洞附件的漏洞 (hackerone-reports/tops_by_program/TOPGITLAB.md at master · reddelexc/hackerone-reports · GitHub)，攻击者本无权访问但通过漏洞下载了安全报告附件，其中可能包含其他漏洞利用信息，形成“以漏洞找漏洞”的连锁反应。

综上，GitLab的逻辑和权限类漏洞提醒我们，不应只盯技术上的输入验证，还要考虑业务逻辑的一致性和权限边界是否严格。红队在模拟攻击时，可以假设自身是某一低权限角色，尝试一切可能去达成高权限行为，从异常反馈中挖掘漏洞线索。

GitLab 关键攻击面分析

GitLab 平台由众多组件和接口构成，攻击面广阔。红队在评估GitLab安全时，应从多个入口着手。下面对几个主要的攻击面进行分析，说明各自暴露的漏洞类型和典型案例：

Web界面 & 前端功能

Web界面是攻击者最直接的入口，包括GitLab提供的所有HTTP页面、表单和上传点。常见威胁有：XSS、CSRF、点击劫持等。正如前述，GitLab历史上多个存储型XSS均通过Web界面注入（如Issue评论、Wiki等）。文件上传也是Web界面的重要功能点，例如头像上传、附件上传，以往ExifTool RCE (Action needed by self-managed customers in response to CVE-2021-22205)就是通过Web上传图片触发的。红队应仔细测试上传接口（图片、LFS 文件等）对文件类型和内容的验证。另一个Web层面的风险是CSRF（跨站请求伪造）。GitLab对关键操作使用了CSRF Token，但仍需留意有没有遗漏的状态更改操作，可被CSRF利用。比如曾有报告指出GitLab某管理操作缺少CSRF保护导致风险 (hackerone-reports/tops_by_program/TOPGITLAB.md at master · reddelexc/hackerone-reports · GitHub)。

GitLab Web界面还包括GraphQL API（通过 /api/graphql 暴露）和一些嵌入式前端应用（如WebIDE、Snippets等）。GraphQL查询往往复杂，可能出现权限绕过或大数据曝露（如不经意返回敏感字段 (hackerone-reports/tops_by_program/TOPGITLAB.md at master · reddelexc/hackerone-reports · GitHub)）。前端应用如果集成第三方库（如Mermaid、Kroki）也可能引入XSS或原型污染。因此，任何在Web界面上可交互的输入点，红队都应当尝试例如：输入恶意Markdown、超大数据、边界值等，看是否触发异常行为。

API 接口（REST & GraphQL）

GitLab提供丰富的REST API（通常以 /api/v4/ 为前缀）和GraphQL API，供自动化和集成使用。这些接口经常成为攻击者的目标，因为有时开发者会忽略对API的严格权限验证或输入过滤。在历史漏洞中，很多RCE/文件读写其实都是通过API调用实现的。例如包管理API的路径遍历RCE (Path traversal, to RCE (#36029) · Issues · GitLab.org / GitLab · GitLab)、Import API的Redis注入 (Remote Command Execution via Github import (#371884) · Issues · GitLab.org / GitLab · GitLab)都属于后端API层面的漏洞。相比Web界面，API往往返回更直接的错误信息，方便攻击者调试利用。

红队应枚举GitLab的API端点，包括：项目管理、用户管理、文件仓库、CI/CD等。重点关注那些接受文件内容或URL的API参数，如项目导入（上传文件或提供URL）、文件上传、CI YAML配置（可否从URL加载）等等。这类接口经常是逻辑复杂的地方，也容易出现漏洞（正如Bulk Import的tar解压问题）。

值得一提的是未公开的或内部API。GitLab内部组件（如Workhorse、GitLab Shell、Gitaly）之间有专门的API通信。例如Workhorse会调用Rails的内部接口完成上传、文件发送等。如果攻击者能够通过特殊手段直接访问内部API（例如伪造请求到内部Unix套接字或端口），可能绕过某些检查。以前的一个漏洞展示了Workhorse 绕过：攻击者构造特殊的Multipart请求，让Workhorse绕过Rails的路径检查，从而读取本地文件 (hackerone-reports/tops_by_program/TOPGITLAB.md at master · reddelexc/hackerone-reports · GitHub)。因此，分析GitLab源码时，要留意有哪些内部API没有暴露在文档中，但可能被攻击者利用SSRF或本地提权手段触及。

OAuth / 单点登录 (SSO) 集成

GitLab支持各种单点登录（SSO）和第三方OAuth，如LDAP、SAML、GitHub OAuth登录等。这些集成提高了企业使用的便利，但同时引入新的攻击面。前述CVE-2022-1162 硬编码密码就是OAuth集成不当的结果 (CVE-2022-1162 flaw in GitLab allowed threat actors to take over …)。另外，如果GitLab对OAuth登录返回的数据（比如用户邮箱、令牌）处理不严，可能被伪造。比如有研究者通过伪造OAuth身份，绕过了GitLab的邮箱域名限制，注册到本应封闭的实例中 (hackerone-reports/tops_by_program/TOPGITLAB.md at master · reddelexc/hackerone-reports · GitHub)。

对于LDAP集成，如果配置不当，可能出现LDAP注入或权限同步错误导致的未授权访问。例如攻击者构造特殊LDAP用户数据也许可骗过GitLab的权限检查。虽然目前未见这方面公开漏洞，但红队可在有条件时测试这些边缘情况。

另一个角度，攻击者可能并不直接攻破GitLab，而是攻破其依赖的OAuth提供商账户，然后利用单点登录进入GitLab。因此，在供应链角度也要考虑OAuth配置的安全，如回调URL是否唯一绑定、防止OAuth客户端凭证泄漏等。

Git 仓库操作面

作为Git平台，GitLab对Git仓库的管理是核心功能。然而Git协议以及仓库内容也可能成为攻击载体。典型的例如Git Submodule RCE攻击：Git本身在克隆含恶意.gitmodules的仓库时可能执行命令（CVE-2018-11235），GitLab在服务端对submodule URL进行了过滤防护 (CVE-2018-11235: Git Submodule RCE Exercise! – Pentesterlab)。但仍有可能遗漏。如果GitLab某些导入、镜像功能允许携带特制仓库（如在仓库文件中嵌入钩子、配置等），就有风险。

以项目导入为例，GitLab允许用户导入整个项目的备份，其中包含仓库数据。之前提到的 CVE-2022-2185 项目导入RCE利用了导入机制的漏洞：通过精心构造仓库备份和配置，使导入过程执行了恶意代码 (Gitlab Project Import RCE Analysis (CVE-2022-2185) )。从STAR Labs的分析可以看出，攻击者需要了解GitLab导入流程的两个分支（Case1, Case2），通过巧妙组合让导入的仓库数据在后台被当作Rails代码执行 (Gitlab Project Import RCE Analysis (CVE-2022-2185) )。这属于非常高级的攻击了。

GitLab还提供Git LFS（Large File Storage）支持和GitHooks。理论上，如果存在路径遍历，攻击者可能把服务器上的敏感文件伪装成仓库文件读取（LFS文件下载是否有权限绕过？），或者上传恶意Git钩子脚本。如果GitLab在某些操作中意外地执行了用户提供的钩子，那就是RCE。但正常情况下GitLab不会执行仓库自带钩子，除非漏洞。

Gitaly服务是GitLab用于执行Git操作的后端（用Go编写，gRPC通信）。先前有针对Gitaly的攻击研究不多，但值得注意：Gitaly也接收Git请求，也可能出现内存破坏或逻辑漏洞。假设攻击者能通过Git协议发送特制数据（如巨型pack文件）导致Gitaly崩溃或代码执行，这属于深度攻击面。目前已知的一个相关案例是CVE-2021-22205最初报告时被认为是经身份验证的，因为需要通过GitLab Workhorse上传，但后来发现未认证依然可调用该路径 (GitLab Unauthenticated RCE CVE-2021-22205 Exploited in the Wild )。这提醒我们GitLab内部不同组件的边界。

CI/CD 执行器（Runner）与管道

GitLab CI/CD 是一大特色，攻击面也相应复杂。首先，GitLab有共享Runner和私有Runner两种执行模式。Runner注册本身就可能有漏洞：早期曾讨论一般项目成员是否能看到Runner注册token，如果泄露，攻击者可注册恶意Runner。虽未找到公开CVE，但这是需要检查的点。

更突出的是GitLab本身CI逻辑漏洞。例如一系列 Pipeline Execution 漏洞：CVE-2023-5009、CVE-2024-5655、CVE-2024-6385、CVE-2024-6678 等。这些漏洞允许攻击者在不应有的情况下触发Pipeline，或以他人身份执行Job。其中 CVE-2024-6678（CVSS 9.9）就允许低权限用户触发环境停止操作（stop action）的Pipeline，以Pipeline所属用户的身份执行 (GitLab warns of critical pipeline execution vulnerability) (GitLab warns of critical pipeline execution vulnerability)。简单来说，攻击者可以伪造某种触发，使CI任务以管理员或项目所有者的权限运行，从而获取他们的CI变量/令牌等敏感信息。这些漏洞影响范围广（8.14起至17.3.1均受影响） (GitLab warns of critical pipeline execution vulnerability)，GitLab多次紧急发布补丁 (GitLab warns of critical pipeline execution vulnerability)。

红队在研究CI/CD攻击时，可以着重以下方面：

• CI 配置解析：.gitlab-ci.yml 配置由GitLab解析执行，过去曾有YAML注入或配置绕过来执行不受控命令的情况。如果解析器存在漏洞，可能直接RCE。
• Pipeline Trigger权限：普通开发者通常不能触发Protected Branch的Pipeline或替他人触发。如果发现某API或UI操作可让低权用户触发高级Pipeline，则是漏洞。
• CI任务权限提升：CI任务运行时绑定项目角色，但有漏洞使任务可以访问更高权限的资源。例如CVE-2020-13326（假设存在）可能是CI job artifact的漏洞。
• Runner与GitLab通信：Runner通过Token领取Job，如果通信过程或Token校验有缺陷，可能Runner伪装服务器或者反之。之前Cycode提到GitLab有GraphQL漏洞使任意用户获取Runner信息并注册恶意任务 (Security Advisory: GitLab Malicious Runner Vulnerability – Cycode)（需要验证具体ID）。
• 敏感信息泄露：CI中有Protected Variables，只能在特定条件下曝光。如果攻击者通过漏洞创建Pipeline拿到了这些变量，就构成严重问题。

总而言之，CI/CD为攻击者提供了一条“曲线”途径：不是直接攻击服务器，而是滥用系统为其“自动执行”恶意操作。比如提交恶意代码等待CI Runner在Runner主机执行，从而攻击Runner主机。如果Runner与GitLab共机，那就是变相RCE。因此，CI相关漏洞同样需要像应用漏洞一样严肃对待。

服务间通信与内部集成

GitLab内部由多进程架构和多个服务组件协作，如：Nginx/Workhorse(反代+接收上传)、GitLab Rails主应用、Sidekiq(后台任务)、GitLab Shell(处理SSH Git流量)、Gitaly(管理Git仓库操作)等。服务间通信通常通过HTTP或RPC完成，例如Workhorse与Rails通过内部HTTP请求交互。攻击者可以尝试伪造这些内部请求，从而绕过某些前置验证。

例如，GitLab Workhorse有一份允许访问的目录清单，正常情况下它会阻止读取非上传目录的文件。但攻击者找到Workhorse与Rails在处理文件上传时的一个绕过，能够直接请求Rails读取任意路径文件 (hackerone-reports/tops_by_program/TOPGITLAB.md at master · reddelexc/hackerone-reports · GitHub)。又如，Sidekiq执行任务时会根据任务名称和参数从Redis拉取数据，如果攻击者能写入恶意任务到Redis（通过前述Redis注入漏洞），Sidekiq可能执行非法操作。Redis在GitLab架构中既是缓存又是任务队列，非常敏感。前面的几个漏洞链条多次以Redis为攻击目标，因为一旦拿到Redis的控制权，就可能伪造Session、植入后台任务，从而完全控制应用 (Remote Command Execution via Github import (#371884) · Issues · GitLab.org / GitLab · GitLab)。

Hook机制也属于服务集成的一部分。GitLab支持System Hooks（管理员级别，在特定事件如用户创建时触发）和Project Hooks。如果System Hook URL被攻击者控制，可以获取大量敏感事件。但这算配置风险，不是漏洞。然而GitLab内部也有“钩子”概念：如Git仓库的server-side hooks、GitLab内部事件触发的钩子（比如GitLab WebHook那部分）。任何一个钩子执行外部程序的机会，都可能被利用。幸运的是GitLab通常执行钩子都在隔离环境下，但曾有传闻攻击者通过更改GitLab YAML配置，引入恶意钩子脚本执行（需要深入代码确认）。

第三方集成也属于这个范畴，例如Slack通知、Jira双向集成、Mattermost等。这些集成通常需要GitLab与你的自建服务互访。如果攻击者控制了GitLab发往Slack的请求（如SSRF），或者控制了Slack传来的内容（如Slack slash命令到GitLab的Webhook），可能利用双方信任实施攻击。2018年的HipChat SSRF (GitLab Security Release: 11.4.3, 11.3.8, and 11.2.7)就是例子，攻击者利用GitLab信任HipChat服务器的机制，反过来让GitLab请求其他地址。

导入/导出与备份功能

GitLab支持项目导出成归档，和从归档导入。这对于数据迁移很方便，但安全隐患在于：导入包内容非常复杂，包括仓库、wiki、issues、配置等，如果校验不严格，可能携带攻击载荷。前文已经详细讨论了项目导入RCE和组导入文件读取的案例。这里再强调几点：

• 备份还原：GitLab管理员可以生成整站备份(tar包)，其中包含Secret等。如果备份恢复流程没有验证来源，就有可能被植入后门文件执行。虽然备份功能默认需要本地shell操作，不易被远程利用，但不排除有人将备份文件上传然后触发恢复的场景。
• 文件导入：除了项目，GitLab还有其他导入，例如从GitHub/GitLab.com导入issue、从Jira导入issue等。这些功能可能涉及解析外部提供的数据格式（JSON、CSV等）。若解析器有漏洞，也可能RCE或注入。例如有报告称“FogBugz import SSRF”就是因为导入功能直接使用用户提供的URL下载附件 (GitLab – Arbitrary file read via the bulk imports UploadsPipeline)。
• 导出漏洞：相对少见，但导出功能如有漏洞，也可能让非授权用户下载到本不应得到的数据。例如早期版本某导出接口没有权限校验，导致机密信息泄露（没有具体CVE公开，在此假设可能存在）。

综上所述，GitLab的攻击面涵盖“从外到内”的各层次：web交互层、API调用层、后台服务层、集成接口层。红队应结合这些面去设计攻击路径。例如：“通过Web XSS获取管理Token -> 调用API提权 -> 导出备份 -> 分析获取密钥 -> 远程登录服务器” 这样多阶段的链条。在每个阶段，都有历史漏洞作为前车之鉴。下一节我们将归纳这些利用模式。

漏洞利用模式归纳

综合以上攻击面和实例，可以发现GitLab的漏洞往往不是孤立的，其利用通常遵循一些典型模式。红队可以参考这些模式，快速定位和组合利用漏洞：

• SSRF ⇒ 内网敏感服务 ⇒ RCE：这是GitLab攻击中屡见不鲜的链路。攻击者先利用SSRF漏洞访问GitLab内网服务，如Redis、数据库或内部HTTP接口。然后利用这些内部服务缺乏认证的特点执行敏感操作。例如2018年的组合拳：Webhook SSRF + Response Splitting，向内部Redis写入payload，引发Rails反序列化RCE (GitLab_File_Read_Remote_Cod…)。又如2022年的GitHub导入漏洞，实际上也是利用了内部Redis未校验用户可控数据的漏洞 (Remote Command Execution via Github import (#371884) · Issues · GitLab.org / GitLab · GitLab)。模式的关键在于，将一个Web层漏洞转化为对内网高敏接口的直接访问，进而控制全局。防守方应确保内部服务（Redis等）即使被内网访问也有认证机制；红队则会设法突破内网隔离，一旦打通，往往大有可为。
• 路径遍历 ⇒ 任意文件读写 ⇒ 提权/RCE：GitLab多次出现路径处理不当导致的文件读写漏洞。攻击者通常先读取敏感文件，如读取/etc/gitlab/gitlab-secrets.json拿到密钥，或者读取/opt/gitlab/embedded/service/.../credentials获取数据库密码等。这些信息可以用于后续提权（登录数据库提取更多数据，或伪造会话）。如果是任意文件写入，则更加直接：写入SSH公钥、写入Cron脚本甚至替换Rails源码，实现持久化RCE (Path traversal, to RCE (#36029) · Issues · GitLab.org / GitLab · GitLab)。在路径遍历利用中，双重URL编码、“过深目录”这些技巧经常出现 (GitLab Arbitrary File Read (CVE-2023-2825) Analysis)。归纳来说就是想尽办法绕过路径规范检查，把文件放到不该放的位置或拿到不该拿的文件。红队在获得文件读取能力后，可以重点搜集包含密码、令牌的文件用于横向移动。
• 不安全反序列化 / 命令注入：作为Rails应用，GitLab使用Ruby对象序列化（如YAML或Marshal）在缓存、Session等处。如果攻击者可以控制反序列化输入，就可能执行任意代码。GitLab官方非常注意这一点，但仍有漏洞从侧面引入了类似效果。例如利用Redis注入，写入精心构造的Ruby对象到缓存键，一旦Rails取出该缓存（可能通过Rails.cache.fetch)，就会触发反序列化RCE。这其实也是利用Rails自身的危险功能。再如ExifTool命令注入，本质也是第三方库反序列化外部数据执行系统命令 (Action needed by self-managed customers in response to CVE-2021-22205)。这种模式特点是触发点隐蔽——可能不在直接的Web请求，而是在后台某个任务/库函数。红队需要对GitLab源码有一定洞察，发现哪些地方存在类似反序列化调用（比如YAML.load）且可能被外部输入影响。一旦找到，就是高价值目标。
• 逻辑绕过 ⇒ 未授权操作：许多GitLab逻辑漏洞可概括为“应该有检查的地方没有检查”。例如邮件验证绕过使未验证用户调用内部API、模板功能缺陷使用户获取私有仓库等等。这类漏洞往往利用简单（直接调用或构造请求即可），但危害取决于场景。红队在评估时，可以构建“滥用场景”：假设自己是受限用户，然后尝试执行管理员才能做的动作，看系统如何响应。如果直接成功或报错信息异常详细，都可能意味着漏洞。典型模式如：IDOR（Insecure Direct Object Reference），使用有效ID访问未授权资源；权限标志绕过，例如请求参数admin=true之类如果被信任；功能组合，如通过一个普通功能调用内部的敏感功能（Project Import就是普通用户触发了管理员才能做的一些事）。逻辑漏洞有时需要多个条件配合才能利用，但一旦掌握，往往不会被日志审计发现，属于“悄无声息”的攻击。
• 前端攻击链（XSS ⇒ API调用 ⇒ 接管账户）：在GitLab这样的平台型应用中，XSS的危害不仅仅是弹窗。攻击者通常编写针对GitLab的特殊恶意脚本，例如自动调用GitLab的REST API修改项目设置、添加SSH Key到管理员账户、建立后门项目等 (Report #977697 – Stored-XSS in merge requests – HackerOne)。因此，一个低权限用户处的XSS也能通过操纵管理员完成高权限操作。如果结合社工或钓鱼，引诱管理员访问恶意页面，这条链路相当有效。红队经常利用存储型XSS作为“定时炸弹”，等待管理员查阅受感染的项目，从而劫持其Session进而控制整个实例。这强调了在报告XSS时，要评估其后续动作。GitLab已经比较完善地实施了内容安全策略（CSP），但依然出现绕过案例 (GitLab CE and EE Kroki Diagram Stored XSS Vulnerability – SonicWall)。因此前端攻击链永远值得一试，并与其它漏洞结合形成闭环。
• 供应链与第三方组件：GitLab整合了许多第三方技术，比如Rails库、Go库、前端JS库等。如果这些第三方出现漏洞且GitLab使用了，就可能间接影响GitLab安全。例如前述ExifTool漏洞是GitLab直接打包的第三方工具问题。再比如GitLab内置容器镜像注册表，如果基础的Docker Registry组件有路径遍历或RCE，则GitLab用户push镜像时也可能受影响（暂未出现重大报道）。红队可以监控GitLab发布的安全公告和依赖项CVE，当出现“GitLab升级组件X以修复CVE”时，往往意味着有潜在利用场景。例如之前GitLab升级了一次Rails以修复某JSON解析漏洞。如果目标没有及时升级，红队可以考虑利用对应的第三方CVE。

通过这些模式的分析，可以看到单个漏洞的威力在于如何与环境结合。红队通常不会孤立地利用一个漏洞，而是链式利用：用信息泄露辅助后续渗透，用低权RCE横向扩大权限，用逻辑漏洞隐藏踪迹等等。理解GitLab常见漏洞模式有助于快速构建攻击路径，提高成功率。

未来可能的攻击向量展望

展望未来，GitLab作为一个复杂的DevOps平台，可能出现的新型漏洞和攻击组合值得红队提前关注：

• 微服务及组件交互漏洞：GitLab版本演进中，可能进一步拆分服务（例如引入更多Go微服务、分布式架构）。服务间的认证与通信将变得更重要，也更复杂。这为身份混淆、权限提升提供了土壤。如果某服务错误地信任了来自内部网络的请求，攻击者一旦进入容器，就能控制其他组件。例如“RegreSSHion”漏洞（CVE-2024-6387）涉及OpenSSH库回退，尚未在GitLab中触发大的问题，但类似地，如果GitLab某服务使用了易受攻击的SSH/SSL库，可能引发0-click漏洞，实现账户接管 (GitLab warns zero-click vulnerability could lead to account takeovers)。未来攻击者可能利用GitLab服务之间的信任进行横向移动，比如从CI Runner容器跳到GitLab主应用。
• GraphQL API 深度利用：GitLab 正在将更多功能接口化到 GraphQL。GraphQL 的灵活性意味着更多的查询组合，攻击者可以尝试复杂查询导致的信息绕过或者DoS。GraphQL也可能出现基于查询的注入（如针对查询语句本身的解析漏洞）。GraphQL通常与权限系统深度绑定，如果有一处权限判断遗漏，攻击者或许可以借助GraphQL单一请求检索大量本不属于他的数据。随着GraphQL覆盖面扩大，红队应投入精力研究GitLab GraphQL Schema，寻找异常字段（比如可能泄露密钥、路径的字段）。
• CI/CD 新特性滥用：GitLab CI/CD 不断加入新功能，如安全扫描、外部部署集成等。这些特性有时需要GitLab与外部系统交互，比如与Kubernetes集群通信部署应用。如果接口验证不严，可能被利用。例如GitLab提供Kubernetes Agent用于CI部署，将来若Agent协议或身份验证有漏洞，攻击者可以伪造Kubernetes集群响应或拦截Runner通信来植入恶意代码。另一个角度，未来攻击者可能更多利用CI管道进行供应链攻击——通过提交代码触发CI，将后门植入构建产物，然后分发。这虽然不直接攻击GitLab本身，但利用了CI基础设施达成攻击目的。
• 基础架构和第三方依赖：GitLab依赖PostgreSQL、Redis、Graphite、Mattermost等组件。这些组件自身的漏洞也可能传导到GitLab环境中。比如如果Redis爆出远程未授权RCE漏洞，虽然默认Redis不开放外网，但GitLab中如果哪天出现可触发Redis恶意命令的意外路径，又会重演此前的故事。GitLab需要频繁关注其打包的依赖安全。红队则可以反其道而行：研究GitLab打包的特定版本依赖库，有无已知但未修补的漏洞作为突破口。
• 权限体系的边界测试：随着GitLab特性增加，权限模型愈发复杂（项目、组、子组、子群组、外部用户、内部用户、访客权限等等）。未来可能出现更隐蔽的权限绕过，比如链式权限问题——A动作允许X用户，B动作允许Y用户，但A→B组合允许了一个既非X也非Y的用户完成敏感操作。这需要对权限判断逻辑进行组合分析才能发现。红队可以开发自动化权限遍历工具，枚举不同角色对各种API和UI操作的访问结果，来挖掘这些逻辑瑕疵。
• Social Engineering + 技术漏洞：攻击GitLab往往不仅靠技术，还结合社工手段。未来可能见到更多例如钓鱼链接触发GitLab操作的攻击，比如利用GitLab的扩展（浏览器插件? WebHook?）诱导管理员执行敏感操作。目前已有攻击者在社区插件中植入恶意代码针对GitLab用户。红队可以考虑GitLab的用户信任链：有没有机会在Merge Request中藏危害（比如一个看似无害的MR，其实包含恶意Git trailer或CI设置，当维护者合并时触发漏洞）。
• AI与自动化：GitLab 17等版本开始引入AI帮助手段（例如代码解释、自动修复提示）。如果这些AI功能与GitLab实例交互不当，可能导致信息泄露（AI可能读取敏感代码摘要）、决策绕过（AI错误分类漏洞风险）等。不过短期看AI主要在客户端并不会直接执行服务器端操作。但值得一提的是，如果GitLab将来提供AI自动配置或修改仓库的功能，攻击者可能尝试通过诱导AI做出不安全的改动来实现攻击。

<a name=”总结” class=”reference-link”>总结

GitLab的安全在不断强化，但“道高一尺魔高一丈”，攻击者也会寻找新的突破口。从早年的XSS、CSRF，到后来的SSRF、RCE，再到如今复杂的CI/CD漏洞，我们可以预见未来的攻击将更加综合和隐蔽。红队应持续关注GitLab官方的安全公告和社区研究，在漏洞尚未曝光前发掘0day。同时，构建针对GitLab的攻击链库，在拿到一个入口漏洞时迅速联想可以组合哪些后续步骤，最大化利用效果。