Git
이 태그가 달린 문서 5건
GitLab CVE-2026-110264(CVSS 10.0)와 악용되는 CVE-2026-97229: 셀프 호스팅 GitLab 확인 및 업데이트 방법
2026년 10월 21일 GitLab은 Community Edition(CE)과 Enterprise Edition(EE)용 긴급 패치 버전 19.5.1, 19.4.3, 19.3.6, 19.2.9, 19.1.9, 19.0.10, 18.11.13을 공개했습니다. 가장 심각한 취약점인 CVE-2026-110264(CVSS 10.0)는 특수하게 조작된 정규식을 컴파일할 때 발생하는 정수 오버플로우입니다. 특정 조건에서 인증되지 않은 사용자가 GitLab 서버에서 임의의 코드를 실행할 수 있게 할 수 있습니다. 7.0 이후 거의 모든 버전이 영향을 받습니다. 10월 29일 CISA는 자매 취약점 CVE-2026-97229(CVSS 10.0, CWE-190)를 KEV(Known Exploited Vulnerabilities) 카탈로그에 추가했으며 기한은 11월 1일입니다. 같은 종류의 버그(CI/CD 정규식 컴파일러의 정수 오버플로우, 인증되지 않은 사용자가 도달 가능)로, GitLab은 10월 12일 19.4.2, 19.3.5, 19.2.8에서 먼저 수정했으며 영향받는 범위는 19.2.0부터 19.2.7, 19.3.0부터 19.3.4, 19.4.0부터 19.4.1뿐입니다. 아직 19.4.2, 19.3.5, 19.2.8 미만이라면 악용되는 취약점에 노출된 상태입니다. 여기서 권장하는 버전(19.5.1, 19.4.3, 19.3.6, 19.2.9)으로 업그레이드하면 CVE-2026-97229도 함께 수정됩니다. GitLab.com은 이미 패치되었으며, 셀프 호스팅 설치는 업그레이드해야 합니다. 10월 21일 릴리스는 심각도 High인 취약점 2건(CVSS 8.2와 7.5)과 기타 취약점도 수정하지만, 해당 수정은 19.3.6, 19.4.3, 19.5.1 라인에서만 제공됩니다. 근본 원인은 Ruby의 정규식 엔진(Onigmo)에 있으며, Ruby는 10월 23일 4.0.9, 3.4.12, 3.3.13을 공개했습니다. 공격자가 제어하는 문자열로 정규식을 컴파일하는 애플리케이션이 영향을 받으며, Regexp.timeout은 이 버그들로부터 보호하지 못합니다. GitLab의 공지는 CVE-2026-110264가 악용되었다고 밝히지 않았고, 10월 30일 기준 KEV에도 없습니다. Alpine Linux는 10월 20일과 21일 자사 GitLab에 CVE-2026-97229를 통한 공격 시도가 있었고, GitLab만 (19.3.6으로) 업그레이드해서는 수정에 Ruby 패치도 필요했기 때문에 취약점이 막히지 않았으며, 인스턴스를 재구축했고 공격자의 코드가 실행된 증거는 찾지 못했다고 밝혔습니다. 이 사이트의 결론: 필수 업그레이드 중간 단계를 확인한 뒤 셀프 호스팅 GitLab을 오늘 업그레이드하고, 최종적으로 19.3.6 이상에 도달하며, GitLab을 직접 빌드하거나 자체 Ruby를 쓴다면 Ruby도 3.3.13, 3.4.12 또는 4.0.9 이상인지 확인하십시오. Ruby 애플리케이션은 수정된 Ruby로 옮기고, 사용자 입력으로 정규식을 만드는 방식을 중단해야 합니다.
GitHub 2단계 인증(2FA) 설정: 인증 앱, 패스키, 복구 코드, 그리고 휴대폰을 잃어버렸을 때 할 일
GitHub에서 2단계 인증(2FA)을 설정하고 잠김을 피하는 가이드. GitHub는 2023년 3월부터 GitHub.com에 코드를 기여하는 사용자에게 그룹별로 2FA를 의무화하고 있다. 대상이 되면 45일의 등록 기간과 7일의 유예 기간이 주어지고, 그 뒤에는 2FA를 켤 때까지 GitHub.com을 쓸 수 없다. GitHub Docs는 TOTP 인증 앱을 주 방법으로, 패스키나 보안 키를 백업으로 권장한다(패스키, 보안 키, GitHub Mobile은 TOTP나 SMS를 설정한 뒤에만 추가할 수 있다). 본 사이트의 견해: GitHub 2FA에서 흔한 실패는 계정 탈취가 아니라 스스로 잠기는 것이며, 2FA 수단과 복구 방법을 모두 잃은 계정은 GitHub Support도 복구할 수 없다. 16개의 복구 코드를 비밀번호 관리자에 저장하고, 같은 날 두 번째 방법을 등록하라. 그 김에 만료되는 fine-grained 토큰으로 옮기고, 승인된 앱과 SSH 키를 정리하고, 푸시 보호와 Dependabot 알림을 확인하라.
GitHub에 공개된 인증 정보 543,699건이 여전히 유효했다 (2026년 연구): 삭제가 아니라 폐기해야 하는 이유와 개발자가 할 일
비밀값 검사 도구를 판매하는 보안 회사가 LLM 학습용으로 수집된 약 2억 2,400만 개 공개 저장소의 스냅숏을 조사해, 2026년 7월 말 시점에 543,699건의 인증 정보가 여전히 인증에 성공했다고 보고했다. 노출 후 경과 기간의 중앙값은 784일이었다. npm과 GitHub 토큰은 거의 모두 무효화돼 있었던 반면, 데이터베이스 연결 문자열은 75~88%가 여전히 작동했다. 유효한 인증 정보 중 19만 9천 건 이상은 GitHub가 push protection을 기본으로 켠 뒤에 나타났고, 유효한 것의 절반 이상은 push protection이 기본으로 막지 않는 유형이었다. 이 사이트의 결론 = 공개 저장소에 push한 인증 정보는 파일 삭제나 이력 재작성으로 회수할 수 없으므로 먼저 폐기한다. 유출된 인증 정보가 자동으로 폐기되는지는 발급자에 달려 있으며, 연결 문자열과 많은 API 키는 내가 멈출 때까지 유효하다.
gitleaks로 커밋 전에 시크릿을 막아라: push 전에 API 키 유출 잡기
시크릿은 '유출된 뒤 삭제'할 수 없다. 한 번 커밋되면 Git 히스토리에 남고, push되면 유출된 것으로 다뤄야 한다 — 키를 폐기/교체해야 한다. gitleaks는 정규식/엔트로피로 저장소 전체와 커밋 히스토리를 스캔해 API 키, 개인 키, 토큰을 찾는 무료 도구다. 방어의 핵심은 두 단계의 점검: push 전에 로컬에서 막는 pre-commit 훅과, 빠져나간 것을 잡는 CI/cron. .gitignore는 새 추적만 막을 뿐 탐지하지 못하므로, 스캐너가 여전히 필요하다.
자체 호스팅 Git vs GitHub: 실제로 어느 쪽이 더 안전한가?
Git을 자체 호스팅한다고 '더 안전'해지지 않습니다 — 위험을 옮길 뿐입니다. 실수로 인한 공개 노출 부류는 사라지지만, 서버 패치·백업·커밋 전 시크릿 탐지가 당신에게 넘어옵니다. 그 일을 계속 해낸다면 옳은 선택이고, 방치하면 GitHub보다 나쁩니다. 본 사이트의 견해: 자체 호스팅은 보상 통제와 묶일 때만 작동합니다.