SillyTavern의 SSRF (<= 1.17.0): 워드프레스 사이트 소유자가 알아야 할 사항과 WP‑Firewall이 당신을 보호하는 방법

날짜: 2026-05-19
작가: WP‑Firewall 보안 팀

태그: 보안, 워드프레스, ssrf, 취약점, waf, 사고 대응

요약

2026년 5월 19일, NPM 패키지 “바보주점” (<= 1.17.0)에 영향을 미치는 고위험 서버 측 요청 위조(SSRF) 취약점이 공개되었습니다(CVE‑2026‑46372, GHSA‑qg89‑qwwh‑5f3j). 이 문제는 검증되지 않은 baseUrl 매개변수에서 발생합니다. 공격자는 이 결함을 악용하여 영향을 받는 서버가 공격자가 제어하는 주소나 내부 주소로 HTTP 요청을 하도록 강제할 수 있으며, 이는 자격 증명, 메타데이터 엔드포인트, 내부 서비스가 노출되거나 추가적인 측면 이동을 가능하게 할 수 있습니다. 이 패키지는 1.18.0 버전에서 패치되었습니다. sillytavern에 의존하거나 리버스 프록시 기능을 노출하는 서비스를 운영하는 경우, 이를 긴급하게 처리하십시오.

이 게시물은 기술적 세부 사항을 간단한 언어로 설명하며, 워드프레스 관리자가 왜 신경 써야 하는지, 악용 시도를 감지하는 방법, 권장되는 즉각적 및 장기적 완화 조치, 지금 배포할 수 있는 샘플 WAF 규칙(워드프레스 방화벽 안내 포함), 그리고 침해가 의심될 경우 따를 수 있는 사고 대응 체크리스트를 제공합니다.

이것이 워드프레스 사이트 소유자에게 중요한 이유

처음 보기에는 NPM 패키지 취약점이 워드프레스와 직접적으로 관련이 없어 보일 수 있습니다. 그러나 현대의 워드프레스 환경은 거의 고립되어 있지 않습니다:

• 워드프레스 사이트는 종종 동일한 호스팅 계정이나 VM에서 다른 서비스와 공존합니다(캐싱 레이어, 헤드리스 프론트엔드/백엔드, 채팅 에이전트, 봇 또는 자체 호스팅 통합).
• 팀은 워드프레스 애플리케이션과 동일한 인프라에서 혼합 기술 도구(Node.js 마이크로서비스, 채팅 프론트엔드, 자체 호스팅 어시스턴트)를 운영합니다.
• 공격자를 대신하여 아웃바운드 HTTP(S) 요청을 수행하도록 유도될 수 있는 모든 구성 요소는 내부 엔드포인트(예: 메타데이터 API, 관리 패널, 데이터베이스 포트)에 접근하거나 절대 공개되어서는 안 되는 내부 서비스에 도달하는 데 무기화될 수 있습니다.

SSRF는 공격자가 서버 측 HTTP 요청의 대상을 제어할 수 있기 때문에 높은 영향력을 가진 버그 클래스입니다. 이는 접근할 수 없는 내부 리소스에 대한 접근을 가능하게 할 수 있습니다. 다른 서비스와 네트워킹이나 자격 증명을 공유하는 워드프레스 환경의 경우, 하나의 패키지에서 발생한 SSRF도 심각한 결과를 초래할 수 있습니다.

기술적 배경 — 무슨 일이 있었는가

SillyTavern은 일부 기능을 위해 SearXNG를 검색 프록시로 사용합니다. 취약한 버전(<= 1.17.0)에서는 baseUrl 검색 프록시를 구성하는 값이 제대로 검증되거나 제한되지 않았습니다. 이는 공격자가 baseUrl 애플리케이션이 공격자가 결정한 임의의 URL로 요청을 하도록 공급하거나 조작할 수 있게 했습니다.

취약점의 주요 특징:

• 클래스: 서버 사이드 요청 위조 (SSRF).
• 근본 원인: 프록시 호출에 전달된 URL/구성 매개변수의 불충분한 검증 (baseUrl)입니다.
• 영향: 취약한 서버는 내부 IP, 클라우드 메타데이터 엔드포인트(169.254.169.254), 기타 내부 관리 API 또는 서버가 도달할 수 있는 모든 호스트에 요청을 수행하도록 만들 수 있습니다. 공격자는 피해자와 동일한 네트워크에 있을 필요가 없으며, 단지 취약한 코드 경로를 트리거할 수 있으면 됩니다.
• 패치: sillytavern v1.18.0은 공격자 제어를 방지하기 위한 검증 및 제한을 포함합니다. baseUrl 값.

