MyMedi 테마 (< 1.7.7) 반사 XSS (CVE-2026-25351): 워드프레스 사이트 소유자가 알아야 할 사항과 자신을 보호하는 방법

작가: WP‑Firewall 보안 팀
날짜: 2026-03-21
태그: 워드프레스, 테마, XSS, 취약점, WAF, 보안

요약: MyMedi 워드프레스 테마에 영향을 미치는 반사형 교차 사이트 스크립팅(XSS) 취약점(1.7.7에서 수정됨, CVE-2026-25351)은 공격자가 조작된 링크를 통해 방문자의 브라우저에 악성 스크립트를 주입하고 실행할 수 있게 합니다. 이 게시물에서는 위험, 실제 영향, 탐지 및 완화 옵션, 사이트 소유자와 개발자가 취해야 할 단계별 조치 — WP-Firewall이 공식 패치를 적용하는 동안 사이트를 즉시 보호할 수 있는 방법을 설명합니다.

요약하자면

• 취약점: MyMedi 테마 버전 1.7.7 이전의 반사형 교차 사이트 스크립팅(XSS) (CVE-2026-25351).
• 심각도: 중간 (CVSS 7.1).
• 영향을 받는 버전: MyMedi 테마 < 1.7.7 (테마 개발자가 1.7.7에서 수정함).
• 공격 벡터: 사용자가 방문하거나 클릭할 때 스크립트가 브라우저에서 실행되도록 하는 URL을 조작하는 것(사용자 상호작용 필요).
• 즉각적인 조치: 테마를 1.7.7 이상으로 업데이트하십시오. 즉시 업데이트할 수 없는 경우 WAF/가상 패치를 적용하고, 사이트를 강화하며, 의심스러운 요청에 대한 로그를 모니터링하십시오.
• WP-Firewall은 업데이트하는 동안 일반 XSS 페이로드와 의심스러운 입력을 차단하는 규칙으로 즉각적이고 관리된 완화를 제공할 수 있습니다.

무슨 일이 있었나요? 쉬운 설명

2026년 3월 20일, MyMedi 워드프레스 테마(1.7.7 이전 버전)에 영향을 미치는 반사형 XSS 문제가 공개적으로 발표되었고 CVE-2026-25351이 할당되었습니다. 반사형 XSS는 HTTP 요청(예: 쿼리 문자열 매개변수 또는 양식 필드)에서 제공된 데이터가 적절한 정화 또는 인코딩 없이 페이지 응답에 포함될 때 발생하며, 공격자는 피해자의 브라우저에서 주입된 JavaScript가 실행되도록 하는 URL을 조작할 수 있습니다.

이 MyMedi 문제의 주요 특징:

• 취약점은 반사형이며 저장되지 않습니다 — 악성 콘텐츠는 페이지 응답에서 즉시 반환되며 데이터베이스에 저장되지 않습니다.
• 인증되지 않은 공격자가 이를 유발할 수 있지만, 성공적인 악용은 사용자 상호작용(예: 피해자가 조작된 링크를 클릭함)을 필요로 합니다.
• 이 취약점은 사이트의 컨텍스트에서 임의의 JavaScript 실행을 허용하며, 이는 세션 도용, 계정 탈취, 피싱 또는 방문자에게 악성 페이로드를 제공하는 결과를 초래할 수 있습니다.

반사형 XSS는 대규모 피싱 캠페인에서 무기화될 수 있기 때문에, 특히 관리 로그인이나 상점이 있는 사이트의 테마 사용자에게 심각한 위험으로 간주됩니다.

기술 개요 (비악용)

반사된 XSS는 일반적으로 다음 패턴을 따릅니다:

1. 애플리케이션은 요청(쿼리 매개변수, 양식 필드, 참조자 헤더 등)에서 입력을 수락합니다.
2. 그 입력은 적절한 정화 또는 출력 인코딩 없이 서버의 HTML 응답에 반영됩니다.
3. 공격자는 입력에 악성 스크립트가 포함된 URL을 조작합니다.
4. 사용자가 URL을 방문하면 브라우저는 주입된 스크립트를 포함한 HTML을 수신하고 사이트의 컨텍스트에서 이를 실행합니다.

