OpenSSH *sshole CVE-2026-123158, 공개 9시간 안에 야생 악용 관측

OpenSSH *sshole(CVE-2026-123158)의 야생 악용이 보도됐다. Alpine Linux와 OpenSSH를 실행한 허니팟에서는 root 접근 성공도 확인됐다.[1][2]

Ubuntu·Debian·Fedora처럼 glibc를 쓰는 호스트는 이번 OpenSSH 인증 우회의 영향을 받지 않는다. 다만 Ubuntu 위에서 실행하는 Alpine 컨테이너까지 같은 결론을 적용하면 안 된다. Alpine 기반 컨테이너와 클라우드 AMI, tiny-cloud 인스턴스 중 sshd가 실행되는 환경을 따로 추려야 한다.[4][6]

달라진 것은 악용 확인 상태다. 11월 6일 공개한 선행 글에서는 확인하지 못했던 CVE 번호와 실제 공격 관측이 같은 날 후속 보도에 나왔다. 이제는 노출된 실행 환경을 찾고, 패치·재시작·로그 점검을 각각 마쳤는지 확인해야 한다.[1][2][3]

후속 보도는 CVE-2026-123158의 야생 악용과 Alpine·OpenSSH 허니팟의 root 접근 성공을 다뤘다. CVE 공개 후 9시간 미만이라는 수치는 첫 악용 시도까지의 시간이지 root 성공까지 걸린 시간이 아니다.[1][2]
대응 순서는 Alpine 실행 환경 인벤토리, 영향 조건 확인, 수정 패키지 적용, sshd 재시작, 로그인 기록 점검이다. 업데이트만 했거나 버전만 확인한 상태를 조치 완료로 처리하지 말자.[4]

이전 글 이후 무엇이 확인됐나?

CVE-2026-123158이 부여됐고 실제 악용 시도와 허니팟 침입 성공이 보도됐다. The Hacker News가 제시한 CVSS 점수는 8.1이다. [1][2]

선행 글은 2026년 11월 6일 11:32 KST에 확인한 공식 공지와 메일을 기준으로 실제 악용 사례와 이후 CVE 배정 여부를 확인하지 못했다고 썼다. 이는 “악용이 없다”는 단정이 아니었다. 이번 후속 글은 같은 날인 11월 6일 Help Net Security와 The Hacker News의 보도로 새로 확인된 내용을 반영한다.[1][2][3]

확인 항목	선행 글 당시	후속 보도 반영
CVE·악용	배정·실제 악용 미확인	CVE 번호·허니팟 침입 보도
관리자 조치	패치와 sshd 재시작	같은 조치에 침해 흔적 점검 병행

출처 확인 기준은 2026년 11월 7일 01:34~01:43 KST다. Help Net Security는 보도 당시 CISA KEV 목록에 아직 포함되지 않았다고 설명했다. 이는 해당 기사 시점의 상태이며, 현재 CISA 공식 목록을 직접 조회한 결과라는 뜻은 아니다.[1]

9시간과 8회는 어디까지 확인된 수치인가?

9시간 미만은 CVE 공개부터 Previdian이 첫 악용 시도를 관측하기까지의 시간이고, 8회는 한 센서에서 잡힌 시도 수다. Previdian은 실제 Alpine Linux와 OpenSSH를 실행한 허니팟에서 root 접근 성공도 확인했다고 밝혔다. root 접근 성공까지 걸린 시간은 이번 보도로 확인할 수 없다.[1][2]

관측 출발지 IP는 89.116.89.18이며, 보도에서 일본으로 지리 분류된 주소다. IP의 위치 분류는 공격자의 국적을 뜻하지 않는다. 같은 주소에서 나온 8회 관측을 전체 피해 서버 수나 전 세계 공격 규모로 읽어서도 안 된다.[1]

