CrowdStrike, PHP2Shell을 통한 위협으로부터 고객 보호

PHP 코어에서 CVE-2026-109618 및 CVE-2026-109619로 추적되는 두 가지 치명적인 메모리 손상 원격 코드 실행(RCE) 취약점이 공개되었습니다.

2026년 10월 21일 • Amit Serper • From The Front Lines

웹의 상당 부분을 구동하는 기반 엔진인 PHP 코어에서 PHP2Shell이라는 이름으로 통칭되는 두 가지 치명적인 메모리 손상 원격 코드 실행(RCE) 취약점이 공개되었습니다. CrowdStrike Falcon® 플랫폼은 두 취약점 모두에 대해 악용 이후 활동을 기본적으로 가시화하고 탐지할 수 있는 기능을 제공합니다.

CVE-2026-109618 및 CVE-2026-109619로 추적되는 두 취약점은 모두 CVSS 4.0 기준 9.2점(치명적)을 받았으며, CWE-824(초기화되지 않은 포인터에 대한 접근)로 분류됩니다. 두 취약점 모두 인증되지 않은 원격 공격자가 HTTP를 통해 영향을 받는 웹 서버에서 임의의 시스템 명령을 실행할 수 있도록 합니다.

두 취약점은 동일한 근본 원인에서 비롯됩니다. PHP에서 치명적인 상황(설정된 memory_limit 초과, 최대 실행 시간 초과 또는 클라이언트 연결 끊김)이 발생하면 호출 스택을 따라 오류를 반환하지 않습니다. 대신 치명적인 오류를 발생시키고 longjmp()를 사용해 현재 실행 컨텍스트를 즉시 벗어나 요청 처리를 중단합니다. 이때 데이터 구조를 생성하는 도중이었던 C 함수는 그대로 폐기됩니다. 소멸자는 실행되지 않고, 변경된 상태는 롤백되지 않으며, 해당 데이터 구조가 불완전하다는 사실도 기록되지 않습니다. 이후 PHP는 모든 데이터 구조가 일관된 상태라는 전제하에 일반적인 정리 절차를 진행합니다.

두 CVE는 이러한 전제가 깨지는 지점을 각각 설명합니다.

CVE-2026-109618(메모리 부족으로 인한 RCE)은 요청 메모리가 초기화되지 않은 상태로 남는 실행 컨텍스트를 다룹니다. 메모리 할당이 완료되기도 전에 데이터 구조에 항목이 추가된 것으로 표시됩니다. 해당 할당이 메모리 제한을 초과하는 할당이라면, 그 항목에는 오래된 힙 데이터가 그대로 남습니다. 이후 실패한 요청 자체의 정리 루틴이 이 바이트를 읽고 이를 바탕으로 분기합니다.
CVE-2026-109619(치명적인 오류로 인한 RCE)은 전역 상태가 유효하지 않은 상태로 남는 실행 컨텍스트를 다룹니다. 모듈 수준의 전역 변수가 이미 해제된 요청별 힙 메모리를 여전히 가리키고 있으며, 해당 작업이 활성 상태라고 표시합니다. 동일한 워커 프로세스가 처리하는 다음 요청은 이 해제된 메모리를 읽거나 이를 바탕으로 분기합니다.

두 경우 모두 공격자는 취약점이 발동되는 조건뿐 아니라, PHP가 궁극적으로 잘못 해석하게 되는 데이터까지 제어합니다. CrowdStrike는 인증, 세션 또는 취약한 애플리케이션 코드 없이도 익명 POST 요청 하나만으로 Apache mod_php 워커가 셸 프로세스를 실행하고 공격자가 지정한 명령을 수행할 수 있음을 처음부터 끝까지 검증했습니다.

이러한 취약점이 특히 위험한 이유는 실행 스택에서 차지하는 위치에 있습니다. PHP는 확장 기능이 초기화되기 전에, 그리고 애플리케이션 코드가 단 한 줄도 컴파일되기 전에 수신된 요청 데이터를 파싱합니다. 따라서 악용 가능성은 서버에서 어떤 애플리케이션을 호스팅하는지와 무관합니다. 철저하게 유지 관리되는 애플리케이션도 방치된 애플리케이션과 동일한 수준으로 노출됩니다. 또한 공격 흔적이 매우 적습니다. 워커 프로세스는 충돌하지 않고, 서버는 일반적인 HTTP 200 응답을 반환하며, 애플리케이션 로그에도 비정상적인 내용이 기록되지 않습니다.

