Rails Active Storage 취약점: 11월 7일 전에 확인해야 할 세 가지 설정

CVSS 9.8의 Rails Active Storage 취약점으로 이미지 업로드 한 번에 서버에 파일이 쓰일 수 있습니다. 세 가지 설정 점검과 업그레이드, Rails 8.0 지원 종료 일정을 정리했습니다.

프로필 사진, 문서, 상품 사진을 받는 Rails 애플리케이션은 거의 모두 해당 파일을 Active Storage로 처리합니다. 2026년 11월 4일, Rails 팀은 이 업로드 경로에 대한 심각한 보안 권고를 발표했습니다. 흔히 쓰이는 일부 구성에서는 조작된 업로드 하나만으로 인증되지 않은 공격자가 서버에 파일을 쓸 수 있습니다.

영향 여부는 쉽게 확인할 수 있는 세 가지 설정에 달려 있습니다. 이 글에서는 취약점의 내용과 각 설정의 확인 방법, 그리고 당장 업그레이드할 수 없을 때 취할 조치를 설명합니다. 특히 Rails 8.0을 사용하는 팀에게 중요한데, 이 브랜치의 보안 지원이 2026년 11월 7일에 종료되기 때문입니다.

취약점의 내용

파일이 첨부되면 Active Storage는 분석기를 실행해 이미지 크기 같은 기본 정보를 읽습니다. :mini_magick 프로세서를 사용하면 이 분석기가 파일을 ImageMagick에 넘깁니다. ImageMagick은 코더라는 모듈을 통해 다양한 형식을 지원하는데, 그중 일부는 매우 강력합니다. 수정 커밋에서는 업로드된 SVG가 MSL 코더에 도달하는 사례를 보여 줍니다. MSL은 스크립트에 지정된 파일을 읽고 쓸 수 있는 스크립트 형식입니다. Active Storage는 업로드가 도달할 수 있는 코더를 제한하지 않았기 때문에 서버의 ImageMagick 정책이 유일한 방어 수단이었습니다.

이 취약점을 심각하게 만드는 요소가 두 가지 있습니다. 첫째, 분석기는 첨부 시점에 실행되므로 variant나 미리보기, 명시적인 analyze 호출이 없어도 업로드를 받아들이는 것만으로 충분합니다. 둘째, Disk 서비스로 파일을 저장하는 애플리케이션은 애플리케이션 프로세스가 읽을 수 있는 모든 파일을 읽히게 될 수도 있습니다. 여기에는 secret_key_base와 다른 시스템의 자격 증명이 포함되며, 이는 원격 코드 실행이나 내부 확산으로 이어질 수 있습니다.

이 권고는 GMO Flatt Security의 RyotaK가 HackerOne을 통해 보고했습니다. Rails 팀은 보고된 공격 체인은 하나이지만 그것이 유일하다고 가정하지 않는다고 밝혔습니다. 권고에는 이 취약점이 실제로 악용되었는지 여부가 나와 있지 않습니다.

노출 여부를 판단하는 세 가지 조건

세 가지 조건이 모두 충족될 때만 영향을 받습니다. 순서대로 확인하십시오. 하나라도 해당하지 않으면 이 공격 체인은 적용되지 않지만, 그래도 업그레이드하는 것이 올바른 대응입니다.

조건	확인할 곳	노출되는 경우
1. Variant 프로세서	config.active_storage.variant_processor 및 load_defaults	값이 :mini_magick인 경우(load_defaults 6.1 이하의 기본값)
2. ImageMagick 정책	서버의 policy.xml	MSL, Ghostscript 코더, gs 델리게이트를 차단하지 않는 경우(Debian과 Ubuntu의 기본 정책은 차단하지 않음)
3. 업로드 가능한 사용자	업로드 폼과 API	신뢰할 수 없는 사용자가 파일을 첨부할 수 있는 경우

1. Active Storage는 어떤 프로세서를 사용하는가?

설정 파일을 검색하고, 실행 중인 애플리케이션에도 직접 확인합니다.

grep -rn "variant_processor\|load_defaults" config/
bin/rails runner 'p Rails.application.config.active_storage.variant_processor'

Rails 7.0부터 기본값은 :vips이지만, 이전 버전에서 업그레이드한 애플리케이션은 여전히 예전 기본값을 불러오거나 :mini_magick을 명시적으로 설정하는 경우가 많습니다. bundle info mini_magick도 확인하십시오. 이 gem이 번들에 포함되어 있다면 어디에서 사용되는지 파악해야 합니다.

2. ImageMagick 정책이 위험한 코더를 차단하는가?

각 애플리케이션 서버와 워커에서 ImageMagick이 실제로 불러오는 정책을 출력합니다.

magick -list policy      # ImageMagick 7
convert -list policy     # ImageMagick 6

MSL 코더, PostScript 및 PDF 코더, gs 델리게이트에 대해 rights="none" 규칙이 있는지 확인합니다. Debian이나 Ubuntu 패키지에 포함된 정책을 그대로 사용한다면 차단되지 않은 것으로 간주하십시오. 컨테이너 이미지와 워커 호스트에서는 웹 서버와 다른 ImageMagick 빌드가 실행되고 있을 수 있다는 점도 기억해야 합니다.

3. 신뢰할 수 없는 사용자가 파일을 업로드할 수 있는가?

파일이 attach, has_one_attached, has_many_attached에 도달하는 모든 지점을 나열하십시오. API, 다이렉트 업로드, 외부에서 파일을 가져오는 관리 도구도 포함됩니다. 아바터 입력란이 있는 공개 회원 가입은 신뢰할 수 없는 경로로 봐야 합니다.

해결 방법: 브랜치별 업그레이드 경로

