Chaos and Order

💡 왼쪽 원문을 읽으면서 오른쪽에 따라 써보세요. Tab 키로 힌트를 받을 수 있습니다.

들어가며 — 한 릴리스에 CVE 18개
숫자부터 검산하기 — curl의 2026년 상반기
어쩌다 여기까지 — 슬롭의 시대와 버그바운티의 죽음
"고품질 카오스" — 슬롭이 아니라 진짜가 몰려온다
18개의 CVE는 실제로 뭘 고쳤나
CVE가 되지 못한 버그 — 첫 CNA 분쟁
기능 쪽 — MASQUE 프록시, named glob, 그리고 제거 예고
실무에서 무엇이 달라지나
마치며
참고 자료

들어가며 — 한 릴리스에 CVE 18개

2026년 6월 24일, curl 8.21.0이 릴리스됐습니다. Daniel Stenberg가 릴리스마다 붙이는 통계는 이번에도 어김없는데, 그중 한 줄이 눈에 박힙니다. 275번째 릴리스, 56일 주기, 커밋 531개, 버그픽스 276건, 새 기능 6개 — 그리고 보안 수정 18건.

한 릴리스에 CVE 18개는 curl 프로젝트 역사상 최다 기록입니다. 2026년 한 해 발행량 기준으로도 이미 기록입니다. 이 숫자만 떼어 놓고 보면 "curl에 무슨 일이 났나" 싶지만, 18개를 뜯어 보면 이야기가 달라집니다. Medium 4건, Low 14건. High도 Critical도 없습니다. curl의 마지막 High 등급 CVE는 2023년 10월의 CVE-2023-38545(SOCKS5 힙 오버플로)가 여전히 마지막입니다.

그러니까 이 릴리스의 진짜 이야기는 "curl이 위험해졌다"가 아닙니다. 보안 보고서 생태계가 올해 구조적으로 달라졌고, curl이 그 최전선에 있다는 것입니다. 이 글은 그 과정을 — 슬롭 시대, 버그바운티 폐지, GitHub 이주 실패, 그리고 Stenberg가 "고품질 카오스"라 부르는 현재까지 — 1차 소스로 따라가고, 실무에서 무엇이 달라지는지 정리합니다.

숫자부터 검산하기 — curl의 2026년 상반기

curl은 자기 취약점 이력 전체를 기계가독 데이터(vuln.json)로 공개합니다. 블로그 주장을 그대로 받아 적는 대신 이 파일을 직접 세어 봤습니다. 발행일 기준 연도별 CVE 수는 이렇습니다.

연도	발행 CVE 수
2020	6
2021	13
2022	21
2023	18
2024	11
2025	9
2026 (6월 24일까지)	36

2026년 릴리스별로는 1월 7일(8.18.0)에 6건, 3월 11일(8.19.0)에 4건, 4월 29일(8.20.0)에 8건, 6월 24일(8.21.0)에 18건. 합이 36건으로, 상반기가 끝나기도 전에 종전 최다 연도였던 2022년(21건)을 이미 넘었습니다. 단일 발행일 기준으로도 이번 18건이 최다고, 종전 기록은 2016년 11월 2일의 11건이었습니다. 블로그의 "기록" 주장은 데이터와 정확히 일치합니다.

주의할 점 하나. 이건 "curl 코드가 갑자기 나빠졌다"의 그래프가 아니라 "찾는 속도가 달라졌다"의 그래프입니다. 그 구분이 이 글 전체의 주제입니다.

어쩌다 여기까지 — 슬롭의 시대와 버그바운티의 죽음

타임라인을 짚어야 지금 상황이 읽힙니다. 전부 Stenberg 본인의 기록입니다.

2019년 4월 — HackerOne에서 curl 버그바운티 시작. 폐지 시점까지 누적 확정 취약점 87건, 연구자 보상금 지급 총액 10만 달러 이상.
2024년 1월 — "The I in LLM stands for intelligence". LLM이 지어낸 취약점 보고가 공론화되기 시작.
2025년 7월 — "Death by a thousand slops". 슬롭이 급증. 예년에 15%를 웃돌던 보고서 확인율(제출 대비 실제 취약점 비율)이 2025년 들어 5% 아래로 추락 — 스무 건에 한 건도 진짜가 아니게 됨.
2026년 1월 26일 — 버그바운티 종료 발표. 1월 31일부로 보상금 전면 폐지. "지어낸 거짓말을 제출할 유인을 없애기 위해"라는 이유였고, 보고 채널도 HackerOne에서 GitHub의 비공개 취약점 보고(Private Vulnerability Reporting)로 옮김.
2026년 2월 25일 — 한 달 만에 HackerOne 복귀 발표. 보상금은 계속 없지만, 플랫폼은 3월 1일부터 다시 HackerOne.

