2026년 10월 22일, 운영 중인 서버 5대의 PHP를 8.4.26에서 8.4.27로 업데이트했다. PHP 엔진에서 원격 코드 실행(RCE)으로 이어질 수 있는 취약점 두 건이 보고됐기 때문이다.

이번 문제는 그누보드나 워드프레스 같은 웹 애플리케이션에서 발생한 취약점이 아니다. PHP 자체의 메모리 처리 과정에서 발생하는 문제다. 따라서 CMS를 최신 버전으로 업데이트하는 것만으로는 해결할 수 없다.

여러 사이트가 같은 PHP 실행 환경을 사용하는 구조라 영향 범위도 넓었다. PHP 업데이트뿐 아니라 PHP-FPM 설정까지 함께 점검했다.

어떤 문제가 있었고, 실제 서버에서 어떻게 대응했는지 기록해 둔다. 특히 PHP 버전 업데이트 과정에서 겪었던 패키지 저장소 문제와 메모리 설정을 변경하지 않은 이유도 함께 설명한다.

PHP 메모리 처리 과정에서 발견된 두 가지 원격 코드 실행 취약점

이번에 대응한 취약점은 CVE-2026-109618과 CVE-2026-109619다. 당시 확인한 취약점 정보에서는 두 건 모두 CVSS v4.0 기준 9.2로 안내됐다. 두 취약점 모두 PHP 내부의 메모리 처리와 관련돼 있지만 발생 원리는 다르다.

CVE-2026-109618은 메모리 부족 상황을 처리하는 과정에서 발생한다. PHP는 스크립트가 허용된 메모리 사용량을 초과하면 실행을 중단한다. 일반적으로는 메모리 부족 오류를 출력하고 요청 처리를 종료한다.

그런데 요청 데이터가 완전히 생성되지 않은 상태에서 실행이 중단되면 문제가 생길 수 있다. 내부 자료구조가 불완전하게 남아 있는데, 이후 정리 과정에서 이를 정상 데이터처럼 처리하는 것이다. 이 과정에서 메모리 손상이 발생하고 원격 코드 실행으로 이어질 수 있다고 보고됐다.

CVE-2026-109619는 해제된 메모리를 다시 사용하는 문제다. PHP-FPM은 하나의 worker 프로세스가 여러 HTTP 요청을 순서대로 처리한다. 이전 요청에서 사용한 메모리가 해제됐는데도 해당 메모리를 가리키는 참조가 남아 있을 수 있다.

이 상태에서 다음 요청이 들어오면 이미 해제된 메모리에 접근할 가능성이 생긴다. 이런 문제를 Use-After-Free(UAF)라고 부른다. 보고된 공격 경로에는 세션 업로드 진행률 기능, 요청 초기화 이전의 설정 경고, PHP 8.5의 치명적 오류 백트레이스가 포함돼 있었다.

PHP-FPM을 사용해도 안전하지 않은 이유

PHP는 웹 서버 환경에 따라 여러 방식으로 실행된다. Apache에 PHP 모듈을 직접 연결하는 mod_php 방식이 있고, PHP를 별도 프로세스로 실행하는 PHP-FPM 방식도 있다. php-cgi를 사용하는 환경도 있다.

이번 취약점은 웹 애플리케이션이 아니라 PHP 엔진 자체에서 발생한다. 따라서 PHP-FPM을 사용한다고 해서 영향 대상에서 제외되는 것은 아니다.

공개된 공격 시연에서는 mod_php 환경에서 로그인 없이 단일 요청으로 코드 실행에 성공한 사례가 보고됐다. 특히 애플리케이션 코드가 실행되기 전에도 공격이 가능하다는 점이 눈에 띄었다.

PHP-FPM 역시 영향 대상에 포함된 것으로 안내됐다. 다만 mod_php에서 시연된 공격 방식이 PHP-FPM에서도 동일하게 성공하는지까지 완전히 입증된 것은 아니었다. 취약점의 존재와 특정 공격 코드의 성공 여부는 구분해서 봐야 한다.

PHP-FPM은 worker 프로세스를 재사용한다. 하나의 프로세스가 여러 요청을 순서대로 처리하기 때문에 요청 간 상태가 제대로 정리되지 않으면 문제가 생길 수 있다. 이번 취약점 중 하나가 바로 이런 상황과 관련돼 있었다.

