PHP 보안 취약점: 내 WordPress 사이트도 영향을 받을까?

지난 이틀 동안 'PHP'라는 단어가 뉴스를 뒤덮었습니다. 네덜란드에서는 시민들이 공공 서비스에 로그인하는 DigiD가 멈췄고, 핀란드에서는 일부 정부 사이트가 예방 차원에서 중단됐습니다. 미국에서는 FBI와 NSA가 패치를 적용할 수 없다면 서버를 오프라인으로 전환하라고 권고했습니다. 튀르키예에서는 대통령실 사이버보안청이 전국 단위 점검에 나섰습니다.

이 글에서는 기술적인 내용에 너무 깊이 들어가지 않고 무슨 일이 있었는지 설명합니다. 그다음 투어 사업자가 자신의 사이트가 영향을 받았는지 확인하는 방법, 오늘 해야 할 일, 다음에 더 잘 대비하는 방법을 차례로 살펴봅니다.

먼저 기본부터: PHP란?

PHP는 많은 웹사이트의 뒤편에서 동작하는 프로그래밍 언어입니다. 방문자가 사이트를 열 때 페이지를 만들고, 문의 양식을 이메일로 바꾸고, 예약을 데이터베이스에 저장하는 코드는 PHP로 작성된 경우가 매우 많습니다.

이름을 들어 본 적이 없더라도 어딘가에서 사용하고 있을 가능성이 큽니다. WordPress, WooCommerce, Joomla, Drupal과 많은 예약 플러그인이 PHP로 동작합니다. FBI에 따르면 전 세계 웹사이트의 약 70%가 PHP를 사용합니다.

무슨 일이 있었나

2026년 10월 20~21일, PHP 팀은 두 가지 치명적인 보안 취약점에 대한 긴급 업데이트를 발표했습니다. 각각 CVE-2026-109618과 CVE-2026-109619로 등록됐으며, 함께 'PHP2Shell'이라고 불립니다. 두 취약점 모두 심각도 점수 10점 만점에 9.2점을 받았습니다.

심각한 이유는 이렇습니다. 특정 조건에서 공격자가 사용자 이름이나 비밀번호 없이 인터넷을 통해 서버에서 원하는 코드를 실행할 수 있습니다. 보안 분야에서는 이를 원격 코드 실행(RCE)이라고 합니다. 쉽게 말해 열쇠 없이도 현관문을 열고 들어올 수 있는 상태입니다.

Qualys에 따르면 하나는 서버 메모리가 부족할 때 데이터가 반쯤 처리된 상태로 남으면서, 다른 하나는 오류가 난 뒤 다음 방문자의 요청이 이미 해제된 메모리를 다시 읽으면서 발생합니다. 연구자들은 비밀번호, 세션 정보, API 키 같은 데이터가 서버 메모리에서 유출될 수 있다는 점도 보여 주었습니다.

아나돌루 통신은 이 취약점을 8월에 보안 기업 Calif가 AI의 도움을 받아 발견했다고 전했습니다. 수정 작업은 약 두 달 동안 비공개로 준비됐지만, 패치 공개 하루 전에 언론에 소식이 새어 나갔습니다.

왜 이렇게 큰 문제인가

• 규모가 매우 큽니다: Palo Alto Networks는 인터넷에 노출된 잠재적 취약 시스템을 2,260만 개 이상 확인했습니다.
• 오래된 버전이 많습니다: Qualys 데이터에 따르면 버전이 확인된 PHP 설치의 71%가 지원이 끝나 정기 패치를 받지 못하는 버전입니다.
• 공격이 이미 시작됐습니다: Cloudflare는 이 취약점을 노린 공격 트래픽을 보고했고, 악용에 쓸 수 있는 코드도 이미 돌고 있습니다.
• 패치 속도가 느립니다: 공개 후 첫 12시간 동안 Qualys가 파악한 1억 6,700만 개 설치 중 업데이트된 것은 약 19만 9,000개뿐이었습니다.

그래서 각국 정부가 사이트를 멈춘 것입니다. 시스템에 패치가 적용되기 전까지는 공격자가 들어올 수 있는 문을 닫아 두는 것이 가장 안전합니다. 튀르키예에서는 사이버보안청이 공공기관에 긴급 통지를 보내고 민간 기업에도 PHP 환경을 점검하라고 요청했습니다. 국가 행정 포털 e-Devlet에서는 서비스에 영향을 주는 문제가 발견되지 않았다고 밝혔습니다.

