PHP2Shell 취약점 대응 가이드 — 버전 확인·임시 설정 코드, 그리고 우리 서비스에 온 실제 공격을 막은 방법

PHP2Shell(CVE-2026-109618·109619)을 완전히 막는 방법은 PHP 업데이트 하나뿐입니다. 그리고 스캔은 그 사이트가 PHP로 만들어졌는지 묻지 않고 옵니다. PHP 보안팀은 2026년 10월 21일(한국 시간 밤 11시) 인증 없이 원격 코드 실행까지 이어질 수 있는 취약점 2건을 고친 PHP 8.5.12·8.4.27·8.3.36·8.2.35를 내놓고, 모든 PHP 사용자에게 즉시 업데이트하라고 강하게 권했습니다. 다음 날인 10월 22일, 엔큐솔루션이 개발·운영하는 실시간 언어 교육 플랫폼 하루(Haru)에도 PHP 설정 파일과 phpinfo 페이지를 찾는 자동 스캔이 99초 동안 276건 들어왔고, 한 건도 앱에 닿지 못했습니다. 하루는 PHP를 한 줄도 쓰지 않습니다.

이 글은 PHP2Shell의 내용과 영향 버전을 PHP 공식 공지 기준으로 정리하고, 지금 바로 쓸 수 있는 확인·완화·차단 코드를 붙였습니다. 이어서 하루에 실제로 들어온 공격 기록과 그것을 막은 구조를 공개합니다. 자료 기준일은 2026년 10월 22일 밤(한국 시간)입니다.

30초 요약 — ① PHP로 웹 요청을 처리하는 서버라면 PHP-FPM·mod_php·php-cgi를 가리지 않고 대상입니다. ② 8.5.12·8.4.27·8.3.36·8.2.35 이상으로 올리고 PHP 워커를 모두 재시작하세요. 설정 변경은 시간을 버는 임시 조치일 뿐입니다. ③ 공격 시도는 공개 나흘 전인 10월 17일부터 관측됐으니 로그는 그날부터 봅니다. ④ PHP를 안 쓰는 사이트에도 스캐너는 옵니다. 없는 파일을 찾는 요청은 앱까지 보내지 말고 앞단에서 끊고, 그 기록을 남겨 두세요.

PHP2Shell이란? (CVE-2026-109618·CVE-2026-109619)

PHP2Shell은 10월 21일 공개된 PHP 코어 취약점 2건을 함께 부르는 이름입니다. PHP 공식 공지는 이 별칭 없이 CVE 번호로만 부르지만, 보안 업계와 언론이 «php2shell»이라고 부르면서 이름이 굳었습니다. 두 건 모두 CVSS v4.0 9.2점이고, 인증 없는 원격 공격자가 악용할 수 있습니다.

PHP 보안팀이 밝힌 위험 범위는 «웹 요청을 처리하는 모든 PHP 설치»입니다. PHP-FPM, 아파치 mod_php, php-cgi, FrankenPHP, LiteSpeed가 모두 들어갑니다. 그중 위험이 가장 큰 쪽은 mod_php입니다. 앱 코드가 실행되기도 전에 인증 없는 요청 하나로 공격이 시작되는 공격 코드가 시연됐다고 공지는 적었습니다.

범위도 넓습니다. 서버 쪽 언어가 알려진 웹사이트의 69.3%가 PHP를 씁니다(W3Techs, Tenable 인용). 워드프레스, 그누보드, 라이믹스(XE)처럼 국내에서 많이 쓰는 CMS와 상당수 쇼핑몰 솔루션도 PHP 위에서 돕니다.

PHP2Shell 영향 버전과 수정 버전

리눅스 배포판과 LTS 업체는 패치를 미리 받았습니다. Tenable이 인용한 분석에 따르면 취약한 코드 경로는 PHP 5.4부터 있었습니다. 오래 손대지 않은 사이트일수록 고칠 길이 좁습니다.

