A common misconfiguration in GitLab project documentation is being exploited by attackers to push malicious code directly into repositories, bypassing standard security reviews. The attack leverages private email addresses intended for issue tracking, which, when exposed in public files, function as unauthenticated gateways for code commits.
Security researchers at BleepingComputer report that attackers are actively scanning for GitLab projects that have inadvertently published these private email addresses in public documentation. In GitLab, each project can have a unique email address designed for submitting issues or tasks. However, when this email appears in public-facing files like READMEs or CONTRIBUTING guides, it can be misused to push code changes without requiring merge request approvals, effectively circumventing the peer review process essential for maintaining code integrity.
This vulnerability underscores a fundamental tension in open-source collaboration: balancing ease of contribution with robust protection against unauthorized modifications. By including these email addresses in public guides, project maintainers unintentionally create a pathway for attackers to introduce malicious code, which could then propagate to all downstream users and dependencies. The result is a significant supply chain risk, as compromised code may be trusted and deployed without detection.
This issue is particularly critical for organizations in regulated sectors, such as fintech or enterprise environments, where GitLab may be used for sensitive software development. A successful exploit could lead to data breaches, service disruptions, or compliance violations, highlighting the importance of rigorous configuration audits and security hygiene in DevOps practices.
To mitigate this risk, the following steps are recommended:
-
Audit Public Documentation: Review all public files, including README, CONTRIBUTING, and support pages, to ensure no private GitLab project email addresses are exposed. Remove or replace them with generic contact methods.
-
Use Authenticated Workflows: Encourage contributors to use GitLab’s web interface or authenticated Git protocols for submitting code changes, rather than email-based pushes.
-
Configure Push Rules: Enable GitLab’s push rules to require that all code changes go through merge requests, with mandatory code reviews and approvals before integration.
-
Restrict Email Interactions: Review GitLab project settings to ensure that email-based interactions are limited to issue reporting and do not allow code pushes. Disable any features that enable email-based code commits.
This incident serves as a reminder that security in software development extends beyond tool vulnerabilities to include human error and process design. As open-source projects power critical infrastructure globally, maintaining secure collaboration practices is essential for protecting the broader software supply chain. DevOps teams should proactively address such exposures to safeguard their projects and the trust of their users.
GitLab 項目文檔中常見的配置錯誤正被攻擊者利用，將惡意代碼直接推送至儲存庫，繞過標準安全審查。此攻擊利用了原本用於問題追蹤的私人電郵地址，當這些地址在公開文件中曝光時，便會成為無需身份驗證的代碼提交通道。
安全研究機構 BleepingComputer 報導指出，攻擊者正主動掃描那些不慎將私人電郵地址公開於文檔中的 GitLab 項目。在 GitLab 中，每個項目都可設有用於提交問題或任務的專屬電郵地址。然而，當此電郵地址出現於 README 或 CONTRIBUTING 指南等公開文件中時，可能被濫用以推送代碼變更，無需經合併請求審批流程，實質上規避了維護代碼完整性所必需的同儕審查。
此漏洞凸顯了開源協作中的根本矛盾：如何在貢獻便捷性與防範未經授權修改的強力保護之間取得平衡。項目維護者將這些電郵地址納入公開指南，無意間為攻擊者創造了引入惡意代碼的路徑，而這些代碼可能隨後傳播至所有下游用戶及依賴項。這導致重大的供應鏈風險，因為受損代碼可能在未被察覺的情況下獲得信任並被部署。
對於金融科技或企業環境等受監管行業的組織而言，此問題尤為關鍵，因為 GitLab 可能被用於敏感軟件開發。成功的漏洞利用可能導致數據洩露、服務中斷或合規違規，突顯了在 DevOps 實踐中進行嚴格配置審計及維護安全衛生的重要性。
為降低此風險，建議採取以下步驟：
-
審計公開文檔： 檢查所有公開文件，包括 README、CONTRIBUTING 及支援頁面，確保沒有泄露私人 GitLab 項目電郵地址。應將其移除或替換為通用聯繫方式。
-
使用經身份驗證的工作流程： 鼓勵貢獻者透過 GitLab 網頁介面或經身份驗證的 Git 協議提交代碼變更，而非透過電郵推送。
-
配置推送規則： 啟用 GitLab 的推送規則，要求所有代碼變更必須透過合併請求進行，並在整合前強制進行代碼審查及批准。
-
限制電郵互動： 審查 GitLab 項目設定，確保基於電郵的互動僅限於問題報告，不允許代碼推送。停用任何支援基於電郵提交代碼的功能。
此事件提醒我們，軟件開發的安全性不僅涉及工具漏洞，亦包括人為錯誤與流程設計。隨著開源項目支撐全球關鍵基礎設施，維持安全的協作實踐對於保護更廣泛的軟件供應鏈至關重要。DevOps 團隊應主動處理此類暴露風險，以保障其項目及用戶的信任。