NPM ‘터보’ Yarn Berry 탐지 결함이 WordPress 프로젝트에 미치는 위협 — 지금 해야 할 일

작가: WP-방화벽 보안팀
날짜: 2026-05-19
태그: WordPress 보안, 공급망, NPM, 터보, Yarn Berry, DevSecOps

요약: 인기 있는 npm 패키지 “터보”에서 발생한 심각한 문제(CVE-2026-45772 / GHSA-3qcw-2rhx-2726)는 Yarn Berry 탐지 중에 예상치 못한 로컬 코드 실행을 허용합니다. 이 권고서는 취약점이 WordPress 사이트와 팀에 의미하는 바, 실용적인 탐지 방법, 즉각적인 완화 조치, 그리고 오늘 적용할 수 있는 단계별 사고 대응 계획을 설명합니다.

목차

• 발생한 일 — 간단한 사실
• WordPress 사이트 소유자와 팀이 신경 써야 하는 이유
• 기술적 배경 (일반 언어)
• WordPress에 영향을 미치는 악용 시나리오
• 위험 평가 — 무엇이 이 문제를 심각하게 만드는가
• 사이트와 파이프라인을 보호하기 위한 즉각적인 조치
• 탐지 체크리스트 (명령어, 지표)
• WordPress 팀을 위한 사고 대응 플레이북
• 장기적인 공급망 위생 및 CI 강화
• WP-Firewall이 어떻게 지원할 수 있는지
• WP-Firewall로 사이트를 안전하게 보호하세요 — 오늘 무료로 시작하세요
• 최종 권장 사항 및 추가 읽기

발생한 일 — 간단한 사실

• npm 패키지의 취약점 터보 (turborepo 도구)가 공개되었고 CVE-2026-45772 (GHSA-3qcw-2rhx-2726)가 할당되었습니다.
• 영향을 받는 버전: turbo >= 1.1.0, < 2.9.14. 2.9.14에서 패치됨.
• 심각도: 높음 (Patchstack 항목 및 공개 권고 사항은 CVSS에 해당하는 심각도가 약 9.8임을 나타냅니다).
• 영향: Yarn Berry (Yarn 2+) 감지 중 예상치 못한 로컬 코드 실행. 실제로 특정 조건 하에서 turbo는 Yarn Berry를 감지하려고 시도하는 동안 발견한 로컬 코드를 실행할 수 있으며, 이는 공격자가 일부 환경에서 악용할 수 있습니다.
• 벡터: 상류 조건이 충족되면 많은 일반 CI / 빌드 설정 및 개발 맥락에서 네트워크를 통해 악용 가능; 현실적인 공급망 상황에서 공격자에게 낮은 복잡성.
• 즉각적인 수정: turbo를 2.9.14 이상으로 업그레이드; 즉각적인 업그레이드가 불가능한 경우 아래에 설명된 완화 조치를 적용하십시오.

Node 기반 빌드 도구(예: Turborepo/turbo 및 Yarn)에 의존하는 WordPress 사이트, 테마, 플러그인 또는 CI/CD 파이프라인을 관리하는 경우 이를 긴급하게 처리하십시오.

WordPress 사이트 소유자와 팀이 신경 써야 하는 이유

“이건 Node/npm 문제야 — 내 WordPress 사이트에 어떻게 영향을 미치지?”라는 생각이 들 수 있습니다. 짧은 대답: 현대의 WordPress 프로젝트는 점점 더 JavaScript 도구 체인에 의존하고 있습니다. 테마, 블록 기반 편집기, 빌드 파이프라인, 자산 번들러 및 지속적 통합 러너는 일반적으로 노드 도구를 사용합니다. 즉:

• 개발자 머신, CI 러너 또는 빌드 도구의 손상은 나중에 WordPress 사이트에 배포되는 테마 또는 플러그인 자산(JavaScript, CSS, 인라인 스크립트)에 악성 코드가 포함되도록 할 수 있습니다.
• 공급망 공격은 종종 정상적인 WordPress 강화 단계를 우회합니다 — 악성 코드가 다른 합법적인 테마나 플러그인에 번들링되면, 전통적인 WordPress 강화는 브라우저나 서버에서 실행될 때까지 이를 감지하지 못할 수 있습니다.
• 공격자는 빌드 단계의 신뢰를 악용합니다. 그들은 코드가 패키징되고 서명되는 장소를 목표로 하며, WordPress 설치 자체만을 겨냥하지 않습니다.

