Ruby on Rails 파일 읽기 취약점(CVE-2026-66066)｜노출 조건과 대응

취약점의 성립 조건

Ruby on Rails 보안팀은 Active Storage가 libvips를 이용해 이미지 변형을 수행하는 경로에서 임의 파일 읽기로 이어지는 CVE-2026-66066을 공개했습니다. 이 문제는 Rails 설치만으로 성립하지 않습니다. 취약한 Active Storage 분기, `:vips` 변형 처리기, 공격자가 제어하는 이미지 업로드, 신뢰되지 않은 로더 동작이 함께 맞물려야 합니다. 조건이 충족된 서비스에서는 애플리케이션 프로세스가 읽기 가능한 파일과 환경 변수가 노출될 수 있고, `secret_key_base`나 외부 서비스 자격증명까지 이어지면 서명 데이터 위조와 후속 침투의 기반이 됩니다. 버전 확인, 업로드 경로, 변형 처리, 저장소 흔적, 비밀정보 교체를 하나의 대응 흐름으로 묶어야 하는 이유입니다.

영향 분기와 수정 버전

공식 권고가 제시한 영향 범위는 Active Storage 7.2.3.2 미만, 8.0 계열의 8.0.5.1 미만, 8.1 계열의 8.1.3.1 미만입니다. 수정판은 각각 7.2.3.2, 8.0.5.1, 8.1.3.1입니다. 애플리케이션의 Gemfile.lock에서 실제 배포된 `activestorage` 버전을 확인하고, 런타임 설정에서 `config.active_storage.variant_processor = :vips`를 사용하는지 대조합니다. Rails 메타 버전만 보면 엔진별 잠금 파일이나 부분 업그레이드 차이로 실제 분기를 놓칠 수 있습니다. 컨테이너 환경은 저장소 선언값과 실행 중 이미지의 잠금 파일이 같은지, 롤링 배포 뒤 구형 파드가 남았는지까지 확인해야 합니다.

업로드 기능의 노출 범위

프로필 사진, 게시물 첨부, 고객지원 파일, 상품 이미지처럼 업로드 직후 자동 썸네일이나 미리보기를 만드는 기능이 우선 점검 대상입니다. MIME 형식과 실제 콘텐츠가 다른 파일을 거부하는지, 어떤 백그라운드 작업이 변형을 생성하는지, 원본이 로컬 디스크·S3 호환 저장소·클라우드 버킷 중 어디에 남는지를 기록하면 공격 가능성과 분석 범위를 좁힐 수 있습니다. 내부 업무 서비스라도 고객·협력사·위탁 운영자가 파일을 올릴 수 있으면 같은 경계를 적용합니다. CDN이나 프록시가 원본 업로드 경로를 감추는 경우에는 애플리케이션 라우트와 직접 업로드 URL을 함께 확인해야 합니다.

libvips 로더 경계

조작된 파일은 표면적으로 이미지처럼 보이면서 MATLAB/HDF5 계열 로더의 외부 파일 참조 기능을 이용할 수 있습니다. libvips가 해당 로더를 신뢰된 경로처럼 처리하면 Rails 프로세스 권한으로 호스트 파일을 읽고, 변형 결과나 오류 응답을 통해 내용을 되돌릴 수 있습니다. 웹 요청 계층의 확장자 검사만 강화해서는 충분하지 않습니다. Rails 보안팀은 Rails 수정판과 함께 libvips 8.13 이상을 사용하도록 안내합니다. libvips 8.13 이상에서는 `VIPS_BLOCK_UNTRUSTED`를, ruby-vips 2.2.1 이상에서는 `Vips.block_untrusted(true)`를 적용해 신뢰되지 않은 로더를 차단할 수 있습니다.

기능 회귀 시험

로더 차단은 운영에서 사용하는 이미지 형식과 변형 작업을 검증한 뒤 적용합니다. JPEG·PNG·WebP 등 허용 형식의 업로드, 원본 저장, 썸네일 생성, 방향 정보 처리, CDN 전달을 차례로 시험합니다. 차단된 로더가 호출되면 작업 큐와 애플리케이션 모니터링에 오류가 남는지도 확인합니다. 스테이징에서 성공한 설정이라도 운영 노드의 libvips 빌드 옵션과 라이브러리 패키지가 다를 수 있으므로 실행 파일 버전과 로더 목록을 배포 기록에 남깁니다. 이미지 처리 전용 워커를 분리한 환경은 웹 노드와 워커 노드의 Gem·libvips 조합을 각각 확인해야 합니다.

공식 포렌식 도구

Rails 보안팀은 `rails-forensics-CVE-2026-66066` 저장소를 공개했습니다. 이 도구는 취약 가능 기간을 계산하고 Active Storage 데이터베이스와 객체 저장소에서 의심 파일을 검색하는 데 초점을 둡니다. 운영 데이터베이스와 저장소에는 읽기 전용 자격증명을 사용하고, 원본 메타데이터·객체 키·생성 시각·해시를 먼저 보존합니다. 파일을 삭제하거나 재인코딩하면 외부 참조 구조와 업로드 시각을 잃을 수 있으므로 격리 사본을 만든 뒤 도구 결과와 웹·작업 큐 로그를 대조합니다. 같은 저장소를 여러 Rails 서비스가 공유하면 객체 키의 소유 애플리케이션과 처리 노드를 구분해 검색 범위를 나눕니다.

