PHP 5.2부터 8.1까지 적용 가능한 php2shell 패치 출시

주요 내용

• php2shell은 CVE-2026-109618 및 CVE-2026-109619라는 두 가지 심각한 PHP 코어 원격 코드 실행(RCE) 취약점을 통칭하는 명칭입니다.
• PHP는 8.5.12, 8.4.27, 8.3.36 및 8.2.35 버전에서 해당 문제를 수정했으나, 지원 종료된 브랜치에는 업스트림 패치가 제공되지 않습니다.
• 출시 전부터 공격 시도가 보고되었으므로, 즉시 패치를 적용하고 모든 PHP 워커를 재시작하십시오.
• TuxCare의 런타임용 ‘무한 수명 주기 지원(ELS)’을 통해, 지원 종료된 PHP 버전에 대한 수정된 빌드를 지금 바로 이용할 수 있습니다.

요약

전체 버전으로 이동 ↓

개요: php2shell은 연구자들이 CVE-2026-109618 및 CVE-2026-109619에 붙인 별칭으로, 이는 특정 프레임워크나 CMS가 아닌 PHP 자체에 존재하는 두 가지 심각한 원격 코드 실행 취약점입니다. 이 취약점들에 대한 소식은 예정된 공개 일보다 앞선 2026년 10월 20일에 유출되었으며, 이에 따라 PHP 보안 팀은 긴급 패치 출시 일정을 10월 21일로 앞당겼습니다.

영향: 두 경우 모두 인증되지 않은 공격자가 PHP 워커의 사용자 권한으로 코드를 실행할 수 있게 하지만, 특정 서버가 얼마나 취약한지는 해당 서버에서 PHP가 어떻게 실행되는지에 따라 달라집니다. PHP 측은 기본 제한값이 적용된 Apache mod_php 환경에서 완전한 원격 코드 실행(RCE)이 가능함을 확인했으며, PHP-FPM 환경에서도 한 가지 경로를 통해 취약점이 검증되었습니다. 이 섹션으로 이동 →

중요도: PHP 보안 팀은 두 가지 취약점 모두 CVSS v4.0 기준 9.2로 평가했으며, 이는 ‘매우 심각(Critical)’ 수준입니다. 유출 당시 유포되었던 10.0이라는 수치는 PHP 측의 평가가 결코 아닙니다. 이 섹션으로 이동 →

영향을 받는 대상: PHP의 보안 권고 사항은 지원되는 4개 브랜치 모두의 해당 릴리스를 다루고 있는 반면, 유출된 익스플로잇 도구는 5.4.0 버전까지 거슬러 올라가 작동한다고 주장합니다. 업스트림에서는 8.2부터 8.5까지만 패치를 제공하므로, PHP 8.1, 8.0, 7.x 및 5.x 버전은 php.net을 통해 아무런 지원도 받지 못하며, Mallory는 이러한 버전 중 하나를 실행 중인 인터넷에 노출된 호스트가 약 884,000개에 달한다고 집계했습니다. 이 섹션으로 이동 →

현황: 클라우드플레어(Cloudflare)의 데인 크네흐트(Dane Knecht) 최고기술책임자(CTO)는 릴리스 몇 시간 전인 10월 21일 07:43(UTC)에 PHP 사이트를 대상으로 한 초기 공격 시도가 있었다고 보고했으나, 실제로 성공한 사례가 몇 건인지는 명확하지 않습니다. 두 CVE를 모두 해결한 런타임용 ‘무한 수명 주기 지원(ELS)’ 빌드는 PHP 5.2부터 8.1까지의 모든 지원 종료 브랜치에서 현재 이용 가능합니다.

지금 당장 다음을 수행하세요: 벤더 소프트웨어나 제어판에 번들로 포함된 버전을 포함해 소유하고 있는 모든 PHP 설치 환경을 찾아내고, FPM 호스트를 빠뜨리지 말고 Apache mod_php를 실행 중인 환경부터 처리하세요. 업스트림이나 배포판에서 지원하는 브랜치로 업데이트하고, 지원이 종료된 브랜치는 고정된 ELS 빌드로 이전하거나 공개 인터넷에서 제거하세요. 그런 다음 모든 PHP 워커를 재시작하거나 교체하세요. 기존 코드는 해당 프로세스가 종료될 때까지 계속 요청을 처리하기 때문입니다. 실제로 실행 중인 환경을 확인하려면:

ps aux | grep -E '[p]hp-fpm|[p]hp-cgi|[l]sphp|[h]ttpd|[a]pache2'

목록을 하나씩 확인하면서, PHP 워커 프로세스가 셸이나 다운로드 도구를 실행하는지 주의 깊게 살펴보세요. 이것이 바로 공격이 이루어지는 전형적인 양상입니다.

이 섹션으로 이동 →

대부분의 PHP 긴급 상황은 애플리케이션에서 시작됩니다. 워드프레스 플러그인, 마젠토 확장 기능, 2019년 이후로 아무도 손대지 않은 라라벨 패키지 등이죠. 이를 업데이트하고, 몇 가지 비밀 키를 변경한 뒤 다음 작업으로 넘어가면 됩니다. 이 모든 과정은 그 밑에 있는 인터프리터에는 전혀 영향을 미치지 않습니다.

php2shell은 그런 식으로 작동하지 않습니다. 취약점은 인터프리터에 존재하기 때문에, 영향을 받는 소프트웨어는 대략 “PHP를 실행하는 모든 것”이며, 수정 패치는 유지 관리되는 네 개의 브랜치에만 적용됩니다. 구형 청구 애플리케이션에서 여전히 PHP 7.4를 실행 중인 사용자들(그리고 그런 경우가 꽤 많습니다)은, 업스트림에서 패치가 영원히 제공되지 않을 치명적인 RCE 취약점이 있다는 사실을 알게 되었습니다.

여기에 또 다른 문제가 하나 더 있습니다. 이러한 취약점은 패치로 공개되기 전에 이미 소문으로 퍼졌고, 공격자들은 수정 패치가 적용되기 전부터 이미 탐색을 시작했습니다.

NIST가 발표한 현재 CVSS 4.0 점수는 9.2(Critical)이지만, 그 외에도 확인되지 않은 수치들이 떠돌고 있었다. 10월 20일 오전, 해커뉴스(Hacker News)에 올라온 한 게시글은 10.0으로 평가되고 PHP 5 버전까지 거슬러 올라가는 두 가지 PHP 원격 코드 실행 취약점이 10월 22일 목요일에 공개될 것이라고 주장했다. 게시자는 “출처: 내 말 믿어, 친구”라는 말 외에는 아무런 증거도 제시하지 않았다. 해당 게시물은 삭제되었지만, 스크린샷은 이미 사방에 퍼져 있었다.

이 소문은 사그라들지 않았는데, watchTowr이 해당 정보가 사실이며, 버그 정보는 공개 금지 상태였기 때문에 모두가 목요일까지 기다려야 한다고 게시했기 때문이다. 그날 저녁 UTC 기준 19:33, 야쿠브 젤렌카(Jakub Zelenka)는 PHP 보안 팀의 사전 공지문을 php.announce에 게시했습니다. 이 공지문은 두 가지 치명적 취약점(모두 CVSS v4.0 기준 9.2 등급)을 확인했으며, 다음 날인 10월 21일에 패치를 배포할 예정임을 알리고, 세부 정보가 공개되거나 악용 사례가 발견될 경우 더 일찍 배포할 권리를 유보한다고 밝혔습니다.

보도 금지 조치가 하루 늦어졌고, 다른 많은 사람들도 같은 스크린샷을 보고 있었다. 다음 날 아침 UTC 기준 07:43이 되자, 클라우드플레어의 CTO는 초기 공격이 감지되고 있다고 밝혔으며, 임시 방편으로 마련된 WAF 규칙이 무료 요금제를 포함한 모든 요금제에 적용되었다.

참고로, PHP의 사전 공지에는 두 CVE 번호 모두 명시되지 않았습니다. 이 식별자들은 유출된 자료와 watchTowr의 보도를 통해 처음 알려졌으며, 수정 패치가 배포되었을 때 PHP의 보안 권고문을 통해 확인되었습니다.

