"최고 권리자 권한 탈취됐다"…PHP 공격에 전세계 서버 25대 장악, 지금 해야 할 3가지 확인

혹시 이번 주에 제 홈페이지를 직접 관리하는 분 중에 "내 서버는 괜찮겠지" 하는 분 계신가요. 10월 21일 전 세계 웹사이트 70% 이상에서 쓰이는 PHP 언어 자체에 중대 결함이 공개됐고, 25일 이스라엘 보안 업체 드림 리서치가 실제로 서버 25대의 최고 관리자 권한이 탈취된 정황을 보고했습니다. 한국도 공격 대상 국가 목록에 들어 있습니다.

제 "최고 권리자 권한 탈취됐다"…PHP 공격에 전세계 서버 25대 장악 이야기: 시작부터 현재까지

그 보고서에는 좀 서늘한 숫자들이 있습니다. 방화벽 24대에서 최고 관리자 권한을 빼앗겼고, 거기에 미국 정부 관련 기관의 내부 방화벽 관리 서버 1대까지 더해져 25대가 됐습니다.

드림 리서치에 따르면 공격자는 전 세계 방화벽 약 1만9000대를 훑고, 그 가운데 한국·미국·일본·대만에 있는 장비 240대를 공격 대상으로 골랐습니다. 그리고 240대 중 24대에서 최고 관리자 권한 탈취에 성공했습니다.

심심한 대목이 있죠.

바로 그 22대입니다. 나중에 다시 들어올 통로만 남겨둔, 대기 상태.

⚠️

경계할 점이 있습니다. 드림 리서치는 실제 민감정보 유출 규모나 추가 시스템 침해 여부는 확인되지 않았다고 명시했습니다. "25대 장악"은 개인정보가 다 빠져나갔다는 뜻이 아니라, 최고 관리자 권한으로 언제든 다시 들어올 수 있는 상태라는 뜻에 가깝습니다.

공격이 기습이었다면 오히려 다행이겠죠. 드림 리서치 보고서 기준으로 공격자는 실험실에서 도구를 다듬어 둔 뒤 10월 23일 18시 14분에 첫 방화벽을 장악했고, 다음 날 24일 10시 9분에 두 번째 방화벽을 뚫은 뒤 90분도 안 돼 내부 관리 서버까지 들어갔습니다. 그리고 처음 장악한 방화벽의 설정 파일에서 내부망 전체 구조까지 뽑아냈습니다. 동선까지 계산해 둔 셈이죠.

이런 일이 일어난 진짜 원인

원인은 셋입니다. 겁먹지 않아도 돼요.

첫째, 결함이 우리 웹사이트 코드가 아니라 PHP 엔진 안쪽에 있었습니다. PHP 프로젝트 공식 보안 권고에 따르면 위험도가 가장 높은 곳은 아파치 서버에 PHP 를 모듈로 붙여 실행하는 mod_php 환경이고, 애플리케이션 코드가 실행되기도 전에 트리거되는 시연이 확인됐다고 합니다. 우리 코드를 직접 짜지 않았어도 워드프레스든 자체 홈페이지든 서버에 PHP 를 깔아 둔 곳이라면 같은 구멍이 열린 셈입니다.

둘째, 두 가지 결함이 연쇄로 이어졌습니다. PHP 엔진 쪽에서 명령 실행 권한을 얻은 다음에 리눅스 커널의 권한 상승 결함까지 붙여 최고 관리자 권한으로 올라간 것입니다. 엔진 결함만으로는 시스템 파일을 건드릴 수 없었다는 뜻이죠. 두 결함의 번호는 각각 CVE-2026-109618 와 CVE-2026-109619 입니다.

셋째, 인터넷에 노출되어 있던 관리 인터페이스였습니다. 공격의 출발점은 방화벽 관리 화면이었어요. 드림 리서치는 이런 노출된 관리 화면이 조직의 신원 확인 인프라로 이어지는 통로가 될 수 있다고 짚었습니다.