테스트 과정에서 CrowdStrike는 x86-64 및 ARM 아키텍처에서 일관되게 작동하고, 워커가 재시작된 후에도 안정적으로 실행되는 익스플로잇 코드를 개발했습니다. 또한 클라우드 환경에서 점차 보편화되고 있는 ARM 기반 호스트에서는 HTTP 요청만으로 주소 공간 배치 난수화(ASLR)를 우회했습니다.

기술적 세부 사항

공통 근본 원인: 스택 언와인딩 없는 `longjmp()`

두 취약점은 모두 PHP의 핵심 엔진인 Zend에서 발생합니다. Zend는 PHP 소스 코드를 바이트코드로 컴파일하고, 가상 머신에서 이를 실행하며, 변수, 배열, 객체, 참조 카운팅 및 메모리 할당 등 언어의 런타임에 필요한 모든 요소를 관리하는 C 구현체입니다. Zend는 Zeev Suraski와 Andi Gutmans가 개발했으며(두 사람의 이름을 조합해 명명), PHP 4와 함께 도입되었습니다. 선택적으로 추가하는 구성 요소나 타사 애드온이 아니라 모든 PHP 빌드에 포함되는 핵심 구성 요소입니다. 따라서 소스 코드가 php-src의 Zend/ 디렉터리에 있습니다. 실제로 이는 Zend의 결함이 곧 PHP 엔진 자체의 결함이라는 의미입니다. 코드 작성 방식과 관계없이 해당 인터프리터에서 실행되는 모든 애플리케이션, 프레임워크 및 확장 기능에 영향을 미칩니다.

여기서 설명하는 문제와 관련된 Zend의 핵심 메커니즘은 두 가지입니다. 모든 PHP 배열(슈퍼글로벌 $_POST 포함)의 기반이 되는 HashTable과 PHP와 운영 체제 사이에서 작동하는 PHP 자체의 요청별 메모리 할당자인 Zend Memory Manager(Zend MM)입니다. PHP의 치명적인 오류 처리 경로는 zend_bailout()에서 종료되며, 이 함수는 현재 C 호출 스택에서 LONGJMP를 수행합니다.

// Zend/zend.c ZEND_API ZEND_COLD ZEND_NORETURN void _zend_bailout(const char *filename, uint32_t lineno) { ... CG(unclean_shutdown) = 1; ... LONGJMP(*EG(bailout), FAILURE); }

치명적인 오류가 발생한 시점부터 이를 감싸는 zend_catch 블록에 도달할 때까지 그 사이의 코드는 실행되지 않습니다. 상태를 변경한 후 자체 정리 코드를 실행해야 한다고 가정한 모든 호출자는 변경된 상태를 그대로 남기게 됩니다. 이러한 방식은 모든 호출자가 갑작스러운 종료를 고려해 작성된 경우에만 안전하지만, 일부 호출자는 그렇지 않습니다.

CVE-2026-109618: 초기화되지 않은 요청 메모리를 동일한 요청 내에서 사용

대표적인 사례는 Zend/zend_hash.c에 있는 _zend_hash_str_add_or_update_i()입니다. 이 함수는 PHP 배열에 문자열 키를 삽입하는 모든 작업을 처리하는 헬퍼 함수입니다. 삽입 경로에서 이 함수는 두 요소 카운터를 모두 증가시키고 새 버킷을 가리키는 포인터를 가져온 다음, 해당 키의 복사본을 할당합니다.

// Zend/zend_hash.c
add_to_hash:
   idx = ht->nNumUsed++;
   ht->nNumOfElements++;
   p = ht->arData + idx;
   p->key = key = zend_string_init(str, len, GC_FLAGS(ht) & IS_ARRAY_PERSISTENT);

