PHP2Shell 공격으로 서버 25대가 장악된 정황이 확인됐습니다.
2026년 10월 29일, PHP 취약점을 악용한 사이버 공격으로 전 세계 서버 25대의 최고 관리자 권한이 탈취된 정황이 보도됐습니다. 이번 공격은 일반적인 웹사이트뿐 아니라 기업과 기관의 네트워크를 보호하는 방화벽 장비를 대상으로 이루어졌다는 점에서 주목할 필요가 있습니다.
보안업체 드림 리서치(Dream Research)의 분석에 따르면 공격자는 약 1만 9,000대의 방화벽을 탐색한 뒤 한국, 미국, 일본, 대만에 있는 장비 240대를 공격 대상으로 선정했습니다.
이후 방화벽 관리 서버의 PHP 기능에 존재하는 원격 코드 실행 취약점인 PHP2Shell을 악용했습니다. 공격자는 PHP 취약점과 리눅스 권한 상승 취약점을 연쇄적으로 이용해 방화벽 24대에서 최고 관리자 권한을 확보한 것으로 분석됐습니다.
미국 정부 관련 기관에서는 방화벽 2대와 내부 관리 서버 1대가 침해되면서 전체 침해 규모가 25대로 집계됐습니다. 다만 한국이 공격 대상에 포함됐다는 사실과 국내 시스템에서 실제 침해가 확인됐다는 사실은 구분해야 합니다. 10월 29일 보도 기준으로 국내 피해 여부는 확인되지 않았습니다.
PHP2Shell 취약점은 어떤 문제인가요?
PHP2Shell은 PHP가 실행되는 특정 환경에서 공격자가 원격으로 명령을 실행할 수 있도록 악용되는 취약점을 가리킵니다. 원격 코드 실행은 RCE(Remote Code Execution)라고 부릅니다.
정상적인 웹서비스에서는 서버가 개발자가 작성한 코드와 허용된 작업만 수행해야 합니다. 하지만 원격 코드 실행 취약점이 존재하면 공격자가 의도하지 않은 명령을 서버에서 실행하도록 유도할 수 있습니다.
예를 들어 웹서비스가 파일을 조회하거나 사용자 요청을 처리하는 과정에서 외부 입력을 안전하게 처리하지 못한다면 문제가 발생할 수 있습니다.
다만 이번 사건의 PHP2Shell을 일반적인 파일 업로드 취약점이나 SQL 인젝션과 동일한 문제로 이해해서는 안 됩니다. 공격에 사용된 구체적인 취약점과 영향을 받는 제품 및 환경을 구분해야 합니다.
PHP로 개발했다는 이유만으로 모든 라라벨, WordPress, 자체 제작 웹서비스가 이번 공격에 동일하게 노출되는 것은 아닙니다. 중요한 것은 실제 사용 중인 제품과 PHP 실행 환경이 해당 취약점의 영향을 받는지 확인하는 것입니다.
공격자는 왜 방화벽을 먼저 노렸을까요?
방화벽은 외부 네트워크와 내부 네트워크 사이에서 접근을 제어하는 보안 장비입니다. 기업에서는 방화벽을 통해 외부에서 접근할 수 있는 서비스와 내부 시스템을 구분합니다.
일반적으로 외부 사용자가 내부 데이터베이스나 관리 서버에 직접 접근하지 못하도록 제한하는 역할을 합니다. 하지만 방화벽 자체의 관리 기능에 취약점이 있다면 상황이 달라집니다.
공격자가 방화벽의 관리자 권한을 확보하면 장비 설정을 확인하거나 변경할 수 있는 위험이 발생합니다. 또한 방화벽과 연결된 내부 관리 시스템으로 공격 범위를 확대할 가능성도 있습니다.
이번 사건에서는 방화벽을 통해 미국 정부 관련 기관의 내부 관리 서버까지 침투한 정황이 확인됐습니다. 이는 보안 장비도 하나의 소프트웨어 시스템이며, 관리 인터페이스와 운영체제에 대한 보안점검이 필요하다는 사실을 보여줍니다.
공격 과정은 어떻게 진행됐을까요?
공개된 보안업체 분석과 보도를 바탕으로 공격 흐름을 정리하면 다음과 같습니다.
인터넷에 노출된 방화벽 탐색
|
V
공격 대상 장비 240대 선정
|
V
PHP2Shell 취약점 악용
|
V
방화벽 관리 서버 침투
|
V
리눅스 권한 상승 취약점 연계
|
V
방화벽 24대의 root 권한 확보 정황
|
V
일부 환경에서 내부 관리 서버 침투
|
V
전체 서버 25대 침해 정황여기서 중요한 것은 두 종류의 취약점이 연결됐다는 점입니다. 첫 번째는 PHP 기능을 통해 서버에 침투하는 과정입니다. 두 번째는 리눅스 운영체제의 권한 상승 취약점을 이용하는 과정입니다.
공격자가 웹 애플리케이션을 통해 서버에 접근했다고 해서 처음부터 최고 관리자 권한을 가진 것은 아닐 수 있습니다. 하지만 이후 운영체제의 다른 취약점을 악용하면 권한을 확대할 수 있습니다. 이처럼 여러 취약점을 연결하는 공격을 취약점 연쇄 악용이라고 설명할 수 있습니다.
root 권한을 탈취하면 어떤 위험이 발생하나요?
리눅스에서 root는 시스템 전체를 관리할 수 있는 최고 관리자 계정입니다. 일반 사용자 계정과 비교하면 시스템 설정, 파일 접근, 서비스 관리 등에 매우 높은 권한을 가집니다.
공격자가 root 권한을 확보하면 시스템의 중요한 설정이나 파일에 접근할 수 있는 위험이 발생합니다. 특히 방화벽 장비라면 네트워크 접근 정책과 관리 기능이 영향을 받을 수 있습니다.
다만 root 권한 탈취가 확인됐다는 사실만으로 모든 데이터가 외부로 유출됐다고 단정해서는 안 됩니다. 이번 사건에서도 추가 시스템 침해 여부와 민감정보 유출 규모는 확인되지 않았습니다. 보안 사고를 분석할 때는 다음 사항을 구분해야 합니다.
- 취약점이 존재한다는 사실
-
공격 시도가 관측됐다는 사실
-
실제 침해가 발생했다는 사실
-
관리자 권한이 탈취됐다는 사실
-
데이터 유출이 확인됐다는 사실
각 단계는 서로 다른 의미를 갖습니다.
웹셸이 설치됐다는 것은 무슨 뜻인가요?
이번 사건에서는 공격자가 일부 침해 장비에 웹셸(Web Shell)을 설치한 정황도 보고됐습니다. 웹셸은 웹 요청을 통해 서버에서 명령을 실행하거나 시스템을 제어하는 데 악용될 수 있는 프로그램입니다.
공격자는 취약점을 이용해 처음 서버에 침투한 뒤 웹셸을 남겨 이후에도 접근하려고 시도할 수 있습니다. 보도에 따르면 공격자는 최고 관리자 권한을 확보한 방화벽 24대 중 미국 정부 관련 기관의 방화벽 2대를 제외한 22대에 웹셸을 설치한 것으로 분석됐습니다.
이는 공격자가 즉시 추가 행동을 하지 않았더라도 나중에 다시 접근할 가능성이 있다는 의미입니다. 따라서 취약점을 패치하는 것만으로 침해 대응이 끝나는 것은 아닙니다. 이미 침해된 시스템에서는 악성 파일, 비정상 계정, 인증정보 변경 여부, 시스템 설정 변경 여부 등을 확인해야 합니다.
라라벨 서버도 이번 PHP2Shell 공격 대상인가요?
이번 공격이 보도됐다고 해서 모든 라라벨 서버가 동일한 취약점을 가진다고 판단할 수는 없습니다. 라라벨은 PHP 기반 웹 프레임워크이며, 실제 보안 상태는 PHP 버전과 실행 환경, 설치된 패키지, 서버 설정 등에 따라 달라집니다.
또한 이번 공격은 방화벽 관리 서버에 탑재된 PHP 기능을 대상으로 했습니다. 따라서 일반적인 라라벨 웹서비스를 운영하는 경우에는 먼저 해당 취약점의 공식 영향 범위를 확인해야 합니다.
영향을 받는 제품과 버전이 확인되지 않은 상태에서 모든 PHP 서버가 침해될 수 있다고 표현하는 것은 부정확합니다. 다만 이번 사건과 별개로 PHP 기반 웹서비스에서도 외부 입력 검증, 접근권한, 보안 패치, 서버 설정을 점검하는 것이 중요합니다.
PHP 서버 운영자가 확인할 보안 항목
실제 웹 요청을 처리하는 PHP 버전 확인 터미널에서 다음 명령어를 실행하면 CLI PHP 버전을 확인할 수 있습니다.
php -v하지만 실제 웹서비스에서 사용하는 PHP-FPM 버전과 다를 수 있으므로 연결된 서비스도 확인해야 합니다.
systemctl list-units --type=service --all | grep phpNginx를 사용하는 경우에는 PHP-FPM 연결 설정을 확인할 수 있습니다.
sudo nginx -T | grep fastcgi_pass여러 PHP 버전이 설치된 서버에서는 서비스별로 연결된 PHP-FPM 버전을 구분해야 합니다.
운영체제와 PHP 보안 패치 확인
이번 공격에서는 PHP 취약점과 리눅스 권한 상승 취약점이 함께 악용됐습니다. 따라서 PHP만 업데이트하고 운영체제 보안 패치를 방치해서는 안 됩니다. Ubuntu 서버라면 설치된 패키지의 보안 업데이트 상태를 확인할 수 있습니다.
sudo apt update
apt list --upgradable이 명령어는 업데이트 가능한 패키지를 확인하는 용도입니다. 실제 업데이트를 적용하기 전에는 운영 서비스와의 호환성 및 재시작 필요 여부를 검토해야 합니다.
외부에 노출된 관리 기능 확인
관리자 페이지와 서버 관리 인터페이스는 일반 사용자용 서비스와 구분해야 합니다. 외부에서 접근할 필요가 없는 관리 기능이라면 VPN이나 접근제어 정책을 활용해 노출 범위를 줄이는 것이 좋습니다. 특히 관리자 계정에는 다중요소인증을 적용하고 사용하지 않는 계정을 정리해야 합니다.
Composer 패키지 보안점검
라라벨 프로젝트에서는 Composer 패키지의 알려진 보안 권고를 확인할 수 있습니다.
composer audit다만 이 명령어는 이번 PHP2Shell 공격의 침해 여부를 직접 확인하는 도구가 아닙니다. 의존성 점검과 침해사고 조사는 서로 다른 작업입니다.
PHP 업로드 진행률 설정과 이번 공격은 같은 문제인가요?
PHP에는 session.upload_progress.enabled라는 설정이 있습니다. 이 설정은 파일 업로드 진행 상태를 세션에 기록하는 기능과 관련이 있습니다. 서비스에서 해당 기능을 사용하지 않는다면 비활성화를 검토할 수 있습니다.
session.upload_progress.enabled = Off하지만 이 설정을 비활성화한다고 해서 이번 PHP2Shell 공격을 차단할 수 있다고 단정해서는 안 됩니다. 이번 공격과 업로드 진행률 관련 보안 문제는 각각의 취약점 원인과 영향 범위를 확인해야 합니다. 보안 설정은 특정 취약점에 대한 공식 대응책과 일반적인 서버 보안 강화 조치를 구분해서 적용하는 것이 중요합니다.
침해가 의심되는 서버에서는 무엇을 해야 할까요?
침해가 의심된다면 단순히 서버를 재시작하거나 PHP를 업데이트하는 것으로 대응을 끝내서는 안 됩니다. 먼저 시스템의 현재 상태와 관련 로그를 보존할 필요가 있습니다.
웹서버 접근 로그, 인증 로그, 관리자 계정 변경 이력, 비정상 프로세스, 외부 연결 등을 확인해야 합니다. 다만 로그에 공격 문자열이 발견됐다는 이유만으로 실제 침해가 발생했다고 단정할 수는 없습니다.
자동화된 공격 시도와 실제 명령 실행은 구분해야 합니다. 반대로 명확한 오류 로그가 없다는 이유만으로 침해가 없었다고 확정할 수도 없습니다.
침해가 확인되거나 의심 수준이 높다면 관련 시스템을 격리하고 보안 담당자와 사고 대응 절차를 진행해야 합니다. 필요한 경우 신뢰할 수 있는 백업을 사용한 복구와 인증정보 교체도 검토해야 합니다.
PHP2Shell 공격이 보여주는 보안 관리의 중요성
이번 사건에서 중요한 부분은 서버 25대라는 숫자만이 아닙니다. 외부에 노출된 방화벽 관리 기능의 취약점이 내부 시스템 침투로 이어질 수 있었다는 점입니다.
또한 PHP 취약점과 운영체제 권한 상승 취약점이 연결되면서 공격 범위가 확대됐습니다. 이는 보안 장비라고 해서 공격 대상에서 제외되는 것이 아니라는 사실을 보여줍니다.
PHP와 라라벨 기반 웹서비스를 운영하는 개발자 역시 실제 영향 범위를 확인하고 보안 패치와 접근통제를 지속적으로 관리해야 합니다.
특히 ERP와 MES처럼 기업의 중요한 데이터를 처리하는 시스템은 서버 보안뿐 아니라 사용자 권한과 데이터 접근 정책도 함께 점검해야 합니다.
보안 사고를 예방하려면 특정 언어에 대한 막연한 불안보다 취약점의 실제 영향 범위와 운영 환경을 정확하게 확인하는 것이 중요합니다.
'개발 > PHP' 카테고리의 다른 글
| PHP SQL 인젝션 방어 : PDO·라라벨 Eloquent와 자바 PreparedStatement 비교 (1) | 2026.10.31 |
|---|---|
| 백엔드 유효성 검증 : 라라벨 validate 사용법과 SQL 인젝션 방어 원칙 (0) | 2026.10.29 |
| PHP 웹서버 보안점검 : 외부 노출 서버와 라라벨 운영 환경 확인 방법 (4) | 2026.10.28 |
| PHP2Shell 취약점 대응 : PHP 5·7·8 구버전도 반드시 업데이트해야 할까 (0) | 2026.10.24 |
| PHP8 새롭게 추가된 어노테이션과 다양한 문법 정리 (14) | 2025.05.21 |
