PHP2Shell 대응에서 관리형 호스팅의 보안 공백이 드러났다

PHP2Shell 취약점에 대응하는 동안 Cloudways와 Kinsta, WP Engine은 2026년 10월 21일 늦은 저녁까지 패치를 배포하고 있었다. 반면 Liquid Web 서버에서는 호스팅 업체의 배포 계획이 정해지기 전에 직접 업데이트해야 했다. 이 사례는 관리형 호스팅을 이용하는 고객이 긴급 보안 업데이트에서 무엇을 기다리고, 어디까지 직접 처리해야 하는지 보여준다.

PHP 보안 업데이트는 로그인하지 않은 공격자가 코드를 실행할 수 있는 취약점 두 건을 수정했다. 취약점은 워드프레스 자체가 사용하는 PHP에 영향을 줬기 때문에 플러그인 업데이트로 해결할 수 없었다. PHP 팀은 업데이트가 완전한 해결책이며, 임시 설정 변경은 특정 공격 경로에 대한 노출을 줄일 뿐이라고 밝혔다.

아래는 관리형·워드프레스 호스팅 업체 7곳의 공개 대응을, 확인 가능한 가장 이른 공지와 최신 패치 상태를 기준으로 정리한 내용이다. 시간은 별도 표시가 없는 한 2026년 10월 21일 UTC 기준이며, 자료는 10월 22일 확인됐다.

이 기록에서 가장 먼저 공지한 곳은 배포 전날 밤에 알린 BigScoots다. 이는 소통 측면에서 긍정적이지만, 공지 시각만으로 어느 업체가 패치를 먼저 끝냈는지는 알 수 없다. 확인 당시 전체 서버에 패치가 완료됐다는 시각을 공개한 업체는 없었다. 일부는 작업이 진행 중이라고 명시했고, 나머지는 완료 시점을 밝히지 않았다.

Cloudways 고객은 밤까지 기다려야 했다

확인한 Cloudways 서버에는 PHP 8.4.26이 설치돼 있었고, 패키지 저장소에도 같은 이전 버전만 있었다. 해당 서버에서 사용할 수 있는 수정 패키지는 없었다. 관련 설정은 업체가 관리했기 때문에 직접 교체할 권한도 없었다.

Cloudways의 오후 공지는 공식 패치의 단계적 배포를 준비하는 동안 추가 임시 보호 조치를 적용한다고 밝혔다. 22:19에도 공식 패치 배포는 진행 중이었다. 업체는 그때까지 전체 서버에 임시 완화 조치를 적용했다고 알렸다. 고객이 아무런 추가 보호 없이 기다리도록 한 것은 아니지만, 영구적인 수정 사항은 밤늦게까지 배포되고 있었다. 앞서 확인한 서버는 그 배포가 이뤄질 때까지 기다려야 했다.

호스팅 업체가 플랫폼을 통제하고 유지관리한다는 점은 고객 측 개발자가 지연된 업데이트를 직접 처리하지 못하게 하는 이유이기도 하다. 무엇이 빠졌는지 확인한 뒤에도 해당 서버에서 할 수 있는 일은 거의 없었다.

Liquid Web에서는 직접 업데이트했다

Liquid Web에서는 누가 업데이트 작업을 맡을지가 문제였다. 패키지 미러가 공식 cPanel 피드보다 늦게 갱신되고 있었다. 서버를 직접 관리해 공식 서명 패키지로 업데이트했고, 그날 오후 수정된 웹사이트용 PHP와 제어판용 PHP 빌드를 확인했다.

이후 Liquid Web은 공개 공지에서 cPanel 고객이 직접 업데이트하는 방법을 안내했다. 업체 자체의 배포 계획은 여전히 검토 중이었다. 해당 서버가 패치된 것은 고객 측에서 개입했기 때문이다.

관리형 호스팅 상품마다 업체가 맡는 범위는 다르므로 모든 상품에 똑같은 책임을 기대할 수는 없다. 그래도 긴급 보안 업데이트가 필요한 상황에서 고객이 개발자를 투입해야 한다는 사실을 뒤늦게 알게 되는 것은 바람직하지 않다. 고객 조치가 필요하다면 업체는 그 사실을 분명하고 신속하게 알려야 한다.

