홈
콘텐츠 센터
콘텐츠 센터
웹콘텐츠
위협 소식 ◦ 위협 분석 ◦ 위협 대응

PHP2Shell 대응, 기업이 확인해야 할 8가지 수칙

KISA, 기업 보안 대응 수칙 배포…자산 점검부터 침해사고 대응까지

PHP에서 인증 없이 원격 코드 실행이 가능한 중대 취약점 2건(CVE-2026-109618, CVE-2026-109619)이 발견되면서 기업의 신속한 보안 대응이 요구되고 있다.

한국인터넷진흥원(KISA)은 이와 관련해 「PHP 보안취약점(PHP2Shell) 관련 기업 보안 대응 수칙」을 배포하고, PHP를 사용하는 기업에 즉각적인 점검과 조치를 권고했다.

KISA에 따르면 이번 취약점은 보안 업데이트가 배포되기 전에 관련 정보가 유출됐으며, 해외 보안업체를 중심으로 공격 시도도 보고되고 있다. 공격에 성공할 경우 웹셸(Web Shell) 설치, 고객 정보 유출, 홈페이지 변조, 내부망 침투 등으로 이어질 수 있다.

KISA가 제시한 대응 수칙은 단순히 PHP를 최신 버전으로 업데이트하는 데 그치지 않는다. 관리되지 않는 서버와 장비의 PHP 사용 여부를 확인하고, 업데이트 후 실제 적용 상태를 점검하는 것은 물론, 침해 흔적 확인과 인증정보 교체, 사고 발생 시 대응 절차까지 포함한다.

기업 보안 담당자가 확인해야 할 8가지 대응 수칙을 살펴본다.

1. 운영 중인 모든 PHP 사용 환경 확인

첫 번째는 조직 내에서 실제로 사용 중인 PHP 환경을 빠짐없이 확인하는 것이다.

KISA는 인터넷에 공개된 모든 홈페이지와 시스템을 대상으로 PHP 사용 여부와 버전을 확인하도록 권고했다. 특히 현재 관리 중인 주요 웹사이트뿐 아니라 다음과 같은 환경도 점검 대상에 포함해야 한다.

  • 외주업체가 제작하거나 운영하는 웹사이트
  • 오래전에 구축돼 현재 관리되지 않는 사이트
  • 이벤트 및 테스트 서버
  • 외부에서 접근할 수 있는 관리자 페이지
  • PHP가 내장된 네트워크 장비 관리 화면 및 솔루션
  • PHP가 포함된 설치 패키지와 외부 컨테이너 이미지

중요한 것은 자산 관리 목록에 등록된 서버만 확인해서는 안 된다는 점이다. KISA는 자산 관리 목록에만 의존하지 말고 실제 동작 중인 서버를 기준으로 점검할 것을 강조했다.

호스팅 업체나 장비·솔루션 제조사가 PHP를 관리하는 환경이라면 해당 업체에 취약점 대응 조치의 적용 여부를 확인하고 필요한 조치를 요청해야 한다.

2. 보안 업데이트 후 웹 서비스 재시작 및 적용 여부 확인

KISA는 취약점이 해결된 PHP 버전으로 업데이트하고, 인터넷에 공개된 서버부터 우선 조치하도록 권고했다.

KISA 자료에 명시된 수정 버전은 다음과 같다.

PHP 버전 계열 수정 버전
PHP 8.5 8.5.12 이상
PHP 8.4 8.4.27 이상
PHP 8.3 8.3.36 이상
PHP 8.2 8.2.35 이상

업데이트 후에는 PHP를 실행하는 웹 서비스를 반드시 재시작해야 한다.

PHP-FPM, Apache mod_php, php-cgi, FrankenPHP, LiteSpeed 등 PHP를 실행하는 서비스가 재시작되지 않으면 메모리에 남아 있는 이전 버전이 계속 동작할 수 있기 때문이다. 컨테이너 환경에서는 보안 수정 사항이 반영된 새 이미지를 재배포해야 한다.

또한 업데이트가 완료됐더라도 웹 서비스가 실제로 사용하는 PHP 버전이 변경됐는지 확인해야 한다.

명령어 php -v로 확인되는 버전과 실제 웹 서비스에서 사용하는 버전이 다를 수 있으며, 한 서버에 여러 PHP 버전이 설치된 경우에는 각각 점검이 필요하다.