GitHub 이주가 왜 실패했는지도 기록으로 남겼는데, 이 목록은 취약점 접수 시스템을 고민하는 팀이라면 그대로 체크리스트로 쓸 만합니다. 보고서 전문이 알림 이메일로 평문 발송되는 걸 끌 수 없고(조기 유출 위험), 무효 판정된 보고서를 공개 상태로 전환할 방법이 없고(curl은 틀린 보고서도 전부 공개하는 걸 원칙으로 합니다), curl은 자체 CNA라 CVE 번호를 직접 발급하는데 GitHub 폼의 CVE 필드는 편집이 안 되고, 슬롭 통계를 내기 위한 라벨 기능도 없습니다. Stenberg의 결론은 "바운티 없이 제대로 된 취약점 접수를 하려는 오픈소스 프로젝트를 위한 도구가 전반적으로 부실하다"였습니다.

"고품질 카오스" — 슬롭이 아니라 진짜가 몰려온다

바운티를 없앴으니 보고서가 줄었을까요? 정반대 일이 일어났습니다. 4월의 "High-Quality Chaos"와 5월의 "The pressure"에 그 수치가 있습니다.

슬롭은 문제가 아니게 됐습니다. 대신 보고 빈도가 2024년의 4~5배, 이미 배로 뛰었던 2025년의 다시 2배 — 평균 하루 1건 이상.
확인율은 AI 이전 수준(15~16%대)으로 돌아왔고, 심지어 웃돕니다. 취약점은 아니지만 실제 버그인 보고의 비중도 예전보다 훨씬 높아졌습니다.
그리고 거의 모든 보고서에 AI를 쓴 흔적이 있습니다. 문체로, 구성으로, 그리고 사람이 썼다면 나올 수 없는 수준으로 정교한 중복 보고가 동시에 들어오는 걸로 알 수 있다고 합니다.

즉 2025년의 문제가 "AI가 지어낸 가짜"였다면, 2026년 3월부터의 문제는 AI로 무장한 연구자들이 진짜 버그를 사람이 처리할 수 없는 속도로 찾아내는 것입니다. Stenberg는 4월 시점에 "이 추세면 올해 CVE 50건에 근접할 수 있다"고 전망했는데, 6월 24일에 이미 36건이니 전망대로 가고 있습니다.

이게 curl만의 일이 아니라는 것도 중요합니다. Stenberg가 Mastodon에서 돌린 비공식 설문에 Apache httpd, BIND, Django, Firefox, git, glibc, GnuTLS, HAProxy, Linux 커널, OpenLDAP, Python, Ruby, urllib3, Wireshark, wolfSSL 같은 프로젝트들이 같은 추세를 확인해 줬습니다. 당신의 의존성 트리 전체에서 CVE 발행 속도가 올라간다고 가정하는 편이 안전합니다.

한편 5월에는 재미있는 대조 사례도 있었습니다. Anthropic이 "보안 결함 탐지가 위험할 만큼 뛰어나 당분간 선별 공개한다"며 화제를 모은 모델 Mythos가 Linux Foundation 경유로 curl을 스캔했는데, 결과는 확정 취약점 단 1건(Low)이었습니다 — 보고서가 주장한 "확정 5건"을 보안팀이 검증하니 오탐 3건, 그냥 버그 1건이 걸러졌습니다. 같은 글에서 Stenberg는 이미 AISLE, Zeropath, OpenAI Codex Security 같은 AI 분석 도구가 최근 8~10개월간 curl에 200~300건의 버그픽스와 십여 건 이상의 CVE로 이어졌다고 밝힙니다. 그의 평가는 양가적입니다. 특정 모델의 신비화는 마케팅에 가깝지만, AI 코드 분석기 전반이 기존 정적 분석기보다 확실히 잘 찾는 것도 사실이라는 것. 그리고 핵심 관찰 하나 — AI는 새로운 종류의 취약점을 발명하지 않고, 이미 아는 종류의 새 인스턴스를 더 많이 찾아낼 뿐입니다.