간단히 말해: 빌드 환경에서 이 turbo 취약점을 발판으로 삼는 공격자는 프로덕션 WordPress 사이트에 배포되는 파일에 악성 페이로드를 삽입할 수 있습니다.

기술적 배경 (일반 언어)

• turbo란 무엇인가요? Turbo (Turborepo 워크플로의 일부)는 작업 실행, 캐싱 및 모노레포 워크플로를 최적화하는 인기 있는 빌드 오케스트레이션 도구입니다. JavaScript/TypeScript, 프론트엔드 및 하이브리드 웹 앱 빌드를 가속화하는 데 일반적으로 사용됩니다.
• Yarn Berry란 무엇인가요? “Yarn Berry”는 Yarn 패키지 관리자의 주요 재작성인 Yarn 2+를 의미하며, 원래 Yarn 1.x와 비교하여 다른 플러그인 및 구성 모델을 가지고 있습니다.
• 무엇이 잘못되었나요? 감지 단계에서 터보 프로젝트가 Yarn Berry를 사용하는지 확인하는 동안, 프로젝트 작업 공간이나 로컬 경로에 존재하는 코드를 실행하는 결과를 초래하는 방식으로 로컬 파일이나 플러그인을 읽고 평가할 수 있습니다. 이러한 파일 중 하나가 공격자가 제어하는 경우(예: 손상된 종속성, 악성 플러그인 또는 CI에 마운트된 신뢰할 수 없는 레포 폴더를 통해 도입된 경우), 코드는 예상치 못하게 실행될 수 있습니다.
• “로컬 코드” 실행이 중요한 이유: Node 환경은 종종 빌드 도구가 설치 또는 빌드 중에 코드를 실행할 수 있는 능력을 부여합니다. 빌드 도구가 공격자가 제공한 스크립트를 실행하도록 속일 수 있다면, 이러한 스크립트는 출력 아티팩트를 수정하거나 비밀을 유출하거나 백도어를 생성할 수 있습니다.

중요한: Yarn Berry의 감지는 일반적으로 무해한 관리 단계입니다. 여기서 문제는 특정 조건 하에서 감지 논리가 악용될 수 있으며, 그 결과는 빌더의 맥락(CI, 개발자 머신, 컨테이너) 내에서 임의의 코드 실행입니다.

WordPress에 영향을 미치는 악용 시나리오

공격자가 이를 WordPress 침해로 전환하기 위해 사용할 수 있는 그럴듯한 실제 시퀀스는 다음과 같습니다:

1. 전이된 npm 종속성을 통한 공급망 주입
   • 공격자가 테마/플러그인 빌드에 의존하는 패키지를 오염시킵니다.
   • 오염된 패키지는 로컬 파일을 배치하거나 참조합니다. 터보 이는 Yarn Berry 감지 중에 읽고 실행됩니다.
   • 악성 코드는 CI 빌드에서 실행되며, 생성된 자산(스크립트, CSS)을 수정하여 코인마이너, 리디렉터 또는 백도어 관리자 스크립트를 포함합니다.
   • 수정된 테마/플러그인이 프로덕션 WordPress에 배포되어 사이트를 감염시킵니다.
2. CI 러너 또는 컨테이너 이미지의 침해
   • 공유 CI 러너 이미지는 공격자가 오염시킬 수 있는 npm 캐시 또는 작업 공간을 포함합니다.
   • 러너는 빌드를 실행합니다; 터보 감지를 트리거하고 공격자가 배치한 로컬 코드를 실행합니다.
   • 공격자의 코드는 비밀을 유출하거나 수정된 아티팩트를 게시합니다.
3. 개발자 워크스테이션 침해
   • 공격자가 개발자 머신에 접근합니다(피싱, 도난된 자격 증명).
   • 그들은 모노레포에 작은 악성 파일을 추가합니다; 이후 빌드 또는 커밋은 변경된 아티팩트를 업스트림으로 푸시합니다.
   • 병합되고 배포되면, 악성 페이로드가 프로덕션 WordPress 자산으로 들어갑니다.
4. 공개 저장소 속임수
   • 공격자가 실행을 트리거하는 파일을 주입하는 풀 리퀘스트 또는 악성 패키지를 엽니다. 저장소가 자동 병합 또는 느슨한 검증을 사용하는 경우, 이러한 변경 사항이 프로덕션에 도달할 수 있습니다.

