[화담일보 = 최유진기자] 웹사이트 개발 언어 PHP의 중대한 취약점 두 건이 공개되기 나흘 전인 10월 17일부터 이를 악용하려는 시도가 탐지됐다. 아마존웹서비스(AWS)는 자체 위협 관측망에서 해당 흔적을 확인했다고 밝혔다. 실제 운영 중인 시스템에 침투가 성공했는지와 공격자가 공개 전 정보를 어떻게 얻었는지는 아직 확인되지 않았다.
AWS의 최고정보보안책임자 CJ 모지스는 21일 보안 블로그에서 PHP2Shell로 불리는 CVE-2026-109618과 CVE-2026-109619에 대한 첫 시도를 자사 허니팟 'MadPot'에서 17일 확인했다고 발표했다. 공격 트래픽은 익명화 서비스와 연결된 IP 주소에서 나왔다. 허니팟은 공격 징후를 관찰하기 위한 유인 시스템이므로 이 기록을 곧바로 실제 고객 사이트 침해로 바꿔 읽을 수 없다.
공식 공개와 패치 배포가 예정된 시각은 21일 14시(UTC)였다. AWS는 같은 날 02시(UTC) 무렵부터 여러 개념증명 코드를 확인했고, 02~08시 사이에도 다른 익명화 인프라에서 MadPot을 겨냥한 시도가 이어졌다고 설명했다. 사용된 요청 내용과 인프라가 달라 복수 공격자가 관여했을 가능성이 있다는 분석이다. CVE는 공개된 보안 취약점에 붙이는 식별번호이며, 이번 두 번호는 PHP 관련 원격 코드 실행 위험을 가리킨다. 시도를 탐지한 시각과 공식 발표 시각을 구분해야 공개 전 노출 기간을 놓치지 않는다. 패치 공개 뒤에는 추가 코드가 몇 시간 만에 나와 센서에 사용됐다.
클라우드플레어는 PHP 관련 취약점의 공개 전부터 웹방화벽 보호 규칙을 준비했고, 21일 03시 02분(UTC)부터 무료·유료 고객에게 기본 적용했다고 밝혔다. 공개 전 약 9시간이라는 선제 적용 시점은 모든 서버가 안전해졌다는 의미가 아니다. 웹방화벽은 외부 요청을 막는 보완 수단이고, 취약한 PHP 자체의 버전을 고치는 조치와 역할이 다르다. 클라우드플레어는 공격자가 차단 규칙을 우회하려 요청 내용을 바꾸는 움직임도 관측했다고 밝혔다. 정상 요청과 공격을 가리려면 요청뿐 아니라 서버 응답을 함께 분석할 필요가 있다는 게 회사의 설명이다.
이번 사례에서는 취약점이 일반에 알려진 시점만을 사고 조사 시작점으로 잡으면 놓치는 구간이 생긴다. AWS는 17일 이후 웹서버 로그와 예상치 못한 프로세스 실행, 파일 변경 등을 확인할 것을 권고했다. 두 CVE를 완전히 고치려면 수정된 PHP 버전으로 업데이트해야 하며 설정 변경만으로 두 문제를 모두 해결하는 방법은 없다고 설명했다. 즉시 패치할 수 없는 환경에서는 파일 업로드 요청을 제한하는 방안을 검토하되 서비스 영향도 따져야 한다.
AWS는 공개 전 시도가 실제 시스템에서도 성공할 수 있었는지 기술 분석을 계속하고 있다. 동아일보는 일본과 영국 등에서 일부 공공·기업 서비스가 예방 차원에서 일시 중단됐다고 보도했다. 서비스 차단 사실을 곧바로 그 기관이 침해됐다는 증거로 볼 수는 없다. 운영자는 보유한 PHP 버전과 외부 노출 여부를 확인하고, 패치를 적용한 뒤 공개 전 기간까지 로그를 거슬러 살펴야 한다.
){kind=small}
){kind=small}
){kind=small}
){kind=small}