OpenAI·Anthropic이 못 찾은 curl 취약점 6건, 전문 에이전트가 포착

널리 감사된 오픈소스에서도 모델보다 분석 시스템의 설계가 결과를 가를 수 있다는 사례가 나왔다. AISLE은 OpenAI Codex Security와 Anthropic Mythos가 curl에서 추가 발견이 없다고 보고된 직후 자체 자율 분석 시스템을 투입했고, 29개 의심 항목을 제출했다고 밝혔다. curl 보안팀은 그중 여섯 건에 CVE를 부여해 curl 8.22.0에서 수정했다.

여섯 건은 CVE-2026-80229, 80230, 80231, 80255, 82208, 82209다. OpenSSL provider의 use-after-free, 공개키 고정 우회, 운영체제 기본 CA 저장소 설정이 다른 연결의 잘못된 재사용, 탭 문자를 이용한 secure 쿠키 속성 우회, wolfSSL CA 캐시와 검증 callback 충돌, Public Suffix List 경계의 쿠키 처리 문제를 포함한다. curl 공식 보안 목록에서도 여섯 건 모두 AISLE 연구자 Stanislav Fort의 제보로 기록돼 있다.

성과의 크기와 위험도는 따로 봐야 한다. 여섯 취약점은 모두 심각도 Low다. 일부는 특정 TLS backend나 연결 재사용 조건이 필요하고, 공격자가 이용하려면 제한된 환경이 맞아야 한다. 다만 ‘낮음’은 오탐이라는 뜻이 아니다. curl 유지관리자가 재현하고 보안 문제로 인정했으며 패치와 권고를 배포했다. 예를 들어 CVE-2026-80229는 curl 8.14.0부터 8.21.0까지 영향을 주는 heap use-after-free이고, OpenSSL 3 provider와 multi interface를 함께 쓰는 상황에서 발생한다.

비교가 관심을 받은 이유는 기준점의 시점이 공개돼 있었기 때문이다. curl 창립자 Daniel Stenberg는 8월 24일 Mythos와 Codex Security의 추가 발견 목록이 비어 있다고 적었다. AISLE은 이후 분석을 시작했고 8월 24일부터 27일 사이 여섯 문제를 제보했다. 9월 2일 공개된 curl 8.22.0은 모두 수정했으며, 해당 버전의 공식 릴리스 표에는 총 아홉 건의 보안 문제가 반영돼 있다. 이 중 여섯 건이 AISLE 제보다.

그렇다고 이 결과 하나로 특정 모델의 보안 능력을 서열화하기는 어렵다. 각 시스템이 받은 코드 범위, 실행 시간, 도구 권한, 후보를 검증하는 절차가 같았는지 공개 정보만으로는 알 수 없다. AISLE의 29개 보고 중 당시 며칠 안에 CVE로 확인된 것은 여섯 건이므로, 후보 생성 수 자체도 정확도 지표가 아니다. 회사가 자사 제품을 설명한 글에서 제시한 비교라는 점도 고려해야 한다. 독립된 재현 자료와 동일 조건의 평가가 있어야 탐지율을 공정하게 비교할 수 있다.

실무 교훈은 더 단순하다. 보안 분석에서 큰 모델 한 번의 ‘0건’은 안전 증명이 아니다. 정적 분석, fuzzing, 설정별 실행, 여러 모델, 사람이 하는 재현과 패치 검토를 겹쳐야 빈틈이 줄어든다. 커뮤니티는 AISLE이 어떤 모델을 썼는지보다 후보를 실제 CVE까지 밀어 올린 검증 파이프라인을 파고들었다. curl 사용자는 비교 논쟁과 별개로 8.22.0 이상으로 올리거나 공식 패치를 적용하는 것이 우선이다.