zend_string_init()이 memory_limit을 초과하면 Zend MM은 zend_bailout()으로 이어지는 치명적인 오류를 발생시킵니다. 버킷을 완성하기 위한 코드가 실행되기 전에 처리가 종료됩니다. 이제 테이블에는 실제로 존재하지 않는 항목이 하나 더 있는 것으로 기록됩니다. 해당 항목의 값, 해시 및 키 포인터에는 할당자가 해당 메모리에 마지막으로 남겨둔 바이트가 그대로 들어갑니다. 버킷 배열은 초기화되지 않은 emalloc()으로 할당되며, 해시 영역만 명시적으로 초기화됩니다.

요청 종료 과정에서 php_request_shutdown()은 슈퍼글로벌 변수를 제거하고, zend_array_destroy()는 nNumUsed개의 버킷을 순회합니다. 이때 오래된 항목은 참조 카운팅 값으로 취급되는 i_zval_ptr_dtor()에 전달됩니다. 이 함수는 해당 항목에 들어 있는 포인터를 역참조하고, 그 주소의 참조 카운트를 감소시킵니다. 참조 카운트가 0에 도달하면, 역시 남아 있던 바이트에서 가져온 유형 태그를 인덱스로 사용해 함수 포인터 테이블을 통해 함수를 호출합니다.

이 취약점이 발생하도록 유도하는 데는 URL 인코딩된 POST 본문만 있으면 충분합니다. PHP는 zend_activate_modules()가 호출되기 전, 그리고 스크립트가 컴파일되기 전에 php_request_startup()이 호출하는 php_hash_environment() 내부에서 $_POST를 채우기 때문입니다. ZZZZ…[x]=1과 같이 중첩된 이름을 가진 필드가 있으면 php_register_variable_ex()가 바깥쪽 이름을 새로운 배열 키로 삽입합니다. 따라서 공격자는 메모리를 할당해야 하는 해당 키의 길이를 직접 제어할 수 있습니다. 해당 이름의 길이를 memory_limit을 초과하도록 조정하면, 메모리 할당이 키를 생성하는 바로 그 시점에 중단되면서 bailout이 발생합니다.

남아 있는 바이트를 제어할 수 있는 것은 할당자의 결정론적 동작 덕분입니다. Zend MM은 작은 할당을 크기별 자유 목록에서 엄격한 후입선출(LIFO) 순서로 처리하며, 재사용되는 메모리 블록을 초기화하지 않습니다. 따라서 PHP가 복사하고 디코딩한 직후 해제하는 동일 요청 내의 이전 필드 크기를 조정하면, 해제된 데이터가 이후 손상된 배열이 사용하는 메모리 블록과 정확히 일치하도록 만들 수 있습니다. 그 결과 오래된 항목은 공격자가 완전히 정의한 값이 됩니다. 이를 통해 소멸자 포인터가 libc의 system()을 가리키고 명령 문자열이 동일한 메모리 블록에 포함된 위조 배열을 구성할 수 있었습니다.

공격이 성공했을 때 서버 측에 남는 유일한 흔적은 웹 서버 로그에 기록되는 일반적인 치명적 오류 메시지입니다.

PHP Fatal error: Allowed memory size of 16777216 bytes exhausted (tried to allocate 3670048 bytes) in Unknown on line 0

여기서 in Unknown on line 0이라는 문구가 중요한 단서입니다. 실제로 PHP 파일이 실행된 적이 없음을 확인해 주기 때문입니다.

CVE-2026-109619: 유효하지 않은 전역 상태를 후속 요청에서 사용

두 번째 CVE도 동일한 메커니즘을 따르지만, 손상이 프로세스 범위의 상태에 영향을 미치므로 악용 시점이 이후 요청으로 이동합니다. 이 경우 중단된 작업은 전역 변수에 상태를 캐시하고 자체 정리 호출에 도달해야 해당 상태를 초기화할 수 있는 작업입니다. PHP는 활성 직렬화 및 역직렬화 컨텍스트를 모듈 전역 변수에 캐시하고, 중첩 수준이 0이 아닌 경우 캐시된 포인터를 재사용합니다. 이에 대응하는 소멸자 호출만이 해당 수준을 감소시키고 포인터를 초기화할 수 있으며, 확장 기능의 요청 초기화 루틴만이 이 상태를 재설정합니다. 세션 처리도 이와 유사합니다. 세션 ID, 핸들러 상태, 세션 변수 및 업로드 진행 상태를 전역 변수에 저장하고 전용 종료 루틴을 통해 초기화합니다.

