Blog

PHP 긴급 보안 패치 2건(CVE-2026-109618, CVE-2026-109619) 대응 – Bitnami WordPress PHP 7.4 환경 임시 완화와 근본 해결

  • Post author:
  • Post published:
  • Post category:Linux

2026년 10월 21일, PHP 보안팀이 원격 코드 실행(RCE)으로 이어질 수 있는 취약점 2건에 대한 보안 공지를 내놓았습니다.
CVE-2026-109618과 CVE-2026-109619입니다.
이 글은 Linux 서버에 Bitnami WordPress 스택(PHP 7.4.16)을 운영 중인 분들을 대상으로, 당장 적용할 수 있는 임시 완화책과 근본 해결 방향을 정리한 것입니다.
PHP 7.4는 이미 공식 지원이 종료된 버전이므로, 설정 변경만으로는 끝나지 않는다는 점을 먼저 짚고 시작합니다.

중요: 아래 설정은 공격 경로를 일부 줄이는 임시 완화책이며 취약점을 완전히 해결하지 않습니다.
PHP 보안팀이 제공한 PHP 7.4용 최소 소스 백포트를 검증된 환경에서 빌드하거나, 패치된 지원 버전의 PHP가 포함된 새 스택으로 이전해야 합니다.
운영 중인 Bitnami의 PHP 실행 파일을 임의로 덮어쓰지 마세요.

1. 이번에 공개된 취약점 2건

두 취약점 모두 PHP 내부 메모리 처리 과정의 결함에서 출발하며, 최악의 경우 원격 코드 실행까지 가능합니다.
공격 경로가 다르기 때문에 완화책도 각각 다릅니다.

CVE 개요 임시 대응
CVE-2026-109618 OOM(메모리 부족) 처리 중 내부 요청 데이터가 손상되어 원격 코드 실행 가능 요청/업로드 크기 제한, 격리된 리소스 제한. PHP 공식 권고의 memory_limit=-1은 위험성 평가 후에만 검토
CVE-2026-109619 해제된 메모리의 전역 상태가 다음 요청에 남아 원격 코드 실행 가능 session.upload_progress.enabled=0 적용 및 모든 PHP 워커 재시작

2. 먼저 실제 Bitnami 환경을 확인한다

Bitnami 스택은 설치 시점과 버전에 따라 경로와 구성(Apache mod_php 또는 PHP-FPM)이 다릅니다.
설정을 건드리기 전에 내 서버가 실제로 어떤 구성인지부터 확인합니다.

ls -ld /opt/bitnami /opt/bitnami/php /opt/bitnami/apache 2>/dev/null
/opt/bitnami/php/bin/php -v
/opt/bitnami/php/bin/php --ini
/opt/bitnami/apache/bin/httpd -M | grep -E 'php|proxy_fcgi' || true
sudo /opt/bitnami/ctlscript.sh status

경로가 다르면 해당 서버의 실제 Bitnami 설치 경로로 치환합니다.
php --ini는 CLI용 설정 파일을 보여 주는 것이므로, 웹 요청을 처리하는 환경의 설정 경로가 같다고 단정하면 안 됩니다.

3. 설정 백업 후 임시 완화 적용

php.ini를 수정하기 전에 반드시 백업부터 남깁니다.
날짜를 붙여 두면 나중에 되돌릴 때 편합니다.

sudo cp -a /opt/bitnami/php/etc/php.ini \
  /opt/bitnami/php/etc/php.ini.bak-$(date +%Y%m%d-%H%M%S)
sudo vi /opt/bitnami/php/etc/php.ini

기존 설정에 같은 항목이 중복 선언되어 있다면 먼저 정리합니다.
그다음 사이트의 업로드 요구 사항을 고려해 아래 항목을 적용합니다.

; CVE-2026-109619: 확인된 세션 업로드 진행 경로 완화
session.upload_progress.enabled = 0

; CVE-2026-109618: 요청 크기 감소 (WordPress 이미지 업로드 사용 가정)
post_max_size = 32M
upload_max_filesize = 16M

; 일반적인 입력 변수 한도 예시 (운영 사이트 플러그인 요구사항 확인)
max_input_vars = 1000

post_max_size=32M, upload_max_filesize=16M은 예시 값입니다.
미디어 업로드 요구 사항에 맞게 조절하고, 웹 서버나 역방향 프록시에서도 요청 본문 크기, multipart 부분 수, 입력 필드 수, 헤더 수 등을 제한하세요.
Content-Length가 누락된 요청에도 제한이 적용되도록 구성해야 합니다.