활동 연결과 영향 판단

의심 파일이 발견되면 업로드 요청의 계정, IP, 사용자 에이전트, 콘텐츠 유형, 실제 파일 시그니처와 변형 작업 시각을 연결합니다. Active Job·Sidekiq 같은 작업 큐 기록, 저장소 접근 로그, 애플리케이션 오류, 변형 결과 다운로드를 함께 보면 파일이 저장만 됐는지 로더 실행까지 도달했는지 구분할 수 있습니다. 오류 응답이나 재시도가 반복된 계정은 같은 시각의 인증 기록과 권한 변경을 추가로 대조합니다. 검색 결과를 단순 파일명 일치로 확정하지 말고 공식 도구의 구조 검사, 원본 해시, 요청 흐름을 함께 기록해야 오탐을 줄일 수 있습니다.

비밀정보 교체

파일 읽기 경로가 성립한 서비스는 패치와 함께 Rails 프로세스가 읽을 수 있었던 비밀정보를 교체합니다. `secret_key_base`, Rails credentials 키, 데이터베이스·객체 저장소·메일·결제·OAuth 자격증명을 목록화합니다. 새 키를 먼저 발급하고 의존 서비스를 전환한 뒤 이전 키를 폐기하며, 세션과 서명 쿠키를 무효화해 탈취된 서명 재료의 재사용을 줄입니다. 외부 서비스 키는 사용 이력과 권한 범위를 확인한 뒤 최소 권한으로 재발급합니다. 키를 바꾸는 순서를 잘못 잡으면 서비스 중단이 생길 수 있으므로 발급·배포·검증·폐기를 구분하고 각 단계의 완료 시각을 남깁니다.

우선순위와 임시 통제

업로드 기능이 외부에 열려 있고 자동 변형이 실행되는 서비스, 비밀정보가 많은 단일 프로세스, 같은 키를 여러 애플리케이션이 공유하는 환경을 먼저 처리합니다. 유지보수 창까지 시간이 필요하면 신뢰되지 않은 업로드의 변형 작업을 멈추고 업로드 권한을 제한하며 비신뢰 로더 차단을 적용합니다. 이 통제는 공식 수정판을 대신하지 않습니다. 큐에 이미 들어간 변형 작업과 저장소의 기존 원본은 통제 이후에도 처리될 수 있으므로 작업 큐를 비우는 방식과 재개 조건을 함께 정합니다. 노출 경로 차단 전후의 요청·작업·저장소 로그를 보존해 통제 시점을 명확히 남깁니다.

적용 후 검증과 기록

배포된 Active Storage가 해당 분기의 수정판인지, libvips가 8.13 이상인지, 비신뢰 로더 차단이 실제 워커에 적용됐는지 확인합니다. 허용 이미지의 업로드·변형·저장소·CDN 전달을 회귀 시험하고, 공식 포렌식 도구 결과를 웹·작업 큐·저장소 로그와 대조합니다. 마지막으로 새 비밀정보가 모든 노드에 반영되고 이전 값이 폐기됐는지 확인합니다. 변경 기록에는 Gem 잠금 파일, 컨테이너 이미지 식별자, libvips 버전, 시험 파일, 검색 범위와 키 교체 완료 시각을 남깁니다. 이렇게 해야 수정판 적용, 기능 복구, 과거 악용 분석, 자격증명 폐기를 하나의 증거 흐름으로 관리할 수 있습니다.

배포 파이프라인과 재노출 방지

수정판 적용 뒤에도 오래된 컨테이너 이미지, 자동 확장 템플릿, 재해복구 레지스트리와 개발 환경의 잠금 파일이 남으면 취약 분기가 다시 배포될 수 있습니다. CI 파이프라인에서 Active Storage와 libvips의 최소 버전을 검사하고, 배포 승인 단계에서 이미지 다이제스트와 Gem 잠금 파일 해시를 기록합니다. 업로드 전용 워커와 웹 노드가 서로 다른 이미지를 사용하면 두 배포 선언을 모두 갱신하며, 작업 큐에 남은 변형 요청이 구형 워커로 전달되지 않도록 큐 소비자 버전도 확인합니다. 스케일 아웃·노드 교체·재해복구 전환을 한 차례씩 시험해 새 인스턴스가 수정된 조합으로 시작되는지 검증해야 대응이 지속됩니다.

1. 배포된 Active Storage 분기와 수정 버전을 확인합니다.
2. libvips 8.13 이상과 비신뢰 로더 차단을 검증합니다.
3. 공식 포렌식 도구로 Active Storage 데이터와 객체 저장소를 검색합니다.
4. 웹·작업 큐·저장소 로그를 시간대별로 연결합니다.
5. 노출됐을 가능성이 큰 Rails·데이터베이스·스토리지·외부 서비스 키를 교체합니다.