PHP를 패치했다면 그다음은 이미 침입당한 흔적이 없는지 확인하는 일입니다. KISA 보호나라는 업데이트 뒤 최소 2026년 10월 20일 이후 기록 전체를 점검하라고 했습니다.
업데이트 전까지 인터넷에 노출됐던 서버라면 이상이 없어도 DB·관리자 비밀번호와 외부 서비스 연동 키를 바꾸라고 권장합니다. 흔적이 보이면 서버를 끄지 말고 외부 접속만 막은 뒤 신고합니다.
패치는 앞으로의 공격을 막을 뿐, 그 전에 들어온 것을 지우지는 않습니다. 2026년 11월 4일 KISA의 PHP2Shell 기업 보안 대응 수칙 5~8번과 보호나라 침해사고 신고 안내를 읽고 점검 순서를 정리했습니다.

1. 패치했는데 해킹 흔적도 확인해야 하나요?
네. KISA 수칙에 따르면 이번 취약점은 보안 업데이트가 나오기 전에 정보가 유출됐고, 해외 보안업체를 중심으로 공격 시도가 보고됐습니다.
공격에 성공하면 원격조종 파일(웹셸) 설치, 고객정보 유출, 홈페이지 변조, 내부망 침투 등이 가능하다고 수칙은 적었습니다. 업데이트 전에 이미 심어진 파일은 업데이트 뒤에도 남아 있을 수 있습니다.
그래서 수칙은 업데이트(2번) 다음에 로그 점검(5번)과 인증정보 교체(6번)를 따로 두었습니다. 업데이트 뒤에는 웹 서비스가 실제로 쓰는 PHP 버전이 바뀌었는지도 확인하라고 적혀 있습니다.
2. 2026년 10월 20일 이후 기록부터 봅니다
KISA 수칙은 최소 10월 20일, 곧 취약점 정보 유출일 이후의 기록 전체를 점검하라고 했습니다. 가능하면 그 이전 기록까지 확인하라는 단서도 붙였습니다.
여기서 기록은 서버가 남기는 로그를 말합니다. 웹호스팅이라면 내 계정에서 볼 수 있는 기록이 호스팅 회사마다 다르니, 어디까지 볼 수 있는지 고객센터에 먼저 묻는 것이 좋습니다.
수칙은 기록을 봐도 확신할 수 없다는 점을 분명히 적었습니다.
※ 기록상 이상이 없더라도 안전이 보장되지 않으므로, 업데이트와 인증정보 교체를 함께 진행
3. 기록에서 찾을 여섯 가지 흔적
KISA 수칙 5번이 든 주요 점검 항목은 여섯 가지입니다.
- PHP 페이지로 들어온 비정상적으로 큰 요청과 그 뒤에 반복된 서버 오류(HTTP 500)
- 원인을 알 수 없는 PHP 프로그램 재시작·비정상 종료(segfault)나 메모리 부족 오류
- 웹 서버가 명령 실행 프로그램(sh, bash 등)이나 파일 다운로드 도구를 실행한 흔적
- 웹 폴더, 업로드 폴더, 임시 폴더에 새로 생기거나 바뀐 PHP 파일(웹셸)
- 홈페이지나 결제 페이지에 몰래 추가된 외부 스크립트
- 웹 서버에서 알 수 없는 외부 주소로 새로 연결한 흔적

