[업데이트] PHP 치명적 취약점 실제 공격 확인…웹사이트 운영자가 지금 할 일

업데이트: 지난주 PHP 보안패치가 나온 뒤 상황이 더 심각해졌습니다. 미국 사이버보안·인프라보안국(CISA)은 2026년 10월 26일 PHP의 치명적 취약점 두 개가 실제 공격에 악용되고 있음을 확인해 알려진 악용 취약점 목록에 올렸습니다. 처음 공개됐을 때는 공격 코드 작성이 어렵다는 평가도 있었지만, 이제는 “가능성”이 아니라 인터넷 현장에서 공격이 확인된 단계입니다. WordPress를 비롯해 PHP 기반 웹사이트를 운영하는 분은 호스팅 회사의 패치 상태를 바로 확인해야 합니다.

무엇이 새로 달라졌나

취약점은 이른바 PHP2Shell로 불리며, 특정 조건의 PHP 서버에 인터넷을 통해 명령을 보내 비밀번호 없이도 시스템에 침입할 수 있게 합니다. 패치는 이미 공개됐지만 패치를 적용하지 않은 서버가 남아 있고, CISA는 실제 악용 증거를 확인했습니다. 미국 연방 민간기관에는 매우 짧은 기한 안에 수정하도록 요구했습니다. 일반 개인이 웹사이트를 보기만 했다고 곧바로 감염된다는 뜻은 아니며, 주된 위험 대상은 취약한 PHP 서버와 그 서버에 저장된 자료입니다.

지난 보안경보와의 차이는 명확합니다. 당시에는 취약점과 패치가 있다는 사실을 알리는 단계였다면, 이번에는 공격자가 실제로 사용하고 있다는 공식 확인이 더해졌습니다. 따라서 “다음 정기 점검 때 하겠다”가 아니라 호스팅 업체나 관리자가 즉시 버전과 침해 흔적을 확인해야 합니다. 업데이트 제목을 붙인 이유도 같은 사건을 반복 보도하는 것이 아니라 위험 수준이 바뀐 새 진전을 설명하기 위해서입니다.

WordPress 운영자가 확인할 순서

첫째, WordPress 관리자 화면의 도구 또는 사이트 건강에서 서버의 PHP 버전을 확인하되, 정확한 패치 빌드는 호스팅 관리 화면이나 고객지원에 문의하십시오. “PHP 8.x”처럼 큰 버전만 보는 것으로는 충분하지 않을 수 있습니다. 둘째, 호스팅 회사에 PHP2Shell 관련 보안패치가 적용됐는지, 적용 시각이 언제인지 서면 답변을 요청하십시오. 공유호스팅 사용자는 서버 자체를 직접 업데이트하려 하지 말고 제공업체의 안내를 따라야 합니다.

셋째, WordPress 코어·테마·플러그인을 최신 안정 버전으로 올리고 사용하지 않는 항목은 삭제하십시오. PHP 자체 취약점은 플러그인 업데이트만으로 해결되지 않지만, 여러 약점이 연결되는 경로를 줄일 수 있습니다. 넷째, 최근 생성된 관리자 계정, 알 수 없는 파일 변경, 갑작스러운 트래픽 증가, 광고 페이지로의 이동, 보안 플러그인의 경고를 확인하십시오. 이상이 있으면 먼저 백업을 보존하고 전문 관리자나 호스팅 보안팀에 분석을 요청해야 합니다.

백업과 비밀번호 변경도 순서가 있다

깨끗한 백업이 있는지 확인하고, 데이터베이스와 업로드 파일뿐 아니라 복구 방법도 시험하십시오. 이미 침해가 의심되면 단순히 비밀번호만 바꾸고 끝내지 마십시오. 공격자가 새 관리자나 예약 작업, 숨은 파일을 남겼다면 다시 들어올 수 있습니다. 서버를 격리하고 로그와 파일을 조사한 뒤, 깨끗한 환경에서 복원하고 WordPress·호스팅·데이터베이스·SFTP 계정의 비밀번호와 보안키를 교체하는 순서가 필요합니다.

웹사이트 방문자는 운영자가 아니면 PHP를 직접 업데이트할 수 없습니다. 자주 이용하는 사이트가 갑자기 다른 주소로 이동하거나 로그인·카드정보를 다시 요구하면 입력을 멈추고 공식 연락처로 확인하십시오. 브라우저와 기기를 최신 상태로 유지하고, 같은 비밀번호를 여러 사이트에 재사용하지 않는 기본 원칙도 피해 확산을 줄입니다.

관리 경험이 적다면 혼자 해결하지 마세요

cPanel이나 호스팅 화면에서 PHP 버전을 바꾸는 일은 간단해 보여도 오래된 테마·플러그인이 새 버전과 충돌할 수 있습니다. 그래서 변경 전 전체 백업과 복구 지점을 만들고, 가능하면 스테이징 사이트에서 시험한 뒤 실제 사이트에 적용해야 합니다. 그러나 실제 공격이 진행 중인 긴급 상황에서는 호환성 걱정 때문에 패치를 무기한 미루면 안 됩니다. 호스팅 회사에 안전한 수정 버전과 자동 적용 계획을 물어 우선 위험을 차단하십시오.

보안 플러그인이 “문제없음”이라고 표시해도 서버 운영체제와 PHP 엔진의 취약점까지 모두 검사한다는 뜻은 아닙니다. 웹방화벽도 패치를 대신하지 않습니다. 방화벽은 알려진 공격 패턴을 막는 임시 방어가 될 수 있지만 공격 방식이 바뀌면 통과할 수 있습니다. 패치, 최소 권한, 다중 인증, 로그 점검과 외부 백업을 겹쳐 사용하는 이유가 여기에 있습니다.

고객 이름·이메일·주문정보를 보관하는 사이트라면 침해 사실이 확인된 뒤 통지 의무가 생길 수 있습니다. 로그를 성급히 삭제하거나 사이트만 초기화하면 조사에 필요한 증거를 잃을 수 있으므로 보안 전문가와 법률·보험 담당자의 절차를 따르십시오. 관리 대행업체에 맡겼더라도 업데이트 책임과 사고 통보 범위가 계약서에 어떻게 적혀 있는지 확인해야 합니다. 운영자가 아닌 일반 독자는 사이트 이상을 발견하면 화면을 캡처하고 공식 연락처로 알려 주되, 취약점을 직접 시험하지 마십시오.

관련 글과 출처

이번 글의 이전 단계는 PHP·Node.js·LiteLLM 보안경보 글에서 확인할 수 있습니다. 인증서 자동 차단 사례는 Apple eMudhra 대응 글, 대화형 서비스의 피싱 방지는 Microsoft Teams 피싱 탐지 글도 참고하십시오.

출처: TechCrunch 보도(2026년 10월 27일), CISA Known Exploited Vulnerabilities Catalog, PHP 공식 지원 버전 안내

컴친 한줄 정리: PHP2Shell은 이제 실제 공격이 확인됐으므로 웹사이트 운영자는 호스팅 업체에 정확한 패치 적용 여부를 즉시 확인하고, 이상 징후가 있으면 전문 대응을 요청하세요.