[전자신문] PHP2Shell 대응, 경고보다 실질적 방어체계가 먼저다

By PLURA 2026-10-28

취약점이 공개되면
기업에는 긴급 보안 공지가 전달된다.

사용 중인 버전을 확인하고,
영향받는 시스템을 찾아,
보안 업데이트를 적용하라는 안내다.

필요한 조치다.

그런데 서비스를 운영하는 기업에는
그와 동시에 해결해야 할 문제가 있다.

패치가 완료될 때까지, 지금 들어오는 공격은 누가 막고 있는가.

PHP2Shell은 이 질문을 다시 꺼내게 한다.

PHP 개발팀은 2026년 10월 21일, 웹 요청을 처리하는 PHP에서
인증 없이 원격 코드 실행으로 이어질 수 있는 취약점의 보안 업데이트를 발표했다.
이 문제는 개별 홈페이지의 코드뿐 아니라 PHP 실행 환경 자체를 확인해야 하는 사안이다.¹

기업이 해야 할 일은 분명하다.

당장 적용할 수 있는 보호 조치를 가동하고,
실제 방어 효과를 확인하며,
취약한 실행 환경을 신속하게 업데이트해야 한다.

경고가 현장의 방어로 이어지도록 만드는 것.
이번 취약점 대응에서 우리가 집중해야 할 과제다.

패치가 끝날 때까지의 보안 공백을 줄여야 한다

취약점 대응에는 함께 진행해야 할 두 가지 일이 있다.

하나는
취약한 소프트웨어를 수정하는 일이다.

다른 하나는
수정이 완료될 때까지 공격자가 이용할 수 있는 경로를 줄이는 일이다.

웹방화벽을 이용한 가상 패치(Virtual Patching)는
두 번째 역할을 수행하는 방법이다.

서비스 앞단에서 알려진 공격 시도를 식별하고 차단해
취약한 코드에 도달할 가능성을 낮춘다.
애플리케이션을 즉시 수정하기 어려운 상황에서도 적용할 수 있다.

OWASP는 가상 패치와 코드 수정을 병행할 수 있다고 설명한다.
동시에 보호 범위는 검사하는 트래픽과 규칙이 식별하는 공격에 한정되므로,
우회 가능성을 검증하고 근본적인 수정을 계속해야 한다고 명시한다.²

따라서 기업의 대응 계획에는
패치 일정과 함께 현재의 보호 상태가 담겨야 한다.

어떤 공격 경로를 통제했는가.
어떤 범위에서 차단을 확인했는가.
추가 확인이 필요한 시스템은 어디인가.

이 질문에 답하면서 패치를 진행해야 한다.

방어 조치와 패치를 병행해, 취약점에 노출된 시간을 줄여야 한다.

중소기업의 패치는 운영 문제이기도 하다

가령 오래된 홈페이지 하나를 운영한다고 해 보자.

PHP 버전은 오래되었고,
게시판과 예약 기능은 서로 다른 시기에 개발되었으며,
유지보수 업체는 외부 결제 모듈의 호환성도 확인해야 한다.

이 환경에서 업데이트에는 여러 작업이 따른다.

실제 실행 환경을 찾고,
관련 모듈의 호환성을 확인하고,
로그인·예약·결제·파일 업로드를 시험하고,
배포 이후의 정상 동작까지 검증해야 한다.

전담 인력이 적을수록 이 작업을 짧은 시간 안에 수행하기 어렵다.

NIST도 패치 관리를 식별, 우선순위 결정, 확보, 설치, 적용 검증이 이어지는 과정으로 설명한다.
조직의 업무와 기술 운영을 함께 고려해 지속적으로 수행해야 하는 예방 정비라는 관점이다.³

이러한 현실은 패치 기간 동안의 보호 대책을 더 구체적으로 준비해야 하는 이유다.

보안 담당자는 노출된 경로와 보호 정책을 확인하고,
개발·유지보수 담당자는 업데이트와 호환성 검증을 진행하며,
운영 책임자는 일정과 서비스 영향을 조정해야 한다.

중소기업에 필요한 지원도 이 과정을 실제로 수행할 수 있게 하는 데 집중해야 한다.

Log4Shell과 Spring4Shell에서 확인한 대응 방식

