PHP2Shell(CVE-2026-109618, CVE-2026-109619): PHP를 운영하는 기업이 지금 해야 할 일

노트북을 든 기술자가 서버 랙에서 작업하는 모습

2026년 10월 21일, PHP 프로젝트는 "인증되지 않은 원격 코드 실행을 허용할 수 있는" 취약점 두 개를 수정한 PHP 8.5.12, 8.4.27, 8.3.36, 8.2.35를 출시했습니다. 쉽게 말해 귀사 웹사이트에 HTTP 요청을 보낼 수 있는 사람이라면 누구든 귀사 서버에서 자기 코드를 실행할 수 있을지도 모릅니다. 비밀번호는 필요 없고, 일부 구성에서는 애플리케이션이 코드 한 줄을 실행하기도 전에 공격이 통합니다. 두 취약점에는 PHP2Shell이라는 이름이 붙었고, PHP는 둘 다 9.2점(CVSS 4.0, 10점 만점)으로 평가합니다.

이 가이드는 실제로 조치해야 하는 분들을 위한 것입니다. PHP 웹사이트와 온라인 쇼핑몰의 소유자, IT 관리자, 그리고 PHP를 대신 운영해 주는 공급업체가 있는 모든 분입니다. 출시 다음 날인 2026년 10월 22일, PHP 프로젝트의 보안 권고, 각국 사이버 보안 기관의 지침, 벤더들이 공개한 수치를 바탕으로 작성했습니다. 출처끼리 말이 다른 부분은 그렇다고 밝혔습니다.

요약

PHP 자체를 업데이트한 뒤 재시작하십시오. WordPress, Drupal, Laravel이나 플러그인을 업데이트해서는 이 문제가 해결되지 않습니다. 결함은 애플리케이션 아래에 있는 PHP에 있습니다.
PHP에 따르면 웹 요청을 처리하는 모든 PHP 설치가 대상입니다. PHP-FPM, mod_php를 쓰는 Apache, php-cgi, FrankenPHP, LiteSpeed가 모두 해당합니다. PHP는 mod_php를 쓰는 Apache를 가장 위험한 구성으로 봅니다.
PHP 웹사이트의 절반 가까이는 PHP 프로젝트가 더 이상 릴리스를 내지 않는 브랜치에서 돌아갑니다(아래 W3Techs 데이터에 대한 저희의 해석입니다). 이런 사이트에는 설치할 공식 패키지가 없습니다.
설정과 방화벽은 시간을 벌어 줄 뿐, 안전을 보장하지는 않습니다. PHP는 임시 조치를 제시하면서도 그 조치가 "설치를 안전하게 만들지는 않는다"고 말합니다.
오늘 패치할 수 없다면 미국, 영국, EU 기관의 권고는 같습니다. 패치할 수 있을 때까지 시스템을 인터넷에서 분리하라는 것입니다.

지금까지의 경과

2026년 8월 19일. Wiz의 공개 글에 따르면 Wiz 연구진이 이날 첫 번째 결함을 발견했고, 8월 24일 두 결함을 PHP 보안팀에 제보했습니다. PHP의 보안 권고에는 다른 여러 회사의 연구자들도 함께 이름을 올렸습니다.
10월 20일. 예정된 공개 이틀 전에 CVE 번호가 온라인에 유출됐습니다. PHP는 릴리스를 하루 앞당겨 10월 21일 14:00 UTC로 정하고 모두에게 대비하라고 알렸습니다.
10월 21일, 03:02 UTC. Cloudflare가 무료 플랜을 포함해 자사 WAF를 쓰는 모든 고객에게 방화벽 규칙을 적용했습니다. Cloudflare는 이후 "고객을 겨냥한 공격 트래픽을 관측했다"고 밝혔고, 공격자들이 "보호 장치를 우회하려고 공격 페이로드를 변형하는" 모습을 보았다고 전했습니다.
10월 21일, 14:00 UTC경. PHP가 수정판과 보안 권고를 공개했습니다. 같은 날 미국 CISA, 영국 NCSC, CERT-EU, 그리고 유럽연합 집행위원회, ENISA, CERT-EU, Europol, EU 각국 CSIRT의 공동 성명이 모두 조직들에 즉시 패치하라고 촉구했습니다.

얼마나 심각한가?

세 가지 점에서 이번 건은 평소의 월례 패치와 다릅니다.

