PHP2Shell 보안 취약점 발견, 영향받는 PHP 버전과 긴급 패치 방법

PHP2Shell 긴급 보안 경고 및 PHP 보안 취약점 대응

 

2026년 10월 21일 공개된 PHP2Shell 보안 취약점으로 PHP 기반 웹서버를 운영하는 기업과 기관에 긴급 보안 점검이 요구되고 있습니다.

이번 취약점은 공격자가 로그인하지 않고도 웹서버에서 임의의 명령을 실행할 수 있다는 점에서 위험합니다. 서버 침해에 성공하면 연결된 데이터베이스(DB)의 고객 개인정보까지 유출될 우려가 있습니다.

한국인터넷진흥원(KISA)은 10월 22일 기업 보안 대응 수칙을 발표했으며, 개인정보보호위원회도 같은 날 개인정보 유출 예방조치를 당부했습니다.

영향받는 PHP 버전과 패치 방법, 개인정보 DB 보호대책, 서버 관리자가 실제로 점검해야 할 사항을 정리했습니다.

1. PHP2Shell 보안 취약점 핵심 내용

구분	주요 내용
취약점 공개	2026년 10월 21일
기업 대응 수칙 발표	2026년 10월 22일
주요 취약점	CVE-2026-109618, CVE-2026-109619
위험도	CVSS v4.0 기준 9.2점
주요 위험	인증 없는 원격 코드 실행
주요 대상	PHP 기반 웹서비스 운영 기업·기관
핵심 조치	보안 업데이트, 서비스 재시작, 로그 점검, DB 접근통제

 

핵심은 PHP 업데이트와 개인정보 DB 보호를 함께 수행하는 것입니다.

패치를 적용해 공격 경로를 차단하는 것도 중요하지만, 그 이전에 서버가 침해되었는지 확인하는 절차도 필요합니다.

KISA 보호나라 PHP2Shell 보안공지 화면

한국인터넷진흥원이 2026년 10월 22일 안내한 PHP2Shell 기업 보안 대응 수칙입니다. PHP 사용 현황 확인과 최신 패치 적용을 권고하고 있습니다.

2. PHP2Shell이란 무엇인가?

PHP는 웹사이트에서 회원가입, 로그인, 게시판, 데이터 조회 등 서버 측 기능을 구현하는 데 사용하는 프로그래밍 언어입니다.

PHP2Shell은 PHP의 내부 처리 과정에 존재하는 두 가지 보안 취약점을 통칭하는 명칭입니다.

이번 취약점의 가장 큰 특징은 공격자가 정상적인 사용자 인증을 거치지 않고 서버에서 명령을 실행할 수 있다는 점입니다.

이를 원격 코드 실행(RCE, Remote Code Execution)이라고 합니다.

두 가지 취약점의 차이

① CVE-2026-109618

PHP의 메모리 부족 상황을 처리하는 과정에서 내부 데이터가 정상적으로 초기화되지 않거나 정리되는 문제가 발생할 수 있는 취약점입니다.

특정 조건에서 잘못된 메모리 처리가 공격에 악용될 수 있습니다.

② CVE-2026-109619

PHP가 요청을 처리하면서 사용하던 내부 상태 정보가 메모리 해제 이후에도 남아 있는 문제와 관련됩니다.

이미 해제된 메모리와 연결된 정보가 재사용되면서 비정상적인 명령 실행으로 이어질 수 있습니다.

두 취약점은 발생 원리가 다르지만, 모두 인증 없는 원격 코드 실행으로 이어질 수 있다는 공통점이 있습니다.

위험도 9.2점은 어떤 의미인가?

두 취약점의 공식 CVSS v4.0 점수는 9.2점입니다.

CVSS는 보안 취약점의 심각도를 평가하는 공통 점수 체계입니다.

점수가 높을수록 공격 조건과 예상 피해 등을 고려한 위험 수준이 높다는 의미입니다.

