사이트 소유자 가이드 · PHP

PHP 버전을 확인하고 안전하게 업데이트하는 방법

사이트 소유자를 위한 가이드: WordPress, 호스팅 패널, SSH에서 PHP를 확인하고 전체 백업 후 환경에 맞게 2026년 10월 보안 패치를 적용하세요.

업데이트가 필요한 이유

PHP는 2026년 10월 21일 CVE-2026-109618과 CVE-2026-109619 수정 버전을 공개했습니다. 웹 요청을 처리하는 PHP 환경에서 인증 없이 원격 코드 실행으로 이어질 수 있는 런타임 취약점입니다. 사이트에서 사용하는 브랜치를 수정 버전으로 업데이트하거나 두 수정 사항을 모두 포함한 공급업체 패키지를 적용하세요.

PHP 브랜치PHP.net 수정 버전
PHP 8.58.5.12
PHP 8.48.4.27
PHP 8.38.3.36
PHP 8.28.2.35

PHP 8.1 이하는 PHP.net의 정식 업데이트가 더 이상 제공되지 않습니다. 배포판 또는 LTS 공급업체의 백포트를 확인하거나 지원 중인 브랜치로 이전하세요. PHP 8.2도 2026년 12월 31일 지원이 종료되므로 이전을 계획하세요.

공식 출처: PHP.net · 2026

1. 변경 전에 전체 백업하기

  1. 파일, 데이터베이스, 설정 저장

    사이트와 해당 서버 또는 서비스의 전체 백업을 만드세요. 업로드 파일, PHP 설정, 웹 서버 설정도 포함하세요. 서버 외부에 사본을 보관하고 복원이 가능한지 확인하세요.

  2. 테스트와 점검 시간 준비

    각 사이트의 현재 버전, 확장 모듈, 도메인, 풀을 기록하세요. 가능하면 스테이징 사본에서 업데이트를 시험하고 호환성 문제가 발생할 때의 복구 방법을 정하세요. 취약한 런타임으로 돌아가야 한다면 패치가 끝날 때까지 사이트를 오프라인으로 유지하세요.

2. 사이트가 실제로 사용하는 PHP 확인하기

  1. WordPress

    관리 화면에서 도구 → 사이트 건강 → 정보 → 서버(Tools → Site Health → Info → Server)를 열고 PHP 버전을 기록하세요. 웹사이트 런타임 정보입니다. 배포판 패키지를 사용한다면 호스팅 업체에 전체 패키지 리비전도 요청하세요.

  2. cPanel 또는 Plesk

    cPanel의 Software → MultiPHP Manager에서 각 도메인을 확인하세요. Plesk에서는 Websites & Domains → 해당 도메인 → PHP Settings를 여세요. 활성 버전과 핸들러를 기록하세요. 도메인마다 다른 PHP를 사용할 수 있습니다.

  3. SSH: CLI와 PHP-FPM

    본인 소유 서버에서 두 버전을 확인하세요. CLI PHP와 웹 런타임은 다를 수 있습니다. php-fpm 명령이 없다면 php8.3-fpm -v처럼 브랜치별 바이너리를 사용하세요. Apache의 mod_php를 쓴다면 활성 모듈과 패키지도 확인하세요.

    php -v
php-fpm -v

  4. Ubuntu/Debian: 전체 패키지 리비전 확인

    아래는 PHP 8.3과 FPM의 예시입니다. 설치 환경에 맞게 이름을 바꾸세요. apt policy는 설치 버전, 후보 버전, 저장소를 보여 주고 dpkg -l은 PHP, 확장 모듈, Apache 모듈을 확인하는 데 사용합니다.

    php8.3-fpm -v
apt policy php8.3-fpm php8.3-cli php8.3-common
dpkg -l 'php*' 'libapache2-mod-php*'

배포판은 기존 PHP 버전 번호를 유지하면서 보안 수정을 백포트할 수 있습니다. 따라서 Ubuntu의 PHP 8.3.6도 패치된 상태일 수 있습니다. php -v만 보지 말고 전체 패키지 리비전과 저장소를 배포판 공지와 대조하세요. 아래는 공개된 수정 리비전이며, 이후 리비전도 동일 공급업체의 확인이 필요합니다.

