호스팅 업체가 PHP를 패치했다는데, 나는 무엇을 해야 할까?

WindowsMac업데이트

호스팅 업체의 패치는 서버가 내 사이트를 실행하는 데 쓰는 언어인 PHP를 업데이트합니다. PHP 개발팀은 2026년 10월 21일 PHP 8.5.12, 8.4.27, 8.3.36, 8.2.35로 그 수정을 내놓았습니다. 그 위에 내가 설치한 소프트웨어는 별개의 일입니다. 워드프레스의 보안 강화 안내는 웹 호스팅 업체가 인프라를 관리하지만, 내가 설치하기로 한 애플리케이션까지 책임지지는 않는다고 말합니다.

간단한 답변

호스팅 업체의 패치는 업체 서버의 PHP를 다룹니다. 내 계정에서는 워드프레스나 CMS, 플러그인, 테마를 업데이트하세요. cPanel에서는 도메인마다 다른 PHP 버전을 쓸 수 있으니 각 사이트가 실제로 쓰는 버전을 확인하세요. 침해 흔적이 있는지 살펴보고, 이상한 점이 있으면 비밀번호를 바꾸세요.

호스팅 업체의 PHP 패치는 무엇을 다루나요?

PHP 자체를 다룹니다. 2026년 10월 21일 PHP 권고문은 두 취약점, CVE-2026-109618과 CVE-2026-109619가 웹 요청을 처리하는 모든 PHP 설치에 영향을 주며, 인증 없이 원격으로 코드를 실행하게 할 수 있다고 말합니다. 쉽게 말해 누군가가 로그인하지 않고도 서버에서 자기 코드를 실행할 수 있다는 뜻입니다. 권고문이 꼽는 PHP-FPM, Apache의 mod_php, php-cgi, FrankenPHP, LiteSpeed는 모두 서버 소프트웨어이므로, 공유 호스팅이나 관리형 호스팅이라면 이 업데이트는 호스팅 업체가 맡습니다.

한국인터넷진흥원(KISA)도 10월 22일 보안공지에서, 호스팅 업체가 PHP를 관리한다면 해당 업체에 조치 적용 여부를 확인하고 요청하라고 안내합니다.

이 패치는 워드프레스나 테마, 플러그인을 업데이트하지 않습니다. 그것들은 각자 업데이트가 있습니다.

악용에 대해서는 2026년 10월 23일 기준으로, CISA가 10월 21일 경보(10월 23일 개정)에서 발표 시점 기준으로 이 취약점들이 실제 환경에서 성공적으로 악용된 것을 관찰하지 못했다고 밝혔습니다. KISA는 10월 22일 보안공지에서 보안 업데이트 배포 전에 취약점 정보가 유출되었고, 해외 보안업체를 중심으로 공격 시도가 보고되고 있다고 밝혔습니다. PHP 권고문은 위험이 가장 높은 Apache mod_php에 대해, 인증되지 않은 요청이 애플리케이션 코드가 실행되기도 전에 공격을 일으킬 수 있는 실제 공격 방법이 확인되었다고 말합니다.

워드프레스와 플러그인, 테마도 업데이트해야 하나요?

네. 워드프레스의 보안 강화 안내는 항상 최신 버전의 워드프레스를 유지하라고 하며, 오래된 버전은 보안 업데이트를 받지 못한다고 말합니다. 플러그인도 마찬가지이고, 쓰지 않는 플러그인은 삭제하라고 합니다. 워드프레스 업데이트 안내에 따라 먼저 백업을 만드세요.

  1. 관리자 화면에 로그인하고 알림판 > 업데이트로 갑니다.
  2. 새 워드프레스 버전이 있으면 지금 업데이트를 누릅니다.
  3. 같은 화면에서 업데이트가 있는 플러그인과 테마를 선택하고, 플러그인 업데이트 또는 테마 업데이트 버튼을 누릅니다. 각 목록 맨 위의 확인란을 선택하면 전부 선택됩니다.
  4. 플러그인 > 설치한 플러그인으로 가서 더 이상 쓰지 않는 플러그인을 삭제합니다.

워드프레스는 이제 대부분의 사이트가 소규모 릴리스와 보안 릴리스를 백그라운드에서 자동으로 적용하지만, 주요 릴리스는 여전히 지금 업데이트를 눌러야 한다고 설명합니다.

내 사이트는 실제로 어떤 PHP 버전을 쓰나요?

짐작하지 말고 확인하세요. cPanel 문서에 따르면 각 도메인은 설치된 PHP 버전 중 아무것이나 쓸 수 있으므로, 호스팅 업체가 패치한 버전과 내 사이트 하나하나가 쓰는 버전은 따로 확인할 만합니다. KISA도 업데이트 뒤 웹 서비스가 실제로 쓰는 PHP 버전이 바뀌었는지 확인하라고 권고합니다. 워드프레스와 cPanel에서 보는 곳은 PHP 버전 확인 방법에 있습니다. 사이트가 오래된 릴리스를 쓰고 있다면 워드프레스 PHP 업데이트 방법에서 바꾸는 방법을 보세요. PHP 8.1 이하는 더 이상 PHP 개발팀의 업데이트를 받지 못하므로, 그런 사이트는 호스팅 업체와 상의가 필요합니다.

침해 흔적도 점검해야 하나요?