보도는 과도하게 긴(oversized) 비밀번호를 이용한 인증 우회와 함께, 비대화형 SSH 세션에서 id·uname·hostname이라는 정찰 명령이 관측됐다고 설명한다.[1][2] 관리자에게 필요한 것은 이를 재현하는 일이 아니라 자신의 환경에서 허용되지 않아야 할 로그인이 있었는지 확인하는 일이다.

투명 실험 서버의 인증 관문을 통과해 붉은 코어로 이어지는 광섬유 띠를 상단 센서가 관측하는 개념도 — 개념 일러스트(daily-it.com 자체 제작)

Ubuntu 다음에는 어떤 자산을 찾아야 하나?

Ubuntu 호스트와 분리해 Alpine 기반 실행 환경에서 sshd와 인증 구성을 확인해야 한다. 인벤토리는 호스트 운영체제 이름만 적는 대신 컨테이너, AMI 인스턴스, tiny-cloud 이미지별로 나누고 실제 SSH 서버 실행 여부를 기록하면 된다. 컨테이너 안에서 sshd를 실행하지 않는다면 이번 우회의 대상이 아니다.[4]

영향 조건은 musl 기반 Linux, PAM을 사용하지 않는 sshd, PasswordAuthentication yes가 함께 있는 경우다. 여기에 SSH 포트로 접근할 수 있고, 비밀번호 필드가 정확히 *인 대상 계정과 $5$ 또는 $6$ 비밀번호 해시를 가진 다른 로컬 계정이 하나 이상 있어야 한다. 정상적인 비밀번호 해시가 있는 계정의 비밀번호를 모두 무력화하는 문제는 아니다.[2][4]

Alpine의 openssh-server는 PAM 없이 빌드된다. openssh-server-pam을 설치했더라도 UsePAM no로 실행하면 제외할 수 없고, UsePAM yes로 비밀번호 인증을 처리하는 구성은 영향 밖이다. PasswordAuthentication no인 환경도 제외된다. shadow 필드가 !로 잠긴 계정은 이번 우회 대상이 아니다. 다만 !인 계정 하나가 있다고 서버의 다른 계정까지 안전해지는 것은 아니다.[3][4]

tiny-cloud는 초기 부팅 상태와 운영 중 상태를 구분해야 한다. Alpine 공지는 해당 구형 이미지의 alpine 계정과 비밀번호 없는 doas 구성을 설명하면서도, 최초 부팅 때는 안전하고 이후 로컬 비밀번호 해시가 생기면 위험 조건이 성립할 수 있다고 안내한다. 이미지 배포 당시의 상태만 보지 말고 사용자 추가나 콘솔 비밀번호 설정 이후의 현재 구성을 확인해야 한다.[4]

OpenWrt·Buildroot·Yocto도 보도에 등장하지만, Alpine 패키지 표를 그대로 적용할 대상은 아니다. 해당 환경은 musl·PAM·sshd와 계정 조건을 별도로 확인해야 한다.[1]

허니팟에서 root에 접근했다면 모든 서버도 같은가?

아니다. root 접근 성공은 해당 허니팟에서 확인된 결과이며 모든 기본 설정의 Alpine 서버에서 root 직접 로그인이 된다는 뜻은 아니다. OpenSSH의 기본 PermitRootLogin prohibit-password는 root의 직접 비밀번호 접속을 제한한다. Alpine 공지는 직접 root 접속이 가능한 조건을 PermitRootLogin yes로 구분한다.[1][4]

다만 다른 계정의 로그인이 가능하고 그 계정에 root로 권한을 높일 수단이 있다면 위험은 남는다. 따라서 root 직접 접속 설정만 보고 점검을 끝내지 말고, alpine과 키 전용 운영 계정의 인증 상태 및 doas 권한도 함께 봐야 한다. 허니팟에서 확인된 결과와 각 서버의 실제 권한 구성을 구분해야 한다.[2][4]

패키지를 올렸다면 조치는 끝난 것인가?

