CVE-2026-123158: OpenSSH 비밀번호 인증 우회, 알파인 리눅스에 영향

OpenSSH의 높은 심각도의 취약점은 인증되지 않은 원격 공격자가 특정 Linux 시스템에서 너무 긴 암호를 제출하여 암호 인증을 우회할 수 있게 합니다. CVE-2026-123158로 추적되며 SSHhole이라고 불리며, 이 결함은 CVSS 3.1 점수가 8.1이며, 주로 sshd가 musl libc와 연결되어 PAM 없이 작동하는 Linux 환경에 영향을 미칩니다. Alpine Linux는 이 기본 설정을 사용하는 구성으로 인해 가장 두드러지게 영향을 받는 플랫폼입니다.

이 취약점은 OpenSSH 암호 검증과 musl libc의 crypt() 구현 간의 예기치 않은 상호작용에 기인합니다. 지나치게 긴 암호가 제공될 때, crypt()는 오류를 표시하기 위해 문자열 *을 반환할 수 있습니다. 일반적인 암호가 구성되어 있지 않은 Linux 계정 중 일부는 /etc/shadow의 암호 필드에 *을 저장하기도 합니다. 취약한 조건에서는 sshd가 일치하는 값을 성공적인 인증으로 잘못 해석할 수 있습니다.

공격자는 대상 사용자의 암호를 알 필요가 없습니다. 노출된 SSH 서비스가 필요한 조건을 충족한다면, 서비스에 도달할 수 있는 공격자는 취약한 길이 범위 내의 암호를 사용하여 특정 계정에 인증할 수 있습니다. 영향은 침해된 계정에 할당된 권한에 따라 달라집니다. 권한 있는 서비스 계정이나 doas 또는 다른 권한 상승 메커니즘을 사용할 수 있는 계정에 접근할 수 있다면, 시스템 전체가 침해될 수 있습니다.

영업 문의

OpenSSH는 2026년 11월 5일 출시된 Portable OpenSSH 10.6p2에서 이 문제를 해결했습니다. Alpine Linux는 동시에 모든 지원되는 브랜치와 여러 오래된 브랜치에 대한 패치된 OpenSSH 패키지를 출시했습니다. OpenSSH 팀은 이 출시가 musl libc를 사용하는 Linux 시스템에서 PAM이 비활성화된 경우에 대한 중요한 보안 해결책을 포함하고 있다고 설명합니다.

공공 재현 환경과 개념 증명 자료는 이미 이용 가능합니다. 그러나 2026년 11월 6일 현재 검토된 소스에서는 실제 공격에서 이 취약점이 확인된 악용은 보고되지 않았고, 이 결함은 CISA의 알려진 악용 취약성 목록에 추가되지 않았습니다.

조직은 SOC Prime의 AI-내장 탐지 지능 플랫폼을 통해 새로운 인증 우회 취약점에 대한 방어를 강화할 수 있으며, SIEM, EDR, XDR 및 데이터 레이크 환경 전반에서 위협 사냥 및 감지 엔지니어링을 가속화할 수 있습니다.

보안 팀은 Prime Architect를 사용하여 취약점 지능을 사냥 쿼리 및 사용 가능한 SSH, 인증, 엔드포인트 및 네트워크 원격 분석에 맞는 탐지 논리로 변환할 수도 있습니다.

CVE-2026-123158를 검출하기 위해 일반적으로 키 전용 인증을 사용하는 계정에 대한 성공적인 암호 기반 SSH 로그인을 모니터링하고, 비정상적으로 긴 암호를 사용하는 비정상적인 인증 시도, 서비스 계정에 대한 예기치 않은 원격 접근, 및 계정의 정상적인 행동과 일치하지 않는 인증 후 활동을 탐지합니다.

모든 CVE에 대해 탐지 콘텐츠가 제공되는 것은 아닙니다. 현재 적용 범위는 SOC Prime 플랫폼에서 확인하십시오. 관련 탐지가 아직 제공되지 않는 경우 새로운 위협 정보 및 탐지 콘텐츠가 지속적으로 추가되므로 다시 확인하십시오.

CVE-2026-123158 분석