2021년 Log4Shell과 2022년 Spring4Shell 대응에서도
웹방화벽 보호 정책과 소프트웨어 업데이트가 함께 제시됐다.

Cloudflare는 각각의 취약점에 대응하는 WAF 규칙을 안내했고,
특히 Spring4Shell 대응에서는 보호 규칙을 활성화하면서
관련 소프트웨어를 패치하도록 권고했다.⁴⁵

취약점의 원인과 공격 조건은 서로 다르다.

그러나 운영자가 준비해야 할 일에는 공통점이 있다.

영향받는 자산 확인, 공격 경로 통제, 업데이트, 침해 흔적 확인.

이 네 가지가 연결되어야 한다.

이번에 적용한 정책과 확인한 결과를 기록해 두면
다음 취약점이 공개되었을 때도 어떤 시스템부터 보호하고
누가 무엇을 확인해야 하는지 빠르게 판단할 수 있다.

취약점 대응 경험은
조직의 상시 운영 능력으로 남아야 한다.

Cloudflare 사례가 보여주는 요청·응답 연계 분석

Cloudflare는 PHP2Shell 대응을 위해 WAF 보호 정책을 배포했고,
같은 HTTP 거래의 요청과 응답을 함께 살펴보는 탐지 방식을 적용했다고 발표했다.
WAF 보호를 사용하는 고객에게도 PHP 업데이트를 권고했다.⁶

이 사례에서 주목할 점은
요청의 특징과 서버가 돌려준 결과를 함께 판단한다는 것이다.

의심스러운 입력이 들어왔더라도
서버가 이를 거부했는지,
내부 정보가 포함된 결과를 반환했는지에 따라
조사해야 할 내용이 달라진다.

Cloudflare는 해당 탐지와 응답 규칙을 통해
조건에 맞는 응답이 요청자에게 전달되기 전에 차단할 수 있다고 설명한다.⁷

이 기능은 모든 WAF에 동일하게 적용되는 기능으로 이해해서는 안 된다.
사용하는 제품의 지원 범위와 활성화된 정책을 확인해야 한다.

또한 응답 차단 시점에는
서버가 이미 요청을 처리했을 수 있다.

서버에서 실행된 명령이나 변경된 파일이 있다면
별도 조사와 대응이 필요하다.
Cloudflare도 응답 차단이 원본 서버에서 이미 수행된 동작을 되돌리지 못한다고 설명한다.⁷

웹 응답은 공격 결과를 판단하는 단서이며, 서버 내부의 흔적과 함께 확인해야 한다.

웹방화벽의 보호 범위를 실제로 확인해야 한다

보호 정책이 발표되면
우리 서비스에 적용됐는지 확인하는 작업이 이어져야 한다.

다음 표는 운영자가 보호 상태를 확인하기 위해 사용할 수 있는 점검 기준이다.
가상 패치의 적용 범위와 우회 가능성을 검증한다는 원칙을
서비스 운영 관점에서 구체화한 것이다.²

No.	확인할 항목	확인할 내용
1	보호 대상	홈페이지, API, 서브도메인 등 외부에 노출된 서비스가 보호 목록에 포함되어 있는가
2	실제 통신 경로	대상 요청이 WAF를 거쳐 원본 서버에 도달하는지 확인했는가
3	우회 접근	원본 서버 IP, 다른 포트·주소 등 WAF를 거치지 않는 접근 경로를 통제했는가
4	정책 적용	해당 취약점 대응 정책이 필요한 도메인·경로에 적용되어 있는가
5	차단 동작	탐지·기록 모드와 차단 모드를 구분하고, 설정한 조치가 실제 실행되는지 확인했는가
6	검사 범위	요청 본문, 파일 업로드, 크기 제한과 예외 설정에 따른 검사 공백을 확인했는가
7	검증 결과	승인된 시험으로 차단 결과와 정상 서비스 영향을 확인하고 근거를 남겼는가

시험 결과에는
확인한 대상과 정책, 시험 시각, 처리 결과를 함께 기록해야 한다.

일부 경로를 시험했다면
그 결과가 어느 서비스까지 적용되는지도 명확히 해야 한다.

이렇게 해야 운영 책임자가
현재 보호 범위와 남아 있는 위험을 이해할 수 있다.

요청과 응답의 헤더·본문을 판단 근거로 확보해야 한다