타임라인: 공개 나흘 전부터 공격이 시작됐다

시각은 한국 시간이고, 10월 17·20일은 해외 출처의 날짜입니다. 침해에 성공한 사례가 확인됐는지는 기관마다 말이 다릅니다. 아마존은 광범위하게 악용되고 있다고 봤고(Tenable 인용), 와치타워는 보안뉴스에 «지금까지 성공한 곳은 없지만 그 상태가 오래가지는 않을 것»이라고 했습니다. 확실한 것은 이 취약점을 악용한다는 코드가 공개돼 돌고 있다는 점입니다. 그 코드가 실제로 작동하는지는 Tenable도 확인하지 못했고, 검증되지 않은 코드에는 악성코드가 섞여 있을 수 있습니다.

PHP2Shell 대응: 지금 할 일과 코드

아래 코드는 Debian·Ubuntu 계열에 PHP 8.3과 nginx를 쓰는 서버를 예로 들었습니다. 경로와 버전 숫자는 서버에 맞게 바꿉니다.

1. PHP 버전과 설정부터 확인합니다

명령줄 PHP와 웹이 쓰는 PHP(FPM)는 서로 다를 수 있으니 둘 다 봅니다.

php -v
php-fpm8.3 -v
# 이번 공지가 짚은 설정 값(명령줄 기준 — FPM 풀 설정이 덮어쓸 수 있다)
php -i | grep -E 'session.upload_progress.enabled|memory_limit|post_max_size'

워드프레스는 관리자 화면의 «도구 → 사이트 건강 → 정보 → 서버»에서, 호스팅은 호스팅사 관리 화면이나 공지에서 볼 수 있습니다.

2. 업데이트하고 워커를 모두 재시작합니다

sudo apt update
sudo apt install --only-upgrade php8.3-fpm php8.3-cli
sudo systemctl restart php8.3-fpm   # mod_php 라면 apache2 를 재시작

배포판 패키지는 PHP 버전 숫자(8.3.36)를 그대로 따르지 않고 고친 내용만 들여오기도 합니다. 이때는 배포판 보안 공지에 적힌 패키지 버전과 비교합니다. 8.1 이하라면 배포판·LTS 패치를 찾거나 지원 버전으로 옮깁니다.

3. 바로 못 올리면 임시 완화로 시간을 법니다

앱이 ini_set()으로 되돌리지 못하도록 FPM 풀 설정에 php_admin_*로 겁니다. .user.ini나 ini_set()으로는 효과가 없습니다.

; /etc/php/8.3/fpm/pool.d/www.conf — 업데이트 전까지만 쓰는 임시 조치
; CVE-2026-109619: 확인된 세션 경로를 막는다
php_admin_flag[session.upload_progress.enabled] = off
; CVE-2026-109618: 메모리 상한 실패 경로를 없앤다
php_admin_value[memory_limit] = -1
; 요청 크기를 줄인다(파일 업로드가 있으면 32M, upload_max_filesize 는 이보다 작게)
php_admin_value[post_max_size] = 8M
php_admin_value[upload_max_filesize] = 4M
; PHP 8.5 라면 추가
; php_admin_flag[fatal_error_backtraces] = off

메모리 상한을 풀었으니 서비스 전체에는 cgroup 단위로 경계를 둡니다. PHP 프로세스 자체의 주소 공간 제한(RLIMIT_AS·RLIMIT_DATA)은 오히려 취약한 경로를 부를 수 있어 쓰지 말라고 공지는 적었습니다.

# sudo systemctl edit php8.3-fpm — 가용성 경계일 뿐 완화책은 아니다
[Service]
MemoryMax=2G

설정을 바꾼 뒤에는 sudo systemctl restart php8.3-fpm으로 모든 워커를 다시 띄웁니다. PHP 보안팀은 이 조치들이 노출을 줄일 뿐 설치를 안전하게 만들지는 않는다고 못 박았습니다.

