Packagist의 ‘Mutable Tags’ 기능으로 인해 PHP 코드가 실행되기도 전에 악성 코드가 먼저 실행될 수 있습니다

주요 내용

• Packagist는 아티팩트를 호스팅하는 대신 Git 태그를 색인화하므로, 2026년 7월까지 게시된 버전이 별다른 공지 없이 다른 커밋으로 재지정될 수 있습니다.
• 2026년에 발생한 두 건의 사건도 똑같은 수법을 사용했는데, 하나는 악성 Composer 플러그인을 등록했고, 다른 하나는 PHP의 오토로더를 탈취했습니다.
• 헌신적인 composer.lock 이미 해결된 커밋을 고정하므로, 이후의 태그 재작성으로도 해당 커밋이 가리키는 내용을 변경할 수 없습니다. composer install 당긴다.
• Packagist는 이제 공개된 안정 버전에 대한 태그 재지정을 허용하지 않지만, 기존 잠금 파일과 개발 브랜치는 여전히 검토가 필요합니다.

다른 주요 레지스트리들도 모두 초기에 동일한 방침을 내렸습니다. 버전이 출시되면 그 내용은 고정됩니다. npm 타르볼은 변경할 수 없습니다. PyPI에서는 동일한 파일 이름을 다시 업로드할 수 없습니다. crates.io에서는 삭제가 아닌 ‘yank’만 허용합니다. Maven Central은 게시된 아티팩트를 아예 삭제하지 않습니다.

Packagist는 다른 방식을 채택했습니다. Packagist는 패키지를 저장하지 않습니다. 대신 Git 저장소를 읽어 들여 발견된 태그를 인덱싱한 뒤, Composer에 어디서 패키지를 가져와야 하는지 알려줍니다. 2.4.1과 같은 버전은 Git 태그와 Packagist가 해당 버전에 대해 기록한 커밋 참조로 구성되며, 2026년 7월까지 해당 태그는 삭제되었다가 다른 커밋에 대해 다시 푸시될 수 있으며, Packagist는 이를 조용히 따라갑니다.

2026 Composer 공급망 공격은 바로 그 취약점을 악용한 것이었으며, PHP에서는 3주 간격으로 두 건의 구체적인 사례가 발생했습니다.

Packagist가 레지스트리가 아닌 인덱스인 이유

아키텍처상의 차이가 보안상의 차이를 만들어냅니다. Composer가 의존성을 해결할 때, Packagist는 메타데이터(패키지 이름, 버전, 각 버전의 위치 등)를 제공합니다. 여기에는 일반적으로 커밋 해시인 소스 및 배포 참조 정보도 포함됩니다. 실제 코드는 소스 저장소에서 가져오거나, 코드 호스트가 특정 참조를 기반으로 요청 시 생성하는 배포 아카이브에서 가져옵니다. 이 체인 내에는 Packagist가 직접 저장하는 불변의 아티팩트가 전혀 없습니다.

마지막 행은 PHP 공급망 위험에 대한 모든 것을 보여줍니다. 이는 Packagist가 실수로 도입한 버그가 아닙니다. Git 인덱싱은 게시 과정의 마찰을 비정상적으로 낮게 유지해 주며, 이는 오랫동안 Packagist의 실질적인 장점 중 하나였습니다.

현실 점검: 이를 ‘Packagist의 취약점’이라고 부르는 것은 가변성이 실제로 어디에 있는지 간과한 것입니다. Git 태그는 설계상 항상 이동이 가능했습니다. Packagist는 아티팩트를 호스팅하는 대신 저장소를 색인화하기로 선택함으로써 이러한 특성을 계승했으며, 바로 이러한 상충 관계가 Composer 패키지 게시가 비교적 가벼운 작업이 될 수 있게 해줍니다.

작곡가 대상 공급망 공격은 실제로 어떤 모습일까

