콜드퓨전(ColdFusion)이나 루시(Lucee)를 윈도우 서버의 IIS 위에서 운영하면서 PHP를 직접 설치한 적이 없다면, 그래도 서버 어딘가에 PHP가 남아 있을 가능성이 있다. 과거에 설치한 phpMyAdmin, 호스팅 업체의 기본 서버 이미지, 혹은 오래전 쓰던 관리 패널이 남긴 흔적일 수 있다. 개발자 그레고리 알렉산더가 자신의 테스트 블로그에서 겪은 사례는 이 '잊힌 PHP'가 어떻게 실제 운영 장애로 이어지는지를 잘 보여준다.
발단은 로그인 실패였다. 콜드퓨전으로만 돌아가는 관리자 페이지가 'multipart/form-data 요청이 PHP 완화 규칙(mitigation)에 의해 차단되었다'는 IIS의 403 오류를 띄웠다. PHP 코드가 단 한 줄도 없는 사이트에서 PHP 보안 규칙이 로그인을 막은 것이다. 원인은 타이밍에 있었다. 2026년 10월 21일 PHP는 인증되지 않은 요청만으로 서버에서 코드를 실행할 수 있는 두 개의 치명적 결함(별칭 PHP2Shell)에 대한 긴급 패치를 내놨고, PHP-FPM·mod_php·php-cgi·FrankenPHP·LiteSpeed 등 웹 요청을 처리하는 모든 PHP 구성이 영향을 받았다. 정식 해법은 8.5.12, 8.4.27, 8.3.36, 8.2.35 중 하나로 올리는 것이다.
과도한 완화 규칙이 만든 장애
문제는 호스팅 업체의 대응 방식이었다. 업체는 같은 주에 IIS의 서버 전역 URL Rewrite 규칙을 추가했는데, 이 규칙이 주소와 무관하게 콘텐츠 타입이 multipart/form-data인 모든 요청을 차단했다. 이 인코딩은 파일 업로드가 가능한 폼이 쓰는 방식이고, 실제로 업로드를 하지 않는 폼에서도 흔히 쓰인다. 규칙의 매칭 패턴이 .*, 즉 모든 주소였기 때문에 .php 주소뿐 아니라 콜드퓨전 사이트 네 곳의 관리자 로그인, 이미지 업로드, 파일 업로드가 한꺼번에 막혔다.
주목할 점은 PHP 공식 권고에는 이런 요청을 통째로 막으라는 내용이 없다는 것이다. 권고는 패치하고, 그 전까지는 session.upload_progress.enabled를 끄고 post_max_size를 낮추라는 것이다. 공식 완화책 상당수가 업로드 처리와 관련돼 있어 호스팅 업체가 '가장 큰 망치'를 집어 든 심정은 이해되지만, PHP를 쓰지 않는 사이트에는 불필요한 피해였다. 규칙을 .php 주소로만 한정하자 모든 기능이 정상으로 돌아왔다.
왜 애초에 PHP가 있었나
범인은 몇 년 전 MySQL 데이터베이스 하나를 관리하려고 설치했던 phpMyAdmin이었다. 그것이 사이트 폴더에 그대로 남아 있었고, 로그인 페이지는 인터넷 전체에 열려 있었다. 게다가 웹 루트에 복사본이 하나 더 있어 IIS 기본 웹사이트가 서버의 맨 IP 주소로 접속한 누구에게나 이를 제공하고 있었다. 인터넷에 노출된 phpMyAdmin 로그인 페이지는 봇들이 종일 비밀번호를 시도하는 상시 표적이며, 시도 한 번마다 PHP가 기동되고 데이터베이스에 접속한다.
점검은 PowerShell을 관리자 권한으로 열어 시작한다. IIS는 핸들러 매핑이 지시할 때만 PHP를 실행하므로, 핸들러 매핑을 조회해 아무것도 출력되지 않으면 IIS가 PHP를 실행하지 않는 것이다. 출력이 있다면 핸들러 이름과 scriptProcessor 경로를 적어 둔다. 제거 시 둘 다 필요하다. 웹 루트의 PHP 파일 개수를 셀 때는 Get-ChildItem -Recurse보다 윈도우 기본 dir이 훨씬 빠른데, 수년치 업로드 이미지가 쌓인 서버에서는 전자가 수 분씩 걸리기 때문이다. 필자의 경우 약 4,500개의 PHP 파일이 두 곳의 phpMyAdmin 폴더에서 발견됐다.
여기서 중요한 보안 경고가 있다. 알아보지 못하는 PHP 파일이, 특히 이미지나 업로드 폴더에 흩어져 있거나 최근에 변경됐다면 침해 가능성으로 간주하고 멈춰야 한다. 공격자들은 업로드 폴더에 작은 PHP '웹셸'을 떨어뜨리기를 즐긴다. 또한 php-cgi.exe 프로세스가 보이지 않는 것은 단지 최근 아무도 PHP 페이지를 요청하지 않았다는 뜻일 뿐이다. IIS는 요청이 올 때 비로소 이를 기동하므로, 판단 기준은 실행 중인 프로세스가 아니라 핸들러 매핑의 존재 여부다.
안전하게 제거하는 순서
제거는 되돌릴 수 있도록 순서대로 진행하고 먼저 백업한다. IIS는 appcmd.exe로 자체 구성을 스냅샷으로 떠 두고 restore backup으로 한 번에 복원할 수 있다. 파일은 삭제하지 말고 이동하는 편이 안전한데, 설정 파일에 데이터베이스 비밀번호가 들어 있을 수 있어 몇 주간 비공개 위치에 보관해 두는 것이 좋다. Move-Item이 파일 사용 중이라고 하면 PHP가 열고 있는 것이므로 iisreset /stop 후 옮기고 다시 start하면 된다(사이트가 몇 초간 중단된다). IIS의 요청 필터링으로 .php 확장자를 서버 수준에서 막으면 파일 존재 여부와 무관하게 404가 반환된다. 이후 Check 1에서 확인한 핸들러 이름과 php-cgi.exe 경로로 핸들러 매핑을 제거하고, 폴더 형태의 PHP는 C:\php를 C:\php-removed로 바꿔 몇 주 두었다가 지우면 문제 발생 시 즉시 되돌릴 수 있다.
몇 가지 실무 함정도 기록할 만하다. 규칙을 .php로 한정하려고 appcmd.exe로 같은 변경을 시도했을 때 PowerShell이 따옴표 처리를 소리 없이 망가뜨려 오류도 변화도 없었고, Set-WebConfigurationProperty에 작은따옴표를 쓰자 한 번에 적용됐다. 호스팅 업체가 PHP를 설치한 경우라면 제거 전에 반드시 문의해야 한다. 리눅스에서는 a2dismod php8.3 후 apache2 재시작으로 아파치의 PHP 실행을 멈출 수 있지만, Virtualmin 같은 관리 패널은 자체 도구용으로 PHP를 설치하므로 제거 전 확인이 필요하다. MySQL 관리는 원격 데스크톱으로 서버에서 HeidiSQL이나 MySQL Workbench 같은 데스크톱 도구를 쓰면 공개 로그인 페이지 없이 phpMyAdmin이 하던 일을 그대로 대체할 수 있다. 결국 교훈은 단순하다. 쓰지 않는 서비스는 공격 표면일 뿐 아니라, 남의 보안 대응에 내 사이트가 휘말리는 통로가 된다.