4. phpinfo·환경 파일·백업 파일을 웹에서 닫습니다

phpinfo 화면에는 PHP 버전, 서버 방식(FPM인지 mod_php인지), memory_limit, session.upload_progress.enabled가 그대로 나옵니다. 이번 공지가 짚은 조건이 한 화면에 다 있습니다. .env와 .git/이 열리면 DB 비밀번호와 API 키가 나갑니다. 파일은 지우는 것이 먼저이고, 남아 있어도 열리지 않게 막습니다.

# server { } 안, PHP 를 넘기는 location ~ \.php$ 보다 위에 둔다
# 숨김 파일(.env, .git …) — 인증서 발급 경로(.well-known)만 예외
location ~ /\.(?!well-known/) {
    return 404;
}
# 백업·임시 파일
location ~* (\.(bak|old|orig|save|swp|sql)|~)$ {
    return 404;
}
# phpinfo·테스트 파일 — 실제로 쓰는 파일과 이름이 겹치지 않는지 먼저 확인
location ~* /(phpinfo|info|test)\.php$ {
    return 404;
}

아파치를 쓰는 호스팅이라면 .htaccess로 같은 일을 합니다.

# .htaccess (Apache 2.4)
RedirectMatch 404 /\.(?!well-known/)
<FilesMatch "\.(bak|old|orig|save|swp|sql)$|^(phpinfo|info|test)\.php$">
    Require all denied
</FilesMatch>

.env가 한 번이라도 웹에서 열렸다면 그 안의 키와 비밀번호는 바꿉니다.

5. 10월 17일부터의 흔적을 봅니다

아마존은 공개일이 아니라 10월 17일부터 조사하라고 권고했습니다(Tenable 인용). 그날부터의 로그를 서버 밖에 떠 두고 아래를 봅니다.

# 10월 17일 이후 웹 루트에 새로 생기거나 바뀐 .php 파일 — 모르는 파일이면 웹셸을 의심
find /var/www -type f -name '*.php' -newermt '2026-10-17' -ls
# 접근 로그에서 설정·정보 파일 탐색 흔적(.gz 로 넘어간 로그까지)
zgrep -E 'phpinfo|/\.env|/\.git' /var/log/nginx/access.log*

관리자 계정이 새로 생기지 않았는지도 확인합니다. 패치를 끝낸 것과 침해당하지 않은 것은 다른 이야기입니다. 클라우드플레어 같은 WAF 규칙은 알려진 공격 경로만, 그 서비스를 거치는 트래픽만 막는 보조 수단입니다. 업데이트를 대신하지 못합니다.

실제 공격 기록: PHP를 쓰지 않는 우리 서비스에도 왔다

하루(Haru)는 엔큐솔루션이 개발·운영하는 실시간 언어 교육 플랫폼입니다. 백엔드는 Spring Boot(자바), 화면은 Next.js로 만들었고 PHP는 쓰지 않습니다. 그런데 PHP2Shell 패치가 나온 다음 날인 10월 22일 하루 동안 이런 요청이 들어왔고, 모두 실패했습니다.

React2Shell(CVE-2025-55182)은 2025년 12월 공개된 React 서버 컴포넌트의 원격 코드 실행 취약점입니다. 하루는 이미 고쳐진 버전을 쓰고 있었고 서버 액션을 하나도 쓰지 않아, 위조 요청이 실행될 수 없었습니다. 워드프레스 경로 가운데 휴대폰 브라우저로 들어온 1건은 사람이 직접 주소를 쳐 본 것일 수 있어 표에서 뺐습니다.

99초, 276건: 스캐너는 이 순서로 문을 두드렸다

