Date: 2026-05-24 Topic: Security Primary source: BleepingComputer
Laravel 생태계에서 널리 쓰이는 서드파티 현지화 패키지 laravel-lang/*가 공급망 공격을 받았다. BleepingComputer와 Snyk는 2026년 5월 22일부터 23일 사이 공격자가 여러 Laravel Lang 패키지의 과거 릴리스 태그를 악성 커밋으로 바꿔 Composer 설치 과정에서 자격증명 탈취 코드가 내려가도록 만들었다고 보도했다.
영향을 받은 패키지는 laravel-lang/lang, laravel-lang/http-statuses, laravel-lang/attributes, laravel-lang/actions로 정리된다. 이들은 Laravel 공식 프레임워크 자체는 아니지만, 번역 문자열과 HTTP 상태 메시지 등을 제공해 많은 Laravel 프로젝트에서 직접 또는 간접 의존성으로 쓰인다.
이번 사건의 위험은 새 악성 패키지를 올린 것이 아니라 기존에 신뢰받던 버전 태그를 악용했다는 데 있다. 악성 버전을 받은 개발 서버, CI/CD 환경, 운영 서버는 .env, 클라우드 키, Git 토큰, SSH 키, Kubernetes·Vault 비밀값 같은 민감 정보를 노출했을 가능성을 전제로 점검해야 한다.
What Happened
보안업체 StepSecurity, Aikido Security, Socket, Snyk와 BleepingComputer 보도에 따르면 공격자는 Laravel Lang 조직의 네 개 저장소에서 GitHub 릴리스 태그를 조작했다. 일반적으로 Composer는 Packagist를 통해 GitHub 태그를 해석하고 해당 버전을 설치한다. 공격자는 이 흐름을 이용해 정상 저장소의 새 커밋을 바꾸는 대신, 태그가 공격자 통제 포크의 악성 커밋을 가리키도록 만들었다.
Snyk는 2026년 5월 22일 첫 악성 태그가 나타났고, 5월 22일부터 23일까지 재게시가 이어지며 네 개 패키지에서 700개가 넘는 과거 버전이 영향을 받은 것으로 정리했다. 초기 연구자 집계는 약 233개 버전이었지만, 이후 공격이 이어지며 수치가 커졌다.
Packagist는 악성 릴리스를 제거하고 관련 패키지를 일시적으로 목록에서 내린 것으로 보고됐다. 현재 laravel-lang/lang Packagist 페이지에도 Aikido가 해당 패키지 버전을 악성으로 표시했다는 경고가 보인다.
Key Details
이번 공격에서 핵심이 된 파일은 악성 커밋에 추가된 src/helpers.php였다. 이 파일은 composer.json의 autoload.files 항목에 연결됐다. Composer는 이 목록에 있는 PHP 파일을 애플리케이션 실행 초기에 자동으로 불러오기 때문에, 개발자가 패키지를 설치하거나 애플리케이션·큐 워커·콘솔 명령을 실행하는 것만으로도 악성 코드가 실행될 수 있었다.
확인된 주요 세부 사항은 다음과 같다.
- 영향을 받은 패키지:
laravel-lang/lang,laravel-lang/http-statuses,laravel-lang/attributes,laravel-lang/actions - 공격 방식: 공식 소스 저장소를 직접 수정하지 않고 Git 태그가 공격자 포크의 악성 커밋을 가리키도록 조작
- 실행 지점: Composer
autoload.files에 등록된src/helpers.php - 2단계 페이로드:
flipboxstudio[.]info에서 내려받는 크로스플랫폼 자격증명 탈취 코드 - 탈취 대상: AWS·GitHub·Slack·Stripe 토큰, 데이터베이스 자격증명, JWT, SSH 개인키,
.env파일, Kubernetes·Vault 비밀값, 브라우저 데이터, 패스워드 매니저·암호화폐 지갑 관련 정보
BleepingComputer는 Windows 환경에서는 추가 실행 파일이 %TEMP%에 생성되고, Chrome·Brave·Edge 브라우저의 저장 자격증명을 복호화하는 데 필요한 키를 노리는 기능도 분석됐다고 전했다. 또 일부 PDB 경로에 claude 문자열이 있어 Windows 악성코드 제작에 AI 도구가 쓰였을 가능성을 언급했지만, 이 부분은 정황일 뿐 확정된 원인으로 보기는 어렵다.
Background
Laravel Lang 패키지는 Laravel 애플리케이션을 여러 언어로 서비스할 때 필요한 번역 문자열과 메시지를 제공하는 커뮤니티 패키지다. 사용자는 대개 Composer로 의존성을 설치하고, 설치된 패키지는 vendor 디렉터리 아래에서 애플리케이션 실행과 함께 로드된다.
이 구조는 편리하지만 한 가지 전제가 있다. 패키지 관리자가 보여주는 버전 태그가 실제로 신뢰할 수 있는 코드와 연결돼 있어야 한다는 점이다. 이번 사건은 바로 그 전제가 흔들린 사례다. 새 이름의 수상한 패키지가 아니라, 이미 쓰던 이름과 버전 범위 안에서 악성 코드가 들어왔기 때문에 자동 업데이트, 새 배포, CI 재빌드가 공격 경로가 될 수 있었다.
PHP 프로젝트에서는 .env 파일에 데이터베이스 비밀번호, 메일 계정, 외부 API 키, 앱 암호화 키가 들어가는 경우가 많다. 그래서 이번 공격은 단순히 웹 애플리케이션 코드 하나가 오염된 문제가 아니라, 빌드 시스템과 운영 환경의 비밀값 전체가 노출됐을 수 있는 사건으로 다뤄야 한다.
Core Lens
이번 사건은 Laravel만의 문제가 아니라, 패키지 매니저가 “정상 태그”를 신뢰하는 방식이 공격자에게 이용될 수 있다는 경고다.
What It Means
개발팀 입장에서 가장 중요한 변화는 “패키지 이름이 익숙하다”거나 “버전 태그가 오래됐다”는 사실만으로 안전을 판단하기 어렵다는 점이다. 공격자가 새 악성 버전을 하나 올렸다면 탐지가 비교적 쉬웠겠지만, 이번처럼 과거 태그를 갈아끼우면 잠금 파일과 캐시, 배포 시점에 따라 어느 환경이 어떤 코드를 받았는지 추적해야 한다.
특히 CI/CD 환경은 위험이 크다. 빌드 서버에는 배포 토큰, 컨테이너 레지스트리 키, 클라우드 배포 권한, GitHub 토큰이 함께 있는 경우가 많다. 악성 Composer 설치가 한 번만 실행돼도 단일 애플리케이션을 넘어 조직의 여러 저장소와 인프라로 피해가 번질 수 있다.
이번 사례는 오픈소스 사용을 줄이라는 이야기가 아니다. 현실적인 교훈은 더 구체적이다. 의존성 설치는 코드 실행에 가깝고, 자동 업데이트는 편의 기능이면서 동시에 권한 있는 실행 경로다. 중요한 서비스일수록 패키지 업데이트 최소 숙성 기간, lockfile 검토, 빌드 환경의 비밀값 최소화, 배포 토큰의 짧은 수명 같은 통제가 필요하다.
What To Watch
Laravel 또는 Composer 기반 프로젝트를 운영한다면 다음 항목을 우선 확인할 필요가 있다.
composer.json과composer.lock에서 네 개laravel-lang/*패키지 사용 여부 확인- 2026년 5월 22일~23일 UTC 사이 새 설치, 배포, CI 재빌드가 있었는지 점검
vendor/laravel-lang/*/src/helpers.php존재 여부와composer.json의autoload.files등록 여부 확인flipboxstudio[.]info로 향한 과거 네트워크 연결 로그 검색- 노출 가능성이 있는 GitHub 토큰, npm·Composer 토큰, AWS 키, SSH 키, 데이터베이스 비밀번호,
.env내 API 키 회전
앞으로 볼 지점은 Packagist와 GitHub가 태그가 포크 커밋을 가리키는 상황을 어떻게 제한할지, Composer 생태계가 태그 무결성과 설치 시 자동 실행 파일을 어떻게 더 강하게 검증할지다. 보안업체마다 집계한 영향 버전 수가 업데이트되고 있으므로, 최종 범위는 Laravel Lang 유지관리자와 Packagist의 후속 공지를 함께 확인해야 한다.