WordPress의 경우, 결과는 사이트 코드에 국한되지 않습니다. 클라이언트 측 악성 JS는 사용자 세션을 탈취하거나 결제 정보를 훔치거나 리디렉션을 실행할 수 있으며; 서버 측 빌드 시간 침해는 빌드 파이프라인에 서버 측 템플릿 단계가 포함된 경우 변경된 PHP 템플릿을 통해 백도어나 숨겨진 관리자 계정으로 이어질 수 있습니다.

위험 평가 — 무엇이 이 문제를 심각하게 만드는가

• 높은 영향력(CVSS 유사 9.8): 빌드 컨텍스트에서 원격 실행은 완전한 공급망 침해로 이어질 수 있습니다.
• 넓은 범위: turbo는 많은 현대 웹 프로젝트와 CI 파이프라인에서 사용됩니다. 하나의 성공적인 타협은 여러 하위 사이트와 클라이언트에 영향을 미칠 수 있습니다.
• 낮은 권한 요구: 공격자는 종종 빌드 시스템에서 볼 수 있는 파일에 영향을 미칠 수 있는 능력만 필요합니다. 이는 의존성 오염, PR 또는 손상된 CI 이미지로 달성할 수 있습니다.
• 은밀한 지속성: 자산에 내장된 악의적인 변경 사항은 정상 파일처럼 보이며, 신중한 코드 감사나 파일 무결성 검사가 발견할 때까지 지속될 수 있습니다.

요약하자면: 이를 중요한 공급망 사고 벡터로 취급하십시오. 귀하의 WordPress 사이트 자체가 잠겨 있더라도, 안전하지 않은 빌드 도구 및 파이프라인 구성은 그 잠금을 무의미하게 만들 수 있습니다.

WordPress 사이트 및 빌드 파이프라인을 보호하기 위한 즉각적인 조치

귀하의 조직이 turbo 또는 monorepo 도구를 사용하는 경우, 즉시 다음을 구현하십시오. 저는 이를 병행하여 수행할 것을 권장합니다. 하나를 끝내기를 기다리지 말고 다음을 시작하십시오.

1. 모든 곳에서 turbo 업그레이드
   • 업그레이드 터보 모든 개발자 머신, CI 러너 및 빌드 서버에서 버전 2.9.14 이상으로.
   • 명령어 (예시):
     • npm: npm install turbo@^2.9.14 --save-dev
     • yarn: yarn add turbo@^2.9.14 -D
     • pnpm: pnpm add turbo@^2.9.14 -D
2. 깨끗한 환경에서 자산 재빌드
   • 업그레이드 후, 새로 프로비저닝된 환경에서 클린 빌드를 수행하십시오 (공유 캐시 없음, 재사용된 컨테이너 없음).
   • 이전 node_modules 또는 악성 파일이 포함될 수 있는 캐시된 아티팩트를 재사용하지 마십시오.
3. 의존성을 고정하고 검증하십시오.
   • 잠금 파일이 (package-lock.json, yarn.lock, pnpm-lock.yaml) 커밋되고 CI에서 사용되는지 확인하세요.
   • 빌드 시간 도구에 대해 엄격한 고정을 사용하세요.
4. 의심스러운 파일 및 변조의 징후를 스캔하세요.
   • 예상치 못한 .yarn, .pnp, 또는 최근에 추가된 플러그인 파일.
   • 마지막으로 알려진 정상 빌드에 없었던 자산 파일(축소된 JS, 공급업체 번들)의 변경 사항을 확인하세요.
5. 빌드 시스템을 격리하고 접근을 최소화하세요.
   • CI 빌드에 사용할 수 있는 비밀을 제한하세요.
   • 각 빌드에 대해 일시적인 러너 또는 컨테이너 이미지를 사용하세요.
   • 검토되지 않은 파일이 포함된 개발자 작업 공간을 마운트하지 마세요.
6. 의심스러운 활동 후 비밀을 감사하고 교체하세요.
   • 의심스러운 실행이나 손상된 빌드를 감지하면 배포 키, CI 토큰 및 영향을 받은 파이프라인에서 사용된 자격 증명을 교체하세요.
7. 배포 후 이상 현상을 모니터링하세요.
   • 비정상적인 트래픽 패턴, 리디렉션에 대한 사용자 보고, 예상치 못한 관리자 행동 또는 사이트의 JavaScript 이상 현상을 주의하세요.

탐지 체크리스트 — 명령, 쿼리 및 IOC

이러한 빠른 점검은 프로젝트가 취약한 터보 버전을 사용하고 있는지, 아티팩트가 영향을 받았는지 확인하는 데 도움이 됩니다.

