PHP 취약점 대응: WAF로 먼저 방어하고, 서비스를 유지하며 패치하라

By PLURA

🧩 PHP 취약점 개요

PHP 취약점 대응의 기본 원칙은 웹방화벽에서 공격을 신속히 통제하고, 방어 효과를 확인하면서 서비스를 유지하며 PHP 패치를 병행하는 것입니다.

취약점 패치는 반드시 필요합니다. 그러나 패치 공개, 호환성 확인, 배포와 실행 환경 반영에는 시간이 필요합니다. 이 시간을 보호된 상태로 운영할 수 있도록 만드는 것이 웹방화벽의 중요한 역할입니다.

2026년 10월 21일, PHP 개발팀은 인증 없이 원격 코드 실행으로 이어질 수 있는 두 가지 중대한 취약점에 대한 보안 업데이트를 공개했습니다. 이 글은 PHP2Shell로 알려진 이번 취약점의 공식 자료와 공개 대응 사례를 바탕으로, 서비스 운영과 공격 차단을 함께 고려하는 대응 방법을 설명합니다.1

항목 내용
취약점 CVE-2026-109618, CVE-2026-109619
문제 발생 영역 PHP 자체의 메모리 처리 및 요청 간 내부 상태 관리
주요 위험 원격 코드 실행, 민감한 프로세스 메모리 노출, 서비스 장애
점검 대상 웹 요청을 처리하는 PHP 환경. Apache mod_php, PHP-FPM 등 실행 방식별 조건 확인 필요
웹방화벽 대응 비정상 요청 구조 제한, 검증된 공격 패턴 차단, 요청·응답 연계 분석
서버 대응 PHP·웹서버의 이상 행위 탐지, 침해 징후에 따른 차단·격리
기본 운영 방향 WAF 보호 정책을 신속히 적용하고 서비스 유지와 PHP 패치를 병행
제한·중단 판단 통제 후 남는 침해 위험과 서비스 중단 피해를 비교해 범위 결정
근본 조치 수정된 PHP 또는 보안 수정이 반영된 배포판 패키지 적용

WAF로 먼저 방어하고, 보호된 서비스를 운영하면서 PHP 패치를 진행합니다. 위험을 충분히 통제하기 어려운 서비스는 필요한 범위에서 제한하거나 격리합니다. 보안 대응의 목표에는 공격 차단과 업무 연속성이 함께 포함됩니다.

🌐 Cloudflare 사례가 보여준 대응 방식

Cloudflare는 이번 PHP2Shell 취약점에 대한 WAF 보호 정책을 배포하고, 같은 HTTP 거래의 요청과 응답을 연계하는 탐지를 적용했다고 발표했습니다. 탐지 결과에 따라 응답이 요청자에게 전달되기 전에 차단할 수 있도록 했으며, 동시에 고객에게 WAF 보호를 유지하면서 PHP 보안 업데이트를 신속히 적용할 것을 권고했습니다.2

이 사례에서 참고할 운영 원칙은 분명합니다.

  1. 지금 적용할 수 있는 방어 조치를 먼저 가동합니다. 취약점 대응 정책을 배포하고 공격 노출을 줄입니다.
  2. 운영 중의 방어 효과를 확인합니다. 요청·응답과 차단 결과, 정상 서비스 영향을 관찰합니다.
  3. PHP 패치를 동시에 추진합니다. 담당자와 적용 일정을 정하고 실제 운영 환경에 반영될 때까지 확인합니다.

여기서 ‘먼저’는 즉시 가동할 수 있는 방어의 우선순위를 뜻합니다. WAF 정책 적용과 패치 준비·배포는 병행해야 합니다.

이러한 접근은 웹방화벽을 이용한 가상 패치(Virtual Patching)의 목적과 맞닿아 있습니다. OWASP도 가상 패치를 공급자 패치가 나오거나 검증·적용되는 동안 위험을 줄이고, 중단하기 어려운 중요 서비스를 보호하는 방법으로 설명합니다.3

⚓ 로테르담 항만 웹사이트의 일시 중단은 어떻게 이해해야 할까요?

ANP 보도에 따르면 로테르담 항만공사는 PHP 취약점에 대한 예방 조치로 공개 웹사이트를 일시 중단했습니다. 당시 대변인은 항만의 서비스나 운영 절차에 영향이 없었으며, 구체적인 보안 문제가 발생했다는 징후도 없다고 설명했습니다.4

