PHP2Shell, 내 사이트도 위험할까요? Black October 실체와 확인법 (2026 기준)

PHP2Shell, 내 사이트도 위험할까요? Black October 실체와 확인법 (2026 기준)

내 사이트도 지금 위험한가요, 아니면 과장된 소동인가요

PHP2Shell은 과장된 소문이 아니라 실제로 수정 버전(PHP 8.5.12, 8.4.27, 8.3.36, 8.2.35)이 나온 원격 코드 실행 취약점입니다. 반대로 'Black October'는 공식 이름이 아니라 SNS에서 붙은 별명이에요. 이 둘을 따로 봐야 불안은 줄고 할 일은 또렷해집니다.

"우리 쇼핑몰도 해킹당하는 거 아닌가요?" "워드프레스만 업데이트하면 끝인가요?" 이런 질문이 먼저 떠오르는 건 당연해요. 정책브리핑에 따르면 과학기술정보통신부가 2026-10-22 낮 12시에 민간 분야 사이버위기 경보를 '관심'에서 '주의'로 올렸으니까요.

이 글은 이런 순서로 답합니다. 무슨 일이 있었는지, 내 사이트가 해당되는지, "AI가 찾았다"는 말의 실제 범위, Black October의 실체, 실제 악용 현황, 한국 상황, 그리고 운영자가 확인할 순서까지입니다. 익스플로잇 방법이나 재현 절차는 방어에 필요하지 않아서 다루지 않아요.

목차

• 내 사이트도 지금 위험한가요, 아니면 과장된 소동인가요
• 2026-10-21에 정확히 무슨 일이 있었나요
• 워드프레스나 그누보드를 쓰는데 이것도 해당되나요
• "AI가 찾았다"는 정확히 누가 무엇을 찾았다는 뜻인가요
• Black October는 공식 명칭인가요
• 실제로 악용됐나요, 지금 어느 정도 위험한가요
• 한국은 어떤 상황이고, 호스팅 업체는 뭘 했나요
• 운영자는 어떤 순서로 확인해야 하나요
• 임시 완화로 버텨도 되나요, 새로 나온 CVE-2026-115560은 뭔가요
• 관련 글
• 마무리

2026-10-21에 정확히 무슨 일이 있었나요

PHP 보안팀은 2026-10-21 13:34 UTC에 GitHub 보안 권고 2건을 공개했고 14:00 UTC에 수정 버전을 배포했습니다. 한국 시각으로는 2026-10-21 23:00이에요. 두 취약점의 번호는 CVE-2026-109618과 CVE-2026-109619입니다.

• CVE-2026-109618(GHSA-w8hw-w9fx-j79w): PHP가 메모리 부족(out-of-memory) 상황을 처리하다 내부 요청 데이터가 덜 초기화된 채 중단되고 정리 단계가 그 잘못된 데이터를 그대로 쓰는 문제예요. 권고문에 따르면 Apache mod_php 기본 설정에서 인증 없이 원격 코드 실행이 검증됐고 이 과정은 애플리케이션 코드가 돌기 전에 일어납니다.
• CVE-2026-109619(GHSA-6wmf-4rv5-p3rp): 요청이 쓰던 내부 상태가 해제된 뒤에도 남아 같은 워커의 다음 요청이 그걸 쓰는 문제(use-after-free)입니다. 세션 업로드 진행(session upload progress) 기능 경로에서 mod_php와 PHP-FPM 모두 원격 코드 실행이 검증됐다고 권고문은 적었어요.

둘 다 로그인 없이 밖에서 웹 서버(PHP 워커) 권한으로 코드를 실행할 수 있다는 점이 핵심이에요.

점수는 채점하는 곳마다 체계가 달라요. 아래 표는 같은 줄끼리만 비교해야 합니다.

2026-10-20 유출 때 돌았던 "10.0점"은 PHP Foundation이 틀린 점수라고 밝혔어요. 소문에 나온 숫자보다 공식 권고의 체계 표기를 믿는 편이 안전합니다.

