- PyPI는 토큰이나 배포 워크플로가 탈취돼도 안정된 기존 릴리스가 오염되지 않도록, 게시 후 14일이 지난 릴리스의 새 파일 업로드를 차단함
- 현재까지 실제 악용 사례는 확인되지 않았지만, 공격자가 가능성을 몰랐다는 점 외에는 공격을 막을 기술적 장벽이 없었음
- 상위 15,000개 패키지를 조사한 결과, 릴리스 14일 후 Python 3.14용
cp314휠을 추가한 프로젝트는 56개에 그쳤음 - 기존 릴리스에 새 Python 버전 지원을 추가하던 프로젝트는 이제 다음 버전을 배포해야 하며, PyCon US 2026 Packaging Summit에서도 이를 수용 가능한 방안으로 판단함
- 아직 릴리스의 개방·폐쇄 상태를 정의하거나 확인할 API가 없으므로 이 동작에 의존하면 안 되며, 향후 PEP 694의 Upload 2.0 API와 Staged Previews가 관련 의미 체계를 정립할 예정임
오래된 릴리스를 닫는 이유
- PyPI의 변경은 오래되고 안정된 릴리스에 새 파일을 올리는 경로를 차단함
- 프로젝트의 게시 토큰이나 워크플로가 침해되더라도 기존 릴리스 일부만 악성 파일로 교체되는 상황을 방지함
- 릴리스 안에 침해된 파일과 그렇지 않은 파일이 섞이는 불명확한 상태를 막고, PyPI 관리자의 정리 작업도 줄임
- 논의는 PEP 740 Digital Attestations 작업 중이던 2024년 1월 시작됐고, 2026년 3월 재개됨
- 계기는 LiteLLM과 Telnyx 공급망 침해였으며, 두 프로젝트가 사용한 Trivy GitHub Action의 변경 가능한 참조(mutable reference)가 원인이었음
- 일부 프로젝트가 이미 게시된 릴리스에 새 Python 버전 지원 파일을 추가하고 있어 초기 논의가 중단됨
- 변경의 영향을 파악하기 위해 PyPI 데이터베이스에서 오래된 릴리스에 파일을 추가한 프로젝트를 경과 일수별로 조사함
- 상위 15,000개 패키지의
cp314휠을 별도로 확인한 결과, 14일 이후 Python 3.14 호환 휠을 게시한 프로젝트는 56개였음
적용 결정과 향후 API
- PyCon US 2026 Packaging Summit에서는 새 Python 버전을 지원할 때 다음 버전으로 올리도록 요구해도 수용 가능하다는 대략적인 합의가 형성됨
- 조사 데이터와 합의를 바탕으로 Warehouse 패치가 추진됐으며, 2026년 7월 8일 병합됨
- 현재 제한은 아직 안정적인 인터페이스로 간주할 수 없음
- “더 이상 새 파일을 받지 않는 릴리스”의 정의가 확정되지 않았고, 상태를 확인할 API도 없음
- PEP 694가 Upload 2.0 API와 Staged Previews를 표준화한 뒤 릴리스를
open또는closed로 다루는 의미 체계가 마련될 예정임