다만 9.2점이라고 해서 모든 PHP 서버가 이미 해킹당했다는 뜻은 아닙니다. 실제 피해 여부는 서버 구성, 취약 버전 사용 여부, 외부 노출 상태, 공격 성공 여부 등에 따라 달라집니다.

3. 영향받는 PHP 버전과 보안 업데이트

KISA가 발표한 두 취약점의 해결 버전은 다음과 같습니다.

PHP 계열	영향받는 버전	보안 해결 버전
PHP 8.5	8.5.12 미만	8.5.12 이상
PHP 8.4	8.4.27 미만	8.4.27 이상
PHP 8.3	8.3.36 미만	8.3.36 이상
PHP 8.2	8.2.35 미만	8.2.35 이상
PHP 8.1 이하	PHP 공식 보안 지원 종료	지원 버전으로 전환 권고

 

PHP2Shell 영향받는 PHP 버전과 보안패치 해결 버전 비교

 

여기서 주의할 점이 있습니다.

PHP 8.2를 사용하고 있다고 해서 모두 동일한 보안 상태는 아닙니다. 8.2.34는 이번 취약점에 영향을 받지만, 8.2.35에는 해결 패치가 포함되어 있습니다.

또한 PHP 8.2는 2026년 12월 31일 공식 보안 지원이 종료될 예정이므로, 장기 운영을 고려한다면 PHP 8.3 이상 지원 계열로 전환하는 것이 권장됩니다.

리눅스 배포판이나 장기지원(LTS) 공급업체가 자체적으로 보안 수정사항을 이전 버전에 반영하는 경우도 있습니다. 따라서 표시되는 버전 번호뿐 아니라 실제 패치 적용 여부를 확인해야 합니다.

4. PHP 업데이트만으로 끝나지 않는 이유

서버 관리자가 놓치기 쉬운 부분은 업데이트 이후의 실행 상태입니다.

PHP 패키지를 새 버전으로 설치하더라도 웹서비스가 기존 PHP 프로세스를 계속 실행하고 있을 수 있습니다.

KISA는 업데이트 후 PHP-FPM, Apache mod_php, php-cgi 등 실제 사용 중인 PHP 실행 환경을 반드시 재시작하라고 권고했습니다.

도커와 같은 컨테이너 환경에서는 패치된 새 이미지로 재배포해야 합니다.

또한 서버 터미널에서 php -v 명령으로 확인되는 버전과 실제 웹서비스가 사용하는 PHP 버전은 다를 수 있습니다.

따라서 설치된 버전 확인 → 서비스 재시작 → 웹서비스 실행 버전 재확인까지 진행해야 합니다.

단, 침해 흔적이 의심되는 서버는 증거를 먼저 보존한 후 재시작 여부를 결정해야 합니다.

5. 개인정보 DB 유출은 어떻게 발생할 수 있나?

개인정보보호위원회가 특별히 강조한 부분은 웹서버와 데이터베이스 사이의 연결입니다.

일반적인 웹서비스는 다음과 같은 구조로 운영됩니다.

이용자 → 웹서버/PHP → 데이터베이스(DB)

정상적인 상황에서는 PHP 프로그램이 정해진 기능에 따라 DB에 접근합니다.

그러나 웹서버가 침해되고 공격자가 DB 접속정보나 과도한 접근권한까지 확보한다면 위험이 커질 수 있습니다.

이 경우 웹사이트 화면이 변조되는 수준을 넘어, 회원정보를 조회하거나 외부로 반출하는 피해로 이어질 수 있습니다.

이는 가능한 공격 경로를 설명한 것이며, 모든 PHP2Shell 공격에서 DB 유출이 발생한다는 의미는 아닙니다.

phpMyAdmin 관리도구도 점검해야 합니다

phpMyAdmin은 웹브라우저에서 MySQL·MariaDB 등의 데이터베이스를 관리할 수 있도록 지원하는 PHP 기반 관리도구입니다.

