
| 플러그인 이름 | 사용자 얼굴 |
|---|---|
| 취약점 유형 | 크로스 사이트 스크립팅(XSS) |
| CVE 번호 | CVE-2026-8038 |
| 긴급 | 중간 |
| CVE 게시 날짜 | 2026-05-19 |
| 소스 URL | CVE-2026-8038 |
긴급: “사용자 얼굴” WordPress 플러그인(≤ 0.0.3)에서 저장된 XSS — 사이트 소유자 및 개발자가 지금 해야 할 일
게시됨: 2026년 5월 19일
심각성: 낮음 (CVSS 6.5) — 저장된 교차 사이트 스크립팅 (CVE-2026-8038)
필요한 권한: 기여자 (인증됨)
취약한 버전: ≤ 0.0.3
최근 공개된 취약점은 “사용자 얼굴” WordPress 플러그인(버전 0.0.3 포함)에서 인증된 기여자가 악성 JavaScript를 저장할 수 있게 하며, 이는 영향을 받는 콘텐츠를 보는 다른 사용자들의 맥락에서 실행됩니다. 이 취약점은 저장된 교차 사이트 스크립팅(XSS)으로 분류되며 CVE-2026-8038이 할당되었습니다. 심각도는 일부 점수 시스템에서 낮음으로 평가되지만, 이 종류의 버그는 체인 공격 및 사이트 탈취 캠페인에서 자주 활용됩니다 — 특히 다수의 저자가 있는 사이트와 외부 협력자 또는 신뢰할 수 없는 사용자에게 편집자/기여자 역할을 부여하는 사이트에서 그렇습니다.
이 게시물에서는 다음을 안내합니다:
– 이 취약점이 무엇인지 및 왜 중요한지;
– 현실적인 공격 및 남용 시나리오;
– 귀하의 사이트가 영향을 받았거나 악용되었는지 감지하는 방법;
– 즉각적인 완화 조치(수동 및 방화벽 기반); 및
– 개발자를 위한 권장 코드 수정 및 장기적인 강화.
이 가이드는 WP‑Firewall과 함께 작업하는 WordPress 보안 전문가의 관점에서 작성되었습니다 — 지금 바로 구현할 수 있는 실용적이고 실질적인 조언입니다.
사이트 소유자를 위한 간단한 요약(TL;DR)
- 무엇: 사용자 얼굴 플러그인에서 저장된 XSS는 기여자가 나중에 실행되는 JavaScript를 삽입할 수 있게 합니다.
- 11. 누가: 사용자 얼굴 플러그인 ≤ 0.0.3을 실행하는 사이트.
- 위험: 기여자 계정을 가진 공격자는 방문자 또는 관리자 브라우저에서 실행되는 스크립트를 주입할 수 있습니다(세션 탈취, 권한 상승, 은밀한 백도어).
- 즉각적인 조치:
- 가능하다면 패치된 버전이 출시되면 플러그인을 업데이트하십시오.
- 플러그인을 제거하거나 일시적으로 비활성화하십시오.
- 기여자 계정을 제한하거나 감사하고, 알려지지 않은 기여자를 제거하십시오.
- 가능성 있는 페이로드를 차단하기 위해 WAF 규칙(가상 패치)을 설정하십시오.
- 착취의 징후를 스캔하고 감염된 파일이나 DB 항목을 정리하십시오.
- 장기적으로: 안전한 코딩 패턴(정리/이스케이프)을 적용하고 최소 권한을 강제하며, 런타임 WAF 보호 및 정기적인 악성 코드 스캔을 활성화하십시오.
CVSS가 “낮음”일 때 저장된 XSS가 위험한 이유”
저장된 XSS(지속적인 XSS라고도 함)는 사용자 제공 데이터가 애플리케이션(데이터베이스, 옵션, 미디어 등)에 저장되고 적절한 이스케이프나 정리 없이 다른 사용자에게 다시 렌더링될 때 발생합니다. 실제 영향은 맥락에 따라 다릅니다 — 페이로드가 출력되는 위치(프론트엔드 방문자 페이지 대 관리자 대시보드), 대상 사용자의 권한, 그리고 콘텐츠 보안 정책(CSP) 및 HTTP 전용 쿠키와 같은 추가 보호 조치.
기여자 역할이 필요한 취약점은 제한적으로 들릴 수 있지만, 기여자 수준의 계정은 일반적으로 게스트 블로거, 계약자 또는 커뮤니티 구성원에게 사용됩니다. 악성 스크립트가 관리자, 사이트 소유자 또는 다른 권한이 있는 사용자의 브라우저에서 실행되면(관리자가 감염된 페이지나 미리보기를 보는 경우) 공격자는 해당 사용자를 대신하여 작업을 수행할 수 있습니다(인증된 세션을 통해). 일반적인 결과는 다음과 같습니다:
- 인증 쿠키 또는 세션 토큰을 훔치는 것(그런 다음 계정을 탈취).
- WordPress REST API 호출을 통해 은밀한 관리자 사용자를 생성하거나 백도어가 포함된 게시물을 형성하는 것.
- 원격 사이트 리디렉션이나 숨겨진 iframe 수익화를 유발하는 JavaScript 기반 백도어 삽입.
- 서버 측 손상으로 전환(악성 파일 업로드, 테마/플러그인 수정).
따라서 초기 벡터가 로그인한 기여자를 요구하더라도, 하류 효과는 심각하고 광범위할 수 있습니다.
이 취약점이 발생할 가능성이 있는 방법(기술 개요)
여기에서 익스플로잇 페이로드나 정확한 재현 단계를 게시하지는 않겠지만, 이와 같은 저장된 XSS는 일반적으로 플러그인 코드의 다음과 같은 하나 이상의 약점으로 인해 발생합니다:
- 인증된 사용자로부터 HTML 또는 텍스트를 수락하고 정리 없이 데이터베이스에 저장하는 것(예: 사용자 프로필 필드, “얼굴” 설명, 캡션).
- 의도된 맥락에 대해 이스케이프하지 않는 함수 사용하여 해당 저장된 콘텐츠를 페이지에 다시 출력하는 것(예: HTML 속성 내에서 원시 값을 에코하거나 이스케이프 없이 HTML 콘텐츠로 출력).
- 저장하기 전에 입력을 정리하지 않거나 기능 확인이 누락되고, 플러그인 제어 템플릿 출력을 신뢰하는 렌더링 논리와 결합된 경우.
일반적인 실패 패턴:
- 사용 중
echo $값값이 신뢰할 수 없는 HTML/JS를 포함할 수 있는 출력에 대해. - 저장하거나 출력할 때
텍스트 필드 삭제(),wp_kses_post(),esc_html(),esc_attr(), 또는 유사한 호출이 누락됨. - 기여자가 제출한 값을 수락하고 더 높은 권한의 사용자가 볼 수 있는 관리자 또는 작성자 미리보기 페이지 내에서 렌더링하는 것.
현실적인 착취 시나리오
적절히 분류할 수 있도록 가능한 남용 경로를 이해하십시오:
- 기여자가 프로필, 얼굴 설명 또는 사용자 메타 필드에 스크립트를 삽입합니다.
- 해당 스크립트는 DB에 저장됩니다.
- 관리자가 사용자 목록, 프로필 또는 얼굴 위젯을 렌더링하는 페이지를 볼 때, 스크립트가 그들의 브라우저에서 실행됩니다.
- 관리 세션 쿠키 또는 특권 작업이 남용될 수 있습니다.
- 기여자가 프론트엔드 위젯이나 저자 바이오에 나타나는 콘텐츠를 게시합니다.
- 방문자가 영향을 받을 수 있습니다(리디렉션, 가짜 로그인 양식, 악성 광고).
- 방문자에 사이트 관리자나 특권 직원이 포함되면, 악용이 확대됩니다.
- 추가 악성 코드의 발판으로 사용되는 지속적인 감염
- 지속적인 XSS는 공격자가 제어하는 도메인에서 추가 스크립트를 로드할 수 있으며, 작은 버그를 장기적인 백도어로 전환합니다.
귀하의 사이트가 악용될 수 있는 징후
귀하의 사이트가 Faces of Users ≤ 0.0.3을 실행하는 경우, 이러한 지표를 확인하십시오:
- 사용자 메타, wp_posts 또는 플러그인 전용 테이블에 저장된 예상치 못한 태그, 이벤트 핸들러(onclick, onmouseover) 또는 javascript: URI.
- 새로 추가된 관리자 사용자 또는 귀하가 승인하지 않은 기존 사용자에 대한 변경 사항.
- wp-content/uploads에 새 파일이 있거나 테마/플러그인에 익숙하지 않은 PHP 파일이 추가되었습니다.
- 서버 로그에서 알려지지 않은 도메인으로의 비정상적인 아웃바운드 연결.
- 방문자에 대한 브라우저 경고 또는 네트워크 오류, 또는 리디렉션/팝업에 대한 사용자 불만.
- 관리자가 관리 대시보드를 탐색할 때 팝업, 예상치 못한 모달 또는 리디렉션을 보는 경우.
DB에서 확인하는 방법(비파괴적 검사):
- 찾다
wp_usermeta“<script” 또는 “onmouseover=”를 포함하는 값에 대해(주의; 백업 없이 원시 DB 항목을 편집하지 마십시오). - 찾다
wp_posts예기치 않은 스크립트 태그나 iframe에 대해. - WP-CLI를 사용하는 경우:
wp db 쿼리 "SELECT meta_id, user_id, meta_key, meta_value FROM wp_usermeta WHERE meta_value LIKE '%<script%';"wp db 쿼리 "SELECT ID, post_title FROM wp_posts WHERE post_content LIKE '%
변경하기 전에 항상 백업을 수행하세요.
즉각적인 완화 조치 (사이트 소유자, 비기술 친화적)
- 플러그인을 비활성화하십시오
위험을 제거하기 위해 일시적인 다운타임을 감당할 수 있다면, 패치가 제공될 때까지 즉시 사용자 얼굴 플러그인을 비활성화하세요. - 기여자 계정 제한
- 기여자 이상의 권한을 가진 모든 사용자를 검토하세요. 알 수 없거나 사용되지 않는 계정을 제거하거나 강등하세요.
- 외부 기여자가 있는 사이트의 경우, 기여자 수를 제한하고 검증을 요구하세요.
- 소유자/관리자에 대해 비밀번호 재설정을 강제하세요.
침해가 의심되는 경우, 관리자 비밀번호를 재설정하고 지속적인 세션을 취소하세요 (WP는 세션 관리를 제공하며, 모든 곳에서 로그아웃을 강제할 수 있습니다). - 웹 애플리케이션 방화벽(WAF) 가상 패치를 활성화하십시오.
플러그인에 의해 렌더링된 입력에서 스크립트 태그와 일반적인 XSS 벡터를 차단하는 애플리케이션 방화벽 규칙(WAF/가상 패치)을 설정하세요. WAF는 플러그인이 아직 업데이트되지 않았더라도 악용 시도를 차단할 수 있습니다. - 사이트를 스캔하십시오.
악성 코드 스캐너를 사용하여 지속적인 XSS 및 기타 주입된 코드의 징후를 찾으세요. 파일과 데이터베이스 모두를 스캔하세요. WP‑Firewall은 저장된 콘텐츠와 파일을 검사하는 스캐너를 통합합니다. - 최근 변경 사항을 감사하십시오.
최근에 수정된 파일, 새로 생성된 관리자 또는 새로운 플러그인/테마를 찾으세요. - 즉시 백업하세요.
수정하거나 변경하기 전에 알려진 좋은 백업을 가져가세요; 사고 대응이나 정리 검증을 위해 필요할 수 있습니다. - 침해된 경우, 전체 정리 및 복원을 고려하세요.
악용의 징후(악성 스크립트 또는 알 수 없는 관리자)를 발견하면, 깨끗한 백업에서 재구성하고 신뢰할 수 있는 플러그인/테마만 다시 적용하세요.
실용적인 개발자 가이드 — 코드를 통해 이를 수정하는 방법
플러그인이나 기여자 콘텐츠를 수용하는 사용자 정의 통합을 유지하는 경우, 올바른 접근 방식은 입력 정화, 출력 이스케이프 및 권한 확인의 조합입니다.
1. 저장하기 전에 입력을 정화하세요 (서버 측)
- 일반 텍스트를 예상하는 경우: 사용하십시오
텍스트 필드 삭제()또는wp_strip_all_tags(). - 제한된 HTML을 예상하는 경우: 사용하세요.
wp_kses()허용 목록에 태그와 속성이 포함되어 있습니다. - WYSIWYG 콘텐츠를 수락하는 경우: 사용하십시오.
wp_kses_post().
사용자 제출 콘텐츠를 저장할 때의 예:
<?php
2. 올바른 컨텍스트에 대한 출력 이스케이프
- HTML 콘텐츠로 출력할 때, 사용합니다.
esc_html()일반 텍스트의 경우,wp_kses_post()안전한 HTML 및esc_attr()속성 컨텍스트에 대해. - 데이터베이스 콘텐츠의 원시 출력 피하기.
렌더링할 때의 예:
<?php
3. 저장/업데이트 시 권한 확인 강제
- 현재 사용자가 실제로 해당 작업을 수행할 권한이 있는지 확인하십시오.
- 사용
current_user_can( 'edit_user', $user_id )또는 적절한 권한.
예:
<?php
4. CSRF를 방지하기 위해 양식 제출에 nonce 사용
<?php
5. JavaScript 정화만 신뢰하지 않기
클라이언트 측 검증은 편리하지만 — 보안에 대해 의존하지 마십시오.
6. 저장된 HTML 출력 위치 검토
저장된 콘텐츠가 나중에 JavaScript 컨텍스트나 속성에 주입되는지 여부를 결정하십시오; 이스케이프 및 정화는 컨텍스트와 일치해야 합니다.
샘플 ModSecurity / WAF 규칙 패턴 (가상 패치)
플러그인을 즉시 패치할 수 없는 경우, WAF를 통한 가상 패치가 일반적인 XSS 벡터를 차단할 수 있습니다. 아래의 예시는 설명을 위한 것이며, 잘못된 긍정을 피하기 위해 귀하의 환경에 맞게 조정해야 합니다.
POST 본문에서 인라인 태그를 차단하기 위한 일반 규칙 (단순화된 예):
SecRule REQUEST_METHOD "POST" "chain,deny,status:403,msg:'XSS 차단 - POST의 스크립트 태그'"
일반 인코딩된 페이로드를 탐지하기 위한 규칙:
SecRule ARGS|REQUEST_BODY "(%3Cscript%3E|%3Csvg%20on|%3Ciframe%20)" \n "t:urlDecodeUni,t:lowercase,deny,log,msg:'Block encoded XSS payload'"
참고:
- 잘못된 긍정을 줄이기 위해 취약한 플러그인과 관련된 요청 경로만 타겟으로 하는 규칙을 조정하십시오 (예: 기여자 제출에 사용되는 URL).
- 합법적인 흐름이 중단되지 않도록 차단으로 전환하기 전에 감지 전용 모드에서 규칙을 테스트하십시오.
- WP‑Firewall 사용자는 미리 구축된 가상 패치를 활성화하고 대시보드를 통해 낮은 잘못된 긍정을 위해 조정할 수 있습니다.
포스트 익스플로잇 정리 체크리스트
공격자가 저장된 XSS를 악용한 것을 감지하면, 이 사건 대응 체크리스트를 따르십시오:
- 분리하다:
- 사이트를 유지 관리 모드로 전환하십시오.
- 필요시 외부 트래픽을 차단하십시오 (또는 IP로 관리자 접근을 제한하십시오).
- 조사:
- 주입 지점을 식별하십시오 (어떤 메타, 포스트 또는 플러그인 테이블이 악성 페이로드를 보유하고 있는지).
- 영향을 받은 사용자와 페이지를 열거하십시오.
- 근절하다:
- DB에서 악성 저장 값을 제거하십시오 (정리하거나 전체 필드 내용을 제거하십시오).
- 백도어 파일을 제거하십시오 (특히 업로드에서 wp-content의 최근 수정된 PHP 파일을 찾으십시오).
- 필요할 경우 깨끗한 백업에서 복원하십시오.
- 다시 덮다:
- 모든 관리자 수준 사용자와 침해된 것으로 의심되는 사용자에 대해 비밀번호를 재설정하십시오.
- API 키를 재발급하고 노출된 외부 비밀을 회전하십시오.
- 신뢰할 수 있는 출처에서 코어, 테마 및 플러그인 파일을 재설치하십시오.
- 강화:
- WordPress 코어 및 모든 플러그인/테마를 최신 안정 버전으로 업데이트하십시오.
- 사용하지 않는 플러그인과 테마를 제거합니다.
- 재악용을 방지하기 위해 WAF 규칙을 구현하십시오.
- 사용자 역할에 대해 최소 권한을 구현합니다.
- 감시 장치:
- 지속적인 파일 무결성 모니터링 및 DB 스캔을 설정하십시오.
- 의심스러운 파일 변경 및 새로운 관리자 사용자 생성을 위한 알림을 활성화합니다.
- 사고 후 검토:
- 근본 원인, 취약점을 허용한 요소 및 수정 방법을 문서화합니다.
- 플러그인을 유지 관리하는 경우 코드 수정 사항을 적용하고 업데이트를 릴리스합니다.
WordPress 사이트를 위한 보안 강화 모범 사례(장기적)
- 최소 권한 원칙: 신뢰할 수 있는 사람에게만 기여자 또는 편집자 역할을 부여합니다. 일회성 기여자의 경우, 콘텐츠가 양식을 통해 제출되고 관리자가 게시하는 워크플로를 고려합니다(Gravity Forms, WP forms).
- 모든 관리자/편집자 계정에 대한 이중 인증.
- 강력한 비밀번호 정책 및 특권 사용자에 대한 주기적인 강제 재설정.
- 가능한 경우 핵심 및 플러그인에 대한 자동 업데이트(스테이징에서 테스트 포함).
- 가상 패칭 및 이상 탐지를 제공하는 런타임 WAF를 사용합니다.
- 정기적인 악성 코드 스캔(파일 및 데이터베이스).
- XSS의 영향을 줄이기 위한 콘텐츠 보안 정책(CSP):
- CSP가 만병통치약은 아니지만, 취약점을 악용하기 어렵게 만들 수 있습니다(허용된 스크립트 소스를 제한하고 가능할 경우 인라인 스크립트를 허용하지 않음).
- 개발자에 의한 출력 인코딩 및 정화:
- 항상 입력 시 정화하고, 적절한 WordPress 함수를 사용하여 출력 시 이스케이프합니다.
- 데이터를 쓰는 모든 작업에 대해 nonce와 결합된 역할 또는 권한 기반 권한 검사를 사용합니다.
WP‑Firewall이 귀하를 보호하는 방법(관리형 방화벽 및 스캔이 어떻게 도움이 되는지)
WP‑Firewall에서는 계층적 접근 방식을 지지합니다: 예방, 탐지 및 대응.
- 관리형 WAF / 가상 패칭: 우리의 방화벽은 플러그인 패치를 설치하기 전에 저장된 XSS 벡터를 악용하려는 시도를 차단하는 규칙을 배포할 수 있습니다. 이는 노출 창을 줄입니다.
- 악성 코드 스캔 및 정리: 우리의 스캐너는 주입된 스크립트, 의심스러운 iframe 및 기타 침해 지표에 대해 파일 및 데이터베이스 콘텐츠를 검사합니다.
- 역할 및 요청 강화: 특정 사용자 역할에 의해 허용된 작업을 제한하고 플러그인 엔드포인트를 대상으로 하는 비정상적인 POST 요청을 차단할 수 있는 세분화된 규칙을 지원합니다.
- 사건 지원: 인젝션이 발견되면 악성 콘텐츠를 제거하고 공격 벡터를 차단하기 위한 지침과 도구를 제공합니다.
위의 코드 수준 권장 사항과 이러한 서비스를 결합하면 WordPress 플릿 전반에 걸쳐 저장된 XSS의 가능성과 영향을 크게 줄일 수 있습니다.
사이트 관리자를 위한 예시 대응 계획(실행 가능한 체크리스트)
- 사이트가 Faces of Users ≤ 0.0.3을 실행하는지 확인합니다.
- 패치가 즉시 제공되지 않는 경우 플러그인을 비활성화합니다.
- usermeta 및 게시물에서 “<script”, “onmouseover=”, “javascript:”에 대한 DB 검색을 실행합니다.
- 기여자를 검토하고 알 수 없는 계정을 취소합니다; 할당 전에 더 강력한 인증을 요구합니다.
- POST 본문에서 스크립트 태그와 인코딩된 페이로드를 포함하는 WAF 가상 패치 규칙을 활성화합니다.
- 관리 사용자에 대해 비밀번호를 강제로 재설정하고 모든 세션을 무효화합니다.
- 영향을 받은 DB 항목을 정리하거나 복원합니다; usermeta 및 게시물에서 주입된 스크립트를 제거합니다.
- 취약점이 패치된 후 공식 출처에서 플러그인/테마를 재설치합니다.
- 사건 발생 후 한 달 동안 로그인 및 파일 무결성을 모니터링합니다.
개발자 노트: 컨텍스트에 맞는 이스케이프
이스케이프는 컨텍스트에 따라 다르다는 것을 기억하세요. 사용하세요:
esc_html()HTML 본문에서 일반 텍스트에 대해.esc_attr()속성 값에 대해.esc_js()인라인 스크립트에 대해 (가능한 경우 인라인 스크립트를 피하세요).wp_kses()또는wp_kses_post()제한된 HTML을 허용할 때 사용하십시오.
플러그인이 이전에 임의의 HTML 입력을 허용했다면 안전한 하위 집합으로 마이그레이션하거나 제출된 HTML에 대한 관리자 검토를 요구하는 것을 고려하세요.
공개 후 팀 및 클라이언트를 위한 커뮤니케이션 팁
- 투명하지만 통제된 상태를 유지하세요: 영향을 받은 이해관계자에게 인지하고 있으며, 조사 중이며, 즉각적인 완화 조치를 나열합니다.
- 그들이 취해야 할 권장 조치를 제공합니다(예: 비밀번호 변경, 수정될 때까지 관리자 미리보기 링크 클릭 피하기).
- 준수 또는 보험 목적을 위한 모든 수정 단계 및 발견 사항을 기록하십시오.
새로 추가: 지금 WP‑Firewall로 사이트를 보호하세요 (무료 플랜)
지금 사이트를 보호하세요 — 무료 플랜 이용 가능
플러그인 패치를 기다리거나 분류하는 동안 즉각적인 위험을 줄이고 싶다면 WP‑Firewall의 기본(무료) 플랜에 가입하는 것을 고려하세요. 이는 저장된 XSS 및 기타 일반적인 WordPress 위험을 완화하는 데 도움이 되는 필수 런타임 보호 기능을 제공합니다:
- 가상 패칭을 제공하고 시도된 XSS 페이로드를 차단할 수 있는 웹 애플리케이션 방화벽(WAF)이 포함된 관리형 방화벽.
- 무제한 대역폭 및 지속적인 스캔.
- OWASP Top 10 위험을 목표로 하는 악성코드 스캐너 및 완화.
즉각적인 보호를 받기 위해 무료 티어로 시작한 후 자동 악성코드 제거, IP 블랙리스트/화이트리스트, 월간 보안 보고서 및 자동 가상 패칭이 필요하면 Standard 또는 Pro로 업그레이드하세요. 여기에서 가입하세요: https://my.wp-firewall.com/buy/wp-firewall-free-plan/
최종 권장 사항
- 프로덕션 사이트에서 Faces of Users를 실행하는 경우, 이를 실행 가능한 것으로 간주하십시오: 플러그인을 패치하거나 제거하고 기여자 계정을 감사하십시오.
- 취약점 공개와 공식 패치 사이의 시간을 벌기 위해 가상 패칭이 있는 WAF를 사용하세요.
- 방어적 코딩 관행을 적용하세요: 입력 시 정리하고; 출력 시 이스케이프하고; 기능 및 논스를 검증하세요.
- 사고 대응 매뉴얼을 만들고 훈련을 실시하여 팀이 신속하게 대응할 수 있도록 하세요.
저장된 XSS는 고전적이고 해결 가능한 문제입니다 — 그러나 지속적인 경계가 필요합니다. WordPress 사이트를 보호하려면 안전한 개발, 신중한 사용자 관리 및 관리형 방화벽 및 자동 스캔과 같은 런타임 보호의 조합이 필요합니다. 위의 단계 중 어떤 것을 구현하는 데 도움이 필요하면 WP‑Firewall이 대응을 준비하고, 가상 패치를 적용하며, 포괄적인 정리 및 강화 프로세스를 실행하는 데 도움을 줄 수 있습니다.
데이터베이스에서 주입된 콘텐츠를 검색하기 위한 실용적인 체크리스트나 샘플 스크립트가 필요하면, 귀하의 호스팅 환경을 알려주시면 WP‑CLI, MySQL 및 먼저 스테이징에서 테스트할 수 있는 안전한 수정 스크립트에 맞춤형 명령을 생성하겠습니다.
