Core Lightning 26.06.7 보안 업데이트, 소스 공개 전 확인할 절차
Core Lightning 노드를 운영한다면 26.06.7로 가능한 한 빨리 올리되, 내려받은 바이너리의 체크섬과 유지관리자 서명을 먼저 확인하는 것이 현재의 직접 답입니다. 2026년 8월 28일 공개된 이번 보안 릴리스는 취약점 세부 내용과 소스 코드를 14일 동안 공개하지 않습니다. 소스 공개 전 바이너리를 설치하고 싶지 않다면 노드를 평소처럼 온라인에 둔 채 기다리기보다 --offline으로 재시작해 피어 연결을 멈추는 선택지를 검토해야 합니다.
Core Lightning 26.06.7은 여러 제보로 확인된 취약점을 고친 보안 릴리스입니다. 실제 공격이 진행 중이라는 공식 확인은 없지만, 세부 정보가 공개되는 약 2주 뒤에는 패치 차이를 분석한 공격 시도가 쉬워질 수 있습니다. 운영자는 설치 방식과 CPU 아키텍처를 확인한 뒤 공식 자산만 받고, SHA-256 체크섬과 GPG 서명을 검증하고, 재시작 후 버전·피어·채널 상태를 점검해야 합니다.
Core Lightning 26.06.7에서 실제로 발표된 내용은 무엇인가
Core Lightning 26.06.7 공식 릴리스는 여러 출처가 책임 있게 보고한 취약점들을 수정했다고 밝힙니다. 다만 취약점 종류, 영향받는 기능, 공격 조건과 심각도는 아직 공개하지 않았습니다. “취약점이 있다”는 사실과 “내 노드가 실제로 공격받았다”는 판단은 같은 말이 아닙니다. 현재 공식 자료만으로 특정 자금 탈취나 채널 손실 시나리오를 단정해서는 안 됩니다.
프로젝트는 소스 코드를 릴리스 후 14일 동안 보류합니다. 이유는 수정 전후의 코드를 비교해 공격 방법을 역으로 찾는 시간을 늦추고, 운영자에게 먼저 패치할 창을 주기 위해서입니다. 이 기간에는 Linux용 사전 빌드 바이너리와 서명된 매니페스트를 배포합니다. 소스가 공개되면 미리 매니페스트에 기록된 소스 압축 파일의 해시와 대조할 수 있도록 약속값도 함께 남겼습니다.
Bitcoin Optech 뉴스레터 420호는 릴리스 직전 상황을 독립적으로 정리하면서, 알려진 실제 악용 사례는 없다고 전했습니다. 동시에 소스 공개를 기다리는 운영자에게는 --offline 플래그로 재시작하는 방법을 제시했습니다. 이 모드는 새 피어 연결과 지급·수신 같은 정상 영업을 멈추지만, 노드가 블록체인을 따라가며 기존 채널의 부정행위를 감시하는 기능은 유지하는 절충안입니다.
이번 업데이트가 모든 비트코인 사용자에게 해당하는가
아닙니다. 직접 대상은 Core Lightning, 줄여서 CLN으로 라이트닝 노드를 실행하는 운영자입니다. 일반 비트코인 지갑만 쓰거나 라이트닝 결제를 이용하더라도 서비스 사업자가 LND, Eclair, LDK 등 다른 구현체를 사용한다면 26.06.7 파일을 직접 설치할 일이 없습니다. “라이트닝 네트워크 전체가 같은 취약점에 노출됐다”는 표현도 현재 근거로는 맞지 않습니다.
먼저 관리 화면이나 터미널에서 노드 구현체와 버전을 확인해야 합니다. 직접 설치형 CLN이라면 lightning-cli getinfo의 버전 정보를 보고, Umbrel·Start9·RaspiBlitz·BTCPay Server 같은 통합 플랫폼을 이용한다면 해당 플랫폼의 앱 정보와 공식 업데이트 공지를 확인하세요. 통합 플랫폼은 파일 경로, 컨테이너 구성, 데이터 볼륨이 직접 설치와 다르므로 CLN 릴리스의 압축 명령을 그대로 복사하면 오히려 관리 환경을 깨뜨릴 수 있습니다.
업데이트 전에 무엇을 기록하고 백업해야 하나
업데이트 작업은 바이너리 교체보다 현재 상태를 되돌아볼 수 있게 기록하는 데서 시작합니다. 노드 버전, 설치 방식, CPU 아키텍처, 데이터 디렉터리, 플러그인 목록, 채널 수와 피어 연결 상태를 메모하세요. 중요한 채널 백업과 지갑 복구 자료가 최신인지도 확인해야 합니다. 복구 문구나 개인키를 온라인 메모, 채팅, 스크린샷에 남기라는 뜻은 아닙니다. 기존에 정한 오프라인 보관 절차가 실제로 작동하는지 확인하라는 의미입니다.
Core Lightning 공식 업그레이드 문서는 업그레이드 과정에서 데이터베이스가 바뀔 수 있고, 변경 뒤에는 일반적으로 이전 버전으로 되돌릴 수 없다고 경고합니다. 26.06.7 릴리스 노트는 별도의 수동 데이터베이스 마이그레이션 단계가 없고 시작 시 필요한 변경이 자동 적용된다고 설명하지만, 이것이 무조건적인 다운그레이드 보장을 뜻하지는 않습니다. 업데이트 직전 백업과 상태 기록이 필요한 이유입니다.
공식 파일과 CPU 아키텍처를 어떻게 구분하나
다운로드는 프로젝트의 GitHub 릴리스 페이지에 연결된 26.06.7 자산에서 시작해야 합니다. 검색 광고, 포럼의 재업로드 파일, 메신저 첨부 파일을 사용하지 마세요. 서버가 Intel·AMD 계열이면 보통 amd64, 64비트 Raspberry Pi나 ARM 서버라면 arm64 자산이 필요하지만, 이름만 보고 추측하지 말고 운영체제에서 uname -m 결과와 플랫폼 설명서를 함께 확인하는 편이 안전합니다.
이번 릴리스 시점에 Docker 이미지는 아직 준비되지 않았다고 공식 노트가 밝혔습니다. 따라서 Docker 사용자가 보이지 않는 태그를 추측해 당기거나, 출처를 알 수 없는 이미지를 대신 쓰면 안 됩니다. 통합 플랫폼의 공식 이미지가 나오기를 기다린다면 온라인 노드의 노출을 그대로 둘 것인지, 플랫폼이 제공하는 중지·오프라인 절차를 사용할 것인지 먼저 결정해야 합니다.
체크섬과 GPG 서명은 왜 둘 다 확인해야 하나
체크섬은 내려받은 파일이 매니페스트에 적힌 파일과 한 글자도 다르지 않은지 확인합니다. 하지만 공격자가 바이너리와 체크섬 파일을 함께 바꿨다면 체크섬만으로는 배포 주체를 확인할 수 없습니다. GPG 서명은 그 매니페스트가 프로젝트가 제시한 유지관리자 키로 서명됐는지를 추가로 확인합니다. 둘은 같은 검사가 아니라 “파일 무결성”과 “서명 주체”를 나눠 확인하는 절차입니다.
공식 릴리스가 안내한 amd64 검증 명령은 sha256sum -c SHA256SUMS-v26.06.7 --ignore-missing와 gpg --verify SHA256SUMS-v26.06.7.asc SHA256SUMS-v26.06.7입니다. ARM64는 별도 매니페스트와 서명 파일을 사용합니다. 단순히 명령이 종료됐다는 사실보다 대상 압축 파일이 OK로 표시되는지, GPG가 유효한 서명을 보고하는지, 키 지문이 공식 릴리스에 적힌 값과 일치하는지를 읽어야 합니다.
GPG의 “신뢰하지 않음” 경고와 “잘못된 서명”은 같은 상태가 아닙니다. 전자는 로컬 신뢰 모델에서 키 소유자를 얼마나 신뢰하는지에 관한 경고일 수 있지만, 후자는 파일이나 서명이 일치하지 않는다는 뜻입니다. 결과를 구분하기 어렵다면 설치를 멈추고 공식 문서와 사용 중인 플랫폼 지원 채널에서 확인하세요. 검증에 실패한 파일을 관리자 권한으로 압축 해제해서는 안 됩니다.
직접 설치형 노드는 어떤 순서로 업데이트하나
먼저 지급이나 채널 열기처럼 상태를 바꾸는 작업을 멈추고 백업이 끝났는지 확인합니다. 그다음 운영체제와 아키텍처에 맞는 공식 압축 파일, 체크섬, 서명 파일을 같은 작업 디렉터리에 내려받아 두 검증을 통과시킵니다. 공식 릴리스는 검증된 압축 파일을 기존 설치 위치에 풀고 lightningd를 재시작하도록 안내합니다.
그러나 sudo tar -xvf <release>.tar.xz -C /usr/local --strip-components=2라는 예시는 모든 환경의 정답이 아닙니다. 기존에 패키지 관리자, 컨테이너, Nix, 소스 빌드로 설치했다면 동일한 관리 방식을 유지해야 합니다. 설치 경로를 모르는 상태에서 /usr/local을 덮어쓰는 것은 중복 바이너리와 플러그인 불일치를 만들 수 있습니다.
재시작 후에는 버전이 26.06.7인지 확인하고, 로그에 데이터베이스·플러그인·비트코인 백엔드 오류가 없는지 봅니다. 이어서 블록 동기화 높이, 피어 연결, 활성 채널과 온체인 지갑 상태를 업데이트 전 기록과 비교하세요. 작은 시험 송금은 서비스 정책과 수수료를 확인한 뒤 마지막에 수행할 수 있지만, 버전과 노드 상태 확인을 대신하지는 않습니다.
소스 공개를 기다린다면 노드를 어떻게 두어야 하나
이번 선택에는 명확한 교환관계가 있습니다. 서명된 바이너리를 즉시 설치하면 공개되지 않은 수정 코드를 먼저 신뢰해야 하지만, 패치가 적용된 상태로 온라인 서비스를 이어갈 수 있습니다. 소스와 재현 빌드를 기다리면 코드를 검증할 기회가 생기지만, 패치 전 노드를 온라인에 두는 시간이 길어집니다.
Bitcoin Optech가 전한 대안은 --offline입니다. 이 옵션으로 재시작하면 CLN이 피어 연결을 만들거나 받지 않으므로 정상 결제 라우팅은 중단됩니다. 대신 기존 채널과 관련된 온체인 감시는 계속할 수 있습니다. 다만 통합 플랫폼에서 이 플래그를 어디에 넣는지, 재시작 시 다른 설정과 충돌하지 않는지는 플랫폼별로 다릅니다. 확인하지 않은 설정 파일을 수정하기보다 플랫폼의 공식 중지·복구 절차를 우선하세요.
14일 뒤에는 무엇을 다시 확인해야 하나
소스 공개 예정 시점은 릴리스일로부터 14일 뒤인 2026년 9월 중순 무렵입니다. 정확한 공개 시각은 프로젝트 공지를 다시 확인해야 합니다. 그때는 공개된 소스 압축 파일의 해시가 8월 28일 서명 매니페스트에 미리 기록된 값과 맞는지, 재현 빌드 지침과 취약점 설명이 무엇인지 확인할 수 있습니다.
이미 26.06.7을 설치한 운영자도 이 후속 확인이 필요합니다. 실제 영향 범위가 공개되면 로그 점검 범위, 노출 기간 중 의심 이벤트, 플러그인 또는 통합 플랫폼의 추가 조치가 구체화될 수 있기 때문입니다. 반대로 취약점 설명이 나오기 전 “자금이 안전하다”거나 “모든 채널을 닫아야 한다”는 단정은 피해야 합니다.
운영자가 지금 확인할 짧은 순서
- 내 노드 구현체가 Core Lightning인지, 현재 버전이 무엇인지 확인합니다.
- 직접 설치인지 통합 플랫폼인지 구분하고, 백업과 채널 상태를 기록합니다.
- 공식 26.06.7 릴리스 자산만 내려받고 CPU 아키텍처를 맞춥니다.
- SHA-256 체크섬과 GPG 서명·키 지문을 모두 확인합니다.
- 기존 설치 방식을 유지해 업데이트하고 재시작 뒤 버전·로그·피어·채널을 점검합니다.
- 바이너리 설치를 미룬다면 온라인 상태를 방치하지 말고
--offline또는 플랫폼의 공식 중지 절차를 검토합니다. - 소스와 취약점 설명이 공개되는 9월 중순에 공식 릴리스 페이지를 다시 확인합니다.
짧은 FAQ
일반 라이트닝 지갑 사용자도 26.06.7을 설치해야 하나요?
직접 CLN 노드를 운영하지 않는 일반 이용자는 설치 대상이 아닙니다. 이용 중인 지갑이나 결제 서비스가 어떤 노드 구현체를 쓰는지 알 수 없다면 서비스 운영자의 보안 공지와 업데이트 상태를 확인하세요.
GitHub의 자동 생성 Source code 압축 파일을 쓰면 되나요?
아닙니다. 공식 릴리스는 GitHub가 자동으로 만드는 소스 zip과 tar.gz가 26.06.7의 보류된 소스가 아니라고 경고합니다. 14일 뒤 프로젝트가 게시할 소스와 재현 빌드 지침을 기다려야 합니다.
업데이트하면 취약점 위험이 완전히 사라지나요?
26.06.7은 프로젝트가 확인한 문제를 고치지만, 세부 영향과 모든 운영 환경의 상태를 보증하지는 않습니다. 업데이트 뒤 버전·로그·채널을 확인하고, 취약점 공개 뒤 후속 조치가 있는지 다시 점검해야 합니다.
공식 출처
- ElementsProject, Core Lightning v26.06.7 공식 릴리스 — 2026년 8월 28일
- Core Lightning 공식 업그레이드 문서 — 2026년 8월 29일 확인
- Bitcoin Optech Newsletter #420 — 2026년 8월 28일
해외 공식자료와 국내 공지·보도를 교차 확인해 정리했으며 자료 조사와 초안 구성에 자동화 도구의 도움을 받았습니다.
본 글은 정보 제공 목적이며 투자 권유가 아닙니다. 암호화폐는 원금 손실 위험이 매우 큽니다.
댓글
댓글 쓰기