[출처에 따르면] 2026년 4월 30일, 해킹당한 서비스 계정을 보유한 누군가가 intercom/intercom-php에 악성 커밋을 푸시하고, 여기에 기존 5.0.2 태그를 적용했다. GitHub 권고 사항. 수정된 composer.json 해당 패키지를 Composer 플러그인으로 선언했으며, 승인(대화형 프롬프트 또는 허용형 방식을 통해)이 완료되면 allow-plugins 설정 – 이 기간 동안 실행되었습니다 composer install Bun 런타임을 가져와 난독화된 자격 증명 탈취 코드를 실행하는 드롭퍼로 활용되었습니다. 이 악성 태그는 관리자들이 이를 정상 코드로 다시 수정하기 전까지 2시간도 채 되지 않는 시간 동안 활성화된 상태였습니다. 연구진은 이를 ‘미니 샤이-훌루드(Mini Shai-Hulud)’라고 명명하고, 다음과 같은 대상에게 피해를 입힌 캠페인과 연관 지었습니다. 같은 창에 표시되는 Intercom의 npm 클라이언트.

3주 후, 동일한 취약점이 훨씬 더 큰 규모로 악용되었습니다. 5월 22일 22:32 UTC부터 5월 23일까지 이어진 이 공격에서, 조직 전체에 대한 푸시 권한을 가진 공격자는 4개의 Laravel-Lang 현지화 패키지에 존재하는 모든 태그를 재작성하여, 자신이 제어하는 포크의 커밋을 가리키도록 변경했습니다. 덕분에 공식 저장소에는 악성 코드가 전혀 반영되지 않았습니다. Socket은 700개 이상의 재매핑된 과거 버전을 집계했고, Aikido는 233개를 확인했으며, 재작성 작업의 주된 급증은 90분도 채 걸리지 않았습니다. 이번 공격에서는 플러그인을 등록하는 대신 PHP의 오토로더를 탈취하는 방식이 사용되었습니다.

두 사건 모두 어디에든 나타나기 위해 새로운 릴리스가 필요하지 않았습니다. 변경 내역도, 새로운 버전 번호도 없었으며, 버전 번호를 모니터링하는 관리자나 종속성 봇이 달라진 점으로 식별할 만한 요소는 전혀 없었습니다.

이를 npm에서 공격자가 어떤 방식을 취해야 하는지와 비교해 보자. npm에서 정식 릴리스를 대체하려면 다른 버전 번호를 배포해야 한다. 기존 패키지와 버전을 뒷단에서 몰래 바꿀 수는 없기 때문이다. 새 버전이 릴리스 피드에 나타나면 의존성 관리 봇이 이를 감지하게 된다. 반면 태그를 이동하는 경우에는 이러한 현상이 전혀 발생하지 않았다.

되돌리기는 양날의 검과 같았다. 복구 과정은 빠르긴 했다. 유지보수 담당자가 태그를 다시 이전 위치로 이동시키기만 하면 되었기 때문이다. 실제로 그날 밤 intercom-php에서 바로 그런 일이 벌어졌다. 하지만 같은 이유로 추적 조사는 더 어려워졌다. 버전 번호가 예전과는 다른 커밋을 가리킬 수 있게 되었기 때문이다. Packagist의 공개 투명성 로그에는 이러한 참조 변경 사항이 기록되어 있어, 적어도 공개된 참조가 언제 이동했는지에 대한 영구적인 기록을 남기게 되었다.

두 가지 다른 페이로드, 하나의 가변 태그

2026년에 발생한 두 건의 사건은 엄밀한 의미에서 모두 Composer 공급망 공격이었으며, 둘 다 동일한 수법으로 시작되었습니다. 그 후의 전개는 완전히 달랐는데, 실제로 무엇을 수정해야 할지 결정할 때 이러한 차이점은 매우 중요합니다.

intercom/intercom-php의 취약점이 발견된 태그는 다음을 변경한 커밋을 가리키고 있었습니다. composer.json 패키지를 Composer 플러그인으로 선언하기 위함입니다. 대부분의 분석 보고서가 이 공격 방식을 다루는 이유는, 이것이 Composer의 플러그인 시스템과 완벽하게 부합하기 때문입니다. 허용된 플러그인은 composer install 그리고 composer update, 애플리케이션 코드가 실행되기 전에.