네덜란드 NCSC 역시 당시 미업데이트 시스템을 예방적으로 오프라인 상태로 유지하도록 권고했습니다. 이러한 현지 대응 지침도 사건을 이해하는 데 필요한 맥락입니다.5

공개된 정보로 보면, 해당 조치는 항만 운영을 유지하면서 공개 웹사이트의 노출을 줄인 선택으로 평가할 수 있습니다. 다만 내부 WAF 구성과 검증 상태, 실제 의사결정 문서는 확인되지 않았으므로 구체적인 판단 근거까지 단정할 수는 없습니다.

이 사례가 모든 웹사이트의 대응 기준을 정해 주지는 않습니다. 일반 웹서비스에는 WAF로 즉시 적용 가능한 보호를 제공하고, 서비스를 운영하면서 패치하도록 안내하는 방식이 우선되어야 합니다. 침해 시 파급효과가 매우 크고 현재의 방어 조치로 위험을 충분히 낮추기 어려운 환경에서는, 로테르담 사례와 같은 예방적 중단을 선택할 수 있습니다.

⚖️ 서비스 유지와 중단을 결정하는 기준

판단 기준은 해당 서비스의 공격 노출, 방어 조치의 효과, 침해 시 피해, 중단 시 피해입니다. 기관의 중요도만으로 중단 여부를 결정하면 업무 연속성에 필요한 고려가 빠질 수 있습니다.

아래 표는 이 글에서 제안하는 운영 판단 기준입니다. ‘1급 위험’과 같은 공식 등급을 부여한 분류는 아닙니다.

서비스 상태와 위험 권장 대응 운영 방향
적용 가능한 WAF 정책이 검증되고 남은 위험을 관리할 수 있음 정책 적용, 요청·응답 및 서버 관찰, PHP 패치 병행 서비스 유지
특정 기능·경로의 노출을 추가로 줄여야 함 앞단에서 해당 기능·경로·접근 대상을 제한하고 패치 가능한 서비스 유지
침해 파급효과가 크고 통제 후에도 남는 위험이 중단 피해보다 큼 취약한 서비스·인스턴스를 최소 범위로 격리 선택적 일시 중단
실제 침해나 방어 우회로 인한 피해가 확인됨 영향받은 시스템 격리, 조사·복구, 추가 공격 차단 침해 확산 억제 우선

정책 검증이 부족한 부분은 접근 제한이나 기능 축소로 노출을 줄이면서 판단해야 합니다. 격리 범위는 취약한 PHP로 들어오는 공격 경로를 실제로 끊을 수 있을 만큼 충분해야 합니다.

정적 안내 페이지를 활용할 때는 취약한 PHP를 실행하지 않는 별도 경로로 제공해야 합니다. Apache mod_php에서는 애플리케이션 코드가 실행되기 전에 취약점이 악용되는 경로가 확인되었으므로, PHP로 만든 점검 화면이나 애플리케이션 로그인만으로 접근을 막았다고 판단할 수 없습니다.1

💡 PHP 자체의 취약점도 웹방화벽으로 대응할 수 있나요?

HTTP 요청을 통해 악용되는 경로라면, 웹방화벽에서 해당 요청을 검사하고 차단하는 방식으로 대응할 수 있습니다.

서버 앞단에 가상 패치 정책을 적용하면 애플리케이션을 즉시 수정하기 어려운 상황에서도 공격 노출을 줄일 수 있습니다. 실제 효과는 적용된 규칙, 검사 범위, 우회 경로 통제를 기준으로 확인해야 합니다.3

이번 PHP2Shell에서는 요청의 문자열뿐 아니라 요청이 PHP 내부에서 어떤 구조로 처리되는지를 고려해야 합니다. 파일 업로드에 사용하는 multipart/form-data, 입력 필드 수, 중첩된 입력 구조 등이 중요한 검사 대상입니다.6

운영에서는 다음 세 가지를 함께 확인해야 합니다.

  1. PHP에 전달하기 전: 공격으로 확인된 요청과 서비스에 불필요한 입력을 차단합니다.
  2. 요청을 처리한 뒤: 응답 헤더·본문에서 정보 노출이나 비정상 결과를 확인합니다.
  3. 서버 내부: 명령 실행, 파일 생성, 외부 연결 등 후속 행위를 확인하고 대응합니다.

