내 서버, PHP2Shell·HTTP2Shell에
안전한가요?

• 패치는 같은 계열 안의 업데이트입니다(예: 8.3.x → 8.3.36). 프로그램 호환 문제가 적어 가장 먼저 할 일입니다.
• 버전 전환은 계열을 올리는 일입니다(예: 7.4 → 8.3). 8.1 이하는 패치가 없어 전환이 필요하고, 오래된 게시판·쇼핑몰 프로그램은 함께 고쳐야 할 수 있습니다.
• PHP 8.2는 8.2.35 이상이면 이번 결함은 해결되지만, 보안 지원이 2026년 12월 31일에 끝납니다. 연내에 상위 버전 전환 계획을 세우세요.
• 웹호스팅 관리 화면에서 PHP 버전을 바꾸면 상품에 따라 서버 자료·데이터베이스·내부 백업이 삭제되거나 되돌릴 수 있는 기간이 제한될 수 있습니다. 바꾸기 전에 반드시 직접 백업하고 호스팅사 안내를 확인하세요.

# 현재 버전 확인
php -v

# 보안 업데이트 적용 (예: PHP 8.3)
sudo apt update
sudo apt install --only-upgrade php8.3 php8.3-cli php8.3-fpm php8.3-common

# 최신 패치가 apt 에 없으면 ondrej PPA 사용
# sudo add-apt-repository ppa:ondrej/php && sudo apt update

# 적용 후 재시작 (FPM 또는 Apache 내장)
sudo systemctl restart php8.3-fpm     # Nginx + PHP-FPM
sudo systemctl restart apache2        # Apache mod_php 인 경우

# 확인
php -v && php-fpm8.3 -v

php -v

# 배포판 기본 모듈
sudo dnf update php php-cli php-fpm php-common
# Remi 저장소를 쓰는 경우
# sudo dnf update php

sudo systemctl restart php-fpm
sudo systemctl restart httpd          # Apache 인 경우
php -v

# WHM 관리자
WHM → Software → EasyApache 4 → 현재 프로필에서 PHP 패키지 업데이트
WHM → MultiPHP Manager → 계정별 PHP 버전을 지원되는 최신으로 변경

# 또는 커맨드라인(루트)
/scripts/check_cpanel_rpms
yum update ea-php83-*

# 현재 값 확인 (1 이면 켜짐)
php -r 'var_dump(ini_get("session.upload_progress.enabled"));'
php -i | grep session.upload_progress.enabled     # CLI 기준 — 웹 쪽은 phpinfo() 로 확인

# 1) php.ini — 웹 서비스가 읽는 파일 (예: /etc/php/8.3/fpm/php.ini)
session.upload_progress.enabled = 0

# 2) 또는 PHP-FPM 풀 설정 (예: /etc/php/8.3/fpm/pool.d/www.conf)
php_admin_flag[session.upload_progress.enabled] = off

# 3) 적용 — 작업 프로세스를 모두 다시 시작해야 반영됩니다
sudo systemctl restart php8.3-fpm     # Nginx + PHP-FPM
sudo systemctl restart apache2        # Apache mod_php 인 경우

# 코드에서 세션 저장 방식을 바꾸는 곳이 있는지 확인
grep -rn "session.serialize_handler" /var/www --include=*.php

서버에 직접 접근할 수 없는 공유 호스팅입니다.
1) 호스팅사 관리 화면 → 'PHP 버전 설정'에서
   지원되는 최신 버전(8.2 이상)으로 변경
2) 호스팅사 보안 공지에서 PHP2Shell 패치와
   업로드 진행 추적 끄기(CVE-2026-115560 임시 조치) 적용 여부 확인
3) 버전 변경 후 사이트가 정상 동작하는지 확인
   (오래된 코드는 상위 PHP 에서 오류가 날 수 있음)

# 베이스 이미지 태그를 최신 패치로 올린다
# 예: FROM php:8.3-fpm  →  최신 8.3.x 패치 포함 이미지 재취득
docker pull php:8.3-fpm
docker compose build --pull && docker compose up -d
docker compose exec app php -v

# 현재 버전 확인
node -v
bun --version

# Node.js: nvm 이면 현행 LTS 최신으로 (또는 NodeSource apt 로 22.x 최신)
nvm install 22 --lts && nvm alias default 22

# Bun
bun upgrade                # 1.4.4 이상인지 확인

# 적용 후 앱 재시작 (pm2 또는 systemd) — 재시작해야 반영됩니다
pm2 restart all            # 또는: sudo systemctl restart <서비스명>

# 실제로 설치돼 있는지부터 — 직접 쓰지 않아도 다른 패키지가 깔았을 수 있습니다
pip show brotli brotlicffi

# 설치돼 있다면 수정 버전으로
pip install -U "brotli>=1.2.1" "brotlicffi>=1.2.1.0"

# 잠금 파일(requirements·poetry.lock 등)도 갱신하고, 컨테이너는 다시 빌드·재배포

# Ubuntu · Debian — 배포판 보안 업데이트로 libbrotli 갱신
sudo apt-get update && sudo apt-get install --only-upgrade libbrotli1
# (배포판은 버전 번호를 유지한 채 수정만 넣을 수 있음 — 보안 공지 확인)

# Docker — 베이스 이미지를 새로 받아 다시 빌드
docker compose build --pull && docker compose up -d

# Envoy · Istio — 1.37.8 / 1.38.6 / 1.39.3 / 1.40.0, Istio 1.30.6 / 1.31.2 이상으로

• 같은 브랜치 내 패치(예: 8.3.x) 업데이트는 보통 호환성 문제가 적습니다. 가능한 한 쓰던 브랜치의 최신 패치로 먼저 올리세요.
• 메이저·마이너 업그레이드(8.1→8.3 등)는 확장 모듈·코드 호환성 점검이 필요합니다. 스테이징에서 먼저 확인하세요.
• 지원이 종료된 PHP·프레임워크는 패치가 없으므로 현행 버전으로 이전(마이그레이션)이 필요합니다.
• HTTP2Shell은 Node.js 만의 문제가 아닙니다 — Python brotli·Bun·배포판 libbrotli·Envoy 까지 쓰는 곳을 모두 올리고, 업데이트 후 앱 재시작·컨테이너 재빌드까지 해야 적용됩니다.
• 업데이트 후 반드시 php -v와 사이트 핵심 기능(로그인·결제·게시판)을 확인하세요.
• 패치 후에도 기록을 조사하세요. 과기정통부·KISA FAQ는 10월 20일 이후의 서버 접속 기록과 파일 변경 내역을 점검하라고 권고합니다. 패치 공개(10월 21일) 전부터 공격 시도가 관측됐다는 보고도 있어, 이 점검기와 내부 점검은 여유를 두고 10월 17일 이후를 봅니다. 새로 생기거나 바뀐 PHP·.htaccess 파일과 예약 작업(cron)을 확인하고, 확인한 기록은 지우지 말고 따로 보관하세요.
• 비밀값은 반드시 교체하세요. 업데이트 전 인터넷에 열려 있던 서버는 메모리 유출·원격 실행으로 설정 파일의 DB 비밀번호·API 키가 새어 나갔을 수 있습니다. DB 비밀번호, 결제·문자·메일 등 외부 연동 키, 관리자·FTP 비밀번호, 프레임워크 서명 키를 새 값으로 바꾸고(새 값 발급 → 설정 반영 → 동작 확인 → 옛 값 폐기), 기존 로그인 세션을 모두 끊으세요.
• WAF·접근 제한은 임시 완화일 뿐입니다. 출처가 불분명한 점검 스크립트/PoC는 서버에서 실행하지 마세요.