2026년 11월 3일 Django 프로젝트가 6.1.3, 6.0.10, 5.2.19 보안 업데이트를 공개했습니다. 이번 릴리스는 총 6건의 보안 문제를 수정합니다. 업로드 파일 처리 과정의 메모리 사용량 문제, GeoDjango의 외부 요청 유발 위험, 특정 캐시 구성의 개인정보 노출 가능성 등이 포함돼 있습니다. 공식 발표는 지원되는 Django 사용자가 가능한 한 빨리 업데이트할 것을 권고합니다.
하지만 모든 웹사이트가 여섯 가지 취약점에 동일한 정도로 노출되는 것은 아닙니다. GeoDjango를 쓰는지, 캐시를 사용하는지, 어떤 방식으로 모델과 관리자 권한을 구성했는지에 따라 조건이 달라집니다. 아래에서 원인을 간단히 구분하고 기존 Python 프로젝트에 안전하게 적용하는 방법을 설명합니다.
업데이트 날짜와 지원되는 수정 버전
공식 발표일은 2026년 11월 3일입니다. Django 6.1 계열은 6.1.3으로, 6.0 계열은 6.0.10으로, 5.2 계열은 5.2.19로 보안 패치가 배포됐습니다. 프로젝트의 Python 버전·서드파티 패키지 호환성을 먼저 점검한 뒤 사용 중인 지원 계열에서 수정 버전으로 업데이트하세요. 단순히 숫자가 가장 큰 버전으로 바꾸는 것이 항상 안전한 배포 전략은 아닙니다.
10월 6일 출시된 Django 6.1.2·6.0.9·5.2.18 보안 업데이트와는 별개의 새로운 보안 릴리스입니다. 이전 버전의 패치를 완료했더라도 11월 수정 사항이 자동으로 포함되는 것은 아니므로 실제 배포 버전을 다시 확인해야 합니다.
수정된 보안 문제 여섯 가지
CVE-2026-108147은 multipart 업로드에서 base64로 인코딩된 파일 내용을 메모리에 통째로 보관해 메모리 사용량이 커질 수 있었던 문제입니다. CVE-2026-111211은 잘못된 지오메트리 입력을 로그에 기록할 때 줄바꿈·제어문자를 정리하지 않아 로그 위조가 가능했던 문제입니다. 공식 분류에서 두 건의 심각도는 낮음(low)입니다.
CVE-2026-111362는 GeoJSON의 CRS 정보가 외부 URL을 참조하는 경우 GDAL을 통해 원치 않는 네트워크 요청이나 파일 읽기를 유발할 수 있었던 SSRF 문제입니다. 공식 분류는 보통(moderate)입니다. 일반 Django 프로젝트보다 사용자가 제공한 공간 정보를 처리하는 GeoDjango 서비스에서 특히 구성 확인이 중요합니다.
CVE-2026-113593은 응답의 Vary 헤더에 지정된 요청 헤더가 아예 없는 경우와 빈 값으로 들어온 경우를 캐시가 동일하게 취급해 다른 사용자에게 캐시 결과가 반환될 수 있었던 문제입니다. CVE-2026-113733은 특정 사용자 모델 설정에서 보기 전용 관리자에게 비밀번호 해시가 드러날 가능성이 있었던 문제입니다. 두 건 모두 공식 분류는 낮음입니다.
CVE-2026-114582는 GeoDjango의 SpatialReference 등에서 전달된 문자열을 GDAL이 URL 또는 파일 경로로 해석해 외부 요청이나 파일 읽기가 발생할 수 있었던 문제입니다. 수정 후 완전한 보호를 위해서는 GDAL 3.9 이상이 필요합니다. Django의 새 gis.W001 시스템 검사는 낮은 GDAL 버전을 알려줍니다. GeoDjango를 이용하지 않는 프로젝트까지 모두 GDAL 업그레이드를 해야 한다는 뜻은 아닙니다.
내 프로젝트의 Django 버전 확인
배포 서버와 로컬 개발 환경의 버전이 같다고 가정하지 말고 각각 확인합니다. 가상환경을 활성화한 뒤 아래의 읽기 전용 명령을 실행하면 설치된 Django 버전과 패키지 정보를 확인할 수 있습니다.
python -m django --version
python -m pip show Django
CI·컨테이너 이미지·호스팅에서 프로젝트를 실행한다면 requirements.txt, pyproject.toml, poetry.lock, uv.lock 등 실제로 배포에 쓰이는 의존성 파일도 확인합니다. 개발 PC의 pip 출력만 보고 운영 서버까지 안전하다고 결론 내리면 안 됩니다.
스테이징 환경에서 안전하게 패치하는 순서
먼저 데이터베이스와 업로드 파일을 백업하고 새 브랜치·스테이징 환경에서 수정 버전을 설치합니다. 예를 들어 기존 5.2 계열을 유지한다면 python -m pip install "Django==5.2.19"로 테스트할 수 있습니다. 6.0과 6.1을 사용하는 프로젝트는 각각 6.0.10, 6.1.3을 선택하세요. 프로젝트가 사용하는 의존성 관리 도구가 별도로 있다면 그 도구에서 잠금 파일도 함께 갱신해야 합니다.
그 다음 python manage.py check와 프로젝트의 기존 테스트를 실행합니다. 인증·로그인, 관리자 권한, 파일 업로드, 민감한 데이터가 포함된 캐시 화면, GeoDjango의 좌표계 변환 등 실제로 사용하는 기능을 중심으로 점검합니다. 새 패치에서 외부 CRS URL을 받지 않도록 변경됐으므로, 그런 입력에 의존하던 기존 애플리케이션에는 호환성 점검이 필요할 수 있습니다.
운영 서버 적용 후 무엇을 검증해야 할까?
스테이징 검증이 끝나면 운영 환경에 배포하고, 운영 서버 안에서 다시 버전을 확인합니다. 오류 로그, 요청 응답, 캐시가 관련된 페이지, 공간 정보 기능과 관리자 권한을 확인합니다. 문제가 있다면 백업·버전 관리 기록을 참고해 이전 안정 상태로 복구할 수 있어야 합니다. 무조건 패치를 되돌리기보다 원인 파악과 최소 변경에 집중하는 것이 좋습니다.
기존 내용을 비교하려면 10월 Django 보안 취약점 4건 수정 안내와 Django 구현·오류 해결 읽기 안내를 참고하세요. 날짜와 버전이 다르기 때문에 각각의 글을 최신 패치에 맞춰 구분해 읽는 것이 중요합니다.
출처와 확인일
1차 출처는 Django 프로젝트 공식 보안 발표(2026.11.03)입니다. 심각도, 영향받는 기능, 배포 버전은 이 발표 기준으로 정리했습니다. 버전 지원과 설치 호환성은 Django 공식 설치 문서를 함께 확인하세요. 이 글의 정보 확인일은 2026년 11월 6일입니다.