- AI가 PHP에서 10년 묵은 결함을 찾아냈고, 공개 뒤 악용 시도는 수천 건 단위에서 수백만 건 단위로 늘었다.
- PHP 엔진 패치를 누가 하는지는 호스팅 형태가 정한다. 공유 호스팅은 버전 선택과 호스팅사 확인, 직접 운영하는 서버는 패키지 업데이트와 PHP 재시작이 핵심이다.
- 지원이 끝난 PHP 버전에는 보안 수정이 나오지 않으므로, 패치가 아니라 상위 버전 이전을 계획해야 한다.
수천 건이던 악용 시도가 수백만 건으로 늘었다. 대부분의 웹사이트 뒤에서 돌아가는 PHP에서 AI가 10년 묵은 결함을 찾아냈고, 그 결함이 공개된 뒤 벌어진 일이다. 로이터가 전한 이 소식에는 더 강한 대목도 있다. 각국 정부가 웹사이트 운영자에게 PHP를 패치하라고 했고, 그럴 수 없다면 아예 사이트를 내리라고까지 촉구했다. 사이트를 하나라도 운영하고 있다면 오늘 할 일은 두 가지다. 내 사이트가 어떤 PHP 위에서 돌아가는지 확인하는 것, 그리고 호스팅 형태에 맞춰 업데이트하는 것. 이 글은 그 절차를 호스팅 형태별로 나눠 짚는다. 결함 자체의 기술적 세부는 아직 알려진 게 많지 않다. 그래서 이번 한 건보다는 다음 PHP 보안 공지가 나왔을 때도 그대로 쓸 수 있는 순서에 초점을 맞췄다.
워드프레스를 최신으로 올려도 PHP 엔진은 그대로다
PHP는 브라우저가 아니라 서버에서 실행되는 언어다. 방문자가 페이지를 열면 서버에 설치된 PHP 실행 엔진이 코드를 해석해 HTML을 만들어 보낸다. 워드프레스, 그누보드 같은 설치형 블로그·게시판·쇼핑몰 솔루션이 모두 이 구조 위에 올라가 있다. 맨 아래에 있는 엔진에 결함이 있으면, 그 위의 애플리케이션을 아무리 최신으로 유지해도 위험은 남는다.
층을 둘로 나눠 보면 덜 헷갈린다. 아래층은 PHP 엔진(인터프리터)이고, 위층은 그 위에서 돌아가는 애플리케이션과 플러그인이다. 워드프레스 관리자 화면에 뜨는 업데이트 알림은 주로 위층을 다룬다. 이번 결함이 가리키는 곳은 아래층, 곧 PHP 자체다. 엔진 업데이트는 관리자 화면 버튼 하나로 끝나지 않는 경우가 많고, 서버를 누가 관리하느냐에 따라 할 일이 갈린다. 플러그인 업데이트 알림이 없다고 해서 안심할 수 없는 이유다.
운영자가 먼저 답해야 할 질문은 두 가지다. 내 사이트는 어떤 PHP 버전에서 돌아가는가. 그 PHP를 업데이트할 권한이 나에게 있는가. 앞의 질문은 몇 분이면 답이 나온다. 뒤의 질문은 기술이 아니라 호스팅 계약 형태가 정한다.
내 사이트 PHP 버전은 세 곳에서 확인된다
아래 경로는 기본 설치 화면 기준이며, 호스팅사가 관리 패널을 자체적으로 고친 경우 표기가 조금 바뀔 수 있다.
① 워드프레스 관리자 화면. 관리자 메뉴에서 도구 → 사이트 건강 → 정보 탭 → 서버 항목을 펼치면 PHP 버전이 보인다(영문 화면은 Tools → Site Health → Info → Server). 같은 화면의 상태 탭은 PHP가 오래됐을 때 개선 권장 항목으로 경고를 띄우기도 한다. 서버에 접속하지 않고 브라우저만으로 확인할 수 있으니, 워드프레스 사이트라면 여기서 시작하는 게 가장 간단하다.
② 호스팅 관리 패널. cPanel을 쓰는 호스팅이라면 소프트웨어 → MultiPHP Manager에서 도메인별 PHP 버전을 볼 수 있다. 일부 호스팅은 같은 기능을 Select PHP Version이라는 메뉴로 제공한다(호스팅 환경에 따라 갈리는 부분이라 이 단계는 확실하지 않다). 국내 웹호스팅은 자체 콘솔을 쓰는 곳이 많다. 이런 곳은 메뉴를 하나씩 찾아보기보다 해당 회사 고객센터 문서에서 ‘PHP 버전 변경’을 검색하는 편이 빠르다.
③ 서버 직접 접속(SSH). 터미널에서 php -v를 입력하면 버전이 나온다. 다만 여기에 나오는 건 명령줄용 PHP 버전이다. 웹 서버가 쓰는 PHP와 다를 수 있고, 여러 버전이 함께 설치된 서버에서는 흔한 일이다. 웹에서 실제로 쓰는 버전은 웹 루트에 <?php phpinfo(); ?> 한 줄짜리 파일을 올려 브라우저로 열어 보면 확인된다. 이 파일은 서버 경로와 설정값을 그대로 노출한다. 확인했으면 바로 지워야 한다. 그대로 두면 공격자에게 서버 구조를 알려 주는 셈이다.
공유 호스팅은 호스팅사가, VPS·도커는 내가 패치한다
PHP 패치를 누가 적용하느냐는 계약 형태가 정한다. 아래 표는 일반적인 책임 구분이며, 세부 사항은 개별 호스팅 약관에서 확인해야 한다.
| 운영 형태 | PHP 엔진 패치 주체 | 운영자가 할 일 |
|---|---|---|
| 공유(웹) 호스팅 | 호스팅사 | 패널에서 지원되는 최신 버전 선택, 호스팅사 보안 공지 확인 |
| 관리형 워드프레스 호스팅 | 호스팅사 | PHP 버전 전환 일정 확인, 테마·플러그인 호환성 점검 |
| VPS·클라우드 서버 | 운영자 본인 | 운영체제 패키지 업데이트 후 PHP-FPM·웹 서버 재시작 |
| 컨테이너(Docker) | 운영자 본인 | 베이스 이미지를 새로 받아 다시 빌드·배포 |
공유 호스팅에서는 PHP 엔진을 호스팅사가 관리한다. 같은 버전 계열 안의 보안 수정은 호스팅사가 적용한다. 운영자가 직접 할 수 있는 건 패널에 더 새로운 지원 버전이 있을 때 그쪽으로 옮기는 정도다. 직접 할 수 있는 일이 적어서, 운영자가 할 일은 대부분 확인 작업이다. 호스팅사가 이번 결함에 대응했는지는 공지사항이나 고객센터 문의로 확인하면 된다.
운영체제까지 직접 관리하는 VPS나 클라우드 서버는 패키지 관리자로 업데이트한다. 우분투·데비안 계열은 sudo apt update && sudo apt upgrade, 레드햇 계열(록키·알마 리눅스 등)은 sudo dnf upgrade가 기본이다. 업데이트만 하고 끝내면 안 된다. PHP 프로세스를 재시작해야 새 코드가 메모리에 올라간다. systemctl list-units | grep php로 실행 중인 서비스 이름(php8.x-fpm 같은 형태)을 찾은 다음 sudo systemctl restart 서비스이름을 실행한다. 아파치 모듈 방식으로 PHP를 돌리고 있다면 아파치를 재시작하면 된다.
배포판 패키지에는 주의할 점이 있다. 우분투·데비안 같은 배포판은 보안 수정을 기존 버전 번호에 덧붙여 내보내는 백포트 방식을 쓴다. 그래서 php -v에 찍히는 PHP 버전 숫자가 그대로여도 패치는 이미 적용됐을 수 있다. 거꾸로 숫자만 보고 안심할 수도 없다. 가장 확실한 방법은 배포판 보안 공지에서 해당 결함의 수정 패키지 버전을 찾은 뒤, apt list --installed | grep php(레드햇 계열은 rpm -qa | grep php)로 설치된 패키지 버전과 하나씩 대조하는 것이다.
컨테이너로 운영 중이라면 실행 중인 컨테이너 안에서 패키지를 올리는 건 임시방편이다. 이미지는 그대로이니 다음 배포 때 패치 전 상태로 돌아간다. 공식 PHP 이미지의 새 버전을 받아(docker pull) 이미지를 다시 빌드하고 컨테이너를 교체해야 다음 배포에서도 패치가 유지된다.
지원 끝난 PHP 버전엔 적용할 패치가 없을 수 있다
PHP는 버전 계열마다 지원 기간이 정해져 있다. php.net의 지원 버전(Supported Versions) 페이지에서 각 계열이 일반 지원 중인지, 보안 수정만 받는지, 지원이 끝났는지 확인할 수 있다. 지원이 끝난 계열에는 PHP 개발진의 보안 수정이 더 나오지 않는다. 오래된 버전으로 돌아가는 사이트라면 이번 같은 결함이 공개돼도 받을 패치 자체가 없을 수 있다. 일부 배포판이나 유료 장기 지원 서비스가 예외적으로 수정을 제공하기도 하지만, 이는 개별적으로 확인해야 한다. 이런 경우에는 패치를 기다리기보다 상위 버전 이전을 계획해야 한다.
상위 버전으로 옮기는 작업은 버전 숫자만 바꾸면 끝나는 일이 아니다. 오래된 플러그인이나 직접 작성한 코드가 새 버전에서 오류를 낼 수 있어서다. 순서는 이렇게 잡는다.
- 파일과 데이터베이스를 함께 백업한다. 호스팅 백업 기능이 있더라도 별도 사본을 내려받아 둔다.
- 가능하면 스테이징(복제) 사이트에서 먼저 버전을 올려 본다.
- 테마·플러그인·솔루션 제작사의 PHP 호환 정보를 확인하고, 업데이트가 끊긴 플러그인은 대체재를 찾는다.
- 운영 사이트의 PHP 버전을 전환한 뒤 로그인, 글쓰기, 회원가입, 결제처럼 데이터와 돈이 오가는 기능부터 점검한다.
- 오류가 나면 패널에서 이전 버전으로 되돌릴 수 있는지 미리 확인해 둔다. 되돌린 상태는 취약한 버전이므로 최대한 짧게 유지해야 한다.
외주로 만들고 관리하지 않는 국내 사이트가 가장 취약하다
한국 웹 생태계의 PHP 의존도는 낮지 않다. 소규모 쇼핑몰, 커뮤니티, 기업 홈페이지 가운데 그누보드나 워드프레스 같은 PHP 기반 설치형 솔루션으로 만든 곳이 많다. 외주로 제작한 뒤 유지보수 계약 없이 운영되는 곳도 적지 않다. 국내에서 가장 약한 고리가 기술보다 관리 공백으로 보이는 이유다. PHP 버전을 누가 확인할지 정해져 있지 않은 사이트는 패치가 나와도 적용되지 않는다.
한국 사이트 운영자가 이번 일로 확인할 것은 세 가지다. 첫째, 사이트 소유자가 호스팅 계정 접속 정보를 직접 가지고 있는가. 호스팅이 외주 제작사 명의로 계약돼 있다면 PHP 버전을 확인할 때도 제작사를 거쳐야 한다. 둘째, 호스팅사 공지 채널. 공유 호스팅에서 PHP 엔진 패치는 호스팅사의 몫이지만, 오래된 버전 지원 중단이나 강제 전환 같은 조치는 대개 공지로 먼저 알린다. 셋째, 한국인터넷진흥원(KISA)이 운영하는 보호나라의 보안공지 게시판. 관련 권고가 올라왔는지 여기서 확인할 수 있다.
확인된 것과 아직 불확실한 것
확인된 것
- AI가 PHP에서 10년 묵은 결함을 찾아냈고, 이 결함은 웹의 상당 부분을 위협하는 것으로 평가됐다.
- 각국 정부가 웹사이트 운영자에게 PHP를 패치하거나 사이트를 오프라인으로 전환하라고 촉구했다.
- 결함 공개 이후 악용 시도는 수천 건 수준에서 수백만 건 수준으로 늘었다.
- 별개의 사례로, 해커들이 클로드(Claude)와 그록(Grok)을 이용해 중남미 은행 400곳 이상을 노린 공격을 자동화했다.
아직 불확실한 것
- 영향을 받는 PHP 버전 범위와 수정이 들어간 정확한 버전 번호. 원문에는 이 정보가 없으므로 php.net과 사용 중인 배포판의 보안 공지로 확인해야 한다.
- 결함을 찾아낸 AI가 어떤 모델·조직의 것인지, 결함에 붙은 식별 번호(CVE).
- 원문이 언급한 각국 정부에 한국 정부 기관이 포함되는지, 국내 기관이 별도 권고를 냈는지.
- 웹 방화벽(WAF)이나 CDN 보안 규칙만으로 이 결함의 악용을 막을 수 있는지. 패치 전 임시 대책으로 쓰더라도 패치를 대신한다고 보기는 어렵다.
결함 공개 후 악용이 몰리기 전에, 보안 업데이트를 자동화한다
결함이 공개되면 수정 방법과 함께 공격 지점도 알려진다. 공격자는 공개된 정보를 바탕으로 인터넷 전체를 자동으로 훑어 패치되지 않은 서버를 찾는다. 공개 뒤 악용 시도가 수천 건에서 수백만 건으로 늘어난 것도 이런 구조 때문이다. 여기에 AI 에이전트로 은행 공격을 자동화한 사례까지 겹쳐 보면, 결함 공개와 대량 악용 사이의 간격은 더 짧아질 가능성이 있다. 이 부분은 두 사례를 근거로 한 해석이며, 간격을 직접 측정한 수치는 원문에 없다.
방어하는 쪽에서 이 간격을 줄이는 가장 현실적인 방법은 보안 업데이트를 사람 손에만 맡기지 않는 것이다. 우분투·데비안 서버라면 sudo apt install unattended-upgrades로 패키지를 설치하고 sudo dpkg-reconfigure unattended-upgrades에서 자동 설치를 켜면 보안 업데이트가 자동으로 적용된다. 레드햇 계열은 dnf-automatic 패키지가 같은 역할을 한다. 다만 환경에 따라 PHP-FPM이 자동으로 재시작되지 않을 수 있다. 앞에서 짚은 재시작 문제는 자동 업데이트에서도 똑같이 생긴다. 업데이트 뒤 서비스가 재시작됐는지 점검하는 절차를 함께 둬야 한다.
패치를 바로 적용할 수 없는 사이트라면 각국 정부의 권고처럼 사이트를 잠시 내리는 것도 방법이다. 웹 서버 설정에서 모든 요청을 정적 HTML 점검 페이지로 보내면 PHP 실행을 멈춘 채 방문자에게 안내할 수 있다. 공유 호스팅 사용자는 PHP 엔진을 직접 고칠 수 없다. 호스팅사의 대응 일정을 확인하면서 그동안 백업을 확보해 두자. 서버에 남아 있는 테스트용 설치본이나 쓰지 않는 사이트를 지워 공격받을 수 있는 범위를 줄여 두는 편이 낫다.
