AI가 찾은 오픈소스 취약점 1,726건, 금융권이 긴급 점검에 들어갔다

AI가 오픈소스 취약점을 대량으로 찾아낸 뒤 금융권이 움직임

• 앤트로픽의 클로드 미토스 프리뷰가 찾아낸 오픈소스 취약점 공개 이후, 금융권에 긴급 점검 지시가 내려옴

  • 금융보안원은 관련 위협 분석 보고서를 통해 주요 취약점 정보를 공유하고 선제 대응을 주문함
  • 금융감독원도 금융사에 공문을 보내 오픈소스 점검과 최신 보안 패치 적용을 권고함
  • 국내 금융 서비스에 당장 큰 영향을 줄 취약점은 없다고 봤지만, 취약 제품을 쓰는지는 빨리 확인하라는 입장임

• 숫자가 꽤 세다. 미토스가 1,000개 이상 오픈소스를 스캔해 결함 후보 2만3,019개를 찾았음

  • 외부 전문가가 이 중 1,900건을 검증함
  • 1,726건이 실제 취약점으로 확정됨
  • 제조사에 공식 전달된 건 1,596건
  • 현재 패치 완료된 취약점은 97건뿐이라 패치율은 6.1%에 그침

• 취약점 유형도 만만하지 않음
  • 전체 중 28.9%인 462건은 힙·스택 버퍼 오버플로우 같은 치명적 메모리 안전성 결함임
  • 인증 우회와 권한 상승 같은 접근제어 취약점도 270건으로 16.9%를 차지함
  • 단순 경고성 이슈가 아니라 실제 공격으로 이어질 수 있는 부류가 꽤 많이 나온 셈임

nginx, wolfSSL, FreeRDP, Ghost까지 이름이 올라옴

• 공개된 주요 취약점 27개 중에는 널리 쓰이는 인프라 구성요소도 포함됨

  • nginx WebDAV 모듈에서는 alias 지시문을 사용할 때 짧은 Destination 요청으로 인증 없는 원격 파일 쓰기가 가능해질 수 있는 취약점이 확인됨
  • 해당 취약점은 CVE-2026-27654로 언급됐고, WebDAV 모듈이 활성화된 경우에만 영향을 줌
  • 그래서 무작정 nginx 전체를 겁낼 일은 아니지만, 자사 설정에서 WebDAV가 켜져 있는지는 바로 봐야 함

• 다른 구성요소의 취약점도 금융권 입장에서는 체크리스트에 들어갈 만함

  • wolfSSL에서는 verify_cb가 1을 반환할 때 X509 리프 인증서의 서명 검증을 건너뛰는 결함이 발견됨
  • FreeRDP에서는 클립보드 채널 검증 누락으로 인한 원격 코드 실행 취약점이 언급됨
  • Node.js 기반 콘텐츠 관리 시스템 Ghost에서는 인증 없이 데이터베이스의 민감 레코드를 탈취할 수 있는 SQL 인젝션 결함이 나옴

• 금융보안원이 강조한 건 결국 자산 식별임

  • 국가 취약점 데이터베이스 기준으로 연간 3만건 이상 CVE가 쏟아지는 상황에서 모든 취약점에 똑같이 대응하는 건 불가능함
  • 먼저 우리 조직이 어떤 오픈소스 구성요소를 쓰는지 알아야 함
  • 그다음 인터넷 노출 여부, 데이터 민감도, 실제 사용 기능 같은 환경 맥락을 붙여야 대응 우선순위가 나옴

이제 오픈소스 보안은 “패치 관리”만으로 부족함

• 패치가 아직 없는 취약점도 많기 때문에 임시 방어가 중요해짐

  • 금융보안원은 패치 전이라도 기능 격리나 임시 우회 같은 운영 환경 맞춤 조치가 필요하다고 봄
  • 단순히 취약 버전 여부만 보는 방식보다, 실제 공격 가능 경로를 줄이는 쪽이 중요해졌다는 뜻임
  • 에스비오엠을 통한 자산 식별이 선행돼야 한다는 지적도 이 맥락임

• 전문가 코멘트도 꽤 강함. AI가 오픈소스 취약점 점검의 판을 바꿀 수 있다는 얘기임

  • 기사에서는 AI를 통해 소수 오픈소스 프로젝트를 점검했는데도 주요 취약점이 대거 나왔다는 점을 강조함
  • 지금까지 집단지성에 기대던 오픈소스 취약점 발견 방식이 바뀔 수 있다는 우려가 나옴
  • 앞으로 개발자와 운영자가 모르는 제로데이 취약점이 계속 드러날 수 있다는 전망도 제기됨

• 한국 개발자에게도 바로 연결되는 이슈임

  • nginx, wolfSSL, FreeRDP, Ghost 같은 구성요소는 특정 국가만의 문제가 아님
  • 금융권뿐 아니라 일반 서비스 회사도 오픈소스 구성요소 목록과 노출 상태를 제대로 관리하지 않으면 같은 압박을 받게 됨
  • “우리는 취약점 스캐너 돌려요”에서 끝내기엔 발견 속도가 너무 빨라지고 있음

---

기술 맥락

• 이번 사건의 핵심은 AI가 취약점을 찾았다는 사실보다, 취약점 처리 파이프라인이 그 속도를 따라갈 수 있느냐예요. 후보 2만3,019개 중 1,726건이 실제 취약점으로 확정됐고, 제조사 전달 1,596건 중 패치 완료가 97건이라는 숫자가 그 격차를 보여줘요.

• 그래서 금융보안원이 에스비오엠을 강조하는 거예요. 취약점이 공개됐을 때 우리 조직이 해당 컴포넌트를 쓰는지 모르면, 패치 여부 판단도 우회 조치도 시작할 수 없거든요. 자산 식별이 보안 대응의 첫 단계가 되는 이유예요.

• nginx WebDAV 사례처럼 취약점은 제품명만으로 판단하면 안 돼요. 특정 모듈이 켜져 있는지, alias 지시문 같은 설정이 있는지, 외부에서 접근 가능한지에 따라 실제 위험이 달라져요. 같은 버전을 써도 운영 맥락에 따라 우선순위가 달라지는 거죠.

• 패치가 나오기 전에는 기능 격리나 임시 우회가 현실적인 선택이 될 수 있어요. 이때 필요한 건 취약점 목록 자체가 아니라, 어떤 서비스가 어떤 구성요소를 어떤 데이터와 함께 쓰는지에 대한 운영 맥락이에요.