치명적인 오류로 인해 이러한 작업이 중단되면 대응하는 정리 절차가 실행되지 않습니다. 전역 변수에는 기존 포인터가 그대로 남고, 중첩 카운터도 해당 작업이 여전히 활성 상태라고 표시합니다. 이후 요청 종료 과정에서 요청별 힙 전체가 해제되지만, 프로세스에 속하는 전역 변수는 그대로 유지됩니다. 그 결과 PHP는 이미 해제된 메모리를 가리키는 모듈 수준 포인터를 보유하게 됩니다.

이러한 상황을 유발하고 제어할 수 있는 요인은 두 가지입니다.

워커 재사용: Apache mod_php와 같이 워커가 지속적으로 재사용되는 배포 환경에서는 동일한 프로세스가 다음 요청을 처리합니다. 이때 오래된 전역 변수는 그대로 남아 있고, 해당 작업이 여전히 진행 중인 것으로 간주되므로 해제된 포인터를 읽거나 이를 통해 데이터를 쓰거나 해당 포인터를 기반으로 분기하게 됩니다. 이 시점에 해당 메모리 영역을 차지하는 데이터는 공격자의 영향을 받습니다. 중간에 처리되는 요청 역시 공격자가 보낸 요청이므로, 공격자는 요청의 크기와 내용을 선택할 수 있습니다. 또한 Zend MM의 메모리 할당 동작은 데이터를 안정적으로 배치할 수 있을 만큼 결정론적입니다. PHP-FPM은 요청 시작 단계에서 오류가 발생하면 해당 워커를 종료하므로, 이 단계에서 발생한 중단에 대해서는 워커 재사용이 이루어지지 않습니다. 그러나 이미 실행 중인 스크립트 내부에서 중단이 발생하면 FPM 워커는 계속 유지되므로 동일하게 취약한 상태가 됩니다.
초기화 순서: php_request_startup()은 확장 기능의 요청 초기화 콜백을 실행하기 전에 요청 변수를 파싱합니다. 따라서 멀티파트 업로드 진행률 처리 과정에서 세션 및 직렬화 코드가 해당 전역 변수를 소유한 확장 기능의 초기화 기회가 주어지기도 전에 실행될 수 있습니다. 이로 인해 요청의 가장 초기 단계에서 오래된 포인터가 사용될 수 있습니다.

메모리 부족뿐 아니라 실행 시간 초과 및 클라이언트 연결 중단으로도 이러한 상황이 발생할 수 있습니다. 이들 모두 동일한 zend_bailout() 경로를 거치기 때문입니다. 따라서 공격은 두 단계로 이루어집니다. 첫 번째 요청으로 워커를 오염시키고, 두 번째 요청으로 해제된 메모리를 사용하도록 유도합니다.

취약점 영향

두 취약점의 심각성은 요청 처리 초기 단계에 위치한다는 점에서 비롯됩니다. PHP가 내부 요청 변수를 구성하는 동안, 즉 확장 기능 초기화 및 애플리케이션 코드 실행 전에 메모리 손상이 발생하므로 영향을 받는 서버에서 접근 가능한 모든 PHP 엔드포인트가 공격 대상이 됩니다. 여기에는 정적 양식, 로그인 경로 및 상태 확인 엔드포인트도 포함됩니다. 우회해야 할 인증도, 탈취해야 할 세션도, 찾아야 할 취약한 엔드포인트도 없습니다. 사용 중인 CMS, 프레임워크 또는 플러그인과 관계없이 노출됩니다.