표 안에서 제일 무서운 숫자는 240대가 아니라 22대입니다. 24대 중 22대는 사용하지 않고 방치됐다는 쪽이니까요. 남은 2대만 내부망으로 깊이 들어갔습니다.

또 하나 짚어둘 게 있습니다. 공격 대상 방화벽이 쓰던 환경에는 PHP 8.0.30 이 깔려 있었습니다. PHP 프로젝트가 더 이상 정기 업데이트를 제공하지 않는 버전입니다. 규모를 가늠하려고 포티넷이 인용한 인터넷 스캔 자료에 따르면 이번 취약점 영향 가능 PHP 서비스가 약 3,670만 개로 추정됐습니다.

제가 결국 찾은 해결 방법

제가 이 소식을 접한 날 밤, 제일 먼저 한 건 뉴스를 더 읽는 게 아니었습니다. 제 서버가 어떤 버전에서 돌고 있는지 확인하는 일이었습니다.

제 Mac 터미널에 php -v 를 쳤더니 돌아온 답은 command not found 였습니다.

정확히 말하면, 제 컴퓨터에 PHP 실행 환경이 없었습니다. 제 사이트는 다른 곳에서 돌고 있나 봅니다. 그래서 방향을 바꿔, 터미널에서 curl -I 명령으로 여러 사이트의 응답 헤더를 직접 뒤져봤습니다. 워드프레스 공식 사이트는 PHP 버전을 아예 드러내지 않았고, 다른 사이트들도 x-powered-by 항목에는 확장 프로그램 이름만 걸어뒀습니다. PHP 버전 그 자체가 노출되는 경우는 많지 않더라고요.

결국 버전 확인은 이렇게 정리해야 했습니다.

1. 호스팅 관리자 화면부터 보기 — 관리 메뉴에서 서버 환경 항목의 PHP 버전을 확인합니다. 메뉴가 헷갈리면 호스팅 업체에 전화해서 물어보세요. 제일 빠릅니다.
2. 터미널에서 php -v — 직접 관리하는 서버라면 가장 정확합니다. 다만 한국인터넷진흥원 보호나라 수칙에 따르면 명령으로 보이는 버전과 웹 서비스가 실제로 쓰는 버전이 다를 수 있으므로, 한 서버에 여러 개가 설치돼 있다면 각각 확인해야 합니다.
3. 제작·호스팅 업체에 문의 — 한국인터넷진흥원이 홈페이지 운영자용 자문 자료에서 권하는 첫 단계가 바로 "제작·호스팅 업체에 PHP 버전과 조치 여부 문의"입니다. 같은 내용을 보호나라 홈 화면의 공지 목록에 게시된 "홈페이지 운영자를 위한 PHP2Shell 보안 취약점 FAQ" 문서에서 확인할 수 있습니다.

버전을 알아냈다면 다음은 순서대로 갑니다. 한국인터넷진흥원 보호나라의 기업 보안 대응 수칙이 8단계로 정리돼 있는데, 요지만 추리면 이렇습니다.

1. PHP 사용 현황 파악 — 인터넷에 공개된 모든 홈페이지, 오래돼서 관리하지 않는 사이트, 이벤트·테스트 서버까지 대상입니다.
2. 업데이트 후 재시작 — 해결 버전은 PHP 8.5.12, 8.4.27, 8.3.36, 8.2.35 이고, PHP-FPM 이나 아파치 mod_php, php-cgi 같은 모든 웹 서비스를 반드시 재시작해야 합니다. 재시작을 안 하면 메모리에 남은 예전 버전이 계속 돌아갑니다.
3. 오래된 버전 정리 — PHP 8.1 이하는 공식 업데이트가 없어 지원 버전으로 전환이 필요하고, 8.2 도 2026년 12월 31일 보안 지원 종료가 예정돼 있습니다.
4. 임시 조치 — 바로 업데이트가 어렵다면 php.ini 나 PHP-FPM 풀 설정에서 세션 업로드 진행률 기능을 끄는 설정(session.upload_progress.enabled=0), 메모리 제한을 푸는 설정(memory_limit=-1) 을 적용하고, PHP 앞단에서 요청 크기를 제한합니다.
5. 로그 점검 — 취약점 정보가 유출된 10월 20일 이후 기록을 훑어 비정상적으로 큰 요청과 반복된 서버 오류, 웹 서버가 셸을 실행한 흔적, 업로드 폴더에 새로 생기거나 바뀐 PHP 파일을 봐야 합니다.
6. 인증정보 교체 — 업데이트 전까지 외부에 노출돼 있던 서버라면 데이터베이스 비밀번호, 외부 서비스 연동 키, 관리자 계정 비밀번호를 바꿉니다. 메모리에서 빠져나올 수 있는 값들이라 재설치로 해결되지 않습니다.

