플러그인 이름	@beproduct/nestjs-auth
취약점 유형	패치되지 않은 취약점
CVE 번호	CVE-2026-46412
긴급	비판적인
CVE 게시 날짜	2026-05-20
소스 URL	CVE-2026-46412

NPM 공급망 악성코드와 귀하의 WordPress 사이트: “Mini Shai‑Hulud” 웜(CVE‑2026‑46412 / GHSA‑6xwp‑cp5h‑q856)과 같은 공격을 탐지, 차단 및 예방하는 방법

WP‑Firewall의 WordPress 보안 전문가로서, 저는 악성 코드를 도입한 Node 패키지 생태계의 최근 공급망 침해를 추적해왔습니다. @beproduct/nestjs-auth 패키지(영향을 받은 버전 >= 0.1.2, <= 0.1.19)에서. 이 취약점은 CVE‑2026‑46412 및 GHSA‑6xwp‑cp5h‑q856로 지정되었습니다. 이것은 NPM/Node 문제이지만, 현대 WordPress 개발 및 배포는 종종 Node 도구(빌드 프로세스, 번들러, CI 파이프라인, GitHub Actions)에 의존하기 때문에 WordPress 사이트 소유자와 개발자에게 매우 관련이 있습니다. 손상된 NPM 패키지는 테마, 플러그인 또는 프로덕션 WordPress 사이트에 배포되는 빌드 아티팩트에 악성코드가 도입될 수 있습니다.

이 게시물은 명확하고 실행 가능한 용어로 설명합니다:

• 이러한 종류의 공급망 악성코드가 어떻게 작동하는지와 WordPress 사이트가 위험에 처한 이유
• WordPress 설치에서 침해의 징후를 탐지하는 방법
• 단계별 차단, 수정 및 복구 지침
• 개발자 환경 및 CI/CD 파이프라인을 위한 강화 및 장기 예방 조치
• 즉시 적용할 수 있는 실용적인 WAF 및 서버 수준 완화 조치
• 관리형 WAF + 악성코드 스캐너(무료 플랜 포함)를 추가하는 것이 합리적인 첫 번째 방어층인 이유

저는 매일 사이트 소유자, 에이전시 및 호스트와 함께 일하는 WordPress 보안 전문가의 관점에서 이 글을 씁니다 — 마케팅 허풍이 아니라, 지금 취할 수 있는 구체적인 단계를 제공하기 위해서입니다.

---

NPM 패키지 취약점이 WordPress에 중요한 이유

WordPress 사이트는 더 이상 단순히 PHP + MySQL이 아닙니다. 현대 테마, 플러그인 및 빌드 프로세스는 종종:

• npm/yarn을 사용하여 webpack, gulp, rollup, Vite 등을 통해 프론트엔드 자산(CSS/JS)을 빌드합니다.
• CI/CD에서 Node 스크립트에 의존하여 자산을 컴파일하고 최적화한 다음, 해당 빌드된 자산을 WordPress 리포지토리 또는 서버로 푸시합니다.
• GitHub/GitLab Actions 및 기타 CI 러너를 사용하여 프로덕션 환경에 대한 접근 권한이 있는 비밀 또는 토큰을 보유할 수 있습니다.
• 최종적으로 WordPress 설치에서 제공되는 테마/플러그인 릴리스에 컴파일된 아티팩트(번들 JS/CSS)를 포함합니다.

널리 사용되는 NPM 패키지가 손상되어 악성 postinstall 스크립트나 런타임 페이로드를 포함하고 있다면, 해당 코드는:

• CI 또는 개발자 머신에서 실행될 수 있으며 npm 설치, 중에 비밀이 유출되거나 악성 파일이 레포에 삽입될 수 있습니다.
• 빌드 아티팩트를 수정하여 최종 자산이 WordPress에 배포될 때 백도어를 포함하거나 프론트엔드 JavaScript를 통해 데이터를 훔칠 수 있습니다.
• 저자가 손상된 코드를 플러그인/테마에 수동으로 복사하거나 CI가 PHP 코드베이스에 파일을 작성하는 경우 PHP 파일에 코드를 주입할 수 있습니다.
• CI에서 사용할 수 있는 토큰과 자격 증명을 남용하여 새로운 배포를 생성하거나 커밋을 푸시하거나 새로운 패키지를 게시하여 벌레와 같은 전파를 생성합니다.