또한 공격은 거의 디지털 흔적을 남기지 않습니다. 워커 프로세스는 안정적으로 유지되고 HTTP 200 응답이 반환되며 애플리케이션 코드가 실행된 적이 없으므로 애플리케이션 로그에도 이상 징후가 기록되지 않습니다. 서버 측에 남는 유일한 흔적은 웹 서버 오류 로그에 기록되는 단 한 건의 메모리 제한 관련 치명적 오류입니다. 이러한 오류는 일반적으로 중요하지 않은 잡음으로 간주되어 무시되므로, 방어자는 침해된 엔드포인트를 식별하는 데 필요한 웹 텔레메트리를 확보하기 어렵습니다.

Apache prefork와 같은 다중 프로세스 웹 서버에서는 모든 워커가 단일 부모 프로세스에서 파생됩니다. 따라서 공격자가 의존하는 메모리 레이아웃은 워커가 재시작된 후에도 일관되게 유지됩니다. 이러한 안정성 덕분에 공격자는 추가 비용 없이 페이로드를 개선할 수 있습니다. 공격이 실패하더라도 워커가 다시 생성되며, 모니터링 시스템은 이를 일반적인 동작으로 처리합니다.

두 CVE는 범위와 발생 시점에서 차이가 있으며, 이러한 차이는 운영 측면에서 중요합니다. CVE-2026-109618은 단일 요청 내에서 모든 과정이 이루어집니다. 하나의 요청이 자체 데이터를 손상시키고, 그 결과가 동일한 요청의 정리 과정에서 실행됩니다. 따라서 공격이 빠르고 단일 단계로 완료되며 사후에 재구성하기 어렵습니다. CVE-2026-109619는 여러 요청에 걸쳐 발생합니다. 동일한 워커를 대상으로 상태를 오염시키는 단계와 이를 유발하는 단계가 필요하지만, 더 광범위한 내부 상태에 접근할 수 있으며 메모리 부족뿐 아니라 실행 시간 초과와 클라이언트 연결 끊김을 통해서도 유발할 수 있습니다. 이 두 번째 유형의 취약점은 워커가 지속적으로 재사용되는 배포 환경에서 특히 문제가 됩니다.

두 취약점 중 하나라도 악용에 성공하면 웹 서버 사용자 권한으로 명령을 실행할 수 있습니다. 이는 웹 셸을 설치하고, 구성 파일에서 데이터베이스 및 API 자격 증명을 수집하며, 내부 네트워크로 침투하는 데 활용되는 일반적인 초기 거점입니다. 완전한 해결을 위해서는 패치 적용이 필수입니다. 즉시 패치를 적용할 수 없는 경우에는 엔드포인트 동작 모니터링이 주요 방어 수단입니다. HTTP 계층에서는 악용 여부가 드러나지 않지만, 악용의 결과는 확인할 수 있기 때문입니다.

영향을 받는 시스템인가요?

두 취약점은 7.x 및 8.x 계열의 모든 PHP 릴리스에 존재합니다. CVE-2026-109618의 근본 원인인 특정 HashTable 처리 순서는 2017년 10월 성능 최적화 과정에서 도입되었으며, PHP 7.3.0(2018년 12월)에 처음 포함되었습니다. CVE-2026-109619의 원인이 되는 직렬화 및 세션 처리 경로는 그보다 오래전인 PHP 7.1 및 PHP 5.4까지 거슬러 올라갑니다. 즉, 이 취약점이 악용 가능한 상태로 출시된 PHP에 존재한 기간은 7년이 넘습니다. 지원되는 PHP 브랜치 중 취약점의 영향을 받지 않는 브랜치는 없습니다.

버전만으로 취약점 노출 여부를 판단할 수는 없습니다. 메모리 부족 트리거가 PHP에서 요청 데이터를 파싱하는 동안 실행될 수 있어야 합니다. 이를 위해서는 스크립트가 실행되기 전에 요청 본문이 메모리 제한을 초과할 만큼 커질 수 있어야 합니다. 실제로는 다음과 같은 설정 조건을 충족해야 합니다.

memory_limit < 4 × post_max_size