Laravel-Lang 타협안은 플러그인 등록과 전혀 관련이 없었습니다. 이 타협안은 악의적인 src/helpers.php ~로 autoload.files 엔트리였기 때문에, 패키지가 설치된 순간부터 모든 PHP 요청에서 페이로드가 실행되었습니다. 태그 이름은 같고, Composer가 태그가 가리키는 대상에 대해 갖는 신뢰도도 동일하지만, 실행 경로는 완전히 달랐습니다. 한 쪽에 대한 수정 사항은 다른 쪽에는 아무런 영향을 미치지 않습니다.

또한 Laravel 보안에 대한 당사의 상세 가이드에서 핵심 프레임워크 보호 전략을 살펴보실 수 있습니다.

작곡가 플러그인의 보안에 실질적인 허점이 있다

이동된 태그는 코드를 전달합니다. 이 코드를 실행할 무언가가 필요하며, 인터콤 방식의 공격에서 그 역할을 하는 것은 플러그인 시스템입니다. 다음을 선언하는 패키지는 "type": "composer-plugin" 허용되면 Composer의 자체 설치 및 업데이트 실행 과정의 일부로 로드되어 코드를 실행할 수 있습니다. 이는 의도된 동작입니다. 플러그인은 Composer의 설치 방식을 변경하기 위해 존재하기 때문에, 설치가 완료되기 전에 실행되어야 하기 때문입니다.

Composer 2.2.0에서는 allow-plugins config 파일에서, 현재 기본 설정은 아무것도 허용하지 않습니다. in composer.json 이런 모양입니다.

{
  "config": {
    "allow-plugins": {
      "composer/package-versions-deprecated": true,
      "phpstan/extension-installer": true
    }
  }
}

~와 함께 allow-plugins 이렇게 구성되면, Composer는 목록에 없는 플러그인은 실행하지 않습니다. 목록에 없는 플러그인이 있을 경우, Composer를 대화형 모드로 실행하면 경고 메시지가 표시되며, 비대화형 모드에서는 해당 플러그인이 선택 사항으로 선언되지 않은 한 Composer가 조용히 진행하지 않고 오류가 발생합니다. 설치 과정에서 오류가 발생하는 것이 조용히 설치되는 것보다 낫습니다.

주의하세요: 누군가 설정했는지 확인해 보세요 "allow-plugins": true 단순히 프롬프트를 없애기 위해서입니다. 이 한 줄의 코드는 현재 및 향후 출시될 모든 플러그인을 허용 목록에 추가하고, 허용 목록 보호 기능을 완전히 비활성화합니다. 다음 명령을 실행하면 composer config allow-plugins 프로젝트에 실제로 어떤 설정이 적용되어 있는지 보여주고, false 모든 것을 부정하는 가치이다.

플러그인이 전혀 필요 없는 빌드의 경우, 이 플래그들은 직설적이면서도 효과적입니다.

composer install --no-plugins --no-scripts --no-dev

프로덕션 빌드에 플러그인이나 Composer 스크립트가 필요하지 않다면, 개발자 컴퓨터에서는 이를 계속 사용할 수 있도록 하면서 프로덕션 빌드에서는 둘 다 비활성화하는 것이 합리적인 접근 방식입니다.

자동 로드 파일은 더 조용한 방법입니다

allow-plugins Laravel-Lang 방식의 공격에는 전혀 효과가 없습니다. autoload.files 이는 권한 확인 창을 통해 제한할 수 있는 선택적 기능이 아닙니다. 이는 PHP 패키지가 헬퍼 함수를 제공하는 일반적인 방식이며, 생태계가 제대로 작동하려면 Composer가 모든 패키지의 자동 로드 설정을 신뢰해야 합니다.