IP, URL, 상태 코드는 기본적인 접근 흐름을 보여준다.

공격의 내용과 결과를 판단하려면
그 요청에 무엇이 담겼고 서버가 무엇을 반환했는지도 확인할 수 있어야 한다.

운영자가 확보해야 할 가시성은 다음과 같이 정리할 수 있다.

No.	분석 대상	확인하려는 내용
1	요청 헤더	요청 형식, 인증 관련 맥락, 비정상적인 헤더 구성
2	요청 본문	입력값, JSON·폼 데이터, 업로드 내용과 구조에 나타난 공격 단서
3	응답 헤더	서버의 처리 결과, 콘텐츠 유형, 세션·캐시 관련 변화
4	응답 본문	예상하지 못한 내부 정보, 민감정보 노출, 오류·실행 결과의 단서
5	거래 연결 정보	해당 요청과 응답을 연결할 시각, 대상 시스템, 요청 식별자

OWASP의 로깅 가이드도 HTTP 요청 본문과 응답 헤더·본문을
상세 이벤트 정보로 다루며, 같은 사용자 상호작용의 이벤트를
연결할 식별자를 기록하도록 설명한다.⁸

예를 들어 HTTP 200은 요청 처리 결과를 나타내는 정보다.
그 응답의 내용이 정당했는지까지 설명해 주지는 않는다.

오류 응답도 마찬가지다.
오류가 발생했다는 사실과 내부 정보가 노출됐는지는 따로 확인해야 한다.

따라서 보안 분석에는
요청 본문 전체를 확인할 수 있는 범위와 응답 내용의 분석 범위를 명확히 설정해야 한다.
본문 일부가 잘렸거나 검사하지 못한 구간이 있다면 그 사실도 판단에 반영해야 한다.

보관 정책은 분석 목적에 맞게 정해야 한다.
비밀번호·접근 토큰 등은 제거하거나 마스킹하고,
조사에 필요한 자료에는 접근 권한과 보존 기간을 적용해야 한다.⁸

그리고 응답을 전달한 뒤 분석하는 방식에서는
이미 전송된 정보를 되돌릴 수 없다.
위험한 응답의 전송 자체를 막으려면 전송 전에 검사하고 차단할 수 있는 구성이 필요하다.

서버 감사 로그를 연결해야 침해 범위가 보인다

웹 요청과 응답은 서버 안에서 일어난 일을 확인하는 출발점이다.

서버의 프로세스 실행, 명령줄, 파일 변경, 계정 사용, 외부 연결을
함께 살펴볼 수 있도록 감사 정책과 로그 수집을 준비해야 한다.

다음은 조사 방법을 설명하기 위한 가상의 예시다.

특정 웹 요청에서 비정상적인 업로드 구조가 확인됐다.
같은 시각, 해당 서버에서 평소와 다른 자식 프로세스가 실행됐다.
관련 경로에 새로운 파일이 생성됐다.
이어서 해당 프로세스의 외부 연결이 관찰됐다.

이때 조사자는 요청 시각과 서버, 프로세스 관계, 파일, 통신을 연결해
하나의 사건으로 설명할 근거를 찾아야 한다.

시간이 비슷하다는 이유만으로 인과관계를 확정해서도 안 된다.
요청 식별자, 실행 계정, 부모 프로세스, 파일 경로 등
연관성을 뒷받침하는 정보가 필요하다.

다만 PHP2Shell의 일부 공격은 악성 명령 실행 없이 메모리 정보를 노출할 수 있다.
새로운 프로세스나 파일이 발견되지 않았다는 사실만으로
정보 유출 가능성을 배제해서는 안 된다.⁹

서버 로그의 수집 범위도 함께 확인해야 한다.
기록하지 않은 행위는 사고 이후에 충분히 재구성하기 어려울 수 있다.⁸

이러한 분석을 통해
차단된 시도와 추가 조사가 필요한 사건을 구분하고,
침해가 확인되면 영향받은 시스템과 조치 범위를 정해야 한다.

웹에서 들어온 요청과 서버에서 일어난 일을 연결할 때, 대응에 필요한 근거가 구체화된다.

서비스 유지와 제한·격리는 위험에 따라 결정한다

서비스 운영 여부는
노출된 공격 경로, 보호 효과, 침해 징후, 업무 영향을 함께 살펴 결정해야 한다.

