아래 안내 장(취약점 설명, 임시 조치, 공격 흔적 등)은 PHP 취약점(PHP2Shell) 기준입니다. nginx·Apache·Tomcat은 결과 화면의 조치 안내와 각 제품의 공식 보안 공지를 확인하세요.

PHP 프로젝트는 2026년 10월 21일, 로그인 없이 원격에서 코드를 실행할 수 있는 취약점 2건을 공개하고 수정 버전을 배포했습니다. 두 취약점을 함께 PHP2Shell이라고 부르며, 심각도는 둘 다 10점 만점에 9.2점입니다.

• 웹 요청을 처리하는 PHP 실행 방식(PHP-FPM, Apache mod_php, php-cgi, FrankenPHP, LiteSpeed)이 대상이며, PHP 측은 mod_php의 위험을 가장 높게 봅니다.
• 공격에 성공하면 웹 작업 프로세스 권한으로 코드가 실행되고, 작업 프로세스 메모리에 있던 비밀번호나 API 키가 노출될 수 있습니다.
• 홈페이지뿐 아니라 PHP를 내장한 장비의 관리 화면(NAS, 방화벽 등)도 영향을 받을 수 있습니다. 이런 제품은 제조사 패치를 받아야 합니다.

수정 버전이 나오기 전부터 취약점 정보가 유출됐고, 해외 보안업체들이 실제 공격 시도를 관측했습니다. 일부 업체는 공개 전인 10월 17일부터 시도가 있었다고 밝혔습니다.

• PHP 보안팀은 발표 시점에 유출된 공격 코드들을 확인했으나 실제로 동작하는 것은 찾지 못했다고 밝혔습니다. 공개된 공격 코드는 기본 설치 상태에서는 잘 동작하지 않고, 대개 홈페이지에 별도의 파일 포함 취약점이 있어야 한다는 분석도 있습니다.
• 그렇다고 안전한 것은 아닙니다. 공격 방법은 계속 바뀌므로 업데이트가 필요합니다.
• 이 페이지와 공개 점검 도구는 공격 요청을 보내지 않고 버전 정보만 확인합니다.
• 인터넷에 ‘PHP2Shell 공격 코드’라는 이름으로 도는 파일은 출처를 확인할 수 없고 악성코드가 섞여 있을 수 있습니다. 운영 서버나 업무용 PC에서 실행하지 마세요. 공격 여부는 ‘공격 흔적 확인하기’처럼 로그로 확인하세요.

이 페이지는 응답 헤더에 표시된 버전만 봅니다. 버전이 숨겨져 있거나 배포판 패키지를 쓰는 경우 서버에서 직접 확인해야 정확합니다. 명령줄의 PHP와 웹에서 실제로 쓰는 PHP가 다를 수 있으니 둘 다 확인하세요.

1. 명령줄 PHP 버전

						php -v
					

2. 웹에서 실제로 쓰는 PHP 버전

웹 문서 폴더에 확인용 파일을 잠시 만들어 서버 안에서만 열어 보고, 확인 즉시 지웁니다. 아래는 웹 문서 폴더가 /var/www/html인 경우의 예입니다.

• 외부에서 접근하지 못하도록 이름을 추측하기 어렵게 정하고, 확인은 서버 안에서만 하세요.
• 같은 이름의 파일이 이미 있으면 덮어쓰지 않도록 먼저 확인하세요.
• localhost로 연 가상호스트가 실제 점검 대상 사이트와 같은지 확인하세요. 사이트가 여러 개면 해당 사이트의 웹 문서 폴더와 주소로 확인해야 합니다.
• 확인이 끝나면 즉시 지우고, 지워졌는지 다시 확인하세요.

F=/var/www/html/_phpver_$(date +%s%N).php
test -e "$F" && echo '이미 있음: 다른 이름 사용' || echo '/dev/null
curl -s "http://localhost/$(basename "$F")"
sudo rm -f "$F" && test ! -e "$F" && echo '삭제 확인'

3. 배포판 패키지 버전