운영체제 및 패키지수정된 패키지 리비전
Ubuntu 22.04 · php8.18.1.2-1ubuntu2.28
Ubuntu 24.04 · php8.38.3.6-0ubuntu0.24.04.13
Ubuntu 26.04 · php8.58.5.4-0ubuntu1.5
Ubuntu 26.10 · php8.58.5.9-0ubuntu2.1
Debian bookworm · php8.2 · DLA-4848-18.2.35-1~deb12u1
Debian trixie · php8.4 · DSA-6574-18.4.27-1~deb13u1

Ubuntu는 USN-8948-1을 참고하세요. 이전 운영체제는 Ubuntu Pro가 필요할 수 있습니다. Debian trixie는 DSA-6574-1, bookworm은 DLA-4848-1입니다. 가이드 작성 시점에 Debian tracker는 sid를 미수정으로 표시합니다. 다른 배포판이나 운영체제 릴리스의 리비전을 적용하지 마세요.

공식 출처: Ubuntu · USN-8948-1 · Debian · DSA-6574-1 / DLA-4848-1

3. 환경에 맞는 방법으로 업데이트하기

모든 방법은 1단계의 전체 백업부터 시작하세요. 사이트에 해당하는 방법만 따르고 재시작 또는 재배포 후 웹사이트를 다시 확인하세요.

공유 호스팅: cPanel / Plesk

  1. 백업 후 호스팅 업체에 패치 요청

    PHP를 바꾸기 전에 전체 백업을 보관하세요. 고객 권한만 있다면 업체에 수정 패키지 설치를 요청하세요. “8.3”이나 “8.4”를 선택하는 것만으로 패치 적용을 확인할 수는 없습니다.

  2. cPanel: EasyApache 업데이트 후 도메인에 적용

    관리자가 WHM에서 EasyApache 4 패키지를 업데이트해야 합니다. 수정 버전은 ea-php85 8.5.12, ea-php84 8.4.27, ea-php83 8.3.36, ea-php82 8.2.35입니다. 이후 MultiPHP Manager에서 도메인을 선택하고 호환되는 패치된 브랜치를 적용하세요.

  3. Plesk: 런타임과 PHP 설정 업데이트

    관리자가 Plesk 설치 관리자로 PHP를 업데이트한 뒤 도메인의 PHP Settings에서 런타임을 선택해야 합니다. Linux 공지의 수정 버전은 8.5.12 / 8.4.27 / 8.3.36 / 8.2.35입니다. Windows나 PHP 7.4~8.1의 제공 여부는 업체에 확인하세요.

  4. 재시작 및 도메인별 동작 확인

    사이트를 처리하는 PHP-FPM 또는 Apache 워커를 재시작해 달라고 요청하세요. 실제 런타임을 다시 확인하고 일반적인 로그인, 폼, 업로드를 시험하세요.

공식 출처: cPanel · EasyApache 4 · Plesk · PHP

Ubuntu / Debian 및 Ondřej PPA: apt

  1. 백업 후 브랜치와 저장소 확인

    전체 백업을 준비하고 apt policy를 USN-8948-1 또는 Debian 공지와 비교하세요. Ubuntu에서 이미 ppa:ondrej/php를 사용한다면 10월 21일 jammy와 noble용으로 공개된 수정 버전 8.2.35 / 8.3.36 / 8.4.27 / 8.5.12를 확인하세요. Debian에 Ubuntu PPA를 추가하거나 예시를 따라 저장소를 섞지 마세요.

  2. 설치된 브랜치의 패키지 업데이트

    PHP 8.3과 FPM의 예시입니다. 8.3을 실제 브랜치로 바꾸고 앱에서 사용하는 설치된 확장 패키지도 업데이트에 포함하세요. mod_php를 사용한다면 해당 브랜치의 libapache2-mod-php 패키지도 업데이트하세요. 수정된 후보 버전이 없다면 먼저 공급업체와 저장소 문제를 해결하세요.

    sudo apt update