이 과정의 효과는 적용된 규칙과 검사 범위에 따라 달라집니다. PHP 개발팀은 이번 취약점의 완전한 해결책으로 보안 업데이트를 명시하고 있습니다.1

⚙️ 공격 메커니즘

① 메모리 부족 처리 과정의 오류 — CVE-2026-109618

PHP가 요청을 처리하는 도중 메모리 부족이 발생하면, 초기화가 끝나지 않은 내부 데이터가 남을 수 있습니다. 이후 요청을 정리하는 과정에서 이를 정상 데이터처럼 사용하면서 원격 코드 실행으로 이어질 수 있습니다.

여기서 중요한 점은 파일 하나의 크기만으로 위험을 판단할 수 없다는 것입니다. multipart 안의 많은 헤더, 빈 파일 입력, 깊게 중첩된 필드 이름도 PHP가 사용하는 메모리를 늘릴 수 있습니다.6

② 이전 요청의 내부 상태가 다음 요청에 영향을 주는 오류 — CVE-2026-109619

요청 처리가 끝난 뒤 해제된 메모리를 가리키는 내부 상태가 PHP 작업 프로세스에 남을 수 있습니다. 같은 프로세스가 다음 요청을 처리하면서 이 상태를 다시 사용하면 정보 노출이나 원격 코드 실행으로 이어질 수 있습니다.

여러 요청과 서버 내부 상태가 관계되므로, 요청 한 건의 특정 문자열만으로 전체 공격 경로를 판단하기 어렵습니다.7

❗ 기존 점검만으로 놓치기 쉬운 부분

점검 방식 추가로 확인해야 하는 이유
SQL 인젝션·명령어 문자열만 검사 이번 취약점은 PHP의 메모리·요청 처리 문제이므로, 알려진 문자열 검사만으로 대응 범위를 판단할 수 없음
업로드 파일 크기만 제한 전체 본문 크기뿐 아니라 필드·파트·헤더 수와 중첩 구조도 메모리 사용에 영향을 줄 수 있음
요청 URL과 상태 코드만 확인 요청 본문의 구조와 응답 헤더·본문에 나타난 결과를 함께 확인해야 함
웹셸 파일 유무만 점검 별도의 웹셸이나 명령 실행 없이 프로세스 메모리 정보가 노출되는 경로도 존재함

앞의 두 항목은 PHP 공식 취약점 설명에, 마지막 항목은 공동 연구진의 공개 분석에 근거합니다.678

또한 HTTP 500 오류나 PHP 프로세스의 재시작만으로 침해를 확정할 수는 없습니다. 해당 시점의 요청, 응답, 서버 오류와 행위를 연결해 판단해야 합니다.8

🛡️ 웹방화벽에서 적용할 대응 전략

① 요청 본문의 크기와 구조를 함께 제한합니다

PHP 공식 권고를 바탕으로, WAF와 리버스 프록시에서 다음 정책의 적용 가능 여부를 점검합니다. 제한값은 서비스의 정상적인 로그인·게시물 작성·파일 업로드를 기준으로 정합니다.6

검사 항목 대응 방향
multipart 허용 경로 업로드 등 multipart가 필요 없는 경로에서는 차단하고, 필요한 경로만 허용
실제 요청 본문 크기 선언된 길이뿐 아니라 전송 형식 해석·디코딩 후 실제 본문 크기를 기준으로 제한
입력 필드·multipart 파트 수 정상 서비스에 필요한 개수를 기준으로 상한 설정
각 파트 내부 헤더 수 비정상적으로 많은 헤더와 잘못된 구성을 검사
입력의 중첩 깊이 과도하게 깊은 배열·중첩 구조 제한
길이를 확정하기 어려운 요청 유효한 Content-Length가 없어도 실제 수신량에 제한이 적용되는지 확인

위 표는 구현·검증해야 할 정책입니다. 제품에 따라 제공되는 검사 항목과 설정 방법이 다르므로, 현재 운영 중인 WAF에서 실제 지원 여부를 확인해야 합니다.

특히 본문 검사 한도를 넘거나 파싱에 실패한 요청이 자동으로 통과하지 않는지 점검합니다. 정상 대용량 업로드에는 경로별 정책을 적용하되, 해당 경로 전체가 검사에서 제외되지 않도록 설계합니다.

