PHP2Shell: 오래된 취약점, 세계적 비상사태, 그리고 지금 해야 할 일

콘텐츠 전략 전문가 겸 뉴스 작가

10월 21, 2026

23 분 읽기

PHP에서 메모리 결함이 처음 발견된 것은 2024년입니다. 2년이 흘렀지만 해결되지 않았다. 그러다가 AI 지원 연구를 통해 그걸 제대로 활용했어요. 현재 2,260만 건 이상의 인터넷 노출 사례가 잠재적 위험에 처해 있습니다. 현재 공격자들이 취약한 서버들을 탐색하고 있으며, 유럽 전역의 공공 웹사이트들이 패치 작업이 진행되는 동안 접속이 차단되었습니다.

이러한 혼란은 PHP2Shell로 알려진 PHP의 두 가지 치명적인 결함에서 비롯됩니다. 10월 21일, PHP 개발자들은 심각도 10점 만점에 9.2점으로 평가된 CVE-2026-109618과 CVE-2026-109619 에 대한 패치를 발표했습니다. PHP는 워드프레스, 드루팔, 줌라를 기반으로 구축된 사이트를 포함하여 잘 알려진 서버 측 프로그래밍 언어를사용하는 웹사이트의 약 70%를 구동합니다. 그리고 이러한 결함은 플러그인이나 앱이 아닌 PHP 자체에 있기 때문에 공격자는 로그인하지 않고도 악성 코드를 실행할 수 있습니다. 그렇게 하면 취약한 서버를 장악하거나 서버 메모리에서 민감한 데이터를 직접 빼낼 수 있습니다.

PHP2Shell은 단순한 패치 문제가 아닙니다. AI 지원 연구는 팀이 테스트하고 수정한 것보다 더 빨리 오래된 결함을 실제 취약점으로 바꿀 수 있어요. 또한, 공용 웹 서버가 침해당하면 공격자는 데이터베이스, 내부 애플리케이션 및 클라우드 워크로드에 접근할 수 있는 경로를 확보하게 됩니다. 패치에는 두 번째 계획이 있어야 해요. 경로를 확인하고, 측면 움직임을 제한하고, 보안 침해가 확산되기 전에 차단하는 거죠.

Illumio 산업 솔루션 담당 이사인 크리스터 스와츠 (Christer Swartz) 는 이렇게 말했습니다. “마치 누군가가 우리 집 현관의 모든 문을 여는 범용 열쇠를 찾은 것 같아요.

누수 문제 해결 경쟁은 누수로 시작되었습니다. 10월 20일, 두 개의 CVE 식별자가 온라인에 유포되기 시작했습니다. PHP의 출시일이 하루 앞당겨졌습니다. 그날 저녁, 보안 회사 캘리포니아가 실수로 작동 중인 익스플로잇을 촬영한 동영상을 올렸어요. 해당 이미지들이 소셜 미디어에 퍼졌다. 다음날 아침, 체인가드는 공식 배포보다 6시간 이상 앞서 수정 사항이 포함된 소프트웨어 이미지를 게시했습니다. 공격자들은 대부분의 팀이 패치를 적용하기 전에 수정 사항을 미리 파악할 수 있었습니다.

그 여파는 공공 서비스에 빠르게까지 미쳤다. 유럽 전역의 정부 기관, 대학 및 기타 공공 웹사이트가 복구팀의 긴급 조치로 인해 접속이 차단되었습니다. 보안 기관들이 즉시 업데이트를 촉구했어요. Cloudflare는 패치 출시 전에 고객에 대한 공격 트래픽을 봤어요. 아마존 위협 인텔리전스는 결함이 공개되기 4일 전인 10월 17일에 악용 시도를 발견했다고 해요. 현재 야생에서 광범위한 남획이 보고되고 있습니다. 얼마나 많은 시도가 성공했는지는 아직 불분명합니다.

해결되지 않은 경고