바로 그 점이 이번 공격 방식이 특히 치명적인 타격을 입힌 이유입니다. Composer는 특정 패키지를 플러그인으로 실행해도 되는지 묻습니다. 하지만 해당 패키지가 자동 로드되는 파일을 정의해도 되는지는 결코 묻지 않습니다. Composer 2.10의 악성코드 정책과 Packagist의 불변성 변경이 도입되기 전에는, 이 부분에서 주요한 보호 수단은 애초에 재작성된 태그를 해결하지 않는 것이었으며, 이것이 바로 lockfile이 그토록 중요했던 이유였습니다.

npm이 제대로 하지 못하는 것 중 작곡가가 제대로 하는 한 가지

의존성에 의해 선언된 Composer 스크립트는 실행되지 않습니다. 루트 패키지의 스크립트만 실행됩니다. 악의적인 post-install-cmd 트리 구조에서 4단계 깊이에 위치한 패키지는 아무런 영향도 미치지 않습니다. 이는 npm보다 훨씬 더 나은 기본 설정입니다. npm의 경우 트리 내의 어떤 패키지든 설치 중에 실행되는 postinstall 스크립트를 포함할 수 있기 때문입니다.

알고 계셨나요? 의존성 스크립트를 무시하는 것은 Composer의 의도적인 설계 결정이지, 보안 사고 발생 후에 급하게 추가된 보안 강화 조치가 아닙니다. 이는 두 생태계를 실제로 비교해 볼 때 종종 간과되는 세부 사항 중 하나입니다.

작곡가 잠금 파일에 기록되는 내용과 기록되지 않는 내용

composer.lock 이 기능은 그 평판이 시사하는 것보다 더 강력한 보호 기능을 제공하며, 이러한 보호 기능에는 명확한 한계가 있습니다. 이 한계는 플러그인 공격과 오토로드 공격 모두를 포괄하는데, 이는 해당 기능이 이 두 공격보다 한 단계 아래에서 작동하기 때문입니다.

각 패키지에 대해, 잠금 파일(lockfile)은 해결된 버전과 소스 및 배포판 참조 정보(일반적으로 해당 릴리스에 해당하는 Git 커밋 해시)를 기록합니다. 다음 명령을 실행하십시오. composer install 그리고 Composer는 태그가 현재 가리키는 커밋이 아니라 정확히 그 커밋을 요청하기 때문에, 나중에 태그가 재작성되더라도 문제가 발생하지 않습니다. 이 보장은 어떤 커밋이 요청되는지에 관한 것이지, 반환되는 바이트의 체크섬에 관한 것이 아닙니다. 코드 호스트는 요청이 있을 때만 해당 아카이브를 생성하며, 잠금 파일에는 이를 확인할 수 있는 해시 값이 포함되어 있지 않기 때문입니다. 의존성을 재해결하는 작업이 취약점이었으며, 여기에는 다음과 같은 부분 업데이트도 포함됩니다. composer update foo -W. The Packagist의 보안 관련 글에서도 잠금 파일에 대해 같은 점을 지적하고 있는데, Laravel-Lang 관련 기사 중 상당수가 잠금 파일이 아무런 보호 기능도 제공하지 않는다고 주장했기 때문에 이 점은 알아두면 좋을 것입니다.

다음만 복사하는 Dockerfile composer.json 실행 전에는 install이 참조할 잠금 파일이 없기 때문에, 아무도 애플리케이션 코드를 한 줄도 수정하지 않았음에도 보호 기능이 사라집니다. 복사 composer.lock 이와 함께 보호 기능도 다시 활성화됩니다.

git ls-files composer.lock

만약 그 결과가 아무것도 반환되지 않는다면, composer.lock 이 저장소에서는 추적되지 않으므로, 클린 빌드를 수행할 때마다 레지스트리 메타데이터에 그 시점에 기록된 내용에 따라 의존성을 새로 해결합니다.

악성코드 검사 및 7월 불변성 변경 사항