다음은 이 글에서 제안하는 운영 판단 기준이다.

No.	확인된 상태	대응 방향
1	적용 가능한 보호 조치를 검증했고, 남은 위험을 관리할 수 있음	보호 정책과 모니터링을 유지하면서 패치·검증을 신속히 진행
2	일부 기능이나 경로의 보호 여부가 불확실함	해당 기능·접근 대상을 제한하고 추가 검증과 패치를 우선 수행
3	방어 조치 후에도 중대한 위험을 통제하기 어려움	필요한 범위의 서비스·시스템을 일시 제한하거나 격리
4	실제 침해 또는 피해 확산의 징후가 확인됨	영향받은 시스템 격리, 증적 보존, 침해 조사와 복구 수행

범위를 정할 때는
취약한 실행 환경에 도달하는 경로가 실제로 차단되는지 확인해야 한다.

PHP 공식 공지에는 일부 실행 방식에서
애플리케이션 코드가 실행되기 전에 공격이 발생할 수 있다고 설명되어 있다.
따라서 PHP로 표시하는 ‘점검 중’ 페이지나 애플리케이션 로그인 화면만으로
공격 경로가 통제됐다고 판단해서는 안 된다.¹

운영 책임자는 선택한 조치와 근거를 남기고,
새로운 침해 징후나 보호 정책의 변경이 확인되면 판단을 갱신해야 한다.

패치 완료는 실제 실행 환경에서 확인해야 한다

업데이트 파일을 설치한 다음에는
웹 요청을 처리하는 실행 환경에 수정이 반영됐는지 확인해야 한다.

관리자가 명령줄에서 확인한 PHP와
웹서버가 사용하는 PHP가 다른 경우를 생각해 볼 수 있다.

이때는 웹 요청을 처리하는 서비스, 작업 프로세스, 컨테이너 등을 기준으로
적용 여부를 확인해야 한다.

배포판이 보안 수정을 기존 패키지에 반영하는 경우도 있으므로
숫자로 표시된 버전만 비교하지 말고 공급사의 보안 수정 내역을 확인해야 한다.¹

점검할 사항은 다음과 같다.

웹서비스가 실제로 사용하는 PHP와 관련 패키지에 수정이 반영됐는가.
공급사가 안내한 재시작 또는 재배포 절차를 수행했는가.
로그인, 예약, 결제, 업로드 등 주요 기능이 정상 동작하는가.
공개 이후 추가된 보안 공지와 설정별 조치 사항을 확인했는가.
업데이트 전후의 침해 의심 흔적을 확인했는가.

취약점 수정은 이미 발생한 침해 흔적을 제거하는 작업과 구분된다.
패치 완료와 침해 조사 결과는 각각 확인해야 한다.

다음 공격에도 작동하는 상시 방어체계가 필요하다

PHP2Shell에 대한 조치를 완료한 뒤에도
웹서비스의 보안 운영은 계속되어야 한다.

애플리케이션의 입력 처리, 파일 업로드, 인증과 권한 검증에는
각각 확인해야 할 위험이 있다.

SQL 인젝션, 악성 파일 업로드, 웹셸 접근, 크리덴셜 스터핑,
브루트포스 등을 살펴보는 정책도 서비스 특성에 맞게 운영해야 한다.

가령 계정 공격을 판단하려면
요청 한 건의 문자열과 함께 로그인 성공·실패의 반복,
여러 계정에 대한 접근, 로그인 이후의 행위를 볼 필요가 있다.¹⁰

평소의 방어체계는 다음 작업을 지속적으로 수행할 수 있어야 한다.

새로운 보호 정책을 적용하고,
서비스 변경에 따라 검사 범위와 예외를 조정하고,
웹·서버의 기록을 연결하며,
위험이 확인되면 대응하고,
그 결과를 다시 정책에 반영하는 것이다.

이 과정이 운영에 자리 잡으면
새로운 취약점이 공개됐을 때도 기존 체계 위에서 보호를 강화할 수 있다.

중소기업 지원은 실제 방어 능력으로 평가해야 한다

과학기술정보통신부와 KISA는 2026년 중소기업 대상 지원사업에서
정보보호 컨설팅, IT 보안 패키지, 클라우드 기반 보안서비스인
SECaaS 패키지 이용 지원을 안내하고 있다.¹¹

