KISA가 경고한 PHP 신규 결함… 3대 조건 겹친 서버만 뚫린다

한국인터넷진흥원(KISA)이 지난 24일 PHP의 신규 원격 코드 실행(RCE) 취약점(CVE-2026-115560)에 대해 임시 조치를 긴급 권고했다. 지난 21일 공개된 취약점 ‘PHP2Shell’ 패치를 마친 서버라도 이번 결함은 막히지 않는다. 다만 전면적으로 열렸던 PHP2Shell과 달리 3가지 특수 설정이 겹친 환경에서만 공격 경로가 성립한다. 공식 보안 패치는 아직 없지만, 차단 방법은 설정 한 줄이다.

사흘 새 몰린 KISA 긴급 보안 권고 3건

웹 애플리케이션을 구동하는 핵심 서버 언어 PHP를 둘러싸고 최근 긴급 보안 공지가 잇따랐다. KISA는 지난 21일 PHP2Shell로 명명된 취약점 2건에 대해 보안 업데이트를 권고했다. 이어 22일에는 기업 정보보호 담당자를 위한 8대 대응 수칙을 별도로 발표했다. 앞서 본지의 22일 심층 분석에서도 PHP2Shell의 침투 구조와 패치 경위를 집중 조명한 바 있다.

하지만 사흘 만에 발표된 3번째 공지는 성격이 전혀 다르다. 제목 역시 ‘보안 업데이트 권고’가 아닌 ‘임시 조치 권고’로 명시됐다. 버그를 수정한 공식 업데이트가 아직 배포되지 않았기 때문이다. PHP 개발팀은 23일 공식 안내문(Informational advisory)을 통해 이 결함이 발생할 가능성이 낮은 원격 코드 실행 경로(an unlikely RCE vector)라고 설명했다. 원격 코드 실행은 외부 공격자가 타깃 서버의 셸 권한을 탈취해 임의의 명령을 실행할 수 있는 치명적인 보안 결함이다.

큰불을 끈 소방서가 이틀 뒤 옆방 배선을 다시 보라고 알린 격이다.

전면 노출 PHP2Shell vs 3중 자물쇠 CVE-2026-115560

PHP 개발팀은 21일 PHP2Shell 권고문에서 웹 요청을 처리하는 모든 PHP 환경이 위험에 노출돼 있으며, 특히 아파치 웹서버에 직접 연동하는 mod_php 환경이 가장 취약하다고 경고했다. 당시 두 결함은 취약점 심각도를 0~10점으로 산정하는 CVSS v4.0 기준으로 각각 9.2점의 높은 점수를 기록했다.

반면 이번 결함은 CVSS 점수도, 공식 영향 버전도 아직 매겨지지 않았다. KISA 공지의 영향 버전 항목에도 ‘제조사 미공개’로 명시돼 있다. PHP 개발팀은 23일 안내문을 통해 차기 정기 유지보수 릴리스에서 해당 결함을 수정하고 종합 권고문을 발행하겠다고 공지했으나, 구체적인 배포 일정은 공개하지 않았다.

“PHP2Shell이 정문이 활짝 열린 사고라면, 이번 결함은 3개의 자물쇠가 한꺼번에 풀려야만 열리는 뒷문이다.”

원격 코드 실행을 부르는 3대 결합 조건

웹서버가 방문자마다 부여하는 고유 임시 저장 공간이 세션(Session)이다. 로그인 인증 상태나 장바구니 품목 등이 이곳에 보관된다. 세션 메모리에 담긴 복합 데이터를 텍스트 파일로 변환해 디스크에 기록하는 메커니즘을 직렬화(Serialization)라고 부른다. PHP 환경에서는 session.serialize_handler 설정이 이 직렬화 알고리즘을 결정한다.

PHP 개발팀이 공식 권고문에 명시한 3가지 설정 조건이 동시에 결합할 때에만 비로소 공격 경로가 성립한다.