② 요청과 응답을 같은 거래로 연결합니다

공격 여부를 판단할 때는 무엇을 요청했는지와 서버가 무엇을 반환했는지를 함께 확인해야 합니다.

확인 위치 분석할 내용
요청 메서드·헤더 메서드, Content-Type, Cookie, 본문 전달 방식
요청 본문 업로드 구성, 입력 필드, 중첩 구조, 의심스러운 데이터
응답 상태·헤더 상태 코드, Content-Type, 비정상적인 Set-Cookie 값
응답 본문 예상하지 못한 데이터, 오류 내용, 정보 노출 징후

공동 연구진은 비정상적으로 크거나 형식이 잘못된 PHPSESSID 응답 쿠키 등을 조사 지표로 제시했습니다. 따라서 이번 대응에서는 응답 본문과 응답 헤더를 모두 확인해야 합니다.8

Cloudflare의 대응은 이러한 연계 분석의 실제 활용 사례입니다. 운영자는 사용하는 제품에서 요청·응답 중 무엇을 검사하고, 어떤 탐지 결과가 실제 차단으로 연결되는지 확인해야 합니다.9

③ 탐지 시점과 차단 시점을 구분합니다

처리 방식 차단·대응 가능한 시점 의미
요청 단계 인라인 차단 PHP에 요청을 전달하기 전 해당 공격 요청의 서버 도달을 차단
응답 단계 인라인 차단 서버 처리 후, 응답이 외부로 전달되기 전 검사한 응답의 민감정보 전달을 억제
미러링·로그 기반 비동기 분석 원래 요청·응답이 전달된 이후일 수 있음 후속 요청 차단, 서버 조사·격리에 활용

응답 차단은 서버에서 이미 발생한 명령 실행이나 파일 변경을 되돌리지 못합니다. 응답을 탐지한 경우에도 서버의 침해 여부를 함께 확인해야 합니다.9

따라서 “요청·응답 분석을 제공한다”는 설명과 함께, 검사 대상, 본문 처리 한도, 인라인 차단 지원 여부, 실제 정책 적용 상태까지 확인하는 것이 좋습니다.

④ 실제 차단 경로를 확인합니다

규칙을 적용한 뒤에는 다음 운영 조건을 확인합니다.

  • HTTPS 요청·응답을 실제로 검사할 수 있는 지점에서 WAF가 동작하는가.
  • 원본 서버의 IP나 다른 도메인·포트로 WAF를 우회할 수 없는가.
  • 취약점 대응 정책이 필요한 대상에 차단 모드로 적용되어 있는가.
  • URL·업로드 예외가 공격 요청까지 통과시키지 않는가.
  • 정상 요청은 처리되고, 요청 단계 차단 대상은 PHP에 전달되지 않는가.

가상 패치의 검증에서는 탐지 로그뿐 아니라 실제 적용 결과와 정상 서비스 영향을 함께 확인해야 합니다.3

🔍 PLURA-XDR 기반 실전 대응

아래 내용은 공개 취약점 정보를 바탕으로 한 권장 대응 절차입니다. 해당 환경의 기능 지원, 정책 적용과 차단 효과는 실제 검증 결과를 기준으로 확인합니다.

PLURA-WAF는 지원 구성에서 웹 요청·응답을 분석하고, PLURA-EDR·SIEM과 연결해 관련 서버 행위를 확인하는 방식으로 활용할 수 있습니다. 이번 취약점에서도 웹에서 들어온 요청과 서버에서 발생한 결과를 연결하여, 보호 상태를 확인하면서 서비스를 유지하는 것이 대응의 중심입니다.1011

① 웹방화벽 정책과 수집 범위를 확인합니다

PHP 서비스를 제공하는 호스트와 URL을 식별하고, 요청 헤더·본문 및 응답 헤더·본문이 필요한 범위에서 분석되는지 확인합니다. URL 끝이 .php인 요청만으로 범위를 정하지 않고, 실제 PHP가 처리하는 서비스 경로를 기준으로 점검합니다.

PHP2Shell 대응 규칙이 제공되는 경우에는 적용 버전, 검사 대상, 예외와 차단 결과를 확인합니다. multipart 구조 제한 등 추가 통제는 제품의 지원 기능과 앞단 프록시 구성을 함께 검토합니다.