# Ubuntu·Debian: 웹에서 쓰는 패키지(php8.3-fpm, libapache2-mod-php8.3 등) 확인
dpkg-query -W -f=' 
' 'php*-fpm' 'libapache2-mod-php*'
# RHEL·Rocky 계열
rpm -q --queryformat '%{NAME} %{VERSION}-%{RELEASE}
' php-fpm php-common

배포판은 버전 숫자는 그대로 두고 보안 패치만 넣습니다. 아래 표는 같은 OS 릴리스·패키지 계열·저장소 조건에서 비교해야 하며, 그 조건에서 표의 버전 이상이면 두 취약점(CVE-2026-109618, CVE-2026-109619)이 수정된 패키지입니다. 표에 없는 배포판이나 조건은 해당 배포판의 보안 공지를 확인하세요.

표의 확인 기준일은 2026년 10월 22일이며, 이후 변경 사항은 각 배포판 공식 보안 공지가 우선합니다. 표 갱신은 서비스 운영 주체가 담당합니다. CVE-2026-115560은 아직 수정 패키지가 없어 이 표에 포함되지 않습니다.

• Debian 보안 추적 CVE-2026-109618
• Ubuntu 보안 공지 USN-8948-1
• Red Hat CVE-2026-109618

패키지를 업데이트했어도 웹 작업 프로세스를 재시작하지 않았다면 이전 버전이 계속 실행됩니다.

업데이트가 근본 해결책입니다. 작업 전에 설정 파일과 데이터를 백업하고, 가능하면 테스트 서버에서 먼저 확인하세요.

# Ubuntu·Debian
sudo apt update && sudo apt install --only-upgrade 'php*'
# RHEL·Rocky 계열
sudo dnf upgrade 'php*'
# 업데이트 후 PHP를 실행하는 프로세스를 모두 재시작 (reload로는 부족)
sudo systemctl restart php8.3-fpm   # 사용 중인 FPM 서비스 모두
sudo systemctl restart apache2      # RHEL 계열은 httpd

• 같은 계열의 보안 업데이트도 사용 중인 확장 모듈, 플러그인 및 업무 기능에 영향을 줄 수 있습니다. 변경 전 백업과 사전 검증을 진행하고, 변경 후 주요 기능의 정상 동작을 확인하세요.
• 계열을 바꾸는 업그레이드(예: 7.4 → 8.3)는 홈페이지 프로그램, 플러그인, 확장 모듈이 동작하지 않을 수 있으니 반드시 먼저 테스트하세요.
• 8.1 이하 계열은 PHP 프로젝트의 정식 패치 릴리스가 없습니다. 배포판·유지보수 업체의 보안 패키지를 확인하거나 지원 중인 계열로 이전하세요.
• Docker 등 컨테이너는 기본 이미지를 새 버전으로 바꾼 뒤 다시 빌드·배포해야 합니다.
• 호스팅이나 관리형 서비스를 쓰면 직접 바꿀 수 없으니 관리업체에 확인하세요.
• 업데이트 후에는 임시로 바꾼 설정을 원래대로 돌리세요. 다만 session.upload_progress.enabled = 0은 추가 권고(CVE-2026-115560) 때문에 유지하는 것이 좋습니다.

어떤 설정도 공격을 완전히 막지는 못합니다. 업데이트 전까지 노출을 줄이는 조치이며, 서비스 영향이 적은 공통 조치와 서버 관리자가 판단해야 하는 상세 조치로 나눠 안내합니다.

공통 조치 (영향이 적음)

업로드 진행률 표시 기능만 꺼집니다. 파일 업로드 자체에는 영향이 없습니다. 추가 권고(CVE-2026-115560)의 임시 조치이기도 합니다.

; php.ini (FPM, Apache 모듈 등 사용하는 설정 폴더마다)
session.upload_progress.enabled = 0

• php.ini 또는 PHP-FPM 풀 설정에 넣으세요. .user.ini나 ini_set()은 요청을 해석한 뒤에 적용되어 효과가 없습니다.
• 바꾼 뒤에는 모든 PHP 프로세스를 재시작하세요. reload로는 부족합니다.