memory_limit=-1 적용 여부 판단

PHP 공식 공지는 CVE-2026-109618의 특정 경로를 줄이는 임시 완화책으로 memory_limit = -1을 제시합니다.
하지만 이 설정은 PHP 메모리 상한을 없애는 것이므로 서버 메모리 고갈로 이어질 수 있습니다.

; 경고: 메모리 사용량 무제한. 격리/모니터링 없이 무작정 적용하지 말 것.
; memory_limit = -1

격리된 워커/컨테이너 또는 cgroup 단위의 적절한 메모리 정책이 준비된 경우에만 검토합니다.
이 설정 역시 완전한 방어가 아니라는 점을 유의하세요.
RLIMIT_AS나 RLIMIT_DATA를 대체 완화책으로 사용하지 마세요.

한 가지 더, session.upload_progress.enabled는 요청 처리 전에 적용되어야 합니다.
WordPress 코드의 ini_set()이나 .user.ini에만 넣지 말고, 웹 서버가 사용하는 주 설정 또는 관련 PHP-FPM 풀 설정에서 적용하세요.

4. PHP 워커 재시작

CVE-2026-109619는 해제된 메모리의 상태가 다음 요청에 남는 문제이므로, 설정을 바꾼 뒤 기존 워커를 모두 교체해야 효과가 있습니다.

sudo /opt/bitnami/ctlscript.sh status
# Apache 기반 설치의 예시
sudo /opt/bitnami/ctlscript.sh restart apache

PHP-FPM을 사용하는 경우 해당 PHP-FPM 서비스도 재시작하여 기존 워커가 남지 않도록 하세요.
실제 서비스 이름과 관리 방법은 Bitnami 버전에 따라 다릅니다.
재시작은 일시적인 서비스 중단을 일으킬 수 있으니 시간대를 골라 진행합니다.

5. 적용 결과 검증

/opt/bitnami/php/bin/php -i | grep -E \
  'memory_limit|post_max_size|upload_max_filesize|session.upload_progress.enabled'

예상되는 결과는 session.upload_progress.enabled => Off, post_max_size => 32M, upload_max_filesize => 16M입니다.
단, 이 결과는 CLI PHP의 설정입니다.
실제 WordPress를 처리하는 Apache mod_php나 PHP-FPM의 설정과 다를 수 있으므로, 웹 환경에 적용된 설정도 별도로 확인하세요.
공개 URL에 phpinfo() 페이지를 상시 노출하지 마세요.

설정 확인 후에는 다음 항목도 함께 점검합니다.

  • WordPress 홈, 관리자 로그인, 글 작성, 이미지 업로드가 정상 동작하는지 확인
  • 서버 에러 로그와 PHP 에러 로그 확인
  • 역방향 프록시/방화벽에서 관리 경로 접근 제한 검토
  • 서비스 노출이 높고 패치가 불가능하다면 외부 접근을 임시로 제한

6. 근본 해결: PHP 7.4 보안 백포트 또는 새 스택 이전

PHP 보안팀은 이번 두 취약점과 관련하여 PHP 7.4/8.0/8.1용 최소 소스 백포트를 제공했다고 공지했습니다.
다만 Bitnami 빌드 옵션, Apache/PHP 연동, 확장 모듈, OpenSSL 등 의존성 호환성을 검증한 뒤 적용해야 합니다.
패치가 적용되지 않은 PHP 7.4.16에서 설정 변경만으로는 해결되지 않습니다.

권장하는 작업 순서는 다음과 같습니다.

  1. WordPress 파일(wp-content, wp-config.php)과 데이터베이스를 각각 백업하고 복구 절차를 검증
  2. 별도 테스트 환경에서 패치된 Bitnami 호환 빌드 또는 최신 PHP 기반 WordPress 설치
  3. 테마/플러그인 호환성 및 업로드, 로그인, 캐시 기능 확인
  4. 서비스 전환 후 웹 요청이 사용하는 PHP 빌드와 관련 보안 패치 적용 여부 확인

7. 공식 참고 링크

마치며

정리하면, 지금 바로 session.upload_progress.enabled=0과 합리적인 업로드/요청 크기 제한을 적용하고 모든 PHP 워커를 재시작하세요.
이것은 어디까지나 임시 완화입니다.
운영 환경에서는 PHP 7.4 백포트를 검증해 적용하거나, 패치된 지원 버전의 PHP로 스택을 이전하는 것이 근본적인 해결책입니다.
지원이 끝난 PHP 7.4를 계속 쓰고 있다면 이번 기회에 이전 계획을 세워 두는 것을 권합니다.