MyMedi 버전 < 1.7.7:

• 테마는 요청 데이터를 HTML로 다시 에코하는 출력 파이프라인의 자리를 가지고 있었으며, 사용된 컨텍스트에 대해 이스케이프/인코딩하지 않았습니다.
• 제품 유지 관리자는 잘못된 이스케이프/인코딩을 수정한 1.7.7을 출시했습니다.

중요한: 현대 WordPress 개발에서 올바른 접근 방식은:

• sanitize_text_field(), wp_kses_post()와 같은 함수를 사용하여 입력을 조기에 검증하고 정리하며, 적절한 경우 허용된 HTML에 대해 esc_url_raw()를 사용합니다.
• 출력 시 컨텍스트에 맞는 올바른 이스케이프 함수를 사용하여 데이터를 이스케이프합니다: esc_html(), esc_attr(), esc_js(), esc_url() 등.

이것이 중요한 이유: 실제 위험 및 시나리오

반사된 XSS는 단순한 이론적 문제가 아닙니다. 취약한 MyMedi 테마를 실행하는 사이트에 대한 구체적이고 현실적인 영향은 다음과 같습니다:

• 자격 증명 도용: 관리자가 로그인한 상태에서 악성 링크를 클릭하도록 속으면, 스크립트가 쿠키나 인증 토큰을 유출할 수 있습니다(쿠키가 HttpOnly이고 다른 완화 조치가 없는 경우 제외).
• 세션 하이재킹: 세션 쿠키에 대한 접근은 공격자가 사용자를 가장할 수 있게 합니다.
• 지속적인 피싱: 공격자는 가짜 관리자 페이지나 체크아웃 양식을 표시하여 자격 증명이나 결제 세부 정보를 수집할 수 있습니다.
• 드라이브 바이 악성코드: 스크립트는 사용자를 외부 악성 페이지로 리디렉션하거나 광고를 제공하거나 추가 악성코드를 로드할 수 있습니다.
• 평판 및 SEO 손상: 악성코드나 피싱 페이지는 검색 엔진 및 보안 공급자에 의해 블랙리스트에 올라가 트래픽과 비즈니스에 피해를 줄 수 있습니다.

악용에는 조작된 링크와 사용자 상호작용만 필요하므로, 대규모 피싱 캠페인은 빠르게 많은 사이트 방문자에게 도달할 수 있습니다.

누가 행동해야 하는가

귀하의 사이트가 MyMedi 테마를 사용하고 있으며 테마 버전이 1.7.7보다 오래된 경우, 귀하는 영향을 받습니다. 우선 순위를 매기십시오:

• 로그인한 고객이 있는 전자상거래 사이트.
• 여러 사용자 역할(관리자, 편집자)이 있는 사이트.
• 많은 사용자가 악성 링크를 클릭할 수 있는 고트래픽 공개 사이트.
• Single Sign‑On (SSO) 또는 제3자 결제 시스템과 통합된 사이트.

클라이언트 사이트를 관리하는 개발자 또는 에이전시인 경우, 클라이언트 알림 및 수정 작업을 우선시하십시오.

사이트 소유자를 위한 즉각적인 체크리스트 (단계별)

이 실용적이고 우선순위가 매겨진 체크리스트를 따라 사이트를 신속하게 보호하십시오.

1. 버전을 확인하십시오.
   • WordPress 관리자에서 외모 → 테마 → MyMedi로 이동하여 버전을 확인하십시오.
   • 또는 테마의 style.css 헤더를 열어 버전을 확인하십시오.
2. 테마 업데이트
   • MyMedi를 버전 1.7.7 이상으로 즉시 업데이트하십시오. 이것이 취약점에 대한 확실한 수정입니다.
   • 테마 파일을 직접 수정한 경우, 업데이트를 통제된 방식으로 적용하십시오: 먼저 백업하고 자식 테마를 사용하여 사용자 지정을 다시 적용하십시오.