20시 23분 14초에 들어온 스캐너는 순서가 분명했습니다. 처음 2초 동안 Next.js 서버 액션 위조(React2Shell 형태) 4건을 던지고, 74초 동안 .env 설정 파일 206곳을 뒤졌습니다. 이어서 18초 동안 PHP 정보 페이지 48곳, 마지막 5초 동안 구글 클라우드·파이어베이스 서비스 계정 키 파일 14곳을 찾았습니다.

.env를 찾을 때도 라라벨·워드프레스·드루팔 같은 PHP 프레임워크·CMS 폴더 13곳과 Next.js·Nuxt·React 같은 자바스크립트 프레임워크 폴더 10곳을 똑같이 뒤졌습니다. 이 스캐너는 하루가 무엇으로 만들어졌는지 확인하지 않고, 맞는 문이 하나라도 걸리면 된다는 방식으로 움직인 것으로 보입니다. phpinfo 경로 48곳은 PHP2Shell 공지가 짚은 조건을 한 화면에서 읽을 수 있는 곳이지만, 이 스캐너가 PHP2Shell을 노렸다고 단정할 근거는 없습니다. phpinfo 찾기는 원래 흔한 정찰입니다.

그 99초 동안 하루 서버에 남은 기록의 일부입니다. 필드 몇 개를 줄였고 IP는 가렸습니다.

20:23:14.653 WARN security-probe blocked ip=34.18.x.x method=POST uri=/ bodyBytes=748 incident=HARU-SEC-45
20:23:16.453 WARN security-probe blocked ip=34.18.x.x method=GET uri=/.env bodyBytes=0 incident=HARU-SEC-50
20:23:17.165 WARN security-probe blocked ip=34.18.x.x method=GET uri=/.env.production bodyBytes=0 incident=HARU-SEC-52
20:23:40.960 WARN security-probe blocked ip=34.18.x.x method=GET uri=/laravel/.env bodyBytes=0 incident=HARU-SEC-118
20:24:30.787 WARN security-probe blocked ip=34.18.x.x method=GET uri=/phpinfo.php bodyBytes=0 incident=HARU-SEC-147
20:24:31.141 WARN security-probe blocked ip=34.18.x.x method=GET uri=/info.php bodyBytes=0 incident=HARU-SEC-147
20:24:48.527 WARN security-probe blocked ip=34.18.x.x method=GET uri=/service-account.json bodyBytes=0 incident=HARU-SEC-147
20:24:52.831 WARN security-probe blocked ip=34.18.x.x method=GET uri=/firebase-adminsdk.json bodyBytes=0 incident=HARU-SEC-147

어떻게 막았나: 하루의 방어 구조

배포 전에 들어온 공격이 모두 실패한 것은 고쳐진 버전을 쓰고 있었기 때문입니다. 하루는 React2Shell이 고쳐진 Next.js·React 버전을 쓰고, 서버 액션을 쓰지 않습니다. PHP 사이트라면 이 자리에 «8.5.12·8.4.27·8.3.36·8.2.35 이상»이 들어갑니다. 같은 날 오후에는 여기에 앞단 차단과 기록을 더했습니다.

1. 정상 기능이 절대 보내지 않는 요청만 앞단에서 끊습니다

nginx가 요청을 앱에 넘기기 전에 네 가지를 판정합니다. 서버 액션 헤더가 붙은 요청, 주소·브라우저 정보에 든 주입 문자열(Log4Shell, 상위 폴더 거슬러 오르기, SQL·명령 주입, 이름을 밝힌 공격 도구), 이 사이트에 없는 민감 파일·관리 도구 경로(.env, .git, *.php, wp-admin, phpMyAdmin, 백업 파일), 그리고 페이지 주소로 온 쓰기 요청입니다. 걸리면 화면이나 API로 넘기지 않고 기록 창구로만 보냅니다.

아래는 그날 처음 넣은 서버 액션 위조 차단 코드입니다. 서버 액션이 하나도 없는 앱에서는 Next-Action 헤더가 붙은 요청이 전부 외부 스캔입니다.

