Grafana Loki 3.6.20, 보안 관련 라이브러리 갱신

핵심 요약
Grafana Loki 3.6.20은 3.6 유지 브랜치의 보안 관련 라이브러리를 갱신한 패치입니다. 라이브러리 4종에 연결된 upstream CVE는 5개지만, Loki 원격 공격 5건이 확인됐다는 뜻은 아닙니다. 운영자는 현재 구성과 복구 계획을 먼저 확인하고, 시험 환경에서 영향을 살펴보는 편이 좋습니다.[1][2][3][4][5]

로그를 모아 검색하는 Grafana Loki의 3.6.20 패치가 나왔습니다. 저장된 공식 릴리스 자료에서 게시 시각은 2026년 11월 7일 오전 1시 11분 18초 KST로 확인됩니다. 이번에 주목할 부분은 새로운 대시보드 화면이 아니라, Loki가 사용하는 보안 관련 라이브러리의 버전 변경입니다.[1]

다만 취약한 부품이 들어 있다는 사실과, 외부 입력이 그 부품의 취약한 기능까지 도달한다는 판단은 다릅니다. 이번 변경을 제로데이 공격 차단이나 로그 유출 사고 대응으로 해석할 근거는 확보하지 못했습니다. 변경 내용과 아직 확인되지 않은 영향을 나눠 살펴보겠습니다.[2][3][4][5]

Loki는 어떤 역할을 하나요?

Loki는 여러 서버와 애플리케이션의 로그를 모아 저장하고 검색할 수 있게 하는 로그 시스템입니다. 수집기가 로그를 보내면 Loki가 저장·검색을 담당하고, Grafana는 Loki를 데이터 소스로 연결해 결과를 보여줄 수 있습니다. Loki는 로그 전체 내용을 미리 색인하기보다는 서비스나 환경 같은 라벨을 색인하고 로그 본문은 압축된 묶음으로 저장합니다.[6]

여기서 Grafana 대시보드 본체와 Loki는 다른 프로젝트입니다. Grafana 화면을 사용한다는 이유만으로 모든 사용자가 이번 Loki 패치를 직접 적용해야 하는 것은 아닙니다. 자체 Loki를 운영하는지, 관리형 서비스를 쓰는지부터 구분해야 합니다. 이번 소식을 Grafana 로그인이나 대시보드 취약점 수정으로 바꿔 읽어서도 안 됩니다.[1][6]

어떤 라이브러리가 바뀌었나요?

보안 관련 변경의 중심은 아래 4종입니다. 공식 Loki PR에 적힌 변경 전후 버전과 저장된 3.6.20 go.mod 발췌를 대조했습니다. CVE는 원래 라이브러리 쪽에서 공개한 취약점 식별자이며, 곧바로 Loki의 외부 공격 경로를 뜻하지는 않습니다.[1][2][3][4][5]

x/net 두 건은 HTML 처리와 관련됩니다. 패키지 이름에 net이 들어 있다고 HTTP/2 취약점으로 설명하면 안 됩니다. 압축 라이브러리 역시 upstream에서 문제를 설명했다는 사실과, 이전 Loki 빌드가 외부에서 같은 입력을 받아 중단된다는 주장은 별개입니다. 다른 의존성도 이번 자료에서는 Loki의 구체적인 공격 경로나 실전 악용을 확인하지 못했습니다.[4][5]

이 표가 3.6.20의 모든 의존성 변경을 나열한 것은 아닙니다. 공식 변경 자료에는 보안 표기 4종 외의 의존성 갱신도 포함됩니다. 그렇다고 그 항목에 확인되지 않은 CVE를 붙일 수는 없습니다.[1]

스캐너 경고와 실제 공격 가능성은 왜 다른가요?

jsonutils 사례에서 그 차이가 분명합니다. 공식 Loki PR #26286은 배포 코드에서 취약한 ordered-map 경로에 도달할 수 없다고 설명합니다. 해당 라이브러리가 Alertmanager models와 kube-openapi를 통해 들어오지만, 그 경로에서는 순서 보존용 코드가 아니라 일반 encoding/json 처리를 사용한다는 설명입니다.[3]

이는 공식 PR의 설명을 인용한 판단입니다. 이 글에서 독립적으로 침투 시험을 하거나 모든 Loki 구성을 검증한 결론은 아닙니다. 해당 경로에 대한 설명을 Loki 전체가 안전하다는 보장으로 넓혀서도 안 됩니다.[3]

