전 세계 수십만 대의 장비를 위협하는 CVE-2026-32746, 단 한 번의 연결로 루트 권한을 탈취할 수 있다면 어떤 일이 벌어질까요? 더 무서운 점은, 이 공격이 인증 이전(pre-auth) 단계에서 가능하다는 사실입니다. 즉, 공격자는 자격증명도, 사용자 상호작용도 없이 네트워크로 포트 23(Telnet) 에 접속하는 것만으로 서버를 장악할 수 있습니다.
CVE-2026-32746가 ‘즉시 대응’급인 이유
CVE-2026-32746는 GNU InetUtils의 telnetd에서 발견된 사전 인증 버퍼 오버플로우로, CVSS 9.8에 해당하는 최상위권 심각도 취약점입니다. 공격 조건이 까다롭지 않습니다.
- 단일 네트워크 연결로 공격 가능(포트 23)
- 인증 불필요
- 사용자 상호작용 불필요
- 특별한 네트워크 위치 요구 없음
telnetd는 운영 환경에서 inetd/xinetd에 의해 root 권한으로 실행되는 경우가 흔하기 때문에, 취약점 악용이 성공하면 결과는 곧바로 “원격 루트 코드 실행(RCE)”로 이어질 수 있습니다. 이는 단순 서비스 장애를 넘어 백도어 설치, 데이터 탈취, 내부망 피벗 등 연쇄 침해의 출발점이 됩니다.
CVE-2026-32746의 기술적 핵심: LINEMODE SLC 처리 버퍼 오버플로우
문제의 발단은 Telnet 확장 기능인 LINEMODE의 하위 옵션인 SLC(Set Local Characters) 처리 로직입니다. LINEMODE는 클라이언트가 로컬에서 라인 편집을 수행한 뒤 서버로 전송하도록 돕는 기능인데, telnetd는 초기 핸드셰이크 과정에서 SLC 값을 교환합니다.
취약점은 add_slc() 함수가 SLC 데이터를 내부 버퍼에 쌓는 과정에서 버퍼 경계 검사 없이 포인터(slcptr)를 증가시키며 값을 기록한다는 점입니다. 공격자가 SLC 관련 명령을 과도하게 많이 보내면, 버퍼를 넘쳐 인접 메모리를 덮어쓸 수 있고, 이 메모리 손상이 제어 흐름 장악으로 이어질 경우 원격 코드 실행이 가능합니다. 무엇보다 이 과정이 로그인 프롬프트 이전에 발생하므로, “계정이 없는 공격자”도 공격을 시도할 수 있습니다.
CVE-2026-32746의 영향 범위: 오래된 Telnet이 ‘현재진행형’인 곳
영향받는 버전은 GNU InetUtils 2.7 이하 전 버전으로 알려져 있습니다. Telnet은 현대 엔터프라이즈 환경에서는 퇴출된 프로토콜로 여겨지지만, 현실에서는 다음과 같은 영역에서 여전히 살아 있습니다.
- OT/ICS(산업 제어 시스템) 및 공장 네트워크
- 레거시 네트워크 장비/임베디드 기기
- 오래된 운영 절차에 묶인 원격 유지보수 채널
외부 노출된 포트 23 장비는 여전히 상당수 존재하며, 이런 환경에서는 “패치를 기다리는 동안”의 공백이 곧 실질적 침해로 이어질 수 있습니다. 특히 하드웨어 교체가 어렵거나 다운타임이 치명적인 산업 현장일수록, CVE-2026-32746 같은 취약점은 단순 경고가 아니라 즉각적인 운영 리스크입니다.
CVE-2026-32746 LINEMODE SLC, 원인은 어디에 있을까?
telnetd의 add_slc() 함수 안에서 경계 검사가 빠지면서 발생하는 치명적 버퍼 오버플로우—이 단순한 코드 한 줄이 어떻게 공격자의 무기가 되는지 살펴봅니다. CVE-2026-32746의 본질은 복잡한 암호학이나 인증 우회가 아니라, 옵션 처리 루틴에서 “얼마나 써도 되는지”를 확인하지 않은 채 메모리에 계속 써버린 것에 있습니다.
LINEMODE SLC가 무엇이고, 왜 위험해지나
Telnet의 LINEMODE는 “키 입력을 서버에 한 글자씩 보내지 말고, 클라이언트가 로컬에서 라인 편집을 한 뒤 전송하자”는 확장 기능입니다. 이때 클라이언트는 라인 편집에 필요한 특수키(예: erase, kill, interrupt 등)를 서버와 맞추기 위해 SLC(Set Local Characters) 정보를 주고받습니다.
문제는 여기서 끝나지 않습니다. SLC는 단일 값이 아니라 여러 항목(기능/플래그/값)을 연달아 보낼 수 있고, 서버는 이를 해석해 내부 버퍼에 “응답 패킷” 또는 “상태 구성” 형태로 누적해 담습니다. 공격자는 바로 이 지점을 악용해 초기 핸드셰이크 단계에서 과도한 SLC 데이터를 반복 전송하여, 서버가 준비한 버퍼 크기를 넘길 때까지 쓰기를 강제할 수 있습니다. 인증 이전(pre-auth) 단계에서 벌어지는 이유도 여기에 있습니다. Telnet 협상(Negotiation)은 로그인 프롬프트가 뜨기 전부터 시작되기 때문입니다.
add_slc()의 치명적 실수: “끝을 보지 않고 쓰기”
취약점이 있는 핵심 코드는 다음 구조를 가집니다(개념적으로 요약):
void add_slc (char func, char flag, cc_t val)
{
/* slcptr에 대한 경계 검사 없음 */
if ((*slcptr++ = (unsigned char) func) == 0xff)
*slcptr++ = 0xff;
if ((*slcptr++ = (unsigned char) flag) == 0xff)
*slcptr++ = 0xff;
if ((*slcptr++ = (unsigned char) val) == 0xff)
*slcptr++ = 0xff;
}
여기서 slcptr는 “지금 버퍼의 어디에 쓰고 있는지”를 가리키는 포인터입니다. 정상이라면 다음 조건이 항상 따라야 합니다.
- 쓰기 전에 남은 공간이 충분한지 확인
- 부족하면 중단하거나, 버퍼를 확장하거나, 에러 처리로 전환
하지만 add_slc()는 그런 방어가 전혀 없습니다. 그 결과, 공격자가 SLC 항목을 많이 보내면 slcptr++는 계속 진행하고, 결국 버퍼 바깥의 인접 메모리까지 덮어쓰기 시작합니다. 이것이 버퍼 오버플로우입니다.
0xFF 이스케이프가 “오버플로우를 더 빨리” 만든다
코드에는 == 0xff일 때 한 바이트를 추가로 쓰는 로직이 있습니다. Telnet 프로토콜에서 0xFF는 IAC(Interpret As Command)로 쓰이기 때문에, 데이터로 0xFF를 보내려면 이스케이프(보통 0xFF 0xFF)가 필요합니다. 즉, 특정 값이 들어오면 바이트를 1개가 아니라 2개 쌓게 됩니다.
- 평소: func/flag/val = 3바이트 누적
- 특정 입력(0xFF 포함) 시: 최대 6바이트까지 누적
경계 검사가 없는 상태에서 이 “추가 바이트”는 공격자가 오버플로우를 더 효율적으로 유도하는 데 도움이 됩니다. 결국 CVE-2026-32746는 단순한 포인터 증가(slcptr++)가 프로토콜 규칙(0xFF 이스케이프)과 결합하면서 파괴력이 커진 사례입니다.
왜 ‘사전 인증 원격 코드 실행’으로 이어질 수 있나
버퍼 바깥으로 쓰기가 발생하면, 다음과 같은 위험이 현실화됩니다.
- 인접한 상태 변수/포인터/길이 값이 손상되어 흐름이 비정상적으로 변경
- 스택/힙 구조에 따라 제어 흐름 탈취(ROP 등) 가능성 증가
- telnetd가 종종 root 권한으로 실행되는 배포 환경에서는, 성공 시 곧바로 시스템 장악으로 연결
핵심은 “로그인 전에 네트워크로 입력을 보내는 것만으로” 서버의 메모리를 덮어쓸 수 있다는 점입니다. 이 때문에 CVSS가 9.8 수준으로 평가될 만큼, 공격 난이도 대비 영향이 매우 큽니다.
정리: 한 줄의 부재가 만든 공격 표면
CVE-2026-32746은 “Telnet 자체가 낡았다”는 사실보다 더 중요한 교훈을 남깁니다. 프로토콜 협상처럼 항상 열려 있고, 항상 먼저 수행되는 코드 경로에서 경계 검사가 빠지면, 그 결함은 곧바로 사전 인증 RCE로 직결될 수 있습니다. 결국 공격자의 무기는 복잡한 트릭이 아니라, 개발자가 작성하지 않은 단 하나의 조건문—“남은 버퍼 길이 확인”입니다.
CVE-2026-32746 영향 범위와 핵심 공격 조건은?
사전 인증 상태에서도 가능한 원격 코드 실행, 인증 절차 없이 포트 23 하나만 열려있으면 위협에 노출되는 현실—당신의 시스템은 안전할까요? CVE-2026-32746의 위험은 “Telnet을 쓰고 있느냐”를 넘어, “Telnetd가 외부 입력을 어디까지 신뢰하느냐”에서 시작됩니다.
영향 범위: “GNU InetUtils telnetd를 쓰는가”가 핵심
- 영향받는 버전: GNU InetUtils 2.7 이하의 telnetd 전 버전이 대상입니다.
- 노출 지점: Telnet 서비스(일반적으로 TCP 23)가 네트워크에 열려 있고, 해당 서비스가 GNU InetUtils의 telnetd로 구동되는 환경.
- 권한 위험도 상승 요인: telnetd는 관행적으로
inetd/xinetd를 통해 root 권한으로 실행되는 경우가 많아, 취약점이 악용되면 곧바로 root 권한 RCE로 이어질 가능성이 큽니다.
특히 “이미 죽은 프로토콜”로 여겨지는 Telnet이 OT/ICS, 레거시 임베디드 장비, 오래된 운영 네트워크에서 계속 쓰이는 현실 때문에, 패치가 어렵거나 서비스 중단이 불가능한 곳일수록 실제 피해 확률이 올라갑니다.
핵심 공격 조건: 단일 연결·무인증·무상호작용
CVE-2026-32746이 치명적인 이유는 공격자가 로그인 화면에 도달하기도 전에 메모리를 깨뜨릴 수 있기 때문입니다. 공격 조건을 정리하면 다음과 같습니다.
- 단일 네트워크 연결만으로 공격 가능
- 인증 불필요(Pre-auth): 자격증명 없이도 취약점 트리거 가능
- 사용자 상호작용 불필요: 클릭, 승인, 입력 유도 같은 단계가 없음
- 특별한 네트워크 위치 불필요: 외부에서 포트 23에 도달 가능하면 조건 성립
즉, “계정이 없어서 안전하다”, “배너만 뜨고 로그인은 안 했으니 괜찮다” 같은 방어 심리는 여기서 통하지 않습니다.
왜 ‘사전 인증 RCE’가 가능한가: LINEMODE SLC 버퍼 오버플로우의 구조
공격이 성립하는 타이밍은 Telnet 연결 직후의 프로토콜 옵션 협상(핸드셰이크) 단계입니다. CVE-2026-32746은 이 과정에서 LINEMODE의 SLC(Set Local Characters) 옵션을 처리할 때, add_slc()가 내부 버퍼에 값을 쓰면서도 경계 검사를 하지 않는 설계 결함에서 발생합니다.
공격자는 다음과 같은 흐름으로 악용을 시도할 수 있습니다.
- 포트 23으로 연결(인증 이전)
- LINEMODE 협상 과정에서 과도한 SLC 명령/항목을 전송
- telnetd가 SLC 항목을 버퍼에 누적 기록하는 중
slcptr가 버퍼 끝을 넘어감 - 인접 메모리가 덮이면서 프로세스 제어 흐름이 손상
- 조건이 맞으면 원격 코드 실행(RCE)로 이어질 수 있음
핵심은 “로그인 이후 처리 루틴”이 아니라, 연결만 되면 곧바로 진입하는 협상 루틴에서 터진다는 점입니다. 그래서 방화벽에서 23을 열어 둔 순간, 공격 표면이 크게 확장됩니다.
실제 운영 관점에서의 의미: “열려 있으면 공격이 온다”
- 인터넷에 직접 노출된 Telnet은 자동 스캐닝/웜형 공격의 표적이 되기 쉽습니다.
- 내부망이라도, 침해된 단말 1대가 들어오면 동서(East-West) 이동 과정에서 Telnet 장비가 다음 희생양이 될 수 있습니다.
- root로 실행되는 경우가 많아, 1회 성공이 곧바로 전체 시스템 장악으로 번질 수 있습니다.
정리하면, CVE-2026-32746의 “영향 범위”는 단순히 취약한 버전 목록이 아니라, Telnetd가 실행 중이고 23번 포트가 닿는 곳 전체입니다. 그리고 “핵심 공격 조건”은 놀랄 만큼 단순합니다. 연결만 가능하면, 인증 없이도 시작될 수 있습니다.
CVE-2026-32746가 드러낸 OT/ICS 환경의 어두운 그림자
Telnet은 많은 IT 조직에서 이미 “죽은 프로토콜”로 분류됩니다. 하지만 OT/ICS 현장에서는 이야기가 다릅니다. 장비 교체 주기가 길고, 인증·암호화보다 가용성이 우선되는 문화, 그리고 수십 년간 이어진 운영 관성 때문에 포트 23(Telnet) 은 여전히 곳곳에서 살아 있습니다. 바로 이 지점에서 CVE-2026-32746 같은 결함은 단순한 취약점이 아니라, 현장의 안전과 생산을 흔드는 현실적 위협이 됩니다.
왜 OT/ICS에서 Telnet이 더 위험한가: CVE-2026-32746의 전제 조건
CVE-2026-32746의 핵심은 “Telnet을 쓰는 환경” 그 자체가 공격 표면이 된다는 점입니다. 이 취약점은 GNU InetUtils telnetd가 LINEMODE의 SLC(Set Local Characters) 옵션을 처리하는 과정에서 버퍼 경계 검증 없이 값을 누적해 쓰면서 발생합니다. 공격자는 로그인 화면이 뜨기도 전에, 즉 사전 인증(pre-auth) 단계에서 과도한 SLC 서브옵션을 밀어 넣어 버퍼를 넘치게 만들 수 있습니다.
OT/ICS 관점에서 특히 치명적인 이유는 조건이 너무 간단하기 때문입니다.
- 단일 네트워크 연결만으로 시도 가능(포트 23 접근)
- 인증 불필요, 사용자 상호작용 불필요
- 많은 배포 환경에서 telnetd가 inetd/xinetd를 통해 root 권한으로 실행되는 관행
결과적으로 “운영망에 접근만 가능하면” 공격자는 원격 코드 실행(RCE) 을 노릴 수 있고, 성공 시 영향은 단순 서버 침해를 넘어 설비 제어망 전반으로 확장될 수 있습니다.
‘취약점 드리프트’가 OT/ICS에서 더 무섭다: CVE-2026-32746의 11년 공백
이 이슈가 주는 가장 불길한 메시지는, 결함이 오랫동안 눈에 띄지 않을 수 있다는 점입니다. CVE-2026-32746은 2015년에 추가된 코드에서 비롯되어 약 11년간 발견되지 않았고, 과거 BSD 계열 telnet 데몬에서 발견된 유사 취약점(CVE-2001-0554)과 닮았습니다. 즉, “이미 한 번 겪어본 유형의 실수”가 시간이 지나며 다른 코드베이스에서 다시 나타나는 취약점 드리프트(vulnerability drift) 현상입니다.
OT/ICS 환경은 이 드리프트를 더 증폭시킵니다.
- 장비/펌웨어 교체 비용이 크고 유지보수 창이 제한적이라 패치 적용이 늦어지기 쉽고
- 레거시 프로토콜이 남아 있어 취약 코드가 오래 생존하며
- 외부 스캔(예: Shodan)으로 포트 23이 드러나는 순간, 공격자는 “오래된 표적”을 “쉬운 표적”로 바꿔버립니다.
공격 시나리오 관점: CVE-2026-32746이 만드는 연쇄 피해
OT/ICS에서 telnetd가 뚫린다는 것은 단지 한 대의 장비가 위험해진다는 뜻이 아닙니다. 공격자는 초기 foothold를 확보한 뒤 다음 단계를 밟기 쉽습니다.
- root 권한 RCE로 시스템 장악
- 계정/키/설정 파일 등 민감정보 수집 및 횡적 이동
- 현장 운영에 맞춘 지속성(백도어) 심기
- 설비 모니터링 무력화, 로그 조작 등으로 탐지 회피
- 제어망 내부 자산으로 피벗하여 운영 중단, 품질 저하, 안전 리스크로 확장
Telnet은 본질적으로 평문 통신이고, 세션 무결성 보호도 약합니다. 여기에 CVE-2026-32746처럼 인증 이전 RCE 가능성이 결합되면, “레거시 유지”가 곧 “침해 가능성 상시화”가 됩니다.
결론: CVE-2026-32746은 ‘레거시 부채’가 비용이 되는 순간을 보여준다
OT/ICS에서 Telnet은 과거의 편의가 아니라 현재의 부채입니다. CVE-2026-32746은 “프로토콜이 구식이라서 위험한 것”을 넘어, 구식 프로토콜이 살아남는 구조 자체가 얼마나 큰 공격 기회를 만들 수 있는지 보여줍니다. 특히 패치가 지연되거나 적용이 어려운 현장일수록, Telnet의 잔존은 단순한 기술 선택이 아니라 리스크 선택이 됩니다.
CVE-2026-32746 실전 대응 전략과 미래 전망
정식 패치가 나오기 전까지는 “취약점이 있는 서비스를 어떻게 안전하게 운영 중단 없이 줄이느냐”가 핵심입니다. 특히 CVE-2026-32746은 사전 인증(pre-auth) 단계에서 단일 연결만으로도 버퍼 오버플로우를 유발할 수 있어, 방치하면 원격 코드 실행(RCE)로 직결됩니다. 아래는 현장에서 즉시 적용 가능한 우선순위 기반 대응 체크리스트와, 이 사건이 남긴 구조적 교훈입니다.
CVE-2026-32746 패치 전 즉시 적용할 “필수” 완화 대책(우선순위)
1) Telnet 비활성화가 최우선(가능하면 즉시)
- telnetd 중지/제거가 가장 확실합니다. Telnet은 암호화가 없고, 이번처럼 구현 결함이 터지면 방어 난이도가 급상승합니다.
- 운영 중단이 어렵다면, 아래의 네트워크·권한·모니터링 조치를 동시에 적용해 위험을 분산해야 합니다.
2) 포트 23 차단 및 접근 경로 최소화(“보이는 것” 자체를 줄이기)
- 경계 방화벽/ACL에서 23/TCP 차단: 외부에서 들어오는 스캔과 무차별 공격을 1차로 차단합니다.
- 내부도 예외가 아닙니다. OT/ICS에서는 내부 침해 후 동서 트래픽으로 telnetd가 노려질 수 있으므로,
- 텔넷이 필요한 관리망/VPN 대역만 허용(Allowlist),
- 나머지는 모두 차단(Deny by default) 형태가 바람직합니다.
- 가능하면 점프 서버(바스천) 단일 진입점으로 Telnet 접근을 강제해 노출 면을 줄이세요.
3) Root 권한으로 실행 회피(성공해도 “피해 반경”을 줄이기)
CVE-2026-32746의 치명점은 telnetd가 종종 root로 실행된다는 운영 관행과 결합될 때 폭발합니다. 패치 전까지는 최소한 다음을 검토해야 합니다.
- root 실행 회피: inetd/xinetd 또는 서비스 유닛에서 권한 분리를 적용합니다(가능한 범위 내에서).
- 격리 강화:
- chroot, 컨테이너, 네임스페이스 격리 등으로 파일시스템과 프로세스 권한을 제한
- SELinux/AppArmor 정책으로 telnetd의 파일/네트워크 접근 범위를 최소화
- “원격 RCE 가능” 취약점의 대응에서 권한 분리는 선택이 아니라, 패치 전 “생존 전략”에 가깝습니다.
4) 프로토콜 차원의 위험을 인정하고 “대체 경로” 마련
- Telnet이 꼭 필요했던 이유(레거시 장비, 자동화 스크립트, 운영 절차)를 분해해,
- SSH로 대체하거나,
- 장비가 SSH를 지원하지 않으면 시리얼 서버/전용 관리망/벤더 안전 채널로 우회하는 설계를 준비해야 합니다.
- 단기적으로는 “텔넷을 살려두되 안전하게”가 목표일 수 있지만, 중장기적으로는 “텔넷을 없애는” 로드맵이 필요합니다.
CVE-2026-32746 공격 징후를 잡아내는 네트워크 모니터링/탐지 포인트
CVE-2026-32746은 초기 핸드셰이크에서 과도한 LINEMODE SLC 옵션을 던져 버퍼를 넘치게 만드는 형태가 핵심입니다. 따라서 패치 전에는 “차단”과 함께 “가시성 확보”가 필수입니다.
1) 패킷 캡처 및 IDS/IPS 룰링(행위 기반 감시)
- 텔넷 세션의 IAC(0xFF) 기반 옵션 협상이 비정상적으로 길어지거나 반복되는지 관찰하세요.
- LINEMODE(SB … SE) 및 SLC 관련 서브옵션이 과도하게 등장하는 흐름은 경보 대상으로 삼을 가치가 큽니다.
- 가능하면 IPS에서 텔넷 옵션 협상 크기/빈도 제한 또는 텔넷 자체 차단 정책을 적용하세요(운영 영향도 테스트 후).
2) 로깅: “연결”이 아니라 “세션 특성”을 남기기
- 방화벽/라우터: 23/TCP 연결 시도, 허용/차단 이벤트를 중앙 수집
- 서버 측: telnetd 크래시(core dump), 비정상 종료, 재시작 이벤트
- 중요한 포인트는 반복 크래시/재기동입니다. 버퍼 오버플로우 시도는 성공/실패와 무관하게 서비스 불안정(DoS) 징후로 먼저 드러날 수 있습니다.
3) OT/ICS 환경의 현실적 권고: “탐지 가능한 경계” 만들기
OT망은 변경이 어렵고 가시성이 낮은 경우가 많습니다. 그래서 다음이 실무적으로 효과적입니다.
- 텔넷이 존재하는 구간을 스위치 미러링/SPAN으로 수집 포인트에 연결
- 수집된 트래픽을 중앙 로그 저장소(SIEM)로 모아 상관분석
- 텔넷 장비를 자산 목록에서 분리해 집중 모니터링 그룹으로 운영
CVE-2026-32746이 남긴 교훈과 미래 전망(“취약점 드리프트”의 재발 방지)
1) 오래된 프로토콜은 “죽지 않았다”—기술 부채는 이자로 돌아온다
Telnet은 현대 IT에서 퇴출된 것처럼 보이지만, OT/ICS·레거시 임베디드에서는 여전히 흔합니다. CVE-2026-32746은 “안 쓰는 줄 알았던 코드”가 실제로는 광범위하게 노출되어 있고, 패치·교체가 느린 환경일수록 공격 성공 확률이 올라간다는 점을 상기시킵니다.
2) 입력 검증 부재는 세월이 지나도 반복된다
이번 결함의 본질은 단순합니다. 경계 검사 없는 버퍼 쓰기와 사전 인증 경로의 결합입니다. 유사한 유형의 결함이 과거에도 반복되었고, 앞으로도 재발합니다. 재발을 줄이려면:
- 네트워크 데몬의 옵션 파서/협상 로직에 대해 퍼징(fuzzing)을 정례화
- 컴파일러 보호기법(스택 보호, FORTIFY, ASLR 등)과 하드닝 옵션을 기본값으로
- “레거시 서비스는 예외”라는 운영 관행을 폐기하고, 예외일수록 더 강한 통제를 적용해야 합니다.
3) 전망: 패치 이후에도 “운영 설계”가 남는다
정식 패치가 배포되더라도, 다음 질문이 남습니다.
- 패치를 언제, 어떤 순서로, 어떤 다운타임으로 적용할 것인가?
- 패치가 불가능한 장비는 어떻게 격리할 것인가?
- Telnet을 완전히 제거하기 위한 대체 아키텍처는 준비되어 있는가?
결국 CVE-2026-32746 대응의 종착점은 “패치 적용”이 아니라, Telnet 의존성을 해소하고 권한·네트워크·관측성을 기본 설계로 끌어올리는 것입니다. 패치 전에는 완화로 시간을 벌고, 패치 후에는 제거와 재발 방지로 구조를 바꾸는 것이 가장 현실적인 승리 시나리오입니다.
