PHP 지원 종료는 비즈니스 리스크다: PHP2shell이 드러내는 패치 책임
Dokebi · 2026년 10월 29일 · #tech #security #php #vulnerability #patch-management #business-risk
소개
웹사이트, 상용 서비스, 엔터프라이즈 시스템에서 지원 종료(End-of-Life, EOL)는 단순한 기술적 문제가 아닙니다. 패치되지 않은 취약점을 방치하는 것은 비즈니스 중단, 고객 신뢰 상실, 예산 영향으로 이어질 수 있는 경영 및 운영 과제입니다.
이 글에서는 PHP를 사례로 사용하여 소프트웨어 지원 종료가 왜 비즈니스 리스크인지 설명하고, 취약점이 실제로 악용된 사례에서 얻을 수 있는 교훈을 정리합니다. 또한 현장의 경영진, 관리자, 엔지니어가 확인해야 할 핵심 사항을 제시합니다.
이 글은 서버 사이드 애플리케이션 엔진의 대표적인 예인 PHP에 초점을 맞추지만, 다른 모든 소프트웨어 및 인프라 구성 요소에도 동일한 수준의 주의와 사전 조치가 필요합니다.
경영진·관리자를 위한 핵심 요약
| 핵심 포인트 | 조직에 중요한 이유 | 먼저 확인할 사항 |
|---|---|---|
| 지원 종료 ≠ 시스템 즉시 중단 | 시스템은 계속 작동하지만 해당 버전에 대한 추가 수정이 제공되지 않음 | 설치된 PHP 버전과 공식 지원 종료일 |
| 지원되는 버전도 취약할 수 있음 | PHP2shell 같은 치명적 취약점은 지원 브랜치에서도 긴급 조치가 필요 | 각 시스템의 영향 여부와 패치된 릴리스 설치 여부 |
| 업그레이드는 엔지니어링만의 과제가 아님 | 테스트, 비즈니스 조율, 예산, 벤더 책임 모두 중요 | 담당자, 마감일, 예산, 전환 승인 권한 |
| "사고가 없었으니 안전"은 증거가 아님 | 알려지지 않은 시스템과 미탐지 침해가 남아있을 수 있음 | 자산 인벤토리, 로그, 복구 절차 |
배경: PHP2shell과 지원되지 않는 버전의 위험
2026년 10월 21일, PHP 개발팀은 PHP2shell로 알려진 두 가지 치명적 취약점에 대한 보안 업데이트를 릴리스했습니다. 악용 시 인증되지 않은 원격 공격자가 코드를 실행할 수 있습니다. 10월 26일, 미국 사이버보안 및 인프라 보안국(CISA)은 두 취약점을 Known Exploited Vulnerabilities (KEV) 카탈로그에 추가했습니다. KEV 카탈로그는 실제 악용 증거가 있는 취약점을 나열합니다.
10월 27일 Wiz Research의 업데이트에 따르면, 자사 텔레메트리에서 관련 시도가 제한적으로 관찰되었으나 성공 사례는 관찰되지 않았습니다. 다만 파트너들이 비공개로 작동하는 익스플로잇을 공유했다고 밝혔습니다. 하나의 텔레메트리 소스에서 성공 사례가 관찰되지 않았다는 것이 다른 곳에서 악용이 발생하지 않았다는 증거는 아닙니다.
PHP2shell은 지원 종료(EOL) 문제만은 아닙니다. 지원되는 PHP 브랜치도 패치 전 릴리스를 실행 중이라면 취약할 수 있습니다. 반대로, 브랜치가 더 이상 지원되지 않을 때는 새로 발견된 취약점에 대해 PHP 프로젝트에서 수정을 제공하지 않을 수 있습니다. 조직은 지원되는 릴리스로 마이그레이션하거나, 운영체제/호스팅 제공자가 별도로 유지관리하는 패키지를 제공하는지, 그 지원이 무엇을 포함하는지 확인해야 합니다.
1. 오래된 버전을 그대로 두는 위험
PHP(또는 범용 소프트웨어)의 버전은 무기한 지원되지 않습니다. PHP 프로젝트는 활성 지원 기간과 보안 지원 기간을 제공합니다. 브랜치가 지원 종료(EOL)에 도달하면 PHP 프로젝트에서 더 이상 지원하지 않습니다. 애플리케이션은 해당 날짜에 반드시 중단되는 것은 아닙니다. 이것이 지원되지 않는 설치를 간과하기 쉬운 이유입니다: 유지관리 옵션이 축소되었음에도 정상적으로 작동하는 것처럼 보입니다.
PHP 지원 상태 확인
2026년 10월 28일 기준, PHP 8.2~8.5는 PHP 프로젝트의 지원 브랜치 범위 내에 있습니다. 그러나 PHP 8.2의 보안 지원은 2026년 12월 31일에 종료될 예정입니다. 지원되는 브랜치를 사용하는 조직도 지원 창이 언제 닫히는지 알고 다음 업그레이드를 긴급해지기 전에 계획해야 합니다.
| PHP 브랜치 | 공식 보안 지원 종료일 | 2026년 10월 28일 기준 상태 |
|---|---|---|
| PHP 5.6 | 2018년 12월 31일 | 지원 종료 |
| PHP 7.4 | 2022년 11월 28일 | 지원 종료 |
| PHP 8.0 | 2023년 11월 26일 | 지원 종료 |
| PHP 8.1 | 2025년 12월 31일 | 지원 종료 |
| PHP 8.2 | 2026년 12월 31일 | 지원 중, 보안 지원 곧 종료 |
| PHP 8.3 | 2027년 12월 31일 | 지원 중, 다음 마이그레이션 계획 필요 |
| PHP 8.4 | 2028년 12월 31일 | 지원 중 |
| PHP 8.5 | 2029년 12월 31일 | 지원 중 |
출처: PHP 프로젝트의 Supported Versions 및 Unsupported Branches 페이지. 일부 운영체제 배포판, 호스팅 제공자, 상용 벤더가 자체 연장 유지보수를 제공할 수 있습니다. 범위, 영향 패키지, 책임 경계를 확인하세요.
오래된 버전을 계속 사용하는 주요 위험
| 위험 | 발생 가능한 상황 | 비즈니스/경영 영향 |
|---|---|---|
| 업스트림 수정 없음 | 새로 공개된 취약점에 대해 해당 브랜치의 공식 수정이 제공되지 않을 수 있음 | 알려진 미해결 위험과 함께 운영을 계속해야 할 수 있음 |
| 알려진 취약점 노출 | 공격자가 공개 정보와 자동 스캐닝을 사용하여 취약한 시스템 탐색 | 웹사이트 변조, 데이터 노출, 비즈니스 중단 발생 가능 |
| 관련 소프트웨어 업데이트 어려움 | 오래된 PHP 런타임이 CMS, 프레임워크, 플러그인, 라이브러리 업그레이드를 차단 | 마이그레이션 작업이 더 비싸지고 옵션이 제한됨 |
| 유지보수 역량 침식 | 문서 누락, 원래 개발자 퇴사, 유지보수 계약 종료 | 대응 시간과 비용이 더욱 증가 |
오래된 릴리스의 공개 취약점 수를 세는 것만으로는 충분한 위험 평가가 아닙니다. 수치는 데이터베이스와 포함 기준에 따라 달라집니다. 경영진이 답해야 할 질문은 더 실용적입니다: 시스템이 지원되는가? 수정을 적용할 수 있는가? 지속적으로 유지보수할 팀이나 벤더가 있는가?
왜 오래된 PHP 설치가 방치되는가
계속 작동하는 시스템은 위험을 덜 보이게 만듭니다. 서비스 중단이 어려워서, 업그레이드가 오래된 애플리케이션 코드를 깨뜨릴 수 있어서, 또는 원래 구현을 이해하는 사람이 아무도 없어서 업데이트가 연기됩니다. 연기는 위험을 제거하지 않습니다; 마이그레이션이 긴급해질 때까지 작업이 누적될 수 있습니다.
위험 및 영향 경로:
[ PHP 브랜치 지원 종료 ]
|
v
[ 업스트림 수정 더 이상 제공되지 않을 수 있음 ]
|
v
[ 알려진 취약점 잔존 + 관련 컴포넌트 업데이트 어려움 ]
|
v
[ 침해, 중단, 장기 복구 위험 증가 ]
마이그레이션 및 완화 경로:
[ 자산 인벤토리 및 마이그레이션 계획 ]
|
v
[ 담당자, 예산, 마감일 할당 ]
|
v
[ 지원되는 릴리스로 마이그레이션 및 유지보수 ]
|
v
[ 잔여 위험 정기 검토 ]
2. PHP 취약점 대응에서 실제 사례가 가르쳐주는 것
사례 1: CVE-2024-4577 관련 웹셸
2024년 7월, 일본 정보처리진흥협회(IPA)는 CVE-2024-4577이 일본의 여러 조직에서 악용되었으며, 영향받은 웹 서비스에 웹셸이 설치되었다고 보고했습니다. 국제 자문도 이 취약점의 활성 악용을 보고했습니다.
웹셸은 공격자가 원격으로 서버에 명령을 내리거나 서버를 운영할 수 있게 해주는 손상된 웹 서버의 악성 코드입니다. 추가 활동을 위한 발판을 제공할 수 있으며, 다른 시스템으로의 이동 시도나 손상된 서버를 다른 공격의 인프라로 사용하는 것을 포함합니다. 결과는 원래 웹사이트의 변조를 넘어설 수 있습니다.
이 예시는 모든 오래된 PHP 설치가 침해될 것이라는 의미는 아닙니다. 패치되지 않은 악용 가능한 결함이 있는 원격 접근 가능한 시스템은 수정이 제때 이루어지지 않을 때 진입점이 될 수 있다는 것을 보여줍니다. CVE-2024-4577에는 특정 조건이 있었습니다: Windows에서 CGI 모드로 실행되는 특정 PHP 버전, 특히 Apache와 특정 코드 페이지 구성. 모든 PHP 배포에 동일하게 영향을 미치지 않았습니다. 모든 취약점과 마찬가지로, 팀은 언어 이름만으로 가정하지 않고 영향받는 버전, 운영체제, 실행 구성을 확인해야 합니다.
사례 2: PHP2shell — 지원 브랜치에서도 긴급 수정이 필요할 수 있음
PHP2shell은 두 가지 취약점으로 구성됩니다: CVE-2026-109618 (메모리 부족 오류 처리 관련)과 CVE-2026-109619 (요청 처리 및 오래된 내부 상태 관련). 성공적인 악용은 원격의 인증되지 않은 당사자가 코드를 실행할 수 있게 합니다.
2026년 10월 21일, PHP 프로젝트는 다음 버전에서 수정을 릴리스하고 업데이트를 강력히 권고했습니다.
| PHP 브랜치 | PHP2shell 수정 포함 최소 릴리스 | 지원 참고 |
|---|---|---|
| PHP 8.2 | 8.2.35 | 보안 지원 2026년 12월 31일 종료 예정 |
| PHP 8.3 | 8.3.36 | 보안 지원 2027년 12월 31일 종료 예정 |
| PHP 8.4 | 8.4.27 | 보안 지원 2028년 12월 31일 종료 예정 |
| PHP 8.5 | 8.5.12 | 보안 지원 2029년 12월 31일 종료 예정 |
| PHP 8.1 이하 | 브랜치 및 벤더 상태 확인 | PHP 프로젝트에서 더 이상 지원하지 않음; 마이그레이션 계획 또는 별도 유지관리 벤더 지원 확인 |
출처: PHP 공식 2026 릴리스 아카이브, PHP 지원 상태 페이지, Wiz 보안 연구. 이는 수정을 포함하는 최소 버전입니다. 배포 전 관련 운영체제 배포판, 호스팅 제공자, 벤더에서 제공하는 현재 릴리스를 확인하세요.
Wiz Research에 따르면 PHP 5.4부터의 버전이 두 취약점 중 적어도 하나에 영향을 받았습니다. 지원되지 않는 브랜치의 경우 PHP 프로젝트의 일반 릴리스 프로세스에서 필요한 수정을 제공하지 않습니다; 따라서 지원되는 브랜치로의 마이그레이션 또는 명확하게 문서화된 유지보수가 있는 제품으로의 전환이 필요할 수 있습니다.
2026년 10월 26일, CISA는 두 CVE를 KEV 카탈로그에 추가했습니다. 10월 27일, Wiz는 자사 텔레메트리에서 관찰된 제한적 시도, 해당 시점 텔레메트리에서 관찰된 성공 사례 없음, 비공개로 작동하는 익스플로잇을 공유한 파트너 정보를 설명하는 업데이트를 발표했습니다. 이것들은 다른 종류의 관찰입니다; 조직은 현재 자문을 따르고 특정 대상에 대한 성공적인 공격의 공개 보고를 기다리며 수정을 지연하지 않아야 합니다.
경영진이 이 사례에서 얻어야 할 것
심각한 취약점이 공개되면 엔지니어는 영향받는 모든 시스템을 식별하고, 수정을 적용하고, 테스트하고, 시간 압박 하에 전환을 준비해야 할 수 있습니다. 이 작업은 기술적 기술 이상에 의존합니다: 비즈니스 팀이 유지보수 창을 승인해야 하고, 벤더가 조율해야 하고, 인력과 예산이 필요합니다.
따라서 엔지니어에게 "업데이트를 적용하라"고 지시하는 것만으로는 충분하지 않습니다. 경영진은 긴급 작업을 우선순위로 지정하고 수행에 필요한 자원을 제공할 수 있는 의사결정 프로세스를 제공해야 합니다.
3. 심층 방어(Defense in Depth)의 현실
보안의 기본 원칙 중 하나는 심층 방어입니다. 집을 생각해 보세요: 현관문에 튼튼한 자물쇠가 있어도 뒷문이나 창문이 열려 있으면 안전하지 않습니다. 오늘 아무도 침입하지 않았다는 사실이 내일의 안전을 보장하지 않습니다.
지원되지 않는 PHP 릴리스를 계속 실행하는 것은 수리 옵션이 줄어든 상태에서 약점을 그대로 두는 것과 유사합니다. 인터넷에 노출된 시스템의 경우, 취약한 서비스가 지속적인 스캐닝을 통해 발견될 수 있다고 가정하고 가능한 모든 곳에서 약점을 줄여야 합니다.
| 방어 계층 | 예시 조치 | 도움이 되는 것 — 한계 |
|---|---|---|
| 패치 및 유지보수 | PHP, CMS, 프레임워크, 플러그인, 라이브러리를 지원되는 릴리스로 유지 | 알려진 취약점 수정; 변경은 여전히 테스트 필요 |
| 노출 제한 | 불필요한 서비스 비활성화, 관리 인터페이스 접근 제한 | 공격 표면 감소, 그러나 패치를 대체하지 못함 |
| 탐지 및 모니터링 | 접근 로그, 예상치 못한 파일/계정, 비정상 네트워크 활동 검토 | 의심스러운 활동 식별 도움, 그러나 모니터링만으로는 침해 방지 불가 |
| 백업 및 복구 | 백업 보호, 복원 및 환경 재구축 절차 테스트 | 복구 지원; 백업이 있다고 해서 성공적으로 복원할 수 있다는 증거는 아님 |
| 사고 대응 | 범위 조사, 증거 보존, 적절한 경우 자격 증명 교체, 의도적 복구 결정 | 의심스러운 침해를 항상 재시작이나 패치만으로 해결할 수 있는 문제로 취급하지 않도록 함 |
이러한 조치 중 어느 것도 지원되지 않는 소프트웨어를 무기한 그대로 두는 이유가 되지 않습니다. 네트워크 제한과 강화된 모니터링은 위험을 일시적으로 줄일 수 있지만 장기적인 안전을 보장하지 않습니다. 임시 조치와 함께 지원되는 환경으로의 마이그레이션 계획을 병행하세요.
4. 경영진과 관리자가 지금 확인해야 할 것
PHP 업그레이드와 마이그레이션을 엔지니어링 팀에만 맡기지 마세요. 조직은 다음 항목을 가시화하고, 담당자를 할당하고, 마감일을 설정해야 합니다. 모든 문제를 즉시 해결할 수는 없지만, 불확실성이 담당자 없는 상태로 남아서는 안 됩니다.
| 우선순위 | 질문 | 예상 증거 또는 결정 | 주 담당자 |
|---|---|---|---|
| 긴급 | PHP2shell에 영향받는 시스템이 있는가? | 설치된 버전, 노출, 패치 상태 목록 | 시스템 관리자 및 유지보수 제공자 |
| 긴급 | 운영 중인 모든 웹 시스템을 알고 있는가? | 기업, 채용, 캠페인, 브랜드, 자회사, 서브도메인, 벤더 관리 사이트 인벤토리 | IT 리더십 및 비즈니스 부서 |
| 높음 | 지원되지 않는 PHP 브랜치가 아직 사용 중인가? | 버전, 지원 종료일, 비즈니스 중요도, 인터넷 노출 | 시스템 관리자 |
| 높음 | 마이그레이션 담당자와 마감일이 명확한가? | 지명된 담당자, 목표 날짜, 테스트 리드, 전환 승인 권한 | IT 및 비즈니스 서비스 소유자 |
| 높음 | 마이그레이션을 위한 인력과 예산이 있는가? | 승인된 계획, 자금, 내부 팀과 공급업체 간 책임 | 경영진 및 관리자 |
| 지속 | 업그레이드 후 시스템을 계속 유지보수할 수 있는가? | 정기 지원 수명 주기 검토, 업데이트 정책, 복구 테스트 기록 | IT 리더십 및 시스템 관리자 |
1. PHP가 어디에 사용되는지 알고 있는가?
메인 기업 웹사이트만이 아닙니다. 채용 및 캠페인 사이트, 제품 및 브랜드 사이트, 자회사 사이트, 오래된 서브도메인, 외부 에이전시나 호스팅 제공자가 유지보수하는 시스템을 포함하세요. 이러한 자산은 다른 소유자와 유지보수 계약을 가질 수 있습니다. PHP는 WordPress, Drupal, Joomla를 포함한 널리 배포된 많은 콘텐츠 관리 시스템에서 사용되므로, 인벤토리 작업은 런타임뿐만 아니라 애플리케이션과 그 의존성도 포함해야 합니다.
W3Techs에 따르면 PHP는 서버 사이드 프로그래밍 언어 시장 점유율 약 70%로 1위를 차지하고 있으며, 2위와 큰 차이가 있습니다. PHP를 사용하는 웹사이트 중 2개 중 1개는 더 이상 지원되지 않는 버전에 의존하고 있습니다.
2. 요청을 실제로 처리하는 버전을 확인했는가?
명령줄 셸에서 보고되는 PHP 버전은 웹 요청을 처리하는 데 사용되는 버전과 다를 수 있습니다. 클라우드 제공자, 호스팅 회사, 또는 유지보수 벤더와 함께 실제 호스팅 환경의 런타임을 확인하세요. 서비스가 여러 인스턴스나 실행 환경을 사용하는 경우 한 머신에서 관찰된 버전 번호에 의존하지 마세요.
3. PHP2shell 노출 및 패치 상태를 확인했는가?
실행 환경을 PHP 공식 자문의 영향받는 및 수정된 버전과 비교하세요. PHP 8.1 이하의 경우 업스트림 패치가 제공되지 않을 것이라고 가정하지 마세요: 지원 상태를 확인하고 지원되는 릴리스 또는 명확하게 문서화된 유지보수가 있는 제품으로의 마이그레이션을 계획하세요. 업데이트가 완료될 때까지 노출 제한을 포함한 적절한 임시 조치를 고려하세요. 효과적인 조치를 취할 수 없는 경우, 잠재적 피해와 비즈니스 영향에 따라 경영진은 외부 접근 차단 또는 서비스 일시 중단을 고려해야 할 수 있습니다.
4. 자원, 마감일, 의사결정 권한이 갖추어져 있는가?
"결국 업그레이드할 것이다"라는 진술은 추가 지연을 초래합니다. 책임 있는 담당자를 지명하고 마감일, 예산, 테스트 책임, 종료 또는 전환 승인 권한을 설정하세요. 레거시 시스템의 경우 지속적인 유지보수와 다른 옵션(리팩토링, 제품 교체, 기능 축소, 공개 접근 종료, 시스템 폐기)을 비교하세요. 결정은 시스템의 현재 비즈니스 목적과 안전하게 유지보수할 수 있는지 여부를 반영해야 합니다.
5. 마이그레이션 후 시스템을 계속 유지보수할 수 있는가?
일회성 업그레이드만으로는 다음 지원 종료일에 같은 문제가 반복되지 않습니다. PHP와 그 의존성의 지원 수명 주기를 추적하고, 업데이트와 마이그레이션을 계획, 테스트, 배포하는 반복 가능한 프로세스를 수립하세요. 내부 팀이나 공급업체가 시스템을 유지보수할 수 없다면, 계속 운영해야 하는지 재고려하세요.
결론: 지원 종료는 IT 문제만이 아니다
PHP 지원 종료는 오래된 버전을 실행하는 기술적 문제만이 아닙니다. 패치되지 않은 취약점에 대한 잠재적 노출, 공격의 비즈니스 영향, 업그레이드 및 마이그레이션 비용, 시스템을 유지보수할 수 있는 사람의 가용성을 포함하는 조직적 위험입니다.
PHP2shell은 두 가지 현실을 보여줍니다: 지원되는 브랜치도 취약한 릴리스가 사용 중이면 긴급 조치가 필요할 수 있고, 지원되지 않는 브랜치는 문제를 해결하는 데 필요한 수정을 받지 못할 수 있습니다. 조직은 영향받는 자산을 식별하고, 적절한 수정을 적용하고, 필요한 경우 노출을 제한하고, 정상 운영의 일부로 신뢰할 수 있는 복구 역량을 유지해야 합니다.
경영진과 관리자는 엔지니어에게 단순히 업그레이드하라고 지시해서는 안 됩니다. 예산, 인력, 권한, 마이그레이션이 어려운 시스템에 대한 명확한 결정을 제공해야 합니다. 엔지니어는 실제 런타임과 그 의존성을 식별하고, 위험과 옵션을 설명하고, 업데이트와 마이그레이션을 위한 안전한 절차를 수립해야 합니다.
"아직 작동한다"는 "미래에 안전하게 운영할 수 있다"는 의미가 아닙니다. 지원 종료일을 알고, 위험을 평가하고, 조치를 취하는 것이 고객 신뢰와 비즈니스 연속성을 보호하는 필수 단계입니다.
참고 자료
아래 출처 목록은 글의 번호 인용을 뒷받침합니다. 게시하거나 조치를 취하기 전에 공식 자문과 벤더 릴리스 노트를 다시 확인하세요.
- The PHP Group, "PHP 2026 News Archive" — 2026년 10월 21일 PHP 8.2.35, 8.3.36, 8.4.27, 8.5.12 보안 릴리스, CVE-2026-109618 및 CVE-2026-109619 대응. 공식 PHP 릴리스 아카이브
- Wiz Research, "PHP2Shell: AI uncovers critical RCE vulnerabilities affecting 70% of the Internet" (2026년 10월 21일) 및 "PHP2Shell: Exploitation Attempts and Remediation Trends" (2026년 10월 27일) — 취약점 연구, 영향받는 버전 분석, 관찰된 악용 활동. 초기 연구 · 관찰된 활동 후속 보고
- CISA, "CISA Adds Two Known Exploited Vulnerabilities to Catalog" (2026년 10월 26일) — CVE-2026-109618 및 CVE-2026-109619를 KEV 카탈로그에 추가. CISA 발표
- The PHP Group, "Supported Versions" — PHP의 활성 지원 및 보안 지원 수명 주기와 현재 지원 브랜치. 공식 지원 일정
- The PHP Group, "Unsupported Branches" — 지원되지 않는 PHP 브랜치의 지원 종료일과 마지막 릴리스. 공식 EOL 목록
- IPA (일본 정보처리진흥협회), "Attacks Targeting PHP Vulnerability CVE-2024-4577" (2024년 7월 5일, 7월 12일 업데이트), CERT-EU, "Vulnerabilities in PHP" (Security Advisory 2024-058, 2024년 6월 13일) — CVE-2024-4577 악용 및 웹셸 관련 보고. IPA 보고서 (일본어) · CERT-EU 자문 (영어)
- CISA 및 파트너 기관, "#StopRansomware Guide" — 백업 보호, 복구 준비, 사고 대응에 대한 일반 가이드. CISA 가이드
- W3Techs — 웹사이트용 PHP 사용 통계, 2026년 10월 28일. PHP 사용 통계
- Google Cloud, "Responding to core PHP vulnerabilities CVE-2026-109618 and CVE-2026-109619" — 클라우드 환경에서의 대응 가이드. Google Cloud 블로그
- Palo Alto Networks Unit 42, "Threat Brief: Critical Vulnerabilities in PHP" — 위협 브리프. Unit 42 블로그
- Tenable, "php2shell (CVE-2026-109618, CVE-2026-109619): FAQ" — 자주 묻는 질문. Tenable 블로그
- Huntress, "php2shell, Leaked Critical PHP Vulnerabilities" — 유출된 취약점 분석. Huntress 블로그
- Sophos, "Advisory: PHP2Shell Vulnerabilities" — 보안 자문. Sophos 자문
- Sansec, "PHP2Shell" — PHP 5.4 이후 버전 영향 분석. Sansec 연구
- Aikido, "PHP2Shell: How to fix PHP RCE with patches and free tooling" — 패치 및 무료 도구 가이드. Aikido 블로그
- Wikipedia, "PHP2Shell" — 취약점 개요. Wikipedia
이 글의 버전 상태 및 PHP2shell 관련 내용은 2026년 10월 28일 기준 공개 정보를 반영합니다. 특정 배포의 경우 소프트웨어, 운영체제, 호스팅, 제품 벤더의 최신 릴리스와 지원 조건을 확인하세요.
원문: PHP End-of-Life Is a Business Risk: What "PHP2shell" Reveals About Patch Responsibility (DEV Community, by nabbisen)