PHP2Shell 취약점이 발생하면서 오래된 PHP 서버에 비상이 걸렸다.
2026년 10월 21일 PHP 실행 환경에서 심각한 보안 취약점 두 건이 공개됐다. PHP2Shell로 불리는 이번 취약점은 웹사이트의 로그인 기능이나 개발자가 작성한 특정 프로그램을 거치지 않고도 서버에 영향을 줄 수 있다는 점에서 위험성이 크다.
취약점 번호는 CVE-2026-109618과 CVE-2026-109619다. 한국인터넷진흥원(KISA)은 두 취약점의 위험도를 CVSS 9.2점으로 안내하고 기업에 신속한 보안 조치를 권고했다.
문제는 PHP를 사용하는 모든 기업이 최신 버전을 쉽게 적용할 수 있는 상황은 아니라는 것이다. 일부 기업에서는 10년 이상 운영한 홈페이지를 여전히 사용하고 있다. PHP 5.6이나 PHP 7.4를 사용하는 시스템도 있을 수 있으며, 프로그램을 개발한 업체가 사라졌거나 기존 소스코드에 대한 문서조차 남아 있지 않을 수 있다.
이런 시스템에서 PHP 버전을 무조건 변경하면 보안 문제는 해결되더라도 기존 프로그램이 실행되지 않는 새로운 문제가 발생할 수 있다.
그렇다면 오래된 PHP 시스템은 반드시 최신 버전으로 변경해야 할까? PHP 설정만 변경해도 괜찮을까? 핵심은 PHP 버전 업그레이드와 보안 패치가 반드시 같은 의미는 아니라는 점이다. 다만 이번 취약점 자체를 수정한 신뢰할 수 있는 보안 패치는 필요하다.
PHP2Shell은 파일 업로드 기능이 없어도 위험할까?
PHP2Shell은 PHP가 웹 요청을 처리하는 과정에서 메모리를 관리하는 방식과 관련된 취약점이다. 일반적인 웹사이트 보안 문제에서는 개발자가 작성한 프로그램의 오류가 원인이 되는 경우가 많다.
예를 들어 파일 업로드 기능에서 파일 확장자를 제대로 검사하지 않거나, 데이터베이스 조회 기능에서 사용자의 입력값을 안전하게 처리하지 않는 경우가 있다.
그러나 이번 취약점은 PHP 실행 엔진 내부의 요청 처리 과정과 연결된다. 특히 PHP의 세션 업로드 진행률 기능이 주요 공격 경로 중 하나로 확인됐다.
여기서 오해하기 쉬운 부분이 있다. 홈페이지에 파일 업로드 버튼이 없다고 해서 PHP 실행 엔진이 해당 기능과 관련된 요청을 처리할 가능성까지 사라지는 것은 아니다.
취약한 PHP 버전에서는 애플리케이션의 로그인이나 일반적인 파일 업로드 검증 로직이 실행되기 전에 문제가 발생할 수 있다. 따라서 게시판에 첨부파일 기능이 없는 홈페이지라도 사용 중인 PHP 버전과 실행 환경을 점검해야 한다.
또한 PHP-FPM, Apache mod_php 등 서버 구성에 따라 공격 조건과 위험성이 달라질 수 있으므로 PHP를 사용한다는 이유만으로 모든 서버의 공격 가능성이 완전히 동일하다고 단정해서도 안 된다.
session.upload_progress.enabled 설정은 무엇을 변경할까?
PHP에는 파일 업로드 진행 상황을 세션에 기록하는 기능이 존재한다. session.upload_progress.enabled 설정은 해당 기능을 사용할지 결정한다.
이 기능을 사용하면 파일 업로드 진행률 정보를 세션에 저장해 업로드 상태를 추적할 수 있다. 일반적인 파일 업로드 자체를 허용하거나 차단하는 기능과는 다르다.
PHP 8.2와 PHP-FPM 환경에서 설정을 변경하려면 운영 중인 서버의 설정 파일을 먼저 확인한다. Ubuntu 또는 Debian 계열에서 일반적인 PHP 8.2 설치 경로는 다음과 같다.
ls -l /etc/php/8.2/fpm/php.ini
현재 설정값을 확인한다.
grep -n "session.upload_progress.enabled" /etc/php/8.2/fpm/php.ini
설정 파일을 열어 다음과 같이 수정할 수 있다.
session.upload_progress.enabled = Off설정이 주석 처리돼 있다면 실제 적용되는 기본값을 별도로 확인해야 한다.
수정 후에는 PHP-FPM 서비스를 재시작한다.
sudo systemctl restart php8.2-fpm
그리고 실행 중인 PHP-FPM이 변경된 설정을 적용했는지 확인한다.
여기서 반드시 알아야 할 사실이 있다.
session.upload_progress.enabled = Off는 PHP2Shell의 모든 공격 경로를 막는 완전한 보안 패치가 아니다. 이 설정은 확인된 일부 공격 경로를 줄이기 위한 임시 완화 조치다. 다른 취약 경로까지 수정하는 것은 아니므로 보안 패치가 적용된 PHP로 업데이트해야 한다.
PHP 8.2를 사용한다면 반드시 최신 PHP로 바꿔야 할까?
이번 PHP2Shell 취약점에 대응하기 위해 PHP 프로젝트는 2026년 10월 21일 보안 수정 버전을 공개했다.
주요 수정 버전은 다음과 같다.
- PHP 8.2.35
-
PHP 8.3.36
-
PHP 8.4.27
-
PHP 8.5.12
예를 들어 PHP 8.2를 사용하는 프로젝트라고 해서 반드시 PHP 8.4나 8.5로 즉시 변경해야 한다는 의미는 아니다. PHP 8.2를 유지하면서 해당 취약점이 수정된 PHP 8.2.35 이상으로 업데이트하는 방법도 있다.
이는 PHP의 메이저·마이너 버전을 변경하는 것보다 기존 프로젝트의 호환성 부담을 줄일 수 있는 방법이다. 물론 기존 서버의 PHP 패키지가 어느 공급업체에서 제공됐는지도 확인해야 한다.
운영체제 공급업체가 보안 수정사항을 자체 패키지에 반영한 경우에는 PHP 버전 문자열만으로 패치 적용 여부를 판단하기 어려울 수 있다.
또한 이번 두 취약점이 수정됐더라도 해당 PHP 버전의 일반적인 보안 지원 종료 일정은 별도로 확인해야 한다. 특정 취약점 하나의 패치를 적용했다고 모든 보안 문제가 해결되는 것은 아니기 때문이다.
PHP 5.6과 PHP 7.4처럼 오래된 시스템은 어떻게 해야 할까?
PHP 5.6이나 PHP 7.4를 사용하는 오래된 홈페이지를 최신 PHP로 옮기는 것은 단순한 패키지 업데이트 작업으로 끝나지 않을 수 있다.
오래된 PHP 프로그램에는 현재 버전에서 더 이상 지원되지 않는 함수나 라이브러리가 포함돼 있을 수 있다. 데이터베이스 연결 방식이나 문자열 처리 방식, 세션 처리 방식 등에서도 호환성 문제가 발생할 수 있다.
이런 프로그램은 PHP 버전을 변경하는 과정에서 로그인 오류나 데이터 처리 오류가 발생할 수 있다. 따라서 운영 중인 시스템을 충분한 점검 없이 즉시 최신 PHP로 전환하는 것은 위험하다. 그렇다고 보안 취약점을 무시하고 계속 사용해도 된다는 뜻은 아니다. 현실적인 대응 방법은 세 가지 관점에서 살펴볼 수 있다.
첫째, 기존 PHP 버전에 이번 취약점을 수정한 보안 백포트가 제공되는지 확인하는 것이다. 백포트는 오래된 버전의 전체 기능을 새 버전으로 변경하지 않고 필요한 보안 수정사항을 이전 버전에 맞춰 적용하는 방식이다.
PHP 프로젝트는 이번 문제에 대해 일부 구버전의 수정 소스도 제공했다. 다만 수정 소스가 공개됐다는 사실과 실제 운영 환경에 검증된 보안 패키지가 제공된다는 사실은 구분해야 한다.
둘째, PHP 앞단의 웹서버나 방화벽에서 외부 접근을 제한하는 것이다. 관리자 페이지나 내부 업무 시스템처럼 외부에 공개할 필요가 없는 서비스는 VPN 또는 내부망으로 접근을 제한할 수 있다.
셋째, 장기적으로 지원되는 PHP 버전으로 이전하는 계획을 수립하는 것이다. 백포트는 특정 취약점에 대응하는 방법일 수 있지만, 지원이 종료된 실행 환경 전체의 장기적인 안전성을 보장하지 않는다.
PHP 보안 업데이트 없이 설정 변경만으로 운영할 수 있을까?
PHP 설정 변경, 방화벽, 접근 제한은 모두 보안을 강화하는 데 도움이 된다. 그러나 취약한 PHP 실행 엔진 자체를 수정하지 않는다는 한계가 있다.
예를 들어 외부에서 들어오는 요청을 일부 차단하더라도 내부 네트워크에서 해당 PHP 서버에 접근할 수 있다면 다른 위험이 남을 수 있다.
또한 공격에 사용되는 요청 형태가 변경되면 기존의 차단 규칙만으로 대응하기 어려울 수 있다. 특히 PHP2Shell처럼 PHP 엔진의 내부 메모리 처리와 관련된 취약점에서는 특정 설정 하나만으로 완전한 보호를 보장하기 어렵다.
따라서 설정 변경은 보안 패치를 적용하기 전까지의 임시 대응으로 이해하는 것이 적절하다. 보안 패치를 바로 적용할 수 없다면 외부 노출을 줄이고 접근을 제한하면서 공급업체의 수정 패키지와 공식 보안 정보를 확인해야 한다. 인터넷에 공개된 서비스라면 임시 조치만 적용한 채 장기간 운영하는 방식은 피해야 한다.
정부와 KISA의 PHP 보안 권고를 반드시 따라야 할까?
이번 PHP2Shell 취약점과 관련해 국내에서도 여러 기관이 대응에 나섰다. KISA는 PHP 사용 여부 확인, 보안 업데이트 적용, 시스템 노출 점검 등의 조치를 권고했다.
개인정보보호위원회 역시 PHP 기반 시스템의 보안 점검과 개인정보 접근 통제 강화를 강조했다. 이때 구분해야 할 것은 보안 권고와 법적 의무다.
KISA의 일반적인 보안 권고가 발표됐다는 이유만으로 모든 민간 홈페이지가 특정 PHP 버전으로 즉시 업그레이드해야 하는 동일한 법적 의무를 부담한다고 볼 수는 없다.
실제 의무는 기관의 성격, 개인정보 처리 여부, 적용되는 법령, 위탁계약, 보안 인증 및 관련 규정에 따라 달라질 수 있다. 다만 법적 의무 여부와 별개로 이미 알려진 심각한 취약점을 방치하면 실제 침해사고가 발생할 수 있다.
특히 개인정보를 보유한 사이트는 피해 발생 시 개인정보 보호 의무 이행 여부도 문제가 될 수 있으므로 위험을 적극적으로 관리해야 한다.
정부 권고를 무조건적인 프로그램 교체 명령으로 이해하기보다는 현재 시스템에 어떤 위험이 있는지 확인하고 적절한 보안 조치를 시행하라는 의미로 받아들이는 것이 합리적이다.
PHP 서버 업데이트 전후에 확인해야 할 사항
보안 패치를 적용할 때는 서버의 정상적인 운영도 중요하다.
먼저 현재 PHP 버전과 패키지 공급업체를 확인한다.
php -v
이 명령어는 명령줄에서 실행되는 PHP의 버전을 보여준다. 다만 PHP-FPM으로 운영하는 웹사이트에서는 명령줄 PHP와 실제 웹 요청을 처리하는 PHP 버전이 다를 수 있다.
따라서 PHP-FPM 서비스와 웹서버 설정까지 함께 확인하는 것이 좋다. 업데이트 전에는 소스코드, 데이터베이스, 주요 서버 설정을 백업하고 가능한 경우 별도 테스트 환경에서 호환성을 확인해야 한다.
업데이트 후에는 로그인, 파일 업로드, 데이터베이스 조회, 외부 API 연동, 예약 작업, 백그라운드 작업 등이 정상적으로 실행되는지 점검한다.
PHP-FPM 워커가 실제로 새로운 버전으로 교체됐는지도 확인해야 한다. 실제 운영 경험에서도 보안 설정 한 줄을 변경하는 것과 프로그램 전체를 업그레이드하는 작업은 영향 범위가 다르다.
설정 변경은 비교적 작은 작업일 수 있지만 실행 환경 변경은 애플리케이션 전반에 영향을 줄 수 있다. 따라서 보안 대응은 신속해야 하면서도 적용 결과를 검증하는 과정이 필요하다.
오래된 PHP 사이트도 안전하게 운영할 수 있을까?
오래된 PHP 사이트를 반드시 폐기해야 하는 것은 아니다. 기존 시스템에 신뢰할 수 있는 보안 수정사항을 적용할 수 있고, 필요한 접근 통제와 서버 관리가 이루어진다면 당장 전체 서비스를 재개발하지 않고 운영하는 방법을 검토할 수 있다. 그러나 보안 패치를 더 이상 제공받을 수 없거나 기존 개발 환경을 유지할 수 없는 상황이라면 장기적인 이전 계획이 필요하다.
PHP vs Java : 바이브코딩과 소규모 웹서비스에 PHP가 유리한 이유
내 개발 시장은 자바 중심인데 PHP를 선택해도 괜찮을까?국내 웹 개발 시장에서는 자바(Java)와 스프링(Spring)을 사용하는 기업을 쉽게 찾아볼 수 있다. 특히 금융권, 공...
www.th-study.com
▲ PHP 언어로 바이브코딩 안정성 개발 정리▲
PHP 5.6을 사용한다는 사실만으로 즉시 전체 프로그램을 자바로 다시 개발해야 하는 것은 아니다. 하지만 오래된 PHP를 아무런 보안 수정 없이 계속 사용해도 된다는 뜻 역시 아니다.
이번 PHP2Shell 취약점에서 얻을 수 있는 교훈은 명확하다. 모든 PHP 사이트를 최신 메이저 버전으로 즉시 이전할 필요는 없지만, 취약점이 수정된 안전한 실행 환경을 확보하는 일은 미뤄서는 안 된다.
'개발 > PHP' 카테고리의 다른 글
| PHP8 새롭게 추가된 어노테이션과 다양한 문법 정리 (14) | 2025.05.21 |
|---|