18개의 CVE는 실제로 뭘 고쳤나

그 관찰을 8.21.0의 CVE 목록에서 그대로 확인할 수 있습니다. 2026년 CVE 36건의 제목을 훑으면 한 단어가 반복됩니다. reuse. 제 집계로 36건 중 10건의 제목에 "reuse"가 들어갑니다 — wrong STARTTLS connection reuse, wrong reuse of SMB connection, connection reuse ignores TLS requirement, incomplete mTLS config matching in conn reuse 등등.

우연이 아닙니다. libcurl은 전송이 끝난 커넥션을 풀에 보관했다가 설정이 맞는 후속 전송에 재사용하는데, "설정이 맞는다"의 판정은 신뢰에 영향을 주는 모든 차원 — 호스트, 포트, 프로토콜, TLS 옵션, 클라이언트 인증서, 프록시, 인증 상태 — 을 빠짐없이 비교해야 안전합니다. 차원 하나를 빼먹을 때마다 "다른 보안 문맥의 커넥션을 잘못 재사용"하는 버그가 하나씩 나옵니다. 한 건이 CVE로 공개되면, AI 도구를 쥔 연구자들이 같은 클래스의 변종을 조직적으로 채굴하기 시작합니다. 2026년의 CVE 클러스터는 그 채굴의 흔적입니다.

개별 건 중 프로토콜 플러밍 관점에서 눈여겨볼 것들을 꼽으면 이렇습니다(심각도와 영향 버전은 curl 자체 공시 기준).

CVE-2026-9545 — HTTP/3 early data 노출 (Low). TLS 세션 캐시와 CURLSSLOPT_EARLYDATA를 켠 상태에서 같은 호스트에 재접속할 때, 인증서 검증 실패를 확정하기 전에 0-RTT로 요청 바이트가 먼저 나갈 수 있었습니다. 8.11.0(2024년 11월)부터 존재. 0-RTT가 기본 비활성인 이유, "재전송 공격 말고도 검증 순서라는 함정이 있다"는 교과서적 사례입니다.
CVE-2026-11352 — QUIC 길이 0 UDP 데이터그램 busy-loop (Low). 수신 헬퍼가 길이 0 데이터그램을 호출당 패킷 예산에 세지 않고 버려서, 악의적 서버가 빈 데이터그램을 계속 흘리면 클라이언트가 무한정 멈춰 있게 됩니다. 8.18.0(2026년 1월)에 들어온 리그레션이 6월에 잡힌 것. QUIC은 수신 경로가 유저스페이스라 이런 예산 로직 하나하나가 곧 가용성 경계라는 점은 QUIC 수신 측 CPU 비용 편에서 다룬 그대로입니다.
CVE-2026-10536 — HTTP/2 스트림 의존성 트리 UAF (Low). CURLOPT_STREAM_DEPENDS로 의존성 트리를 만들고 curl_easy_reset() 후 정리하면 해제된 구조체를 다시 만졌습니다. 7.88.0(2023년 2월)부터 존재. 흥미로운 건 대응 방식입니다 — 8.21.0은 이 버그를 고치는 데서 멈추지 않고 스트림 의존성 추적 기능을 통째로 제거했습니다. RFC 7540의 우선순위 트리는 후속 표준에서 이미 폐기 표시된 메커니즘이니, 잘 쓰이지도 않는 위험 표면을 유지하느니 걷어낸 겁니다.
CVE-2026-8924 — trailing dot super cookie (Low). 쿠키 파서가 Public Suffix List 검사를 우회당해, 악성 서버가 무관한 서드파티 도메인으로 전송되는 쿠키를 심을 수 있었습니다. 도입 버전이 7.46.0 — 2015년 12월입니다. 10년 넘게 퍼저와 정적 분석기와 감사를 다 통과하며 잠복해 있던 버그가 이번 물결에 걸렸습니다.

Medium 4건은 SASL 더블 프리, 프록시/교차 출처 Digest 인증 상태 누수 두 건, 오래된 프록시 비밀번호 누수입니다. 인증 상태가 커넥션·리다이렉트 경계를 넘는 부류로, 프록시를 낀 배포에서는 실질적 의미가 있으니 목록을 직접 확인할 가치가 있습니다.

