평소 내가 다루는 기술은 AI 에이전트나 API, 업무 자동화 쪽이다. 하지만 내가 운영하는 Peter’s Stack 블로그는 WordPress로 만들었다. Docker 위에서 직접 관리하는 환경이고, 그 안에서는 PHP가 실행된다.
2026년 10월 21일 PHP에 심각한 보안 취약점 두 건이 공개됐다. 흔히 PHP2Shell이라고 부르는 사건이다. 소식을 보고 내가 먼저 한 일도 내 서버에서 어떤 PHP가 실행되고 있는지 확인하는 것이었다. 이번에는 보안 뉴스를 길게 해설하기보다, PHP가 뭔지부터 짚어보려 한다. 실제 웹사이트 운영자에게 필요한 것은 막연한 공포보다 정확한 확인 방법이기 때문이다.
PHP는 웹사이트의 어디에서 일할까?
웹브라우저에서 글 하나를 열었다고 해보자. 화면에 보이는 글은 HTML로 전달되지만, 그 HTML이 언제나 미리 완성된 파일로 존재하는 것은 아니다. 서버가 글과 메뉴 같은 데이터를 찾아 방문자에게 보여줄 결과를 만들기도 한다. PHP는 이런 서버 측 처리를 담당하는 언어다.
WordPress는 글과 사이트를 관리하는 애플리케이션이고, PHP는 WordPress의 서버 측 코드를 실행한다. 웹서버와 데이터베이스도 각각 역할이 다르다. 관리자 화면에서 글만 쓴다면 이 차이를 알 필요가 없었을지 모른다. 그러나 업데이트와 보안은 계층마다 별도로 관리해야 한다.
30년 된 언어인데 왜 아직도 쓸까?
PHP는 1995년에 등장했다. 오래된 언어라는 이유로 이미 사라졌어야 한다고 생각할 수도 있다. 하지만 개발 현장에서는 언어의 유행보다 그 기술 위에 쌓인 자산이 더 중요할 때가 많다.
WordPress를 비롯한 CMS, 다양한 테마와 플러그인, 저렴한 호스팅, 익숙한 관리 도구가 PHP와 함께 자라났다. 언어만 갈아 끼운다고 이런 생태계를 한꺼번에 대체할 수 있는 것은 아니다. 기업의 레거시 시스템도 비슷하다. 유지비와 운영 가능성, 담당자가 알고 있는 기술, 장애 대응 방법까지 합쳐서 선택이 이어진다.
그렇다고 낡은 버전을 방치해도 된다는 이야기는 아니다. PHP가 오래된 언어인지와 현재 지원되는 안전한 PHP 버전을 쓰고 있는지는 완전히 다른 질문이다.
PHP2Shell은 무엇이 다른 문제였을까?
PHP 개발팀은 10월 21일 CVE-2026-109618과 CVE-2026-109619를 수정한 보안 버전을 발표했다. 두 취약점은 PHP 내부의 예외 처리와 메모리 상태 관리에 관련된다. 공식 공지는 조건에 따라 로그인하지 않은 외부 요청만으로 서버에서 코드가 실행될 위험을 경고했다. 특히 일부 Apache mod\_php 환경에 대해서는 애플리케이션 코드가 실행되기 전 공격 가능성이 검증됐다.
여기서 중요한 구분이 있다. WordPress 관리자 계정을 보호하는 일과 PHP 실행 환경을 패치하는 일은 다르다. 2단계 인증을 켜고 플러그인을 최신으로 유지해도 PHP 자체의 결함은 그대로 남을 수 있다. WAF 같은 보완책이 있을 수 있지만, 이번 PHP 공식 공지는 업데이트를 대체할 완전한 우회책은 없다고 강조했다.
그렇다고 취약점 공개가 곧 모든 사이트가 침해됐다는 의미도 아니다. 취약한 상태였는지, 실제 노출됐는지, 침해 흔적이 있는지는 각각 따져야 한다.
내 사이트는 무엇부터 확인해야 할까?
2026년 10월 21일 공식 수정 버전은 PHP 8.2.35, 8.3.36, 8.4.27, 8.5.12다. 자신이 쓰는 PHP 계열을 확인해 해당 수정 버전 이상인지 비교하면 된다. PHP 8.1 이하는 PHP 프로젝트의 공식 보안 지원이 종료됐으며, 운영체제 배포판의 백포트가 있다면 별도 보안 공지를 확인해야 한다.
관리형 WordPress를 이용한다면 제공자가 패치를 담당하는지 문의하면 된다. 일반 호스팅이라면 관리 화면이나 WordPress 사이트 건강 정보에서 PHP 버전을 찾고 업체의 업데이트 공지를 확인한다. VPS나 Docker를 직접 운영한다면 업데이트 패키지나 이미지뿐 아니라 실제 서비스를 처리하는 PHP 프로세스의 버전이 무엇인지까지 확인한다.
마지막 단계는 사이트가 정상 동작하는지 확인하는 것이다. 업데이트를 다운로드한 것, 새 이미지를 배치한 것, 실제 서비스가 수정된 PHP로 요청을 처리하는 것은 같지 않다. 변경 전 복구 경로도 확보해야 한다. 그리고 패치가 적용됐다는 사실과 과거 침해가 없었다는 결론은 구별해야 한다.
내 블로그에서는 이렇게 처리했다
Peter’s Stack도 이번에 PHP 8.3 계열을 수정 버전인 8.3.36으로 업데이트했다. Docker 이미지를 교체하는 데서 끝내지 않고 실행 중인 컨테이너의 PHP 버전과 이미지 식별 정보, 서비스 정상 동작을 확인했다. 이는 패치 결과에 대한 확인이지, 과거 침해 가능성 전체를 조사했다는 주장은 아니다.
웹사이트를 운영한다고 PHP 개발자가 될 필요는 없다. 다만 내 사이트가 어떤 소프트웨어로 돌아가고, 누가 패치를 책임지며, 지금 실제로 어느 버전이 실행되고 있는지는 알고 있어야 한다. 이번 사건은 그 기본을 다시 확인하게 만들었다.