리눅스 배포판이나 제조사가 제공하는 패키지는 보안 패치를 적용해도 버전 번호가 변경되지 않을 수 있다. 이 경우 패키지 변경 이력을 통해 해당 취약점의 수정 사항이 반영됐는지 확인해야 한다.

3. 지원이 종료된 PHP 구버전은 전환 계획 수립

PHP 8.1 이하 버전은 공식 업데이트가 제공되지 않으므로 지원되는 버전으로 전환해야 한다.

KISA는 PHP 8.2 역시 2026년 12월 31일 보안 지원이 종료될 예정인 만큼, PHP 8.3 이상으로 전환할 것을 권고했다.

구버전 환경을 즉시 전환하기 어렵다면 리눅스 배포판이나 장기지원(LTS) 업체가 제공하는 보안 패치, 또는 PHP 보안팀이 공개한 PHP 7.4·8.0·8.1용 소스 패치를 임시로 적용하고 전환 계획을 수립해야 한다.

적용할 수 있는 패치가 없는 경우에는 임시 완화 조치를 검토해야 하며, 이를 수행하기 어려운 환경에서는 외부 접속 차단이나 서비스 일시 중단을 고려하도록 안내했다.

4. 즉시 업데이트가 어렵다면 임시 완화 조치 적용

운영 환경이나 서비스 특성상 즉시 업데이트하기 어려운 경우에는 공격 가능성을 낮추기 위한 임시 조치가 필요하다.

KISA는 웹 방화벽(WAF), 웹 서버, 프록시 등 PHP 앞단에서 요청 크기를 제한하고, 파일 업로드 기능이 필요 없는 서비스에서는 multipart 형식의 파일 업로드 요청을 차단하도록 권고했다. 이때 요청 크기 정보가 없는 요청도 제한 대상에 포함해야 한다.

웹 방화벽을 사용하는 환경이라면 최신 차단 규칙이 적용됐는지도 확인해야 한다.

또한 KISA는 PHP 공식 임시 설정을 php.ini, PHP-FPM pool 설정 또는 웹 서버 설정에 적용하도록 안내했다.

설정 항목 KISA 권고 내용
session.upload_progress.enabled 0으로 설정해 파일 업로드 진행률 표시 기능 비활성화
memory_limit -1로 설정하고, 프로그램이 변경하지 못하도록 관리자 설정으로 지정
post_max_size 낮게 설정. 업로드가 불필요하면 8M, 필요하면 32M 수준
upload_max_filesize post_max_size보다 작게 유지
fatal_error_backtraces PHP 8.5 사용 시 0으로 설정

memory_limit은 PHP-FPM pool의 php_admin_value와 같은 관리자 설정으로 지정하도록 안내하고 있다.

설정을 적용한 후에는 모든 PHP 프로세스를 재시작해야 한다.

다만 임시 조치만으로 공격을 완전히 차단할 수 있는 것은 아니다. KISA는 임시 완화 조치를 적용한 환경에서도 보안 업데이트를 실시할 것을 권고했다.

임시 조치조차 적용하기 어려운 경우에는 업데이트 전까지 외부 접속을 차단하거나 서비스를 일시 중단하는 방안도 검토해야 한다.

5. 업데이트 후에도 침해 흔적 점검

보안 업데이트를 완료했다고 해서 이미 발생했을 가능성이 있는 침해까지 해결되는 것은 아니다.

KISA는 최소 10월 20일 이후의 서버 기록 전체를 점검하고, 가능하다면 그 이전 기록까지 확인하도록 권고했다.

주요 점검 항목은 다음과 같다.

  • PHP 페이지로 유입된 비정상적으로 큰 요청과 이후 반복된 HTTP 500 오류
  • 원인을 알 수 없는 PHP 프로그램 재시작이나 비정상 종료(segfault), 메모리 부족 오류
  • 웹 서버에서 sh, bash 등 명령 실행 프로그램이나 파일 다운로드 도구를 실행한 흔적
  • 웹 폴더, 업로드 폴더, 임시 폴더에 새로 생성되거나 변경된 PHP 파일
  • 홈페이지나 결제 페이지에 무단으로 추가된 외부 스크립트
  • 웹 서버에서 알 수 없는 외부 주소로 새롭게 연결한 흔적

특히 웹 폴더나 업로드 폴더 등에 생성된 의심스러운 PHP 파일은 공격자가 서버를 원격으로 제어하기 위해 설치한 웹셸일 가능성을 확인해야 한다.