# 이 앱에는 서버 액션이 없다("use server" 0개) — Next-Action 헤더가 붙은 요청은 전부 위조
# if ($http_next_action) 으로 바로 쓰면 값이 "0" 인 요청이 통과한다. map 으로 비었을 때만 0
map $http_next_action $next_action_probe {
    ""      0;
    default 1;
}

server {
    # server 단계에서 돌아 모든 경로에 걸리고, 요청 본문은 앱으로 보내지 않는다
    # 나중에 서버 액션을 도입하면 이 차단부터 지운다
    if ($next_action_probe) {
        return 403;
    }
}

if ($http_next_action)처럼 헤더 값을 바로 조건에 쓰면 nginx는 값이 «0»인 요청을 거짓으로 보고 통과시킵니다. 스캐너가 가짜 액션 ID로 0을 보내는 경우가 실제로 있어서, map으로 «헤더가 비었을 때만 0»을 만든 뒤 판정합니다. 지금 운영 설정은 이 판정을 앞의 네 가지로 넓혀 403과 함께 기록 창구로 넘깁니다.

2. 공격자에게는 경고문과 사건 번호를 돌려줍니다

막힌 요청에는 403과 함께 영어·한국어 경고문이 갑니다. 20시 24분 30초에 /phpinfo.php를 찾은 스캐너가 받은 응답의 한국어 부분입니다.

403 Forbidden
… (영문 경고문 생략)
----
이 요청은 서비스에 대한 무단 접근·공격 시도로 판단되어 차단되었습니다.
정당한 접근 권한 없이 정보통신망에 침입하는 행위는 「정보통신망 이용촉진 및 정보보호 등에 관한 법률」 제48조에 따라 금지되어 있습니다.
이 시도의 출발지 IP, 시각, 요청 내용(헤더와 본문 일부)은 기록되어 보관되며, 망 사업자와 수사기관에 제공될 수 있습니다.
사건 번호: HARU-SEC-147

경고문에는 실제로 하는 일만 적었습니다.

3. 공격 기록을 따로 보관합니다

막힌 요청마다 출발지 IP, 시각, 원래 주소, 브라우저 정보, 요청 헤더(쿠키·인증 값은 길이만), 본문 일부를 일반 로그와 다른 별도 기록에 남기고, 자동으로 지워지지 않게 했습니다. 같은 요청이 반복되면 한 줄에 횟수만 올려 기록이 무한정 불어나지 않게 했습니다. 로그인 대입·API 탐색처럼 원래 일정 기간이 지나면 사라지던 판정도 같은 기록으로 옮겨 적습니다. 관리자 화면 «보안 점검 → 공격 기록»에서 종류와 IP로 찾아봅니다.

4. 로그를 서버 밖에 보관합니다

백엔드 로그, 컨테이너 콘솔 출력, nginx 접근 로그(JSON)를 1분마다 외부 저장소로 올려 1년 보존하도록 했습니다. 종료 직전에도 남은 몫을 올리게 해서, 재배포할 때 마지막 줄까지 남기도록 했습니다. 정상 요청의 쿼리 값처럼 개인 정보가 섞일 수 있는 부분은 가리고 남깁니다.

배포 결과는 같은 날 저녁에 바로 확인됐습니다. 15시 57분 배포 뒤 22시 40분까지 앞단에서 막힌 요청은 281건이었고, 그중 276건이 20시 23분의 그 스캐너였습니다. 막힌 요청은 모두 화면·API에 닿지 않았고, 출발지·시각·주소와 함께 사건 번호가 붙어 기록됐습니다.

PHP 사이트라면: 하루의 방식을 옮기면 이렇습니다