관리자는 이를 이용해 DB 구조를 확인하고 데이터를 조회하거나 관리할 수 있습니다.

문제는 이러한 관리도구가 인터넷에 직접 공개되어 있고 접근권한까지 과도하게 부여된 경우입니다.

개인정보보호위원회는 다음과 같은 조치를 권고했습니다.

• phpMyAdmin 등 DB 관리도구의 인터넷 직접 접근 제한
• 관리도구 버전 확인과 보안 업데이트
• 불필요한 설정파일 정리
• 웹서비스 계정에 부여된 개인정보 DB 접근권한 최소화
• 개인정보 대량조회 및 반출 이상행위 점검

여기서 구분할 점은 PHP2Shell이 곧 phpMyAdmin 자체에서 발견된 취약점이라는 뜻은 아니라는 사실입니다.

phpMyAdmin은 이번 취약점이 악용되었을 때 피해를 확대할 수 있는 관리환경 중 하나로 점검이 강조된 것입니다.

6. 기업과 기관의 긴급 보안 대응 절차

KISA 대응 수칙과 개인정보위 보도자료를 현장 점검 순서로 재구성하면 다음과 같습니다.

1단계. PHP 사용 시스템을 모두 찾아야 합니다

홈페이지뿐만 아니라 외주업체가 구축한 서비스, 관리자 페이지, 이벤트 서버, 테스트 서버도 확인해야 합니다.

네트워크 장비 관리 화면, PHP가 포함된 솔루션, 컨테이너 이미지도 점검 대상입니다.

자산관리대장에 등록된 서버뿐 아니라 실제 운영 중인 서버를 기준으로 조사하는 것이 중요합니다.

2단계. 보안패치를 적용합니다

인터넷에 공개된 취약 서버부터 우선 조치합니다.

보안패치를 적용한 뒤 실제 서비스가 수정된 PHP 코드를 사용하도록 관련 프로세스를 재시작하고, 서비스 정상 작동 여부를 확인합니다.

취약점 악용이 의심되는 시스템이라면 재시작 전에 로그와 메모리 등 침해 증거 보존을 우선해야 합니다.

3단계. 즉시 업데이트가 어렵다면 임시 보호조치를 적용합니다

KISA는 웹방화벽과 프록시를 통한 요청 크기 제한, 불필요한 파일 업로드 요청 차단, 최신 차단 규칙 적용 등을 권고했습니다.

PHP 공식 보안 권고문에는 session.upload_progress.enabled = 0 등의 임시 설정도 안내되어 있습니다.

다만 메모리 제한 관련 설정 변경은 서버의 자원 사용과 서비스 가용성에 영향을 줄 수 있으므로 공식 기술문서를 확인하고 운영환경에 맞게 적용해야 합니다.

임시 설정만으로 두 취약점을 완전히 해결할 수는 없습니다. 가능한 한 신속하게 정식 보안 업데이트를 적용해야 합니다.

4단계. 서버 로그와 비정상 행위를 점검합니다

KISA는 최소한 2026년 10월 20일 이후의 기록을 점검하고, 가능하면 그 이전 기록도 확인하라고 안내했습니다.

주요 확인사항은 다음과 같습니다.

• PHP 페이지에 전달된 비정상적으로 큰 요청
• 반복적인 HTTP 500 오류
• PHP 프로세스의 비정상 종료 및 메모리 오류
• 웹서버에서 예상하지 못한 시스템 명령 실행
• 새로운 PHP 파일이나 웹셸 설치 흔적
• 알 수 없는 외부 주소로의 통신

웹셸(Web Shell)은 공격자가 웹서버를 원격으로 조종하기 위해 설치하는 악성 프로그램입니다.

아울러 개인정보 DB의 대량조회, 대량반출, 평소와 다른 접속 패턴도 확인할 필요가 있습니다.

5단계. 중요한 인증정보를 교체합니다