3. 즉시 업데이트할 수 없는 경우, 보상 조치를 적용하십시오 (아래 참조).
   • 반사된 XSS 페이로드를 차단하기 위해 웹 애플리케이션 방화벽(WAF) 규칙을 활성화하십시오.
   • 삽입된 스크립트의 영향을 줄이기 위해 콘텐츠 보안 정책(CSP)을 추가하십시오 (아래 CSP 안내 참조).
   • 쿠키 플래그를 강화하십시오: 중요한 쿠키가 HttpOnly 및 Secure인지 확인하십시오.
4. 손상 여부를 스캔하세요
   • 예상치 못한 변경 사항에 대해 사이트 파일을 스캔하십시오 (알 수 없는 PHP 파일, 수정된 테마 파일).
   • 삽입된 HTML/JS에 대해 데이터베이스 내용을 확인하십시오 (예: 게시물, 옵션, 위젯 내용).
   • 의심스러운 쿼리 문자열이나 반복된 시도를 위해 서버 및 접근 로그를 검토하십시오.
5. 침해가 의심되는 경우 자격 증명을 재설정하십시오.
   • 악의적인 활동의 증거를 발견한 경우 관리자의 비밀번호 재설정을 강제하십시오.
   • 사이트에서 사용되는 모든 API 키, 토큰 또는 SSO 클라이언트 비밀을 취소하고 교체하십시오.
6. 수정 후 테스트
   • 개인 브라우저에서 중요한 흐름(로그인, 체크아웃, 양식)을 테스트하고 예상치 못한 스크립트가 없는지 확인하십시오.
   • 적용 가능한 경우 캐시 및 CDN 자산을 재구성하십시오.
7. 모니터링 및 보고
   • 취약성과 일치하는 시도를 위해 로그 및 WAF 이벤트를 주의 깊게 살펴보십시오.
   • 침해된 경우, 사고 대응 플레이북을 따르고 데이터 노출이 가능할 경우 영향을 받는 사용자에게 알리십시오.

보완 통제 및 WAF 전략( WP‑Firewall이 권장하는 사항)

1.7.7로 업데이트하는 것이 올바른 장기 수정이지만, 즉각적인 가상 패치 및 WAF 규칙은 업데이트를 계획하고 배포하는 동안 노출을 줄일 수 있습니다.

반사된 XSS에 대한 효과적인 WAF 전략:

• 잘 정의된 컨텍스트에서 쿼리 문자열 및 헤더의 의심스러운 문자를 차단하십시오:
  • 일반적인 XSS 마커는 , script, onerror, onload, javascript:, data:, eval(, document.cookie, location=, innerHTML — 그러나 합법적인 기능을 방해할 수 있는 단순 차단은 피하십시오(예: 귀하의 사이트가 합법적으로 데이터 URI를 사용하는 경우).
• 컨텍스트 인식 규칙을 사용하십시오:
  • 매개변수가 숫자일 것으로 예상되는 경우 비숫자 문자를 차단하십시오.
  • 매개변수가 슬러그인 경우 [a‑z0‑9‑_]만 허용하십시오.
• 서명을 적용하기 전에 입력을 정규화하고 디코딩하십시오:
  • 많은 회피 기술은 URL 인코딩 또는 HTML 엔티티에 의존합니다. WAF 규칙은 디코딩된 값을 검사해야 합니다.
• 의심스러운 요청에 대해 비율 제한 또는 도전하십시오:
  • 고위험 요청 패턴의 경우, CAPTCHA를 제시하거나 임계값이 초과되면 차단하십시오.
• 매개변수를 조사하려는 알려진 악성 사용자 에이전트 및 스크레이퍼를 차단하십시오.

WP‑Firewall은 다음과 같은 관리 규칙을 배포할 수 있습니다:

• 익스플로잇 세부정보를 공개하지 않고 반사된 XSS 패턴을 감지하고 차단합니다.
• 악성 요청이 WordPress에 도달하기 전에 엣지에서 가상 패치를 적용합니다.
• 차단된 이벤트에 대해 로그를 기록하고 경고하여 시도된 익스플로잇 시도를 검토할 수 있도록 합니다.

메모: 가상 패칭은 테마 업데이트의 대체물이 아니며, 패치하는 동안 시간을 벌고 공격 표면을 줄입니다.

개발자 및 테마 저자를 위한 강화 권장 사항

사용자 정의 테마를 유지 관리하는 개발자(또는 MyMedi에 기여하는 경우)는 다음의 보안 코딩 관행을 적용하십시오:

1. 출처에서 입력을 정화하십시오
   • 처리하기 전에 들어오는 데이터에 대해 sanitize_text_field(), sanitize_email(), esc_url_raw()를 사용하십시오.
   • 수용해야 하는 HTML의 경우, 엄격한 허용 목록과 함께 wp_kses() 또는 wp_kses_post()를 사용하십시오.
2. 올바른 컨텍스트에 대해 출력을 이스케이프하십시오
   • HTML 본문 텍스트: esc_html()
   • 속성 값: esc_attr()
   • URL: esc_url()
   • JavaScript 컨텍스트: wp_json_encode() 또는 esc_js()
   • 인라인 JavaScript에 데이터를 에코할 때는 항상 wp_localize_script()를 사용하거나 서버 데이터를 json‑encode하고 그에 따라 이스케이프하십시오.
3. 클라이언트 측보다 서버 측 유효성 검사를 선호하십시오
   • 클라이언트 유효성 검사는 사용자 경험을 향상시키지만 쉽게 우회될 수 있습니다. 서버에서 다시 검증하십시오.
4. 원시 요청 변수를 에코하는 것을 피하십시오
   • $_GET, $_POST, $_REQUEST 또는 헤더를 직접 신뢰하지 마십시오; 출력 전에 정화하고 이스케이프하십시오.
5. 액션 엔드포인트에 대해 논스를 사용하십시오
   • 상태를 변경하는 작업의 경우, CSRF로 인한 연쇄 공격을 방지하기 위해 항상 유효한 논스를 요구하십시오.
6. 추가 완화를 위해 CSP를 구현하십시오
   • 엄격한 콘텐츠 보안 정책(CSP)은 스크립트 실행 소스를 제한할 수 있습니다. 예:
     Content‑Security‑Policy: default‑src 'self'; script‑src 'self' https://trusted.cdn.example; object‑src 'none'; base‑uri 'self';
   • CSP는 심층 방어이며 신중하게 테스트해야 합니다(타사 스크립트가 중단될 수 있습니다).
7. CI/CD에서 보안 테스트
   • 불안전한 출력 패턴을 잡기 위해 지속적인 통합에 SAST/DAST 스캔을 포함하세요.
   • 템플릿에서 변수의 적절한 이스케이프를 주장하는 자동화된 테스트를 사용하세요.

시도된 악용을 감지하는 방법(로그에서 무엇을 찾아야 하는지)

반사된 XSS 악용 시도를 감지하려면 웹 서버 로그, 애플리케이션 로그, WAF 로그 및 분석에서 의심스러운 패턴을 검색해야 합니다. 지표에는 다음이 포함됩니다:

• 쿼리 문자열에 스크립트 키워드를 포함하는 요청:
  • 예제 패턴: script=, , script, javascript:, onerror=, onload=.
• 알려지지 않은 IP 주소에서 비정상적인 쿼리 매개변수를 가진 동일 페이지에 대한 여러 요청.
• referer 헤더가 비어 있거나 의심스러운 쿼리 문자열과 결합된 예상치 못한 출처에서 온 항목.
• 동일한 엔드포인트와 관련된 4xx 또는 5xx 응답의 비정상적인 급증.
• XSS 또는 의심스러운 입력으로 레이블이 붙은 차단된 패턴을 보여주는 WAF 로그.

다음에 대한 경고 규칙을 설정하세요:

• 각도 괄호 또는 JavaScript 의사 프로토콜을 포함하는 쿼리 문자열.
• 길거나 고도로 인코딩된 매개변수 값을 가진 요청.
• 짧은 시간 내에 동일한 엔드포인트를 대상으로 하는 고유 쿼리 문자열의 높은 볼륨.

응답 및 복구: 손상이 의심되는 경우

1. 격리하다
   • 손상이 심각하고 정리할 시간이 필요하면 사이트를 오프라인(유지 관리 모드)으로 전환하세요.
   • 조사하는 동안 안전한 정적 메시지로 공개 페이지를 교체하세요.
2. 분류
   • 손상된 파일과 타임스탬프를 식별하세요. 백업 및 테마/플러그인 원본과 비교하세요.
   • 새로운 관리자 사용자, 수정된 테마 파일, 업로드 또는 테마 디렉토리의 낯선 PHP 파일을 확인하십시오.
3. 정리
   • 주입된 파일을 제거하고 가능한 경우 알려진 좋은 백업에서 복원하십시오.
   • 검증된 출처에서 MyMedi 테마를 재설치하십시오(1.7.7로 업데이트한 후).
   • 모든 관리자 비밀번호를 변경하고 필요시 모든 사용자에 대해 재설정을 강제하십시오.
4. 강화
   • 이전에 나열된 보안 조치를 적용하십시오(WAF 규칙, CSP, 쿠키 강화).
   • 파일 권한이 엄격한지 확인하십시오(예: wp-config.php는 웹 서버 사용자에 의해 쓰기 불가능해야 함).
5. 신뢰를 재구축하십시오.
   • 데이터나 사용자가 영향을 받았다면 법률 및 모범 사례에 따라 알림을 준비하십시오.
   • 이전에 플래그가 지정된 경우 검색 엔진 및 보안 블랙리스트에 깨끗한 사이트를 재제출하십시오.
6. 사후 분석 및 교훈
   • 패치 관리, 백업 빈도 및 모니터링을 개선하기 위한 검토를 수행하십시오.

현재 가상 패칭 및 관리형 방화벽 서비스가 중요한 이유

공급자가 수정 사항을 발표하더라도 많은 사이트는 호환되지 않는 사용자 정의, 테스트 부족 또는 호스팅 제한으로 인해 며칠, 몇 주 또는 그 이상 패치되지 않은 상태로 남아 있습니다. 가상 패칭(WAF 규칙이 공격 패턴을 차단함)은 그 기간 동안 즉각적인 보호를 제공합니다.

가상 패치의 이점:

• 사이트 코드를 수정하지 않고 즉각적인 보호를 제공합니다.
• 취약성 패턴에 맞춘 세분화된 규칙.
• 악용 시도에 대한 모니터링 및 가시성.
• 최소한의 위험으로 공식 업데이트를 예약하고 테스트할 시간입니다.

WP-Firewall의 관리 규칙 세트는 다음을 위해 설계되었습니다:

• 컨텍스트 전반에 걸쳐 반사된 XSS 페이로드를 감지합니다.
• 잠재적으로 악의적인 요청을 차단하거나 도전합니다(CAPTCHA/JS 도전).
• 컨텍스트 및 매개변수별 규칙을 사용하여 허위 긍정을 줄입니다.

다시 말해, 가상 패칭은 임시방편이며, 테마 업데이트는 가능한 한 빨리 적용해야 합니다.

예시 보안 강화 체크리스트 (운영)

• 테마 버전을 확인하십시오; MyMedi를 1.7.7 이상으로 업데이트하십시오.
• 패칭하는 동안 XSS에 대해 WP‑Firewall 관리 규칙을 적용하십시오.
• 엄격한 쿠키 플래그를 활성화하십시오: HttpOnly, Secure, SameSite.
• 콘텐츠 보안 정책(CSP)을 구성하고 먼저 보고 전용 모드에서 테스트하십시오.
• 변경 사항 및 악성코드를 스캔하고, 손상된 파일을 백업에서 복원하십시오.
• 손상 증거가 있는 경우 관리자 및 API 자격 증명을 교체하십시오.
• 사용자 역할을 검토하고 사용하지 않는 관리자 계정을 제거하십시오.
• 의심스러운 쿼리 패턴에 대한 로깅 및 경고를 활성화하십시오.
• 백업을 유지하고 복원 절차를 테스트하십시오.

개발자 노트: 보안 템플릿 패턴

테마 템플릿에서 동적 데이터를 출력할 때는 다음 패턴을 따르십시오:

• 일반 텍스트 출력의 경우:
  echo esc_html( $variable );
• 속성 값의 경우:
  echo esc_attr( $variable );
• URL의 경우:
  echo esc_url( $url );
• 스크립트를 지역화할 때:
  wp_localize_script( 'script-handle', 'wpData', array( 'nonce' => wp_create_nonce( 'action' ) ) );
  연결 대신 인라인 스크립트에 JSON을 삽입할 때는 wp_json_encode()를 선호하십시오.
• 안전한 HTML을 허용할 때:
  echo wp_kses_post( $html );
  또는 wp_kses()로 명시적으로 허용된 태그/속성 집합을 지정하십시오.

피하십시오:
echo $변수; // 이스케이프 없이
신뢰할 수 없는 입력을 JavaScript 또는 인라인 이벤트 핸들러에 직접 출력하기.

콘텐츠 보안 정책 (CSP) — 실용적인 시작

CSP는 인라인 스크립트 실행을 방지하고 출처를 제한하여 XSS의 결과를 크게 줄일 수 있습니다. 헤더 접근 방식을 사용하십시오; 보고 전용 모드에서 관대 한 정책으로 시작하고 점차 강화하십시오.

예시 (보고 전용으로 시작):

헤더:
Content‑Security‑Policy‑Report‑Only: default‑src 'self'; script‑src 'self' https://trusted.cdn.example; object‑src 'none'; base‑uri 'self'; report‑uri https://csp.example/report

확신이 생기면, 시행하십시오:
Content‑Security‑Policy: default‑src 'self'; script‑src 'self' https://trusted.cdn.example; object‑src 'none'; base‑uri 'self'; report‑uri https://csp.example/report

참고:

• CSP는 서드파티 스크립트와 일부 플러그인 기능을 중단시킬 수 있으므로, 스테이징에서 신중하게 테스트하십시오.
• 논스 기반 CSP는 인라인 스크립트에 더 유연하지만 일관된 논스 생성 및 삽입이 필요합니다.

자주 묻는 질문

큐: 내 사이트는 이미 CDN을 사용하고 있습니다 — 이것이 나를 보호합니까?
에이: CDN은 캐싱 및 DDoS 완화를 제공할 수 있으며, 일부 CDN은 WAF 기능을 제공합니다. 그러나 핵심 문제는 테마의 불안전한 출력입니다. WAF가 악의적인 요청을 차단하지 않는 한 CDN만으로는 테마 수준의 XSS를 해결할 수 없습니다.

큐: 취약점이 사용자 상호작용을 요구하면 덜 심각합니까?
에이: 반드시 그렇지는 않습니다. 사용자 상호작용은 종종 많은 사용자에게 도달할 수 있는 피싱 또는 사회 공학 캠페인을 통해 이루어집니다. 관리자가 또는 특권 사용자가 조작된 링크를 클릭하면 결과가 심각할 수 있습니다.

큐: 플러그인이 유사한 문제를 일으킬 수 있습니까?
에이: 예. 반사형 및 저장형 XSS는 테마, 플러그인 또는 사용자 정의 코드에 존재할 수 있습니다. 모든 코드에 대해 동일한 정화 및 이스케이프 원칙을 적용하십시오.

큐: 댓글이나 사용자 제출 콘텐츠를 비활성화해야 합니까?
에이: 반드시 그럴 필요는 없습니다. 대신, 콘텐츠를 적절하게 정리하고 이스케이프하며 노출을 줄이는 조정 설정을 고려하세요.

탐지 스크립트 예제 (안전하고 비착취적)

아래는 의심스러운 쿼리 문자열을 찾기 위해 액세스 로그에 대해 실행할 수 있는 안전한 읽기 전용 패턴 검색입니다 — 이는 탐지 전용이며 착취 세부정보를 제공하지 않습니다.

명령 (리눅스):
grep -E -i '(|<|javascript:|onerror|onload|document\.cookie|eval\()' /var/log/nginx/access.log | less

해석:

• 이는 URL 디코딩 후 XSS 시도에서 자주 나타나는 일반적인 마커를 찾습니다.
• 잘못된 긍정 결과가 반환될 수 있습니다; 조치를 취하기 전에 일치 항목을 신중하게 검토하세요.

WP‑Firewall의 접근 방식에 대하여

우리는 계층화된 보호를 제공합니다:

• WordPress 테마와 플러그인에 맞춘 관리형 WAF 규칙.
• 고위험 패턴을 신속하게 차단하기 위한 가상 패치.
• 감염된 사이트에 대한 악성코드 스캔 및 복구 지원.
• 사이트 소유자가 패치를 우선순위에 두고 적용할 수 있도록 하는 실행 가능한 경고 및 보고.

우리의 철학은 실용적입니다: 가장자리에서 공격을 방지하고, 코드에서 안전한 관행을 구현하도록 돕고, 사건을 탐지하고 복구할 수 있는 운영 통제를 보장합니다.

오늘 귀하의 사이트를 보호하세요 — WP‑Firewall 무료로 시작하세요

우리는 많은 사이트 소유자가 운영을 방해하지 않고 즉각적이고 신뢰할 수 있는 보호가 필요하다는 것을 이해합니다. WP‑Firewall은 몇 분 안에 활성화할 수 있는 필수 방어를 제공하는 기본 무료 요금제를 제공합니다:

• 필수 보호 기능: 관리형 방화벽, 무제한 대역폭, 웹 애플리케이션 방화벽(WAF), 악성코드 검사기, OWASP Top 10 위험 완화.
• 업데이트 및 테스트를 조정하는 동안 능동적인 방어를 원하는 사이트 소유자에게 이상적입니다.

더 많은 자동화 및 추가 안전 기능을 원하신다면, 자동 악성코드 제거, IP 블랙리스트/화이트리스트에 대한 더 큰 제어, 상세한 월간 보고서, 자동 취약점 가상 패치 및 전담 계정 관리 및 관리 보안 서비스와 같은 프리미엄 추가 기능이 포함된 유료 요금제도 제공합니다.

여기에서 무료 요금제 및 업그레이드 옵션을 등록하거나 검토하세요:
https://my.wp-firewall.com/buy/wp-firewall-free-plan/

최종 권장 사항 — 지금 당장 할 일

1. MyMedi 테마 버전을 확인하세요; < 1.7.7인 경우 즉시 1.7.7로 업데이트하세요.
2. 즉시 업데이트할 수 없는 경우, XSS에 대한 WP‑Firewall의 관리 규칙을 활성화하고 모니터링을 활성화하세요.
3. 사이트에서 손상 징후를 스캔하고, 발견되면 위의 복구 단계를 따르십시오.
4. 테마 템플릿을 강화하고 이스케이프/정화 모범 사례를 따르십시오.
5. 취약점 모니터링 서비스에 가입하고 테마/플러그인 및 해당 버전의 목록을 유지하십시오.

보안을 유지하는 것은 신속한 패치, 스마트한 경계 방어 및 좋은 코딩 관행의 조합입니다. 노출 평가, WAF 규칙 세트 배포 또는 정리 수행에 도움이 필요하면, 저희 WP‑Firewall 보안 팀이 귀하의 WordPress 사이트를 빠르고 안전하게 보호하는 데 도움을 드릴 수 있습니다.

원하신다면, 우리는:

• 특정 호스팅 환경에 맞춘 짧고 맞춤화된 체크리스트를 제공하십시오.
• 무료 사이트 스캔을 실행하고 즉각적인 위험 요약을 제공하십시오.
• 사용자 정의를 유지하는 테마 업데이트를 위한 단계적 업데이트 프로세스를 만드는 데 도움을 주십시오.

WP‑Firewall 콘솔을 통해 저희 보안 팀에 연락하거나 무료 플랜에 가입하여 시작하십시오:
https://my.wp-firewall.com/buy/wp-firewall-free-plan/