공격자에게 필요한 것은 요청 하나뿐입니다. 로그인도, 누군가 링크를 클릭하는 일도 필요 없습니다. PHP의 보안 권고는 mod_php를 쓰는 Apache에서 시연된 익스플로잇을 설명하는데, 이 환경은 "인증되지 않은 요청이 애플리케이션 코드가 실행되기도 전에 공격을 일으킬 수 있는" 곳입니다. Wiz는 최신 WordPress, Drupal, Joomla에 대한 공격을 시연했고, "영향받는 PHP 버전에서 돌아가는 단순한 'Hello World' 애플리케이션조차 취약할 수 있다"고 지적합니다. 이렇게 실행된 코드는 웹 서버 계정의 권한을 가지며, 대부분의 사이트에서 이 계정은 애플리케이션 설정을 읽을 수 있습니다. 데이터베이스 비밀번호, API 키, 메일과 결제 자격 증명이 거기 있습니다. 두 번째 결함인 CVE-2026-109619에 대해서는 PHP가 메모리 노출도 확인했습니다. 완전한 코드 실행까지 가지 않더라도 서버 메모리의 데이터가 밖으로 새어 나간다는 뜻입니다.

설치 기반이 거대합니다. W3Techs에 따르면 서버 측 언어가 알려진 웹사이트의 69.3%가 PHP로 돌아갑니다(2026년 10월 22일 기준 수치). Palo Alto Networks의 Unit 42는 자체 인터넷 스캔을 바탕으로 잠재적으로 취약한 노출 인스턴스가 2,260만 개를 넘는다고 집계했으며, 적어도 한 유럽 정부가 예방 차원에서 웹사이트를 내렸다고 전합니다.

익스플로잇 개발이 빠르게 진행되고 있습니다. CERT-EU는 초기 개념 증명(PoC)이 "유포되기 시작했다"고 전합니다. 보안 업체 watchTowr는 자사 허니팟이 10월 21일부터 악용 시도를 기록하고 있다고 밝힙니다. Cloudflare는 공격 트래픽을 보고합니다. 그리고 Wiz는 연구진이 작업 내내 AI 모델을 활용했고, 그 덕에 연구자 한 명이 "세계 최고 수준의 팀에게 몇 달이 걸렸을" 일을 일주일 만에 해냈다고 말합니다. 익스플로잇을 귀사의 PHP 버전에 맞게 고치는 공격자도 같은 도구를 갖고 있습니다.

반대쪽 사정도 공정하게 전하자면, CISA가 10월 21일 경보를 발표했을 때는 악용을 관측하지 못한 상태였고, 두 결함 모두 아직 CISA의 Known Exploited Vulnerabilities(알려진 악용 취약점) 카탈로그에 올라 있지 않았습니다. Red Hat은 이 문제를 치명적(critical) 등급이 아닌 "Important"(중요) 등급으로 평가합니다. 표준 Red Hat Enterprise Linux 서버는 PHP-FPM을 쓰고, 이 환경에서는 악용이 더 어렵기 때문입니다. 더 어렵다고 불가능한 것은 아닙니다. PHP는 두 번째 결함의 경로 하나가 PHP-FPM에서도 통한다고 확인했습니다. 이 중 어느 것도 귀사가 해야 할 일을 바꾸지는 않습니다. 달라지는 것은 미리 받게 될 경고가 얼마나 되느냐뿐입니다.

어느 버전을 쓰고 있습니까? 수치로 본 현황

W3Techs는 웹사이트가 어떤 PHP 버전을 쓰는지도 공개하며, 버전을 드러내는 사이트를 집계합니다. 2026년 10월 22일 자 두 표를 합치면 다음과 같습니다.

PHP 브랜치	PHP 웹사이트 중 비중	PHP 프로젝트의 수정
8.3, 8.4, 8.5	약 34%	있음: 8.3.36, 8.4.27, 8.5.12
8.2	약 18%	있음: 8.2.35. 다만 8.2 자체가 2026년 12월 31일에 지원 종료
8.0, 8.1	약 14%	릴리스 없음. 8.0과 8.1은 소스 백포트만
7.x	26.9%	릴리스 없음. 7.4는 소스 백포트만, 7.3 이하는 없음
5.x 이하	7.8%	없음

따라서 PHP 웹사이트의 약 48%는 PHP 프로젝트가 수정 릴리스를 내지 않는 브랜치에서 돌아가고, 또 다른 18%는 지금 수정판을 받지만 10주 뒤에 지원을 잃습니다.