apt policy php8.3-fpm php8.3-cli php8.3-common
sudo apt install --only-upgrade php8.3-fpm php8.3-cli php8.3-common

  3. FPM을 사용한다면 재시작

    실제로 웹 요청을 처리하는 브랜치의 서비스를 사용하고 관련 풀, 서비스, 서버를 모두 포함하세요. 아래는 PHP 8.3 예시입니다.

    sudo systemctl restart php8.3-fpm

  4. Apache를 사용한다면 재시작

    mod_php에서는 재시작해야 패치된 런타임이 로드됩니다. Apache가 FPM을 사용한다면 해당 FPM도 재시작하세요. 이후 apt policy, 웹사이트, 로그를 확인하세요.

    sudo systemctl restart apache2

공식 출처: Ubuntu · USN-8948-1 · Debian · DSA-6574-1 / DLA-4848-1 · Ondřej Surý · Launchpad

Docker: PHP 공식 이미지

  1. 영구 데이터도 백업

    재빌드 전에 데이터베이스, 업로드, 볼륨, 설정을 백업하세요. 컨테이너 이미지만으로는 이 데이터가 백업되지 않습니다.

  2. 수정된 이미지 태그 지정

    php:8.5.12, php:8.4.27, php:8.3.36, php:8.2.35 중 해당 버전에 -fpm 또는 -apache 같은 변형을 붙여 사용하세요. 앱에 필요한 운영체제 변형과 확장 모듈을 유지하세요. Dockerfile 예시:

    FROM php:8.4.27-fpm

  3. 재빌드하고 재배포

    아래는 Dockerfile로 빌드하는 Compose 서비스의 예시입니다. 업데이트된 베이스를 가져오고 캐시 없이 재빌드하세요. 다른 오케스트레이터에서는 기존 배포 절차로 새 이미지를 게시하고 배포하세요. Compose가 image:만 사용한다면 태그를 바꾸고 수정 이미지를 받은 후 서비스를 다시 생성하세요.

    docker compose build --pull --no-cache
docker compose up -d

  4. 모든 복제본 확인

    새 컨테이너 내부 PHP와 웹 런타임을 확인하세요. 이전 복제본이 더 이상 트래픽을 받지 않는지 확인하고 앱을 시험하세요.

공식 출처: Docker · Official Images / PHP · PHP.net · 2026

Laravel Forge

  1. 서버와 앱 백업

    변경 전에 전체 백업을 보관하세요. 10월 21일 17:12 UTC에 갱신된 Laravel 공지는 브랜치별 업데이트 방법을 안내합니다.

  2. PHP 8.5: Update PHP

    Forge 대시보드에서 서버를 열고 Update PHP를 누르세요. 수정 리비전으로 업데이트가 완료되고 서비스가 재시작되는지 확인하세요.

  3. PHP 8.2~8.4: SSH와 apt

    해당 공지에 따라 SSH로 연결하고 이 가이드의 apt 절차를 사용하세요. 실제 브랜치의 패키지와 서비스를 지정하고 해당하는 PHP-FPM과 Apache를 재시작하세요. 앱의 다른 상주 프로세스도 검토하세요.

  4. 업데이트할 수 없는 경우

    Laravel은 업데이트를 적용할 수 있을 때까지 서버를 끄도록 권고합니다. 먼저 백업을 보관하세요. Vapor 사용자는 업데이트된 런타임을 반영하도록 재배포하라는 안내를 따르세요.

공식 출처: Laravel · 2026-10-21

WordPress: 호스팅의 PHP를 수정해야 합니다

  1. WordPress 전체 백업

    파일, 업로드, 데이터베이스, 설정을 보관하고 런타임을 바꾸기 전에 복원 방법을 확인하세요.

  2. WordPress를 실행하는 PHP 업데이트

    실제 설치 환경에 맞는 호스팅, apt 또는 Docker 방법을 따르세요. WordPress 코어, 테마, 플러그인 업데이트로는 이번 PHP 런타임 취약점이 수정되지 않습니다. 호스팅 업체가 서버를 관리한다면 두 수정 사항의 적용을 확인하세요.

  3. 사이트 건강 다시 확인

    도구 → 사이트 건강 → 정보 → 서버를 다시 확인하세요. 백포트라면 전체 패키지 리비전도 요청하고 관리자 접근, 폼, 구매, 업로드를 시험하세요.