이러한 지원은
기업이 자체적으로 확보하기 어려운 보안 역량을 보완하는 기반이 된다.

지원의 성과를 더 분명히 하려면
서비스를 도입한 이후에 무엇이 달라졌는지를 확인해야 한다.

아래 항목은 상시 방어 능력을 평가하기 위한 제안이다.

No.	평가 항목	확인할 결과
1	보호 범위	지원 대상 서비스 중 실제 보호 경로와 정책 적용을 확인한 범위
2	차단 효과	승인된 시험에서 확인한 차단 결과와 정상 서비스 영향
3	가시성	요청·응답 및 서버 행위에 필요한 로그의 확보 여부와 수집 공백
4	대응 속도	위험 확인부터 담당자 통보·조치까지 걸린 시간
5	패치 이행	영향 자산의 수정 적용과 실행 환경 검증 완료 여부
6	운영 지속성	정책 갱신, 예외 검토, 로그 수집 상태 점검을 맡은 담당자와 절차

차단 건수가 많다는 사실만으로
방어 품질을 판단하기는 어렵다.

실제 공격 노출이 늘어서 건수가 많아졌을 수도 있고,
정상 요청이 잘못 차단되는 경우도 확인해야 하기 때문이다.

정부와 지원기관은
기업이 어떤 공격을 어떤 근거로 탐지·차단할 수 있게 되었는지,
문제가 발생했을 때 누가 대응하는지까지 살펴야 한다.

중소기업 지원의 성과는 현장에서 지속되는 보호와 대응 능력으로 확인해야 한다.

보안정책의 기준을 실제 대응 능력까지 넓혀야 한다

ISMS-P에는 관리적 요구사항과 함께
시스템·서비스 보안관리, 사고 예방 및 대응 등 기술적 영역도 포함되어 있다.¹²

이 요구사항이 운영 현장에서 어느 수준으로 작동하는지
실제 공격 상황을 가정해 확인해야 한다.

예를 들어 취약점 대응 절차가 있다면
최근 공개된 취약점을 기준으로 대상 자산을 찾아보아야 한다.

웹방화벽을 운영한다면
정책 적용 범위와 차단 결과를 확인해야 한다.

사고 대응 절차가 있다면
위험한 요청과 서버 행위를 연결하고,
담당자 통보와 격리 판단에 필요한 근거를 제시해 보아야 한다.

이 검증을 통해
문서에 정한 역할과 실제 수행 능력의 차이를 발견할 수 있다.

개인정보 보호와 기업의 관리 책임을 유지하면서도
정책의 실효성을 판단하는 기준에 탐지·분석·차단·대응 결과를 반영해야 한다.

정부는 인증 항목과 제출 증적을 늘리는 데 그치지 않고,
실제 환경에서 탐지·분석·차단·대응 능력을 검증하는 기준을 제시해야 한다.

PLURA-XDR이 연결하는 방어의 흐름

PLURA-XDR이 접근하는 방향도
웹 공격과 서버·PC의 행위를 하나의 사건 흐름으로 연결하는 것이다.

PLURA-XDR의 통합 기능은
웹 보호, 호스트 행위 분석, 로그 상관분석, 대응, 포렌식으로 이어진다.¹³

No.	기능	침해대응에서 확인할 내용
1	PLURA-WAF	웹 요청·응답의 공격·노출 징후와 정책에 따른 대응
2	PLURA-EDR	서버·PC의 실행, 접근, 변경 등 호스트 행위
3	PLURA-SIEM	시각·자산·계정 등 맥락을 기준으로 연결한 관련 로그
4	PLURA-SOAR	허용된 정책과 권한에 따른 조치 및 실행 이력
5	PLURA-Forensic	침해 조사와 영향 범위 확인에 필요한 호스트 증적

AI 분석도 이 데이터 위에서 이루어져야 한다.

어떤 웹 요청과 서버 행위가 관련되어 있는지,
어떤 근거가 위험 판단을 뒷받침하는지,
어떤 부분을 추가로 조사해야 하는지 정리해야 한다.

PLURA-XDR은 이러한 근거 기반 분석을 운영자의 판단과
정책에 따른 대응으로 연결하는 방향을 제시하고 있다.¹⁴