엔큐솔루션은 보안 점검을 마지막에 따로 하는 일이 아니라 개발하면서 함께 하는 일로 봅니다. 접근 권한과 최소 권한, 입력 검증, 의존성 업데이트와 보안 패치, 비밀 정보 분리, 출시 전 노출 점검, 사람이 하는 코드 리뷰가 그 내용이고 보안 정책에 공개해 두었습니다. 하루에 넣은 차단·기록 방식은 우리가 운영하는 서비스에서 쓴 사례이고, 어떤 점검과 기록이 필요한지는 프로젝트 성격에 맞게 함께 정합니다.

오래된 PHP 버전에 묶여 업데이트가 어려운 사이트라면, 지원 버전으로 옮기거나 새로 만드는 쪽이 근본 해결이 될 수 있습니다. 사이트 주소와 지금 쓰는 호스팅·CMS를 정리해 프로젝트 문의로 보내 주시면 옮길지, 새로 만들지 범위와 비용을 같이 봅니다. 만드는 범위는 홈페이지·웹서비스와 업무 시스템·AI 자동화 안내에 정리해 두었습니다.

자주 묻는 질문

PHP2Shell이란 무엇인가요?

2026년 10월 21일 공개된 PHP 코어의 원격 코드 실행 취약점 2건(CVE-2026-109618, CVE-2026-109619)을 함께 부르는 이름입니다. 둘 다 CVSS v4.0 9.2점이고 인증 없는 원격 공격자가 악용할 수 있습니다. 하나는 메모리 부족 처리 중 반쯤 만들어진 요청 데이터를, 다른 하나는 해제된 메모리를 가리키는 남은 요청 상태를 문제 삼습니다.

내 사이트가 PHP2Shell 영향을 받나요?

PHP로 웹 요청을 처리한다면 대상입니다. PHP-FPM, 아파치 mod_php, php-cgi, FrankenPHP, LiteSpeed가 모두 해당하고, 워드프레스·그누보드·라이믹스 같은 PHP 기반 CMS 사이트도 들어갑니다. PHP 버전이 8.5.12·8.4.27·8.3.36·8.2.35보다 낮다면 업데이트가 필요합니다.

PHP 버전은 어떻게 확인하나요?

서버에서 php -v와 php-fpm -v(배포판에 따라 php-fpm8.3 -v)를 함께 확인합니다. 명령줄과 웹이 서로 다른 PHP를 쓸 수 있기 때문입니다. 배포판 패키지는 버전 숫자 대신 배포판 보안 공지의 패키지 버전과 비교합니다. 워드프레스는 «도구 → 사이트 건강 → 정보 → 서버»에서, 호스팅은 관리 화면이나 호스팅사 공지에서 볼 수 있습니다. 확인하려고 phpinfo 파일을 만들었다면 확인 직후 지웁니다.

바로 업데이트할 수 없으면 어떻게 하나요?

FPM 풀 설정에 php_admin_flag[session.upload_progress.enabled] = off, php_admin_value[memory_limit] = -1, 낮은 post_max_size를 넣고 모든 워커를 재시작합니다. 메모리 제한은 cgroup 단위로 겁니다. PHP 보안팀은 이 조치들이 노출을 줄일 뿐 설치를 안전하게 만들지는 않는다고 밝혔습니다. 업데이트까지 시간을 버는 용도입니다.

호스팅을 쓰면 호스팅사가 알아서 패치하나요?

호스팅사마다 다릅니다. 카페24는 10월 21일 오전 11시 30분부터 선제 완화 조치를 하고, 같은 날 밤 11시 30분부터 PHP 8.2 이상 서비스에 같은 계열 최신 버전을 적용한다고 공지했습니다. 8.1 이하를 쓰는 서비스는 이 패치 대상이 아니므로 지원 버전으로 옮겨야 합니다. 쓰고 있는 호스팅사의 공지를 직접 확인하세요.

PHP를 쓰지 않으면 안전한가요?

