AWS IoT Device SDK for Python CVE-2026-92943 보안 이슈, AWS IoT Core 호스트명 불일치 인증서 검증 누락
AWS가 AWS IoT Device SDK for Python의 MQTT TLS 연결 계층에서 서버 인증서와 AWS IoT Core 엔드포인트 호스트명의 일치 여부를 확인하지 않는 취약점 CVE-2026-92943를 공개했다. 이 문제는 Python 3.7 이상에서 동작하는 영향 버전에 해당하며, 네트워크 경로상에 위치한 공격자가 다른 호스트명으로 발급된 인증서를 제시해 AWS IoT Core를 가장할 수 있다는 점이 핵심이다.
영향 범위와 공격 시나리오
영향받는 범위는 AWS IoT Device SDK for Python 1.5.3 이상 1.6.0 이하이며, 조건은 Python 3.7 이상이다. 취약점은 MQTT 클라이언트의 TLS 연결 처리에서 서버 인증서가 실제 접속 대상인 AWS IoT Core 엔드포인트와 일치하는지 검증하지 않는 데서 발생한다.
AWS 설명에 따르면 공격자가 네트워크 중간자 위치에 있을 경우, 디바이스 신뢰 저장소가 신뢰하는 인증기관이 발급한 다른 호스트용 인증서를 제시해 AWS IoT Core 엔드포인트를 사칭할 수 있다. 이 경우 디바이스 텔레메트리 열람과 함께, 디바이스가 정상으로 받아들일 수 있는 임의 MQTT 메시지 주입 위험이 생긴다.
어떤 접속 경로가 영향받는가
영향을 받는 기본 연결 경로는 두 가지다. 하나는 8883 포트의 X.509 상호 인증 경로이고, 다른 하나는 443 포트의 SigV4 기반 WebSocket 경로다.
반면 443 포트의 ALPN 경로는 영향받지 않는다고 AWS가 명시했다. 따라서 운영 환경에서 동일한 SDK를 쓰더라도 실제 연결 방식에 따라 우선 점검 대상이 달라질 수 있다.
운영자가 바로 확인할 항목
우선 Python 런타임이 3.7 이상인지, 그리고 애플리케이션 또는 게이트웨이 이미지에 AWSIoTPythonSDK 1.5.3 이상 1.6.0 이하가 포함되어 있는지 확인할 필요가 있다. 특히 현장 단말, 게이트웨이, 테스트 장비, 내부 배포용 표준 이미지에 동일 SDK가 남아 있는지 함께 점검하는 편이 효율적이다.
다음으로 실제 사용 중인 접속 경로가 8883 포트 X.509 상호 인증인지, 443 포트 WebSocket with SigV4인지 구분해 영향 범위를 좁혀야 한다. 443 ALPN 경로만 사용하는 환경이라면 이번 공지 기준 직접 영향 대상은 아니다.
원문에는 수정 버전이 제시되지 않았으므로 특정 패치 버전을 단정해 적용 목록을 만들면 안 된다. 대신 운영 측면에서는 영향 버전 사용 중지 여부를 확인하고, 공급망 내부 미러나 빌드 의존성 잠금 파일에 해당 버전이 잔존하는지 함께 점검하는 것이 현실적이다.
네트워크·호스팅 환경에서 보는 의미
이번 이슈는 애플리케이션 계층의 SDK 검증 문제이지만, 실제 악용 전제는 네트워크 중간자 위치다. 따라서 공용망, 지점망, 무선 구간, 외부 현장 게이트웨이처럼 경로 통제가 약한 환경일수록 우선순위를 높게 잡는 것이 적절하다.
서버호스팅이나 코로케이션 환경에서 IoT 수집 게이트웨이를 운영하는 경우에도, 문제가 데이터센터 전용 기능에 한정된 것은 아니다. 다만 수집 노드가 외부 장비와 MQTT 세션을 유지한다면 SDK 버전, Python 버전, 연결 포트, 인증 방식 기준으로 자산 목록을 분리해 확인하는 것이 직접적인 대응 포인트가 된다.
핵심 포인트
- CVE-2026-92943는 AWS IoT Device SDK for Python의 서버 인증서 호스트명 검증 누락 이슈다.
- 영향 버전은 AWSIoTPythonSDK 1.5.3 이상 1.6.0 이하이며 Python 3.7 이상에서 해당된다.
- 8883 포트 X.509 상호 인증과 443 포트 WebSocket with SigV4 기본 경로가 영향받는다.
- 443 포트 ALPN 경로는 영향 대상이 아니다.
- 공격자는 중간자 위치에서 텔레메트리 열람과 임의 MQTT 메시지 주입을 시도할 수 있다.