dev.to

Patch Your PHP: What PHP2Shell Means for WordPress Sites

PHP를 패치하세요: PHP2Shell이 워드프레스 사이트에 미치는 영향

PHP2Shell 취약점 두 건은 로그인 없이 서버에서 코드를 실행할 수 있으며, 워드프레스나 플러그인 업데이트만으로는 해결되지 않습니다. 글은 PHP 패치 버전과 배포판 백포트 확인법, 호스팅 업체 확인 절차, 임시 완화 설정을 정리합니다.

에디터 노트

패치 적용 여부를 버전 번호만으로 판단하기 어렵다는 점이 이 사안의 실무상 쟁점입니다. 배포판이 CVE 수정을 백포트하면 오래된 버전 문자열이 남을 수 있고, 댓글의 Ubuntu 경험담도 8.5.4 패키지 변경 기록을 확인해야 했다고 전합니다. 공유 호스팅에서는 호스트의 패치 확인이 필요하다는 조언이 이 조건에 맞습니다. 완화 설정은 패치를 대신하지 않습니다. 특히 memory_limit=-1은 요청당 메모리 제한을 없애므로 댓글이 지적한 프런트엔드 요청 크기 제한과 함께 조건을 따져야 합니다. 글도 완전한 완화책은 없다고 밝힙니다. 따라서 우선순위는 수정된 PHP 빌드 적용 여부를 확인하는 것이고, 설정 변경은 확인된 공격 경로를 줄이는 임시 조치로 읽는 편이 정확합니다.

AI 요약

PHP 자체의 취약점 두 건인 CVE-2026-109618과 CVE-2026-109619가 공개됐습니다. 두 취약점 모두 CVSS v4.0 기준 9.2점이며, 공격자는 로그인하지 않고 서버에서 코드를 실행할 수 있습니다. 워드프레스는 PHP 위에서 동작하므로 워드프레스와 플러그인을 최신 상태로 유지해도 PHP 런타임이 취약하면 공격에 노출됩니다. PHP-FPM, Apache mod_php, php-cgi, FrankenPHP, LiteSpeed 등 웹 요청을 처리하는 PHP 구성이 영향을 받습니다. 특히 mod_php에서는 워드프레스 코드가 로드되기 전에 공격이 실행될 수 있습니다.

영향을 받는 버전과 패치

PHP 8.5는 8.5.12, 8.4는 8.4.27, 8.3은 8.3.36, 8.2는 8.2.35에서 수정됐습니다. PHP 7.4부터 8.1까지는 보안팀이 수정 코드만 담은 소스 백포트를 제공하므로 직접 빌드하거나 리눅스 배포판 및 장기 지원 업체의 패키지를 사용해야 합니다. PHP 7.3 이하에는 수정본이 없어서 지원 버전으로 옮기는 방법만 남습니다. 글은 워드프레스 권장 최소 버전이 PHP 8.3이라고 안내하며, PHP 8.2의 지원 종료일은 2026년 12월 31일이라고 덧붙입니다.

워드프레스 관리자 화면의 /wp-admin/site-health.php?tab=debug에서 Server 항목을 열면 PHP 버전을 확인할 수 있습니다. 다만 Debian, Ubuntu, RHEL 같은 배포판은 기존 버전 번호를 유지한 채 보안 패치를 백포트하기도 합니다. 따라서 버전 문자열만 보지 말고 패키지 변경 기록에서 CVE 번호가 반영됐는지 확인해야 합니다. 관리형 호스팅에서는 업체에 패치된 빌드 적용 여부를 문의하는 편이 정확합니다.

취약점과 완화 설정

CVE-2026-109618은 요청 처리 중 메모리가 부족해 PHP가 요청 데이터를 일부만 구성한 뒤 정리 과정에서 이를 완성된 데이터처럼 다루면서 발생합니다. 공격자는 조작한 폼 업로드로 이를 유발할 수 있습니다. CVE-2026-109619는 치명적 오류 뒤 PHP 작업자가 이미 해제된 메모리를 가리키는 포인터를 남기고, 다음 요청에서 이를 사용하면서 발생합니다. 세션 업로드 진행 기능과 mod_php의 .htaccess 안 php_value 설정이 확인된 공격 경로입니다. 세부 정보는 공개 예정일보다 이틀 먼저 유출됐고, Tenable 타임라인에 따르면 Amazon은 10월 17일 이른 공격 시도를 보고했습니다.