5월에 발생한 사건들은 그냥 넘어가지 않았다. 닐스 아더만(Nils Adermann)과 이고르 벤코(Igor Benko)는 5월 27일 Composer와 Packagist를 위한 보안 로드맵을 발표했으며, 이튿날 Composer 2.10이 출시되었다.

이번 릴리스 내용 중 하나가 이 문제와 직접적인 관련이 있습니다. Packagist는 이미 3월부터 Aikido의 악성코드 탐지 결과를 가져오고 있었으며, 2.10 버전을 통해 비로소 이 기능이 실제로 유용하게 활용될 수 있게 되었습니다. 경고 표시가 붙은 버전은 해결 대상 목록에서 제외되므로, composer update, composer require 그리고 composer create-project 그들에게 연락할 수 없고, 그리고 composer install 표시된 버전이 이미 잠금 파일에 존재하는 경우, 해당 버전을 조용히 가져오는 대신 큰 소리로 오류가 발생합니다. composer audit 동일한 버전을 보고하며 기본적으로 실패합니다.

6월부터는 Private Packagist 조직에도 플러그인 제한 제어 기능이 도입되어, 조직에서 어떤 패키지가 Composer 플러그인으로 작동할 수 있는지 사전에 결정할 수 있게 되었습니다. 이 기능을 활성화하면, 갑자기 스스로를 플러그인으로 선언하는 악성 릴리스는 업데이트 메타데이터에서 제거되어 Composer의 리졸버에 도달하지 못하지만, 기존 잠금 파일(lockfile)을 통해 설치할 경우에는 Private Packagist의 별도의 다운로드 차단 설정도 함께 적용되어야 합니다.

더 큰 구조적 개선은 7월 7일, Packagist가 불변 버전을 도입하면서 이루어졌습니다. 안정 버전이 공개되면, 해당 버전을 가리키는 Git 참조는 더 이상 변경되지 않습니다. 태그를 삭제하거나, 다시 생성하거나, 업스트림으로 이동하더라도 Packagist는 원래의 참조를 유지하며, 패키지 페이지에 ‘태그 재지정 차단’ 배지를 표시하고 모든 유지보수 담당자에게 이메일을 보냅니다.

브랜치를 추적하는 개발 버전은 여전히 변경됩니다. 이는 브랜치의 본래 목적이기 때문이며, 해당 규칙은 아카이브 바이트가 아닌 버전과 커밋 간의 매핑을 다루고 있습니다. 대부분의 ZIP 파일은 여전히 코드 호스트에 의해 필요에 따라 생성되기 때문입니다. 차단된 참조 변경, 소프트 삭제 및 복구 작업은 모두 공개 투명성 로그에 기록됩니다.

이러한 조치들 중 어느 것도 보호 기능이 적용되기 전에 악의적인 커밋을 기록한 락파일을 소급하여 정리해 주지는 못하며, 바로 그 때문에 composer.lock 그리고 allow-plugins 스캐너가 어떤 결과를 보여주든, 본인의 프로젝트에 대해서는 여전히 직접 확인해야 합니다.

태그가 해결되기 전에 패키지 확인하기

두 공격 모두에서 위험한 참조는 플러그인이 로드되거나 오토로더 하이재킹이 발생하기 훨씬 전인 해결 시점에 의존성 그래프에 유입되었습니다. Composer 2.10은 이제 설치 시점에도 악성코드 검사를 추가했으나, 이 검사는 여전히 누군가가 해당 버전을 먼저 신고해야만 작동합니다.

SecureChain for PHP는 팀이 업스트림 VCS 참조를 통해 직접 해결하는 대신, 소스 코드에서 재컴파일되고 악성코드 검사를 거친 패키지 소스를 제공합니다. 모든 패키지는 격리된 환경에서 재컴파일되고 설치 가능해지기 전에 검증을 거치므로, 사용자가 다운로드하는 것은 검증된 버전 그 자체입니다. 취약점은 SLA에 따라 지속적으로 패치되며, 유지보수자가 업데이트 제공을 중단한 후에도 ‘무기한 라이프사이클 지원’을 통해 해당 지원이 지속됩니다. 이는 예상치 못한 업스트림 변경 사항을 포착해 줄 유지보수자의 감독이 이미 사라진, 더 이상 관리되지 않는 패키지의 경우 특히 중요합니다.