공개 전까지 알려진 정보는 거의 없었습니다. watchTowr는 CVE-2026-109618을 재현했다고 밝혔고, Huntress는 개념 증명(PoC)을 구축하지 못했으며, Sansec에 따르면 유출된 PHP2Shell 스크린샷에는 5.4.0 이후 모든 릴리스를 지원한다는 내용의 배너가 표시되어 있었습니다. 10월 21일 발표된 PHP의 두 건의 권고문을 통해 대부분의 공백이 채워졌습니다.

109618, “OOM 손상을 통한 RCE”는 PHP가 메모리 부족 오류를 어떻게 처리하느냐에 달려 있습니다. 이 방법은 longjmp() 요청을 중단하기 위함이며, 요청 메모리가 부분적으로만 초기화된 상태에서 할당이 실패할 경우, 이후 종료 코드가 해당 오류 상태를 감지하여 해당 부분을 읽거나 분기 처리합니다. 다중 부분 파싱은 공격자에게 겉보기에는 제한 범위 내에 머물면서 OOM(메모리 부족) 오류를 유발할 수 있는 여러 가지 방법을 제공하는데, 예를 들어 헤더 수가 무제한인 부분 등이 있습니다. mod_php의 경우, 이러한 모든 과정은 애플리케이션 코드가 실행되기 전인 요청 시작 단계에서 발생합니다.

CVE-2026-109619, “오래된 전역 상태를 통한 원격 코드 실행(RCE)”은 요청 간에 걸쳐 발생하는 사용 후 해제(use-after-free) 취약점입니다. OOM을 포함한 치명적인 오류가 발생하면, 이미 종료된 요청에 속했던 메모리를 가리키는 포인터를 영구 작업자(persistent worker)가 계속 보유하게 될 수 있습니다. 같은 워커에서 처리되는 후속 요청은 정상적인 초기화 과정을 통해 해당 상태가 재설정되기 전에 이 오래된 상태를 참조하게 됩니다. 이 공격을 성공적으로 수행하는 것은 다소 까다롭지만, PHP 측은 mod_php에 대한 원격 코드 실행(RCE) 가능성을 확인했으며, PHP-FPM에 대한 세션 경로 공격도 검증했습니다.

따라서 PHP를 어떻게 실행하느냐가 중요합니다. mod_php는 두 가지 측면 모두에서 최악의 경우입니다. FPM은 요청 시작에 실패하면 자식 프로세스를 종료하는데, 이로 인해 가장 깔끔한 OOM 처리 순서가 차단되지만, PHP는 여전히 이를 취약한 상태로 간주합니다. PHP는 FrankenPHP를 mod_php와 마찬가지로 애플리케이션과 무관한 OOM 공격에 취약할 가능성이 높은 것으로 간주하며, LSAPI는 FPM과 더 유사한 방식으로 동작합니다.

업로드 진행 상황 연결

그 5.4.0 배너가 유용한 단서가 되었습니다. PHP 5.4에서는 세션 업로드 진행 상황 기능이 도입되었는데, 이를 통해 스크립트가 멀티파트 업로드가 어느 정도 진행되었는지 확인할 수 있습니다. 이 기능은 기본적으로 활성화되어 있으며, PHP 공식 권고문에서는 이 기능이 거의 사용되지 않는다고 설명하고 있습니다. 또한 이 기능은 CVE-2026-109619에서 확인된 취약점의 원인이기도 한데, 이는 일반적인 초기화 과정보다 먼저 세션 처리 단계에 도달하여 중단된 요청이 남긴 상태를 파악할 수 있기 때문입니다. session_start() 전화 연락이 필요합니다. 한 연구자의 분석 보안 권고문이 발표되기 전부터 이 코드 경로에서 ‘use-after-free’ 문제를 지적한 바 있었는데, 그 지적은 거의 정확했다.