PHP에 기본으로 제공되는 설정값(post_max_size = 8M, memory_limit = 128M)은 이 조건을 충족하지 않습니다. 따라서 기본 설정을 그대로 사용하는 설치 환경에서는 앞서 설명한 URL 인코딩 경로를 통한 공격이 불가능합니다. 그러나 실제 운영 환경에서는 대용량 업로드를 허용하기 위해 설정을 조정하는 경우가 많으며, post_max_size = 64M 및 memory_limit = 128M, 또는 post_max_size = 100M 및 memory_limit = 256M과 같은 일반적인 설정 조합은 이 조건을 충족합니다. 또한 post_max_size는 .htaccess 파일이나 가상 호스트별로 설정할 수 있습니다. 따라서 공유 호스팅 환경에서는 서버 전체의 설정을 변경하지 않고도 개별 사이트가 취약한 설정 상태에 놓일 수 있습니다. CrowdStrike는 테스트 페이로드의 크기를 줄이기 위해 memory_limit을 16M으로 낮추고 post_max_size를 64M으로 높인 환경에서 이 문제를 재현했습니다. 그러나 위에서 설명한 더 큰 제한값을 사용하는 환경에서도 더 큰 페이로드를 통해 동일한 취약점이 발생합니다.

서버에서 실행 중인 PHP 버전을 확인하려면 php --version을 실행하면 됩니다. 서버에 앞서 언급한 옵션들이 어떻게 설정되어 있는지 확인하려면 다음 명령어를 실행합니다.
php -i | grep -E "^(memory_limit|post_max_size|upload_max_filesize|Loaded Configuration File)"

CrowdStrike Falcon의 고객 보호 방식

CrowdStrike는 머신 러닝과 공격 지표(IOA)를 포함한 행위 기반 탐지를 활용해 악용 및 악용 이후 활동을 탐지하는 다층 방어 접근 방식을 적용합니다. Falcon 플랫폼은 PHP 취약점의 악용 이후 활동에 대한 가시성과 탐지 기능을 기본적으로 제공합니다. 기존 IOA는 웹 셸 설치, PHP 또는 웹 서버 프로세스에서 생성되는 의심스러운 하위 프로세스, 악성 명령 실행 등 일반적인 악용 이후 활동을 탐지하고 차단합니다.

CrowdStrike는 이 취약점과 관련된 공격 기법에 대한 연구를 계속 진행하고 있습니다.

그림 1. PHP 취약점의 공격 및 악용 과정

Falcon Exposure Management를 통한 취약한 PHP 버전 식별

CrowdStrike Falcon® Exposure Management는 영향을 받는 환경 전반에 대한 포괄적인 가시성을 제공합니다. 네트워크 스캔(Network Scan, Netscan) 및 외부 공격 표면 관리(External Attack Surface Management, EASM) 기능은 인터넷에 노출된 자산을 대상으로 배너 정보를 기반으로 신속하게 탐지합니다. 또한 센서 기반 가시성을 통해 지원되는 Linux 배포판, Windows 및 macOS 운영 체제 전반에서 공급업체가 제공하는 하위 패치의 적용 여부를 자동으로 평가할 수 있습니다.

Falcon Exposure Management는 기존 패키지 관리자 검사 및 대상 애플리케이션 검사를 통해 지원되는 모든 센서 버전에서 해당 CVE를 탐지합니다. 이러한 검사에는 최소 센서 버전 요구 사항이 없습니다.

CrowdStrike는 기존 검사에서 누락될 수 있는 PHP 설치 환경을 찾아내기 위해 다음과 같은 센서 기반 탐지 기능도 추가했습니다. 여기에는 사용자 지정 설치 또는 패키지 관리자를 사용하지 않고 설치한 환경이 포함됩니다. 이 기능은 아래에 명시된 센서 버전에서만 사용할 수 있습니다.

Windows(Falcon 센서 7.40 이상): 기본 드라이브에서 PHP 실행 파일을 찾는 시스템 전체 검사입니다. 이를 통해 사용자 지정 설치를 포함하여 기존 검사에서 식별하지 못할 수 있는 추가 PHP 설치 환경을 찾아냅니다.
Linux(Falcon 센서 7.31 이상): 실행 중인 프로세스를 검사하여 예상된 패키지 관리자를 통해 설치되지 않은 PHP 환경을 식별합니다.

