2026년 10월 28일 수요일
미단재
웅파 목록

AI PHP CVE-2026-115560 정리 — 패치 없는 세 번째 RCE, 하지만 한 줄로 막힌다

#PHP #CVE-2026-115560 #session.upload_progress #원격 코드 실행 #임시 보안 조치
웅파 2026-10-27 22:47:15 14

PHP CVE-2026-115560 정리 — 패치 없는 세 번째 RCE, 하지만 한 줄로 막힌다

작성일: 2026-10-27 · 대상: PHP로 서비스를 운영하는 개발자·운영자

한 줄 요약

  • CVE-2026-115560은 PHP 세션의 업로드 진행률(session upload progress) 기능과 직렬화 핸들러(serialize_handler) 의 특이한 조합에서 생기는 원격 코드 실행(RCE) 취약점입니다.
  • 10월 23일 PHP 보안팀이 정보성 공지로 먼저 알렸고, 아직 패치된 PHP 버전은 없습니다. 수정판은 다음 정기 릴리스에 나옵니다.
  • 10월 21일 PHP2Shell 긴급 패치(8.5.12 / 8.4.27 / 8.3.36 / 8.2.35)로는 해결되지 않습니다.
  • 대신 임시 조치가 아주 간단합니다. session.upload_progress.enabled = 0 한 줄이면 됩니다.

배경: 일주일 사이 PHP 코어 RCE가 세 개

10월 셋째 주는 PHP 쪽이 꽤 시끄러웠습니다.

날짜 내용
10/21 PHP2Shell로 불리는 CVE-2026-109618(OOM 처리 중 메모리 손상), CVE-2026-109619(요청 간 남는 전역 상태) 긴급 패치. CVSS 9.2
10/23 세 번째 RCE인 CVE-2026-115560 정보성 공지. 긴급 릴리스 없이 정기 릴리스에서 수정 예정
10/26 기준 CVE-2026-115560에 대한 실제 공격 보고 없음. 공개된 공식 PoC도 없음

PHP2Shell 두 건은 웹 요청을 처리하는 거의 모든 PHP 버전이 대상이라 "무조건 업데이트"였지만, 이번 건은 성격이 다릅니다. PHP 측도 실제 운영 환경에서 나오기 어려운 설정이라고 보고 있고, 그래서 긴급 패치 대신 정기 릴리스로 돌렸습니다.

PHP는 아직 영향 받는 버전 범위, CVSS 점수, 수정 릴리스 시점, 그리고 CVE-2026-109619와 근본 원인이 같은지 여부를 공개하지 않았습니다. 상세 어드바이저리는 수정 릴리스와 함께 나옵니다.

언제 위험한가: 세 조건이 모두 맞아야 한다

위 이미지처럼 아래 세 가지가 동시에 성립해야 공격 경로가 열립니다.

  1. 설정 — session.serialize_handler가 php_binary 또는 php_serialize로 설정되어 있음 (기본값은 php)
  2. 코드 — 애플리케이션이 session_start()를 부르기 전에 ini_set('session.serialize_handler', 'php')로 핸들러를 런타임에 다시 바꿈
  3. 기능 — session.upload_progress.enabled가 켜져 있음 (PHP 기본값이 On)

현실적으로 1번과 2번이 드뭅니다. 설정에서 바꿔 놓고 코드에서 다시 되돌리는 조합 자체가 흔하지 않으니까요. 반대로 3번은 거의 모든 서버에 해당합니다. 그래서 우리가 끊을 수 있는 고리는 3번입니다.

내 서버는 해당되나? (5분 점검)

1) 현재 설정 확인

CLI와 FPM 설정이 다를 수 있으니 둘 다 봅니다. Ubuntu + PHP-FPM 기준입니다.

  bash

# CLI 기준
php -i | grep -E "session.serialize_handler|session.upload_progress.enabled"

# FPM 기준 (버전에 맞게)
php-fpm8.3 -i | grep -E "session.serialize_handler|session.upload_progress.enabled"

# 설정 파일 전체에서 직접 찾기
grep -rn "serialize_handler\|upload_progress.enabled" /etc/php/

session.serialize_handler => php라면 조건 1이 성립하지 않으므로 사실상 안전합니다.

2) 코드에서 핸들러를 바꾸는 곳이 있는지

  bash

grep -rn "serialize_handler" --include="*.php" .

vendor/도 반드시 포함해서 검색하세요. 내 코드가 아니라 패키지가 바꾸고 있을 수 있습니다.

3) 웹으로 실제 적용값 확인

FPM 풀마다 값이 다를 수 있으니, 확실히 하려면 임시로 phpinfo() 페이지를 띄워 Local Value 를 확인하고 바로 지우는 것도 방법입니다.

임시 조치: 업로드 진행률 끄기

php.ini

  ini

session.upload_progress.enabled = 0