이 기능을 비활성화한다고 해서 문제가 해결되는 것은 아닙니다. PHP 핵심 팀의 지나 배니야드(Gina Banyard)는 초기에 패치 적용이 유일한 완화책이라고 밝혔으며, 두 권고문 모두 그녀의 주장을 뒷받침하며 업데이트만이 유일하고 완전하며 신뢰할 수 있는 해결책이라고 명시하고 있습니다. 업로드 진행 상황을 비활성화하면 시연된 세션 경로는 차단되지만, 그 외의 다른 라이프사이클 경로는 차단되지 않습니다.

오늘 일부 호스트에 패치를 적용할 수 없는 경우, 해당 경로에 대한 PHP의 임시 조치가 적용됩니다. php.ini 또는 다음 항목 아래에 드롭인 conf.d, 그리고 Sansec은 여기에 엄격한 세션 모드를 추가로 적용합니다:

session.upload_progress.enabled = 0
session.use_strict_mode = 1

FPM 풀은 메인 INI 설정을 재정의할 수 있으므로, 각 풀의 실제 구성을 확인하십시오. 풀별로 별도의 재정의가 필요한 경우, 다음 설정을 적용한 후 해당 풀의 워커를 다시 시작하십시오:

php_admin_flag[session.upload_progress.enabled] = off
php_admin_flag[session.use_strict_mode] = on

엄격한 세션 모드는 PHP 고유의 기능입니다. 세션 보안 지침 수년 동안 추진해 온 덕분에, 그 비용의 절반은 거의 들지 않지만, Redis나 데이터베이스 세션 핸들러가 이에 필요한 ID 확인 기능을 구현하지 않을 수도 있습니다. 그 밖의 임시 해결책으로는 다음과 같은 것들이 있습니다. fatal_error_backtraces=0 PHP 8.5 환경에서, 앱이 파일을 업로드받지 않는 경우 프론트엔드에서 멀티파트 요청을 차단하는 방법입니다. CVE-2026-109618의 경우, PHP의 주요 임시 대응책은 다음을 강제 적용하는 것입니다. memory_limit=-1 관리적으로 모든 워커를 재시작하면, 확인된 취약점이 의존하는 요청당 예측 가능한 제한이 제거됩니다. 이 방법은 통제 불능 상태가 된 스크립트에 대한 PHP의 방어 기능도 무력화시키므로 신중하게 처리해야 하며, PHP 측에서도 이 방법이 완전하지 않다고 밝혔습니다. 이 중 어느 것도 근본적인 해결책은 아닙니다. 모든 호스트에 패치가 적용될 때까지는 이를 일시적인 조치로만 간주하십시오.

왜 수명이 다한 PHP가 더 큰 문제인가

PHP의 지원 버전 페이지에는 이 점이 명확히 명시되어 있습니다. 8.4 및 8.5 브랜치는 활발히 지원되고 있으며, 8.2와 8.3은 보안 수정만 제공받고, 그보다 오래된 모든 버전은 지원 종료(EOL) 상태입니다. 지원이 종료된 브랜치에는 php.net에서 보안 업데이트가 제공되지 않으며, 심각한 RCE 취약점이 발견된다 해도 이 사실은 변하지 않습니다.

아직도 사용 중인 버전에 대한 수치는 결코 좋지 않습니다. 말로리(Mallory)는 10월 20일 기준으로 HTTP 배너에 PHP 8.1 이하 버전을 보고한 인터넷에 노출된 호스트가 약 884,000개에 달한다고 집계했는데, 이는 버전을 보고한 전체 호스트의 약 59%에 해당합니다. 배너 정보만으로는 노출이 확정된 것은 아니며, 해당 호스트 중 일부는 백포트된 패키지를 실행하고 있을 수도 있습니다. 그럼에도 불구하고 구버전 PHP를 보고하는 인터넷에 노출된 호스트의 수는 여전히 어마어마한 수준입니다.

문제를 일으키는 설치 사례는 아무도 PHP 서버라고 생각하지 않는 것들입니다. 벤더의 어플라이언스나, 자체 서버를 포함하는 Windows 소프트웨어 등이죠. php-cgi.exe (ELS for Runtimes에도 바로 이런 이유로 Windows용 PHP 빌드가 있습니다). 제어판. 2017년에 누군가가 만들어 놓고는 다시는 언급하지 않은 내부 위키.

