마루옵스서버 · 네트워크 · AI 기술 노트

소개문의

보안이슈취약점·대응

PHP 보안취약점(PHP2Shell): 기업 보안 대응 수칙

MaruOps

데이터센터의 서버 캐비닛 통로

참고 사진 · 123Net 데이터센터의 서버 캐비닛 통로 · 사진: 123net / 원본 / CC BY-SA 3.0 · 목록용 크기 조정

회사 홈페이지나 WordPress를 운영한다면 먼저 웹서버가 사용하는 PHP에 보안 패치가 적용됐는지 확인해야 합니다. PHP2Shell은 게시판이나 플러그인 하나의 문제가 아니라, 웹페이지를 실행하는 PHP 자체에서 발견된 취약점입니다.

이 글은 KISA의 「PHP 보안취약점(PHP2Shell) 관련 기업 보안 대응 수칙」을 바탕으로 운영자가 확인할 내용을 풀어 설명합니다. 기준일은 2026년 10월 22일이며, 홈페이지 담당자·서버 운영자·호스팅 이용자를 대상으로 합니다.

이 글의 목차

PHP2Shell은 어떤 문제인가요?

PHP를 웹페이지를 만드는 작업자로 생각하면 이해하기 쉬워요. 작업이 중간에 실패했을 때 사용하던 메모리를 정리하는 과정에 문제가 생기고, 공격자가 그 틈을 이용할 수 있습니다. PHP2Shell은 이와 관련된 두 취약점을 부르는 이름입니다.

  • CVE-2026-109618: 메모리 부족 오류를 처리하는 과정에서 잘못된 메모리 상태를 사용할 수 있는 문제입니다.
  • CVE-2026-109619: 이전 요청에서 사용하던 내부 상태가 남아 다음 요청에서 잘못 사용될 수 있는 문제입니다.

조건이 맞으면 로그인하지 않은 공격자가 웹서버 권한으로 명령을 실행하거나, 메모리에 남은 인증정보를 읽을 수 있습니다. 두 취약점의 심각도는 CVSS 4.0 기준 9.2입니다. 모든 환경에서 같은 방식으로 공격이 성공한다는 뜻은 아니지만, PHP-FPM을 사용한다는 이유만으로 점검을 생략해서는 안 됩니다. (PHP 공식 공지: 메모리 부족 처리, PHP 공식 공지: 요청 간 상태 처리)

WordPress 본체와 플러그인을 업데이트해도 PHP가 함께 바뀌는 것은 아닙니다. 웹서버나 호스팅 환경에서 PHP 보안 업데이트를 별도로 확인해야 합니다.

어느 PHP 버전으로 업데이트해야 하나요?

PHP 프로젝트가 2026년 10월 21일 공개한 수정 버전은 다음과 같습니다. 사용 중인 버전 계열에서 수정 버전 이상으로 올리거나, 운영체제·제조사가 제공한 해당 CVE 보안 패치를 적용합니다. (PHP 보안 업데이트 안내)

사용 중인 계열공식 수정 버전
PHP 8.28.2.35 이상
PHP 8.38.3.36 이상
PHP 8.48.4.27 이상
PHP 8.58.5.12 이상

예를 들어 PHP 8.3.35는 위 표의 수정 버전에 미달합니다. 다만 리눅스 배포판은 기존 버전 번호를 유지하면서 보안 수정만 적용하기도 합니다. 이를 백포트라고 하며, 이런 패키지는 숫자만 비교하지 말고 공급사의 보안 공지와 패키지 변경 이력에서 두 CVE의 수정 여부를 확인합니다.

PHP 8.1 이하는 PHP 프로젝트의 정규 지원이 종료됐습니다. 배포판·장기지원 업체의 패치나 일부 구버전용 소스 패치는 임시 대응에 활용할 수 있지만, 지원 버전으로 옮길 계획이 필요합니다. PHP 8.2의 보안 지원도 2026년 12월 31일 종료 예정이므로 새로 전환한다면 애플리케이션 호환성을 확인해 8.3 이상을 검토하는 편이 좋습니다. (PHP 공식 지원 기간)

운영자는 무엇부터 확인하면 되나요?

1. 실제로 동작 중인 PHP를 찾습니다