단서가 두 가지 있습니다. W3Techs는 버전을 드러내는 사이트만 봅니다. 또 Linux 배포판이 오래된 브랜치를 자체적으로 패치했을 수 있습니다. 아래에서 보듯 Ubuntu가 그렇게 했습니다. 버전 번호만으로는 보호되고 있는지 알 수 없습니다. 그것을 알려 주는 것은 벤더 패키지의 버전입니다.

1단계: 운영 중인 모든 PHP 찾기

목록에 없는 것은 패치할 수 없는데, PHP는 잘 숨어 있습니다. 영국 NCSC는 인터넷에 노출된 것부터 모든 PHP 시스템을 찾으라고 요청하면서 이렇게 덧붙입니다. "탐색 범위를 오래된 PHP 버전으로 한정하지 마십시오." EU 공동 성명은 일부 제품이 "PHP를 직접 사용하지 않는 것처럼 보이더라도 이 취약점의 영향을 받을 수 있다"고 경고합니다.

살펴볼 곳은 다음과 같습니다.

웹사이트와 쇼핑몰: WordPress와 WooCommerce, Drupal, Joomla, Magento와 Adobe Commerce, Shopware, PrestaShop, TYPO3, 그리고 Laravel이나 Symfony로 만든 모든 것.
잊힌 것들: 캠페인 마이크로사이트, 오래된 언어 버전, 인터넷에서 접근 가능한 스테이징 및 테스트 서버, 몇 년 전 누군가 설치한 웹메일이나 헬프데스크.
컨테이너: php 베이스 이미지로 빌드한 모든 이미지에는 자체 PHP가 들어 있습니다. 호스트를 업데이트해도 그 PHP는 그대로입니다.
호스팅 제어판: cPanel, Plesk 같은 제어판은 시스템의 PHP와 별도로 자체 PHP 빌드를 함께 제공합니다. 제어판에서 활성화한 버전 하나하나가 따로 업데이트할 대상입니다.
PHP가 내장된 제품: 어플라이언스, 모니터링 도구, CRM, 헬프데스크, 벤더의 관리 인터페이스. 네덜란드 NCSC는 이런 제품의 공개 목록을 공급업체별 현황과 함께 관리합니다.
공급업체: 호스팅 회사, 외주 에이전시, 밑에서 PHP가 돌아간다고 알고 있는 모든 서비스. 귀사 시스템에서 어떤 PHP 버전이 돌아가는지, 언제 패치할 것인지 서면으로 물어보십시오.

각각에 대해 PHP 버전, PHP 실행 방식(mod_php, PHP-FPM, LiteSpeed, FrankenPHP, 컨테이너), 인터넷에서 접근 가능한지, 누가 패치할 수 있는지를 기록하십시오.

2단계: 올바른 순서로 패치하기

인터넷에서 접근 가능한 것부터 시작하고, 그중에서도 Apache mod_php 구성부터 처리하십시오.

지원되는 브랜치(8.2부터 8.5까지)를 쓴다면. 8.5.12, 8.4.27, 8.3.36, 8.2.35로, 또는 수정이 포함된 배포판 패키지로 업데이트하십시오. PHP는 Linux 배포판들이 패치를 미리 받았다고 말합니다. 지금까지 확인된 것은 다음과 같습니다.

Ubuntu: 14.04부터 26.10까지 모든 릴리스에 수정 패키지가 나왔습니다. 22.04 이상에서는 일반 업데이트로 받고, 20.04 이하에서는 Ubuntu Pro 구독이 필요합니다. Ubuntu Pro는 최대 5대까지 무료입니다(Canonical의 공지).
Debian: Debian 13용 php8.4 8.4.27(DSA-6574-1), Debian 12용 php8.2 8.2.35(DLA-4848-1).
Red Hat Enterprise Linux: Red Hat의 보안 공지 RHSB-2026-013에 릴리스별 패키지가 나와 있습니다.
Remi 저장소: Red Hat 계열 시스템에서 최신 PHP를 쓰기 위해 널리 사용되는 저장소입니다. 10월 21일 CERT-EU는 이 저장소에 출시 당일 패키지가 없다고 지적하고, 배포판 패키지로 바꾸거나 소스에서 빌드하라고 권고했습니다. 이 저장소에 의존하기 전에 그사이 패키지가 나왔는지 확인하십시오.