도입 버전의 분포도 눈여겨볼 만합니다. 2015년 것부터 올해 1월 리그레션까지 섞여 있습니다. 찾는 도구가 좋아지면 오래된 침전물과 신선한 실수가 같이 걸려 올라옵니다.

CVE가 되지 못한 버그 — 첫 CNA 분쟁

CVE가 쏟아지는 이야기의 반대편에, 같은 날 공개된 첫 CVE 분쟁 이야기가 있습니다. curl은 2024년 1월부터 자체 CNA라서 자기 영역의 CVE 발급 여부를 스스로 결정하는데, 그 결정이 처음으로 MITRE까지 올라간 사건입니다.

버그 자체는 실재했습니다. 와일드카드 인증서 매칭 함수가 https://.example.com/처럼 점으로 시작하는 호스트명을 *.example.com 와일드카드와 잘못 매칭시키는 문제로, 2025년 12월 8일에 수정됐습니다. 다만 점으로 시작하는 이름은 DNS에서 불법이라 /etc/hosts 같은 로컬 개입 없이는 도달 자체가 안 되고, 공격자가 해당 와일드카드 인증서까지 쥐고 있어야 하는 등 전제 조건이 겹겹이라, curl 보안팀은 이를 내부 용어로 "Low보다 낮음"으로 판정하고 CVE를 발급하지 않았습니다. 보고자는 불복해 MITRE에 분쟁을 제기했고, MITRE는 2월, 5월, 6월 세 차례에 걸쳐 같은 질문을 반복하다가 6월 24일 최종 판정을 내렸습니다 — CVE 미발급, CNA 판단 유지.

이 에피소드가 중요한 건 판정 결과보다 그 안의 비용 논리입니다. Stenberg의 추산으로 libcurl은 전 세계 수백억 대(그의 표현을 빌리면 200억에서 300억 사이)에 설치돼 있고, CVE 하나가 발행될 때마다 전 세계 보안팀의 스캐너가 울리고 패치와 업데이트 작업이 연쇄적으로 발생합니다. 그 비용은 curl이 아니라 생태계가 치릅니다. 그래서 실제로 도달 불가능한 이론적 문제에 경보를 울리지 않는 것도 CNA의 책임이라는 겁니다. CVE 36건을 발행한 해에 CVE 하나를 발행하지 않으려고 넉 달 넘게 싸운 프로젝트 — 이 두 사실이 같은 원칙에서 나옵니다. 숫자가 아니라 실질 위험 기준.

기능 쪽 — MASQUE 프록시, named glob, 그리고 제거 예고

보안 이야기에 묻혔지만 8.21.0의 새 기능 6개 중에도 플러밍 관점의 굵직한 게 있습니다. 공식 체인지로그 기준으로.

HTTP/3 프록시 지원 — CONNECT와 MASQUE CONNECT-UDP(ngtcp2 QUIC 빌드 한정). 지금까지 curl에서 프록시는 HTTP/1.1이나 HTTP/2까지였는데, 이제 프록시 구간 자체를 HTTP/3으로 뚫고 그 위로 UDP(즉 종단 QUIC)를 CONNECT-UDP로 실어 나르는 구성이 가능해집니다. MASQUE 계열 프록시가 iCloud Private Relay 같은 대형 배포 밖에서도 시험해 볼 수 있는 도구가 하나 늘어난 셈입니다.
named glob — URL 글롭에 이름을 붙여 출력 파일명에서 참조하는 CLI 편의 기능, 업로드 쪽 글롭 참조 포함.
제거된 것: HTTP/2 스트림 의존성 추적(앞서 설명), 그리고 IE 6 호환용이던 CURLAUTH_DIGEST_IE.

그리고 릴리스 노트 끝의 제거 예고 목록이 사실 실무자에게 제일 급한 부분일 수 있습니다. 자체 crypto 구현, NTLM, SMB, TLS-SRP가 제거 후보로 올라 있고, 해당 기능을 쓰고 있다면 지금 curl-library 리스트에서 발언하라고 명시돼 있습니다. 레거시 인증·프로토콜을 걷어내는 물결은 OpenSSH 10.4의 삭제 목록과 정확히 같은 방향입니다. NTLM 프록시 인증에 기대는 기업 내부망 자동화가 아직 얼마나 많은지 생각하면, 이 예고는 조용히 지나칠 항목이 아닙니다.