최근의 “Mini Shai‑Hulud” 캠페인은 바로 이러한 위험의 유형을 보여줍니다: 비밀을 전파하고 잠재적으로 유출하기 위해 postinstall 동작을 사용하는 NPM 패키지의 악성 코드. 귀하의 WordPress 사이트가 Node를 직접 사용하지 않더라도, 귀하 또는 귀하의 에이전시가 개발 파이프라인에서 Node를 사용한다면 귀하의 사이트에 영향을 미칠 수 있습니다.

---

빠른 고수준 위험 체크리스트 (즉시 확인해야 할 사항)

개발/빌드/배포 과정에서 Node 패키지를 사용하는 경우, 이를 높은 우선 순위로 처리하십시오. 즉시 확인하십시오:

• 귀하의 플러그인, 테마 또는 빌드 프로세스 중에 @beproduct/nestjs-auth (버전 0.1.2 – 0.1.19)를 포함하거나 설치하거나 간접적으로 참조하는 것이 있습니까?
• 최근 빌드가 npm 설치 패키지 무결성을 확인하지 않고 사용된 CI 시스템(GitHub/GitLab/기타)에서 실행되었습니까?
• 새로운 또는 예상치 못한 관리자 사용자, 예약된 작업(wp_cron 작업) 또는 wp-content(특히 uploads, mu-plugins 또는 테마/플러그인 디렉토리) 내의 알 수 없는 파일이 있습니까?
• 서버에서 설명할 수 없는 아웃바운드 네트워크 연결(특히 알 수 없는 호스트나 IP로), 증가된 CPU/디스크 사용량 또는 비정상적인 로그 항목이 있습니까?

위의 질문 중 하나라도 “예”라고 답하면 지금 즉시 격리 조치를 취하십시오(아래 지침 참조).

---

탐지: WordPress 환경에서 공급망 악성 코드의 징후를 찾는 방법

탐지에는 개발 파이프라인(로컬 개발 머신, CI)과 프로덕션 WordPress 사이트 모두를 살펴보는 것이 필요합니다. 아래는 실용적인 점검 및 명령입니다.

1) 프로젝트 의존성 그래프를 확인하십시오.

• 검사합니다 패키지.json, package-lock.json 그리고 yarn.lock 취약한 패키지 또는 의심스러운 전이 종속성을 위해.
• 실행:

# 직접 사용을 찾기

2) node_modules 및 빌드 단계에서 postinstall 및 의심스러운 스크립트 검색

악성 패키지는 종종 postinstall 임의의 명령을 실행하기 위한 스크립트를 사용합니다. npm 설치:

# 리포지토리 및 node_modules에서 postinstall의 발생 찾기

또한 의심스러운 패턴 검색:

# 유출 또는 셸 생성을 위해 사용될 수 있는 의심스러운 Node API

3) 빌드 아티팩트 및 커밋 기록 검사

• 리포지토리에서 새로운, 예상치 못한 파일이나 익숙하지 않은 코드 또는 난독화된 페이로드(긴 base64 문자열, 많은 eval)를 포함하는 빌드 출력의 변경 사항을 찾습니다.
• 의심스러운 base64 문자열, eval 사용 또는 원격 코드 가져오기를 위해 리포지토리 검색:

grep -R --line-number -E "eval\(|new Function|atob\(|fromCharCode|base64|http[s]?://(?!your-trusted-domains)" .

4) 서버 파일 시스템 및 업로드 검사

악성 소프트웨어는 종종 업로드, 테마 폴더 또는 mu-plugins에 웹 셸 또는 백도어 PHP 파일을 떨어뜨립니다.

• 업로드에서 최근 수정된 PHP 파일 찾기(정상적으로 존재하지 않아야 함):

find wp-content/uploads -type f -name "*.php" -print

• wp-content의 모든 곳에서 의심스러운 파일 스캔:

# 의심스러운 이름이나 최근 변경 사항이 있는 파일

5) 워드프레스 데이터베이스 및 사용자 검토

• 알 수 없는 관리자 계정이나 수정된 사용자 메타를 확인하십시오.
• 익숙하지 않은 크론 항목 및 의심스러운 자동 로드 옵션에 대해 wp_options를 확인하십시오.

6) CI 로그 및 워크플로 실행 확인

• 최근 CI 실행을 검토하십시오. npm 설치 출력 및 모든 포스트 설치 스크립트 로그를 확인하십시오.
• 빌드 중에 비밀(예: NPM/GitHub 토큰)이 출력되었거나 사용되었는지 확인하십시오.

