diff --git a/content/writing/PHP2Shell (CVE-2026-109618, CVE-2026-109619) Vulnerability Analysis & Technical Report copy.md b/content/writing/PHP2Shell (CVE-2026-109618, CVE-2026-109619) Vulnerability Analysis & Technical Report copy.md
@@ -0,0 +1,155 @@
+---
+title: "PHP2Shell (CVE-2026-109618 / CVE-2026-109619) Vulnerability Analysis & Technical Report"
+titleKo: ""
+date: 2026-10-22
+deck: ""
+type:
+tags: []
+draft:
+---
+
+## 1. Executive Overview
+
+In October 2026, two critical security vulnerabilities were publicly disclosed in the PHP core engine, which powers approximately 70% of web systems worldwide. These flaws allow unauthenticated attackers to gain full control of targeted web servers or leak process memory without requiring any login or credential verification. This set of vulnerabilities has been dubbed **'PHP2Shell'**.
+
+Regardless of the source code security of individual web applications (such as WordPress, Drupal, or Laravel), these vulnerabilities stem directly from **memory management defects within the PHP engine itself**.
+
+### 1.1 Intuitive Analogy: System Architecture Perspective
+To understand the flaw intuitively, imagine a website as an **apartment building**:
+* **Standard Web Application Hacking**: Picking the lock or breaking a window of an individual apartment unit.
+* **PHP2Shell Attack**: A structural flaw in the building's core materials (the PHP engine itself), allowing attackers to bypass the front desk security or keypads entirely and gain direct control of the entire building management room.
+
+### 1.2 Key Vulnerability Summary
+
+| Item | Details |
+| :--- | :--- |
+| **Vulnerability Identifiers** | **CVE-2026-109618** (OOM Memory Corruption & Disclosure), **CVE-2026-109619** (Stale Global State RCE) |
+| **Severity** | **Critical** (CVSS v4.0 Score: **9.2**) |
+| **Attack Vector** | Unauthenticated Remote Code Execution (RCE), Memory Disclosure |
+| **Affected Versions** | PHP 5.4.0 through unpatched releases across all active branches (8.2, 8.3, 8.4, 8.5) |
+| **Patched Releases** | **PHP 8.2.35 / 8.3.36 / 8.4.27 / 8.5.12 or higher** |
+
+---
+
+## 2. Vulnerability Mechanics & Attack Pipeline
+
+The root cause of the PHP2Shell attack lies in a structural flaw where the PHP engine fails to properly clean up its state during fatal errors—specifically **Out-Of-Memory (OOM)** conditions—and abruptly performs an emergency stack unwind via `longjmp()`.
+
+The attack unfolds across a 3-stage pipeline:
+
+1. **Stage 1: Inducing Intentional OOM (Out-Of-Memory)**
+ The attacker sends a specially crafted HTTP multipart (file upload) request that rapidly exhausts PHP's allocated `memory_limit`.
+2. **Stage 2: Emergency Abort & Residual Dangling Pointers (Triggering Use-After-Free)**
+ When OOM occurs, the PHP engine skips standard cleanup routines and terminates via `longjmp()`. While the active Heap memory is freed, global memory pointers are left uninitialized (Dangling Pointers).
+3. **Stage 3: Memory Re-allocation & Server Hijacking via Secondary Request**
+ The attacker immediately issues a second HTTP request targeted at the same web server worker process. Malicious payload structures (fake function pointers) fill the newly allocated memory space, causing the server to reference the dangling pointer, execute malicious code, or leak sensitive memory data (passwords, API keys, etc.).
+
+
+
+---
+
+## 3. Deep Technical Analysis: Memory Management Defects
+
+This section details the C-level memory management architecture and exploit mechanics within the PHP core engine.
+
+### 3.1 C-Level Pointer Uninitialization and `longjmp()` Emergency Unwinding
+Under normal execution, PHP frees allocated memory upon request completion and resets pointer addresses to `NULL (0)`. However, when a memory allocation function (`emalloc()`) fails due to OOM, the PHP core immediately executes `longjmp()` to unwind the stack directly to the top-level error handler.
+
+During this abrupt unwinding, cleanup routines inside core functions such as `_zend_hash_str_add_or_update_i()` are bypassed. Consequently, even though the OS and PHP allocator mark the Heap memory region as freed, global execution state objects (such as `zend_executor_globals`) retain **dangling pointers** pointing to the freed memory addresses.
+
+### 3.2 HTTP Multipart Manipulation & `memory_limit` Exhaustion Techniques
+To bypass the server's `post_max_size` guard while triggering `memory_limit` exhaustion, attackers craft HTTP headers and body structures with the following traits:
+
+* **Empty Filename Specification (`filename=""`)**: Generates metadata structures for PHP's internal file upload management array (`PG(http_post_files)`) continuously without requiring actual file payloads.
+* **Deeply Nested Field Names (`a[b][c][d]...`)**: Triggers the creation of multi-dimensional hash tables, fragmenting the Heap memory into numerous small chunks and accelerating exhaustion.
+* **Chunked Transfer Encoding**: Streams request data without specifying an initial content length, preventing web servers from pre-validating memory allocation thresholds.
+
+### 3.3 Web Server Worker Process Reuse & State Persistence
+Modern web hosting environments (such as Apache `mod_php` or `PHP-FPM`) keep worker processes alive across multiple requests to optimize performance.
+
+Immediately after corrupting a worker process's global state with the first request, the attacker uses HTTP/1.1 Keep-Alive or synchronized concurrent requests to ensure the **second request hits the exact same worker process**.
+
+### 3.4 Heap Memory Re-allocation & Control Flow Hijacking
+When the second request arrives at the corrupted worker, PHP's memory manager (Zend MM) re-allocates the recently freed Heap chunk for the new request's data.
+
+The attacker structures the second request body with a fake virtual method table (VTable) and function pointers. When the PHP engine mistakenly trusts the dangling pointer from the prior request and invokes a method, execution branches to the attacker-controlled address (e.g., ROP gadget), achieving **Remote Code Execution (RCE)**.
+
+### 3.5 Memory Disclosure via Residual Data & Session Cookies
+In `CVE-2026-109618`, the flaw leads not only to RCE but also to severe memory leaks:
+1. Triggering OOM during session initialization leaves the session ID pointer (`PS(id)`) pointing to freed Heap memory.
+2. When the second request arrives, the PHP engine treats whatever residual data remains in that memory space (such as database passwords, API keys, encryption tokens, or ASLR bypass addresses from previous operations) as a valid session ID string.
+3. PHP URL-encodes this raw memory content and returns it in the `Set-Cookie: PHPSESSID=...` response header, allowing attackers to decode and extract sensitive server secrets directly.
+
+
+
+---
+
+## 4. Threat Intelligence & Exploit Dynamics
+
+### 4.1 Weaponization via Artificial Intelligence (LLM) & Automated Debugging
+Although these flaws remained dormant in the PHP core for over a decade, security researchers (Wiz Research, Calif, etc.) leveraged **advanced Large Language Models (LLMs)** combined with automated debugging tools (GDB/LLVM) to compress what used to take months of manual research into a matter of hours.
+
+### 4.2 ASLR Mitigation & The 2-Stage Exploit Chain
+According to analysis by security expert Marcus Hutchins, most public proof-of-concept (PoC) scripts circulating online fail or simply crash the server. This is because modern operating systems enforce **ASLR (Address Space Layout Randomization)**.
+
+To achieve reliable exploitation, attackers must execute a **2-stage exploit chain**:
+* **[Stage 1] Memory Disclosure Attack**: Exploit `CVE-2026-109618` to extract process memory addresses and module base addresses via response cookies.
+* **[Stage 2] ASLR Bypass & RCE Execution**: Calculate exact ROP gadget offsets using the leaked addresses, then deliver the secondary payload to achieve stable code execution.
+
+---
+
+## 5. Server Architecture Risk Matrix
+
+| Server Environment | Vulnerable? | Risk Assessment & Vector |
+| :--- | :---: | :--- |
+| **Apache + mod_php (prefork)** | **Yes (Highest Risk)** | Unauthenticated RCE possible across any request path regardless of application code. |
+| **Apache + PHP-FPM** | **Yes (High Risk)** | RCE possible via endpoints triggering `session_start()`, `unserialize()`, or upload handling. |
+| **Nginx + PHP-FPM** | **Yes (High Risk)** | Same vector as Apache + PHP-FPM. Higher `client_max_body_size` increases exploitability. |
+| **FrankenPHP / LSAPI** | **Yes (Caution)** | Similar to FPM worker reuse models, susceptible to state corruption. |
+
+---
+
+## 6. Remediation & Mitigation
+
+### 6.1 Permanent Solution (P0) - Apply Official Patches
+Applying official vendor patches is the **only complete solution** to defend against all exploit variations.
+
+1. **Immediately Upgrade PHP Core**:
+ * PHP 8.2 branch $\rightarrow$ **8.2.35 or higher**
+ * PHP 8.3 branch $\rightarrow$ **8.3.36 or higher**
+ * PHP 8.4 branch $\rightarrow$ **8.4.27 or higher**
+ * PHP 8.5 branch $\rightarrow$ **8.5.12 or higher**
+2. **Restart Web Services**:
+ * After updating binaries, run `systemctl restart apache2` or `systemctl restart php-fpm` to flush corrupted worker instances from memory.
+
+### 6.2 Temporary Mitigations (P1)
+If immediate patching is not possible, implement these temporary measures to reduce exposure:
+
+* **Update `php.ini` Settings**:
+ ```ini
+ session.upload_progress.enabled = 0
+ session.auto_start = 0
+ ```
+* **Web Application Firewall (WAF) Rules**:
+ * Block request bodies containing `PHP_SESSION_UPLOAD_PROGRESS`.
+ * Drop requests containing empty filenames (`filename=""`) combined with deeply nested fields (`a[b][c][d]`).
+
+---
+
+## 7. Forensic & Detection Guide
+
+System administrators can check Linux server logs for signs of exploitation attempts using the following commands:
+
+1. **Check for Pre-execution OOM Errors**:
+ ```bash
+ grep -cE 'Allowed memory size of [0-9]+ bytes exhausted.*in Unknown on line 0' \
+ /var/log/php_errors.log /var/log/apache2/error.log /var/log/httpd/error_log /var/log/php*-fpm.log
+ ```
+2. **Check for Worker Segmentation Faults**:
+ ```bash
+ grep -E "Segmentation fault|signal 11|SIGSEGV" /var/log/apache2/error.log /var/log/php*-fpm.log
+ ```
+3. **Inspect Response Cookies for Memory Leaks**:
+ * Review web server or WAF logs for abnormally long or binary-encoded `PHPSESSID` cookie values in HTTP responses.
+
+---
\ No newline at end of file
diff --git a/content/writing/PHP2Shell (CVE-2026-109618, CVE-2026-109619) Vulnerability Analysis & Technical Report_kr.md b/content/writing/PHP2Shell (CVE-2026-109618, CVE-2026-109619) Vulnerability Analysis & Technical Report_kr.md
@@ -0,0 +1,151 @@
+---
+title: "PHP2Shell (CVE-2026-109618 / CVE-2026-109619) 보안 취약점 종합 분석 및 기술 보고서"
+titleKo: ""
+date: 2026-10-22
+deck: ""
+type:
+tags: []
+draft:
+---
+
+## 1. 개요 및 위협 수준 (Executive Overview)
+
+2026년 10월, 전 세계 웹 시스템의 약 70%를 구동하는 PHP 핵심 엔진(Core)에서 로그인이나 비밀번호 검증 없이 서버를 완전 장악하거나 프로세스 메모리를 탈취할 수 있는 치명적인 보안 결함 2건이 공개되었습니다. 이 취약점 집합은 **'PHP2Shell'**로 명명되었습니다.
+
+본 취약점은 워드프레스(WordPress), 드루팔(Drupal), 라라벨(Laravel) 등 개별 웹 애플리케이션 소스코드의 안전성과 관계없이 **PHP 엔진 자체의 메모리 관리 결함**으로 인해 발생합니다.
+
+### 1.1 시스템 구조적 관점에서의 직관적 이해
+웹사이트를 하나의 **아파트**에 비유하면 다음과 같습니다:
+* **일반적인 웹 애플리케이션 해킹**: 개별 가구의 비밀번호를 따거나 창문을 깨고 들어가는 방식입니다.
+* **PHP2Shell 공격**: 아파트 건물 자재(PHP 엔진) 자체에 결함이 존재하여, 현관 검문소나 비밀번호 입력 절차를 전혀 거치지 않고 건물 제어실 전체를 통째로 점령하는 방식입니다.
+
+### 1.2 취약점 핵심 요약
+
+| 항목 | 상세 내용 |
+| :--- | :--- |
+| **취약점 식별자** | **CVE-2026-109618** (OOM Memory Corruption & Disclosure), **CVE-2026-109619** (Stale Global State RCE) |
+| **심각도** | **Critical** (CVSS v4.0 **9.2**) |
+| **공격 유형** | 비인증 원격 코드 실행 (Unauthenticated RCE), 메모리 정보 유출 (Memory Disclosure) |
+| **영향 버전** | PHP 5.4.0 이상 ~ 패치 미적용 버전 전반 (8.2, 8.3, 8.4, 8.5) |
+| **정규 패치 버전** | **PHP 8.2.35 / 8.3.36 / 8.4.27 / 8.5.12 이상** |
+
+---
+
+## 2. 취약점 발생 원리 및 단계별 공격 파이프라인 (Vulnerability Mechanics)
+
+PHP2Shell 공격의 본질은 치명적 오류(Fatal Error), 특히 **메모리 부족(Out-Of-Memory, OOM)** 상황에서 PHP 엔진이 상태를 완벽히 정리하지 못하고 비상 탈출(`longjmp()`)하는 구조적 결함에 있습니다.
+
+공격은 크게 3단계 파이프라인으로 전개됩니다:
+
+1. **1단계: 의도적 OOM(Out-Of-Memory) 유도**
+ 공격자가 특수하게 조작된 HTTP 멀티파트(file upload) 요청을 전송하여 PHP의 `memory_limit`을 순간적으로 고갈시킵니다.
+2. **2단계: 비상 탈출 및 미초기화 전역 포인터 남김 (Use-After-Free 유발)**
+ OOM이 발생하면 PHP 엔진은 정상적인 정리 절차를 건너뛰고 `longjmp()`로 비상 종료됩니다. 이때 사용 중이던 힙(Heap) 메모리는 해제되지만, 전역 변수 내 메모리 포인터는 지워지지 않고 잔류(Dangling Pointer)합니다.
+3. **3단계: 2차 요청을 통한 메모리 재할당 및 장악**
+ 동일한 웹 서버 일꾼(Worker) 프로세스에 즉시 2차 요청을 보냅니다. 새로 할당된 메모리에 해커의 악성 데이터(가짜 함수 포인터)가 들어차고, 서버는 이전 요청이 남긴 잔여 포인터를 참조하다가 악성 코드를 실행하거나 메모리 내 민감 정보(비밀번호, API 키 등)를 유출시킵니다.
+
+---
+
+## 3. 메모리 관리 결함 및 메커니즘 심층 분석 (Deep Technical Analysis)
+
+이 장에서는 PHP 코어 내부의 C-Level 메모리 관리 구조와 공격 메커니즘을 상세히 다룹니다.
+
+### 3.1 C-Level 포인터 초기화 누락과 비상 탈출(`longjmp`)의 상호작용
+정상적인 요청 처리 과정에서 PHP는 작업 종료 시 메모리를 해제하고 포인터 주소를 `NULL(0)`로 초기화합니다. 그러나 메모리 할당 함수(`emalloc()`) 실패로 OOM 오류가 터지면, PHP 코어는 즉시 `longjmp()` 실행을 통해 최상위 에러 핸들러로 스택을 복구합니다.
+
+이 비상 탈출 과정에서 `_zend_hash_str_add_or_update_i()` 등의 함수 내부에 있던 메모리 포인터 초기화 코드가 실행되지 못하고 건너뛰어집니다. 그 결과, 힙 메모리 영역은 OS/PHP 얼로케이터에 의해 해제되었음에도 불구하고, 전역 실행 상태 객체(`zend_executor_globals` 등)에는 해제된 메모리를 가리키는 **더 이상 유효하지 않은 옛날 주소 포인터(Dangling Pointer)**가 그대로 남아있게 됩니다.
+
+### 3.2 HTTP Multipart 요청 조작 및 `memory_limit` 고갈 기법
+공격자는 서버의 `post_max_size` 제한을 우회하면서 `memory_limit`에 도달시키기 위해 다음과 같은 HTTP 헤더 및 바디 형태를 구성합니다:
+
+* **빈 파일명 지정 (`filename=""`)**: 실제 파일 데이터를 전송하지 않더라도 PHP 내부 업로드 관리 배열(`PG(http_post_files)`) 메타데이터 구조체를 연속 생성하게 만듭니다.
+* **복잡하게 중첩된 필드 이름 (`a[b][c][d]...`)**: 다차원 해시 테이블 생성을 유도하여 힙 메모리를 수많은 작은 파편(Chunk)으로 나누고 메모리 고갈을 가속화합니다.
+* **Chunked Transfer Encoding 활용**: 전체 요청 길이를 미리 알리지 않고 데이터를 스트리밍 방식으로 주입하여 서버가 메모리 할당 검사를 사전에 수행하지 못하도록 방해합니다.
+
+### 3.3 웹 서버 일꾼(Worker) 프로세스 재사용 구조와 상태 지속성
+Apache(`mod_php`), `PHP-FPM` 등 현대 웹 서버 환경은 성능 최적화를 위해 요청이 끝난 후 일꾼(Worker) 프로세스를 종료하지 않고 살려두어 다음 요청을 처리합니다.
+
+공격자는 첫 번째 요청으로 특정 Worker 프로세스의 전역 상태를 오염시킨 직후, HTTP/1.1 Keep-Alive 세션이나 동시 다발적 요청을 활용하여 **동일한 Worker 프로세스에 두 번째 HTTP 요청이 도달하도록 정밀하게 타이밍을 맞춥니다**.
+
+### 3.4 힙(Heap) 메모리 재할당 및 실행 흐름 가로채기 (Control Flow Hijacking)
+두 번째 요청이 오염된 Worker에 도착하면 PHP 메모리 관리자(Zend MM)는 방금 해제되었던 빈 힙 메모리 공간(Chunk)에 두 번째 요청의 데이터를 재할당(Re-allocation)합니다.
+
+공격자는 두 번째 요청의 바디에 특정 크기와 구조를 맞춘 가짜 VTable(Virtual Method Table) 및 함수 포인터 데이터를 배치합니다. PHP 엔진이 이전 요청에서 지우지 못하고 남겨둔 포인터를 진짜 유효한 구조체로 잘못 알고 메서드를 호출하는 순간, 실행 흐름이 공격자가 지정한 메모리 주소(ROP Gadget 등)로 분기되어 **원격 코드 실행(RCE)**이 달성됩니다.
+
+### 3.5 프로세스 메모리 잔류 데이터 및 세션 쿠키를 통한 정보 유출 (Memory Disclosure)
+`CVE-2026-109618` 취약점의 경우 RCE뿐만 아니라 심각한 정보 유출을 유발합니다:
+1. 세션 초기화 단계를 겨냥해 OOM을 유발하면, 세션 ID를 가리키던 포인터(`PS(id)`)가 해제된 힙 메모리 영역을 가리키게 됩니다.
+2. 해커가 두 번째 요청을 전송할 때, PHP 엔진은 해당 메모리 영역(이전 사용자들의 DB 비밀번호, API 키, 암호화 토큰, ASLR 우회용 메모리 주소가 잔류해 있던 공간)을 유효한 세션 ID 문자열로 잘못 알고 그대로 처리합니다.
+3. PHP는 이 메모리 데이터를 URL 인코딩하여 응답의 `Set-Cookie: PHPSESSID=...` 헤더에 담아 해커에게 그대로 반환하며, 해커는 쿠키 값을 디코딩하여 서버 내부 비밀 정보를 수집합니다.
+
+---
+
+## 4. 위협 동향 및 익스플로잇 실태 분석 (Threat Intelligence)
+
+### 4.1 AI(LLM) 및 자동화 도구를 활용한 공격 무기화
+이번 취약점은 10년 이상 PHP 코어 깊숙이 잠복해 있던 결함입니다. 보안 연구진(Wiz Research, Calif 등)은 **최신 대형 언어 모델(LLM)**과 자동화 디버깅 도구(GDB/LLVM 기반)를 결합하여, 과거 수개월 이상 소요되던 복잡한 OOM-UAF 체인 탐색 및 익스플로잇 개발 과정을 단 수시간 만에 완료했습니다.
+
+### 4.2 ASLR 방어막 무력화 및 2단계 공격 체인 (Exploit Chain)
+보안 전문가 Marcus Hutchins의 분석에 따르면, 인터넷에 확산된 단순 공격 코드는 실제 성공률이 매우 낮거나 서버 크래시(Crash)를 유발하는 데 그칩니다. 그 이유는 현대 운영체제의 **ASLR(Address Space Layout Randomization)** 기술이 메모리 주소를 무작위로 변경하기 때문입니다.
+
+안정적인 공격을 성공시키기 위해서는 다음과 같은 **2단계 연쇄 공격 체인(Exploit Chain)**이 필요합니다:
+* **[1단계] 메모리 유출(Memory Disclosure) 공격**: `CVE-2026-109618`을 활용해 응답 쿠키 등으로 프로세스 메모리 주소 및 모듈 베이스 주소를 먼저 알아냅니다.
+* **[2단계] ASLR 우회 및 RCE 실행**: 알아낸 메모리 주소를 바탕으로 정확한 ROP 가젯(Gadget) 주소를 계산한 뒤 두 번째 RCE 페이로드를 주입하여 실행합니다.
+
+---
+
+## 5. 서버 구성별 취약성 분석 매트릭스 (Server Architecture Matrix)
+
+| 서버 환경 구성 | 취약 여부 | 비고 및 공격 경로 |
+| :--- | :---: | :--- |
+| **Apache + mod_php (prefork)** | **O (최고 위험)** | 앱 소스코드와 무관하게 모든 요청 경로에서 직접적인 비인증 RCE 가능 |
+| **Apache + PHP-FPM** | **O (높음)** | `session_start()`, `unserialize()` 등 세션/역직렬화가 수행되는 경로에서 RCE 가능 |
+| **Nginx + PHP-FPM** | **O (높음)** | Apache + PHP-FPM과 동일. `client_max_body_size` 설정이 클수록 공격 용이 |
+| **FrankenPHP / LSAPI** | **O (주의)** | FPM과 유사하게 Worker 재사용 프로세스 환경에서 취약점 노출 가능 |
+
+---
+
+## 6. 대응 및 완화 방안 (Remediation & Mitigation)
+
+### 6.1 근본적인 해결책 (P0) - 패치 적용
+공식 패치를 적용하는 것만이 변종 공격까지 차단하는 **유일한 완전한 해결책**입니다.
+
+1. **PHP 코어 버전 즉시 업그레이드**:
+ * PHP 8.2 계열 $\rightarrow$ **8.2.35 이상**
+ * PHP 8.3 계열 $\rightarrow$ **8.3.36 이상**
+ * PHP 8.4 계열 $\rightarrow$ **8.4.27 이상**
+ * PHP 8.5 계열 $\rightarrow$ **8.5.12 이상**
+2. **웹 서버 서비스 재시작**:
+ * 업데이트 완료 후 `systemctl restart apache2` 또는 `systemctl restart php-fpm` 명령을 실행하여 메모리상의 기존 인스턴스를 반드시 교체해야 합니다.
+
+### 6.2 패치 적용 전 임시 완화 조치 (P1)
+즉시 패치가 불가능한 경우 다음 임시 조치를 통해 공격 경로를 부분 차단합니다:
+
+* **`php.ini` 설정 수정**:
+ ```ini
+ session.upload_progress.enabled = 0
+ session.auto_start = 0
+ ```
+* **WAF(웹 방화벽) 차단 룰 추가**:
+ * 요청 바디 내 `PHP_SESSION_UPLOAD_PROGRESS` 키워드 차단
+ * 빈 파일명 (`filename=""`) 및 복잡 중첩 필드(`a[b][c][d]`) 대량 전송 패턴 차단
+
+---
+
+## 7. 침해 여부 점검 및 포렌식 가이드 (Forensic & Detection Guide)
+
+시스템 관리자는 다음 Linux CLI 명령어를 통해 과거 침해 시도 흔적을 조사할 수 있습니다.
+
+1. **애플리케이션 실행 전 OOM 발생 에러 로그 검사**:
+ ```bash
+ grep -cE 'Allowed memory size of [0-9]+ bytes exhausted.*in Unknown on line 0' \
+ /var/log/php_errors.log /var/log/apache2/error.log /var/log/httpd/error_log /var/log/php*-fpm.log
+ ```
+2. **Worker 프로세스 Segmentation Fault 검사**:
+ ```bash
+ grep -E "Segmentation fault|signal 11|SIGSEGV" /var/log/apache2/error.log /var/log/php*-fpm.log
+ ```
+3. **응답 쿠키 내 메모리 유출 흔적 검사**:
+ * 웹 로그 또는 WAF 로그에서 `PHPSESSID` 쿠키 값이 비정상적으로 길거나 깨진 바이너리 텍스트 형태가 포함되어 있는지 확인합니다.
+
+---
\ No newline at end of file
|