curl 8.23.0 보안 업데이트 | High 취약점 CVE-2026-92392, 8.12.0~8.22.0이면 확인할 것 (2026년 10월 기준)

서버, CI 러너, 컨테이너 이미지 안에 curl이 몇 군데 들어 있는지 바로 말할 수 있나요? 대부분은 설치해 놓고 잊어버립니다. 그런데 10월 14일 curl 8.23.0이 나오면서, curl 프로젝트가 High 등급 취약점 하나(CVE-2026-92392)를 함께 고쳤습니다.

curl 프로젝트 공지는 HTTP/2로 파일을 올리는 도중에 이미 해제한 메모리를 다시 쓰는 결함이라고 설명하고, 영향 버전을 8.12.0부터 8.22.0까지로 밝혔습니다. curl 프로젝트의 High 이상 목록에서 2023년 10월 CVE-2023-38545 다음으로 올라온 High입니다. 아래에서 내 환경이 해당되는지 확인하는 명령, 배포판 패치 상태, 바로 올리기 어려울 때의 임시 대응을 순서대로 정리합니다.

curl 8.23.0(10월 14일)이 HTTP/2 업로드 use-after-free(CVE-2026-92392, High)를 고쳤다. 영향은 8.12.0~8.22.0의 curl 명령줄 도구와 libcurl이고, 문제는 curl로 올리는 쪽이 악의적인 서버에 HTTP/2로 업로드할 때 생긴다. 8.23.0으로 올리거나 배포판 수정본을 쓰고, 어렵다면 업로드 명령에 --http1.1을 붙인다.

목차

1. CVE-2026-92392 한눈에 보기

2. 어떤 조건에서 문제가 되나

3. 내 curl 버전 확인하기

4. 배포판은 번호만 보고 판단하지 마세요

5. 패치하는 방법

6. 서버가 많다면, 그리고 당장 못 올린다면

1. CVE-2026-92392 한눈에 보기

curl 공지는 이 결함을 "HTTP/2 upload Use-After-Free"라고 부릅니다. 업로드 중에 서버가 보낸 HTTP/2 RST_STREAM(이유가 HTTP_1_1_REQUIRED 또는 REFUSED_STREAM인 경우)을 curl이 잘못 처리해, 이미 해제한 Curl_easy 구조체를 다시 쓰게 됩니다. 등급은 High이고 CWE-416(해제 후 사용)으로 분류됐습니다.

항목	내용 (curl 공지 기준)
CVE	CVE-2026-92392 (HTTP/2 upload Use-After-Free)
등급	High, CWE-416
영향 버전	curl 8.12.0 ~ 8.22.0 (명령줄 도구와 libcurl 모두)
영향 없음	8.12.0 미만, 8.23.0 이상, 8.20.X 가지는 8.20.2 이상, 8.16.X는 8.16.2 이상, 8.14.X는 8.14.3 이상
공개	2026년 10월 14일, curl 8.23.0 릴리스와 같은 날
보고	2026년 9월 15일, 보고자는 공지에 "Luna with Claude, Anthropic"으로 적힘

아래는 공지의 영향 버전과 권고 부분입니다. 이 결함은 curl 명령줄 도구만이 아니라 libcurl을 쓰는 프로그램에도 해당하고, 공지가 "libcurl을 쓴다고 광고하지 않는 앱도 많다"고 짚습니다.

출처: curl 프로젝트 보안 공지 CVE-2026-92392 갈무리

핵심 같은 날 공개된 취약점이 더 있습니다. curl 취약점 목록에는 10월 14일 공개분이 24건 올라와 있고 High는 이 1건, 나머지 23건은 Low입니다. 제 판단으로는 8.22.0 이하를 쓴다면 이번 릴리스로 한꺼번에 올리는 편이 점검 횟수를 줄입니다.

2. 어떤 조건에서 문제가 되나

공지는 이 결함이 특정 조건을 모두 갖춘 악성 서버에서는 원격 코드 실행으로 이어질 수 있다고 인정합니다. 조건으로는 정확한 curl 구조 배치와 아키텍처, libc 할당기와 힙 배치, nghttp2와 TLS 1.3 동작, 병렬 전송 두 개의 타이밍, 약 23바이트라는 명령 길이 제한 등이 줄줄이 적혀 있습니다.

curl 개발자 Daniel Stenberg는 자신의 글에서 조건을 이렇게 풀었습니다. 피해자가 악의적인 서버에 실제로 업로드를 시도해야 하고 서버 인증서가 유효해야 합니다. 업로드 크기가 대략 135KB 안팎이어야 하고, 공격자가 curl의 아키텍처를 알아야 하며, 배포판과 libc, 인증서 묶음에 따라 달라지는 메모리 할당 순서가 맞아야 합니다. 그래서 "가장 가능성 높은 결과는 비정상 종료"이고 성공 확률은 낮다고 추정했습니다. 원격 코드 실행 가능성은 증명됐지만 실제 공격 조건이 까다로워 Critical이 아니라 High로 분류했다고 설명합니다.