그 시계는 대중이 PHP2Shell에 대해 알기 훨씬 전부터 작동하기 시작했습니다.

2024년에 한 PHP 개발자가 보안 감사와는 다른 문제를 고치다가 메모리 문제의 첫 징후를 발견했어요. 팀은 여러 가지 해결책을 검토했습니다. 각각의 방법은 호환성을 깨뜨리거나, 새로운 서비스 거부 공격 위험을 초래하거나, 타사 확장 프로그램에 변경을 강요할 위험이 있었습니다. 원격으로 코드를 실행할 수 있는 알려진 경로가 없었기 때문에 작업이 중단되었습니다.

그러자 상황이 바뀌었다.

8월에 AI 지원 연구를 통해 결함이 어떤 영향을 미칠 수 있는지 보여줬어요. 8월 11일, Calif와 OpenAI의 연구원들은 각각 동일한 근본 원인을 가진 원격 코드 실행 경로를 보고했습니다. 며칠 후 위즈는 프론티어 AI 모델을 써서 더 많은 공격 경로를 찾아냈어요. 그 팀은 워드프레스, 드루팔, 줌라 사이트에 대한 효과적인 공격을 보여줬어요. 이제 그 버그는 실제 운영 중인 웹 서버에 침투할 수 있는 통로가 되었습니다.

PHP 팀과 연구원들은 패치 작업에 착수했습니다. 그들의 목표는 부지 소유주들에게 준비할 시간을 주는 것이었습니다. 하지만 발표 전에 세부 사항이 유출되면서 계획은 수포로 돌아갔다.

경고에서 위기로 이어지는 과정

2024년: PHP 개발자가 감사 결과를 수정하던 중 메모리 결함을 발견합니다. 해결책이 지연되고 있습니다.
2026년 8월: 캘리포니아, 오픈AI, 위즈는 AI 지원 연구를 통해 원격 코드 실행을 보여줘요.
2026년 8월부터 10월까지: PHP 유지 관리자와 연구원들이 10월 22일 릴리스를 위한 수정 작업을 진행합니다.
10월 17일: 아마존은 허니팟에서 공격 시도를 감지했습니다.
10월 20일: CVE 식별자가 유출되었습니다. PHP 측에서 릴리스 일정을 하루 앞당겼습니다. 캘리프가 실수로 악용 영상을 게시했습니다.
10월 21일: Chainguard에서 수정된 이미지를 조기에 공개했습니다. PHP는 웹사이트 접속 장애와 공격 시도 급증에 대응하여 패치를 배포했습니다.

PHP 재단은 이후 과거 경고 메시지 처리 방식에 미흡한 점이 있었음을 인정했습니다 . 이 사례는 취약점에 대한 증거가 퍼지면 해결책을 숨기기가 얼마나 어려운지도 보여줍니다. 패치는 테스트가 필요합니다. 공격자는 아직 패치가 적용되지 않은 서버 하나만 있으면 됩니다.

모든 PHP 사이트가 동일한 위험에 직면하는 것은 아닙니다. 위험도는 사용 중인 버전, 서버 설정 및 관련 보안 조치에 따라 달라집니다. 하지만 이번 위기는 팀들이 대응할 수 있는 시간에 심각한 제약을 가했습니다.

웹 서버는 네트워크로 들어가는 경로가 될 수 있습니다.

고객 포털을 생각해 보세요. 계정 기록을 위한 데이터베이스, 결제를 위한 API, 그리고 기타 작업을 위한 클라우드 앱에 연결될 수 있습니다. 저 링크들 덕분에 사이트가 작동하는 겁니다. 또한 침입자에게 현관문을 통과하는 경로를 제공할 수도 있습니다.

스와츠는 웹 서버를 장악한 공격자가 앱이 이미 사용하고 있는 경로를 따라갈 수 있다고 경고했습니다.

