AI와 함께 찾아낸 OpenSSL 고위험 취약점: CVE-2026-45447, PKCS#7 검증의 use-after-free
🤖 AI Summary
OpenSSL이 High 등급 취약점 CVE-2026-45447을 공개했습니다(2026년 6월 9일). 특수하게 조작된 PKCS#7·S/MIME 서명 메시지가 PKCS7_verify() 검증 과정에서 use-after-free를 일으켜, 크래시와 힙 손상은 물론 상황에 따라 원격 코드 실행 가능성까지 명시됐습니다. 영향 버전은 4.0·3.6·3.5·3.4·3.0과 구형 1.1.1·1.0.2까지 7개 라인에 걸칩니다. 이번 건이 특히 주목받은 이유가 하나 더 있습니다. 공식 발견자 크레딧에 보안 연구자와 함께 AI(Claude·Anthropic Research 협업)가 올랐다는 점입니다. 발표 후 한 달이 지난 지금, 아직 점검 전이라면 영향 버전 대조부터 시작할 시점입니다. 이 글은 공식 advisory 원문 기준으로 메커니즘과 패치 기준을 정리합니다.
블로그 목차
이번 취약점이 눈길을 끄는 두 가지 이유
OpenSSL 취약점 공개는 드문 일이 아닙니다. 그런데 6월 9일 공개된 CVE-2026-45447은 두 가지 점에서 평소와 다릅니다. 첫째, 등급이 High이고 영향에 "잠재적 원격 코드 실행"이 명시됐습니다. OpenSSL은 사실상 인터넷 전체가 쓰는 암호 라이브러리라, High 한 건의 파급 범위가 넓습니다.
둘째, 발견자 항목입니다. OpenSSL 공식 취약점 페이지의 발견자(Found by) 항목에는 이렇게 적혀 있습니다. "Thai Duong (Calif.io in collaboration with Claude and Anthropic Research)". 보안 연구자가 AI 모델과 협업해 찾아냈고, 그 협업이 공식 크레딧에 그대로 남은 것입니다. AI를 활용한 취약점 발굴이 실험을 넘어 실제 고위험 CVE 발견으로 이어지고 있다는 신호죠. 공격자도 같은 도구를 쓸 수 있는 시대라는 뜻이기도 합니다.
무엇이 문제인가: PKCS7_verify()의 use-after-free
advisory의 요약은 명확합니다. "특수하게 조작된 PKCS#7 또는 S/MIME 서명 메시지가 PKCS#7 서명 검증 과정에서 use-after-free를 일으킬 수 있다"는 것입니다. 메커니즘을 풀면 이렇습니다.
서명된 데이터(SignedData)의
digestAlgorithms필드가빈 ASN.1 SET으로 들어오면,OpenSSL이
PKCS7_verify()도중호출자(애플리케이션) 소유의 BIO를 잘못 해제합니다.이후 애플리케이션이 그 BIO를 다시 사용하는 순간(대표적으로
BIO_free()호출)use-after-free가 발생합니다.
결과는 할당자 동작과 애플리케이션의 BIO 사용 패턴에 따라 달라집니다. advisory는 영향을 "프로세스 크래시, 힙 손상, 또는 잠재적으로 원격 코드 실행"으로 요약하고, 원격 코드 실행은 일부 애플리케이션 맥락에서 잠재적으로 악용될 수 있다고 별도로 덧붙입니다. 라이브러리가 내 것이 아닌 메모리를 해제해 버리고, 애플리케이션은 그 사실을 모른 채 평소처럼 정리 코드를 실행하다 무너지는 구조입니다.
범위의 경계도 advisory에 명시돼 있습니다. 영향 대상은 PKCS#7·S/MIME 서명 메시지를 OpenSSL의 PKCS#7 API로 처리하는 애플리케이션입니다. 같은 처리를 CMS API로 하는 애플리케이션은 영향받지 않고, FIPS 모듈도 영향 범위 밖입니다(해당 코드가 FIPS 모듈 경계 밖에 있기 때문).
영향 버전과 수정 버전: 7개 라인 전부 확인
영향 범위가 넓습니다. 현행 4.0 라인부터 오래된 1.0.2까지 7개 라인이 모두 대상입니다. advisory의 영향·수정 버전을 그대로 옮기면 다음과 같습니다.
라인 | 영향 버전 | 수정 버전 |
|---|---|---|
4.0 | 4.0.0 이상 4.0.1 미만 | 4.0.1 |
3.6 | 3.6.0 이상 3.6.3 미만 | 3.6.3 |
3.5 | 3.5.0 이상 3.5.7 미만 | 3.5.7 |
3.4 | 3.4.0 이상 3.4.6 미만 | 3.4.6 |
3.0 | 3.0.0 이상 3.0.21 미만 | 3.0.21 |
1.1.1 | 1.1.1 이상 1.1.1zh 미만 | 1.1.1zh (프리미엄 지원 고객 전용) |
1.0.2 | 1.0.2 이상 1.0.2zq 미만 | 1.0.2zq (프리미엄 지원 고객 전용) |
주의할 점 하나. 1.1.1과 1.0.2는 이미 공개 지원이 끝난 라인이라, 위 수정 버전(1.1.1zh·1.0.2zq)은 advisory 기준 프리미엄 지원 고객 전용으로 제공됩니다. 이 라인을 일반 환경에서 쓰고 있다면 이번 기회에 지원 중인 3.x 이상 라인으로의 이전을 함께 검토하는 편이 현실적입니다.
참고로 이번 advisory는 CVE-2026-45447 하나만 담고 있지 않습니다. 같은 날 문서 전체로 총 18건(High 1·Moderate 5·Low 12)이 공개됐고, Moderate에는 CMS 메시지 위조(CVE-2026-34182), OCSP 스테이플링 더블프리(CVE-2026-35188) 같은 건이 포함됩니다. 위 표의 수정 버전에는 같은 날 공개된 취약점 중 해당 라인에 영향을 주는 건의 수정이 함께 포함되므로, 버전을 올리면 함께 해소됩니다.
또 하나 놓치기 쉬운 문장이 있습니다. advisory는 "현재 지원 중인 릴리스만 분석했다"고 명시하며, 지원이 끝난 3.1·3.2·3.3은 분석 대상에서 제외됐다고 밝힙니다. 즉 위 표에 이 라인이 없는 것은 안전하다는 뜻이 아니라 확인되지 않았다는 뜻입니다. 이 라인을 쓰고 있다면 지원 중인 버전으로 옮기는 것이 답입니다.
운영자가 지금 점검할 것
발표가 6월 9일이었으니 이 글을 읽는 시점이면 한 달 넘게 지난 상태입니다. 패치를 이미 마쳤다면 확인만 하면 되고, 아직이라면 순서는 간단합니다.
버전 확인:openssl version으로 현재 버전을 확인하고 위 표와 대조합니다. OS 패키지로 설치했다면 배포판 벤더가 구버전 번호에 백포트 패치를 얹는 경우가 있으므로, 배포판 보안 공지 기준으로 판단합니다.노출 경로 파악: 외부에서 들어오는 PKCS#7·S/MIME 서명 메시지를 OpenSSL PKCS#7 API로 처리하는 서비스(메일 게이트웨이, 서명 검증 모듈, 문서 처리 파이프라인 등)를 먼저 찾습니다. 이런 시스템이 패치 1순위입니다.패치: advisory에 별도의 공식 완화책(워크어라운드)은 제시되어 있지 않습니다. 수정 버전으로 올리는 것이 근본 대응입니다.재발 대비: OpenSSL처럼 광범위하게 깔린 라이브러리는 "우리가 어디에 쓰는지"의 목록화가 절반입니다. 이번 점검에서 만든 사용처 목록을 남겨 두면 다음 CVE 때 대응 시간이 크게 줄어듭니다.
마지막으로 이번 사건이 남긴 흐름 하나. AI가 공식 크레딧에 오르는 취약점 발견은 이번이 끝이 아닐 것입니다. 발굴 속도가 빨라진다는 건 패치 릴리스도, 공격 시도도 함께 빨라진다는 뜻입니다. 취약점 공개 후 패치까지의 시간을 줄이는 운영 체계가 점점 더 중요해지고 있습니다.
이것만 기억하세요
OpenSSL CVE-2026-45447(High)은 조작된 PKCS#7·S/MIME 서명 메시지가 PKCS7_verify()에서 use-after-free를 일으키는 취약점입니다. 크래시·힙 손상, 상황에 따라 원격 코드 실행 가능성까지 명시됐습니다. 7개 라인 전부 영향이므로 openssl version으로 확인하고 수정 버전(4.0.1·3.6.3·3.5.7·3.4.6·3.0.21·1.1.1zh·1.0.2zq)으로 올리는 것이 답입니다. CMS API 사용 앱과 FIPS 모듈은 비영향입니다.
자주 묻는 질문 (FAQ)
Q. 우리 서버가 영향을 받는지 어떻게 확인하나요?
openssl version 명령으로 현재 버전을 확인하고 본문 표와 대조하면 됩니다. 영향 버전은 4.0.0(4.0.1 미만)부터 1.0.2(1.0.2zq 미만)까지 7개 라인이에요. OS 패키지로 설치했다면 배포판 벤더가 백포트 패치를 별도 버전 번호로 내는 경우가 있으니, 배포판 보안 공지도 함께 확인해야 합니다.
Q. 어떤 경로로 공격이 이뤄지나요?
공식 advisory 기준으로, 조작된 PKCS#7 또는 S/MIME 서명 메시지가 PKCS#7 서명 검증 과정에서 use-after-free를 일으킵니다. digestAlgorithms 필드가 빈 ASN.1 SET으로 들어오면 OpenSSL이 호출자 소유의 BIO를 잘못 해제하고, 이후 애플리케이션이 그 BIO를 다시 쓸 때(대표적으로 BIO_free 호출) 문제가 발생합니다. 결과는 크래시, 힙 손상, 상황에 따라 잠재적 원격 코드 실행입니다.
Q. PKCS#7을 안 쓰면 안전한가요?
advisory는 영향 대상을 "PKCS#7·S/MIME 서명 메시지를 OpenSSL PKCS#7 API로 처리하는 애플리케이션"으로 명시합니다. 같은 처리를 CMS API로 하는 앱과 FIPS 모듈은 비영향이에요. 다만 어떤 구성 요소가 서명 메시지를 처리하는지 전수 파악이 안 된 상태라면, 버전 자체를 올리는 쪽이 확실합니다.
Q. AI가 찾았다는 건 무슨 뜻인가요?
공식 취약점 페이지의 발견자(Found by) 항목에 "Thai Duong (Calif.io in collaboration with Claude and Anthropic Research)"라고 기재돼 있습니다. 보안 연구자가 AI 모델과 협업해 찾아냈고 그 협업이 공식 크레딧에 오른 것이죠. AI 기반 취약점 발굴이 실제 고위험 CVE 발견으로 이어지고 있다는 신호로 읽을 수 있습니다.
Q. 당장 업그레이드가 어려우면 어떻게 하나요?
advisory에 별도 공식 완화책은 없어서 수정 버전 업그레이드가 근본 대응입니다. 즉시 패치가 어렵다면 PKCS#7·S/MIME 서명 메시지를 외부 입력으로 받는 서비스부터 파악해 그 시스템을 먼저 패치하는 순서를 권합니다. 발표 후 한 달이 지난 시점이니, 아직 점검 전이라면 이번 주 점검 목록에 올릴 만합니다.
