```

The US Cybersecurity and Infrastructure Security Agency (CISA) says attackers are now actively exploiting a maximum-severity GitLab vulnerability that the vendor patched shortly before the agency's warning, according to BleepingComputer's report. The flaw has been added to CISA's Known Exploited Vulnerabilities (KEV) catalogue, which in practice converts a routine patch advisory into a deadline-driven one for anyone running a self-managed GitLab instance.

The core point for operators: the fix already exists. What has changed is that the window between "patched" and "publicly exploited" has closed, and any organisation still running an unpatched release is now a target rather than a straggler.

Who is affected

The important distinction in this story is between GitLab SaaS and self-managed installations. GitLab's hosted service is patched by the vendor; the exposure sits with organisations that run GitLab on their own infrastructure — a common setup in development shops that keep source code, CI/CD runners, and container registries on-premises or in private cloud for compliance and data-residency reasons. The advisory is broadly relevant to organisations running self-managed GitLab, including in Hong Kong — though no Hong Kong-specific incident has been reported.

What this summary does and does not carry

The reporting available here establishes three things: maximum severity, a vendor patch issued shortly before CISA's warning, and exploitation observed in the wild. It does not carry the CVE identifier, the CVSS score, the affected and fixed version ranges, or any KEV remediation deadline — so this summary does not reproduce those figures; operators should work directly from GitLab's advisory and the CISA bulletin.

Same-day checklist for self-managed instances

  1. Establish exposure. Check your installed GitLab version (/help in the web UI, or the package manager manifest) against the affected range in GitLab's security release notes. If your instance is outside the affected range, document that check and move on.
  2. Patch to a fixed release. Upgrade to the latest patched version for your supported upgrade path, following GitLab's documented upgrade sequencing — skipping major versions can break background migrations.
  3. If you cannot patch today, mitigate. Restrict network access to the GitLab web endpoint and API to trusted ranges, disable or tightly limit public project registration, and review the allowlist for runners and deploy tokens. Treat these as holding measures, not fixes.
  4. Look for signs of exploitation. Review authentication logs for anomalous logins, new or elevated access tokens, unexpected admin or owner membership changes, and unusual CI/CD job activity such as runners invoking unfamiliar endpoints. Preserve logs before you rotate anything.
  5. Rotate credentials if in doubt. Personal access tokens, runner registration tokens, and webhook secrets should be treated as potentially compromised for any instance that was reachable and unpatched during the exploitation window.

Why this matters beyond the patch itself

GitLab sits at the centre of the software supply chain: access to a CI/CD instance typically means access to build credentials, container registries, and deployment keys. A confirmed-in-the-wild flaw on that path warrants the same urgency teams would apply to an internet-facing VPN appliance. CISA's KEV listing signals that this is not a theoretical risk, and self-hosted operators — including those in Hong Kong's dev-ops and CI/CD-heavy environments — should treat the upgrade as a same-day task.

```

據 BleepingComputer 報道，美國網絡安全和基礎設施安全局（CISA）表示，攻擊者目前正積極利用一個最高嚴重性的 GitLab 漏洞，而廠商在該局發出警告前不久才剛為此漏洞修補程式。該漏洞已列入 CISA 的已知被利用漏洞（KEV）名錄，實際上這意味著一則例行修補公告，對所有自行運行 GitLab 實例的人士而言，已變成一項限期任務。

對運營者而言，核心要點是：修補程式早已存在。變了的是「已修補」與「已被公開利用」之間的窗口已經關閉，任何仍在運行未修補版本的機構，如今已成為攻擊目標，而非落後一步的少數。

受影響的範圍

這則新聞的關鍵，在於區分 GitLab SaaS 與自行安裝（self-managed）版本。GitLab 的託管服務由廠商負責修補；風險則落在自行於自有基礎設施上運行 GitLab 的機構——這種部署在開發團隊中十分常見，它們基於合規及資料所在地（data residency）要求，將原始碼、CI/CD runner 及 container registry 置於本地（on-premises）或私有雲。該公告廣泛適用於運行自行管理 GitLab 的機構，包括香港——惟目前未有香港本地的相關事件報告。

本摘要包含與不包含的內容

此處可得的報道確立了三點：最高嚴重性、廠商在 CISA 警告前不久發出修補程式，以及已觀察到野外（in the wild）利用。報道並未提供 CVE 編號、CVSS 評分、受影響及已修復的版本範圍，或任何 KEV 修補期限——因此本摘要不重列這些數字；運營者應直接依據 GitLab 的安全公告及 CISA 通報自行處理。

自行管理實例的即日清單

  1. 確定暴露範圍。 將你已安裝的 GitLab 版本（在網頁介面輸入 /help，或查閱套件管理器清單）對照 GitLab 安全版本說明中的受影響範圍。若你的實例不在受影響範圍內，記錄該檢查結果並繼續跟進其他事項。
  2. 修補至已修復版本。 按照 GitLab 文件規定的升級次序，沿支援的升級路徑升級至最新已修補版本——跳過主要版本（major versions）可能令背景遷移（background migrations）失敗。
  3. 若今日無法修補，先作緩解。 將 GitLab 網頁端點及 API 的網絡存取限制至可信 IP 範圍，停用或嚴格限制公開項目註冊，並檢視 runner 及 deploy token 的 allowlist。這些只是臨時措施，並非修補。
  4. 留意被利用的跡象。 檢視 authentication logs，查找異常登入、新增或權限提升的 access token、非預期的管理員或 owner 成員變動，以及不尋常的 CI/CD job 活動（例如 runner 呼叫陌生端點）。在輪換任何憑證之前，先保存日誌。
  5. 如有疑問，即時輪換憑證。 對於在利用窗口期間可被存取且未修補的實例，personal access token、runner registration token 及 webhook secret 均應視為可能已遭洩露。

為何此事的重要性超越修補本身

GitLab 位居軟件供應鏈核心：存取一個 CI/CD 實例，通常即代表可取得 build credential、container registry 及部署金鑰。該路徑上已證實野外利用的漏洞，值得團隊以同等於應對面向互聯網的 VPN 裝置的緊急程度處理。CISA 將其列入 KEV，顯示這並非理論風險，而自行託管的運營者——包括香港 dev-ops 及重度使用 CI/CD 的環境——應將升級視為即日完成的任務。

新聞來源 / Original News Source