CVE 및 권고 식별자(추적용): CVE‑2026‑46372, GHSA‑qg89‑qwwh‑5f3j.

가능한 악용 시나리오 (고급)

아래는 SSRF가 위험한 이유를 설명하기 위한 대표적인 시나리오입니다. 익스플로잇 코드를 제시하는 것은 피하지만, 그럴듯한 공격을 이해하는 것이 중요합니다:

• 클라우드 메타데이터 검색: 서버가 클라우드 제공업체 메타데이터 엔드포인트에 도달할 수 있다면, 공격자는 자격 증명 토큰이나 인스턴스 메타데이터(예: 169.254.169.254의 AWS IMDS)를 요청할 수 있어 클라우드 API 접근을 상승시킬 수 있습니다.
• 내부 관리자 인터페이스 접근: 많은 애플리케이션이 로컬호스트 또는 내부 서브넷에서 관리 API를 노출합니다. SSRF는 이러한 API에 접근하는 데 사용될 수 있으며(예: 127.0.0.1에 바인딩된 관리 엔드포인트 또는 HTTP를 통해 노출된 Docker/RPC 소켓) 파괴적인 작업을 트리거할 수 있습니다.
• 포트 스캐닝 및 내부 탐색: 공격자는 취약한 서버를 피벗으로 사용하여 내부 IP 범위를 스캔하고 인터넷에서 도달할 수 없는 서비스를 매핑할 수 있습니다.
• 네트워크 접근 규칙 우회: 일부 네트워크는 특정 시스템에 대한 직접 외부 접근을 제한합니다. SSRF는 피해자 서버가 대신 요청을 하게 하여 이러한 제한을 우회할 수 있습니다.
• 내부 엔드포인트를 통한 데이터 유출: 일부 서비스는 내부 API 또는 디버그 엔드포인트를 통해 민감한 데이터를 노출합니다. SSRF는 이러한 엔드포인트를 요청하고 결과를 공격자에게 반환할 수 있습니다(직접 또는 리디렉션된 응답을 통해).

취약한 매개변수가 아웃바운드 대상을 구성하기 때문에, 공격자는 유용한 데이터를 직접 반환하거나 데이터 공개로 이어지는 후속 요청 체인을 설정하는 요청을 작성할 수 있습니다.

악용 시도를 감지하는 방법

SSRF 시도를 탐지하려면 웹 요청과 서버의 아웃바운드 활동을 모두 모니터링해야 합니다. 다음은 실용적인 탐지 신호입니다:

• 웹 서버 로그: 특히 비정상적인 매개변수를 가진 요청을 찾습니다. baseUrl, 프록시, url, 대상, 또는 기타 URL 매개변수. 비정상적으로 긴 값이나 인코딩된 값, URL에 있는 기본 인증 자격 증명, 또는 http://169.254.169.254 또는 개인 IP 범위를 포함하는 값은 경고 신호입니다.
• 애플리케이션 로그: HTTP 요청을 수행하고 목적지 주소를 기록하는 코드 경로를 확인합니다. 아웃바운드 요청 빈도의 급증이나 단일 프록시 엔드포인트에 대한 반복 요청은 의심스럽습니다.
• 아웃바운드 네트워크 로그: 1. 웹 서버 프로세스에서 내부 IP 범위로의 연결 또는 169.254.169.254, 127.0.0.1, 개인 RFC1918 범위 또는 IPv6 링크 로컬 주소로의 예상치 못한 연결에 대한 이그레스 로그를 검사하십시오.2. fe80::/10).
• 3. DNS 로그: 4. 빠른 TTL 변경이 있는 무작위 서브도메인 또는 도메인에 대한 DNS 쿼리를 찾으십시오(잠재적인 DNS 기반 회피).
• WAF 로그: 5. 의심스러운 값을 포함하는 모든 시도를 차단하고 모니터링하십시오. baseUrl 6. 또는 개인 IP 범위와 일치하는 패턴.
• 7. 프로세스 행동: 8. PHP/Node 런타임에서 네트워크 호출을 하는 새로운 프로세스나 CPU/DNS 활동의 급증은 자동화된 악용 시도를 나타낼 수 있습니다.

