A feature designed for convenience has become a stealthy security loophole. Research reveals that publicly listed GitLab project email addresses, often shared for bug reporting, can be abused to silently inject malicious commits into code repositories, bypassing standard security reviews entirely.
The Mechanism of Silent Attack
GitLab creates unique, project-specific email addresses to allow external users to submit issues via email. However, as detailed in a September 28 report from BleepingComputer, these same email endpoints can accept code push payloads. If a GitLab instance is not configured to restrict email-based pushes, an attacker can craft a malicious commit into an email and send it directly to the exposed address. GitLab then processes this email and inserts the attacker's code as a new commit.
The attack's power lies in its stealth. Because the commit originates from the project's own system-generated email address—the same address GitLab uses for its internal automated actions—it appears as a legitimate system activity. This allows it to blend seamlessly into the commit history, evading both automated scanning tools and human code review.
A Common Practice Creates the Vulnerability
This attack vector exists because many open-source and corporate projects deliberately publish these email addresses. They are often embedded in README files, CONTRIBUTING guides, and public support pages to streamline how users report bugs or suggest features. While the intention is to improve accessibility, this practice directly advertises a ready-made entry point into the codebase. Attackers need only scan a project's public documentation to find the address, requiring no authentication tokens or SSH keys to execute the breach.
A Systematic Blind Spot in Security
Traditional GitLab security hardening focuses on HTTP APIs, SSH access, and personal access tokens. The email-to-push functionality represents a frequently overlooked audit surface. Standard security reviews rarely include checks for push-capable email addresses, leaving this vector unmonitored by default.
For development teams in Hong Kong and globally managing internal or open-source projects, this represents a critical gap. The combination of a publicly shared address and default GitLab settings creates a low-effort, high-impact risk that requires no sophisticated tooling to exploit.
Concrete Steps to Mitigate the Risk
Repository maintainers and security teams should prioritize the following actions:
- Audit and Sanitize Public Documentation: Search all public-facing documentation, including
READMEandCONTRIBUTINGfiles, for GitLab project email addresses. Remove them or replace them with web-based issue templates. - Restrict Email-to-Push Functionality: Configure the GitLab instance to disable email-based pushes entirely or restrict them to authenticated, pre-approved senders.
- Enforce Cryptographic Commit Verification: Require GPG-signed commits for all merges. This adds a verification layer that unsigned commits injected via email cannot pass.
- Review Mail Processing Policies: Examine the instance's email handling configuration to ensure it properly validates sender identity before processing any commit payloads.
Awareness is the Primary Hurdle
The technical fixes for this vulnerability are straightforward and low-effort. The greater challenge is awareness. Many development and DevOps teams do not consider that an email address published for bug reports could also function as a code injection point.
This incident serves as a stark reminder of the security trade-offs embedded in development workflow conveniences. A brief, targeted audit of your project's public assets and GitLab instance configuration is all it takes to close this silent backdoor and prevent a potential compromise.
一項旨在提供便利的功能，已成為一個隱蔽的安全漏洞。研究顯示，公開列出的 GitLab 項目電郵地址（通常用於錯誤報告）可能被濫用，將惡意提交靜默注入代碼倉庫，完全繞過標準安全審查。
靜默攻擊的機制
GitLab 會創建獨特的項目專屬電郵地址，允許外部用戶透過電郵提交議題。然而，根據 BleepingComputer 於 9 月 28 日發布的詳細報告，這些電郵端點同樣可以接收代碼推送載荷。若 GitLab 實例未配置為限制基於電郵的推送，攻擊者便可將惡意提交編寫成電郵，直接發送至公開的電郵地址。GitLab 隨後處理該電郵，並將攻擊者的代碼作為新提交插入倉庫。
此攻擊的威力在於其隱蔽性。由於提交源自項目自身的系統生成電郵地址（即 GitLab 用於內部自動操作的相同地址），它看起來像是一個合法的系統活動。這使其能無縫融入提交歷史，規避自動化掃描工具及人工代碼審查。
常見做法催生漏洞
此攻擊向量的存在，是因為許多開源及企業項目故意公開這些電郵地址。它們常被嵌入 README 檔案、CONTRIBUTING 指南及公開支援頁面中，以簡化用戶報告錯誤或建議功能的流程。雖然初衷是提高可達性，但此做法直接宣傳了一個現成的代碼庫入口。攻擊者只需掃描項目的公開文件即可找到該地址，執行入侵無需任何認證令牌或 SSH 密鑰。
安全體系中的系統性盲點
傳統的 GitLab 安全加固專注於 HTTP API、SSH 存取和個人存取令牌。電郵轉推送功能代表了一個常被忽視的審計面。標準安全審查很少包含對具備推送能力的電郵地址的檢查，導致此向量在預設情況下未受監控。
對於香港及全球管理內部或開源項目的開發團隊而言，這構成了一個關鍵缺口。公開共享的電郵地址與 GitLab 預設設定的結合，創造了一個低投入、高影響的風險，且無需複雜工具即可利用。
緩解風險的具體步驟
倉庫維護者及安全團隊應優先執行以下行動：
- 審計與清理公開文件： 搜尋所有公開文件，包括
README和CONTRIBUTING檔案，查找 GitLab 項目電郵地址。將其移除或替換為基於網頁的議題模板。 - 限制電郵轉推送功能： 配置 GitLab 實例以完全禁用基於電郵的推送，或將其限制為經認證、預批准的發送者。
- 強制執行加密提交驗證： 要求所有合併都使用 GPG 簽署的提交。這增加了一個驗證層，使透過電郵注入的未簽署提交無法通過。
- 審查郵件處理政策： 檢查實例的電郵處理配置，確保在處理任何提交載荷前，能正確驗證發送者身份。
意識是主要障礙
此漏洞的技術修復直接且輕鬆。更大的挑戰在於意識。許多開發及 DevOps 團隊並未考慮到，一個用於錯誤報告的電郵地址，也可能成為代碼注入點。
此事件強烈提醒我們，開發工作流程的便利性中隱含著安全權衡。只需對你的項目公開資產及 GitLab 實例配置進行簡短而有針對性的審計，即可關閉這個靜默後門，防止潛在的安全入侵。