PHP2Shell, 우리 홈페이지는 괜찮을까?
상황별로 정리한 담당자 대응 가이드
💡 핵심 3줄 요약
1. 2026년 10월 21일 PHP가 로그인 없이 서버를 장악할 수 있는 치명적 취약점 PHP2Shell을 긴급 패치했고, 정부는 사이버위기 경보를 '주의'로 올렸습니다.
2. 문제는 홈페이지 코드가 아닌 PHP 자체에 있어, 워드프레스나 플러그인을 최신으로 유지해도 PHP를 업데이트하지 않으면 여전히 위험합니다.
3. 업데이트 후 웹 서비스 재시작, 10월 20일 이후 로그 점검, 관리자·DB 비밀번호 교체까지 마쳐야 대응이 끝납니다.
"뉴스에 PHP 취약점 얘기가 계속 나오던데, 우리 홈페이지는 괜찮은 건가요?"
지난주부터 홈페이지 담당자들 사이에서 가장 많이 나온 질문일 겁니다. 10월 21일 PHP 개발팀이 치명적 취약점 두 건(CVE-2026-109618, CVE-2026-109619)을 고친 긴급 업데이트를 내놓았고, 보안업계는 이를 'PHP2Shell'이라고 부르기 시작했습니다. 두 건 모두 CVSS 4.0 기준 9.2점, 최고 수준인 치명적(Critical) 등급입니다.
국내에서도 대응이 이어졌습니다. KISA가 패치 당일 보호나라에 업데이트 권고문을 올렸고, 다음 날에는 과학기술정보통신부가 민간 분야 사이버위기 경보를 '관심'에서 '주의'로 높였습니다. 개인정보보호위원회도 개인정보를 다루는 기관과 기업에 긴급 보호조치를 당부했습니다.
그런데 막상 담당자 입장에서는 무엇부터 해야 할지 막막합니다. 서버를 직접 만져본 적도 없고, 홈페이지를 누가 어떻게 만들었는지조차 기억나지 않는 경우도 많으니까요. 그래서 이 글은 기술적인 점검 절차보다 우리 홈페이지가 지금 어떤 상황인지에 따라 무엇을 하면 되는지를 중심으로 정리했습니다.
💡 PHP2Shell, 기존 해킹 이슈와 무엇이 다를까?
PHP는 전 세계 웹사이트의 약 70%가 사용하는 언어입니다. 워드프레스, 그누보드, 라라벨처럼 이름은 들어봤을 법한 솔루션들이 모두 PHP 위에서 돌아갑니다.
지금까지 홈페이지 해킹 소식은 대개 "특정 게시판 프로그램의 취약점", "특정 플러그인의 보안 허점"처럼 범위가 좁았습니다. 해당 프로그램을 안 쓰면 상관없는 이야기였죠. PHP2Shell은 다릅니다. 홈페이지를 움직이는 엔진인 PHP 자체에 결함이 있어서, 그 위에 무엇을 얹었든 영향을 받습니다. 취약점을 발견한 연구진은 기능이라고는 글자 한 줄 출력하는 것뿐인 페이지도 취약한 PHP에서 돌아가면 위험할 수 있다고 설명했습니다.
한눈에 보기 | 내용 |
|---|---|
무엇이 문제인가 | PHP가 메모리를 처리하는 과정의 결함 2건 |
공격 조건 | 로그인 불필요, 인터넷으로 요청만 보내면 됨 |
최악의 경우 | 서버 장악, 웹셸 설치, 홈페이지 변조, 고객정보 유출 |
조용한 피해 | 서버를 장악하지 않고 메모리 속 비밀번호·API 키만 빼가는 것도 가능 |
영향 버전 | PHP 8.2.35, 8.3.36, 8.4.27, 8.5.12 미만 (연구진 분석상 PHP 5.4부터 해당) |
해결 방법 | 위 버전 이상으로 업데이트 후 웹 서비스 재시작 |
여기서 특히 눈여겨볼 건 '조용한 피해'입니다. 홈페이지가 변조되면 누구나 알아채지만, 메모리에 있던 관리자 비밀번호나 DB 접속 정보만 빠져나가면 겉으로는 아무 일도 없어 보입니다. 업데이트를 마친 뒤에도 비밀번호를 바꿔야 하는 이유가 여기에 있습니다.
참고로 이번 취약점은 Wiz Research, OpenAI, Calif 연구진이 AI를 활용해 찾아낸 것으로 알려져 있습니다. 워드프레스, 드루팔, 줌라에서 로그인 없이 서버 명령을 실행하는 시연도 공개됐습니다.
💡 먼저, 우리 홈페이지가 대상인지부터
✅ 이런 솔루션을 쓰고 있다면 대상입니다
워드프레스, 드루팔, 줌라 같은 설치형 홈페이지 솔루션
그누보드처럼 국내 게시판·커뮤니티 사이트에 많이 쓰이는 솔루션
라라벨, 심포니 등 PHP 프레임워크로 개발한 맞춤형 홈페이지
무들(Moodle) 같은 교육용 플랫폼
어떤 솔루션인지 모르겠다면 제작 업체나 호스팅 업체에 "우리 사이트 PHP 쓰나요, 버전이 몇인가요?" 한 줄만 물어보면 됩니다.
✅ "플러그인은 매일 업데이트하는데요?"
워드프레스를 쓰는 곳에서 자주 나오는 반응입니다. 하지만 워드프레스나 플러그인 업데이트는 PHP 위에 얹힌 프로그램을 바꾸는 것이고, 서버의 PHP는 그대로 남습니다. 집 안 가구를 새것으로 바꿔도 건물 기초에 금이 가 있으면 소용없는 것과 비슷합니다.
✅ 메인 홈페이지만 보고 끝내지 마세요
오히려 위험한 건 아무도 신경 쓰지 않는 사이트입니다. 몇 년 전 학술대회용으로 만든 사이트, 이벤트가 끝났는데 닫지 않은 페이지, 개발할 때 열어둔 테스트 서버 같은 곳이죠. KISA도 자산 목록만 믿지 말고 실제로 돌아가는 서버를 기준으로 확인하라고 당부했습니다. 우리 기관 이름으로 운영되는 사이트를 한 번 전부 적어보는 것부터 시작하는 게 좋습니다.
💡 상황별로 해야 할 일이 다릅니다
같은 취약점이라도 홈페이지를 누가 관리하고 있느냐에 따라 할 일이 달라집니다. 우리 상황이 어디에 가까운지 먼저 확인해 보세요.
상황 1. 유지보수 업체나 호스팅사가 관리하고 있다면
가장 다행인 경우입니다. 다만 "알아서 해주겠지" 하고 기다리기보다는 먼저 연락해서 조치 여부를 확인하는 게 좋습니다. 업체가 바쁜 시기라 고객사 문의 순서대로 처리하는 경우도 있으니까요.
확인할 때는 "업데이트했다"는 답에서 멈추지 말아야 합니다. PHP는 업데이트를 설치해도 웹 서비스를 재시작하지 않으면 메모리에 올라가 있던 구버전이 계속 돌아갑니다. 또 서버에 PHP가 여러 개 깔려 있거나, 리눅스 배포판 패키지처럼 패치를 적용해도 버전 숫자가 그대로인 경우가 있어서 실제로 홈페이지가 쓰는 PHP가 바뀌었는지까지 확인해야 합니다. 아래에 정리한 질문 목록을 그대로 보내셔도 됩니다.
상황 2. 외주로 만들고 지금은 관리하는 곳이 없다면
생각보다 많은 경우입니다. 제작 업체와 계약이 끝났거나, 업체가 사라졌거나, 담당 개발자가 바뀌어서 서버 구조를 아는 사람이 없는 상황이죠.
이럴 때 먼저 챙길 건 서버 접근 정보입니다. 호스팅 계정, 서버 관리자 계정, 도메인 관리 계정이 누구 명의로 되어 있는지 확인해 두세요. 이게 있어야 다른 업체에 맡기든 호스팅사에 요청하든 조치를 시작할 수 있습니다.
당장 업데이트할 사람이 없다면 임시로 노출을 줄이는 방법도 있습니다. 웹 방화벽이나 웹 서버에서 지나치게 큰 요청을 막고, 파일 업로드가 필요 없는 사이트라면 업로드 요청을 차단하는 식입니다. PHP 공식 안내에도 임시 설정이 나와 있지만, 일부 설정은 서버 안정성에 영향을 줄 수 있어 서버 구성을 아는 사람이 검토한 뒤 적용해야 합니다. 그리고 PHP 개발팀과 KISA 모두 임시 조치로는 공격을 완전히 막을 수 없다고 분명히 했습니다.
더 이상 쓰지 않는 사이트라면 이번 기회에 닫는 것도 방법입니다. 관리하지 않을 사이트를 열어두는 것 자체가 위험이기 때문입니다.
상황 3. PHP 8.1 이하 구버전을 쓰고 있다면
가장 난감한 경우입니다. PHP 8.1 이하는 공식 보안 업데이트가 아예 나오지 않습니다. PHP 8.2도 2026년 12월 31일에 지원이 끝나기 때문에 KISA는 8.3 이상으로 옮길 것을 권고했습니다.
문제는 오래된 홈페이지일수록 PHP 버전만 올렸다가 사이트가 깨질 수 있다는 점입니다. 몇 년 전 문법으로 짠 코드가 새 버전에서 동작하지 않는 경우가 있기 때문이죠. 그래서 구버전 사이트는 단순 업데이트가 아니라 코드 점검이나 구조 개선, 경우에 따라서는 리뉴얼까지 함께 검토해야 할 수 있습니다. 전환에 시간이 걸린다면 그동안은 리눅스 배포판이나 장기 지원 업체가 제공하는 보안 패치로 버티면서 일정을 세우는 게 현실적입니다.
공통 상황. 회원 DB나 결제 기능이 있는 사이트라면
학회·협회 회원 관리, 쇼핑몰, 예약 시스템처럼 개인정보를 DB에 보관하는 사이트는 한 가지를 더 챙겨야 합니다. 앞서 말한 '조용한 피해' 때문입니다. KISA는 로그에서 이상이 발견되지 않더라도 안전하다고 단정할 수 없다며, 업데이트와 함께 인증정보를 교체하라고 권고했습니다. 관리자 계정 비밀번호, DB 접속 비밀번호, 결제·문자 발송 등 외부 서비스 연동 키(API 키)는 바꿔두는 게 좋습니다. 개인정보보호위원회가 이번 사안에 별도로 주의를 당부한 것도 DB에 저장된 개인정보까지 유출될 수 있어서입니다.
💡 제작사·호스팅사에 이렇게 물어보세요
서버를 직접 다루지 않는 담당자라면 결국 업체에 확인을 요청하게 됩니다. 이때 "PHP 취약점 괜찮나요?"라고만 물으면 "네, 괜찮습니다"라는 답이 돌아오기 쉽습니다. 아래 질문을 그대로 복사해서 보내면 확인해야 할 부분을 빠짐없이 짚을 수 있습니다.
[PHP2Shell 조치 확인 요청]
1. 운영 중인 사이트별 PHP 버전을 알려주세요. (테스트·이벤트 사이트 포함)
2. PHP를 8.2.35, 8.3.36, 8.4.27, 8.5.12 이상으로 업데이트했나요? 배포판 패키지라면 CVE-2026-109618, 109619 반영 여부를 확인해 주세요.
3. 업데이트 후 웹 서비스(PHP-FPM, 아파치 등)를 재시작했고, 홈페이지가 실제로 쓰는 PHP 버전이 바뀐 것까지 확인했나요?
4. 10월 20일 이후 서버 로그에서 이상 요청, 비정상 종료, 웹셸 등 침해 흔적을 점검했나요?
5. DB 비밀번호와 API 키 등 서버 인증정보를 교체했나요? 아직이라면 일정을 알려주세요.
6. PHP 8.1 이하라면 버전 전환 계획과 그 전까지의 임시 조치를 안내해 주세요.
담당자가 직접 해볼 수 있는 것도 있습니다. 홈페이지에 못 보던 문구나 링크가 생기지 않았는지, 관리자 페이지에 모르는 계정이 추가되지 않았는지, 결제 페이지가 평소와 다르게 동작하지 않는지 정도는 바로 확인할 수 있습니다.
💡 혹시 이상한 흔적이 보인다면
이상한 파일이나 접속 기록을 발견하면 일단 서버부터 껐다 켜고 싶어지는데, 이건 피해야 합니다. 재시작하는 순간 메모리에 남아 있던 공격 흔적이 사라져 원인을 추적하기 어려워집니다. 서버는 그대로 두고 외부 접속만 차단한 뒤, 보호나라(boho.or.kr) 침해사고 신고 메뉴나 118 상담센터로 신고하세요. 로그와 실행 중인 프로그램 정보를 보존한 다음에 업데이트, 웹셸 제거, 인증정보 교체를 진행하는 순서입니다.
추가로, 인터넷에 'PHP2Shell 공격 코드'라며 돌아다니는 파일 중 상당수가 악성코드를 숨긴 가짜라고 KISA가 경고했습니다. 우리 서버가 취약한지 궁금해도 이런 파일을 직접 실행해 보는 건 절대 피해야 합니다.
💡 그래서 우리 홈페이지는 누가 관리하고 있나요?
PHP2Shell 대응 과정에서 많은 담당자가 비슷한 벽에 부딪혔을 겁니다. 연락할 업체가 없거나, 서버 계정을 누가 갖고 있는지 모르거나, PHP 버전이 오래된 상황 등, 취약점 자체보다 이런 관리 공백이 더 큰 위험일 수 있습니다.
그리고 이번이 마지막도 아닙니다. PHP 8.2 지원이 올해 말 끝나고, 패치를 마친 뒤에도 메모리·요청 크기 설정을 다시 조정하는 등 후속 작업이 남아 있습니다. 다음 취약점이 나왔을 때 하루 만에 대응할 수 있느냐는 결국 평소에 누가 홈페이지를 지켜보고 있느냐에 달려 있습니다.
홈페이지코리아는 27년 동안 공공기관, 학회·협회, 대학, 기업 등 1,100여 곳의 홈페이지를 만들고 운영해 왔습니다. 라라벨을 비롯한 PHP 기반 개발 경험이 많아, 이번처럼 PHP 런타임 단의 이슈가 생겼을 때도 서버 구조를 이해한 상태에서 대응할 수 있습니다. 다른 업체가 만든 홈페이지도 구조와 개발 환경을 검토한 뒤 유지보수를 맡고 있으며, 유지보수 요청은 영업일 기준 24시간 안에 1차 확인과 처리를 진행합니다.
지금 우리 홈페이지를 맡아줄 곳이 없다면, 유지보수 상담을 통해 현재 상태와 필요한 관리 범위부터 함께 확인해 보세요.
💡 자주 묻는 질문 (FAQ)
Q1. 워드프레스와 플러그인을 최신으로 유지하고 있으면 안전한가요?
: 이번 취약점에서는 아닙니다. PHP2Shell은 워드프레스가 아닌 그 아래의 PHP 자체 결함이라, 서버의 PHP를 해결 버전으로 따로 업데이트하고 웹 서비스를 재시작해야 합니다.
Q2. 호스팅을 쓰고 있으면 호스팅사가 알아서 해주나요?
: 호스팅 형태에 따라 다릅니다. 웹 호스팅은 호스팅사가 PHP를 관리하는 경우가 많지만, 서버 호스팅이나 클라우드 서버는 이용자가 직접 관리해야 하는 경우가 대부분입니다. 어느 쪽이든 호스팅사에 조치 여부를 직접 확인하는 것이 가장 확실합니다.
Q3. PHP 업데이트를 마쳤는데 비밀번호까지 바꿔야 하나요?
: 패치 전까지 인터넷에 열려 있던 서버라면 바꾸는 것을 권장합니다. 이 취약점은 흔적 없이 메모리 속 비밀번호나 API 키를 빼갈 수 있어서, 로그에 이상이 없어도 유출되지 않았다고 확신하기 어렵습니다.
Q4. PHP 버전을 올리면 홈페이지가 깨지지 않나요?
: 오래된 홈페이지라면 그럴 수 있습니다. 예전 문법으로 작성된 코드가 새 버전에서 동작하지 않는 경우가 있어, 버전 전환 전에 코드 호환성을 점검하는 것이 좋습니다. 같은 8.x 버전 안에서 보안 업데이트만 적용하는 경우는 영향이 상대적으로 적습니다.
Q5. 다른 업체가 만든 홈페이지도 유지보수를 맡길 수 있나요?
: 가능합니다. 홈페이지코리아는 타 업체에서 제작한 홈페이지도 구조와 개발 환경을 검토한 뒤 월 단위 유지보수 계약으로 관리합니다. 기존 소스 구조에 따라 추가 작업이 필요한 부분은 초기 검토 단계에서 함께 안내드립니다.
[콘텐츠 출처]
PHP, Security advisory: Critical remote code execution vulnerabilities (2026.10.21)
php-src 보안 권고문, RCE via OOM corruption (CVE-2026-109618)
php-src 보안 권고문, RCE via stale global state (CVE-2026-109619)
PHP2Shell 공식 사이트 (Wiz Research × OpenAI × Calif)
PHP Foundation, Today's PHP security release (2026.10.21)
KISA 보호나라, PHP 제품 보안 업데이트 권고 (2026.10.21)
KISA 보호나라, PHP 보안취약점(PHP2Shell) 관련 기업 보안 대응 수칙 (2026.10.22)
대한민국 정책브리핑, PHP 보안 취약점 관련 긴급 보안 업데이트 및 기술적 조치 당부 (2026.10.22)