7) 서버의 네트워크 및 프로세스 모니터링

• 비정상적인 원격 호스트에 대한 아웃바운드 연결(netstat/ss)을 검토하십시오.
• 비표준 스크립트에 의해 생성된 의심스러운 장기 실행 노드 또는 PHP 프로세스의 프로세스 기록을 살펴보십시오.

8) 악성 코드 스캐너 및 파일 무결성 모니터링 사용

• 신뢰할 수 있는 악성 코드 스캐너 및 파일 무결성 검사기를 워드프레스 파일 시스템 전체에서 실행하십시오. 깨끗한 백업 또는 알려진 좋은 기준과 비교하십시오.

---

즉각적인 격리 조치(먼저 해야 할 일)

침해가 의심되면 신속하지만 체계적으로 행동하십시오.

1. 사이트를 유지 관리 모드로 전환하고 가능한 경우 트래픽을 차단하십시오.
   • WAF를 사용하여 모든 비관리 IP를 차단하거나 트래픽을 정적 유지 관리 페이지로 임시로 라우팅하십시오.
2. 서버(디스크/VM)의 스냅샷을 찍고 로그(웹 서버, PHP-FPM, 시스템 로그, CI 로그)를 캡처하십시오.
   • 포렌식 분석을 위한 증거를 보존하고 지표를 파괴하지 않도록 하십시오.
3. 비밀 및 토큰을 교체하십시오:
   • CI 러너의 토큰과 워크플로에서 사용된 모든 GitHub/GitLab 토큰을 취소하십시오.
   • 노출되었을 수 있는 API 키, 데이터베이스 자격 증명 및 모든 제3자 서비스 키를 교체하십시오.
4. 손상된 배포 및 잠금을 철회하십시오:
   • CI에 배포 접근 권한이 있는 경우, 배포 키를 변경하고 모든 토큰을 철회하십시오.
5. 파이프라인이 깨끗하다고 확인할 때까지 검증되지 않은 스크립트를 실행하거나 자동으로 배포할 수 있는 CI 워크플로우를 비활성화하십시오.

---

정리 및 복구: 깨끗한 상태로 돌아가는 방법

격리 및 증거 수집 후, 깨끗한 빌드와 자격 증명 회전을 강조하는 복구 경로를 따르십시오.

1. 악성 파일을 식별하고 제거하십시오.
   • 백도어 PHP 파일, 의심스러운 업로드 및 수정된 테마/플러그인 파일을 제거하십시오. 깨끗한, 침해 전 백업에서 복원하는 것을 선호하십시오.
   • 복원할 경우, 백업이 침해 이전에 이루어졌는지 확인하십시오.
2. 신뢰할 수 있는 소스에서 다시 빌드하십시오.
   • 로컬을 삭제하십시오. node_modules 및 잠금 파일을 삭제한 후, 검증된 패키지 소스에서 다시 설치하십시오.
   • CI에서 새 체크아웃을 수행하고 npm ci add_action('wp_ajax_ahc_update_settings', 'ahc_update_settings'); // 인증된 사용자만 npm 설치) 검증된 패키지 잠금을 사용하여, 그런 다음 보안 실행기에서 아티팩트를 다시 빌드하십시오.
   • 안전하고 통제된 환경에서 빌드를 생성하는 것을 선호하고 잠재적으로 손상된 아티팩트를 재사용하는 것을 피하십시오.
3. 손상된 패키지를 업그레이드하거나 제거하십시오.
   • 패키지가 악성인 경우, 저자가 수정 사항을 제공하면 안전한 버전으로 제거하거나 업그레이드하십시오. 이 특정 경우, 버전 >= 0.1.2 및 <= 0.1.19가 취약합니다 — 공식 권고를 주의 깊게 살펴보고 검증 후에만 업그레이드하십시오.
   • 즉각적인 업그레이드가 불가능한 경우, 의존성을 제거하거나 대체품으로 교체하십시오.
4. 자격 증명 회전 및 세션 무효화
   • 데이터베이스 비밀번호, 애플리케이션 API 키 및 유출되었을 수 있는 모든 토큰을 변경하십시오.
   • 모든 관리자 사용자에 대해 비밀번호 재설정을 강제하고 활성 세션을 무효화합니다.
   • SSH 배포 키와 CI 토큰을 취소하고 재발급합니다.