업체별 공지에는 진행 상황과 빈틈이 함께 있었다

Kinsta는 PHP 브랜치별 작업 상황을 공지했다. 처음에는 일부 버전의 검증된 빌드를 알렸고, 저녁 동안 대상 버전을 늘렸다. 23:25 공지에는 해당 공지에 열거된 모든 브랜치에서 검증된 패치가 배포 중이라고 적혔지만, 작업 완료를 알리지는 않았다.

WP Engine도 21:52 업데이트 시점까지 패치를 배포하고 있었다. BigScoots는 17:07에 일괄 배포를 시작하면서 몇 시간 정도 걸릴 것으로 예상했지만, 확인 당시 사고 기록에는 완료 공지가 없었다.

업데이트를 서둘러 고객 사이트를 중단시키는 것도 실패다. Kinsta가 버전별 진행 상황을 공개한 것은 검증에 시간이 걸리는 이유와 남은 작업을 고객이 알 수 있게 했다. BigScoots도 패키지를 테스트한 뒤 묶음으로 배포한다고 설명했다. 두 업체 모두 막연히 안심시키는 말보다 구체적인 정보를 제공했다.

그러나 이 작업은 고객이 호스팅 비용을 내는 이유 중 하나다. 고객에게는 현실적인 진행 상황과 명확한 완료 안내가 필요하다. 예상 시간이 지나도 후속 공지가 없으면 고객이 직접 답을 찾아다녀야 한다.

‘보호됨’이라는 공지만으로는 패치 시점을 알 수 없었다

Pressable은 샌드박스·스테이징·운영 사이트를 포함해 제공하는 모든 PHP 버전이 보호됐으며 고객이 따로 조치할 필요가 없다고 밝혔다. SiteGround는 PHP 업데이트가 나오기 전에 서버 수준의 보호 조치를 적용했다고 설명했다. 두 공지 모두 PHP 패치가 고객 서버에 언제까지 적용됐는지는 밝히지 않았다.

그렇다고 두 업체의 서버에 패치가 적용되지 않았다는 뜻은 아니다. 공개 공지만으로는 비교에 필요한 정보를 확인할 수 없다는 뜻이다. Pressable의 설명이 수정 완료까지 포함했을 수도 있지만, 그 일정을 명시하지 않았다. SiteGround 게시물은 PHP 업데이트가 공개된 뒤 확인했을 때도 업데이트를 예정된 것으로 설명하고 있었다.

고객은 호스팅 업체가 알려진 공격 경로를 차단했는지, 영구 패치 설치를 시작했는지, 작업을 끝냈는지 구분할 수 있어야 한다. PHP 내부 구조를 이해하지 못하는 사이트 운영자도 짧은 상태 공지로 이를 알 수 있다.

호스팅 평가에 보안 대응을 포함해야 한다

이번 사건은 호스팅 서비스를 비교할 때 긴급 보안 대응도 살펴봐야 한다는 점을 보여줬다. 평소 빠른 웹사이트를 제공하는 업체라도 중요한 수정 사항이 나왔을 때 고객을 기다리게 할 수 있다. 그 대기 시간도 고객이 구매한 서비스의 일부다.

Cloudways와 Kinsta는 밤늦게까지 패치를 배포하고 있었다. Liquid Web은 자체 배포 계획이 정해지지 않은 상황에서 cPanel 고객이 직접 조치할 방법을 안내했다. Pressable과 SiteGround는 보호 조치를 알렸지만 패치 일정은 분명히 하지 않았다. 모두 관리형 호스팅으로 판매되더라도 고객이 겪는 대응은 서로 달랐다.

유용한 호스팅 평가는 업체의 최근 주요 보안 사고를 살펴봐야 한다. 영구적인 수정 사항이 적용되기까지 얼마나 걸렸는지, 고객에게 진행 상황을 얼마나 명확히 알렸는지, 작업을 끝내기 위해 고객이 개발자를 따로 투입해야 했는지를 확인할 필요가 있다. 이런 기록은 홈페이지 속도 테스트의 작은 차이보다 더 중요할 수 있다.

이 기사를 쓴 알리 칼라드(Ali Khallad)는 10년 넘게 맞춤형 플러그인과 WooCommerce 솔루션을 개발해 온 워드프레스 개발자다.