주의 업로드 API를 운영하는 쪽이 곧바로 위험하다는 뜻은 아닙니다. 영향을 받는 것은 curl로 올리는 클라이언트입니다. 백업·배포·로그 업로드 같은 자동화가 서버나 CI 러너에서 HTTPS로 파일을 올린다면 그 클라이언트의 curl 버전이 점검 대상입니다. 공지와 개발자 글에는 실제 악용 사례에 대한 언급이 없습니다.

3. 내 curl 버전 확인하기

가장 빠른 확인은 curl --version의 첫 줄입니다. 아래 움직이는 화면은 이 글을 쓴 Mac에서 실제로 실행한 출력입니다. 맨 아래 주석 두 줄만 설명용으로 붙였습니다.

이 글을 쓴 Mac에서 실제로 실행한 출력(마지막 주석 두 줄만 설명용)

내 curl 버전과 HTTP/2 지원 확인

curl --version | head -1
curl --version | grep -o HTTP2

첫 줄 버전	판정
8.11.x 이하	이 결함에는 영향 없음(8.12.0 이전)
8.12.0 ~ 8.22.0	영향권. 단 8.20.2, 8.16.2, 8.14.3 이상 가지 버전은 수정본
8.23.0 이상	수정됨

컨테이너 이미지 안의 curl 버전 보기

docker run --rm 이미지이름:태그 curl --version | head -1

이미지에 curl이 없으면 위 명령이 실패합니다. 이미지 안에 curl 명령은 없어도 libcurl을 쓰는 프로그램이 들어 있을 수 있으니, 그런 프로그램은 제작사의 업데이트 공지에서 libcurl 버전을 확인하세요.

4. 배포판은 번호만 보고 판단하지 마세요

배포판은 curl 번호를 올리지 않고 수정만 가져오는 경우가 있습니다. Debian 보안 트래커는 trixie의 수정 버전을 상위 번호 8.14.1이 붙은 8.14.1-2+deb13u7로 적었고, 같은 번호의 8.14.1-2+deb13u5는 취약하다고 표시합니다. 번호가 낮아도 수정본일 수 있다는 뜻입니다.

배포판	상태 (보안 트래커 기준)
Debian 12 bookworm	영향 없음(해당 코드 없음, curl 7.88.1)
Debian 13 trixie	8.14.1-2+deb13u7에서 수정(DSA-6558-1)
Debian sid	8.23.0-1에서 수정
Ubuntu 26.04 LTS	8.18.0-1ubuntu2.8에서 수정
Ubuntu 24.04 LTS 이하	영향 없음

위 표는 Debian 보안 트래커와 Ubuntu 보안 페이지에서 가져온 상태입니다. 다른 배포판(RHEL 계열, Alpine, SUSE 등)의 상태는 각 배포판의 보안 페이지에서 직접 확인하세요.

5. 패치하는 방법

배포판 패키지 업데이트 (환경에 맞게 하나만)

# Debian·Ubuntu 계열
sudo apt update && sudo apt install --only-upgrade curl 'libcurl4*'

# RHEL·Fedora 계열
sudo dnf upgrade curl libcurl

# 설치된 패키지 버전 확인 후 보안 트래커와 대조
apt-cache policy curl

올린 뒤에는 curl --version이 아니라 패키지 버전을 트래커의 수정 버전과 비교하세요. 앞서 본 것처럼 배포판은 번호가 그대로일 수 있습니다. 컨테이너는 호스트를 패치해도 이미지 안 curl이 그대로이므로, 베이스 이미지를 수정된 것으로 바꿔 다시 빌드해야 합니다. curl.se에서 직접 받아 쓰는 경우에는 8.23.0 소스를 받아 교체합니다.

6. 서버가 많다면, 그리고 당장 못 올린다면

서버가 여러 대라면 반복문으로 한 번에 보면 됩니다. 아래 화면은 가상의 호스트 이름을 쓴 예시 출력이고, 빨간색이 영향권입니다.

재구성한 예시 화면(가상의 호스트 이름과 예시 출력, 직접 실행한 결과가 아님)

반응형

여러 서버의 curl 버전 한 번에 보기

for h in web1 web2 ci-runner; do
  printf "%s: " $h; ssh $h "curl --version | head -1 | cut -d' ' -f1,2"
done

영향권이 나왔는데 바로 올리기 어렵다면 임시 대응이 있습니다. curl 공지의 세 번째 권고는 "HTTP/2를 쓰지 않기"입니다. 명령줄에서는 --http1.1이 그 방법입니다. curl 설명서는 HTTPS에서 curl이 기본으로 HTTP/2를 협상한다고 적고, --http1.1은 HTTP 1.1을 쓰게 합니다. 업로드하는 명령에만 붙이는 식으로 쓰면 됩니다.