1. 리포지토리에서 터보 사용 찾기
   • 찾다 패키지.json 파일:
     • grep: grep -R "\"turbo\"" -n .
     • 또는: rg '"turbo"' -S --hidden
   • 잠금 파일 검사: grep -n "turbo@" yarn.lock package-lock.json pnpm-lock.yaml || true
2. 설치된 터보 버전 확인
   • npm ls turbo --depth=0 (레포지토리에서)
   • yarn why turbo (yarn을 사용하는 경우)
   • CI 러너에서: node -e "console.log(require('turbo/package.json').version)" (안전/신뢰할 수 있는 컨테이너에서만)
3. 의심스러운 최근 수정 자산 검색
   • 재빌드 시간 근처에서 변경된 JS 파일 찾기:
     
     git log --name-only --since="2026-05-01" --pretty=format:"%h %ad %s" -- package.json package-lock.json yarn.lock
   • 의심스러운 문자열이 포함된 축소된 JS 찾기:
     
     rg "eval\\(|Function\\(|atob\\(|unescape\\(|document\\.cookie|localStorage\\.|fetch\\(" --glob '!node_modules' wp-content/themes wp-content/plugins || true
4. 예상치 못한 파일 찾기
   • 레포지토리 또는 작업 공간에서 새 파일 확인: .yarn/plugins, .yarnrc.js, .pnp.js 예상치 못한 경우.
   • 빌드 서버에서 최근에 작성된 파일 목록: find /path/to/workspace -type f -mtime -7 -ls
5. 아티팩트의 출처 검증
   • 로컬에서 빌드를 재생성하고 (클린 클론에서) 아티팩트를 비교: diff -ruW build/ build-clean/
   • 아티팩트 서명/해시를 유지하는 경우 체크섬을 확인하십시오.
6. 로그 및 네트워크 지표 모니터링
   • 예상치 못한 CI 로그 노드 탐지 단계 동안의 실행.
   • 빌드 후 빌드 호스트에서 낯선 도메인으로의 예상치 못한 아웃바운드 연결.

IOC(찾아볼 예시)

• 패치 릴리스 전에 터보를 위한 수정된 잠금 파일 항목.
• 예상치 못한 .js 빌드 직후 축소된 번들에서의 수정.
• 배포 후 wp-content에 새로운 관리자 사용자, 예약된 크론 항목 또는 난독화된 JS.

WordPress 팀을 위한 사고 대응 플레이북

빌드 파이프라인이나 워드프레스 사이트에 영향을 받았다고 의심되면, 다음 순서를 따르세요:

1. 영향을 받은 시스템을 격리하세요.
   • 의심되는 CI 러너, 개발자 머신, 빌드 서버를 격리하세요.
   • CI 비밀 및 배포 키를 취소하거나 교체하세요.
2. 포렌식 증거 보존
   • 변경하기 전에 빌드 로그, 커밋 해시, 아티팩트 체크섬을 수집하세요.
   • 가능하다면 영향을 받은 빌드 머신의 파일 시스템을 스냅샷하세요.
3. 범위 식별
   • 어떤 리포가 터보를 사용했나요? 어떤 테마/플러그인이 그 자산으로 빌드되었나요?
   • 그 리포에서 빌드된 배포가 있는 사이트는 무엇인가요?
4. 되돌리고 다시 빌드하세요.
   • 마지막으로 알려진 좋은 커밋으로 되돌리거나 터보를 패치된 버전으로 업그레이드한 후 깨끗한 복사본에서 다시 빌드하세요.
   • 깨끗한 환경에서 다시 빌드된 아티팩트를 재배포하세요.
5. 워드프레스 사이트를 스캔하고 수정하세요.
   • 워드프레스 파일(플러그인, 테마, 업로드)의 전체 악성 코드 스캔을 실행하세요.
   • 주입된 JS, 수정된 PHP 템플릿 또는 새로운 관리자 사용자를 찾아보세요.
   • 손상된 파일을 깨끗한 백업 또는 새로 빌드된 아티팩트로 교체하세요.
6. 비밀 및 자격 증명 회전
   • 빌드 환경에 노출된 API 키, 배포 토큰 및 기타 비밀을 변경하세요.
7. 이해관계자 및 고객에게 알리세요.
   • 범위 및 수정 단계에 대해 투명하게 하세요. 공급망 사건은 명확한 커뮤니케이션이 필요합니다.