공개 홈페이지부터 확인하고 관리자 페이지, 테스트 서버, 외주 제작 사이트도 목록에 넣습니다. 호스트 운영체제의 PHP만 확인하면 컨테이너나 솔루션 안에 따로 들어 있는 PHP를 놓칠 수 있어요. 실행 위치마다 버전과 패치 상태를 따로 기록합니다. (NCSC-NL의 PHP2Shell 자산 점검 자료)

서버에 접속할 수 있다면 다음 명령으로 기본 PHP 버전을 확인할 수 있습니다. Docker Compose 예시는 서비스 이름이 wordpress인 환경을 가정합니다.

# 서버의 기본 PHP 확인
php -v

# Docker Compose로 운영하는 WordPress 컨테이너의 PHP 확인
docker compose exec wordpress php -v

이 명령은 명령줄용 PHP(CLI)를 보여줍니다. 웹사이트를 처리하는 PHP-FPM이나 Apache가 다른 PHP를 사용할 수 있으므로 실제 웹 요청을 처리하는 실행 파일·패키지·컨테이너까지 대조해야 합니다. 공개된 phpinfo() 페이지를 만들어 두기보다는 관리자 도구나 서버 설정에서 확인하세요.

2. PHP를 업데이트하고 실행 중인 프로세스를 교체합니다

정상 백업과 복구 방법을 확인하고, 가능한 별도 환경에서 로그인·주요 업무·파일 업로드가 정상 동작하는지 시험합니다. 인터넷에 공개된 서비스를 먼저 조치하되, 침해가 의심되는 서버는 아래의 증거 보존 절차를 먼저 따릅니다.

패키지만 업데이트해도 메모리에서 실행 중인 이전 PHP가 자동으로 교체된다고 가정해서는 안 됩니다. PHP-FPM, Apache mod_php 등 사용 중인 방식에 맞게 웹 서비스와 PHP 작업 프로세스를 재시작합니다. 컨테이너는 수정된 PHP가 들어 있는 이미지로 다시 만들어 배포해야 하며, 이전 컨테이너를 재시작하는 것만으로는 이미지가 바뀌지 않습니다.

재시작 후에는 웹서비스가 실제로 수정된 PHP를 사용하고 있는지 다시 확인합니다. 호스팅이나 장비에 PHP가 내장돼 있다면 공급사가 제공하는 업데이트와 재시작 절차를 따릅니다.

3. 로그를 살피고 노출 가능성이 있는 인증정보를 교체합니다

KISA는 최소한 취약점 정보가 유출된 2026년 10월 20일 이후의 기록을 점검하고, 가능하면 그 이전 기록도 확인하도록 안내합니다. 요청 로그뿐 아니라 PHP 오류, 실행된 프로세스, 파일 변경, 외부 연결 기록을 함께 살펴봅니다.

  • 큰 요청이 들어온 직후 반복되는 HTTP 500 오류, 메모리 부족, 원인 불명의 PHP 비정상 종료
  • 웹서버가 sh·bash 같은 셸이나 다운로드 도구를 실행한 흔적
  • 웹·업로드·임시 폴더에 새로 생긴 PHP 파일, 변경된 페이지, 낯선 외부 스크립트나 통신

이상 로그가 없다는 사실만으로 정보 유출을 배제할 수는 없습니다. 패치 전 인터넷에 노출된 서버는 DB 비밀번호, 관리자 비밀번호, API 키 등 PHP가 접근하던 인증정보의 교체를 검토합니다. 침해 흔적이 있다면 증거를 보존하고 서버를 정비한 뒤 관련 인증정보를 반드시 교체합니다. 이미 발급된 토큰·세션도 폐기할 범위를 함께 확인합니다.

바로 업데이트하기 어렵다면

임시 조치는 패치 전까지 노출을 줄이기 위한 수단입니다. 웹 방화벽(WAF)의 최신 규칙을 확인하고, 앞단 웹서버·프록시에서 요청 크기를 제한합니다. 파일 업로드를 사용하지 않는 서비스라면 multipart 요청 차단도 검토합니다.