KISA는 이번 취약점으로 서버 메모리에 남아 있는 비밀번호와 인증 토큰, API 키 등이 노출될 수 있다고 설명했습니다.

패치 전까지 인터넷에 노출되었던 서버의 DB 비밀번호, 관리자 비밀번호, 외부 서비스 연동 키 등은 교체를 권고하고 있습니다.

침해 흔적이 확인되었다면 해당 인증정보는 반드시 교체해야 합니다.

6단계. 침해사고가 의심되면 증거부터 보존합니다

KISA는 실제 침해사고가 발생한 경우 다음 순서를 권고했습니다.

외부 접속 차단 및 격리 → 침해사고 신고 → 로그·메모리 관련 증거 확보 → 업데이트·악성코드 제거·인증정보 교체

침해사고가 의심되는 서버를 무작정 종료하거나 재시작하면 메모리에 남아 있는 공격 흔적이 사라질 수 있습니다.

일반적인 예방 패치 작업과 실제 사고 대응 절차는 구분해야 합니다.

 

PHP2Shell 웹서버 및 개인정보 DB 보안점검 6단계

 

7. 기업과 외주업체는 각각 무엇을 확인해야 하나?

실무에서는 웹서비스 운영자와 실제 서버 관리자가 다른 경우가 많습니다.

구분	우선 확인할 사항
자체 서버 운영 기업	PHP 버전, 서비스 재시작, 웹서버 로그
웹 개발·유지보수 업체	고객사 시스템 현황, 패치 적용 결과
호스팅 이용 기업	호스팅 업체의 PHP 패치 적용 여부
공공기관	외주 시스템, DB 접근권한, 개인정보 이상행위
클라우드·컨테이너 운영자	이미지 패치, 재배포, 실제 실행 버전

 

특히 외주 운영환경에서는 계약상 관리 책임과 실제 기술적 조치 담당자를 구분해야 합니다.

운영기관은 외주업체로부터 단순히 '업데이트 완료'라는 답변만 받을 것이 아니라, 적용된 PHP 버전과 패치 이력, 서비스 재시작 여부, 이상징후 점검 결과를 확인하는 것이 바람직합니다.

이는 공식 권고를 현장 운영관리 관점에서 구체화한 점검 방법입니다.

8. 개인정보 보호법과 어떤 관계가 있나?

이번 발표는 새로운 보안 의무를 신설한 법령 개정이 아니라, 기존 개인정보 보호 의무에 따라 긴급 조치를 당부한 것입니다.

「개인정보 보호법」 제29조는 개인정보처리자가 개인정보의 안전성을 확보하기 위해 필요한 기술적·관리적·물리적 조치를 해야 한다고 규정하고 있습니다.

이번 사안에서 특히 관련되는 관리영역은 보안패치, 접근권한 관리, 접속기록 보관과 이상행위 점검입니다.

단순히 PHP의 최신 버전만 유지한다고 모든 개인정보 보호 의무가 충족되는 것은 아닙니다.

DB 접근통제와 개인정보 처리시스템의 로그 관리, 위탁업체에 대한 관리·감독도 함께 검토해야 합니다.

9. 기대효과와 현실적인 한계

보안패치는 취약점 악용 경로를 제거하는 가장 중요한 조치입니다.

그러나 오래된 웹서비스나 외주 관리 시스템에서는 즉시 버전을 변경하기 어려운 상황도 발생할 수 있습니다.

예를 들어 PHP 버전을 변경하면서 기존 프로그램과의 호환성 문제가 생길 수 있습니다. 이 경우 기능 시험과 서비스 영향 검토가 필요합니다.

또한 업데이트가 완료되었다고 해서 패치 이전에 이미 발생했을 수 있는 침해 흔적까지 사라지는 것은 아닙니다.

따라서 이번 보안 대응은 세 가지 측면에서 접근해야 합니다.

첫째, 취약한 PHP 실행환경을 수정해야 합니다.

둘째, 서버 침해 여부와 개인정보 접근기록을 확인해야 합니다.