PHP2Shell 자체에는 해당하지 않지만 스캐너는 옵니다. PHP를 쓰지 않는 하루(Haru)에도 10월 22일 99초 동안 .env 206건, phpinfo 48건을 포함한 276건이 들어왔습니다. 스캐너는 대상의 언어를 확인하지 않고 알려진 경로를 한꺼번에 던집니다. 환경 파일과 저장소 폴더가 웹에서 열리지 않는지는 어떤 언어로 만든 사이트든 확인해야 합니다.

phpinfo 페이지는 왜 위험한가요?

PHP 버전, 서버 방식(FPM·mod_php), memory_limit, session.upload_progress.enabled 같은 설정이 그대로 보이기 때문입니다. PHP2Shell 공지가 짚은 조건이 한 화면에 다 있는 셈이라 공격 대상을 고르는 데 쓰일 수 있습니다. 확인이 끝나면 바로 지우고, 웹 서버에서도 열리지 않게 막습니다.

React2Shell과 PHP2Shell은 같은 취약점인가요?

다릅니다. React2Shell(CVE-2025-55182)은 2025년 12월 공개된 React 서버 컴포넌트의 원격 코드 실행 취약점이고, PHP2Shell은 2026년 10월 공개된 PHP 코어 취약점입니다. 다만 하루(Haru)에 들어온 스캐너는 Next.js를 노린 React2Shell 형태의 요청과 PHP 정보 페이지 탐색을 한 번에 보냈습니다. PHP2Shell을 노린 것인지는 알 수 없지만, 무엇으로 만든 사이트인지 가리지 않고 열린 문을 찾는다는 점은 분명합니다.

출처

• PHP 공식 사이트 공지, 2026년 10월 20~21일: 긴급 보안 릴리스 예고, 보안 권고(영향 범위 PHP-FPM·mod_php·php-cgi·FrankenPHP·LiteSpeed와 mod_php 최고 위험, 두 취약점 설명, CVSS v4.0 9.2), 수정 버전 8.5.12·8.4.27·8.3.36·8.2.35, 7.4·8.0·8.1 최소 백포트, 임시 완화(memory_limit·post_max_size·session.upload_progress.enabled·fatal_error_backtraces, php_admin_value, cgroup 제한, RLIMIT_AS·RLIMIT_DATA 금지)와 «완전한 해결은 업데이트뿐», 8.2 지원 종료일.
• Tenable, php2shell 자주 묻는 질문: 아마존 10월 17일 허니팟 관측과 조사 시작일 권고, CVE 유출과 릴리스 일정 당김, 클라우드플레어 WAF, W3Techs 69.3%, PHP 5.4부터의 코드 경로, 7.3 이하 지원 종료.
• 보안뉴스, 2026년 10월 22일: 각국 보안 경보, 와치타워 발언, 임시 조치.
• 안랩 ASEC 보안 권고, 2026년 10월 21일: CVE 번호·CVSS 9.2, 패치 공개 예정 시각.
• 카페24 공지: PHP 긴급 보안 취약점 조치·PHP 공식 보안 패치 적용: 10월 21일 오전 11시 30분 선제 완화, 밤 11시 30분 PHP 8.2 이상 패치 적용.
• 하루(Haru) 운영 기록(엔큐솔루션 자체): 2026년 10월 22일 서버 로그와 공격 기록, 실제 nginx 설정과 경고문. 출발지 IP는 뒤 두 자리를 가렸습니다.
• 앞선 보안 글: ARTEX(아르텍스) 직접 돌려봤다 — 은행 해킹 AI, 43초 실험부터 금융권 해킹 원인까지

PHP 공식 공지, 보안 업체 분석, 언론 보도, 하루 운영 기록을 구분해 적었습니다. 코드 예시는 Debian·Ubuntu와 nginx 기준의 예시이니 서버 구성에 맞게 바꿔 쓰세요. 자료 기준일은 2026년 10월 22일 밤(한국 시간)이며, 공격 현황과 권고는 바뀔 수 있습니다.