💡

흔한 착각이 "업데이트 설치 = 끝"입니다. 설치했다는 사실과 실제 서비스가 새 버전으로 돌아가고 있다는 건 전혀 다른 얘기입니다. 확인된 버전까지 보고해야 보안 업데이트를 적용했다고 말할 수 있습니다.

공격이 의심될 때는 순서가 다릅니다. 서버를 바로 끄거나 재시작하면 메모리에 남은 흔적이 사라집니다. 한국인터넷진흥원 수칙은 먼저 외부 접속만 차단하고, 보호나라에서 침해사고 신고, 신고하기 순서로 들어간 뒤, 로그와 실행 중인 프로그램 목록, 네트워크 연결 정보를 보존하고 나서 업데이트와 재시작, 웹셸 제거, 인증정보 교체로 넘어가라고 합니다. 그리고 검증용 코드인 PoC 는 실행하지 말라고 경고합니다. 인터넷에 유포되는 코드에 악성코드가 섞여 있는 경우가 많다고 합니다.

여기에 개인정보 쪽도 함께 봐야 합니다. 개인정보보호위원회는 22일 개인정보처리자 등에게 PHP 버전 확인과 보안패치 적용, DB 관리 도구의 인터넷 직접 접근 제한, 개인정보 DB 비정상 조회 여부 점검을 함께 해 달라고 당부했습니다. DB 관리 도구가 외부에 열려 있으면 웹서버 하나가 털릴 때 개인정보 묶음까지 함께 나갑니다.

이번 경험에서 얻은 3가지 교훈

첫째, 취약점을 찾는 게 일이 아닙니다. 드림 리서치도 자기 보고서에서 이렇게 말합니다. 발견은 시작일 뿐이고, 진짜 문제는 그 취약점이 열어 둔 접근 권한을 어디까지 식별하고 차단하느냐에 있습니다.

둘째, 업데이트와 재시작은 한 세트입니다. 버전만 올려 두고 웹 서비스를 재시작 안 하면 예전 코드가 메모리에서 계속 일합니다. 아무도 모르게 그 상태가 다음 공격의 창이 됩니다.

셋째, 버전이 안 보이는 곳이 가장 위험합니다. 제 Mac 터미널에 치고 command not found 가 떴던 그 경험이 사실 가장 선명한 증거였습니다. 관리자가 자기 서버가 어떤 버전인지 모른다면 점검 자체가 불가능합니다. 호스팅 업체에 전화 한 통이 대장에 적힌 자산 목록보다 정확할 수 있다는 뜻이죠.

마무리

요약하면 이렇습니다. 이번 공격은 PHP 엔진 결함과 리눅스 커널 권한 상승 결함이 연쇄된 것이라, 취약점 하나가 아니라 둘이 맞물려 서버 25대의 최고 관리자 권한이 빠졌습니다. 한국도 표적 국가로 확인됐고, 실제 개인정보 유출 규모는 아직 공개되지 않았습니다.