PHP 취약점으로 서버가 공격당하면 어디까지 영향을 받을까

운영 중인 PHP-FPM worker는 일반 사용자 권한으로 실행된다. 따라서 PHP에서 원격 코드 실행에 성공했다고 해서 곧바로 root 권한을 얻는 것은 아니다.

일부 커뮤니티에서는 이런 취약점을 두고 서버 관리자 권한을 탈취할 수 있다고 설명한다. 하지만 실제로 얻는 권한은 PHP 프로세스의 실행 계정과 서버 설정에 따라 달라진다.

그렇다고 일반 사용자 권한으로 실행되는 공격을 가볍게 볼 수는 없다. 웹사이트 파일에 쓰기 권한이 있다면 파일을 변조하거나 웹셸을 설치할 수 있다. 데이터베이스 접속 정보가 저장된 설정 파일을 읽을 수 있다면 DB 접근으로도 이어질 수 있다.

워드프레스나 그누보드 같은 PHP 기반 CMS에서는 데이터베이스 접속 정보가 설정 파일에 저장돼 있다. 공격자가 해당 파일을 읽을 수 있다면 DB 계정과 비밀번호가 노출될 수 있다. DB 계정에 부여된 권한에 따라 게시물이나 회원정보가 유출되거나 변조될 가능성도 있다.

이번에 관리하는 환경은 여러 웹사이트가 동일한 PHP 실행 환경을 공유하는 구조다. 사이트별 파일 권한과 프로세스 격리가 충분하지 않다면 한 사이트에서 시작된 침해가 다른 사이트로 확산될 수 있다. 이 때문에 개별 사이트 업데이트가 아니라 PHP 실행 환경 전체를 대상으로 대응했다.

PHP 8.4.26에서 8.4.27로 업데이트하고 웹 요청까지 확인하기

이번 작업에서는 운영 중인 서버 5대의 PHP를 모두 업데이트했다. 기존 버전은 PHP 8.4.26이었고, 업데이트 대상은 PHP 8.4.27이었다.

당시 확인한 수정 버전 정보는 다음과 같았다.

PHP 버전 계열	안내된 수정 버전
PHP 8.2	8.2.35
PHP 8.3	8.3.36
PHP 8.4	8.4.27
PHP 8.5	8.5.12

서버마다 PHP 버전이 다르다면 해당 계열의 수정 버전을 확인해야 한다. 이번 환경에서는 모두 PHP 8.4 계열을 사용하고 있었기 때문에 같은 버전으로 업데이트할 수 있었다.

업데이트 과정에서 예상하지 못한 문제가 있었다. Remi 저장소의 미러 반영이 늦었고, 원본 서버에서도 패키지 다운로드 속도가 느렸다. 패키지가 공개됐더라도 저장소에 즉시 반영되지 않으면 업데이트가 지연될 수 있다.

일부 서버에서는 다운로드 속도가 정상적으로 나오는 미러를 직접 지정했다. 이때 패키지 서명 검사는 그대로 유지했다. 설치된 패키지는 모두 Remi 서명 검사를 통과했다.

패키지 설치 후에는 PHP-FPM을 재시작했다. 여기서 업데이트 작업을 끝내지 않고 실제 웹 요청까지 확인했다. 패키지 버전이 바뀌었다고 해서 현재 웹 요청을 처리하는 프로세스까지 새 버전으로 동작한다고 단정할 수 없기 때문이다.

PHP 버전 확인에 사용할 수 있는 명령어는 다음과 같다.

php -v

다만 이 명령어는 CLI 환경의 PHP 버전을 보여 준다. 웹 서버에서 사용하는 PHP와 다를 수 있다. 따라서 실제 웹 요청을 처리하는 PHP 버전도 별도로 확인해야 한다.

PHP-FPM을 사용하는 서버에서는 다음 명령어로 설정 오류 여부도 확인할 수 있다.

php-fpm -t