CVE-2026-123158는 Linux에서 musl libc를 사용하며 PAM 없이 암호 인증이 발생하는 Portable OpenSSH 10.6p2 이전의 OpenSSH sshd에 영향을 미칩니다. 이 CVE는 AV:N/AC:H/PR:N/UI:N/S:U/C:H/I:H/A:H의 벡터로 CVSS 3.1 점수가 8.1로 설정되었으며, 이는 사전 권한이나 사용자 상호작용 없이 원격 악용이 가능하지만 특정 시스템 및 계정 구성이 필요함을 반영합니다.

근본 원인은 OpenSSH와 musl libc가 제공하는 암호 해싱 함수 간의 상호작용에 있습니다.

PAM이 비활성화된 시스템에서는 sshd가 시스템의 crypt() 기능을 사용하여 암호 검증을 수행합니다. 일반 계정의 경우 /etc/shadow에 암호 해시가 저장되어 있으며, 사용자가 제출한 암호로 생성된 값이 저장된 해시와 비교됩니다.

musl libc는 제공된 암호가 지원되는 입력 길이를 초과할 때 다르게 동작합니다. 256바이트를 초과하는 암호에 대해 crypt()는 정상적인 암호 해시 대신 오류 값으로 *을 반환합니다.

이 문제는 /etc/shadow에서 전통적인 암호가 구성되지 않은 계정에 *가 흔히 사용되기 때문에 발생합니다.

취약한 sshd가 이러한 계정에 대해 지나치게 긴 암호를 받으면, 인증 흐름은 crypt()가 반환한 *과 계정의 shadow 항목에 저장된 *을 효과적으로 비교할 수 있습니다. 값이 일치하면 인증이 잘못 성공할 수 있습니다.

CVE 설명에 따르면, 영향을 받는 계정 구성의 경우 256에서 1024 문자 사이의 암호가 성공적인 인증을 초래할 수 있습니다. 독립 재현은 정상적인 256바이트 경계를 초과하는 암호가 취약한 조건을 유발하는 데 충분하다고 설명합니다.

따라서 이 결함은 모든 OpenSSH 배포에 영향을 미치는 보편적인 암호 우회가 아닙니다.

여러 특정 조건이 맞아야 합니다.

첫째, 서버는 musl libc를 사용해야 합니다. Alpine Linux는 주요 주류 예제이며, 기타 임베디드 또는 최소한의 Linux 환경도 musl을 사용할 수 있습니다.

둘째, sshd는 PAM 없이 사용자를 인증해야 합니다. Alpine의 표준 openssh-server 패키지는 PAM 없이 빌드되며, 대안 openssh-server-pam 구성은 UsePAM이 활성화되어 있을 때 보호됩니다.

셋째, 암호 인증이 활성화되어 있어야 합니다. PasswordAuthentication yes는 관련 구성입니다. PasswordAuthentication no로 공공 키 전용 인증에 대한 시스템은 문서화된 공격 경로에 노출되지 않습니다.

마지막으로, 공격자는 암호 필드에 *가 포함된 계정이 필요합니다. 여기에는 키 전용 사용자, 암호 없이 생성된 계정, 디렉터리 서비스를 통해 제공된 일부 ID 및 특정 클라우드 이미지 사용자가 포함될 수 있습니다.

Alpine은 또한 하나 이상의 로컬 계정이 취약한 인증 경로가 설명된 대로 작동하기 위해 $5$ 또는 $6$ 스타일의 암호 해시를 포함해야 한다는 추가 조건을 언급합니다.

루트 계정은 특별한 주의를 요합니다. Alpine은 일반적으로 root:*을 저장하지만 OpenSSH의 PermitRootLogin prohibit-password 기본 설정은 루트에 대한 암호 인증을 직접 방지합니다. 결과적으로 표준 Alpine 설치는 이 버그를 통해 직접적인 루트 로그인을 자동으로 노출하지 않습니다.

그 보호책은 더 넓은 위험을 제거하지 않습니다. 암호 필드에 *가 있는 다른 계정이 원격으로 접근 가능하고 doas, sudo, 컨테이너 기능 등 권한 있는 메커니즘을 통해 관리 권한이 있는 경우, 성공적인 인증은 여전히 시스템 전체 침해의 경로를 제공할 수 있습니다.

Alpine의 공식 tiny-cloud 이미지는 특히 관련이 있습니다. 보안 연구에 의하면 alpine 계정이 취약한 조건을 충족할 수 있었고 또한 doas를 사용하여 권한을 상승시킬 수 있었습니다. 이는 수비자들이 계정 권한을 평가해야 하며 이 취약점이 모든 환경에서 무해한 사용자 접근을 제공하거나 자동으로 루트 접근을 제공하지 않는다는 점을 일깨워 줍니다.