이전 센서 버전을 사용하는 고객도 패키지 관리자 검사 및 대상 애플리케이션 검사를 통해 보호받을 수 있습니다. 다만 센서를 업그레이드하기 전까지는 추가적인 시스템 전체 검사 및 실행 중인 프로세스 검사를 이용할 수 없습니다.

그림 2. Falcon Exposure Management에서 취약한 PHP 버전 식별

차세대 SIEM을 통한 위협 식별

Falcon Next-Gen SIEM: Emerging Threat Response 대시보드

이 위협에 대한 CrowdStrike Falcon® Next-Gen SIEM 탐지 기능은 NG-SIEM 콘텐츠 패키지 릴리스의 일부로 프로덕션 환경에 배포되었습니다. 해당 기능은 CrowdStrike Falcon - Emerging Threat Response 대시보드에 새롭게 추가된 'PHP Remote Code Execution Vulnerabilities(CVE-2026-109618/109619)' 섹션을 통해 제공됩니다.

Emerging Threat Response 대시보드는 활성 공격 캠페인이나 새롭게 발견된 취약점이 고객 환경에 미치는 영향을 즉시 파악할 수 있도록 설계된 집중 대응 도구입니다. Falcon 플랫폼 모듈의 풍부한 텔레메트리와 Falcon Next-Gen SIEM에 수집된 타사 데이터를 활용하여, 이 대시보드는 바로 사용할 수 있는 탐지 및 위협 헌팅 쿼리를 제공합니다. 이를 통해 보안팀은 위협 노출 여부를 신속하게 파악하고 침해되었을 가능성이 있는 자산을 식별할 수 있습니다.

차세대 SIEM > 로그 관리 > 대시보드에서 확인해 보세요

그림 3. Falcon Next-Gen SIEM에서 Emerging Threat Response 대시보드 식별

Falcon Next-Gen SIEM 상관관계 규칙 템플릿

CrowdStrike는 CVE-2026-109618 및 CVE-2026-109619를 탐지하고 대응하기 위한 새로운 Falcon Next-Gen SIEM 상관관계 규칙 템플릿(CRT)을 추가했습니다. 이 규칙은 해당 취약점과 관련된 공격 시도에 대한 탐지 범위를 제공합니다.

Generic - Web - PHP Memory Exhaustion During Request Startup(CVE-2026-109618 & CVE-2026-109619)

이 탐지 기능은 PHP 스크립트 실행이 시작되기 전에 발생하는 PHP의 메모리 고갈 관련 치명적 오류를 식별합니다. 구체적으로 웹 서버 오류 로그에 “Allowed memory size of N bytes exhausted”와 “in Unknown on line 0” 메시지가 함께 나타나는 특징적인 패턴을 탐지합니다. "Unknown on line 0”이라는 표시는 스크립트 실행 중 발생하는 훨씬 더 빈번한 메모리 오류와 요청 초기화 단계에서 발생하는 오류를 구분해 줍니다. 이를 통해 애플리케이션 코드가 실행되기도 전에 PHP 인터프리터의 메모리를 고갈시키는 행위가 발생했음을 보다 높은 신뢰도로 식별할 수 있습니다. 이러한 패턴은 PHP 엔진에 대한 악용 시도를 나타낼 수 있습니다. 고객은 여기에서 해당 템플릿을 확인할 수 있습니다([US-1] [US-2] [US-3] [EU-1] [US-GOV-1] [US-GOV-2]).

결론 및 권장 사항

CrowdStrike는 변화하는 상황을 적극적으로 모니터링하고 있으며, 새로운 정보가 확인되는 대로 업데이트를 제공할 예정입니다. 이와 동시에 공개된 PHP 취약점인 CVE-2026-109618 및 CVE-2026-109619와 관련된 악성 활동을 탐지하고 차단하기 위해 Falcon 플랫폼의 새로운 행위 기반 탐지 로직을 지속적으로 개발하고 배포하고 있습니다.

고객은 취약한 PHP 버전을 실행하는 시스템을 식별하고, 공식 PHP 또는 공급업체의 지침에 따라 최신 보안 업데이트를 적용하는 것이 좋습니다.