PHP 공식 설정 지침에는 다음 항목이 포함됩니다. 서비스 구조에 따라 적용 위치가 다르므로 담당자가 공식 문서를 확인한 뒤 적용하고 모든 PHP 작업 프로세스를 재시작해야 합니다.

  • 업로드 진행률: session.upload_progress.enabled=0. 요청 처리 전에 적용되는 서버 설정을 사용합니다.
  • PHP 메모리 제한: memory_limit=-1을 애플리케이션이 바꾸지 못하도록 적용하는 방안을 검토합니다. 앞단 요청 제한과 자원 보호가 함께 필요합니다.
  • 요청·업로드 크기: post_max_size를 낮추고 upload_max_filesize를 그보다 작게 유지합니다. 앞단에서는 길이 정보가 없는 요청도 제한합니다.
  • PHP 8.5 추가 항목: fatal_error_backtraces=0을 적용합니다. 다른 버전에 그대로 넣는 설정은 아닙니다.

memory_limit=-1은 PHP 자체의 메모리 상한을 없애는 값입니다. 큰 요청을 그대로 받으면 서버 자원 고갈 위험이 커지므로 이 값만 복사해 넣어서는 안 됩니다. PHP 공식 문서는 앞단 제한과 컨테이너·cgroup 자원 경계를 함께 검토하도록 안내합니다. 위 설정을 모두 적용해도 업데이트를 대신할 수는 없습니다. (PHP 공식 임시 대응 지침)

임시 조치도 적용하기 어렵다면 수정 전까지 외부 접근을 제한하거나 서비스 일시 중단을 검토합니다. 패치 후에는 임시로 바꾼 메모리·업로드 설정을 다시 검토하고 정상적인 자원 제한을 구성합니다.

침해가 의심되면 재시작 전에 증거를 보존합니다

웹셸은 공격자가 서버를 원격으로 조작하려고 심어 놓는 파일입니다. 이런 파일이나 수상한 명령 실행이 보인다면, 정상 서버의 업데이트 절차와 구분해서 대응해야 합니다.

  1. 격리: 서버 전원을 끄거나 재시작하지 말고 외부에서 접근하지 못하도록 네트워크를 격리합니다.
  2. 신고: 보호나라의 「침해사고 신고 → 신고하기」로 접수하고 보안 담당자와 대응을 진행합니다.
  3. 증거 보존: 로그, 실행 중인 프로세스, 네트워크 연결 정보 등 조사에 필요한 자료를 확보합니다. 재시작하면 메모리의 흔적이 사라질 수 있습니다.
  4. 복구: 증거 확보 후 패치·재시작, 웹셸 제거, 인증정보 교체를 진행하고 신뢰할 수 있는 상태로 복구됐는지 확인합니다.

출처를 확인할 수 없는 취약점 검증 코드(PoC)를 운영 서버에서 실행하지 마세요. 악성코드가 섞인 가짜 도구일 수 있습니다. 우선 버전·공급사 패치 공지·운영 기록으로 확인하고, 추가 검증은 업무망과 분리된 환경에서 진행합니다.

호스팅 업체에는 이렇게 물어보세요

직접 PHP를 관리하지 않는다면 「최신 버전인가요?」보다 확인할 항목을 구체적으로 전달하는 편이 좋습니다. 다음 내용은 문의할 때 사용할 수 있는 예시입니다.

우리 사이트가 실제로 사용하는 PHP 버전과 CVE-2026-109618·CVE-2026-109619 패치 적용 여부를 확인해 주세요. 공급사 패치라면 근거 공지나 패키지 정보를 부탁드립니다. 업데이트 후 PHP 작업 프로세스 재시작 여부와 로그 점검·인증정보 교체가 필요한 범위도 알려 주세요.

우선 기록할 것은 「실제 사용 PHP → 패치 근거 → 재시작·재배포 완료 → 서비스 확인」입니다. 침해 의심 정황이 있으면 증거 확보를 앞에 두고 대응합니다.

확인한 공식 자료

이 글은 위 공식 자료를 2026년 10월 22일 확인해 작성한 운영 안내입니다. 특정 기업의 서버를 진단했거나 침해 여부를 판정한 결과는 아닙니다. 패치와 공급사 안내는 변경될 수 있으므로 실제 적용 시 원문을 다시 확인합니다.

함께 읽을 글