Debian, Ubuntu, RHEL과 같은 glibc 기반의 Linux 배포판은 이 특정 취약점에 영향을 받지 않습니다. 왜냐하면 취약한 동작은 musl libc의 암호 해싱 구현에 의존하기 때문입니다. PAM을 SSH 암호 검증에 사용하는 시스템도 문서화된 취약한 구성 밖에 있습니다.

컨테이너도 유사한 검증이 필요합니다. Alpine은 널리 사용되는 컨테이너 베이스 이미지이지만 sshd를 실행하지 않는 일반적인 컨테이너는 이 공격 경로를 통해 취약해지지 않습니다. 주요 우려사항은 SSH 서버를 명시적으로 설치하고 노출하는 컨테이너, 어플라이언스, 개발 환경. 또는 레거시 워크로드입니다.

CVE-2026-123158 PoC 환경은 빠르게 개발되었습니다. 공공 재현 실험실은 취약점 기록에 직접 참조되어 있으며, 수비자들은 사설 익스플로잇 연구에 접근할 수 없어도 인증 우회를 재현할 수 있다고 가정해야 합니다. 확인된 악의적 악용이 아직 보고되지 않았더라도 이러한 사항이 수정 시급성을 유리하게 높입니다.

이 취약점은 Wakefield의 Özgün Kültekin에 의해 보고되었습니다. OpenSSH는 2026년 11월 5일 보안 해결책을 포함한 버전 10.6p2를 공개 릴리스했습니다. 검토된 주요 소스들은 연구자가 최초로 발견했거나 사적으로 보고했을 당시의 정확한 날짜를 명시하지 않았습니다.

OpenSSH 수정은 암호 인증 중 오류 값 및 잘못된 짧은 암호 해시가 수락되지 않도록 설계된 검증을 추가합니다. OpenSSH는 기본적인 원인이 sshd 외부에 존재한다고 보고 있지만, SSH 서버를 통해 악용될 수 있기 때문에 프로젝트 자체에 방어적인 해결책을 구현했습니다.

Alpine Linux는 여러 브랜치에 걸쳐 수정을 백포트했습니다:

Alpine 브랜치	수정된 OpenSSH 패키지
edge	10.6_p2-r0
3.24	10.3_p1-r2
3.23	10.2_p1-r1
3.22	10.0_p1-r11
3.21	9.9_p2-r1
3.20	9.7_p1-r6
3.19	9.6_p1-r3
3.18	9.3_p2-r4
3.17	9.1_p1-r7
3.16	9.0_p1-r6

관리자는 SSH 버전 배너만이 아닌 배포 패키지 상태를 신뢰해야 합니다. Linux 배포판은 상위에 표시된 OpenSSH 버전을 변경하지 않고도 보안 패치를 백포트하는 경우가 많습니다. 따라서 서버가 오래된 버전 문자열을 표시하더라도 이미 공급업체 수정을 포함하고 있을 수 있습니다.

CVE-2026-123158 탐지를 위해, 수비자는 SSH 인증 원격 분석을 우선적으로 처리해야 합니다. 특히 강력한 탐지 신호는 일반적으로 공개 키 인증만 사용하거나 의미 있는 암호를 구성하지 않은 계정에 대한 성공적인 암호 로그인입니다.

Alpine 시스템에서는 관리자들이 /var/log/messages, 중앙 집중식 인증 로그, SIEM 기록 또는 서비스, 키 전용, 관리 계정과 관련된 수락된 암호 이벤트를 사용 가능한 동등한 원격 분석을 검토할 수 있습니다.

수비자는 성공적인 인증을 소스 IP 주소, 로그인 시간, 세션 기간, 로그인 후 실행된 명령, 권한 상승, authorized_keys 변경, 계정 생성, 예약 작업 및 예기치 않은 아웃바운드 네트워크 연결과 상호 연관 시켜야 합니다.

네트워크 원격 분석 또한 노출된 시스템을 식별하는 데 도움을 줄 수 있습니다. 암호 또는 키보드 인터랙티브 인증을 광고하는 외부적으로 도달 가능한 SSH 서비스는 기저 시스템이 Alpine 또는 다른 musl 기반 디스트리뷰션일 때 특히 높은 수정 우선 순위를 받아야 합니다.