KISA는 로그에서 이상 징후가 발견되지 않더라도 안전이 보장되는 것은 아니므로, 업데이트와 인증정보 교체를 함께 진행하도록 안내했다.

6. DB 비밀번호와 API 키 등 중요 인증정보 교체

이번 취약점은 서버 메모리에 저장된 비밀번호, 인증 토큰, 외부 서비스 연동용 API 키 등이 유출되는 결과로 이어질 수 있다.

이에 KISA는 보안 업데이트 전까지 인터넷에 노출됐던 서버를 대상으로 다음 인증정보의 교체를 권고했다.

  • 데이터베이스(DB) 접속 비밀번호
  • 외부 서비스 연동용 API 키
  • 관리자 계정 비밀번호

특히 침해 흔적이 발견된 서버에서는 중요 인증정보를 반드시 교체해야 한다.

이는 취약점 자체를 수정하더라도 이미 유출됐을 가능성이 있는 인증정보가 계속 사용되면 추가적인 보안 위험이 남을 수 있기 때문이다.

7. 침해사고 발생 시 증거 확보를 우선

침해사고가 의심되거나 실제 침해가 확인된 경우에는 대응 순서에도 주의해야 한다.

KISA는 다음과 같은 절차를 제시했다.

① 격리: 서버를 종료하거나 재시작하지 말고, 네트워크에서 외부 접속을 차단한다.

② 신고: 보호나라(https://boho.or.kr)의 ‘침해사고 신고’ 메뉴를 통해 신고한다.

③ 증거 확보: 서버 로그, 실행 중인 프로그램 목록, 네트워크 연결 정보 등을 보존한다.

④ 조치 및 복구: 보안 업데이트와 서비스 재시작, 웹셸 제거, 인증정보 교체 등 필요한 조치를 진행한다.

특히 서버를 재시작하면 메모리에 남아 있는 공격 흔적이 사라질 수 있다. 따라서 침해사고가 발생한 환경에서는 업데이트나 재시작에 앞서 증거를 확보해야 한다.

이는 일반적인 취약점 패치 절차와 침해사고 발생 시 대응 절차를 구분해야 한다는 의미다.

8. 출처가 불분명한 PoC 실행 지양

마지막으로 KISA는 인터넷에 공개된 PoC(Proof of Concept, 개념 증명) 코드의 무분별한 실행을 경고했다.

취약점 공개 이후 유포되는 PoC 중에는 악성 코드가 숨겨진 가짜 PoC가 포함될 수 있기 때문이다.

KISA는 취약 여부를 확인하기 위해 검증되지 않은 PoC를 직접 실행하기보다, PHP 버전 확인과 서버 기록 점검을 통해 취약 여부를 판단하도록 권고했다.

분석 목적으로 PoC 실행이 반드시 필요한 경우에도 업무망과 분리된 환경에서만 수행해야 한다.

PHP2Shell 대응, 패치 이후까지 확인해야

KISA의 이번 기업 보안 대응 수칙은 PHP2Shell 대응이 단순한 소프트웨어 업데이트로 끝나지 않는다는 점을 강조한다.

실제 운영 중인 PHP 자산을 빠짐없이 파악하고, 업데이트 후 서비스 재시작과 패치 적용 여부를 확인해야 한다. 또한 취약점 정보가 공개된 시점을 고려해 침해 흔적을 점검하고, 필요에 따라 중요 인증정보 교체와 사고 대응 절차까지 진행해야 한다.

특히 외주 운영 사이트나 장비에 내장된 PHP, 지원이 종료된 구버전 환경 등은 일반적인 서버 관리 과정에서 놓치기 쉬운 점검 대상이다.

기업 보안 담당자는 KISA가 제시한 8가지 대응 수칙을 기준으로 자사 환경을 점검하고, 확인된 위험에 따라 필요한 조치를 수행해야 한다.

참고자료

본 콘텐츠는 한국인터넷진흥원(KISA)이 배포한 「PHP 보안취약점(PHP2Shell) 관련 기업 보안 대응 수칙」을 바탕으로 기업 보안 담당자가 확인해야 할 주요 내용을 재구성한 것입니다. 구체적인 설정과 대응 절차는 KISA 원문 및 관련 공식 권고를 함께 확인하시기 바랍니다.

 
  • AhnLab
목록 보기