관리자용 상세 조치 (장애 가능성 있음)

아래 조치는 운영 환경에 따라 메모리 고갈, 성능 저하 또는 업로드 기능 장애를 유발할 수 있습니다. 서버 관리자가 자원 제한, 서비스 영향 및 복구 절차를 확인한 뒤 적용하세요. 적용 전 설정 파일을 백업하고, 테스트 환경에서 먼저 검증하고, 문제가 생기면 백업한 설정으로 되돌린 뒤 재시작하세요.

multipart 요청 차단 예시: 업로드가 필요한 경로가 있다면 해당 경로를 예외로 두는 설정을 먼저 추가하세요.

# nginx: http 블록
map $http_content_type $deny_multipart {
    default 0;
    "~*multipart" 1;
}
# PHP로 넘기는 server 블록 안
if ($deny_multipart) { return 403; }
# Apache 2.4: PHP를 처리하는 vhost

    Require all denied

memory_limit = -1은 프로세스 메모리 상한을 함께 걸 때만 적용하세요. Apache RLimitMEM 같은 RLIMIT_AS·RLIMIT_DATA 방식은 오히려 취약한 경로를 일으키므로 쓰지 말고, 컨테이너나 systemd의 메모리 제한(cgroup)을 쓰세요.

요청별 PHP 설정 점검

요청 처리 중에 적용되는 PHP 설정(.htaccess의 php_value, nginx의 PHP_VALUE 등) 가운데, 잘못되었거나 폐기된 지시어처럼 초기화 단계에서 경고·오류를 내는 설정이 확인된 유발 조건입니다. 이런 설정을 찾아 고치거나 php.ini·PHP-FPM 풀로 옮기세요. 정상적으로 필요한 설정까지 지울 필요는 없으며, 옮길 때는 기존 기능에 영향이 없는지 확인하세요.

적용됐는지 확인하기

항목별로 설정한 목표값과 일치하는지 확인하세요. 서비스 중인 PHP-FPM 풀과 사이트별 덮어쓰기 설정도 확인해야 하며, 명령 출력만으로 모든 웹 요청에 적용되었다고 판단하지 마세요.

						php-fpm8.3 -i | grep -E 'session.upload_progress.enabled|post_max_size|memory_limit'
					

cPanel(EasyApache 4) 서버

NCSC-NL이 공개한 스크립트는 서버의 모든 ea-php 버전에 업로드 진행률 끄기와 요청 크기 상한을 한꺼번에 넣습니다. 서버 전체 PHP 설정이 바뀌고, 적용 시 웹서버와 PHP-FPM이 재시작되어 잠시 서비스가 끊길 수 있습니다. 옵션 없이 실행하면 바꾸지 않고 계획만 보여주므로 먼저 확인하세요.

curl -O https://raw.githubusercontent.com/NCSC-NL/php2shell/main/detection_mitigation/cpanel/php2shell-mitigate.sh
less php2shell-mitigate.sh   # 내용 먼저 검토
sudo bash php2shell-mitigate.sh   # 계획만 표시 (변경 없음)
sudo bash php2shell-mitigate.sh --apply   # 적용, 재시작 발생
sudo bash php2shell-mitigate.sh --rollback --apply   # 되돌리기

효과가 없는 방법

• 오류 숨기기(display_errors = 0, error_reporting 조정)
• file_uploads = Off (PHP는 여전히 multipart 본문을 해석함)
• 홈페이지 프로그램 안의 점검(로그인, CSRF 확인, 보안 플러그인) — 공격은 프로그램이 실행되기 전에 일어남
• CDN·웹방화벽 차단만 하는 경우 — 서버 IP로 바로 들어오는 요청은 그대로 통과함

PHP 버전이 응답 헤더에 보이면 공격자가 취약한 서버를 쉽게 골라냅니다. 숨긴다고 취약점이 사라지지는 않으므로 업데이트가 먼저입니다. Apache에 PHP 모듈을 쓰는 경우 Server 헤더에도 PHP 버전이 붙을 수 있어 웹서버 설정도 함께 확인하세요.