투어 사업자에게는 어떤 영향이 있을까

공격자가 침입한 뒤 무엇을 할 수 있는지는 사이트에 무엇이 저장돼 있는지에 달려 있습니다. 가장 가능성이 높은 경우는 다음과 같습니다.

• 고객 데이터 유출: 예약 양식의 이름, 전화번호, 이메일, 여권 정보 등. 사업장과 고객의 위치에 따라 개인정보보호법이나 GDPR 등에 따라 신고 의무가 생길 수 있습니다.
• 비밀번호와 키 탈취: 데이터베이스 비밀번호, 결제 서비스·채널 매니저·이메일 서비스의 API 키.
• 사이트에 악성 콘텐츠 삽입: 숨겨진 스팸 페이지나 방문자를 다른 곳으로 보내는 코드. Google이 이를 감지하면 사이트가 경고와 함께 표시되고, 몇 달간 쌓은 SEO 성과가 훼손될 수 있습니다.
• 서버 악용: 암호화폐 채굴, 스팸 발송, 다른 사이트 공격 등.
• 매출 손실: 예방 차원에서 사이트를 내려야 하면 성수기에도 예약을 받을 수 없습니다.

내 사이트도 영향을 받을까? 먼저 버전을 확인하세요

첫 단계는 사이트가 PHP로 동작하는지, 어떤 버전인지 확인하는 것입니다. WordPress라면 관리자 화면의 도구 → 사이트 건강 → 정보 → 서버에서 PHP 버전을 볼 수 있습니다. 호스팅 관리 패널(cPanel, Plesk 등)에서도 보통 'PHP 버전' 항목에 표시됩니다.

취약점이 수정된 버전은 다음과 같습니다.

• PHP 8.5: 8.5.12 이상
• PHP 8.4: 8.4.27 이상
• PHP 8.3: 8.3.36 이상
• PHP 8.2: 8.2.35 이상
• PHP 8.1 이하: 정기적인 공식 업데이트가 없습니다. 호스팅 업체가 별도 패치를 적용하지 않았다면 더 새로운 버전으로 옮겨야 합니다.

참고로 일부 리눅스 배포판은 기존 버전 번호를 유지한 채 수정 사항을 배포합니다. 그래서 번호가 낮다고 해서 반드시 취약하다는 뜻은 아닙니다. 가장 확실한 방법은 호스팅 업체에 직접 확인하는 것입니다.

오늘 해야 할 일

• 호스팅 업체에 "제 서버의 PHP가 PHP2Shell(CVE-2026-109618, CVE-2026-109619)에 대비해 업데이트됐나요?"라고 문의하세요. "방화벽 규칙을 추가했습니다"라는 답만으로는 부족합니다. PHP 자체가 업데이트됐는지 확인하세요.
• WordPress를 업데이트해도 해결되지 않는다는 점을 기억하세요. 취약점은 WordPress가 아니라 그 아래에서 동작하는 PHP에 있습니다. 플러그인·테마 업데이트, 보안 플러그인, 유지보수 모드로는 막을 수 없습니다. 공격이 WordPress가 로드되기도 전에 실행될 수 있기 때문입니다.
• 직접 운영하는 서버(VPS)라면: PHP 패키지를 업데이트한 뒤 PHP-FPM이나 Apache를 반드시 재시작하세요. 재시작하지 않으면 서버는 예전의 취약한 코드를 계속 실행합니다. Docker를 쓴다면 새 이미지를 받아 컨테이너를 다시 만드세요.
• 오래된 버전을 쓰고 있다면: 서버 밖에 전체 백업을 만든 뒤 PHP 8.3 또는 8.4로 옮기세요. 그다음 홈페이지, 투어 페이지, 문의 양식, 예약 단계를 하나씩 확인하세요.
• 바로 패치할 수 없다면: Cloudflare 같은 방화벽 뒤에 사이트를 두면 임시로 보호할 수 있습니다. 기술 담당자가 있다면 PHP가 권장하는 임시 설정(예: session.upload_progress.enabled=0)을 적용할 수 있습니다. 완전한 해결책은 아니고 시간을 버는 방법일 뿐입니다.

이미 누군가 들어왔을까? 확인해야 할 신호

패치 후에는 취약점이 막히기 전에 누군가 침입하지 않았는지도 확인해 보세요.