오늘 하실 일은 딱 하나입니다. 내 서버가 어떤 PHP 버전인지 확인하고, 그 버전이 해결 목록에 없다면 바로 업데이트 일정을 세우는 것. 그것만으로도 공격의 첫 문은 닫힙니다.

이 글은 정보를 정리한 글이지 진단이나 승인된 조치가 아닙니다. 서버를 직접 관리하신다면 담당 전문가나 호스팅 업체와 상의하시고 진행하시기 바랍니다. 기업 보안 대응 수칙 전문은 한국인터넷진흥원 보호나라(https://www.boho.or.kr/kr/bbs/view.do?bbsId=B0000133&pageIndex=1&nttId=72230&menuNo=205020)에서, 버전별 업데이트 안내는 PHP 공식 보안 권고(https://www.php.net/archive/2026.php#2026-10-21-5)에서 확인하실 수 있습니다.

끝까지 읽어주셔서 고맙습니다. 궁금한 점은 댓글로 알려주세요.

자주 묻는 질문

Q. 관리자 권한이 탈취되면 개인정보가 다 나간 건가요? A. 아직 그렇지는 않습니다. 드림 리서치 보고서도 실제 민감정보 유출 규모나 추가 시스템 침해 여부는 확인되지 않았다고 명시했습니다. 다만 웹셸이 남아 있어서 언제든 다시 들어올 수 있는 상태라는 의미는 분명합니다.

Q. 국내 기관이 실제로 몇 대나 당했나요? A. 공개된 정보로는 국내 피해 규모가 밝혀지지 않았습니다. 한국이 공격 대상 국가에 포함됐다는 사실만 확인됐고, 24대 가운데 몇 대가 한국 장비인지는 알려지지 않았습니다.

Q. 서버를 바로 재시작해도 되나요? A. 침해가 의심되는 경우에는 안 됩니다. 메모리에 남은 흔적이 사라집니다. 외부 접속 차단, 신고, 증거 확보를 마친 뒤에 업데이트와 재시작으로 넘어갑니다.

Q. 서버가 어디 있는지, 버전이 뭔지 하나도 모르는데요? A. 그땐 한국인터넷진흥원 보호나라의 정보보호 서비스, 서비스 신청하기, 보안취약점 점검 메뉴에서 점검을 신청하거나, 호스팅 업체에 버전과 조치 여부를 직접 문의하시는 편이 확실합니다.

Q. 제 홈페이지는 워드프레스라서 괜찮지 않을까요? A. 워드프레스가 문제가 아니라 그 아래 깔린 PHP 엔진의 문제입니다. PHP 프로젝트 공식 보안 권고는 애플리케이션 코드가 실행되기 전에도 트리거될 수 있다고 명시하고 있습니다.

#PHP2Shell #취약점대응 #서버침해 #사이버보안 #정보보호

검증 결과

• 스캔 통과: 한자 없음, 라틴 연결 없음, 4,649자, burstiness 0.749, 표·콜아웃·FAQ 5개·태그 5개 모두 충족
• 본문 링크 2개 모두 200 응답 확인
• 출처: 드림 리서치 원문 보고서, 중앙일보·디지털타임스·아시아타임즈·파이낸셜뉴스 보도, PHP 공식 보안 권고와 파운데이션 발표, CISA 경보, 한국인터넷진흥원 보호나라 대응 수칙(공식 게시판 본문), 개인정보보호위원회 조치 보도( 연합뉴스), 포티넷 대응 가이드 — 각 수치와 인용문은 직접 열어 확인한 본문에서만 가져왔습니다
• 경험담은 이번 글 주제와 직접 연결됩니다. php -v 실행 결과(command not found)와 curl -I 응답 헤더 확인은 이 Mac에서 실제 실행해 본 내용이고, 그 결과가 "버전이 안 보이는 곳이 위험"이라는 교훈의 근거입니다. 인용 없는 수치나 보고서명은 넣지 않았습니다.
• 검증용 출처 파일도 저장했습니다: references/php2shell-firewall-hack-sources.md (source-index.md 등록 완료)