워드프레스 보안기술 정보 확인 2026-10-24수정 2026-10-24

워드프레스 해킹 복구 순서, 격리부터 재발 방지까지

해킹이 확인되었다면 급한 마음에 의심 파일부터 지우기 쉽지만, 순서를 지키지 않으면 증거가 사라지거나 백도어(침입 통로로 남겨둔 숨은 파일)가 남아 같은 일이 반복됩니다. 이 글은 복구를 하나의 순서로 정리합니다.

해킹 여부가 아직 불확실하다면 먼저 워드프레스 해킹 확인 글의 체크리스트를 따라가 보세요. 아래 내용은 WordPress.org의 해킹 대응 안내(2026년 10월 확인 기준)를 바탕으로 합니다.

1단계, 기록하고 백업하기

처음 이상을 발견한 시각을 시간대와 함께 적고, 최근에 설치하거나 바꾼 플러그인·테마를 메모합니다. 백업이 없다면 지금 만들고, 청소 전의 감염 상태도 한 번 더 따로 보관합니다. 나중에 침입 경로를 분석할 때 필요합니다. 가능하다면 복구 작업 동안 점검 안내 페이지를 띄우거나 접속을 제한하는 것이 안전합니다.

2단계, 접속 경로 잠그기

공격자가 이미 가진 인증 정보를 무효로 만드는 단계입니다.

보안 키(salts)는 WordPress.org가 제공하는 키 생성기로 새 값을 만들어 wp-config.php에 붙여 넣습니다. 비밀번호는 길고 서로 다르게 만들고 비밀번호 관리자를 쓰는 편이 좋습니다.

3단계, 코어 파일 교체하기

WordPress.org FAQ는 현재와 같은 버전의 워드프레스를 내려받아 SFTP로 wp-admin과 wp-includes 폴더를 직접 덮어쓰라고 안내합니다. 관리자 화면의 재설치 기능은 주입된 파일을 남길 수 있어 권하지 않습니다. 덮어쓴 뒤에는 WP-CLI가 있으면 다음 명령으로 코어 파일이 원본과 같은지 확인할 수 있습니다.

wp core verify-checksums

이 명령은 워드프레스 파일을 WordPress.org의 체크섬과 비교합니다. 자세한 활용은 워드프레스 악성코드 검사 글을 참고하세요.

4단계, 플러그인·테마·설정 파일 정리

wp-content 안의 테마와 플러그인은 출처를 확인하고 필요한 것만 최신 버전으로 새로 설치합니다. 쓰지 않는 것은 삭제합니다. 그다음 다음 파일을 직접 열어 낯선 코드를 확인합니다.

• 루트와 하위 폴더의 .htaccess
• 테마의 index.php, header.php, footer.php, functions.php
• wp-config.php

업로드 폴더 안에 PHP 파일이 있다면 내용을 확인하고 정상 파일이 아니면 제거합니다. 여기서 놓친 파일 하나가 재침입의 통로가 됩니다.

5단계, 업데이트와 재점검

정리가 끝나면 워드프레스 코어, 플러그인, 테마를 모두 최신으로 올립니다. 이후 비밀번호를 한 번 더 바꾸고, 데이터베이스 사용자 비밀번호를 바꿨다면 wp-config.php에도 같은 값을 반영합니다. 구글 서치 콘솔과 빙 웹마스터 도구에 사이트를 등록해 블랙리스트 경고가 남았는지 확인합니다. 경고가 있었다면 정리 후 검토를 요청하는 절차를 거칩니다.

재발을 줄이는 기본 설정

WordPress 문서의 Hardening 안내에서 제시하는 항목 중 핵심만 추립니다.

1. 정식 사이트(wordpress.org)에서만 워드프레스를 내려받고, 코어·플러그인·테마를 최신으로 유지합니다.
2. 관리 화면에서 코드를 직접 고치는 기능을 막으려면 wp-config.php에 다음 줄을 추가합니다.

define( 'DISALLOW_FILE_EDIT', true );

3. 쓰기 권한은 필요한 곳에만 줍니다. 문서는 폴더 755, 파일 644를 예로 들고, wp-config.php는 400 또는 440처럼 더 좁게 두라고 안내합니다.
4. 2단계 인증을 켜고(자세한 내용은 워드프레스 로그인 보안 글), 정기 백업을 해 두고 복원 테스트까지 해 봅니다.

원인을 찾지 못한 복구의 한계

복구가 끝났다고 바로 안심하기는 이릅니다. 며칠 동안은 새 관리자 계정이 생기지 않는지, 파일이 이유 없이 바뀌지 않는지, 검색 결과에 낯선 문구가 다시 나타나지 않는지 지켜보는 것이 좋습니다. 복구 후 관찰 기간에 같은 증상이 재발하면 청소하지 못한 파일이 남아 있다는 신호일 수 있습니다.

침입 경로를 모르는 채로 복구하면 같은 취약점이 그대로 남을 수 있습니다. 서버 로그와 마지막으로 바뀐 파일의 시각을 비교하면 단서를 얻을 수 있지만, 로그가 없거나 분석이 어렵다면 호스팅 업체나 전문가의 도움을 받는 것이 현실적입니다. 초기 대응 전반은 웹사이트 악성코드 감염 대처 글에서도 다룹니다.