아니다. 수정 패키지 적용 뒤 실행 중인 sshd를 재시작해야 한다. OpenSSH는 2026년 11월 5일 10.6p2를 공개했고, Alpine 안정 브랜치는 같은 문제의 수정 패키지를 제공한다. 업스트림 버전 숫자 하나만으로 판정하지 말고 Alpine 공식 공지와 선행 글의 브랜치별 Fixed openssh 표에 맞춰 비교하자.[3][4][5]

Alpine 공식 공지의 업데이트와 OpenRC 재시작 명령은 다음과 같다. OpenRC가 아닌 환경은 해당 프로세스 관리 방식에 맞춰 sshd를 재시작해야 한다.[3][4]

apk upgrade -U -a
rc-service sshd restart

아래 두 줄은 설치 패키지와 호출한 sshd의 버전을 확인하는 보조 명령이다. 실행 중인 데몬이 새 바이너리로 바뀌었다는 확인을 대신하지는 못한다.[3]

apk info -v openssh
sshd -V

운영 작업표에서도 “수정 패키지 확인”과 “sshd 재시작 확인”을 별도 항목으로 기록하자. 패키지 업데이트만으로 기존 데몬이 교체되지 않기 때문이다. 여기에 로그 검토 결과까지 따로 남기면 패치 완료와 침해 여부 확인이 섞이지 않는다.[4]

왼쪽의 부품 교체, 중앙의 실행 코어 교체, 오른쪽의 기록판 점검과 별도 완료 램프를 보여 주는 정비 모형 — 개념 일러스트(daily-it.com 자체 제작)

바로 패치할 수 없으면 무엇을 바꿔야 하나?

sshd 설정에서 비밀번호 인증을 끄고 sshd를 재시작해야 한다. 실제 설정 문법은 PasswordAuthentication no다. Damien Miller의 긴급 공지도 musl을 쓰면서 PAM을 사용하지 않는 Linux에 즉시 완화하거나 SSH를 비활성화하라고 요청했다.[4][6]

먼저 키로 새 로그인이 되는지 확인하고, 현재 접속 세션을 유지한 채 변경해야 한다. 설정 적용과 재시작 뒤에도 새 키 접속을 확인하기 전에는 기존 세션을 닫지 말자. 설정 파일을 저장한 것과 실행 데몬에 반영한 것은 별개의 단계다.[4]

Alpine 공지는 구형 릴리스에서 drop-in 디렉터리를 읽지 않는 차이와 Match 블록의 설정도 다룬다. 파일 하나를 추가했다는 사실만으로 모든 접속 조건에 적용됐다고 보지 말고, 자신의 릴리스와 구성에 맞춰 공식 안내를 확인해야 한다.[4]

점형 입력 경로의 금속 셔터는 닫고 열쇠가 놓인 독립 통로는 열어 둔 임시 완화 조치의 개념도 — 개념 일러스트(daily-it.com 자체 제작)

로그에서는 어떤 기록부터 확인해야 하나?

/var/log/messages에서 비밀번호 로그인이 없어야 할 계정의 Accepted password for 기록부터 확인해야 한다. Alpine 공지는 alpine·root·키 전용 계정을 예로 들며, doas 사용과 최근 생성된 사용자·파일·authorized_keys도 검토하라고 안내한다.[4]

중요한 것은 성공 기록의 계정이 실제로 비밀번호 인증을 허용하던 계정인지다. 키 전용이라고 관리하던 계정에서 비밀번호 로그인 성공이 보였다면 정상적인 접속으로 넘기지 말고 조사해야 한다. 로그인을 배제할 수 없다면 침해된 머신으로 취급하라는 것이 Alpine의 지침이다. 패치를 마쳤다는 사실만으로 과거의 접속 여부까지 해결되지는 않는다.[4]

GitHub에 공개된 PoC는 미검증이며 악성코드가 포함될 수 있다는 경고가 있다. 운영 서버에서 이를 실행해 안전 여부를 시험하는 대신, 공식 수정 패키지와 실제 설정, 재시작 여부, 로그인 기록을 확인하는 데 집중하자.[1]