실제 작업에서는 다섯 서버 모두 웹 요청을 통해 PHP 8.4.27이 동작하는 것을 확인했다. 기존 사이트가 정상적으로 응답하는지도 함께 점검했다. 버전 확인을 위해 임시로 만든 공개 진단 파일이 있다면 확인 후 삭제해야 한다.

PHP-FPM에서 세션 업로드 진행률과 업로드 크기 제한하기

PHP 버전 업데이트 외에 추가로 적용한 설정도 있다. 취약점 대응 과정에서 안내된 완화 조치다. 업데이트 이후에도 설정을 유지하기로 했다.

PHP-FPM에서는 풀 설정 파일을 통해 PHP 설정값을 지정할 수 있다. 일반적인 Remi 기반 환경에서는 다음 파일을 사용한다.

/etc/php-fpm.d/www.conf

설정을 변경하기 전에 기존 파일을 백업했다. 문제가 발생하면 이전 설정과 비교하거나 복원할 수 있도록 하기 위해서다.

적용한 설정은 다음과 같다.

php_admin_value[session.upload_progress.enabled] = Off
php_admin_value[post_max_size] = 32M
php_admin_value[upload_max_filesize] = 30M

첫 번째 설정은 PHP의 세션 업로드 진행률 기능을 비활성화한다. PHP는 파일 업로드 진행 상태를 세션에 기록하는 기능을 제공한다. 이번 CVE-2026-109619에서 확인된 공격 경로 중 하나가 이 기능과 관련돼 있었다.

두 번째 설정은 HTTP POST 요청 본문의 최대 크기를 제한한다. 세 번째 설정은 개별 업로드 파일의 최대 크기를 지정한다. 요청 크기를 제한하면 과도한 데이터 전송으로 메모리 부족 상황을 유도하는 공격의 부담을 높일 수 있다.

업로드 파일의 최대 크기는 POST 요청 크기보다 작게 설정했다. 파일 업로드 요청에는 파일 데이터 외에도 multipart 형식의 부가 정보가 포함되기 때문이다. 두 값을 동일하게 설정하면 최대 크기에 가까운 파일이 예상과 다르게 거부될 수 있다.

설정 변경 후에는 PHP-FPM을 재시작해 적용했다. 다만 이런 제한은 메모리 손상 취약점 자체를 수정하는 방법이 아니다. PHP 업데이트를 대신할 수 없다는 점은 구분해야 한다.

업로드 제한을 낮추기 전에 기존 서비스의 파일 전송 방식 확인하기

업로드 크기 제한을 변경할 때는 기존 서비스에 영향을 주지 않는지 확인해야 한다. 특히 이미지 업로드나 대용량 파일을 다루는 사이트라면 더 그렇다.

이번 환경에서도 일부 서버는 기존 POST 요청 크기 제한이 64MB였다. 이를 32MB로 낮추면 이전에 가능했던 요청이 거부될 수 있다. 그래서 설정을 변경하기 전에 실제 서비스에서 큰 파일을 어떻게 처리하는지 살펴봤다.

이미지 업로드 기능을 제공하는 사이트는 애플리케이션 코드에서 이미 30MB 제한을 사용하고 있었다. PHP의 파일 업로드 제한을 30MB로 설정해도 기존 애플리케이션의 제한보다 낮아지지는 않는 구조였다.

대용량 파일을 제공하는 다른 사이트도 확인했다. 이곳에서는 파일을 PHP 업로드 기능으로 서버에 전송하지 않았다. SFTP나 rsync를 이용하고 있었다.

SFTP나 rsync로 전송하는 파일은 PHP의 업로드 크기 제한을 받지 않는다. 따라서 대용량 파일을 제공하는 사이트라고 해서 PHP의 업로드 제한까지 크게 유지해야 하는 것은 아니다.

반대로 관리자 페이지에서 PHP를 통해 백업 파일이나 압축 파일을 업로드하는 서비스라면 문제가 생길 수 있다. 이런 경우에는 실제 업로드 방식과 파일 크기를 먼저 확인해야 한다. PHP 설정을 일괄 적용할 때 놓치기 쉬운 부분이다.

memory_limit=-1을 적용하지 않은 이유와 JIT 설정 변경

이번 취약점의 완화 방안 중에는 PHP의 메모리 제한을 해제하는 설정도 있었다.