; php.ini — X-Powered-By 헤더에서 PHP 버전 제거
expose_php = Off
# Apache — Server 헤더에 붙는 버전 제거
ServerTokens Prod
# nginx — PHP가 보내는 X-Powered-By 제거
fastcgi_hide_header X-Powered-By;

						# 확인: 헤더에 PHP 버전 숫자가 없어야 함 curl -sI https://내사이트/ | grep -iE '^(server|x-powered-by):'
					

버전을 숨기면 이 페이지의 주소 점검 결과는 “버전 정보만으로 확인 불가”로 나옵니다. 정상이며, 실제 버전과 패치 적용 여부는 서버에서 직접 확인하세요.

아래 징후가 있다고 반드시 공격당한 것은 아니며, 없다고 안전한 것도 아닙니다. 로그는 10월 17일 이후부터 살펴보세요.

• 비정상적인 multipart 요청 뒤에 메모리 부족 오류나 HTTP 500이 반복됨
• PHP_SESSION_UPLOAD_PROGRESS 값이 들어 있는 POST 요청
• 비정상적으로 크거나 깨진 PHPSESSID 쿠키 응답
• PHP 작업 프로세스가 이유 없이 죽거나 재시작됨
• php-fpm, httpd, apache2 같은 PHP 프로세스가 셸이나 다운로드 도구를 실행함
• 웹 문서 폴더의 낯선 PHP 파일(웹셸), 새 예약 작업(cron), 새 사용자 계정
• 서버에서 외부로 나가는 낯선 연결

침해가 의심되면 서버를 격리하고 로그를 보존한 뒤, 서버에 있던 비밀번호·토큰·키를 바꾸세요. 업데이트만으로는 공격자가 남긴 것이 지워지지 않습니다. 118 전화 상담은 신고와 별개이므로, 침해사고 신고는 보호나라 신고하기로 진행하세요.

단계별로 체크하며 진행하세요. 화면에서 체크한 내용은 저장되지 않습니다.

확인 단계

• 운영하는 PHP 홈페이지와 PHP가 들어간 장비(관리 화면 포함)를 모두 파악했다
• 이 페이지의 참고 결과와 함께, 서버에서 웹 실행 버전과 패키지 버전을 직접 확인했다
• 배포판 패키지를 쓰는 경우 같은 OS 릴리스의 배포판 보안 공지와 비교했다

조치 단계

• 정식 수정 버전(8.5.12 / 8.4.27 / 8.3.36 / 8.2.35) 이상 또는 배포판 수정 패키지를 적용했다
• 8.1 이하 서버는 배포판·유지보수 업체의 보안 패치를 확인했거나 지원 중인 계열로의 이전 일정을 정했다
• 8.2 서버는 지원 종료(2026년 12월 31일) 전 상위 계열로 이전할 일정을 정했다
• PHP를 실행하는 프로세스를 모두 재시작했고, 컨테이너는 새 이미지로 다시 배포했다
• session.upload_progress.enabled = 0 을 적용했다 (추가 권고 CVE-2026-115560 포함)
• 관리업체가 관리하는 곳은 보안 공지 번호·패키지 버전·프로세스 반영 여부를 확인받았다

마무리 단계

• 10월 17일 이후 로그와 웹 문서 폴더에서 공격 흔적을 살펴봤다
• PHP 버전 정보를 숨겼다
• 로그인, 게시판 업로드, 결제 같은 주요 기능이 정상 동작한다
• 업데이트 후 임시로 바꾼 설정(memory_limit 등)을 원래대로 돌렸다

배포판 패치나 버전 비공개 설정 때문에 이 페이지의 결과는 조치 후에도 바뀌지 않거나 확인 불가로 표시될 수 있습니다. 조치 완료 여부는 위 확인 근거로 판단하세요.

결과의 세 가지 표시는 무슨 뜻인가요?