PLURA-WAF는 그룹별 탐지·차단 모드를 설정할 수 있으므로, 보호 대상 그룹의 실제 운영 모드를 확인해야 합니다.12

② 웹 요청·응답과 서버 행위를 연결합니다

다음은 운영자가 확인할 수 있는 분석 흐름 예시입니다.

관측 내용 함께 확인할 사항 대응 방향
비정상 multipart 요청 같은 거래의 응답, PHP 오류·중단 여부 요청 구조 제한과 취약점 정책 적용 여부 확인
비정상 응답 쿠키·정보 노출 징후 해당 요청, 응답 내용, 서버 상태 응답 인라인 차단 지원 여부 확인 및 후속 요청 대응
PHP·웹서버의 예상하지 못한 자식 프로세스 실행 명령, 부모 프로세스, 직전 웹 요청 침해 여부 판단 후 정책에 따른 차단·격리
웹 경로의 의심 파일 생성·변경 생성 주체, 파일 내용, 후속 접근·실행 웹셸 여부 조사와 접근 차단

PLURA-EDR에서는 감사 정책과 이벤트 수집 상태를 확인하여 프로세스·파일·외부 연결 등 실제 관측 데이터를 확보합니다. 지원되는 조치와 운영 정책에 따라 대응을 연결합니다.11

③ AI 분석에는 실제 판단 근거를 제공합니다

AI 분석을 사용하는 경우에는 경보 이름만 전달하기보다 요청·응답의 헤더와 본문, 검사 누락·절단 여부, 해당 시점의 서버 이벤트를 함께 제공하는 구성이 적절합니다.

이를 바탕으로 요청의 의도, 응답의 이상 징후, 후속 서버 행위를 연결해 판단하도록 설계합니다. 비동기 AI 분석이라면 분석이 끝난 뒤 실행할 수 있는 후속 차단·격리 범위도 구분해야 합니다.

이번 취약점에 대한 보호 여부는 적용된 정책과 검증 결과로 확인해야 합니다. AI 기능의 존재나 로그 수집만으로 특정 공격의 사전 차단이 입증되는 것은 아닙니다.

🛡️ MITRE ATT&CK 매핑

아래는 공격 단계와 후속 행위가 확인되었을 때 적용할 수 있는 매핑입니다. 취약한 PHP가 설치되어 있다는 이유만으로 모든 단계가 발생한 것으로 판단하지 않습니다.

전술 기법 적용할 관측 근거
Initial Access T1190 — Exploit Public-Facing Application 외부에서 공개 PHP 서비스를 대상으로 취약점을 악용하는 공격
Execution T1059 — Command and Scripting Interpreter 침투 후 셸·명령 인터프리터를 악용한 실행이 확인된 경우
Persistence T1505.003 — Web Shell 웹셸 설치와 접근·실행 등 지속적 접근을 위한 행위가 확인된 경우

출처: MITRE ATT&CK 공식 기법 설명.13

🔧 PHP 보안 업데이트 안내

WAF 보호 정책을 적용하는 즉시 PHP 업데이트 작업도 시작합니다. 담당자, 적용 대상과 완료 시점을 정하고, 보호 중인 시스템이 실제로 패치됐는지 확인할 때까지 추적합니다.

2026년 10월 22일 확인 기준, 이번 두 취약점을 수정한 PHP 공식 최초 릴리스는 다음과 같습니다.1

PHP 계열 최초 수정 버전
8.2 8.2.35
8.3 8.3.36
8.4 8.4.27
8.5 8.5.12

운영 중인 계열의 수정 버전 또는 이후 보안 릴리스를 적용합니다. 배포판이 보안 수정을 기존 버전에 반영한 경우에는 배포판의 보안 공지와 패키지 버전을 기준으로 판단해야 합니다. upstream 버전 숫자가 낮다는 이유만으로 미조치 상태라고 단정하면 안 됩니다.14

업데이트 후에는 실제 웹 요청을 처리하는 Apache·PHP-FPM 등 관련 서비스와 PHP 작업 프로세스를 재시작하거나 교체하고, 변경이 반영됐는지 확인합니다. 컨테이너 환경은 수정된 이미지로 재배포하고, 여러 인스턴스에서 이전 버전이 계속 실행되고 있지 않은지 점검합니다.14

