curl 취약점 22건, 8.23.0에서 수정 예정

AI 요약

curl 프로젝트는 취약점 22건을 수정한 curl 8.23.0을 2026년 10월 14일 공개합니다. 원래 계획보다 몇 주 앞당긴 일정입니다. 심각한 취약점 제보 한 건을 받은 뒤 출시 주기를 단축했으며, 해당 취약점과 상대적으로 덜 심각한 21건을 새 버전에서 함께 수정합니다.

취약점 공개와 등급

가장 심각한 취약점은 CVE-2026-92392입니다. curl 프로젝트는 CVSS 점수 체계를 신뢰하지 않아 보고하는 CVE에 LOW, MEDIUM, HIGH, CRITICAL 네 단계 자체 등급을 붙입니다. 2021년 이후 HIGH 등급 취약점은 두 건뿐이었고, 직전 사례는 힙 버퍼 오버플로로 이어질 수 있었던 CVE-2023-38545입니다.

CVE-2026-92392의 세부 내용은 curl 8.23.0 공개와 맞춰 10월 14일 유럽 오전에 발표합니다. 그전까지는 curl 사용자와 curl을 쓰는 인프라의 안전을 위해 취약점 정보를 공개하지 않습니다. 배포판 보안 담당자 메일링 리스트인 distros@openwall과 유료 curl 지원 고객에게는 취약점과 수정 내용을 미리 알릴 예정입니다. 프로젝트는 공개 뒤 별도 글에서 취약점이 발동하는 조건과 수정 방법, 비슷한 문제를 다루는 방식을 설명할 계획입니다.

Lobsters 반응

• @evert — 범위가 작은 프로젝트인데도 이렇게 많은 소식이 나오는 게 늘 놀랍습니다. curl이 훌륭하고 유용하다는 말은 아닙니다. 다만 아키텍처가 이런 상황에 영향을 주는지 궁금합니다. wget이나 fetch() 소식은 거의 듣지 못합니다. wget이 지원하는 프로토콜이 더 적다는 건 알지만, HTTP가 가장 복잡한 부분이라고 생각합니다. 기술 부채가 쌓인 거대한 코드베이스인가요? Daniel이 언젠가 일을 끝내고 다른 일로 넘어갈 수 있을까요? 네트워크를 다루는 C 코드의 특성일까요? 아니면 그가 글을 많이 써서 무슨 일이든 널리 알려지는 걸까요? 새로운 문제를 부르는 변경을 많이 하는 편인가요? 정말 궁금해서 묻습니다.
  • @Diana — 차이는 Daniel이 공개적으로 이야기하고, 공개성을 중요하게 여긴다는 점입니다. libcurl은 어디에나 쓰입니다. wget은 특별히 신경 쓰는 사람이 없습니다.
  • @tclancy — 두 번째 문단은 비누극의 절정 장면처럼 오케스트라 반주와 성우 내레이션이 어울리겠습니다. Daniel이 마땅히 받아야 할 사랑을 찾기를 바랍니다.
  • @evert — 하하, 조금 극적이긴 했네요.
  • @marginalia — curl은 명령줄 도구보다 libcurl 덕분에 더 중요합니다. libcurl은 xkcd #2347에 나온 기술의 전형이라고 할 만합니다.
  • @tclancy — 솔직히 말하면, 오래된 자료이긴 하지만 이 모든 일이 얼마나 말도 안 되게 어려울 수 있는지 처음 알게 해준 책은 《The Tangled Web》이었습니다. 지금은 에이전트가 PDF를 안전하게 읽게 하려고 Mythos와 씨름하며 글꼴을 배우고 있습니다. 글꼴은 안다고 생각했는데 말이죠!

원문: Daniel's blog / 번역·요약: Trawling