수정된 릴리스는 Rails 8.1.4.1과 Rails 8.0.5.2입니다. 두 릴리스는 모두 21건의 보안 문제를 수정하므로, 이번 취약점에 노출되지 않았더라도 설치할 가치가 있습니다.

사용 중인 브랜치	조치
8.1	8.1.4.1로 업그레이드
8.0	지금 바로 8.0.5.2로 업그레이드한 뒤 8.1로의 전환을 계획(8.0의 보안 지원은 2026년 11월 7일 종료)
7.2 이하	수정 릴리스가 제공되지 않습니다. 아래의 정책 기반 우회책을 적용하고 8.0 이상으로 업그레이드

:mini_magick을 사용하는 애플리케이션은 mini_magick 5.1 이상도 필요합니다. 이전 버전에서는 수정 릴리스가 부팅 시 오류를 발생시키므로, 두 gem을 함께 업데이트하고 스테이징 환경에서 부팅을 테스트하십시오.

bundle update rails mini_magick
bundle info activestorage
bundle info mini_magick

수정 릴리스에는 자체 ImageMagick 정책이 포함되어 있지만, 그것이 실제로 ImageMagick에 적용되는지 확인해야 합니다. 애플리케이션이 부팅 후 MiniMagick.cli_env를 교체하거나, MiniMagick.cli_prefix를 사용하거나, 자체 MiniMagick::Shell을 설치하는 경우에는 적용되지 않으므로 시스템 정책에 규칙을 넣어야 합니다. GraphicsMagick은 ImageMagick 정책을 전혀 읽지 않습니다. 또한 포함된 정책은 서버의 policy.xml을 대체하지 않고 추가되는 방식이므로, 그곳에 와일드카드를 포함한 허용 규칙이 있으면 차단 규칙이 무시됩니다.

같은 릴리스에서 두 번째 취약점인 GHSA-v924-7rp8-4mxh(CVSS 8.8)도 수정되었습니다. Active Storage는 업로드된 파일을 원래 확장자를 유지한 임시 이름으로 ImageMagick과 FFmpeg에 전달했기 때문에, 파일 이름과 선언된 콘텐츠 유형을 조작할 수 있는 공격자가 어떤 디코더를 실행할지에 영향을 줄 수 있었습니다. 이 취약점에 대한 Rails의 우회책은 FFmpeg만 다루므로, 우회책에 의존하기보다 업그레이드해야 할 이유가 하나 더 있는 셈입니다.

일회성이 아닌 반복되는 패턴

2026년 7월에는 libvips를 사용하는 애플리케이션에 영향을 준 별도의 심각한 Active Storage 취약점 CVE-2026-66066이 있었습니다. ImageMagick을 사용하는 애플리케이션은 그 경로에는 노출되지 않았지만 이번 취약점에는 노출됩니다. 지원되는 두 이미지 라이브러리 모두를 통해 4개월 사이에 심각한 취약점이 두 건 나왔다는 사실은 같은 교훈을 줍니다. 이미지 처리는 넓은 공격 표면이며, Active Storage는 낯선 사람이 보낸 파일이 첨부되는 순간 그 처리를 실행합니다.

프로세서를 바꾸는 것만으로는 해결되지 않습니다. 진정한 방어는 이미지 라이브러리를 공격 표면의 일부로 다루는 데서 나옵니다. 프레임워크처럼 꾸준히 패치하고, 정책으로 제한하며, 어떤 호스트에서 실행되는지 파악해 두십시오. 특히 ImageMagick 정책은 애플리케이션 코드가 아니라 운영체제 이미지에 들어 있는 서버 설정이라 잊기 쉽습니다.

즉시 업그레이드할 수 없다면

Rails는 8.1과 8.0용 패치 커밋도 공개했습니다. 수정 릴리스를 배포할 수 있을 때까지 다음 체크리스트를 진행하십시오.

1. 업로드를 처리하는 모든 호스트에서 권고에 제시된 최소 규칙을 ImageMagick 시스템 정책(예: /etc/ImageMagick-7/policy.xml)에 추가합니다.
2. 같은 파일의 허용 규칙이나 와일드카드가 이를 덮어쓰지 않는지 확인한 뒤 magick -list policy로 검증합니다.
3. ImageMagick으로 PDF나 PostScript를 렌더링한다면 gs 델리게이트와 꼭 필요한 코더만 다시 허용하고, 이로 인해 일부 위험이 남는다는 점을 감수해야 합니다.
4. 업로드를 통제합니다. 파일을 첨부할 수 있는 사용자를 일시적으로 제한하거나 익명 업로드를 중단합니다.
5. Disk 서비스를 사용한다면 secret_key_base, 마스터 키, config/credentials.yml.enc의 내용, 스토리지 및 데이터베이스 자격 증명, 서드파티 토큰의 교체를 계획합니다. 노출된 시크릿을 대체 수단으로 남겨 두지 마십시오.

권고에 공개된 최소 규칙은 다음과 같습니다.

<policy domain="coder" rights="none" pattern="MSL"/>
<policy domain="delegate" rights="none" pattern="gs"/>
<policy domain="coder" rights="none" pattern="{PS,PS2,PS3,EPS,EPS2,EPS3,EPI,EPSF,EPSI,EPT,EPT2,EPT3,PDF,AI,EPDF,PDFA,POCKETMOD,XPS,PCL}"/>

자세한 내용은 Rails 보안 권고에서 확인하십시오.

LOGIQ가 도울 수 있는 부분

LOGIQ는 운영체제 이미지부터 애플리케이션 런타임까지, Linux에서 오픈소스 스택을 운영하는 팀을 지원합니다. 여러 서버의 ImageMagick 정책 점검이나 지원이 끝나는 브랜치에서의 전환 계획에 도움이 필요하시면 저희 팀에 문의해 주십시오.