타임라인으로 보면

• 2024: 외부 보안 감사(OSTIF 주관, Quarkslab 수행) 과정에서 PHP Foundation 계약 개발자가 메모리 부족 문제의 첫 징후를 발견했어요. 수정은 늦어졌습니다.
• 2026-08-11: 보안 회사 Calif의 연구원이 첫 버그를 PHP에 보고했습니다.
• 2026-08-24: Wiz Research가 PHP 보안팀에 보고했어요.
• 2026-09-18: OpenAI가 추가 공격 경로를 보고했습니다.
• 2026-10-17: AWS가 허니팟(MadPot, 공격을 유인하는 미끼 서버)에서 첫 악용 시도를 관측했어요. 공개 4일 전입니다.
• 2026-10-20: CVE 번호 2개가 포럼과 SNS로 유출됐고 PHP는 릴리스를 하루 앞당겼습니다.
• 2026-10-21: 공식 패치가 공개됐어요.

같은 2026-10-21에는 엠바고 논란도 있었습니다. PHP Foundation은 보안 업체 Chainguard가 수정 반영 이미지를 07:41 UTC에 먼저 공개했다며 "unilaterally broke the embargo(일방적으로 엠바고를 깼다)"고 비판했어요. Chainguard의 CEO Dan Lorenc는 The Register 인터뷰에서 유출하지 않았다고 반박했고 자사 AI로 같은 취약점을 독자적으로 찾았으며 공격 증거를 보고 먼저 배포했다고 설명했습니다. 양쪽 말이 엇갈리는 상태 그대로 두는 게 정확해요.

워드프레스나 그누보드를 쓰는데 이것도 해당되나요

웹사이트에게 PHP는 건물 공용 출입문의 잠금장치와 비슷해요. 가게마다 간판(워드프레스, 그누보드 같은 사이트 프로그램)은 달라도 같은 건물이면 출입문 잠금장치는 함께 씁니다. 이번에는 그 잠금장치 자체에서 열쇠 없이 열리는 결함이 나왔어요. 그래서 간판을 새로 달아도 소용없고 잠금장치를 수정 버전으로 갈아야 합니다. 경비 업체에 해당하는 웹 방화벽(WAF)은 수상한 사람을 막아 주지만 잠금장치 교체를 대신하지는 못해요.

Cloudflare와 과기정통부 설명대로 워드프레스, 그누보드 같은 CMS의 코드나 플러그인을 고쳐서는 해결되지 않습니다. 워드프레스 보안 업데이트를 전부 적용한 사이트라도 그 밑에서 도는 PHP가 옛 버전이면 이번 취약점은 그대로 남아요. 이번에 필요한 PHP 보안 업데이트는 CMS 쪽이 아니라 서버 쪽 작업입니다.

GHSA는 8.2.35, 8.3.36, 8.4.27, 8.5.12 미만을 전부 취약 범위로 표기했어요. Wiz와 Calif, Google Cloud에 따르면 영향은 PHP 5.4부터 시작합니다.

php.net 릴리스 공지는 "PHP 8.1 and older no longer receive updates from the PHP project"라고 적으면서 7.4, 8.0, 8.1용 최소 소스 백포트를 따로 냈어요. CISA는 8.1 이하를 쓰는 조직에 패치 전까지 오프라인으로 두라고 권했습니다.

PHP-FPM이면 괜찮을까요

php.net은 웹 요청을 처리하는 모든 PHP 설치(PHP-FPM, Apache mod_php, php-cgi, FrankenPHP, LiteSpeed)를 위험군으로 보고 그중 mod_php를 가장 위험하다고 봤어요. PHP-FPM은 조금 헷갈립니다. GHSA는 완전한 익스플로잇은 시연되지 않았다고 썼지만 같은 날 PHP Foundation 블로그는 CVE-2026-109618의 원격 코드 실행이 애플리케이션 단 경로로 FPM에서도 확인됐다고 적었죠. 두 문서가 엇갈리니 FPM도 같은 긴급도로 패치하는 게 맞습니다.