PHP 7.4, 8.0, 8.1을 쓴다면. PHP 프로젝트는 이 버전들의 릴리스를 내지 않습니다. PHP 보안팀이 세 브랜치에 대해 최소한의 소스 백포트를 만들었고, PHP를 직접 컴파일한다면 이것이 도움이 됩니다. 그렇지 않다면 수정은 벤더(예를 들어 Ubuntu Pro는 Ubuntu 20.04의 PHP 7.4를 지원합니다)에게서 받거나 PHP 업그레이드로 얻어야 합니다. 8.1 이하를 쓰면서 업데이트할 수 없는 곳에 대한 CISA의 조언은 단호합니다. 패치하거나 업그레이드할 때까지 시스템을 오프라인으로 두라는 것입니다.

PHP 7.3 이하를 쓴다면. PHP 프로젝트에서 나오는 것은 없습니다. 벤더가 아직 귀사의 빌드를 패치해 주지 않는 한, 선택지는 업그레이드 아니면 시스템을 오프라인으로 전환하는 것입니다.

업데이트 후에는 재시작하십시오. 패키지를 설치해도 이미 실행 중인 PHP는 교체되지 않습니다. Ubuntu의 공지도 분명히 말합니다. 애플리케이션을 "재시작해야 할 가능성이 높다"는 것입니다. 모든 서버에서 PHP-FPM, Apache, LiteSpeed 또는 컨테이너를 재시작하십시오. 그다음 명령줄의 php -v만 보지 말고 웹 서버가 실제로 실행하는 버전을 확인하십시오. 명령줄의 PHP는 다른 빌드일 수 있습니다.

컨테이너: 패치된 베이스 이미지로 이미지를 다시 빌드하고 다시 배포하십시오. 호스트를 패치해도 오래된 이미지를 돌리고 있다면 여전히 노출된 상태입니다.

매니지드 호스팅: 제공업체에 패치 날짜와 버전을 물어본 뒤 직접 확인하십시오.

3단계: 오늘 패치할 수 없다면

PHP의 보안 권고는 임시 조치를 나열하면서 먼저 경고를 붙입니다. 이 조치들은 "특정 공격 경로에 대한 노출을 줄이지만 설치를 안전하게 만들지는 않는다"는 것입니다. 서버를 운영하는 담당자를 위해 요약하면 다음과 같습니다.

CVE-2026-109618 대응: 애플리케이션이 덮어쓸 수 없도록 memory_limit=-1을 설정합니다(예를 들어 PHP-FPM 풀이나 Apache 설정에서 php_admin_value로). post_max_size를 낮게 설정합니다(PHP는 파일 업로드가 없으면 8M, 있으면 32M을 제안합니다). 웹 서버나 프록시에서 요청 크기, 필드 수, 멀티파트 파트 수를 제한합니다. 그리고 메모리 제한은 컨테이너나 cgroup으로 걸고, RLIMIT_AS나 RLIMIT_DATA는 절대 쓰지 않습니다.
CVE-2026-109619 대응: php.ini나 서버 설정에서 session.upload_progress.enabled=0을 설정하고(ini_set()이나 .user.ini 파일로는 안 됩니다) 모든 워커를 재시작합니다. PHP 8.5에서는 fatal_error_backtraces=0도 설정합니다.

경고가 두 가지 있습니다. PHP 보안팀의 한 구성원이 지적했듯이, 10월 20일에 널리 퍼진 세션 설정은 두 번째 결함의 경로만 막을 뿐 첫 번째 결함에는 아무 효과가 없습니다. 그리고 memory_limit=-1은 PHP 자체의 메모리 상한을 없애므로, 이제 무거운 요청 하나가 서버 자원을 바닥낼 수 있게 됩니다. 컨테이너나 cgroup 제한과 함께 쓰십시오.

웹 애플리케이션 방화벽은 도움이 되지만, 조금뿐입니다. Cloudflare의 규칙은 무료 플랜을 포함해 WAF가 있는 모든 플랜에서 기본으로 켜져 있고, Palo Alto Networks를 비롯한 다른 벤더들도 자체 보호 기능을 공개했습니다. 그래도 Cloudflare는 고객에게 "WAF 보호가 있더라도" PHP를 패치하라고 말하며, 공격자들이 규칙을 빠져나가려고 페이로드를 바꾸는 것을 직접 보았습니다. 또 WAF는 자신을 거쳐 가는 트래픽만 보호합니다. 서버가 자체 IP 주소로도 응답한다면 공격자는 WAF를 돌아서 갈 수 있습니다.

이 중 어느 것도 빨리 할 수 없다면 CISA, CERT-EU, NCSC, EU 공동 성명이 모두 같은 방향을 가리킵니다. 고칠 때까지 시스템을 공용 인터넷에서 분리하라는 것입니다. 하루 동안 점검 페이지를 띄우는 비용이 서버를 새로 구축하는 비용보다 적습니다.