5. 접근을 감사하고 무단 사용자를 제거합니다.
   • WordPress 사용자 계정을 정리하고 알 수 없는 관리자를 제거합니다.
   • 의심스러운 로그인에 대해 호스팅 제어판, FTP, SFTP 및 SSH 접근 로그를 확인합니다.
   • 알 수 없는 계정이나 오래된 계정을 취소합니다.
6. 복구 후 강화 및 모니터링
   • 사이트가 깨끗하다는 것을 확인하고 의심스러운 아웃바운드 연결이나 예상치 못한 파일 변경 사항을 최소 며칠 동안 모니터링한 후에만 사이트를 다시 활성화합니다.
   • 관리형 WAF 뒤에 사이트를 두고 빈번한 악성 코드 스캔 및 파일 무결성 검사를 예약합니다.

---

장기적인 예방: 개발자 및 CI/CD 강화

공급망 공격은 생산 사이트만큼 개발자 생애 주기와 관련이 있습니다. 파이프라인을 안전하게 유지하십시오.

의존성 위생

• 커밋 잠금 파일(package-lock.json 또는 yarn.lock)을 소스 제어에 추가하고 npm ci CI에서 재현 가능한 설치를 선호합니다.
• 엄격한 버전 고정을 사용하고 ^ 또는 ~ 중요한 패키지에 대해 플로팅 범위를 피합니다.
• 새 의존성의 포스트 설치 및 프리 설치 스크립트를 수동으로 검토한 후 추가합니다.
• 프로덕션 코드에서 서드파티 패키지의 사용을 제한합니다. 패키지가 개발 중에만 사용되는 경우, 프로덕션 아티팩트에 도달하지 않도록 합니다.

CI/CD 및 워크플로우 보안

• CI 토큰에 대한 최소 권한을 적용하십시오: 필요한 최소 권한만 부여하십시오(예: 배포 전용 토큰).
• 비밀을 비밀 관리자에 저장하십시오; 절대 리포지토리에 두지 마십시오.
• CI 구성 보호: CI 파이프라인을 변경할 수 있는 워크플로에 대해 PR 검토 및 브랜치 보호를 요구하십시오.
• 가능할 때 일회성 러너를 사용하고 러너 자격 증명을 정기적으로 교체하십시오.
• 소스 제어 호스팅 계정에 대해 이중 인증을 요구하고 누가 병합/배포할 수 있는지 제한하십시오.

코드 검토 및 자동화

• 빌드 스크립트에 영향을 미치는 모든 변경 사항에 대해 필수 코드 검토를 시행하십시오, 패키지.json 또는 CI 워크플로.
• 자동화된 종속성 모니터링(새로 발견된 취약점에 대한 경고)을 활성화하고 공급망 권고를 높은 우선 순위로 처리하십시오.
• 재현 가능한 아티팩트를 구축하고 배포 전에 아티팩트 자체가 악성 소프트웨어에 대해 스캔되도록 하십시오.

패키지 무결성 및 레지스트리

• 패키지 무결성 검사(패키지 잠금 shas, npm ci)를 사용하고 중요한 패키지에 대해 개인 레지스트리 또는 미러를 고려하십시오.
• 패키지가 확인되지 않은 출처에서 가져오거나 무결성 검사가 실패할 경우 빌드 시스템이 실패하도록 구성하십시오.

---

WordPress에 특정한 WAF 및 서버 수준 완화

공급망 악성 소프트웨어는 개발자 및 CI 수준에서 해결해야 하지만, 악성 아티팩트가 프로덕션에 도달할 경우 영향을 줄이기 위해 WordPress 서버를 강화할 수 있습니다.

고려해야 할 WAF 규칙

• 업로드 디렉토리에서 PHP 파일 실행 차단:
  • 거부 *.php 15. uploads 내부에 생성하거나 수정하십시오: wp-content/uploads.
• 민감한 파일 및 디렉토리에 대한 접근 차단:
  • 접근 거부 .git, .env, node_modules, .github/workflows, package-lock.json 공개 HTTP 요청에서.