실제 적용 시에는 고객 환경의 수집 범위와 대응 권한을 정하고,
분석 결과와 조치가 실행된 이력을 함께 확인해야 한다.

가시성은 AI의 눈이다.
분석에 필요한 기록을 확보하고 서로 연결할수록
AI의 판단을 검토하고 대응에 활용할 근거도 분명해진다.

지금 확인해야 할 7가지

PHP2Shell 대응을 진행 중인 조직이라면
다음 질문에 현재의 상태와 근거로 답할 수 있어야 한다.

No.	점검 질문
1	실제 웹 요청을 처리하는 PHP와 외부 노출 서비스를 모두 확인했는가
2	보호 대상의 요청이 WAF를 통과하고, 원본 서버로의 우회 접근이 통제되는가
3	필요한 정책이 적용되어 있으며 실제 차단 결과를 확인했는가
4	요청·응답과 서버 감사 로그를 연결해 공격 결과와 침해 흔적을 조사할 수 있는가
5	패치 담당자, 적용 일정, 실행 환경 검증 방법이 정해져 있는가
6	위험이 확인되면 제한·격리·증적 보존을 수행할 담당자와 절차가 있는가
7	이번 대응 이후에도 정책 갱신과 로그 점검, 후속 조치를 계속 수행할 수 있는가

답하기 어려운 항목이 있다면
그 항목이 지금 보완해야 할 운영 과제다.

맺음말

취약점 공지는 대응의 시작이다.

그다음에는
서비스를 보호하고,
취약한 환경을 수정하고,
침해 여부를 확인하는 실행이 이어져야 한다.

기업은 WAF 보호 정책과 패치를 병행하고,
웹 요청·응답에서 서버 내부 행위까지 확인할 수 있어야 한다.

정부는 보안 인력과 예산이 부족한 기업이
이 과정을 지속적으로 운영하도록 지원해야 한다.

다음 취약점이 등장했을 때
우리에게 필요한 답변은 구체적이어야 한다.

어떤 경로를 보호했고, 어떤 차단 결과를 확인했으며,
패치는 어디까지 진행됐는지 설명할 수 있어야 한다.

공격을 통제하고, 신속히 패치하며, 그 결과를 확인할 수 있는 상시 방어체계를 갖추자.

📰 함께 읽기

📚 함께 읽기

📰 원문 뉴스

이 글은 전자신문 기고를 바탕으로
웹방화벽 운영, 패치 검증, 요청·응답 및 서버 로그 분석,
중소기업 지원정책에 필요한 설명을 보완한 PLURA-Blog 확장 글입니다.

필자: 신승민 큐비트시큐리티 대표
전자신문: 2026년 10월 23일 온라인판
블로그 확장본 작성: 2026년 10월 28일
원문 기고 보기

🔎 근거 자료

아래 자료는 2026년 10월 28일 확인 기준입니다.
세부 패치와 설정은 사용하는 PHP·배포판·WAF 공급사의 후속 보안 공지를 함께 확인해야 합니다.

PHP 공식, 2026년 보안 공지 모음. 10월 21일 원격 코드 실행 취약점 안내와 10월 23일 추가 설정 관련 안내 등을 참고. ↩︎ ↩︎ ↩︎
OWASP, Virtual Patching Cheat Sheet. ↩︎ ↩︎
NIST, SP 800-40 Rev. 4: Guide to Enterprise Patch Management Planning. ↩︎
Cloudflare, Inside the Log4j2 vulnerability. ↩︎
Cloudflare, WAF mitigations for Spring4Shell. ↩︎
Cloudflare, Cloudflare deploys protections against php2shell vulnerability. ↩︎
Cloudflare, Introducing full transaction detection for Cloudflare WAF. ↩︎ ↩︎
OWASP, Logging Cheat Sheet. ↩︎ ↩︎ ↩︎
공동 연구팀, PHP2Shell: PHP 취약점 연구 설명. ↩︎
OWASP, Credential Stuffing Prevention Cheat Sheet. ↩︎
KISA, 2026년 ICT 중소기업 정보보호 지원사업 수요기업 모집 공고. ↩︎
개인정보보호위원회 개인정보 포털, ISMS-P 인증기준. ↩︎
PLURA, 통합 보안 기능. ↩︎
PLURA, AI 분석·대응. ↩︎