“그리고 이 위협이 고객 대면... 웹 서버에 도착했는데 발견하지 못하면 계속 열어둔 네트워크 깊숙한 곳과 같은 경로를 따라가기 시작할 거예요.” 라고 그는 말했습니다.

공격자는 서버 메모리에서 API 키 또는 로그인 토큰을 찾을 수 있습니다. 위즈는 이러한 결함들이 바로 그런 종류의 데이터를 유출시킬 수 있다는 것을 보여주었습니다. 공격자는 서버가 어떤 시스템에 접근할 수 있는지 테스트할 수도 있습니다. 액세스 범위가 너무 넓으면 한 번의 침해로 고객 데이터, 내부 앱 및 중요 자산이 위험에 빠질 수 있어요.

패치 상태만으로는 상황이 얼마나 심각해질지 알 수 없습니다. 팀은 서버가 침해된 후 어떤 영역에 접근할 수 있는지도 알아야 합니다.

여기에는 IT와 운영 기술(OT) 간의 모든 연결이 포함되며, 보안이 취약한 경로를 통해 공장 시스템이 노출될 수 있습니다.

AI가 레이스의 속도를 바꿨어요.

AI는 연구자들이 위험을 발견하는 데 도움이 됐어요. 그 덕분에 수비수들은 문제를 해결할 기회를 얻었습니다. 하지만 동일한 도구들이 공격자들이 침입 경로를 찾는 데에도 이용될 수 있습니다.

스와츠는 수동 대응에 의존하는 팀들에게 새로운 문제가 발생할 수 있다고 지적합니다.

“취약점 기간이 의미하는 바는 이제 인간이 대응할 수 있는 시간보다 훨씬 짧다는 거예요.” 라고 그는 말했습니다. 그는 지연으로 인한 비용에 대해 더욱 직설적으로 말했다. "만약 당신이 사람, 즉 키보드를 두드리는 사람에게 의존한다면, 당신은 손해를 보는 겁니다."

문제는 속도입니다. 분석가들은 여전히 위험을 평가하고 공격을 조사해야 해요. 하지만 누군가가 낯선 연결을 발견하고 조치를 취할 때쯤이면 공격자는 이미 다른 곳으로 이동했을 수도 있습니다.

피해를 최소화하는 방법

1. 노출된 서버부터 시작하세요

첫 번째 조치는 영향을 받는 PHP 서버를 찾아서 보안 업데이트를 적용하는 거예요. 공용 서버에 패치를 적용할 수 없는 경우, 접근을 제한하거나 서버를 오프라인으로 전환하는 것이 더 안전한 선택일 수 있습니다.

스와츠는 서버 수뿐만 아니라 노출도를 기준으로 작품의 순위를 매길 것이다. 민감한 데이터베이스나 기타 중요 자산에 연결된 사이트는 세심한 주의를 기울여야 해요.

"패치를 해야 하지만, 해당 서버가 어디까지 도달할 수 있는지도 고려해야 합니다."라고 그는 말했다. “중요 자산에 연결되면 그 한 시스템의 취약점보다 위험이 훨씬 커요.” 로드 밸런싱이 적용된 사이트의 경우, 그는 한 그룹의 서버에 패치를 적용하는 동안 나머지 서버들은 사이트를 계속 운영하도록 권장합니다. 그러면 팀에서 트래픽을 전환하고 나머지는 패치할 수 있어요.

2. 공격자가 다음에 어디로 갈지 예측해 보세요.

스와츠의 다음 관심사는 웹 서버와 API, 데이터베이스, 내부 애플리케이션 및 클라우드 워크로드 간의 연결입니다. 그러한 경로는 사업에 유리한 경우가 많습니다. 측면 이동 경로가 될 수도 있어요.