버전도 구분해야 합니다. jsonutils의 해당 문제를 처음 고친 버전은 0.27.1이고, 이번 Loki가 채택한 버전은 0.29.2입니다. “0.29.2에서 처음 수정됐다”라고 쓰면 수정 이력이 달라집니다. 라이브러리를 갱신해 스캐너 경고를 정리하는 작업은 의미가 있지만, 경고 개수만으로 실제 침해 가능성을 계산할 수는 없습니다.[3]

3.6.20이 제품 전체의 최신 안정판인가요?

저장 자료의 기준시각에 GitHub의 대표 안정 릴리스는 3.7.9였습니다. 이번 등록 전 릴리스 API 재조회에서도 같은 표시를 확인했습니다. 3.6.20은 그보다 나중에 게시된 3.6 계열 유지보수 패치입니다. 게시일이 최근이라는 사실과 더 높은 안정 버전 계열이라는 사실은 구분해야 합니다. 3.7 계열 운영자에게 3.6.20으로 다운그레이드하라고 권하지 않습니다.[7]

이번 대조에서는 3.7.9가 같은 CVE를 모두 수정했는지 별도로 검증하지 않았습니다. 따라서 3.7.9가 안전하다거나 위험하다고 단정하지 않습니다. 별도 출시 후보판인 4.0.0-rc.3의 S3 저장등급 제한도 3.6.20의 변경이나 필수 조치에 섞지 않았습니다.[7]

운영자는 어떤 순서로 준비하면 좋을까요?

아래는 공식 운영 문서의 일반 원칙을 참고한 준비 안내입니다. Grafana가 이번 패치에 대해 모든 환경에 강제한 별도 필수 절차는 아닙니다. 실제 적용 방식은 배포 형태와 지원 브랜치에 맞춰 판단해야 합니다.[8][9][10]

1. 구성·저장소·보존부터 확인합니다. Loki 실행 버전, 바이너리나 이미지, 배포 방식, Helm chart 버전을 각각 구분합니다. 설정과 인증 연동, 스키마·색인, 로그 청크 저장 위치, WAL과 영속 볼륨, 보존 정책 및 버킷 수명주기를 파악합니다. 차트 갱신과 Loki 갱신도 같은 작업으로 보지 않습니다. 보존 기간을 줄이거나 기존 데이터를 지우는 일을 패치의 전제조건으로 삼지 않습니다.[8][9]
2. 백업과 복구 준비를 먼저 갖춥니다. 현재 설정과 저장 데이터, 필요한 영속 상태의 복구 지점과 복원 방법을 준비하는 것이 일반적인 운영 권고입니다. 백업 대상과 일관성 확보 방식은 배포 형태마다 다릅니다. 복구 절차를 확인하기 전에 단순히 이전 버전으로 되돌리면 안전하다고 가정하지 않습니다.[8][9]
3. 스테이징에서 검증합니다. 운영과 비슷한 시험 환경에서 설정 유효성과 로그 수집→저장→검색 흐름을 살펴봅니다. 최근 로그뿐 아니라 과거 로그 검색, 기존 알림, 인증·권한, 압축 데이터 읽기도 점검 대상입니다. 여러 버전을 건너뛴다면 공식 업그레이드 안내의 해당 구간을 별도로 확인해야 합니다. 이 글에서 이를 실행하거나 정상 동작을 실측한 것은 아닙니다.[8]
4. 범위를 제한해 적용합니다. 유지보수 시간과 허용 가능한 중단, 복구 판단 기준을 정한 뒤 해당 배포 방식의 공식 절차에 따라 단계적으로 적용하는 것이 일반 원칙입니다. 모든 구성이 무중단이라는 보장은 없으며, 환경을 모르는 상태에서 재시작 순서를 일률적으로 제시할 수도 없습니다.[8]
5. 적용 전후 상태를 비교합니다. 수집·요청 오류, 검색 응답시간, 프로세스 재시작, CPU·메모리 사용량, 저장소 접근 오류와 지연을 관찰합니다. 공식 모니터링 문서는 Loki 자체 상태를 별도의 정상적인 관측 환경에서 살펴보는 구성을 권고합니다. 문제가 생기면 스키마와 저장 데이터 호환성을 고려한 복구 계획에 따라 판단해야 합니다.[10]

이번 패치는 “침해가 확인됐으니 일괄 긴급 조치”라는 소식보다는, 사용 중인 유지 브랜치의 라이브러리 갱신과 영향 범위를 살펴볼 계기로 읽는 편이 정확합니다. 부품의 취약점, 실제 호출 경로, 운영 환경을 나눠 확인한 뒤 시험을 거쳐 적용 여부와 일정을 정하는 것이 핵심입니다.[1][2][3][4][5]

출처