• WordPress에 모르는 관리자 계정이 있나요?
• 설치한 적 없는 플러그인이 보이나요?
• 이미지가 저장되는 wp-content/uploads 폴더에 .php 파일이 있나요? 이 폴더에는 PHP 파일이 없어야 합니다.
• Google에서 site:내도메인.com으로 검색했을 때 직접 작성하지 않은 페이지가 나오나요?
• Google Search Console의 '보안 문제'에 경고가 있나요?
• 호스팅 업체에서 악성코드, 스팸, 비정상적인 리소스 사용에 관한 경고를 받았나요?

하나라도 해당된다면 호스팅 업체에 서버 검사와, 의심스러운 활동 이전의 깨끗한 백업으로 복원을 요청하세요. 그런 다음 WordPress, 호스팅, 데이터베이스, 이메일, 결제 및 판매 채널 연동의 모든 비밀번호와 API 키를 변경하세요. 고객 데이터가 유출됐을 가능성이 있다면 법적 의무에 대해 전문가와 상담하세요.

앞으로를 위해: 꾸준한 예방 조치

PHP2Shell이 마지막 취약점은 아닐 것입니다. 진짜 중요한 것은 다음번에 얼마나 준비돼 있느냐입니다. 다음과 같은 습관을 권합니다.

• 지원되는 버전을 사용하세요: 지원이 끝난 소프트웨어는 패치를 받지 못합니다. 지금은 PHP 8.3이나 8.4가 좋은 선택입니다.
• 업데이트 담당자를 정하세요: 누가, 얼마나 자주 사이트를 업데이트하나요? 분명한 답이 있어야 합니다. 관리형 호스팅이나 유지보수 계약은 이를 문서로 정하는 쉬운 방법입니다.
• 가진 것을 파악하세요: 메인 사이트, 예전 캠페인 페이지, 테스트 설치, 잊힌 서브도메인… 각각의 서버와 버전을 목록으로 관리하세요. 공격자는 잊힌 사이트를 좋아합니다.
• 필요 없는 것은 지우세요: 사용하지 않는 플러그인, 테마, 오래된 사이트를 삭제하세요. 부품이 하나 늘 때마다 취약점이 열 수 있는 문도 하나 늘어납니다.
• 사이트를 방화벽 뒤에 두세요: Cloudflare 같은 서비스는 새 취약점이 발표됐을 때 패치 전까지 첫 번째 방어선이 됩니다.
• 비밀번호와 키를 분리해 관리하세요: API 키를 코드에 적지 말고, 각 서비스에는 필요한 권한만 주고, 키를 정기적으로 바꾸세요.
• 백업은 서버 밖에 두고 복원을 시험해 보세요: 한 번도 복원해 보지 않은 백업은 제대로 동작할지 알 수 없는 백업입니다.
• 사이트를 모니터링하세요: 가동 상태 감시, Search Console 알림, 파일 변경 알림이 있으면 고객보다 먼저 문제를 알아챌 수 있습니다.
• 간단한 사고 대응 계획을 써 두세요: 문제가 생겼을 때 누구에게 연락할지, 사이트를 임시로 내리는 방법, 고객에게 알리는 방법을 미리 정해 두세요.

큰 그림: 취약점은 점점 더 빨리 발견된다

이번 일에서 가장 눈에 띄는 점은 취약점이 AI의 도움으로 발견됐다는 것입니다. 같은 도구는 나쁜 의도를 가진 사람들도 쓸 수 있습니다. 앞으로 취약점은 더 빨리 발견되고, 더 빨리 악용될 것입니다.

즉 "시간 날 때 업데이트하자"의 시대는 끝났습니다. 투어 사업자에게 웹사이트는 더 이상 단순한 진열장이 아닙니다. 예약을 받고 고객 데이터를 보관하는 사업 도구이며, 이를 안전하게 지키는 일은 사업을 멈추지 않게 하는 일의 일부입니다.

Monotim은 이런 서버 언어 취약점의 직접적인 영향을 받지 않는 현대적인 기반 위에 사이트를 만듭니다. 하지만 영원히 안전한 기술은 없습니다. 진짜 차이를 만드는 것은 사이트를 꾸준히 살피고, 문제가 생겼을 때 빠르게 대응할 수 있느냐입니다.

내 사이트가 PHP2Shell의 영향을 받았는지 확실하지 않거나 호스팅 업체에서 분명한 답을 받지 못했다면, 함께 살펴볼 수 있습니다.