다음 릴리스는 여름 휴지기로 사이클을 2주 늘려 9월 2일로 예고돼 있습니다.

실무에서 무엇이 달라지나

libcurl을 직접 링크하든, 베이스 이미지의 배포판 패키지로 깔려 있든, 이 흐름이 당신 팀에 닿는 지점은 대략 이렇습니다.

스캐너 노이즈가 늘어납니다. 연 9~11건이던 curl CVE가 올해 36건+로 뛰었으니, 컨테이너 이미지 스캔 결과에서 curl 항목이 눈에 띄게 늘어납니다. 다행히 curl의 공시 품질은 업계 최상급입니다 — 건별 상세 페이지에 도입 커밋부터 수정 버전까지 명시되고, vuln.json이 OSV 호환 스키마로 제공되므로 "우리 버전이 실제 영향 범위에 드는가"를 자동으로 판별하는 파이프라인을 만들 수 있습니다.

심각도는 재평가해서 쓰는 값입니다. curl의 등급은 "사용자가 어떻게 쓰는지 모른다"는 전제의 curl 관점 등급입니다. 예컨대 CURLSSLOPT_EARLYDATA를 켠 적이 없으면 CVE-2026-9545는 무관하고, 스트림 의존성 API를 쓴 적이 없으면 CVE-2026-10536도 무관합니다. 반대로 프록시 + 인증 조합이 많은 환경이라면 Medium 4건은 등급 이상으로 진지하게 볼 필요가 있습니다.

패닉은 근거가 없습니다. 최근 몇 년간 curl 취약점은 전부 Low/Medium이고 High는 2023년 10월이 마지막이라는 사실은, 격이 다른 스크루티니를 수십 년 받아온 코드베이스의 실측치입니다. 다만 그 반대 방향의 교훈도 같이 가져가야 합니다 — 이 정도로 털린 코드에서도 도구가 좋아지자 반년 만에 36건이 나왔습니다. 스캔 이력이 얕은 당신의 사내 C 코드라면 훨씬 많이 나올 겁니다. Stenberg 표현대로, AI 분석기를 안 돌리는 프로젝트는 공격자가 같은 도구로 먼저 찾을 시간을 벌어 주는 셈입니다.

유지보수자 쪽 비용도 시야에 두시길. 하루 1건 이상의 보안 보고를 검증·수정·공시하는 일은 지금 소수의 사람이 감당하고 있고, Stenberg는 5월 글에서 처음으로 건강과 노동 시간 우려를 공개적으로 언급하며 상업적 사용자들의 지원 계약을 요청했습니다. 이 추세가 의존성 전반으로 확산될 때 각 프로젝트의 대응 역량은 곧 당신의 공급망 리스크입니다. 이 물결이 퍼징처럼 언젠가 정체기에 도달할지는 그 자신도 "지켜봐야 안다"고만 말합니다.

마치며

정리하면 이렇습니다. curl 8.21.0의 CVE 18건은 코드가 나빠졌다는 신호가 아니라, 2026년 3월 이후 보안 연구 생태계가 AI로 재무장하면서 발견 속도가 구조적으로 뛰었다는 신호입니다. 슬롭의 시대는 버그바운티와 함께 끝났고, 지금 오는 것은 진짜 버그의 홍수입니다 — 대부분 Low, 오래된 침전물과 신선한 리그레션이 섞인, 커넥션 재사용 같은 특정 버그 클래스에 집중된.

curl은 이 물결을 기록적인 투명성으로 통과하는 중입니다. 건별 상세 공시, 기계가독 데이터, CVE를 만들 때와 같은 진지함으로 CVE를 거부하는 원칙까지. 우리가 할 일은 담백합니다. 스캐너 결과에 늘어난 curl 항목을 영향 범위 기준으로 트리아지할 파이프라인을 갖추고, NTLM·SMB 같은 제거 예고 목록에 자기 워크로드가 걸리는지 지금 확인하고, 의존성 전체에서 CVE 발행 속도가 올라가는 시대에 맞게 패치 케이던스를 조정하는 것. 그리고 어딘가의 릴리스 노트에서 "보안 수정 18건"을 봤을 때, 숫자에 놀라기 전에 심각도와 전제 조건부터 읽는 습관 — 그게 이 새 시대의 기본기입니다.