공식 출처: PHP.net · 2026

4. 완료 전에 업데이트 확인하기

  1. 웹 런타임과 패키지 확인

    수정 버전 또는 공급업체의 백포트, 모든 워커의 재시작, 각 도메인, 서버, 복제본을 확인하세요. CLI 업데이트만으로 웹사이트 PHP의 패치를 증명할 수는 없습니다.

  2. 일상적인 기능 시험

    사이트에 맞게 페이지, 로그인, 폼, 업로드, 결제를 확인하세요. 오류를 검토하고 백업과 적용한 버전 기록을 보관하세요.

Cloudflare: 업데이트 중 임시 보호

  1. 주황색 구름으로 프록시 확인

    Cloudflare는 2026년 10월 21일 03:02 UTC부터 모든 요금제에 규칙을 자동 배포했으며 Free에도 Cloudflare Managed Free Ruleset으로 제공했다고 안내합니다. 웹사이트를 제공하는 DNS 이름이 프록시 상태이며 주황색 구름으로 표시되는지 확인하세요.

  2. Pro / Business / Enterprise: Block 확인

    Cloudflare Managed Ruleset이 배포되어 있고 보호 규칙이 Block 모드인지 확인하세요. Security → Security Analytics → Events에서 활동을 확인하세요.

WAF는 패치가 아닙니다. Cloudflare를 통과하는 트래픽만 보호하며 서버 런타임 자체는 고치지 않습니다. 규칙이 활성화되어 있어도 PHP 업데이트를 완료하세요.

공식 출처: Cloudflare · WAF

PHP.net 임시 완화 조치: 불완전한 대책

패치를 준비하는 동안에만 관리자와 함께 적용하고 설정 변경 전에 전체 백업을 만드세요. 이 조치만으로 취약한 설치 환경이 안전해지지는 않습니다.

  1. 관리자 설정으로 memory_limit=-1 적용

    PHP.net은 앱이 유한한 제한을 다시 설정하지 못하도록 php_admin_value로 PHP 메모리 제한을 없애도록 안내합니다. 아래는 FPM 풀 예시이며 Apache 문법은 php_admin_value memory_limit -1입니다. 메모리 사용량이 늘 수 있으므로 관리자가 서버 용량을 확인해야 합니다.

    php_admin_value[memory_limit] = -1

  2. POST 크기 제한과 업로드 진행 기능 해제

    php.ini 또는 서버 설정에서 업로드가 없으면 post_max_size=8M, 필요하면 32M으로 설정하고 upload_max_filesize는 더 작게 유지하세요. 요청 처리 전에 session.upload_progress.enabled=0을 적용해야 하며 ini_set()이나 .user.ini만으로는 부족합니다. 아래 예시는 사이트에 맞게 조정하세요.

    post_max_size = 8M
upload_max_filesize = 2M
session.upload_progress.enabled = 0

  3. PHP 8.5: 치명적 오류 역추적 해제

    PHP 8.5에서만 서버 설정에 이 항목도 적용하세요.

    fatal_error_backtraces = 0

  4. 모든 워커 재시작

    관련 PHP-FPM 또는 Apache 서비스를 모두 재시작하고 각 사이트에 실제로 적용된 설정을 확인하세요. 일부 위험만 줄이는 조치이므로 패치 설치까지 완료하세요.

업데이트를 대체하는 완전한 완화 조치는 없습니다. 패치할 수 없다면 소유자와 협의해 서비스를 일시 중단하세요.

공식 출처: PHP.net · 2026

도움이 필요하신가요? 작업을 맡겨 주세요

런타임 확인, 백업 준비, 업데이트 적용, 사이트 작동 확인을 도와드립니다.

PHP 업데이트 의뢰하기Humberto에게 이메일

소유자가 서면으로 허가한 사이트에서만 작업하며, 변경 전에 반드시 전체 백업을 만듭니다.