PHP 개발팀은 이러한 설정 조합이 실제 운영 환경에서는 매우 드물다고 판단했다. 실행 중에 직렬화 방식을 바꾸지 않는 일반적인 애플리케이션이라면 업로드 진행률 기능을 켜 두어도 안전하다고 덧붙였으나, 취약점의 근본 원인 코드는 공개하지 않았다. 보안 전문지 시큐어월드(SecureWorld)는 이번 결함이 PHP2Shell과 동일한 근본 원인에서 비롯된 것인지도 아직 명확히 규명되지 않았다고 전했다.

실제 재현 환경 검증… 세션 미호출 상태서도 파일 자동 생성

실제 우분투(Ubuntu) 24.04 공식 저장소의 PHP 8.3 패키지(8.3.6-0ubuntu0.24.04.13) 환경에서 3가지 조건을 하나씩 대조 검증했다. 공격 코드를 생성하지 않고 설정값과 파일 시스템 기록 동작만을 추적했다.

우선 기본 설정 상태를 점검하자 업로드 진행률 기능은 켜져 있고(On), 직렬화 방식은 php였다. 즉 조건 1은 시스템 관리자가 의도적으로 설정을 변경해야 성립하지만, 조건 3은 아무런 조치를 취하지 않은 기본 상태에서도 만족된다.

다음으로 세션 함수(session_start())를 일절 호출하지 않는 테스트용 엔드포인트를 PHP-FPM 환경에 구성했다. PHP-FPM은 고성능 웹서버 뒤에서 PHP 프로세스 풀을 관리하는 표준 실행 엔진이다. 여기에 업로드 진행률 필드를 포함한 파일 업로드 요청을 단 한 차례 전송했다. 애플리케이션 코드상에서 세션을 명시적으로 열지 않았음에도 세션 저장 경로에 임시 파일이 즉시 생성됐으며, 파일 내부에는 요청자가 전송한 파일명이 그대로 기록됐다.

주인이 사물함을 열기도 전에 택배 기사가 짐부터 넣어 둔 꼴이다.

이어 설정 파일의 직렬화 방식을 php_serialize로 변경한 뒤 동일한 업로드 요청을 전송하자, 동일한 데이터가 완전히 다른 바이너리 구조로 저장됐다. 기본 php 방식은 키|값 구조로 파싱되지만, php_serialize 방식은 단일 직렬화 배열 형태로 묶어 기록한다. 조건 1과 조건 2가 결합하면 데이터를 저장할 때의 직렬화 엔진과 애플리케이션이 읽어 들일 때의 역직렬화 엔진이 어긋나게 된다. 이 구조적 불일치가 원격 코드 실행 취약점의 핵심 트리거로 작용한다.

런타임 비활성화 시도에서도 중요한 기술적 제약이 확인됐다. ini_set() 함수로 코드 실행 중에 업로드 진행률을 끄라는 명령은 완전히 거부됐다(false 반환). 해당 옵션은 시스템 설정 파일(php.ini)이나 FPM 풀 단위에서만 변경할 수 있도록 보호돼 있기 때문이다. 반면 직렬화 핸들러는 런타임 코드 한 줄로 손쉽게 변조됐다. 조건 2가 단 한 줄의 코드로 충족되는 이유다.

버전 표기 체계에서도 실무적인 함정이 드러났다. 설치된 엔진은 php -v 출력에서 8.3.6으로 표시돼, PHP 공식 개발팀이 발표한 수정 버전(8.3.36)보다 한참 낮아 보인다. 그러나 리눅스 패키지 변경 이력(Changelog)을 역추적한 결과, 10월 19일자로 PHP2Shell 2건에 대한 보안 패치가 이미 백포트(Backport) 적용돼 있었다. 반면 이번 CVE-2026-115560 패치 내역은 어디에도 없었다.

간판은 옛 번호 그대로인데 안은 이미 수리를 마친 가게다.