그 어떤 것도 그것을 대체할 수 없다 composer.lock, allow-plugins 또는 composer audit. 이는 사용자 자체 툴링으로 파악할 수 있는 부분보다 상류에 위치한 문제의 일부를 해결합니다. 어떻게 하는지 확인해 보세요 PHP용 SecureChain 작동합니다.

자주 묻는 질문

‘Composer’ 공급망 공격이란 무엇인가요?

이 공격은 사용자가 직접 작성한 코드의 취약점을 통해 이루어지는 것이 아니라, 대개 해킹당한 저장소, 이동된 Git 태그 또는 악성 Composer 플러그인을 통해 PHP 패키지가 프로젝트에 도달하기도 전에 이를 침해하는 방식입니다. 이는 모든 프로그래밍 언어의 오픈소스 레지스트리를 대상으로 발생하고 있는 광범위한 공급망 공격 패턴 중 하나의 구체적인 형태입니다.

Packagist 패키지의 버전은 출시 후 변경될 수 있나요?

역사적으로 보면 가능했습니다. Packagist는 변경 불가능한 아티팩트를 저장하기보다는 Git 태그를 색인화했기 때문에, 버전 번호가 바뀌지 않은 채로 태그를 삭제하고 다른 커밋에 대해 다시 푸시할 수 있었습니다. 2026년 7월부터 Packagist는 이미 공개된 안정 버전의 소스 참조를 변경하려는 모든 시도를 거부하며, 이는 개발자가 어떤 Composer 버전을 사용하든 상관없이 적용되는 서버 측 보호 기능입니다. 브랜치를 추적하는 개발 버전은 여전히 이동할 수 있으며, 이 변경 사항만으로는 이전에 악의적인 커밋을 해결했던 기존 설치 환경을 안전하게 만들 수는 없습니다.

Composer 의존성 스크립트는 설치 중에 실행되나요?

아닙니다. 루트 패키지의 스크립트만 실행됩니다. 악성 post-install-cmd 의존성에서 선언된 내용은 무시되며, 이는 npm의 기본값보다 더 엄격한 설정입니다.

Composer 플러그인은 코드를 어떻게 실행하나요?

다음이 들어 있는 소포 "type": "composer-plugin" 설치 및 권한 부여가 완료되면, Composer의 설치 및 업데이트 실행 과정의 일부로 코드를 실행할 수 있습니다. Composer 2.2.0 이상 버전에서는 플러그인을 다음을 통해 명시적으로 허용 목록에 추가해야 합니다. allow-plugins config.

composer.lock 파일은 Git 태그가 이동된 경우에도 보호 기능을 제공하나요?

네, 잠금 파일에 이미 유효한 커밋이 포함되어 있다면, 그 이유는 composer install 태그를 다시 해결하는 대신 그 잠긴 참조를 사용합니다. 이는 보호하지 않습니다 composer update, 새로운 composer require 호출, 또는 잠금 파일이 없는 상태에서 빌드하는 경우.

'allow-plugins'를 true로 설정하면 어떤 효과가 있나요?

이는 현재 및 향후 출시될 모든 Composer 플러그인을 허용 목록에 추가하여 보안 기능을 완전히 무력화합니다. 대신 프로젝트에 필요한 특정 플러그인을 명시적으로 나열한 목록으로 대체하십시오.

요약

기사 이름

Packagist의 가변 태그로 인한 컴포저 공급망 리스크

설명

Composer 공급망 공격에는 타이포스쿼트가 필요하지 않습니다. Packagist의 변경 가능한 Git 태그가 어떻게 2026년에 발생한 두 건의 사고를 가능하게 했는지 살펴보겠습니다.

작성자

팀 워커

게시자 이름

TuxCare

게시자 로고