"웹 서버가 어떤 시스템과 통신하는지 모른다면 공격자가 어디까지 침투할 수 있는지 알 수 없습니다."라고 그는 말했다. “먼저 그러한 연결 관계를 파악하십시오.” 그러면 어떤 것이 필요하고 어떤 것이 중요 자산을 위험에 빠뜨리는지 알 수 있어요.”

3.트래픽 변화 조심하세요

그는 새로운 워크로드 연결, 이상한 목적지, 갑작스러운 볼륨 증가 등 서버의 일반적인 패턴을 깨뜨리는 트래픽을 찾곤 했어요.

그는 DNS를 한 예로 들었다. 평소에 소량의 DNS 요청을 보내던 서버가 갑자기 대량의 데이터를 전송하기 시작한다면, 좀 더 자세히 살펴볼 필요가 있습니다. PHP2Shell 전용 신호가 아니고 위반으로 입증되지도 않아요. PHP2Shell의 경우, Wiz는 비정상적인 업로드 요청 이후 메모리 제한 오류 또는 반복적인 HTTP 500 응답이 발생하는지 주의 깊게 살펴볼 것을 권장합니다 .

“공격자가 어떤 취약점을 사용했는지 모를 수도 있어요.” 라고 그는 말했습니다. 하지만 여전히 이전에는 결코 하지 않았던 방식으로 작업량이 처리되는 것을 볼 수 있습니다. 공격이 확산되기 전에 알아차려야 할 변화예요.”

4. 불필요한 경로를 차단하세요

"제 생각에 가장 좋은 방법은 기본 세그먼트와 관계없이 애플리케이션을 세분화하는 것입니다."라고 스와츠는 말했습니다. 즉, 어떤 네트워크에 있든 각 앱에 대한 제어 기능을 설정하라는 뜻입니다.

그는 에지 방화벽 , VLAN 또는 클라우드 네트워크 경계가 애플리케이션 간의 액세스를 항상 제어하는 것은 아니라고 주장합니다. 워크로드 수준의 세분화로 각 서버가 필요한 서비스로 제한될 수 있어요.

그는 "웹 서버는 하나의 데이터베이스와 통신해야 할 수도 있다"고 말했다. "그렇다고 해서 모든 데이터베이스에 접근할 수 있어야 한다는 의미는 아닙니다." 서버가 해킹당할 경우, 이러한 제한 사항은 공격자가 해당 서버를 네트워크의 나머지 부분으로 연결하는 다리로 사용하는 것을 막을 수 있습니다.

5. 패치가 최종 해결책이 아닐 수도 있다고 가정하십시오.

스와츠는 패치가 취약점을 없애지만 수정 전에 침입한 공격자는 제거할 수 없다고도 경고해요. 팀은 여전히 로그, 프로세스, 액세스 토큰 및 새 연결을 확인해야 합니다.

"서버 취약점이 드러났다고 해서 패치가 적용됐다고 해서 문제가 해결된 거라고 생각하지 마세요."라고 그는 말했다. “누군가 침입했다는 흔적을 찾아보고 어디로 갔는지 확인하고 위협이 발견되면 워크로드를 격리하세요.”

그는 비즈니스에 필요한 모든 서비스를 차단하지 않고 보안 침해를 억제하는 것이 목표라고 말합니다.

제때 수정할 수 없는 부분을 격리하세요.

PHP2Shell은 두 개의 시계를 작동시킵니다. 팀이 패치를 테스트하고 배포하는 데 필요한 시간을 추적합니다. 다른 하나는 공격자가 얼마나 빨리 침입 경로를 찾을 수 있는지를 추적합니다.

스와츠는 PHP2Shell을 현관문을 열 수 있는 만능 열쇠에 비유했습니다. 팀은 누군가가 열쇠를 시도하기 전에 항상 자물쇠를 바꿀 수는 없습니다. 하지만 작업량 사이의 경로를 알고 있고, 액세스를 제한하고, 이상한 교통 체증에 빠르게 대처한다면 문 하나로 집 전체를 열 필요는 없어요.