“취약 영향 범위의 버전 정보 확인”은 응답 헤더의 버전이 이번 취약점의 영향 범위에 해당한다는 뜻, “수정 버전 이상의 정보 확인”은 수정 버전 이상이 표시된다는 뜻, “버전 정보만으로 확인 불가”는 버전 정보만으로는 판단할 수 없다는 뜻입니다. 모두 버전 정보를 비교한 참고 결과이며, 실제 취약 여부와 패치 적용 여부는 서버 운영자 또는 관리업체를 통해 확인해야 합니다.

“수정 버전 이상의 정보 확인”이 나오면 조치가 끝난 건가요?

아닙니다. 응답 헤더의 버전만 확인한 것이므로, 실제 적용 패키지와 실행 프로세스 반영 여부, 추가 보안 권고(CVE-2026-115560) 대응 여부를 확인해야 합니다. 침해가 의심되면 별도의 사고 대응이 필요합니다.

업데이트했는데 결과가 그대로이거나 확인 불가로 나와요.

배포판은 버전 숫자를 유지한 채 보안 패치를 넣는 경우가 많고, 버전을 숨기도록 설정하면 확인 불가로 나옵니다. 이 경우 관리업체에 적용한 보안 공지 번호, 패키지 버전, 실행 프로세스 반영 여부를 확인하세요.

점검하면 우리 홈페이지에 영향이 있나요?

일반 브라우저가 첫 화면을 여는 것과 같은 요청을 몇 번 보내고 응답 헤더만 읽습니다. 주소를 어떻게 적었든 https, http, www를 붙이거나 뗀 주소를 함께 확인해 같은 기준으로 판정하며, 결과 화면에 판정에 쓴 주소를 보여드립니다. 공격 요청이나 많은 양의 요청을 보내지 않으며, 홈페이지에 아무것도 설치하거나 바꾸지 않습니다.

점검할 때 수집하는 정보가 있나요?

서비스 운영을 위해 점검 시 접속 IP를 수집합니다.

다른 기관이나 남의 홈페이지도 점검할 수 있나요?

운영 중이거나 관리 권한을 받은 홈페이지만 점검해 주세요. 그래서 주소로 점검할 때는 확인란에 체크해야 합니다. 버전 숫자만 넣는 경우는 어디에도 접속하지 않으므로 체크하지 않아도 됩니다.

호스팅 업체를 쓰는데 무엇을 해야 하나요?

결과 화면의 “호스팅·외주 업체가 관리해요” 탭에 있는 참고 문구를 계약 범위에 맞게 고쳐 업체에 보내세요. 업체가 PHP 업데이트를 담당하지 않을 수도 있으니 관리 범위부터 확인하세요.

어디에 문의하나요?

점검 서비스 문의와 해킹 의심 상담은 118(KISA 상담센터), 침해사고 신고는 보호나라 신고하기, 실제 패치 적용 여부는 서버 운영자나 관리업체가 창구입니다. 이 페이지 아래 ‘문의와 신고’에서 확인하세요.

• KISA 보안 취약점 정보 포털
• PHP 공식 보안 공지 (php.net)
• PHP 보안 권고 CVE-2026-109618 (GitHub)
• PHP 보안 권고 CVE-2026-109619 (GitHub)
• CERT-EU 보안 권고 2026-018

• openai/php2shell-checker 주소를 넣으면 응답 헤더의 PHP 버전으로 판정하는 공개 점검 스크립트입니다(Apache-2.0, Node.js 필요). 함께 공개된 서버 점검 안내(phpcheck-server)에 배포판별 수정 패키지 버전이 정리되어 있습니다. 이 도구의 안내만을 근거로 삼지 말고 배포판 공식 공지와 함께 확인하세요.
• NCSC-NL/php2shell 네덜란드 국가사이버보안센터가 공개한 자료입니다. cPanel(EasyApache 4) 서버용 임시 완화 일괄 적용 스크립트와, PHP를 내장해 영향을 받는 제품 목록이 있습니다. 스크립트는 서버 관리자가 적용 범위와 재시작 영향을 확인한 뒤 사용하세요.

외부 도구는 내려받은 뒤 내용을 확인하고 실행하세요. 같은 이름의 출처 불명 파일은 실행하지 마세요.