"AI가 찾았다"는 정확히 누가 무엇을 찾았다는 뜻인가요

답부터 말하면 회사마다 자기 쪽 모델을 앞세워서 한 회사나 한 모델로 정리하면 틀려요.

OpenAI 쪽 설명은 2차 보도에서 더 구체적으로 나옵니다. Greg Brockman을 인용한 보도에 따르면 Calif가 OpenAI의 GPT-5.6 Sol로 8월에 한 버전을 찾았고 OpenAI 팀이 9월에 더 완전한 버전을 찾았다고 해요. 다만 이 문장은 직접 확인한 1차 문서가 아니라 보도를 거친 인용입니다. Calif 본문은 모델명을 밝히지 않았고, 초기 발견에는 "특별한 하네스나 일반에 공개되지 않은 모델은 쓰지 않았다"고만 적었죠.

"공격자보다 먼저"라는 말은 어디까지 맞을까요. 첫 보고(2026-08-11)는 AWS가 관측한 첫 악용 시도(2026-10-17)보다 67일 앞섭니다. 알려진 범위에서는 방어 쪽이 먼저 알았다는 말이 성립해요. OpenAI 문장에도 "to our knowledge"라는 단서가 붙어 있고 공격자가 더 일찍 알았는지는 확인할 수 없습니다.

공식 문서들의 공통 분모는 따로 있어요. 결함 코드는 오래전부터 있었고 AI는 그것을 실제 공격으로 증명하는 비용을 크게 낮췄다는 점입니다. Wiz는 AI가 바꾼 것을 "약점을 이해하고 작동하는 익스플로잇으로 만드는 능력"이라고 표현했어요. 수정이 늦어진 이유도 AI 때문이 아니었습니다. PHP Foundation에 따르면 수정안마다 호환성과 성능 부담이 있어 합의제 보안팀이 결정을 못 냈고 구체적인 원격 코드 실행 경로가 알려지지 않았으며 엔진을 아는 인력도 적었어요. Foundation은 이 상황을 "structural failure(구조적 실패)"라고 불렀습니다.

Black October는 공식 명칭인가요

아니요. 공식 기관이 붙인 이름이 아니에요. PHP2Shell 권고 2건은 2026-10-21에 나왔고, Black October로 묶인 공개는 2026-10-19부터 2026-10-22 사이에 몰린 여러 건입니다. SecurityToday는 2026-10-22 AISafetyMemes 계정의 X 게시물에서 이름이 시작됐다고 지목했지만 Forkast는 그 게시물을 찾지 못했다고 썼습니다. 원 게시물은 확인되지 않은 상태예요.

Black October는 공식 명칭인가요

이미지 출처: nodejs.org

묶인 공개 중에는 Node.js가 2026-10-21 보안 릴리스에서 고친 Brotli 디코더 취약점 CVE-2026-111497도 거론돼요.

반론도 있습니다. SecurityToday는 급증한 건 주로 "공개"의 몰림이고 상당수 공격은 몇 주에서 몇 달 전에 시작됐다고 썼어요. Unit 42는 적어도 유럽 정부 한 곳이 공격 때문이 아니라 예방 차원에서 웹사이트를 내렸다고 적었어요. 인터넷이 멈춘다는 식의 이야기는 제가 확인한 공식 문서 어디에도 없습니다.

Hacker News의 반응도 참고할 만해요. 엠바고를 실수로 깼다는 사과문이 703 points로 가장 큰 반응을 얻었고 분위기는 세 갈래였습니다. 엠바고 붕괴를 성토하는 쪽, AI 공로 다툼에 지친 쪽, 그리고 일단 패치하자는 쪽이에요. 커뮤니티 정서는 사실 근거가 아니라 반응으로만 읽어야 합니다.

실제로 악용됐나요, 지금 어느 정도 위험한가요

공개 전부터 악용 시도는 있었습니다. 다만 성공한 침해가 얼마나 되는지는 공개 자료로 확인되지 않아요.