웹 애플리케이션이나 플러그인만 업데이트해서는 PHP 런타임의 결함이 수정되지 않습니다. 호스팅 서비스를 사용한다면 운영사에 해당 CVE의 수정 적용 여부를 확인해야 합니다.1

다중 인스턴스 환경에서는 구성에 맞는 순차 교체·재배포를 검토하여 중단 영향을 줄입니다. 패치 완료 후에도 공격 시도와 서버 이상 행위를 관찰하고, 긴급 제한은 정상 서비스 영향과 보호 필요성을 다시 평가해 조정합니다.

✅ 운영자 필수 점검 사항

  • 외부 요청이 WAF를 통과하며, HTTPS 내용을 검사할 수 있는가.
  • 필요한 취약점 대응 정책이 차단 모드로 적용되어 있는가.
  • 본문 크기·multipart 구조·파싱 실패·검사 한도 초과에 대한 처리 정책을 확인했는가.
  • 요청과 응답의 헤더·본문을 연결해 분석하고, 후속 서버 행위를 확인할 수 있는가.
  • 정상 서비스 영향과 실제 차단 결과를 검증했는가.
  • 패치 담당자와 적용 일정을 정하고, 실제 실행 중인 PHP 전체에 수정이 반영됐는지 확인했는가.
  • 추가 제한이나 중단이 필요하다면 침해 위험과 업무 영향을 비교하고 필요한 범위를 정했는가.

📌 대응 원칙

일반 웹서비스는 WAF에서 취약점 악용을 신속히 통제하고, 서비스를 유지하면서 PHP 패치를 병행하는 것을 기본 방향으로 삼아야 합니다. 보안 공급자는 적용 가능한 보호 정책, 보호 범위와 검증 방법을 제공하고 패치까지 안내해야 합니다. 운영자는 실제 차단 효과와 정상 서비스 영향을 확인하며 업데이트를 완료해야 합니다.

침해 파급효과가 크고 현재의 통제로 위험을 충분히 낮추기 어려운 서비스에는 접근 제한이나 선택적 격리를 적용합니다. 로테르담과 같은 일시 중단은 그 조건과 업무 영향을 고려해 선택할 수 있는 대응입니다.

WAF는 패치가 운영 환경에 반영될 때까지의 시간을 방어합니다. PHP 패치는 취약점 자체를 제거합니다. 두 조치를 병행해 서비스의 안전성과 연속성을 확보해야 합니다.

🎬 함께 볼 영상

📚 PLURA-Blog

📚 참고 자료

  1. PHP — Security advisory: Critical remote code execution vulnerabilities, update now, 2026-10-21. ↩︎ ↩︎ ↩︎ ↩︎ ↩︎

  2. Cloudflare — Cloudflare deploys protections against php2shell vulnerability, 2026-10-21. ↩︎

  3. OWASP — Virtual Patching Best Practices. ↩︎ ↩︎ ↩︎

  4. ANP / Welingelichte Kringen — Haven Rotterdam zet site uit, verder geen impact PHP-situatie, 2026-10-21. 공개 웹사이트의 예방적 일시 중단과 항만 운영 영향이 없다는 대변인 발언을 전한 보도. ↩︎

  5. 네덜란드 NCSC — Kwetsbaarheden PHP: patches beschikbaar - update nu, 2026-10-21. 당시 미업데이트 시스템의 예방적 오프라인을 권고한 현지 대응 맥락. ↩︎

  6. PHP 공식 보안 권고 — RCE via OOM corruption / CVE-2026-109618. ↩︎ ↩︎ ↩︎ ↩︎

  7. PHP 공식 보안 권고 — RCE via stale global state / CVE-2026-109619. ↩︎ ↩︎

  8. Wiz·OpenAI·Calif 공동 공개 — PHP2Shell. ↩︎ ↩︎ ↩︎

  9. Cloudflare — Introducing full transaction detection for Cloudflare WAF, 2026-10-21. ↩︎ ↩︎

  10. PLURA-WAF 공식 제품 안내. ↩︎

  11. PLURA-EDR 공식 제품 안내. ↩︎ ↩︎

  12. PLURA 공식 문서 — 웹방화벽 관리. ↩︎

  13. MITRE ATT&CK — T1190, T1059, T1505.003. ↩︎

  14. Canonical — PHP2Shell vulnerability fixes available, 2026-10-21. ↩︎ ↩︎

Tags