8. 사건 후 검토를 수행하십시오.
   • 무엇이 손상을 허용했나요? 약한 핀 고정? 공유 캐시? 과도한 빌드 권한?
   • 정책을 업데이트하고 장기적인 완화 조치를 구현하세요.

장기적인 강화: 공급망 위생 및 CI 모범 사례

하나의 사건이 영구적인 개선을 이끌어야 합니다. 다음은 실용적이고 우선 순위가 매겨진 조치입니다.

1. 잠금 파일 및 고정 버전 강제 적용
   • 병합을 위해 잠금 파일의 존재를 요구합니다.
   • 결정론적 종속성 설치를 강제하는 도구 사용.
2. CI에서 최소 권한
   • 빌드 작업에 사용할 수 있는 비밀 제한; 테스트와 배포를 위해 서로 다른 토큰 사용.
   • 일시적이고 단일 목적의 러너 사용.
3. 재현 가능한 빌드 사용
   • 가능한 경우 빌드를 결정론적으로 만드세요. 입력을 기록하고 체크섬을 통해 아티팩트를 검증합니다.
4. 아티팩트 서명 및 검증
   • 프로덕션 아티팩트 또는 컨테이너에 서명하고 배포 중 서명을 검증합니다.
5. 종속성 검토 및 SCA
   • 소프트웨어 구성 분석(SCA) 도구를 사용하여 취약한 패키지를 조기에 감지합니다.
   • 빌드 도구에 영향을 미치는 PR에 대한 보안 검토 요구.
6. 공급망 피드 모니터링
   • 권고 사항을 구독하고 PR 검사에 취약성 스캐닝을 통합합니다.
7. 빌드 환경을 컨테이너화하고 격리합니다.
   • 최소한의 기본 이미지를 사용하고 오염될 수 있는 지속적인 캐시를 피합니다.
8. 개발자 교육
   • 개발자에게 의심스러운 패키지를 인식하고, 임의의 설치 스크립트를 실행하지 않도록 하며, 타사 코드를 검증하는 방법을 가르칩니다.

WP-Firewall이 도움이 되는 방법 (WP-Firewall 관점)

WP-Firewall에서는 공급망 문제로 인해 두 가지 유형의 워드프레스 사건이 발생한다고 보고 있습니다: 빌드 파이프라인을 손상시키는 사건과 손상된 아티팩트가 배포된 후 프로덕션 워드프레스 환경에서 실행되는 사건입니다.

귀하의 사이트에서 WP-Firewall을 실행하면, 다음과 같이 지원합니다:

• 클라이언트 측 자산 및 주입 시도의 일반적인 악성 패턴을 감지하고 차단하기 위한 관리형 방화벽 및 WAF 규칙. 이는 손상된 자산으로 인해 도입될 수 있는 의심스러운 트래픽을 차단하는 데 도움이 됩니다.
• 주입된 JavaScript, 알 수 없는 PHP 파일 또는 알려진 좋은 기준선에서 벗어난 수정된 테마 및 플러그인을 찾기 위한 악성코드 스캐너 및 파일 무결성 검사.
• 배포 후 일반적인 공격 행동에 대한 신속한 완화 — 예를 들어, 알려진 악성 엔드포인트를 차단하고 깨끗한 아티팩트에서 재구축할 수 있을 때까지 의심스러운 관리자 작업을 방지합니다.
• 비정상적인 트래픽이나 배포 후 감염 패턴을 식별하는 데 도움이 되는 지속적인 모니터링 및 로그 (예: 사이트에서 새로운 도메인으로의 갑작스러운 아웃바운드 호출).
• 팀이 재구축 및 키 회전을 조정하는 데 도움이 되는 실제 사건을 기반으로 한 가이드라인 및 플레이북.

WP-Firewall은 워드프레스 현실에 최적화되어 있습니다: 우리는 빌드 손상 후 공격자가 의존하는 행동을 차단하고 감지하는 데 집중합니다 — 따라서 악성 자산이 프로덕션에 유입되더라도 귀하의 사이트는 더 잘 차단되고, 감지되며, 수정됩니다.

WP-Firewall로 사이트를 안전하게 보호하세요 — 오늘 무료로 시작하세요