9. 이러한 기준선을 조기에 설정하여 이탈이 두드러지도록 하십시오.

10. 즉각적인 조치 — 다음 몇 시간 내에 할 일

1. 11. 소프트웨어 패치
   12. SillyTavern 또는 sillytavern에 의존하는 서비스를 실행하는 경우 즉시 v1.18.0으로 업데이트하십시오. 그것이 올바른 수정이며 근본적인 버그를 제거합니다.
2. 즉시 업데이트할 수 없는 경우, 가상 패치를 적용하십시오.
   13. 악의적인 사용을 감지하고 차단하기 위해 WAF 규칙을 배포하십시오. baseUrl 14. (아래 예시).
   15. URL을 수락하거나 프록시하는 모든 엔드포인트에 대한 공개 액세스를 제한하십시오. baseUrl 16. 아웃고잉 연결을 제한하십시오.
3. 17. 호스트 이그레스 규칙(클라우드 보안 그룹, 방화벽 규칙, iptables 또는 호스팅 제어)을 사용하여 명시적으로 허용된 목적지 외의 아웃바운드 트래픽을 거부하십시오.
   18. 최소한 클라우드 메타데이터 엔드포인트(169.254.169.254) 및 내부 관리 네트워크에 대한 액세스를 차단하십시오.
   19. 격리하고 조사하십시오.
4. 격리하고 조사하다
   1. 탐지 목록에서 의심스러운 지표를 감지하면 영향을 받은 호스트를 격리하고 포렌식을 위해 로그를 보존하십시오. 자격 증명 도용 또는 추가 손상의 징후를 확인하십시오.
5. 2. 자격 증명 및 비밀을 회전하십시오(필요한 경우).
   3. 클라우드 메타데이터 또는 관리자 API가 쿼리되었을 수 있는 경우 영향을 받은 API 키 및 자격 증명을 회전하십시오.
6. 4. 후속 조치를 모니터링하십시오.
   5. 새로운 사용자 계정, 변경된 구성, 수정된 파일 또는 후속 활동을 나타낼 수 있는 예약된 작업을 찾으십시오.

6. WP‑방화벽 완화 및 예제 규칙

7. 웹 애플리케이션 방화벽 공급업체로서, 우리는 계층적 접근 방식을 권장합니다: 이 특정 벡터에 대한 즉각적인 WAF 규칙 세트와 깊이 있는 방어를 위한 호스트/네트워크 이그레스 제어.

8. 아래는 즉시 배포할 수 있는 샘플 규칙입니다. 이는 귀하의 플랫폼에 맞게 조정될 수 있는 일반적인 규칙 예제(ModSecurity 스타일)입니다. 합법적인 트래픽이 중단되지 않도록 프로덕션에 배포하기 전에 스테이징 환경에서 규칙을 테스트하십시오.

중요 참고 사항: 9. 이는 탐지 및 차단 패턴입니다. 의도적으로 방어적이며, 이를 유일한 보호 수단으로 사용하지 마십시오 — 취약한 패키지를 업데이트하는 것은 여전히 필수입니다.

10. 1) 요청 차단 baseUrl 11. 개인 IP 또는 메타데이터 엔드포인트를 참조하는

12. # 개인 IP 또는 메타데이터 엔드포인트를 포함하는 baseUrl 매개변수를 확인하십시오."

SecRule ARGS_NAMES|ARGS "@rx (?i)^(baseurl|base_url|proxy_url|target_url)$" "phase:2,pass,id:100001,log,ctl:ruleRemoveById=981172"

• SecRule ARGS:baseUrl|ARGS:base_url|ARGS:proxy_url|ARGS:target_url \n "@rx (?i)(127\.0\.0\.1|localhost|10\.\d{1,3}\.\d{1,3}\.\d{1,3}|172\.(1[6-9]|2[0-9]|3[0-1])\.\d{1,3}\.\d{1,3}|192\.168\.\d{1,3}\.\d{1,3}|169\.254\.169\.254|fe80:|::1)" \n "phase:2,deny,status:403,msg:'잠재적인 SSRF 차단 - baseUrl에서 허용되지 않는 대상',id:100002,log" baseUrl 13. 이것이 하는 일:.

14. localhost, 개인 RFC1918 범위, AWS 메타데이터 IP 또는 IPv6 링크-로컬 주소를 포함하는 경우 요청을 거부합니다.