4단계: 이미 공격당했는지 확인하기

위험 구간은 유출이 시작된 10월 20일에 열렸고, 다음 날 아침 공격 트래픽이 보고됐습니다. 그 기간에 시스템이 인터넷에서 접근 가능하고 패치되지 않은 상태였다면, 패치는 문을 닫아 줄 뿐 누군가 먼저 들어왔는지는 알려 주지 않습니다. NCSC는 즉시 패치하지 못한 모든 곳에 침해 징후와 백도어를 확인하라고 요청합니다.

공개된 지침과 일반적인 사고 대응 관행을 바탕으로, 찾아볼 것은 다음과 같습니다.

PHP가 원래 하지 않는 일을 하는 PHP 프로세스. 예를 들어 셸을 실행하거나 도구를 내려받는 경우입니다(CISA).
비정상적인 멀티파트 요청 뒤에 이어지는 메모리 제한 오류나 반복되는 HTTP 500 응답, 뚜렷한 이유 없이 재시작하는 PHP 워커, 응답에 담긴 비정상적으로 크거나 형식이 깨진 PHPSESSID 쿠키(Wiz).
새로 생기거나 변경된 PHP 파일(업로드 폴더, 캐시 폴더, 웹 루트), CMS의 새 관리자 계정, 아무도 만들지 않은 예약 작업.

로그가 깨끗하다고 해서 아무 일도 없었다는 증거는 아닙니다. PHP의 두 번째 결함 보안 권고가 바로 그 점을 경고하고, Wiz는 애플리케이션 로그에 맥락이 거의 남지 않을 수 있다고 지적합니다.

무언가를 발견했다면 패치 작업이 아니라 보안 사고로 다루십시오. 서버를 격리하고, 증거를 보존하고, 사고 대응 업체를 부르고, 웹 서버가 읽을 수 있었던 모든 시크릿을 바꾸십시오. 데이터베이스 비밀번호, API 키, 결제 및 메일 자격 증명, 서명 키입니다. 두 번째 결함은 메모리를 노출할 수 있으므로, 며칠 동안 노출된 채 패치되지 않았던 서버라면 침입 징후가 없더라도 그중 가장 민감한 시크릿을 교체하는 것을 고려하십시오.

5단계: 통보해야 할 수도 있는 것

취약점 자체는 통보 대상 사고가 아닙니다. 악용된 취약점은 그럴 수 있습니다.

NIS2: 귀사가 적용 대상이고 침해가 중대 사고에 해당한다면, 국가 CSIRT에 대한 조기 경보는 24시간 안에 해야 합니다. 저희의 NIS2 가이드를 참고하십시오.
GDPR: 개인정보에 대한 접근이 있었다면, 사람들에게 위험을 초래할 가능성이 낮은 경우가 아닌 한 유출을 인지한 때부터 72시간 안에 감독기관에 통지해야 합니다. 저희의 GDPR 가이드를 참고하십시오.
사이버 복원력법: PHP가 들어간 소프트웨어나 기기를 판매한다면 귀사는 사이버 복원력법상 그 제품의 제조자입니다. EU 공동 성명이 상기시키듯, 2026년 9월 11일부터 제조자는 자사 제품에서 실제로 악용되는 취약점을 사이버 복원력법 단일 통보 플랫폼을 통해 통보할 의무를 지고 있습니다. 저희의 사이버 복원력법 가이드를 참고하십시오.
고객: 고객을 위해 PHP를 호스팅하거나 운영한다면 고객이 물어올 것입니다. 짧은 서면 안내(무엇을 운영하는지, 언제 패치했는지, 무엇을 점검했는지)로 대부분의 질문에 답할 수 있고, 감사인이나 사이버 보험사가 보고 싶어 할 것도 바로 그 문서입니다.

비상 상황이 지난 뒤: 무엇을 바꿀 것인가

잘 관리되는 서버라면 대부분 며칠 안에 PHP2Shell 패치를 마칠 것입니다. 하지만 이번 일이 드러낸 귀사 환경의 사정은 그 뒤에도 그대로 남습니다.