KISA 역시 22일 대응 수칙을 통해 리눅스 배포판 패키지는 겉보기 버전 번호가 바뀌지 않을 수 있으므로, 패키지 변경 이력에서 실제 CVE 반영 여부를 대조하라고 안내했다. 이번 테스트는 특정 배포판 빌드 환경에서의 실측 검증 결과다.

취약점 침투 시 위협 시나리오와 확산 양상

KISA는 대응 가이드라인에서 PHP2Shell 공격이 성공할 경우 웹셸(Webshell) 삽입, 고객 개인정보 유출, 웹사이트 위변조, 기업 내부망 침투로 이어질 수 있다고 경고했다. 웹셸은 공격자가 서버 내부 파일 시스템에 상주시키며 원격 제어권을 행사하는 악성 스크립트다. 이번 결함 역시 동일한 원격 코드 실행(RCE) 계열이므로, 3대 조건만 갖춰지면 피해 양상은 사실상 동일하다.

다만 실제 위협 상황에서는 온도 차가 감지된다. 보안 전문 매체 더해커뉴스(The Hacker News)는 현재까지 CVE-2026-115560이 실제 공격에 악용된 사례는 보고되지 않았다고 보도했다. 실제 공격 트래픽이 집중된 표적은 PHP2Shell이다. 아마존웹서비스(AWS) 보안 인텔리전스 팀은 위협 분석 보고서에서 공식 공개 나흘 전인 10월 17일 자사 미끼 서버(허니팟)를 통해 PHP2Shell 공격 징후를 최초 포착했다고 밝혔다.

잠재적 노출 지면 자체는 방대하다. 보안 분석 플랫폼 바이러스토탈(VirusTotal)은 노출 범위 분석 보고서를 통해 지난 21일 기준 공용 인터넷에 PHP 환경으로 식별된 IP가 약 510만개에 달한다고 분석했다. 이는 취약점에 직접 노출된 서버 수가 아니라 전체 PHP 구동 인프라 규모이며, 이 가운데 3대 결합 조건을 모두 충족하는 시스템 비율은 아직 공식 집계되지 않았다.

서버 환경 점검과 즉시 적용 가능한 방어 조치

인프라 관리자는 가장 먼저 운영 중인 서버가 결합 조건에 부합하는지 확인해야 한다. 이때 핵심은 CLI가 아닌 실제 웹 요청을 수신하는 PHP 런타임의 설정을 들여다보는 것이다. 리눅스 배포판은 명령줄용(CLI)과 웹 처리용(FPM) 설정 파일을 독립적으로 분리 관리한다. 글로벌 보안 기업 아스트라(Astra)는 보안 권고문에서 php -i 명령어가 CLI 환경 설정만을 출력하므로 실제 웹 서비스 판단을 그르칠 수 있다고 지적했다.

# 웹용(FPM) 런타임 설정 검사 (지면 맞춤 사전 개행)
php-fpm8.3 -i | \
  grep -E "session.(upload_progress.enabled|serialize_handler)"

# 소스코드 내 직렬화 방식 동적 변조 지점 일괄 검색
grep -rn "serialize_handler" /var/www

다음 단계는 세션 업로드 진행률 기능을 비활성화하는 일이다. KISA와 PHP 개발팀이 공통으로 제시한 임시 대응 지침은 업로드 진행률 기능을 비활성화하는 조치다. 전역 설정 파일(php.ini) 또는 PHP-FPM 풀 설정에서 session.upload_progress.enabled=0으로 변경한 뒤 워커 프로세스를 재시작해야 한다.

; php.ini 전역 비활성화
session.upload_progress.enabled = 0

; PHP-FPM 풀 설정 (애플리케이션 ini_set 덮어쓰기 원천 차단)
php_admin_flag[session.upload_progress.enabled] = off