15. 2) 내장된 자격 증명 또는 의심스러운 프로토콜이 있는 URL 거부"

16. # 기본 인증 자격 증명 또는 위험한 프로토콜이 있는 URL 차단

SecRule ARGS "@rx [a-z0-9+\-.]+://[^@]+@|^(file|gopher|dict|scp|ssh):" \n "phase:2,deny,status:403,msg:'잠재적인 SSRF 차단 - 자격 증명 또는 안전하지 않은 스킴 발견',id:100003,log" baseUrl 17. 3) 반복된 프록시 요청에 대한 속도 제한 또는 차단

# 속도 제한 예제 (개념적)"

(위의 내용은 자동화된 악용을 줄이기 위해 사용자 정의 속도 제한 검사를 통합하는 방법을 보여줍니다.)

4) 개인 주소로 해석되는 DNS 조회 차단

더 발전된 접근 방식은 제공된 호스트의 DNS 해석을 수행하고 개인 IP로 해석되면 차단하는 것입니다. 이는 외부 검사를 위한 WAF 지원 또는 프록시 서비스 사용이 필요합니다.

5) WP‑Firewall 관리 규칙

WP‑Firewall 고객은 다음과 같은 관리 서명을 받게 됩니다:

• 쿼리 매개변수 및 JSON 페이로드에서 일반적인 SSRF 패턴을 감지하고 차단합니다.
• 메타데이터 또는 RFC1918 IP 범위를 대상으로 하는 요청을 거부합니다.
• DNS 리바인딩 또는 내부 주소로 해석되는 호스트 이름을 감지하기 위해 휴리스틱을 적용합니다.

WP‑Firewall 고객이라면 관리 규칙이 활성화되어 있고 자동 규칙 업데이트가 활성 상태인지 확인하십시오.

개발자를 위한 보안 강화 가이드 (코드 수정)

외부 URL 또는 프록시 구성을 수용하는 코드를 유지 관리하거나 개발하는 경우, 이러한 보안 코딩 관행을 채택하십시오:

• 허용 목록 사용: 애플리케이션이 합법적으로 연락해야 하는 특정 호스트 이름(또는 명확하게 정의된 호스트 이름 집합)만 허용합니다.
• 비HTTP 스킴 거부: http 그리고 https 적절한 경우에만 수락합니다. 거부합니다. file:, 고퍼:, ssh:, 등.
• 호스트 검증 시행: URL을 서버 측에서 구문 분석하고 허용 목록에 대해 호스트 구성 요소를 검증합니다. 개인 범위의 IP를 거부합니다.
• 내장 자격 증명 방지: user:pass@host가 포함된 URL을 허용하지 않습니다..
• 호스트 이름을 해석하고 IP 주소를 검증합니다: 호스트 이름을 허용하는 경우 DNS 해석을 수행하고 해석된 IP가 개인적이거나 의심스러운 경우 거부합니다. DNS 경쟁 조건에 유의하고 복원력 있는 검사를 사용하십시오(예: 안전한 해석기를 사용하여 해석 수행).
• 타임아웃 및 제한: 요청 타임아웃 및 리디렉션 제한을 설정하여 요청 스머글링 및 장기 연결을 피하십시오.
• 사용자 제공 값을 구성으로 직접 사용하지 마십시오: 구성 매개변수를 사용 전에 엄격한 검증이 필요한 민감한 입력으로 취급하십시오.

이러한 수정 유형은 SillyTavern 유지 관리자가 취약점을 해결하기 위해 v1.18.0 릴리스에서 구현한 것입니다.

호스트 및 네트워크 수준 보호

애플리케이션 수정에만 의존하는 것은 충분하지 않습니다. 네트워크 제어를 추가하십시오:

• 명시적으로 요구되지 않는 한 웹 프로세스가 내부 전용 서비스에 접근하지 못하도록 하십시오. 호스트 이그레스 방화벽 규칙(iptables / nftables), 클라우드 보안 그룹 또는 이그레스 프록시를 사용하여 아웃바운드 HTTP를 제한하십시오.
• 애플리케이션에서 클라우드 API가 필요하지 않은 경우 애플리케이션 인스턴스에서 클라우드 메타데이터 접근을 차단하십시오. 예를 들어, 웹 프로세스에서 169.254.169.254로의 아웃바운드 트래픽을 차단하거나 노출을 제한하는 인스턴스 역할 정책을 사용하십시오.
• 구성 요소 간 최소 권한 네트워킹으로 분리된 네트워크 세그먼트에서 서비스를 실행하십시오.
• 가능하다면, 허용 목록을 시행하고 활동을 기록하는 모니터링된 제어 프록시를 통해 아웃바운드 요청을 강제하십시오.