셋째, 운영환경의 보안관리 사각지대를 줄여야 합니다.

정보통신 시스템의 설계·운영·유지관리 관점에서도 소프트웨어 자산 현황을 정확하게 파악하고, 변경 후 검증 결과를 기록하는 체계가 중요하다는 점을 보여주는 사례입니다.

10. PHP2Shell 자주 묻는 질문

Q1. PHP2Shell 취약점은 언제 공개되었나요?

2026년 10월 21일 PHP 보안 업데이트와 관련 기술정보가 공개되었습니다. KISA는 10월 21일 보안 업데이트를 권고했고, 10월 22일 기업 대응 수칙을 추가 안내했습니다.

Q2. PHP를 사용하는 모든 홈페이지가 위험한가요?

PHP 사용 여부만으로 취약하다고 단정할 수 없습니다. 실제 실행 버전과 공급업체의 패치 적용 여부, 서버 설정 등을 확인해야 합니다. 지원이 종료된 구버전도 별도 점검이 필요합니다.

Q3. 패치만 하면 안전한가요?

정식 패치는 해당 취약점 해결에 필요하지만, 패치 이전 침해 여부까지 확인해 주지는 않습니다. 서비스 재시작, 로그 점검, 인증정보 관리가 함께 필요합니다.

Q4. phpMyAdmin을 사용하면 무조건 위험한가요?

그렇지 않습니다. 다만 인터넷 직접 접근이 허용되어 있거나 과도한 DB 권한이 부여된 경우에는 피해 확대 위험이 있습니다. 관리도구 접근 제한과 권한 최소화가 중요합니다.

Q5. 호스팅 업체가 PHP를 관리한다면 직접 조치해야 하나요?

PHP 패치 적용은 실제 관리 주체가 수행해야 합니다. 이용 기업이나 기관은 호스팅 업체에 적용 여부를 확인하고 필요한 조치를 요청해야 합니다.

Q6. 일반 이용자는 무엇을 해야 하나요?

이번 공지는 주로 기업과 기관의 서버 운영자를 대상으로 합니다. 일반 이용자가 직접 PHP를 업데이트할 필요는 없습니다.

다만 이용 중인 서비스에서 개인정보 유출 안내를 받았다면 해당 서비스의 공식 안내에 따라 대응해야 합니다.

11. 한 줄 정리

PHP2Shell 대응의 핵심은 PHP 보안패치뿐 아니라 웹서버 침해 흔적과 개인정보 DB 접근권한까지 함께 점검하는 것입니다.

서버를 운영하는 기업과 기관은 사용 중인 PHP 버전을 확인하고, 패치 적용과 서비스 재시작, 로그 점검, 개인정보 접근통제를 신속히 수행할 필요가 있습니다.

12. 출처 및 참고자료

• 자료명: PHP 보안취약점(PHP2Shell) 관련 기업 보안 대응 수칙
• 발표 기관: 한국인터넷진흥원(KISA)
• 발표일: 2026년 10월 22일
• 관련 보안 업데이트 발표일: 2026년 10월 21일
• 자료명: 개인정보위, PHP 보안 취약점 관련 개인정보 유출 예방조치 당부
• 발표 기관: 개인정보보호위원회
• 발표일: 2026년 10월 22일 16:00
• 별도 시행일: 없음(긴급 보호조치 권고)
• 원문 기준일: 2026년 10월 22일

공식 참고자료

• KISA PHP2Shell 기업 보안 대응 수칙 원문
• KISA PHP 제품 보안 업데이트 권고
• PHP 공식 보안 업데이트 안내
• 개인정보 보호법 제29조 안전조치의무

※ 본문은 2026년 10월 22일 공식 발표자료를 기준으로 작성한 기술 해설입니다. 시스템별 정확한 적용사항은 공급업체 보안공지와 실제 운영환경을 함께 확인하시기 바랍니다.

 

작성자: 정보통신기술사 박승우