스위치는 애플리케이션 내부가 아니라 서버 배전반 차원에서 내려야 안전하다. PHP 개발팀은 21일 보안 권고문에서 애플리케이션 레벨의 ini_set()이나 PHP-FPM 디렉터리별 설정인 .user.ini에 의존한 차단은 불완전하다고 지적했다. 실제 테스트 환경에서도 풀 설정으로 비활성화하자 임시 세션 파일 생성이 완전히 차단됐다. .user.ini 파일 역시 국소적으로는 동작하지만, 해당 디렉터리에만 국한되고 변경값 갱신까지 기본 300초의 캐시 지연이 발생한다. 따라서 PHP2Shell 임시 조치 가이드에 따라 이미 해당 설정을 비활성화해 둔 시스템이라면 추가적인 설정 변경 없이도 방어 상태가 유지된다.

이와 별도로 선행 PHP2Shell 업데이트 완료 여부도 반드시 점검해야 한다. 이번 임시 조치는 근본적인 엔진 패치를 대체할 수 없다. KISA는 보안 공지를 통해 PHP 엔진 버전을 8.5.12, 8.4.27, 8.3.36, 8.2.35 이상으로 즉각 업데이트하고 관련 웹 서비스를 전면 재시작하라고 권고했다. 8.1 이하 구형 버전은 공식 보안 지원이 영구 중단됐으며, 8.2 역시 오는 12월 31일부로 지원이 종료되므로 8.3 이상으로의 업그레이드가 필수적이다.

웹 애플리케이션 방화벽(WAF)을 운용하는 조직이라면 시그니처 매칭의 사각지대도 점검해야 한다. 글로벌 웹 보안 기업 클라우드플레어(Cloudflare)는 기술 분석 블로그를 통해 기본 필드명(PHP_SESSION_UPLOAD_PROGRESS)을 사용하는 고객의 경우 기존 관리형 방화벽 규칙(Managed Rules)으로 공격을 차단할 수 있다고 발표했다. 다만 session.upload_progress.name 옵션으로 필드명을 커스텀 변경한 서버는 WAF 관리형 룰셋의 보호망을 벗어나게 된다.

설정 한 줄로 완전 방어 가능한가… 릴리스 전까지의 한계

아니다. 세션 업로드 진행률 모듈 주변에서 불과 이틀 간격으로 새로운 공격 벡터가 연달아 터져 나왔다. 이번 단일 경로는 파라미터 비활성화로 차단되지만, 실제로 PHP 개발팀은 21일 권고문에서 해당 설정이 확인된 세션 경로의 공격은 방어할 수 있으나 잠재적인 다른 변종 경로까지 완벽히 차단하지는 못한다(but not other variants)고 명시했다. 설정 한 줄은 지금까지 식별된 공격 경로만을 막는 임시 차단선이다.

소화기를 놓았다고 화재보험을 해지하는 사람은 없다.

KISA 역시 대응 수칙에서 설정 변경을 통한 임시 조치는 근본적인 방어책이 될 수 없으며 정식 보안 패치 적용이 최우선이라고 강조했다. 즉각적인 업데이트가 어렵다면 외부 인터넷 접속 차단이나 방화벽 IP 통제, 심지어 서비스 일시 중단까지 검토하라고 권고했다. 아울러 인터넷에 유포되는 공격 개념증명(PoC) 코드를 운영 시스템에서 직접 구동하는 행위를 엄격히 금지하고, 로그 분석과 버전 검증을 통해 취약 여부를 진단하라고 당부했다.

실제로 지난 24일 깃허브에는 이번 결함의 PoC 익스플로잇이라고 주장하는 공개 저장소가 최소 2개 이상 등록됐다. 그중 한 곳은 기본 환경이 아닌 취약 조건을 인위적으로 조합한 실습 컨테이너 환경을 함께 배포했다. 상용 운영 환경에서의 실제 침투 성공률은 검증되지 않았다.

PHP 개발팀이 취약 버전 목록과 정식 버그 수정 패치를 공식 배포하기 전까지, 이 결함의 파괴력은 당분간 릴리스 안내문 속 권고 한 줄에 맡겨져 있다.

패치 전까지 서버를 지킬 유일한 방패는 결국 설정 한 줄이다.