30명 규모의 대행사가 하나의 cPanel 서버에서 수백 개의 고객사 워드프레스 사이트를 호스팅하고 있다고 상상해 보세요. 프리미엄 테마가 8.x 버전에서는 제대로 작동하지 않아 계정의 절반이 PHP 7.4에 고정된 상태입니다. 금요일까지 그 모든 사이트를 PHP 8로 마이그레이션할 사람은 아무도 없습니다. PHP 업그레이드는 애플리케이션 프로젝트에 해당하기 때문에, 바로 그 이유 때문에 여전히 수많은 PHP 7.x 설치 환경이 가동되고 있는 것입니다.

이것이 바로 Runtimes용 ELS가 메우려는 공백입니다. TuxCare는 지원 종료된 브랜치에 보안 수정 사항을 역포트하므로, 7.4 버전에 고정된 사이트는 활성 RCE 공격이 발생하는 동안 PHP 8로의 강제 마이그레이션 없이도 php2shell 수정 사항을 적용받을 수 있습니다. 마이그레이션은 여전히 이루어져야 합니다. 다만, 누군가가 정한 일정에 따라 진행될 뿐입니다.

php2shell 수정 사항의 출처와 브랜치별 정보, 그리고 PHP 측의 지원 기간:

두 공지 모두 8.5.12, 8.4.27, 8.3.36 및 8.2.35를 패치된 릴리스로 명시하고 있으며, PHP의 변경 내역에는 브랜치별 세부 정보가 나와 있습니다. 해당 버전을 설치한 후, 요청을 처리하는 프로세스가 실제로 해당 버전을 실행하는지 확인하십시오.

PHP가 사용 중인 리눅스 배포판의 자체 저장소에서 제공된 것이라면, 해당 배포판의 보안 권고 사항이 우선합니다. 배포판은 종종 업스트림 버전 번호를 변경하지 않고 수정 사항을 백포트하므로, 버전 문자열만으로는 아무것도 판단할 수 없습니다.

지금 바로 Runtimes용 ELS를 확인해 보세요 →

PHP는 예전에도 이런 적이 있었다

2012년 5월, 의 원격 코드 실행 취약점인 CVE-2012-1823에 대한 세부 정보가 php-cgi, 수정본이 준비되기도 전에 실수로 공개되었습니다. PHP 개발팀은 서둘러 5.3.12와 5.4.2 버전을 출시했습니다. 스테판 에서(Stefan Esser)를 비롯한 연구진들은 이 수정 사항이 우회될 수 있음을 곧바로 밝혀냈고, PHP 개발팀은 며칠 뒤 다시 업데이트를 배포해야만 했습니다. 컴퓨터월드는 다음과 같이 보도했다 그 당시.

그리고 Windows의 CVE-2024-4577이 있는데, php-cgi 2024년 6월의 인자 주입 공격. 아카마이에 따르면, 해당 취약점이 공개된 지 24시간도 채 되지 않아 자사의 허니팟을 겨냥한 공격 시도가 포착되었다. 해커 뉴스.

유출된 버그는 수정 코드를 작성하는 개발자를 포함해 모든 사람의 일정을 촉박하게 만들며, 급하게 작성된 수정 코드는 때때로 재검토가 필요할 수 있습니다. 패치를 적용한 후 며칠 동안은 보안 권고 사항을 계속 주시하시기 바랍니다.

PHP가 무엇을 생성하는지 살펴보세요

인터프리터 수준의 원격 코드 실행(RCE)은 버그의 작동 방식에 관계없이 대체로 비슷한 양상을 띱니다. 다음과 같은 PHP 워커는 php-fpm, php-cgi, lsphp 또는 아파치 프로세스가 평소에는 절대 시작하지 않는 무언가를 시작하거나, 셸, 파이썬 또는 펄, curl 또는 wget. 다음을 포함하는 명령줄 /dev/tcp/ 또는 mkfifo 이는 전형적인 리버스 쉘 징후이며, 다음 역시 마찬가지입니다. php -r 한 줄 호출 fsockopen. 갑자기 터져 나온 whoami, id 또는 uname -a 웹 서버 사용자로 실행 중인 것은 정찰 활동을 하는 누군가일 수 있습니다. 관리자 도구도 비슷한 기능을 수행하기 때문에, 이 중 어느 하나만으로는 증거가 될 수 없습니다. 중요한 것은 요청이나 방금 생성된 파일과 일치하는, 비정상적인 프로세스 트리입니다.