• AWS는 2026-10-17 허니팟에서 첫 시도를 관측했고 "broad exploitation attempts"를 말하면서도 실제 시스템에서 성공했을지는 불명확하다고 썼어요.
• The Register가 인용한 Cloudflare CEO Matthew Prince의 설명에 따르면 공격 시도는 공개 전 10시간 동안 수천 건, 공개 후 45분 안에 수만 건, 2시간 안에 수십만 건, 그 뒤 수백만 건이었습니다. 기간별 누적 시도 건수이고 성공 건수는 밝히지 않았어요.
• CISA의 알려진 악용 취약점 목록(KEV) 2026.10.23판에는 두 CVE가 없습니다. Rapid7도 실제 악용 성공은 관측하지 못했다고 했어요.
• Unit 42는 2026-10-23 업데이트에서 유럽 정부기관 1건의 침해 후 활동을 적었습니다. 다만 초기 침투 경로가 PHP2Shell이라고 명시하지는 않았어요. 그래서 "PHP2Shell로 정부기관이 해킹됐다"고 옮기면 안 됩니다.

공개된 PoC(개념 증명 코드)는 여러 개 돌고 있어요. Rapid7은 이를 검토해 "각각 특정 OS, PHP 버전, 웹 서버 조합에서만 동작하고 넓게 신뢰할 만한 것은 없다"고 평가했습니다. 그러면서 악용이 어려운 지금을 "패치할 시간으로 써야지 미룰 이유로 삼지 말라"고 덧붙였죠. 안심하라는 말이 아니라 서두르라는 말입니다.

한국은 어떤 상황이고, 호스팅 업체는 뭘 했나요

공식 대응은 이미 여러 겹 나와 있어요.

• 과기정통부: 2026-10-22 낮 12시 민간 분야 사이버위기 경보를 '관심'에서 '주의'로 올렸습니다. 일반 국민이 직접 조치할 사항은 없다고도 안내했어요.
• KISA 보호나라: 2026-10-21 PHP 제품 보안 업데이트 권고, 2026-10-22 기업 보안 대응 수칙, 2026-10-24 신규 CVE-2026-115560 임시 조치 권고로 모두 3건입니다. KISA는 PHP 8.2의 보안 지원이 2026-12-31에 끝나므로 8.3 이상을 권했어요.

집계 숫자는 주체를 같이 보세요

규모 숫자는 집계 주체를 꼭 같이 봐야 합니다.

• Palo Alto Networks는 자사 Cortex Xpanse 기준으로 인터넷에 노출된 인스턴스 2,260만 개 이상이 잠재적으로 취약하다고 추정했어요. 실제로 공격 가능한 수를 센 숫자가 아닙니다.
• 세계일보는 안랩의 인터넷 자산 검색 집계를 인용해 취약 버전이 설치된 것으로 추정되는 국내 서버가 약 11만 개로 세계 6번째라고 보도했어요.
• 같은 기사가 인용한 W3Techs 자료(2026-10-19 기준)에 따르면 서버 측 언어를 식별할 수 있는 한국어 웹사이트의 78.1%가 PHP를 씁니다. Wiz 등이 말하는 "약 70%"도 서버 측 언어를 식별할 수 있는 웹사이트 가운데 PHP를 쓰는 비중이지 인터넷의 70%가 해킹 가능하다는 뜻이 아니에요.

국내 호스팅은 이렇게 움직였어요

• 카페24: 2026-10-21 오전 11:30부터 PHP 8.x 이하 전체 서버에서 세션 업로드 진행 기능을 선제 차단한다고 공지했어요. 완전한 방어를 보장하지는 않는다고 공지에 밝혔습니다. 같은 날 오후 11:30부터 PHP 8.2 이상 서비스를 8.2.35, 8.4.27, 8.5.12로 순차 업데이트한다고 공지했고, 서버당 1~10분 내외 중단을 안내했어요(공지 버전 목록에 8.3은 없어요).
• 가비아: 2026-10-22 00:00~03:00에 PHP 7.4, 8.4, 8.5 대상 보안 패치를 진행한다고 공지했고, 서버당 약 30분 내외 중단이 가능하다고 안내했습니다. 공지에는 8.2와 8.3 처리 내용이 없어요.