PHP-FPM 풀 설정 (/etc/php/8.x/fpm/pool.d/www.conf)

  ini

php_admin_flag[session.upload_progress.enabled] = off

Apache + mod_php

  apache

php_admin_flag session.upload_progress.enabled off

적용 후 재시작:

  bash

sudo systemctl restart php8.3-fpm   # 버전에 맞게
php-fpm8.3 -i | grep session.upload_progress.enabled
# session.upload_progress.enabled => Off => Off

주의할 점

  • ini_set()이나 .user.ini로는 막을 수 없습니다. 이 설정은 PHP가 요청 본문을 파싱하기 전에 적용되어야 하기 때문입니다. 반드시 php.ini, FPM 풀, 웹서버 설정 같은 관리자 레벨에서 바꾸세요.
  • 잃는 것은 $_SESSION을 통한 서버측 업로드 진행률 추적뿐입니다. 요즘 업로드 진행 바는 대부분 프론트엔드 JS(XHR/fetch의 progress 이벤트)로 구현하니 영향이 거의 없습니다.
  • 10/21에 CVE-2026-109619 우회책으로 이미 이 값을 꺼 두었다면 그대로 유지하면 끝입니다.
  • Docker 이미지를 쓴다면 이미지 쪽에서 기본값을 바꿨는지 확인하세요. 예를 들어 serversideup/php는 v5.0.3에서 이 값을 기본 0으로 바꿨습니다.

프레임워크별로 보면

CodeIgniter 4

CI4 코어(system/ 디렉토리)를 최신 develop 브랜치 기준으로 확인해 보면 serialize_handler를 건드리는 코드가 없습니다. Session 클래스가 ini_set()으로 바꾸는 값은 session.name, cookie_samesite, gc_maxlifetime, save_path, use_strict_mode, use_only_cookies, sid_length 같은 쿠키·ID 관련 항목뿐입니다.

다만 CI4는 내부적으로 PHP 네이티브 세션(session_start() + 커스텀 SaveHandler)을 그대로 쓰므로 조건 3은 기본으로 성립합니다. 즉,

  • 서버 설정에서 serialize_handler를 바꾼 적이 없고
  • 내 코드/패키지에서 런타임에 바꾸지 않는다면

조건이 성립하지 않습니다. 그래도 끄는 비용이 거의 없으니 끄는 것을 권장합니다.

Laravel

Laravel은 PHP 네이티브 세션을 쓰지 않고 자체 드라이버로 세션 데이터를 읽고 씁니다. session_start()를 부르지 않으므로 조건 2가 성립하지 않습니다. 단, 별도 패키지나 레거시 코드가 네이티브 세션을 함께 쓰는 경우는 예외입니다.

레거시/직접 구현

오래된 그누보드·XE류, 혹은 직접 짠 세션 코드에서 php_serialize를 쓰다가 일부 페이지에서 php로 바꾸는 식의 호환 코드가 남아 있다면 바로 대상입니다. 이런 코드가 있는 곳일수록 위의 grep 점검을 꼭 해 보세요.

체크리스트

  • 10/21 PHP2Shell 패치 버전으로 올렸는가 (8.5.12 / 8.4.27 / 8.3.36 / 8.2.35 이상)
  • session.serialize_handler 실제 값 확인 (CLI, FPM 각각)
  • 코드와 vendor/에서 serialize_handler 변경 여부 grep
  • session.upload_progress.enabled = 0 을 php.ini 또는 FPM 풀에 적용, 재시작 후 확인
  • 다음 정기 릴리스 공지 확인 → 업데이트 후 상세 어드바이저리 읽고 설정 원복 여부 판단

정리

CVE-2026-115560은 "RCE"라는 단어 때문에 놀라기 쉽지만, 실제로는 흔치 않은 설정 + 흔치 않은 코드가 겹쳐야만 문제가 됩니다. 그래도 끊을 수 있는 세 번째 고리가 설정 한 줄이고, 그걸로 잃는 것도 거의 없습니다. 오늘 서버 설정 한 번 보고, 업로드 진행률은 꺼 두는 게 가장 경제적인 선택입니다.

그리고 PHP2Shell 패치를 아직 안 했다면 그쪽이 훨씬 급합니다. 그 두 건은 실제 대규모 공격 시도가 관측되고 있습니다.

참고

다음글 AIvance 제품 이름은 왜 라틴어일까: Cassa에서 Cella까지 이전글 26년차 개발자가 다시 코딩을 시작한 이유

댓글 1개

웅*
2026-10-27 22:55

개발용 맥북프로와 우분투 홈서버 체크결과 첫번째 조건에서 탈락. 해당사항 없음.
php -i | grep -E "session.serialize_handler|session.upload_progress.enabled"
session.serialize_handler => php => php
session.upload_progress.enabled => On => On