memory_limit = -1

이 설정은 PHP 스크립트에 적용되는 메모리 사용량 제한을 없앤다. 메모리 한도 초과로 요청이 중단되는 상황을 피할 수 있지만, 다른 문제가 생길 수 있다.

PHP 스크립트가 메모리를 과도하게 사용하더라도 PHP 자체의 메모리 제한으로 실행을 중단하지 않기 때문이다. 서버의 실제 메모리 용량이 부족해지면 운영체제의 OOM Killer가 프로세스를 종료하거나 서비스가 불안정해질 수 있다.

우리 환경은 서버 메모리 용량이 크지 않다. 과거에도 메모리 부족으로 서비스가 중단된 이력이 있었다. 이런 환경에서 메모리 제한을 없애는 것은 부담이 있었다.

이미 PHP 8.4.27로 업데이트한 상태였기 때문에 해당 설정은 적용하지 않았다. 취약점 완화를 위해 다른 장애 가능성을 높이기보다는 패치를 우선 적용하는 방향으로 결정했다.

추가로 일부 서버에서는 JIT 설정도 변경했다. 해당 서버에는 다음 설정이 적용돼 있었다.

opcache.jit=1255

이를 비활성화했다.

opcache.jit=off

JIT는 PHP 코드를 실행할 때 일부 작업을 기계어로 컴파일해 성능을 높이는 기능이다. 하지만 모든 PHP 웹사이트에서 JIT를 활성화한다고 성능이 좋아지는 것은 아니다. 일반적인 웹 애플리케이션에서는 효과가 제한적일 수도 있다.

이번 취약점과 JIT 설정은 직접적인 관계가 없다. 다만 이전 PHP 업데이트 과정에서 JIT와 관련해 PHP-FPM이 반복 종료된 경험이 있었다. 같은 상황을 피하기 위해 해당 서버의 JIT를 미리 비활성화했다.

JIT 설정 역시 기존 파일을 백업한 뒤 변경했다. PHP 업데이트와 별개로 진행한 작업이므로 나중에 원인을 분석할 때 구분할 수 있도록 기록해 뒀다.

PHP 업데이트가 끝나도 기존 침해 여부는 별도로 확인해야 한다

2026년 10월 22일 기준으로 운영 서버 5대의 PHP 업데이트를 완료했다. PHP-FPM도 재시작했고, 실제 웹 요청에서 새 버전이 동작하는 것을 확인했다. 기존 사이트의 정상 응답도 확인했다.

세션 업로드 진행률 기능은 비활성화했다. POST 요청 크기와 파일 업로드 제한도 조정했다. 메모리 제한 해제는 적용하지 않았고, 일부 서버의 JIT 설정만 별도로 변경했다.

다만 아직 확인하지 않은 부분이 있다. 패치 이전에 이미 공격이 발생했는지 여부다. 취약점이 수정됐다고 해서 과거에 침입이 없었다는 뜻은 아니다.

다음 점검에서는 웹 디렉터리에서 최근 생성되거나 수정된 PHP 파일을 확인할 필요가 있다. 웹셸로 의심되는 코드와 비정상적인 파일 변경도 살펴봐야 한다. 웹 서버 접속 로그와 PHP 오류 로그를 함께 확인하면 공격 시도가 있었는지 판단하는 데 도움이 된다.

최근 수정된 PHP 파일이 모두 악성 파일인 것은 아니다. 정상적인 배포나 자동 업데이트로 변경된 파일도 있을 수 있다. 반대로 파일 변경 흔적이 없다고 해서 침해가 없었다고 단정할 수도 없다.

이번 작업으로 확인한 범위는 PHP 업데이트, 완화 설정 적용, 서비스 정상 동작까지다. 기존 침해 여부는 아직 조사하지 않았다.

PHP 엔진 취약점은 웹사이트 소스만 관리해서는 대응하기 어렵다. CMS가 최신 버전이어도 PHP 자체에 문제가 있다면 영향을 받을 수 있다. 앞으로도 PHP 보안 업데이트가 나오면 실제 웹 요청을 처리하는 버전까지 확인하고, 필요한 경우 침해 흔적 점검을 별도로 진행할 생각이다.