그누보드, 라이믹스, 영카트의 공식 공지는 확인하지 못했습니다. 국내 침해 여부도 공식 기관 발표로는 확인되지 않아서 "피해가 없다"고도 "피해가 났다"고도 말할 수 없어요.

운영자는 어떤 순서로 확인해야 하나요

핵심 요약: 내 사이트가 쓰는 PHP 버전을 확인하고, 수정 버전 이상으로 올린 뒤 PHP 서비스를 재시작하세요. 워드프레스나 그누보드가 아니라 그 밑의 PHP 자체를 올려야 해요.

KISA 대응 수칙을 기준으로 정리한 순서입니다. 직접 서버를 관리하는지 호스팅을 쓰는지에 따라 해당되는 부분만 보면 돼요.

호스팅을 쓰는 경우

호스팅 관리 화면의 PHP 버전과 호스팅사 공지로 내 사이트의 버전을 확인하세요(아래 1번). 그다음 호스팅 업체에 보안 업데이트 적용 여부를 문의하면 됩니다(아래 8번). 과기정통부는 일반 국민이 직접 조치할 사항은 없다고 안내했어요.

서버를 직접 운영하는 경우

1. 사이트가 실제로 쓰는 PHP 버전을 확인합니다. 터미널의 php -v와 웹 서비스가 쓰는 버전이 다를 수 있고 한 서버에 PHP가 여러 개면 각각 봐야 해요. 호스팅 이용자는 호스팅 관리 화면이나 호스팅사 공지로 확인합니다.
2. 리눅스 배포판 패키지는 고쳐져도 버전 번호가 그대로일 수 있어요. 예를 들어 Ubuntu 24.04의 수정 패키지는 8.3.6-0ubuntu0.24.04.13이라 php -v에 8.3.6으로 보입니다. "8.2.35 이상인가"만 보지 말고 패키지 변경 이력에서 CVE 반영 여부를 확인하세요.
3. 업데이트한 뒤에는 PHP를 돌리는 서비스(PHP-FPM, Apache 등)를 전부 재시작합니다. 재시작하지 않으면 메모리에 남은 옛 버전이 계속 돌아요. 컨테이너는 새 이미지로 재배포합니다.
4. 8.1 이하라면 지원 버전으로 옮깁니다. KISA는 8.3 이상을 권했어요.
5. 최소 2026-10-20 이후 로그를 살핍니다(AWS는 2026-10-17부터 보라고 했어요). KISA의 점검 항목은 이렇습니다. 비정상적으로 큰 요청 뒤 반복되는 HTTP 500 오류, 원인 모를 PHP 재시작이나 메모리 부족 오류, 웹 서버가 셸이나 다운로드 도구를 실행한 흔적, 업로드·임시 폴더의 낯선 새 PHP 파일, 결제 페이지에 몰래 붙은 외부 스크립트, 알 수 없는 외부 주소 연결이에요.
6. 업데이트 전까지 인터넷에 노출됐던 서버는 DB 비밀번호, API 키, 관리자 비밀번호를 교체하라고 KISA는 권했습니다. 서버 메모리의 비밀값이 새어 나갈 수 있는 취약점이라서예요.
7. 출처 불명 PoC는 실행하지 않습니다. KISA는 악성코드를 숨긴 가짜가 많다고 알렸어요. 취약 여부는 버전 확인과 로그 점검으로 판단하세요.
8. 호스팅으로 홈페이지를 운영하는 소상공인은 호스팅 업체에 보안 업데이트 적용 여부를 문의하면 됩니다.
9. 침해가 의심되면 서버를 끄거나 재시작하지 말고 외부 접속만 차단하세요. 그다음 증거부터 확보하고 보호나라(KISA)에 신고합니다.