4. 웹셸과 몰래 붙은 스크립트 찾기
웹셸은 공격자가 서버에 심어 두고 밖에서 명령을 내리는 파일입니다. 수칙은 웹 폴더, 업로드 폴더, 임시 폴더에 새로 생기거나 바뀐 PHP 파일을 보라고 했습니다. 내가 올린 기억이 없는 파일이나 10월 20일 이후에 바뀐 파일부터 살펴보는 것도 방법입니다.
홈페이지나 결제 페이지 화면에 내가 넣지 않은 외부 스크립트가 붙었는지도 봅니다. 결제 페이지는 고객 정보가 오가는 곳이라 따로 챙깁니다.
인터넷에 도는 공격 시험 코드(PoC)를 돌려 보는 것은 피합니다. KISA 수칙 8번은 출처가 불분명한 PoC 중에 악성코드가 숨겨진 가짜가 많다며, 취약 여부는 PoC 대신 버전 확인과 기록 점검으로 판단하라고 했습니다.
5. 비밀번호와 연동 키는 바꿔 둡니다
KISA 수칙 6번은 이번 취약점이 서버 메모리에 담긴 비밀번호, 접속 인증값(토큰), 외부 서비스 연동 키(API 키) 등을 유출시킬 수 있다고 적었습니다.
업데이트 전까지 인터넷에 노출됐던 서버라면 DB 비밀번호, 외부 서비스 연동 키, 관리자 계정 비밀번호를 바꾸라고 권장합니다. 침해 흔적이 발견된 서버는 반드시 바꾸라고 했습니다.
연동 키에는 결제, 문자 발송, 지도처럼 외부 서비스에 붙일 때 받은 키가 들어갑니다. 키를 바꾸면 홈페이지 설정 파일의 값도 새 키로 바꿔야 서비스가 계속 동작합니다.
6. 흔적이 보이면 끄지 말고 외부 접속만 막기
KISA 수칙 7번은 침해사고가 나면 아래 순서로 대응하라고 했습니다. 업데이트·재시작보다 격리와 증거 확보가 먼저입니다.
- 격리: 서버를 끄거나 재시작하지 말고, 네트워크에서 외부 접속만 차단
- 신고: 보호나라(boho.or.kr) → 침해사고 신고 → 신고하기
- 증거 확보: 서버 기록, 실행 중인 프로그램 목록, 네트워크 연결 정보 보존
- 조치: 업데이트와 재시작, 웹셸 제거, 인증정보 교체
서버를 재시작하면 메모리에 남은 공격 흔적이 사라지므로, 업데이트·재시작 전에 증거를 먼저 확보하라고 수칙은 적었습니다.
보호나라 신고 안내에 따르면 정보통신서비스 제공자는 침해사고 발생을 안 때부터 24시간 이내 신고해야 하고(정보통신망법 제48조의3), 늦거나 하지 않으면 5천만원 이하 과태료 대상입니다. 해킹 상담은 국번 없이 118입니다.

이 블로그를 운영하는 AiApp에서는 직접 점검하기 어려운 분을 위해, 엠바스 외주로 기존 PHP 홈페이지의 점검과 업그레이드를 맡길 수 있습니다. 상담은 견적 페이지에서 시작합니다. 침해사고 신고는 위 순서대로 보호나라에 따로 합니다.
정리하면 PHP2Shell 패치 뒤 점검은 이렇게 합니다.
- 웹 서비스가 실제로 쓰는 PHP 버전이 바뀌었는지 확인합니다
- 최소 10월 20일 이후 기록 전체에서 여섯 가지 흔적을 찾습니다
- 웹·업로드·임시 폴더의 새 PHP 파일과 몰래 붙은 외부 스크립트를 봅니다
- 인터넷에 노출됐던 서버라면 이상이 없어도 DB·관리자 비밀번호와 연동 키를 바꿉니다
- 흔적이 보이면 끄지 말고 외부 접속만 막고, 신고하고, 증거를 남긴 뒤 조치합니다
PHP2Shell 대응 전체는 PHP2Shell 조치 방법, 확인부터 패치까지에 있습니다. 카페24를 쓴다면 카페24 php 업데이트, 확인부터 변경까지를, 아직 패치 전이라면 PHP2Shell 차단 방법, 패치 전 임시 조치를 먼저 보세요.
참고자료 (모두 2026년 11월 4일 확인)
- KISA 보호나라 「PHP 보안취약점(PHP2Shell) 관련 기업 보안 대응 수칙」(2026-10-22) — boho.or.kr 보안공지
- KISA 보호나라 「침해사고 신고 안내」 — boho.or.kr 침해사고 신고
- PHP 뉴스 「Security advisory: Critical remote code execution vulnerabilities, update now」(2026-10-21) — php.net/archive/2026.php
- AiApp 운영팀 확인(2026년 11월) — 엠바스 외주의 PHP 점검·업그레이드
#PHP취약점 #PHP2Shell #웹셸점검 #해킹점검 #홈페이지보안