패치에 얼마나 걸리는지 알아 두십시오. 보안 권고가 나온 때부터 모든 서버를 재시작할 때까지 몇 시간입니까, 며칠입니까, 몇 주입니까? 정직한 답이 "에이전시에 물어봐야 한다"라면 다음 사태가 오기 전에 그것부터 고치십시오. 연구자들이 AI 덕분에 익스플로잇 작업을 몇 달에서 일주일로 줄였다고 말하는 이상, 공격자도 그 속도로 움직일 수 있다고 가정하십시오.
방금 만든 자산 목록을 유지하십시오. 대응에서 가장 어려운 부분이었고, 맡는 사람이 없어지는 순간 낡기 시작합니다.
지원이 종료된 PHP에서 벗어나십시오. 7.4나 8.1의 사이트는 이번에 벤더나 소스 백포트가 필요했습니다. 다음에는 둘 다 없을 수도 있습니다. PHP 8.2는 2026년 12월 31일에 지원이 종료되므로, 8.1을 떠나는 사이트는 곧바로 8.3 이상으로 가야 합니다. PHP를 옮기려면 애플리케이션도 함께 업데이트해야 하는 경우가 많습니다. Drupal, Umbraco, Kentico 지원 종료에 관한 저희 글이 한 CMS의 경우 그것이 어떤 작업인지 보여 줍니다.
가능하면 mod_php보다 PHP-FPM을 쓰십시오. 이번에는 PHP-FPM이 위험이 더 낮은 구성이었습니다.
쓰지 않는다면 업로드 진행 기능은 꺼 두십시오. PHP의 보안 권고는 애플리케이션에 필요하지 않다면 패치 후에도 session.upload_progress.enabled를 꺼 두라고 제안합니다.
패치 시간을 계약서에 넣으십시오. 호스팅 제공업체와 에이전시에 치명적인 PHP 보안 수정을 얼마나 빨리 적용하는지 묻고, 답을 서면으로 받으십시오.

이번 주 체크리스트

컨테이너, 제어판, 벤더 제품, 스테이징 서버를 포함해 모든 PHP 설치의 목록을 만듭니다.
인터넷에 노출된 시스템부터, 그중에서도 Apache mod_php부터 패치합니다.
모든 PHP 프로세스를 재시작하고 웹 서버가 보고하는 버전을 확인합니다.
컨테이너 이미지를 다시 빌드하고 다시 배포합니다.
오늘 패치할 수 없는 곳에는 PHP의 임시 설정을 적용하거나, 트래픽을 WAF로 보내거나, 시스템을 오프라인으로 전환합니다.
공급업체와 호스팅 제공업체에 PHP 버전과 패치 날짜를 서면으로 요청합니다.
10월 20일 이후 노출된 채 패치되지 않았던 모든 시스템의 로그와 파일 변경을 검토합니다.
통보 의무(NIS2, GDPR, 사이버 복원력법)가 적용되는지 판단합니다.
PHP 8.1 이하에서 벗어나는 이전, 그리고 12월 31일 전에 8.2에서 벗어나는 이전을 계획합니다.

저희가 도울 수 있는 부분

대부분의 회사에 부족한 것은 패치하려는 의지가 아닙니다. 부족한 것은 무엇을 운영하고 있는지에 대한 명확한 그림, 또는 이번 주에 그 작업을 해 줄 사람입니다. 저희가 맡는 것이 바로 그 부분입니다.

며칠 안에 끝내는 자산 파악과 패치. 서버, 컨테이너, 호스팅 제어판, 공급업체 전반에서 PHP 설치를 찾아 패치하고, 재시작하고, 검증한 뒤, 무엇을 언제 했는지 서면 기록으로 남겨 드립니다. 그 기록은 고객과 감사인에게 드리는 답이기도 합니다.
오래된 PHP에서 벗어나기. 코드가 더 새로운 버전에서 돌아가지 않아 PHP 7.x, 8.0, 8.1에 묶여 있는 애플리케이션을 저희의 레거시 시스템 유지보수 서비스로 지원되는 버전에 이식합니다.
보안 강화와 정기 패치 체계를 갖춰, 다음 보안 권고가 비상 상황이 아니라 일정에 잡힌 작업이 되게 합니다.

침입 징후를 발견했다면 먼저 사고 대응 업체에 연락하십시오. 재구축과 업그레이드는 그 업체와 함께 저희가 맡을 수 있습니다.

운영 중인 환경을 적어 office@c9group.dev로 보내 주시면, 무엇부터 할지 답장 드리겠습니다.

출처

2026년 10월 22일에 확인했습니다. 상황은 계속 바뀌고 있으며, 특히 악용 현황과 벤더 패키지는 그 뒤로 달라졌을 수 있습니다.

PHP 프로젝트

기관

연구자, 벤더, 데이터