PHP는 완전한 완화책이 없다고 밝혔습니다. 글은 확인된 공격 경로의 노출을 줄이는 설정으로 php_admin_value를 사용한 memory_limit=-1, 낮은 post_max_size 설정, session.upload_progress.enabled=0, PHP 8.5의 fatal_error_backtraces=0, .htaccess의 오래됐거나 잘못된 php_value 항목 제거를 제시합니다. 이 설정은 php.ini, PHP-FPM 풀 설정 또는 웹 서버 설정에 적용해야 합니다. ini_set()과 .user.ini는 적용 시점이 늦습니다. 변경 뒤에는 모든 PHP 작업자를 재시작해야 합니다. 글은 RLIMIT_AS나 RLIMIT_DATA로 메모리를 제한하지 말라는 advisory 내용도 언급합니다.

호스팅 업체와 이용자 대응

글쓴이는 WP Engine이 PHP 패치 공개 전에 네트워크와 서버 수준 완화 조치를 적용했다고 고객에게 알렸다고 전합니다. SiteGround는 10월 20일 PHP의 공지를 받은 뒤 서버 완화를 추가하고 10월 21일 공식 패치를 적용했다고 블로그에 게시했습니다. 글쓴이의 SiteGround 사이트는 PHP 8.2.35로 표시됐으며, PHP 8.3으로 옮길 계획이라고 밝혔습니다. 호스팅 업체의 안내가 없으면 블로그나 상태 페이지를 확인한 뒤 Site Health에서 버전을 점검하라고 권합니다.

dev.to 반응

  • @shuttlewright — 이번 주 고객에게 보내는 모든 이메일에서 "워드프레스를 업데이트해도 해결되지 않는다"는 점을 별도 문단으로 설명해야 합니다. 비기술 담당자에게는 사이트가 워드프레스 위에서 돌고, 워드프레스는 PHP 위에서 돌아가며, 버그가 있는 계층은 PHP이므로 관리자 화면이 아니라 서버에서 수정해야 한다고 설명하면 됩니다. 여러 사이트를 관리하는 업체는 wp-cli로 설치별 버전을 한나절 안에 확인할 수 있고, 고객은 먼저 알려준 업체를 기억합니다.
  • @rushdeploy — 시의적절한 글입니다. 공유 호스팅 사용자라면 PHP 버전만 묻지 말고 패치된 빌드인지 호스트에 확인해야 합니다. 배포판은 버전 번호를 올리지 않고 패치를 백포트하는 경우가 있어 Site Health 화면의 버전이 취약해 보일 수 있습니다.
    • @shuttlewright — 좋은 지적이며 반대 방향도 마찬가지입니다. 백포트로 패치된 오래된 버전 번호도 있고, 수정 전 빌드인 깨끗해 보이는 버전 번호도 있습니다. 고객이나 티켓에서 버전 문자열을 분류하는 사람들을 위해 붙여 넣은 버전을 수정 릴리스와 대조하고 백포트 가능성을 표시하는 간단한 검사기를 만들었습니다. 공개한 도구입니다. 공유 호스팅에서는 호스트의 답변이 여전히 기준이며, 검사기는 분기별 버전 확인을 덜어줄 뿐입니다.
    • @cseeman — 좋은 지적입니다, Rishabh. 공유해 주셔서 감사합니다.
  • @jeemmo — 이번 주 직접 서버에 패치를 적용하면서 Ubuntu 보안 저장소에 수정이 이미 들어와 있었고, 8.5.4 패키지에 백포트된 것을 알았습니다. unattended-upgrades가 켜져 있지 않으면 자동 적용되지는 않습니다. 따라서 php -v에 8.5.4라고 표시된다고 미패치 상태라는 뜻은 아니며, 패키지 변경 기록에서 CVE 번호를 확인해야 합니다. 제 서버도 mod_php여서 이후 접근 로그에서 phpinfo 탐색과 새 .php 파일을 찾아봤습니다. 아무것도 발견하지 못했지만 확인에 10분을 쓸 가치는 있습니다.
  • @stefan_07d23f966225156b50 — memory_limit=-1 옆에 더 큰 경고를 붙이겠습니다. 이 설정을 해결책으로 그대로 복사하면 PHP 요청별 메모리 제한을 없앤다는 점을 잊기 쉽습니다. PHP advisory는 프런트엔드의 요청 크기 제한도 요구합니다. 이 부분은 "이 설정을 바꾸면 패치된 것"이 아니라 임시 완화책이라고 써야 합니다.

원문: dev.to / 번역·요약: Trawling

원문 보기 ↗토론 보기 ↗