임시 완화로 버텨도 되나요, 새로 나온 CVE-2026-115560은 뭔가요

임시 완화는 업데이트까지 시간을 버는 용도예요. 공식 문서들이 같은 말을 합니다. GHSA-w8hw-w9fx-j79w는 수정이 포함된 PHP 릴리스로 올리는 것이 "the only complete mitigation"이라고 적었고 GHSA-6wmf-4rv5-p3rp는 "There is no complete generic configuration mitigation"이라고 했어요. php.net 릴리스 공지의 표현은 더 직접적입니다. "There are no complete mitigations, updating is the only safe choice."

CVE-2026-109619 쪽 임시 조치는 session.upload_progress.enabled=0으로 끈 뒤 모든 워커를 재시작하는 것입니다. ini_set()이 아니라 php.ini, FPM 풀, 서버 설정으로 걸어야 해요. CVE-2026-109618 쪽 임시 설정은 메모리와 요청 크기를 만지는 방식이라 부작용(메모리 고갈 위험)이 있습니다. 설정값은 여기에 늘어놓지 않을게요. 공식 권고문의 임시 설정은 업데이트 전까지 시간을 버는 용도로만 보시면 됩니다.

웹 방화벽도 같은 위치예요. Cloudflare는 무료 요금제를 포함해 WAF를 쓰는 고객을 기본 보호하지만 업로드 진행 필드 이름을 바꾼 사이트는 규칙 밖이고 "WAF가 있어도 PHP를 패치해야 한다"고 밝혔습니다. Google Cloud Armor와 Imunify360도 보완책일 뿐이라고 명시했어요.

새로 나온 결함 CVE-2026-115560

2026-10-23 php.net이 새로운 결함 CVE-2026-115560에 대한 정보성 권고를 냈습니다. 2026-10-21 수정 버전(8.5.12 포함)으로도 막히지 않는 문제예요. 다만 실행 중에 세션 직렬화 방식을 바꾸고 세션 업로드 진행 기능도 켜 둔 드문 설정 조합에서만 생깁니다. 권고는 다음 정규 릴리스 전까지 session.upload_progress.enabled=0이고 CVE-2026-109619 완화로 이미 껐다면 추가 조치는 필요 없어요. KISA는 이 건의 영향 버전을 "제조사 미공개", 해결 버전을 "미배포(차기 정기 업데이트 예정)"로 표기했습니다.

관련 글

• 제미나이 4 아르곤 써볼 만할까요? 가격, 벤치마크에서 진 항목까지 정리: Wiz가 2026-08-24 PHP 보안팀에 보고한 분석에 썼다고 밝힌 모델 중 하나를 다룬 글이에요.
• OpenAI 모델 테스트넷 지갑 무단 사용 원문 검증: 같은 GPT-5.6 Sol 계열 모델이 등장한 다른 사건을 다룬 글이에요.

마무리

PHP2Shell은 소동이 아니라 업데이트 숙제예요. 취약점 2건은 실재하고 완전한 해결책은 수정 버전(8.5.12, 8.4.27, 8.3.36, 8.2.35 이상) 하나뿐이며, 누가 먼저 찾았는지는 회사마다 말이 다릅니다. Black October는 공식 이름이 아니라 별명이고요. 겁을 먹을 일도 무시할 일도 아니죠. 워드프레스 보안 점검에서 놓치기 쉬운 곳이 CMS 밑의 PHP라는 점만 기억해 두세요.

우리 사이트가 해당되는지는 지금 바로 판단할 수 있어요. 내 사이트가 쓰는 PHP 버전부터 확인해 보세요. 호스팅을 쓴다면 관리 화면이나 호스팅사 공지가 가장 빠릅니다.

자주 묻는 질문

워드프레스 플러그인과 테마만 업데이트하면 PHP2Shell은 막히나요?

아니요. Cloudflare와 과기정통부 설명대로 CMS 코드나 플러그인이 아니라 그 밑에서 도는 PHP 자체를 올려야 합니다. 기준은 8.5.12, 8.4.27, 8.3.36, 8.2.35 이상이에요. 호스팅을 쓴다면 관리 화면에서 PHP 버전을 확인하세요.