패치 전에 공백이 있었다면 그렇습니다. KISA는 업데이트 후 적어도 10월 20일 이후의 서버 기록(로그)을 점검하라고 권고합니다. 10월 20일은 KISA가 취약점 정보가 유출된 날로 적은 날짜입니다. 또 기록에 이상이 없더라도 안전이 보장되지는 않으므로, 업데이트와 인증정보 교체를 함께 진행하라고 합니다. PHP를 새 버전으로 바꾸면 취약점은 고쳐지지만, 그 전에 무슨 일이 있었는지는 알려 주지 않습니다.

  1. 사용자 > 모든 사용자로 가서 목록 위의 관리자 링크를 누릅니다. 워드프레스의 해킹 FAQ는 새 사용자가 만들어진 것을 분명한 징후로 꼽습니다.
  2. Google Search Console의 보안 문제 보고서를 엽니다. 구글은 사이트가 해킹되었거나 방문자에게 해로울 수 있다고 판단하면 이 보고서에 발견한 문제를 표시한다고 설명합니다.
  3. 호스팅 업체에 내 계정에서 발견된 문제가 있는지 물어봅니다.

각 점검은 워드프레스 해킹 징후와 확인 방법에서 더 자세히 다룹니다.

비밀번호는 언제 바꿔야 하나요?

이상한 점이 보이면 바로 바꾸세요. 워드프레스의 해킹 FAQ는 FTP나 SFTP, 워드프레스 관리자, cPanel 등 호스팅 관리 화면, 데이터베이스까지 모든 접근 지점의 비밀번호를 나뿐 아니라 접근 권한이 있는 모든 사용자에 대해 바꾸라고 합니다. 바꿀 비밀번호와 순서, KISA의 인증정보 교체 권고는 홈페이지가 해킹되었을 때 대처법에 처음 한 시간 동안 할 일과 함께 정리했습니다.

호스팅 업체에는 무엇을 물어보면 되나요?

짧고 구체적인 질문이 가장 쓸모 있는 답을 받습니다.

  1. 지금 제 사이트들은 각각 어떤 PHP 버전을 쓰고 있고, 8.5.12, 8.4.27, 8.3.36, 8.2.35 중 하나 이상인가요?
  2. 업데이트 뒤 PHP-FPM 같은 PHP 실행 서비스를 모두 재시작했나요? KISA는 재시작하지 않으면 메모리에 남은 이전 버전이 계속 동작해 여전히 취약하다고 안내합니다.
  3. 제 도메인 중 cPanel에서 Inherited로 설정된 것이 있다면 서버의 기본 버전은 무엇인가요?
  4. PHP 8.1 이하를 쓰는 사이트가 있다면 백포트 수정을 적용했나요? PHP 개발팀은 일부 업체가 이를 제공한다고 말합니다.
  5. PHP 개발팀이 10월 23일 정보성 권고에서 다음 정기 버그 수정 릴리스까지 권한 session.upload_progress.enabled=0 설정을 적용했나요?
  6. 제 계정이나 함께 쓰는 서버에서 침해를 가리키는 흔적을 발견했나요? 워드프레스 FAQ는 공유 호스팅에서 해킹이 한 사이트 이상에 영향을 줄 수 있다고 말합니다.
  7. 제 사이트의 백업은 어떤 것이 있나요? 워드프레스는 호스팅 업체의 백업 정책을 물어보라고 권합니다.

자주 묻는 질문

내 호스팅 업체도 PHP2Shell의 영향을 받았나요?

웹사이트를 실행하는 데 PHP를 쓴다면 업데이트하기 전까지는 영향 범위에 있었습니다. PHP 권고문은 웹 요청을 처리하는 모든 PHP 설치가 위험하다고 하고, CISA는 PHP가 다른 소프트웨어의 구성 요소인 경우가 많다고 설명합니다. 취약점 자체는 PHP2Shell 해설에서 다룹니다.

호스팅 업체가 PHP를 패치했으면 이제 내 사이트는 안전한가요?

두 PHP 취약점은 패치된 릴리스에서 고쳐졌습니다. 다만 워드프레스의 보안 강화 안내는 공유 서버에서는 같은 서버의 다른 사이트가 뚫리면 내 사이트도 뚫릴 수 있다고 말합니다. 내 업데이트와 버전 확인, 침해 점검은 여전히 필요합니다.

웹 방화벽이 패치와 같은 역할을 하나요?

아닙니다. CISA는 패치할 때까지 웹 방화벽이 어느 정도 보호를 제공할 수 있다고 말합니다. PHP 권고문은 업데이트만이 완전한 해결책이고 임시 완화책은 설치를 안전하게 만들지 않는다고 합니다. 자세한 내용은 PHP2Shell 점검 방법에 있습니다.

10월 23일 PHP 권고는 무엇이었나요?

별도의, 일어나기 어려운 원격 코드 실행 경로인 CVE-2026-115560에 관한 것입니다. PHP 개발팀은 설정과 애플리케이션 코드가 흔치 않은 조합일 때만 생기는 문제라며, 다음 정기 버그 수정 릴리스까지 session.upload_progress.enabled를 0으로 설정하라고 권했습니다. 이 설정은 서버에서 하는 것이므로 호스팅 업체가 적용합니다.

호스팅 업체가 패치할 때까지 사이트를 내려야 하나요?

KISA는 즉시 업데이트도 임시 조치도 어렵다면 업데이트 전까지 외부 접속 차단이나 서비스 일시 중단을 검토하라고 권고합니다. CISA는 바로 업데이트할 수 없거나 PHP 8.1 이하를 쓰는 시스템을 오프라인으로 전환하라고 합니다. 사이트가 수정 릴리스를 쓰는 것이 확인되면 이 조언은 더 이상 해당되지 않습니다.

출처