Rails Active Storage CVE-2026-66066, 패치 뒤 포렌식까지 확인하세요

7월 31일에 바뀐 것은 공격 상세와 조사 방법의 공개예요

Rails는 7월 29일 CVE-2026-66066 보안 권고를 내고 수정 버전을 공개했어요. 처음에는 공격 경로의 상세 설명을 8월 28일까지 미룰 계획이었지만, 여러 연구자가 빠르게 역분석해 공개 PoC를 내놓자 7월 31일 공식 설명과 포렌식 도구를 앞당겨 공개했습니다.

따라서 이번 새 정보의 핵심은 취약점이 처음 발견됐다는 데 있지 않아요. 이미 패치한 운영자도 과거 노출 기간과 흔적을 확인할 수 있는 공식 동선이 생겼다는 점이 중요합니다. 공개 기사에서는 공격 파일 제작법 대신 방어와 조사 순서만 다뤄야 해요.

• 공식 심각도 — Critical, CVSS v4 9.5
• 7월 29일 — 영향 조건과 수정 버전이 담긴 공식 권고 공개
• 7월 31일 — 공격 상세와 공식 포렌식 저장소 조기 공개
• 주의 — 공개 PoC 존재와 실제 침해 확인은 서로 다른 사실

먼저 우리 앱이 두 가지 영향 조건을 모두 충족하는지 봐요

공식 권고가 지목한 환경은 Active Storage 이미지 처리에 libvips를 사용하고, 신뢰할 수 없는 사용자가 이미지를 올릴 수 있는 Rails 앱이에요. Rails 7.0 기본값을 불러온 앱은 :vips가 기본 처리기일 수 있지만, 모든 Rails 앱이 자동으로 영향받는 것은 아닙니다.

별도로 variant를 직접 생성하는 코드를 찾지 못했다고 안전하다고 결론 내리면 안 돼요. Rails 권고는 variant 생성이 별도 요구조건이 아니라고 명시합니다. 반대로 ImageMagick이나 다른 업로드 경로까지 이 CVE 하나로 모두 취약하다고 확대해서도 안 됩니다.

1. 운영 환경의 Active Storage와 Rails 버전 확인하기
2. variant_processor가 :vips인지 설정과 실제 배포 환경에서 확인하기
3. 비회원·일반 사용자를 포함한 비신뢰 이미지 업로드 경로 목록 만들기
4. ruby-vips와 시스템 libvips 버전을 각각 확인하기

Active Storage와 libvips를 함께 맞춰야 패치가 끝나요

공식 수정 Active Storage 버전은 7.2.3.2, 8.0.5.1, 8.1.3.1이에요. 사용 중인 지원 분기에서 이 버전 이상으로 올리고, 시스템의 libvips도 8.13 이상으로 맞춰야 합니다. Rails나 Active Storage만 올린 채 오래된 libvips를 남기면 충분하지 않아요.

지원이 끝난 오래된 Rails 분기를 계속 쓰거나 지금 바로 올리기 어려운 환경이라면 공식 권고의 우회 조건을 그대로 검토해야 합니다. libvips 8.13 미만에는 차단 환경변수만 추가하는 우회가 통하지 않으며, 공식 권고는 해당 의존성 제거 외의 우회를 제시하지 않습니다. 변경 뒤에는 재배포와 정상 부팅까지 확인하세요.

• Active Storage 7.2 계열 — 7.2.3.2 이상
• Active Storage 8.0 계열 — 8.0.5.1 이상
• Active Storage 8.1 계열 — 8.1.3.1 이상
• 시스템 libvips — 8.13 이상

정리 작업 전에 증거를 보존하고 공식 도구의 한계를 기록해요

Rails 공식 포렌식 저장소는 먼저 앱이 언제 취약했는지 확인하고, 그다음 Active Storage 데이터에서 조작된 파일과 읽힌 정보의 단서를 찾는 두 단계 흐름을 제공합니다. Rapid7은 연결되지 않은 blob을 지우는 예약 작업이 증거를 없앨 수 있으므로 조사를 빨리 시작하라고 권고했어요.

가능한 범위에서 DB, 오브젝트 스토리지, 접근 로그의 보존 시점을 남긴 뒤 공식 문서를 따라가세요. 다만 증거 보존 준비가 긴급 패치를 오래 늦추게 해서는 안 됩니다. 공식 저장소도 깨끗한 결과는 강한 증거일 뿐, 도구 범위 밖 경로나 이미 삭제된 흔적까지 부정하는 완전한 증명이 아니라고 설명합니다.

영향 조건을 충족했다면 패치 뒤 비밀정보 교체까지 계획해요

취약한 기간에 애플리케이션 프로세스가 읽을 수 있었던 secret_key_base, Rails master key와 복호화되는 credentials, 스토리지·DB 자격증명, 외부 서비스 토큰은 잠재적으로 노출됐다고 보고 교체 순서를 세워야 해요. 패치는 앞으로의 파일 읽기를 막지만 이미 유출된 값을 회수하지는 못합니다.

secret_key_base를 바꾸면 사용자의 활성 세션이 끝나고 암호화·서명 쿠키, signed global ID, Active Storage URL에도 영향이 생겨요. 유지보수 공지, 강제 재로그인, 연결 시스템 로그 확인을 함께 준비하세요. Rapid7이 7월 30일 기준 실제 악용을 인지하지 못했다는 관측만으로 이 단계를 생략해서는 안 됩니다.

1. 현재와 과거 배포의 영향 조건과 노출 기간 정리하기
2. 패치와 libvips 버전 수정 뒤 재배포·부팅 확인하기
3. 공식 도구 결과와 조사 범위·한계를 기록하기
4. 비밀정보를 의존 순서에 맞춰 교체하고 연결 시스템 로그 확인하기
5. 세션 종료와 서명 URL 영향까지 사용자 안내에 반영하기