현재로서는 특정 캠페인 CVE-2026-123158 IOC 공격자 IP 주소, 도메인, 악성코드 해시, 명령 및 제어 인프라와 같은 것이 없습니다. 정적 지표의 부재는 SSH 인증 및 이후 세션 활동에 대한 행동 모니터링이 특히 중요한 이유입니다.

CVE-2026-123158 완화

주된 해결책은 OpenSSH 10.6p2 또는 Linux 배포판에서 제공한 수정된 패키지를 설치하는 것입니다. Alpine 관리자는 현재 패키지 저장소를 사용하여 전체 시스템을 업데이트하고 그 후에 sshd를 다시 시작해야 합니다. 패키지 자체를 업데이트하는 것만으로는 실행 중인 SSH 데몬 프로세스를 대체하지 않습니다.

Alpine 기반 컨테이너를 실행 중인 조직은 openssh-server를 설치한 이미지를 다시 빌드하고 다시 배포해야 합니다. 호스트 운영 체제를 단순히 업데이트하는 것은 컨테이너 이미지 내부에 임베디드된 취약한 OpenSSH 패키지를 패치하지 않습니다.

관리자는 모든 Alpine 호스트가 취약하다고 가정하기 전에 노출을 식별해야 합니다. 주요 점검 사항은 다음과 같습니다:

1. 호스트가 musl libc를 사용하는지 확인하십시오.
2. pam이 비활성화된 상태에서 sshd가 실행 중인지 확인하십시오.
3. 암호 인증이 활성 상태인지 확인하십시오.
4. /etc/shadow 암호 필드가 *인 로그인 가능 계정을 식별하십시오.
5. 해당 계정에 할당된 권한을 검토하십시오.
6. 배포판의 수정된 패키지 버전에 대해 설치된 OpenSSH 패키지를 확인하십시오.

즉각적인 패치가 불가능한 경우, 조직은 SSH 암호 인증을 비활성화해야 합니다.

구성:

PasswordAuthentication no

및, 해당되는 경우:

KbdInteractiveAuthentication no

관리자는 합법적인 관리 접근을 잃지 않기 위해 이 구성을 적용하기 전에 공개 키 인증이 작동하는지 확인해야 합니다.

그 후 SSH 구성을 검증하고 데몬을 다시 로드하거나 재시작해야 합니다. 그런 다음 외부 검증을 통해 서버가 공개 키 인증만 제공하는지 확인해야 합니다.

네트워크 접근성을 제한하는 것은 심층적인 방어를 추가로 제공합니다. SSH는 일반적으로 신뢰할 수 있는 관리 네트워크, VPN 인프라, 파수꾼 호스트 또는 명확한 소스 IP 허용 목록에서만 도달 가능해야 하며 인터넷에 보편적으로 노출되어서는 안 됩니다.

조직은 또한 컨테이너 내부에서 SSH가 정말 필요한지 다시 고려해야 합니다. 최신 오케스트레이션 환경은 일반적으로 docker exec 또는 kubectl exec과 같은 대안을 제공하여 필요 없는 원격 인증 서비스를 제거합니다.

노출될 수 있는 시스템의 경우, 수정 이전 발생한 히스토리적 성공 암호 로그인을 검토하십시오. 암호 없이 구성된 계정과 SSH 키로만 인증할 것으로 예상되는 ID에 특히 주의를 기울이십시오.

예기치 않은 성공 로그인이 확인된 경우, 그 계정을 잠재적으로 침해된 것으로 간주하십시오. 사용 가능한 경우 쉘 이력, 프로세스 실행, 권한 상승, 새롭거나 수정된 authorized_keys 항목, 사용자 및 그룹 변경, cron 작업, 시작 스크립트, 패키지 설치 및 아웃바운드 네트워크 연결을 검토하십시오.

침해된 계정에 접근 가능한 자격 증명 및 키는 잠재적으로 노출된 것으로 간주해야 하며, 조사 결과에 따라 교체해야 합니다. 계정에 관리 권한이 있었을 경우, 수비자는 전체 호스트 및 해당 자격 증명이 저장된 다른 시스템에 대한 조사로 확장해야 합니다.

공공 개념 증명 자료는 조직이 수정을 적용하기 전에 광범위한 공격증거를 기다릴 필요가 없음을 의미합니다. 악용 전제 조건은 취약 대상 인구를 좁히지만, 이러한 조건을 충족하는 시스템은 유효한 암호를 알지 못해도 원격으로 접근 가능합니다.