업로드 명령에 HTTP/1.1 강제 (임시 대응)

curl --http1.1 -T backup.tar.gz https://upload.example.com/backup/

주의 이것은 패치가 아니라 임시 대응입니다. 반복문이나 스크립트 안에 흩어진 curl 호출을 하나라도 빼먹으면 소용이 없고, libcurl을 쓰는 프로그램은 앱 설정이나 코드에서 HTTP 버전을 바꿔야 합니다. 업그레이드 날짜를 정해 두고 쓰세요.

핵심 점검 순서 제안 1) 파일을 HTTPS로 올리는 자동화부터 찾는다. 2) 그 작업이 도는 서버·러너·이미지의 curl 버전을 확인한다. 3) 영향권이면 업그레이드 날짜를 정하고, 그 전까지 업로드 명령에 --http1.1을 붙인다.

Q. 실제로 공격에 쓰인 사례가 있나요?

공지와 개발자 글에는 실제 악용 사례에 대한 언급이 없습니다. curl 개발자는 성공 확률이 낮고 가장 흔한 결과는 비정상 종료일 것이라고 밝혔습니다. 그래도 High로 분류된 결함이라 패치는 하는 편이 좋습니다.

Q. 8.11.x 이하는 이번 결함에서 안전한가요?

이 결함은 8.12.0에서 들어온 것이라 그보다 낮은 버전은 이 CVE에 해당하지 않습니다. 다만 같은 날 공개된 낮은 등급 취약점 중에는 7.x 버전부터 영향을 받는 것도 있어서, 오래된 버전도 업데이트하는 편이 낫습니다.

Q. http:// 주소로 올리면 안전한가요?

curl 설명서는 http:// 주소에서 기본이 HTTP/1.1이라고 적습니다. HTTP/2를 직접 지정하지 않았다면 이 결함의 경로와는 거리가 있다는 것이 제 판단입니다. 다만 평문 HTTP로 파일을 올리자는 뜻은 아니고, 보안상 HTTPS를 쓰고 curl을 올리는 편이 맞습니다.

Q. Ubuntu 24.04나 22.04는 어떤가요?

Ubuntu 보안 페이지에서 24.04 LTS 이하는 영향 없음으로 표시됩니다. 26.04 LTS는 8.18.0-1ubuntu2.8에서 수정됐습니다.

Q. 컨테이너 호스트만 패치하면 되나요?

아닙니다. 컨테이너 안에는 별도의 curl이 들어 있어서, 이미지를 수정된 버전으로 바꿔 다시 빌드해야 합니다.

3줄 핵심 요약

1. curl 8.23.0(10월 14일)이 HTTP/2 업로드 use-after-free(CVE-2026-92392, High)를 고쳤고, 영향 버전은 8.12.0~8.22.0이며 curl 명령줄 도구와 libcurl 모두 해당한다.
2. 문제는 curl로 올리는 쪽이 악의적인 서버에 HTTP/2로 업로드할 때 생긴다. 실제 공격은 조건이 까다롭고 가장 흔한 결과는 비정상 종료라고 curl 개발자가 밝혔다. 공지와 개발자 글에는 실제 악용 사례에 대한 언급이 없다.
3. curl --version으로 확인하고, 배포판은 번호가 아니라 패키지 버전을 보안 트래커와 대조한다. 당장 못 올리면 업로드 명령에 --http1.1을 붙이되 임시 대응으로만 쓴다.

마치며

curl은 안 터지면 신경 쓰지 않게 되는 도구입니다. 그래서 이번처럼 High가 나오면 어디에 몇 개 들어 있는지부터 모릅니다. 오늘은 파일을 HTTPS로 올리는 자동화 하나만 골라, 그 작업이 도는 서버나 러너에서 curl --version을 실행해 보세요. 버전이 영향권이면 업그레이드 날짜를 적어 두고, 아니면 이번에는 넘어가도 됩니다. 나머지 서버는 위 반복문으로 한꺼번에 1차 확인하고, 영향권으로 보이는 서버만 패키지 버전을 보안 트래커와 대조하세요.

NEXT READ

이어서 읽어 볼 글

01  금융권 연쇄 해킹, 은행 밖으로 번졌다 · 내가 대상인지 확인하고 오늘 할 일

02  클로드 소네트 4.5 API, 11월 30일에 꺼진다 · 종료 전에 코드에서 바꿔야 할 것

03  맥북 처음 켰다면 개발 전에 이것부터 · 개발 시작 전 맥 설정 정리

#curl,#curl보안업데이트,#CVE202692392,#HTTP2취약점,#libcurl,#서버보안,#CICD,#컨테이너보안,#패치방법,#안전하게쓰기