• 웹쉘에 일반적인 패턴을 감지하고 차단합니다:
  • 요청이 포함된 eval(base64_decode(, exec(, system(, passthru(, shell_exec(.
• 의심스러운 POST 요청에 대한 비율 제한 및 차단 wp-로그인.php 그리고 xmlrpc.php.
• 서버에서 알려진 악성 IP/도메인 및 새로 관찰된 예상치 못한 호스트에 대한 아웃바운드 요청을 차단합니다.

(구현은 귀하의 WAF 제품에 따라 다릅니다; 관리형 WP‑Firewall WAF 사용자로서 코드를 수정하지 않고 이러한 패턴을 차단하는 규칙을 만들 수 있습니다.)

서버 강화

• 필요하지 않은 디렉토리(업로드)에서 PHP 실행을 비활성화합니다.
• 파일 권한이 엄격한지 확인합니다(웹 서버 사용자는 필요한 권한만 가져야 함).
• 서버 소프트웨어(OS, 웹 서버, PHP)를 보안 패치로 최신 상태로 유지합니다.
• 빌드 아티팩트 및 배포 단계를 별도의 환경으로 격리합니다 — 프로덕션 비밀로 프로덕션 서버에서 빌드 도구를 실행하지 마십시오.

---

사고 대응 체크리스트(구체적인 순서)

1. 탐지 — 지표 확인(의심스러운 네트워크 활동, 파일, CI 로그).
2. 격리 — 트래픽 차단, 배포 비활성화, 시스템 스냅샷.
3. 조사 — 로그 수집, 초기 진입 식별, 손상 범위 파악.
4. 근절 — 악성 파일 제거, 깨끗한 소스에서 재구축.
5. 복구 — 자격 증명 회전, 깨끗한 빌드 재배포, 적극적으로 모니터링.
6. 교훈 — 플레이북 업데이트, 파이프라인 및 개발자 관행 강화, 이해관계자에게 전달.

수행한 모든 단계를 문서화합니다. 좋은 로그와 스냅샷은 복구와 관련 보안 자문 또는 패키지 레지스트리에 보고하는 데 모두 중요합니다.

---

깨끗한 복구를 확인하는 방법

• 파일 무결성 검증: 업로드에 예상치 못한 PHP 파일이 없고, 테마 및 플러그인이 알려진 좋은 버전과 일치합니다.
• 알려지지 않은 관리자 사용자가 없음을 확인하고 마지막 로그인 타임스탬프를 검증합니다.
• CI 로그가 깨끗한 실행을 보여주는지 확인하십시오(포스트 설치 오류 또는 알 수 없는 스크립트 없음).
• 서버에서 네트워크 이gress를 최소 30일 동안 모니터링하여 악성 인프라에 대한 반복되거나 지연된 콜백이 있는지 확인하십시오.
• 맬웨어 스캔을 다시 실행하고 일정 기간 동안 더 자주 스캔을 예약하십시오.

---

샘플 빠른 명령 및 쿼리(기술 팀용)

업로드 및 최근 변경된 파일에서 새로운 PHP 파일을 검색하십시오:

# 업로드에서 PHP 파일 찾기(나쁨) find wp-content/uploads -type f -name "*.php" -print

# wp-content에서 지난 7일 동안 변경된 파일 찾기 find wp-content -type f -mtime -7 -print

node_modules에서 포스트 설치 스크립트 및 의심스러운 패턴을 검색하십시오:

grep -R --line-number '"postinstall"' node_modules || true

grep -R --line-number -E "eval\(|child_process|exec\(|spawn\(|base64|Buffer.from\(" node_modules || true

예상치 못한 커밋에 대한 git 기록을 확인하십시오:

wp user list --role=administrator --format=csv

---

# 지난 30일 동안 package.json 또는 workflows에 영향을 미친 커밋 목록 git log --since="30 days" --pretty=oneline -- package.json package-lock.json .github/workflows || true

• WP‑CLI를 통해 알 수 없는 관리자 사용자를 확인하십시오: npm ci 실용적인 개발자 정책 체크리스트(필수 항목).
• 잠금 파일을 커밋하고 CI에서 사용하십시오.
• CI 워크플로를 편집할 수 있는 사람을 제한하고 모든 워크플로 변경에 대해 PR 검토를 요구하십시오.
• 비밀을 금고에 저장하고 실행 중 CI에 일시적인 액세스를 부여하십시오.
• 병합하기 전에 패키지에서 비정상적인 스크립트나 종속성을 스캔하십시오.
• 소스 제어 및 CI 계정에 대해 2FA 및 최소 권한을 시행하십시오.

---

자동화된 취약성 모니터링을 예약하고 공급망 권고를 중요 사항으로 취급하십시오.

• 업로드에서 PHP 실행 거부:
  • Apache에서: wp-content/uploads에 PHP 실행을 거부하는 .htaccess 추가.
  • Nginx에서: 업로드에 대한 php‑fastcgi 처리를 방지하는 location 블록 추가.
• 접근 차단 .git 및 기타 점 파일:
  • 거부 /.git/*, /.env, /package-lock.json, /node_modules/* 외부 접근으로부터.
• 큰 의심스러운 파일 업로드를 차단하고 허용된 파일 유형을 화이트리스트로 제한.

이러한 규칙은 위험이 낮고 공격 표면을 즉시 줄여줍니다.

---

이해관계자 및 개발자와의 소통

• CVE‑2026‑46412와 같은 권고가 나타날 때:
  • 개발 팀과 호스팅/운영 팀에 즉시 알리십시오.
  • 종속성 목록을 실행하고 사용하는 패키지를 강조 표시합니다. postinstall.
  • GitHub/GitLab 작업 변경 사항을 긴급으로 처리하고 최근 워크플로우 커밋을 검사합니다.

명확한 수정 일정 제공 및 개발자가 자격 증명을 회전하지 않고 CI를 정리하지 않고 재배포하면 타협이 재발할 수 있음을 이해하도록 합니다.

---

강력하게 시작하세요: 오늘 무료 관리 방화벽 보호 받기

조사하고 파이프라인을 강화하는 동안 보호 계층을 추가하는 즉각적이고 낮은 마찰의 방법을 원하신다면, WordPress용 WP‑Firewall의 무료 플랜을 고려해 보세요. 기본(무료) 플랜은 지금 당장 중요한 필수 보호를 제공합니다:

• 일반 웹 페이로드를 차단하는 규칙이 있는 관리 방화벽
• 무제한 대역폭 및 프로덕션 등급 WAF
• 의심스러운 PHP 파일과 웹쉘을 탐지하는 데 도움이 되는 악성코드 스캔
• OWASP 상위 10대 위험에 대한 완화책

우리의 무료 요금제는 저수준 구성 관리를 필요로 하지 않는 즉각적이고 신뢰할 수 있는 보호가 필요한 사이트를 위해 설계되었습니다 — 개발자가 영향을 받은 아티팩트를 정리하고 재구성하는 동안 유용합니다. 여기에서 무료 기본 요금제에 대해 자세히 알아보고 가입하세요:
https://my.wp-firewall.com/buy/wp-firewall-free-plan/

자동화된 악성코드 제거, IP 차단 목록 및 복구를 지원하는 보고 기능이 필요하다면, 우리의 표준 및 프로 요금제가 기관 및 기업 환경을 위한 추가적인 수정 및 지원 기능을 제공합니다.

---

최종 생각: 개발자 파이프라인을 일급 보안으로 취급하세요

패키지 생태계에서 공급망 악성코드의 증가는 중요한 진리를 강조합니다: 애플리케이션 보안은 전체 생애 주기 문제입니다. 워드프레스 사이트 소유자에게 생산 사이트는 마지막 단계입니다 — 코드를 생성하고 아티팩트를 만드는 파이프라인은 라이브 사이트에 도달하기 훨씬 전에 많은 공격을 차단할 수 있는 곳입니다.

오늘 실행할 짧은 체크리스트:

• 영향을 받은 패키지와 의심스러운 포스트 설치 활동을 위해 리포지토리와 CI 로그를 검색하세요.
• 빌드에서 Node를 사용하는 경우 즉시 리포지토리 및 서버 스캔을 수행하세요.
• 의심되는 침해를 스냅샷하고 격리하세요; CI/배포에 사용되는 모든 비밀과 토큰을 교체하세요.
• 종속성을 정리하고 검증한 후 신뢰할 수 있는 환경에서 아티팩트를 재구성하세요.
• 사이트를 관리되는 WAF 뒤에 두고 악성코드 스캐너를 활성화하세요 — 무료 WP-Firewall 기본 요금제가 복구하는 동안 빠른 보호 계층을 제공합니다.

사건 분류에 도움이 필요하거나 CI 강화, WAF 서명 조정 또는 악성코드 정리에 도움이 필요하다면 보안 전문가에게 연락하세요. 공급망 공격은 국가 규모의 문제지만 사이트 수준의 조치는 실제로 차이를 만듭니다 — 탐지, 격리로 시작하고 개발 생애 주기에 장기적인 파이프라인 위생을 구축하세요.