PHP 취약점 2건, 워드프레스를 갱신해도 서버는 따로 고쳐야 한다

워드프레스는 왜 업데이트를 내놓지 않았나

워드프레스는 이번 결함을 고치기 위한 자체 업데이트가 필요하지도, 예정돼 있지도 않다고 공지했다. 손봐야 할 곳이 워드프레스가 아니라 사이트를 실행하는 PHP였기 때문이다. 이용자가 호스팅 업체의 조치 여부를 확인하도록 안내한 이유도 여기에 있다.

운영자가 워드프레스를 최신으로 바꿔도 PHP 보안 조치까지 끝난 것은 아니다. 화면에 보이는 프로그램과 그것을 돌리는 실행 환경의 업데이트는 서로 다른 일이다. 익숙한 관리 화면만 살피면, 정작 고쳐야 할 곳을 지나칠 수 있다.

이 구분은 이용자에게도 중요하다. 사이트가 정상적으로 열리는지와 서버에 보안 수정이 적용됐는지는 다른 질문이다. 이번 사건에서 패치 완료를 판단할 자리는 홈페이지의 겉모습보다 호스팅·서버 운영자의 적용 내역이다.

PHP 취약점 2건은 어디까지 건드리나

이번 결함에는 로그인하지 않은 공격자가 원격으로 코드를 실행할 수 있는 경로가 있었다. PHP를 아파치 서버에 모듈로 붙여 쓰는 mod_php 환경에서는 애플리케이션 코드가 실행되기 전 공격하는 실증도 나왔다. PHP 프로젝트가 위험을 가장 높게 평가한 근거다.

사이트 프로그램이 요청을 받아 처리하기도 전에 공격이 들어올 수 있다면, 그 프로그램만 새것으로 바꾸는 조치로는 부족하다. PHP 자체나 해당 환경에 맞는 보안 수정이 적용돼야 한다. 워드프레스 공지가 이용자를 호스팅 업체로 보낸 것은 책임을 피하는 설명이 아니라 고쳐야 할 위치를 짚은 안내다.

PHP 개발자들은 긴급 수정판을 배포했다. 그러나 수정판을 공개하는 일과 개별 사이트의 서버를 바꾸는 일은 이어지는 별도 작업이다. 미첼 아마도르 이뮤네파이(Immunefi) CEO가 소규모 사이트에서는 적용까지 수주가 걸릴 수 있다고 경고한 것도 이 간격이다.

PHP 결함은 왜 발견 뒤에도 오래 남았나

PHP 재단은 2024년 메모리 부족 문제의 징후를 찾았지만 당시에는 구체적인 공격 경로가 없었다고 설명했다. 고치려는 시도는 있었다. 문제는 수정안마다 기존 코드와의 호환성이 깨지거나, 서비스 거부 문제가 생기거나, 확장 모듈까지 바꿔야 하는 부담이 따라왔다는 것이다.

결함을 찾는 사람에게는 문제가 있는 위치가 답이다. 수정하는 사람에게는 그곳을 바꾸고도 다른 기능이 제대로 돌아가게 하는 일까지 답이어야 한다. 이번 수정 과정에서 부딪힌 호환성·확장 모듈 문제는 발견과 해결의 작업량이 왜 다른지 보여 준다.

합의를 거치는 의사결정과 전문 인력 부족도 작업을 멈춰 세웠다. Calif가 2026년 8월 11일 같은 원인에서 원격 코드 실행이 가능하다고 보고하면서 수정은 최우선 작업이 됐다. 공격 가능성이 구체화되자 우선순위가 달라졌지만, 그 전에 쌓인 수정의 난도가 사라진 것은 아니었다.

PHP 구버전은 어떻게 패치를 적용하나

지원이 끝난 PHP라고 수정 경로가 모두 닫힌 것은 아니다. PHP 프로젝트는 지원 종료 버전에도 최소한의 소스 수정을 제공했고, 배포판이나 장기지원 공급자가 구버전에 보안 수정을 옮겨 제공할 수 있다고 안내했다.

최신 지원판으로 바꾸는 사이트도 있고, 공급자가 기존 버전에 옮겨 넣은 수정을 적용하는 사이트도 있다. 직접 소스를 반영해야 하는 경우도 있다. 같은 결함을 고치더라도 운영 환경에 따라 해야 할 일이 달라진다. 그래서 패치 파일의 존재만으로 사이트별 완료 시점을 알 수는 없다.

2026년 10월 23일에는 특이한 세션 설정 변경과 업로드 진행 기능이 결합할 때 남는 별도 원격 코드 실행 경로도 공지됐다. 이 경로는 다음 정기 수정 대상으로 안내됐다. 긴급 수정판을 받았다는 사실과 자기 서버의 설정에 남은 경로까지 처리했다는 판단 역시 구분해야 한다.

PHP 유지보수 비용은 누가 부담하나

PHP 보안 작업은 소수의 재단 지원 개발자와 자원봉사자에게 의존하고 있다. 재단이 PHP를 사용하는 기업뿐 아니라 호스팅·클라우드 사업자와 정부에도 지속적인 후원을 요청한 배경이다. 공통으로 쓰는 기반을 유지할 인력이 부족하면, 그 위의 서비스도 영향을 받는다.

돈이 필요한 자리는 수정판을 만드는 쪽에만 있지 않다. 수정안을 검토하고 배포하는 개발 인력, 각 서버에 적용하는 운영 작업이 모두 이어져야 한다. 재단의 인력 부족과 사이트별 독립 업그레이드 의무를 함께 보면, 보안은 패치 배포로 끝나는 상품보다 계속 수행해야 하는 업무에 가깝다.

아마도르의 경고에서 오래 남을 대목도 발견 비용과 수정 비용의 격차다. AI가 결함을 더 빨리 찾아낼 것이라는 전망을 받아들이더라도, 그 속도만큼 고칠 사람과 적용할 여력이 늘어난다는 보장은 없다. 발견 목록이 길어지는 것과 안전해지는 것은 같은 성과가 아니다.

PHP 패치의 마지막 작업은 이용자 앞에 남는다

아마도르는 패치 적용이 늦는 동안 이용자에게 비밀번호 재사용을 피하고, 암호화폐 지갑을 연결할 때 주의하며, 알 수 없는 토큰 승인을 철회하라고 권고했다. 서버를 직접 고칠 수 없는 사람에게는 로그인과 지갑 연결이 위험을 만나는 접점이기 때문이다.

이 경고를 특정 국내 거래소나 지갑 서비스의 피해로 옮겨 읽어서는 안 된다. 이번 사건에서 개인의 돈에 닿는 경로는 특정 코인의 가격보다 이용하는 웹사이트의 보안 상태에 있다. 운영자의 적용 작업이 늦어지는 동안, 이용자는 그 사이트에 계정 정보와 자산 접근 권한을 맡길지를 판단해야 한다.

사이트 운영자가 워드프레스 업데이트를 마친 장면으로 돌아가 보자. 그 일이 PHP 수정까지 끝냈는지는 별도로 확인해야 한다. 이용자에게 필요한 것은 패치가 발표됐다는 소식보다 자신이 쓰는 서비스에 적용됐다는 설명이다.

운영자가 끝내지 못한 보안 작업은, 결국 이용자가 감당할 위험으로 남는다.