카페24나 가비아 같은 호스팅을 쓰면 제가 직접 할 일이 있나요?

과기정통부는 일반 국민이 직접 조치할 사항은 없다고 안내했어요. 카페24는 2026-10-21 밤부터 PHP 8.2 이상 서비스를 순차 업데이트한다고, 가비아는 2026-10-22 00:00~03:00에 PHP 7.4, 8.4, 8.5 대상 패치를 한다고 공지했습니다. 가비아 공지에는 8.2와 8.3 처리 내용이 없으니 내 사이트의 PHP 버전이 대상이었는지는 호스팅사에 확인하는 게 좋아요.

WAF나 Cloudflare를 쓰면 PHP 업데이트를 미뤄도 되나요?

미루면 안 됩니다. Cloudflare는 무료 요금제를 포함한 WAF 고객을 기본 보호하지만 업로드 진행 필드 이름을 바꾼 사이트는 규칙 밖이라고 밝혔어요. 그러면서 WAF가 있어도 PHP를 패치해야 한다고 적었습니다. Google Cloud Armor와 Imunify360도 보완책일 뿐이라고 명시했어요.

PHP-FPM을 쓰면 안전한가요?

안전하다고 말할 수 없어요. GHSA는 FPM의 완전한 익스플로잇은 시연되지 않았다고 썼지만 PHP Foundation 블로그는 CVE-2026-109618의 원격 코드 실행이 FPM에서도 확인됐다고 적었습니다. CVE-2026-109619 쪽은 세션 업로드 진행 경로에서 mod_php와 FPM 모두 검증됐어요.

이미 침해됐는지 어떻게 알 수 있나요?

KISA의 점검 항목을 기준으로 로그를 보세요. 비정상적으로 큰 요청 뒤 반복되는 HTTP 500 오류, 업로드·임시 폴더의 낯선 PHP 파일, 알 수 없는 외부 주소 연결이 대표적입니다. 의심되면 서버를 끄거나 재시작하지 말고 외부 접속만 차단한 뒤 증거를 확보하고 보호나라(KISA)에 신고하세요.

참고 자료

• php.net 뉴스 아카이브 2026 (보안 권고와 릴리스 공지)
• GHSA-w8hw-w9fx-j79w (CVE-2026-109618)
• GHSA-6wmf-4rv5-p3rp (CVE-2026-109619)
• PHP Foundation: Today's PHP Security Release, and How We're Strengthening PHP Security
• CISA 경보: Critical Vulnerabilities in PHP Require Immediate Patching
• KISA 보호나라: PHP 제품 보안 업데이트 권고
• KISA 보호나라: PHP 보안취약점(PHP2Shell) 관련 기업 보안 대응 수칙
• KISA 보호나라: PHP 신규 취약점(CVE-2026-115560) 임시 조치 권고
• AWS Security Blog: Amazon Threat Intelligence identifies PHP2Shell exploitation prior to public disclosure in MadPot
• Cloudflare: Cloudflare deploys protections against php2shell vulnerability
• Wiz Research: PHP2Shell: AI uncovers critical RCE vulnerabilities
• Calif Research: php2shell, A tale of two PHP remote vulnerabilities
• Rapid7 ETR: CVE-2026-109618 and CVE-2026-109619
• Unit 42 Threat Brief: Critical Vulnerabilities in PHP
• 정책브리핑: 과기정통부 민간 분야 사이버위기 경보 주의 상향
• 카페24 호스팅센터: PHP 긴급 보안 취약점 조치 작업 공지
• 카페24 호스팅센터: PHP 공식 보안 패치 적용 작업 공지
• 가비아: 웹호스팅(PHP) 긴급 보안 패치 작업 공지
• The Register: Hackers pile on PHP2Shell as AWS reveals attacks began before disclosure
• SecurityToday: Black October: Many attacks had been running for months