엔드포인트 탐지 기능이 없는 리눅스 서버에서, 플로리안 로스(Florian Roth)가 개발한 무료 프로세스 감시 도구인 ‘process-watcher’는 PHP 프로세스가 실행하는 모든 프로그램과 해당 프로그램의 전체 명령줄을 기록합니다. 로스는 이 도구가 어떤 것도 차단하지는 않으며, 단지 모니터링만 할 뿐이라고 분명히 밝히고 있습니다. 당분간 특정 시점의 상황을 빠르게 확인하려면:

ps -eo pid,ppid,user,args --forest | grep -A3 '[p]hp-fpm'

무언가 발견되면, 누군가가 “정리”하기 전에 해당 서버를 격리하고 웹 서버 및 PHP 로그를 보존하십시오. 기본 로그에는 POST 본문이 기록되지 않기 때문에, 액세스 로그가 깨끗하다고 해서 문제가 해결된 것은 아닙니다. 웹쉘, 웹 루트 디렉터리의 새로운 파일, 새로운 크론 작업, 그리고 새로운 계정을 확인하십시오. 침해된 호스트에 패치를 적용하는 것은 침입자가 여전히 내부에 있는 상태에서 문을 닫는 것과 같습니다. 즉시 패치를 적용할 수 없는 경우, CERT-EU는 수정 조치가 마련될 때까지 인터넷에 노출된 애플리케이션을 공용 네트워크에서 분리하는 것을 고려할 것을 권장합니다. 오래된 지점 앞에 WAF나 VPN을 배치하면 시간을 벌 수 있지만, 그 이상은 기대할 수 없습니다.

재고 파악이 최우선이며, 그 목록은 대개 누구나 예상하는 것보다 더 길다. 이 루프는 일반적인 리눅스 저장소와 ELS 빌드 디렉터리를 확인한다. /opt/alt/ 을 포함하며, 각 바이너리가 보고하는 버전을 출력합니다. 사용자 지정 빌드나 벤더 번들은 어디에나 존재할 수 있으므로, 이는 시작점입니다:

for p in /usr/bin/php /usr/bin/php[0-9]* /opt/alt/php*/usr/bin/php; do [ -x "$p" ] && echo "$p $("$p" -r 'echo PHP_VERSION;')"; done

이는 디스크에 무엇이 있는지 보여줄 뿐, 각 사이트에서 실제로 실행되는 내용을 나타내는 것은 아닙니다. FPM 풀, 가상 호스트(vhosts), 제어판은 각각 서로 다른 바이너리를 가리킬 수 있기 때문입니다. 해당 설정도 확인해 보십시오. 지원되는 브랜치는 업스트림 또는 배포판 업데이트를 받습니다. ELS for Runtimes 빌드는 TuxCare의 ELS for Runtimes PHP 문서에 명시된 명령어를 사용하여 일반 패키지 관리자를 통해 업데이트됩니다. RPM 기반 시스템에서는 `sudo yum update alt-php*`를 실행하면 됩니다. Debian 및 Ubuntu에서는 패키지 목록을 새로 고치고 alt-php 패키지를 업그레이드하십시오:

sudo apt-get update
sudo apt-get upgrade alt-php*

그리고 여기서 종종 간과되는 단계가 있습니다. 워커들이 여전히 기존 코드를 실행하고 있는 상태에서는 수정된 패키지를 설치하는 것만으로는 충분하지 않습니다. 실행 중인 PHP-FPM 마스터, 또는 mod_php Apache 내에 로드되어 재시작될 때까지 기존 코드를 메모리에 유지하며, 컨테이너는 대체될 때까지 이를 유지합니다. 수십 개의 FPM 풀을 가진 공유 호스팅 서버가 대표적인 사례로, 한 버전은 재시작되지만 나머지 세 버전은 재시작되지 않는 경우가 있습니다. 업데이트가 적용된 후 모든 FPM 마스터가 시작되었는지 확인하십시오:

ps -eo pid,lstart,args | grep '[p]hp-fpm: master'

마지막으로, 스캐너의 업스트림 버전 비교 결과를 근거로 티켓을 종료하지 마십시오. 백포트된 ELS 또는 배포판 빌드는 여전히 원래의 업스트림 버전 번호를 보고할 수 있으므로, 버전 문자열만 읽는 스캐너는 이미 패치가 적용된 호스트를 문제로 표시할 수 있습니다. 도구가 지원하는 경우, OVAL 및 CSAF 피드를 포함하는 TuxCare의 기계 판독 가능 보안 데이터를 도구에 제공하십시오. 설치된 패키지, 해당 패키지가 해결하는 보안 권고 사항, 그리고 실제로 요청을 처리하는 프로세스를 기록해 두십시오. 감사관이 바로 이러한 정보를 요청할 것이기 때문입니다.

php2shell이 중요한 이유

런타임은 의존성 중 하나이며, 이를 지원하지 않는 상태로 방치하면 새로운 핵심 취약점이 무기한으로 노출된 채 남게 됩니다. 개발 팀들은 Composer 패키지를 꼼꼼하게 관리하고 있지만, 수년 전부터 보안 패치가 더 이상 제공되지 않는 인터프리터에서 이를 실행하고 있습니다.

이번 정보 유출 사건은 또한 사람들이 얼마나 사전 경고를 거의 받지 못하는지 보여주었습니다. 첫 소문은 몇 시간 만에 사실로 확인되었고, 패치는 다음 날 배포되었지만, 패치가 배포되기도 전에 이미 공격 시도가 나타났습니다. “다음 분기에 업그레이드하겠다”는 식의 말은 이런 일정을 감당할 수 없습니다.

직접 설치하는 방법도 등장했습니다. PHP 개발팀은 7.4, 8.0, 8.1 버전에 대한 백포트를 릴리스 태그를 지정하지 않은 채 php-src에 커밋했으며, 커뮤니티 스크립트는 이제 이를 사용하여 소스 컴파일된 PHP를 재빌드합니다. 이는 자체 컴파일된 단일 서버에서는 작동할 수 있지만, php2shell만 수정하고 그 이후의 문제는 해결하지 못하며, 배포판 패키지, `mod_php` 및 `lsphp`는 건너뛰고, 향후 발생할 모든 PHP CVE를 다시 빌드 프로젝트로 전환하게 됩니다.

그러니 지금 당장 지원되는 브랜치에 패치를 적용하고, 재시작이 필요한 것은 재시작하세요. php.net에서 더 이상 지원하지 않는 PHP 버전은 수정된 ELS 빌드로 옮기거나 인터넷에서 완전히 제거한 다음, 실제 마이그레이션 작업을 ‘희망 목록’이 아닌 ‘일정표’에 반영하세요.

지금 바로 Runtimes용 ELS를 확인해 보세요 →

연표

참조

이 게시물의 주요 출처는 PHP 보안 권고문인 ‘OOM 손상을 통한 RCE (CVE-2026-109618)’ 및 ‘오래된 전역 상태를 통한 RCE (CVE-2026-109619)’, php.announce에 게시된 PHP 보안 팀의 사전 공지 (2026년 10월 20일), PHP 지원 버전 페이지 및 PHP 8 변경 내역, watchTower의 php2shell FAQ, Sansec의 php2shell 연구 보고서, Huntress의 신속 대응 보고서, CERT-EU 보안 권고 2026-018, Mallory의 노출 분석, Florian Roth의 process-watcher, CVE-2026-109618 및 CVE-2026-109619에 대한 NVD 항목, The Hacker News의 관련 보도, 그리고 TuxCare의 런타임용 ELS PHP 문서를 참조하십시오.