이러한 조치는 애플리케이션이 취약하더라도 SSRF가 도달할 수 있는 범위를 제한합니다.

사고 대응 체크리스트 (실용적인 단계)

착취가 의심되는 경우, 이 순서화된 체크리스트를 따르십시오:

1. 증거 보존
   로그를 캡처하십시오(웹, 애플리케이션, 방화벽, DNS 및 네트워크 흐름). 로그를 덮어쓰지 마십시오.
2. 포함
   취약한 기능 또는 엔드포인트를 일시적으로 비활성화하십시오.
   호스트를 접근 제어(IP 제한) 뒤에 두거나 서비스에 대한 공개 접근을 비활성화하십시오.
3. 패치
   sillytavern을 v1.18.0으로 업데이트하거나 공급업체 권장 수정 사항을 적용하십시오.
4. 분석
   의심스러운 접근 로그를 검사하세요 baseUrl 값, 반복된 프록시 요청 또는 개인 IP 대상을 포함하는 요청.
   호스트에서 발생하는 아웃바운드 연결 및 DNS 쿼리를 확인하십시오.
5. 비밀을 회전하다
   클라우드 메타데이터나 자격 증명이 노출되었다고 생각되는 이유가 있는 경우 API 키, 토큰 및 서비스 자격 증명을 회전하십시오.
6. 스캔하고 정리하세요.
   서버에서 전체 맬웨어 스캔 및 무결성 검사를 실행하여 가능한 포스트 익스플로잇 아티팩트를 감지하십시오.
7. 복원 및 모니터링
   시스템이 깨끗하고 강화되었다고 확신할 수 있을 때만 정상 운영을 재개하십시오. 최소 30일 동안 모니터링을 강화하십시오.
8. 보고하십시오.
   필요한 경우, 사고 대응 정책 및 규제 의무에 따라 보안 팀, 호스팅 제공업체 또는 고객에게 알리십시오.

검색할 탐지 및 로그 예시

시도된 악용의 징후를 찾기 위해 로그를 검색하세요(또는 이러한 쿼리를 호스팅 제공업체에 제공하세요):

• 매개변수가 포함된 요청:
  • ?baseUrl=
  • ?proxy= 또는 ?target=
  • 포함된 POST/JSON 본문 baseUrl 또는 proxy_url
• 포함된 매개변수의 값:
  • 169.254.169.254
  • 127.0.0.1 또는 로컬/개인 범위,
  • 10. / 172.16.–172.31. / 192.168.
  • fe80: 또는 ::1
  • @ (내장된 자격 증명을 나타냄)
• 웹 서버 IP에서 시작된 개인 범위로의 갑작스러운 아웃바운드 요청 급증.
• 위에서 언급한 서명이 반복적으로 트리거되는 WAF 로그.

웹, 네트워크 및 DNS 로그에서 이러한 발견 사항을 수집하고 상관관계 분석하세요.

업데이트가 여전히 가장 중요한 단계인 이유

WAF 규칙, 아웃바운드 필터링 및 호스트 제한은 위험을 줄이지만 보완적 제어입니다. 진정한 해결책은 취약한 소프트웨어를 패치하는 것입니다. 공격자가 페이로드를 변경하거나 합법적인 사용이 필요한 경우 가상 패치는 실패할 수 있습니다. sillytavern v1.18.0으로 업데이트하면 소스에서 취약성을 제거하고 장기적인 공격 표면을 줄입니다.

WP‑Firewall이 WordPress 환경을 보호하는 방법

WP‑Firewall에서는 관리 규칙, 능동적 탐지 및 쉬운 수정 방법을 결합하여 WordPress 사이트와 그 주변 인프라를 보호하는 데 집중합니다:

• 관리 서명: 우리의 규칙 업데이트에는 SSRF 탐지 패턴과 검증되지 않은 악용 시도를 차단하기 위한 조정된 휴리스틱이 포함됩니다. baseUrl 또는 프록시 매개변수입니다.
• 가상 패치: 긴급 취약점이 공개되면, WP‑Firewall은 WAF를 통해 가상 패치를 배포하여 코드 업데이트를 계획하는 동안 노출을 줄일 수 있습니다.
• 악성 코드 스캔: 우리는 SSRF 피벗에 따라 발생할 수 있는 침해 지표 및 의심스러운 변경 사항을 스캔합니다.
• 이그레스 및 속도 제어: WP‑Firewall은 의심스러운 엔드포인트를 조절하고 비정상적인 아웃바운드 요청 패턴을 감지하도록 구성할 수 있습니다.
• 안내 및 사고 지원: 우리의 전문가들은 단계별 수정 안내를 제공하고 로그 해석 및 사고 대응을 도와줄 수 있습니다.

WP‑Firewall 보호를 공급업체 패치(v1.18.0) 및 호스트 네트워크 강화와 결합하여 최상의 방어를 제공합니다.

보안 구성 체크리스트(요약)

• sillytavern을 v1.18.0(또는 이후 버전)으로 업데이트하십시오.
• WP‑Firewall 관리 규칙을 활성화하고 자동 서명 업데이트가 활성화되어 있는지 확인하십시오.
• 차단하는 WAF 규칙 배포 baseUrl 개인 범위, 메타데이터 IP 및 내장 자격 증명을 가리킵니다.
• 웹 프로세스에 대한 아웃바운드 네트워크 액세스를 제한하고, 앱 프로세스에서 클라우드 메타데이터 엔드포인트를 차단하십시오.
• 다른 사용자 제공 URL 매개변수에 대해 애플리케이션 코드를 검토하고 그에 따라 강화하십시오.
• 의심스러운 프록시 사용에 대한 로그를 모니터링하고 비정상적인 아웃바운드 연결에 대한 경고를 구현하십시오.
• 메타데이터 또는 내부 엔드포인트에 접근했을 가능성이 있는 경우 자격 증명을 교체하십시오.
• 악용이 의심되는 경우 전체 조사 및 악성 코드 스캔을 수행하십시오.

즉각적인 보호를 위해 가입하세요: WP‑Firewall 무료 플랜으로 시작하십시오.

WP‑Firewall 무료 플랜으로 사이트를 빠르게 보호하세요.

아직 보호받지 못하고 있다면, WP‑Firewall의 기본(무료) 플랜은 취약한 구성 요소를 업데이트하는 동안 즉각적인 완화를 얻을 수 있는 훌륭한 방법입니다. 무료 플랜에는 관리형 웹 애플리케이션 방화벽(WAF), 악성 코드 스캐너, 무제한 대역폭 및 OWASP Top 10 위험에 대한 완화와 같은 필수 보호 기능이 포함되어 있습니다. 일반적인 SSRF 악용 패턴을 차단하고 즉각적인 노출을 줄이는 데 필요한 모든 것이 포함되어 있습니다. 다음 링크에서 빠르게 가입하고 보호를 활성화할 수 있습니다:

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

추가 자동화(자동 악성 코드 제거, IP 블랙리스트/화이트리스트) 또는 고급 기능(월간 보안 보고서, 자동 가상 패치 및 관리형 보안 서비스)이 필요하다면, 다음 단계로 표준 또는 프로 등급으로 업그레이드하는 것을 고려해 보세요.

마지막 생각

SSRF 취약점은 자신의 호스트를 정찰 및 공격 플랫폼으로 전환하기 때문에 강력합니다. Node.js 서비스와 인프라를 공유하거나 혼합 환경에서 운영하는 WordPress 사이트 소유자 및 운영자에게 이 SillyTavern SSRF 문제는 다음을 상기시켜주는 시의적절한 경고입니다:

• 신속하게 패치하세요.
• WAF를 사용하여 신속한 가상 패치를 제공합니다.
• 이그레스 규칙과 네트워크 세분화를 강화합니다.
• 로그를 모니터링하고 대응할 준비를 합니다.

노출 평가 또는 안내된 완화 적용에 도움이 필요하다면, WP‑Firewall의 보안 팀이 가상 패치를 적용하고 맞춤형 WAF 규칙을 작성하며 조사를 수행하는 데 도움을 줄 수 있습니다. 빠르게 보호를 추가하기 위해 무료 플랜으로 시작하고, 악용 지표를 발견하면 더 깊은 지원을 위해 우리 팀에 연락하세요.

안전을 유지하세요 — 소프트웨어를 최신 상태로 유지하고, 입력을 검증하며, 각 서버가 네트워크에서 수행할 수 있는 작업을 최소화하세요.