우리는 워드프레스 팀과 프로젝트를 보호하는 것이 즉시 구현할 수 있는 간단하고 효과적인 보호에서 시작된다는 것을 이해합니다. WP-Firewall의 기본(무료) 플랜은 첫 번째 방어층을 위해 설계되었습니다: 관리형 방화벽, 무제한 대역폭, WAF 보호, 악성코드 스캐너 및 OWASP Top 10 위험에 대한 완화 조치를 포함합니다 — 이는 손상된 빌드 프로세스를 통해 도착할 수 있는 악성 아티팩트를 감지하고 차단하는 데 도움이 되는 모든 기능입니다.

감사, 재구축 또는 CI 강화 구현 중에 라이브 사이트를 보호하고 싶다면 WP-Firewall 기본 플랜(무료)을 사용해 보시고 기본 보안을 얼마나 빨리 높일 수 있는지 확인해 보세요:

https://my.wp-firewall.com/buy/wp-firewall-free-plan/

(더 많은 자동화 및 신속한 수정이 필요하신가요? 표준 및 프로 플랜은 자동 악성코드 제거, 블랙리스트/화이트리스트, 취약점 가상 패치, 월간 보안 보고서 및 프리미엄 지원을 추가합니다.)

감지 및 업그레이드를 위한 실용적인 명령 및 코드 조각

지금 귀하와 귀하의 팀이 실행할 수 있는 몇 가지 구체적인 명령.

turbo가 사용되는 위치 찾기 (레포 검색):

# 프로젝트의 루트에서

현재 설치된 turbo 버전 확인:

# 프로젝트 내부에서"

고정 버전으로 업그레이드:

# npm

새 환경에서 재구성:

# 클린, 설치 및 빌드

빌드된 자산에서 의심스러운 문자열 검색:

rg "eval\\(|Function\\(|document\\.cookie|localStorage\\.|atob\\(" wp-content/themes wp-content/plugins -S || true

모니터링 및 로깅 권장 사항

• CI를 위한 빌드 로그 보존 및 중앙 집중식 로깅 활성화. 포렌식 비교를 위해 최소 30일의 로그를 유지하십시오.
• 다음에 대한 알림 추가:
  • 빌드 노드에서 예상치 못한 아웃바운드 네트워크 활동.
  • 배포 후 테마/플러그인 디렉토리에 새 파일.
  • 정상 업무 시간 외에 생성된 새 관리자 사용자.
• PHP, JS 및 템플릿 변경을 감지하기 위해 프로덕션 WordPress 파일에서 파일 무결성 모니터링(FIM)을 사용하십시오.

최종 권장 사항

1. 팀에서 turbo를 사용하는 경우, 모든 머신과 러너에서 지금 2.9.14 이상으로 업그레이드하십시오.
2. 깨끗한 환경에서 프로덕션 아티팩트를 재구성하고 재배포하십시오.
3. 주입된 자산 및 비정상적인 행동에 대해 WordPress 사이트를 스캔하십시오.
4. CI/CD 강화: 비밀 제한, 일시적인 러너 사용, 아티팩트 검증.
5. 심층 방어 사용: WAF, 악성 코드 스캔, 파일 무결성 검사 및 신중한 배포 정책.

보안은 예방 통제와 빠른 탐지/응답의 조합입니다. turbo Yarn Berry 탐지 취약점은 빌드 도구 체인의 작은 부분조차도 프로덕션 WordPress 사이트에 큰 영향을 미칠 수 있다는 강력한 경고입니다. 개발 및 빌드 환경을 고위험 인프라로 취급하고 그에 따라 보호하십시오.

노출 평가, 격리 배포 또는 안전한 재구성을 도와주길 원하시면 WP-Firewall의 보안 전문가가 도와드릴 수 있습니다. 파이프라인 업데이트 작업을 하는 동안 프로덕션 사이트에 즉각적인 방어층을 제공하기 위해 무료 기본 보호 계획으로 시작하십시오:

https://my.wp-firewall.com/buy/wp-firewall-free-plan/

안전하게 지내고, 실용적으로 행동하며, 빌드 보안을 WordPress 보안 태세의 일부로 간주하십시오 — 후순위가 아닙니다.

— WP-방화벽 보안팀

참고문헌

• CVE-2026-45772 (CVE 기록)
• GitHub 자문 GHSA-3qcw-2rhx-2726
• NPM/turbo 패키지 페이지 및 릴리스 노트

(공식 패치 릴리스 및 권고 사항에 대한 링크는 공공 보안 피드에 포함되어 있습니다; 신뢰할 수 있는 보안 피드와 패키지 관리자 권고 사항을 참조하여 권위 있는 일정 및 패치 세부 정보를 확인하십시오.)