# PHP 심각한 취약점, 워드프레스는 괜찮을까? 영향, 확인, 그리고 그 이후의 관리 (2026년) (CVE-2026-109618)

> https://bookfactory.kr/board/news/23194
> 게시판: 뉴스
> 작성자: admin
> 작성일: 2026-10-22T06:57:56.227Z

---

10월 21일 저녁, PHP 공식 뉴스에서 해당 날의 수정 사항이 2건 나열되어 있었습니다. 인증 없이 서버 측 명령을 실행될 가능성을 지칭하는 내용이며, 워드프레스 화면의 결함과는 관련이 없습니다. 영어권에서는 이를 ‘php2shell’이라는 별칭으로 부르며, CISA는 이 두 수정 사항을 통칭하여 그렇게 명명하고 있습니다. PHP 공식 공지 본문에는 해당 별칭이 언급되지 않았습니다.

저는 이노와에서 워드프레스 홈페이지를 제작하고 공개 후 PHP를 확인했습니다. 이와 유사한 사례는 간혹 발생합니다. 이번에는 중요한 차이점이 있습니다. 공식적으로 위험도가 가장 높다고 언급된 Apache의 mod_php에서, 인증되지 않은 요청이 애플리케이션 코드가 실행되기 전에 통과할 수 있다는 사례가 실제로 증명되었으며, 심각도는 CVSS v4.0 기준 9.2입니다. 근본적으로 수정해야 할 부분은 워드프레스의 “업데이트” 버튼이 아닌 PHP 자체입니다.

관리 화면을 최신 버전으로 업데이트해도 서버의 PHP가 오래되면 이번 문제는 그대로 남아 있습니다. HTML만으로 만들어진 페이지라도, 같은 서버가 PHP를 외부에서 실행하고 있다면 무관한 것은 아니라고 단정할 수 없습니다. 우선 확인해야 할 것은 어떤 PHP가 웹 요청을 받고 있는가입니다. 수정은 그 후에 하면 됩니다. 저는 이 공지를 읽은 주에 상황을 지켜보지 않았습니다.

2026년 10월 21일 저녁부터 22일까지 PHP 공식, CISA, 영국 NCSC, IPA의 사전 고지, PHP Foundation, Google Cloud, CERT-EU, ENISA에서 제공된 정보는 확인된 내용과 아직 추적되지 않은 내용을 본문과 말미에 구분하여 제시합니다.

宜野湾市伊佐でホームページを見ている鈴木孝昌です。屋号は沖縄ホームページ制作工房WEBCRAFTS。1993年頃からの実務で、WordPressは宜野湾の現場で保守してきました。官公庁のサイトも、大手のサイトも、Astroで作ってきました。今回の番号は、その現場の話として書いています。

## 2026년 PHP 취약점은 워드프레스 업데이트로는 해결되지 않는다.

대상은 웹 요청을 처리하는 PHP입니다. 바로잡아야 할 본질은 PHP 자체의 업데이트입니다. 워드프레스의 “업데이트” 버튼은 또 다른 층입니다. 여기를 혼동하면 관리 화면은 최신이지만 구멍만 남게 됩니다.

2026년 10월 20일, PHP 보안팀은 다음 날인 21일에 심각한 수정 사항을 발표할 예정임을 사전에 알렸습니다. 예정된 시각은 UTC 14:00이며, 심각도는 CVSS v4.0 기준에서 2건 모두 9.2로 평가되었습니다. 실제 수정 버전은 2026년 10월 21일에 공개되었습니다. Google Cloud의 해당 날짜 설명에서는 조사 측으로 Wiz Research의 이름이 언급되었습니다. 발견 경위의 세부 사항은 이 기사에서는 공식 보안 공지 이상의 내용은 다루지 않았습니다. 분 단위의 시간은 PHP 공식 뉴스 목록에는 기재되어 있지 않습니다. CERT-EU는 UTC 13:30, ENISA는 UTC 13:40으로 기록하고 있으며, 이는 출처 불일치입니다. 날짜는 10월 21일로 처리합니다.

번호는 다음 두 건입니다.

- CVE-2026-109618（GHSA-w8hw-w9fx-j79w）。메모리 부족으로 처리 중인 도중에 요청의 내부 데이터가 중단된 상태로 남아있고, 나중에 이를 올바른 데이터로 취급하는 문제입니다.
- CVE-2026-109619 (GHSA-6wmf-4rv5-p3rp)입니다. 요청이 사용하던 내부 상태가 메모리 해방 후에도 남아 있어, 동일한 작업 프로세스가 다음 요청에서 해당 오래된 상태를 사용してしまう 문제입니다.

PHP 공식은 두 경우 모두 인증 없이 원격 코드 실행으로 이어질 수 있다고 지적했습니다. 공격이 성공할 경우, 해당 PHP 작업 프로세스의 권한으로 명령 실행, 해당 프로세스에서 보이는 데이터 읽기, 처리 중단 등이 발생할 수 있다고 AWS가 설명하고 있습니다. Google Cloud는 코드 실행 외에도 메모리 상의 정보가 노출될 가능성까지 언급합니다. 어디까지가 실제 증거이고, 어디부터가 영향 범위 설명인지 각 벤더마다 표현 방식이 다릅니다. 중요한 점은 인증이 필요 없다는 것입니다. 관리 화면의 비밀번호가 강력한가보다 중요한 것이 아니라, PHP가 요청을 받은 시점에서 이미 통과할 수 있다는 mod_php에 대한 공식적인 설명입니다. 일본 내 피해가 확인된 사례는 아직 발견되지 않았습니다.

일반적으로 알려진 php2shell(PHP-2 셸)은 CISA가 10월 21일에 발표하면서 이 두 건을 묶어 부르는 용어입니다. 네덜란드 NCSC의 정리용 리포지토리 이름에도 사용되었습니다. PHP 공식 보안 공지의 본문에는 확인된 범위 내에서 이 용어가 등장하지 않습니다. 두 건 중 하나만을 지칭하는 공식적인 별칭이라는 대응표는 공식 문장에서는 찾아볼 수 없습니다.

평소에 홈페이지와 관련된 것은 PHP가 “서버 내에서 방문자의 요청을 받아 페이지를 구성하는” 역할을 하기 때문입니다. 회사 소개, 예약, 문의, 워드프레스 관리 화면 등이 동적인 페이지들을 기반으로 구축되어 있습니다.

## 기술적으로 무엇이 문제인지

애플리케이션의 PHP 파일을 여는 이전 단계의 PHP 엔진 수신 처리 문제에 대한 공식 측의 지적이 있습니다. 하지만 모든 동작 방식에서 동일하다는 주장은 명확하게 나타나 있지 않습니다.

일반적인 사용자에게 설명하자면 다음과 같습니다. 홈페이지의 프로그램은 방문자가 페이지를 열 때, 서버 내의 PHP가 “이 요청을 처리하라”고 일을 시작합니다. 이번 문제는 바로 이 일의 시작과, 오류로 인해 중간에 종료된 후의 정리 문제에 있습니다. 웹사이트에 쓰여진 글이나 워드프레스 플러그인의 좋고 나쁨과는 별개로, 건물을 비유하자면 매장 내장과 달리 전기 배선에 문제가 있는 것과 같습니다.

기술 전문가를 위해 PHP 공식 문서를 훼손하지 않고 제공합니다.

CVE-2026-109618은 메모리 부족 상황에서 처리 시 내부 요청 데이터가 일부만 초기화되지 않은 시점에 PHP가 중단될 수 있다는 설명입니다. 공식적으로는 정리 작업이 해당 잘못된 데이터를 합당한 것으로 취급한다고 되어 있습니다. PHP Foundation은 Apache의 mod_php에서는 인증되지 않은 요청이 애플리케이션 코드 실행 전에 이 문제를 일으키고, 초기 설정 상태에서 원격 코드 실행이 시도되었다고 설명합니다. 같은 Foundation의 글에서는 PHP-FPM에서도 원격 코드 실행이 확인되었지만, 이는 애플리케이션 측 처리 경로를 통해 발생했다고 적고 있습니다. “어떤 사이트든 프로그램이 한 줄도 움직이지 않은 상태에서 반드시 침입된다”는 주장은 공식적으로 언급하지 않았습니다. 실제 사례는 mod_php의 예와 FPM에서는 애플리케이션 측 경로로 나누어 읽어야 합니다.

CVE-2026-109619는 이미 해제된 메모리를 그대로 둔 상태가 남아, 동일한 워커가 처리하는 다음 요청이 초기화되기 전에 해당 상태를 사용하게 되는 현상을 설명합니다. PHP Foundation은 use-after-free(해제 후 메모리 참조) 및 워커의 중단을 확인했으며, Apache의 mod_php 상의 실제 애플리케이션에서 원격 코드 실행이 시연되었다고 밝혔습니다.

PHP 공식이 가장 큰 위험으로 생각하는 것은 Apache와 mod_php입니다. 언급된 대상은 PHP-FPM, Apache의 mod_php, php-cgi, FrankensteinPHP, LiteSpeed입니다. Nginx 자체에 문제가 있다는 것이 아니라, Nginx가 PHP-FPM으로 요청을 전달하는 경우, 전달된 대상의 PHP가 대상이 됩니다.

명령줄(CLI)에만 사용하는 PHP에 대해 공식적인 경고는 “웹 요청을 처리하는 PHP”입니다. `php -v` 명령의 출력 결과가 웹 서버와 동일한 버전은 아닐 수 있습니다. CLI만 오래되었고 웹에 PHP를 전달하지 않는다면, 이 경고의 주 대상과는 거리가 둡니다. CLI에 외부 입력을 전달하는 배치까지 안전하다고 명시되어 있지는 않습니다. 이는 환경에 따라 확인해야 할 부분입니다.

실증 코드가 공개의 장에 나타나기 시작했다는 언급은 CERT-EU의 10월 21일 주의 촉구에 있습니다. 이는 “침입의 성공이 일본에서 확인되었다”는 것과는 별개입니다. CISA는, 공표 시점에서는 이 취약성의 악용을 관측하지 않았다고 보고 있습니다. 공격 통신의 관측, 실증 코드의 유통, 실제 침해. 이 세 가지는 다른 사실입니다. 원고를 모아 10월 22일에도 CISA의 문면은 10월 21일 공표의 “관측하지 않은” 상태 그대로입니다. 그 이후 악용의 관측이 나오지 않는지는 공개의 횟수에 따라 공식적으로 확인하는 문제입니다. 관측되지 않은 것과, 통과되지 않는 것은 별입니다. 실증 코드가 나타난 주에, 오래된 PHP를 인터넷으로 계속 내버려 두는 이유는, 자신에게는 발견되지 않습니다.

일시적인 설정 변경은 PHP 공식에서 “특정 경로에 대한 노출을 줄이는 동시에 안전을 보장하지 않는다”고 기술하고 있습니다. 메모리 제한, 전송 크기 제한, 세션 업로드 진행 중단 설정, PHP 8.5에서는 치명적인 오류의 백트래스 설정 등이 안내문에 포함됩니다. 공식은 동시에 “완전한 해결책은 업데이트뿐”이라고 강조합니다. 설정 이름과 적용 시 주의사항은 PHP 공식의 2026년 뉴스에 모두 담겨 있습니다. WAF(웹 애플리케이션 방화벽, 의심스러운 통신을 미리 차단하는 방식) 또한 CISA는 업데이트까지의 일부 보호에는 도움이 될 수 있다고 언급하고 있습니다. WAF를 추가했을 뿐만 아니라 바로 해결되었다고는 다루지 않습니다.

## 영향을 받는 PHP 버전

현재 지원 중인 8.2, 8.3, 8.4, 8.5 버전은 각각 지정된 버전 이후로 업그레이드하는 방안을 논의하고 있습니다. 8.1 이전 버전은 PHP 프로젝트의 일반적인 수정 릴리스는 없습니다.

PHP 공식 버전은 “이 버전으로 업데이트”라고 언급된 8.5.12, 8.4.27, 8.3.36, 8.2.35입니다. AWS 보안 공지는 각 시스템의 영향을 다음과 같이 정리하고 있습니다. Google Cloud 역시 PHP 5.4부터 8.5.11까지의 영향을 미치는 수정 버전을 4가지로 제시하고 있습니다.

시스템 영향으로 정리된 범위 공식 수정본 8.58.5.0 ~ 8.5.118.5.128.48.4.0 ~ 8.4.268.4.278.38.3.0 ~ 8.3.358.3.368.28.2.0 ~ 8.2.348.2.358.1 이전 PHP 프로젝트의 일반 릴리스는 없음

8.2 버전은 PHP 공식에서 “2026년 12월 31일자로 지원이 종료되며, 이후 이 계열의 보안 수정 사항은 제공되지 않는다”고 8.2.35 릴리스 노트에 명시하고 있습니다. 이번 수정 사항이 포함되더라도, 이 계열에 계속 머무는 결정은 연말까지의 일시적인 조치입니다.

8.1 이전 버전 관련하여 공식적으로는 두 단계로 작성되어 있습니다. 일반적인 업데이트는 제공되지 않습니다. 심각성을 고려하여 소스 코드를 직접 빌드하는 사용자나 장기 지원 업체의 지원이 없는 사용자들을 위해 7.4, 8.0, 8.1의 최소 소스 차이점을 제공한다고 명시되어 있습니다. 이는 공식적인 신버전 번호와는 별개입니다. Linux 배포판이나 장기 지원 사업자가 패키지에 통합한 수정 사항(백포트) 역시 별도로 구분됩니다. 공식적으로는 배포판과 LTS 사업자에게 사전에 패치를 전달했다고 명시되어 있습니다. Ubuntu, Red Hat, Debian, 국내 렌털 서버들이 원고를 작성한 10월 22일 현재 어떤 패키지를 배포 완료했는지는 개별적으로 확인하고 있으며, 배포 완료 연락이 오는 대로 “우리는 괜찮다”고 답변하지 않습니다. 서버 회사의 안내 또는 계약 중인 관리 화면이 해당 확인처입니다. Amazon Linux는 AWS가 10월 22일을 기준으로 업데이트 패키지를 배포할 예정이라고 10월 21일 게시글에 작성되어 있습니다. 배포 후 적용 상황은 아직 확인되지 않았습니다.

자원봉사 운영 중인 rpms.remirepo.net은 공개 당일에 업데이트가 없을 수 있다는 경고를 PHP 공식이 했습니다. 또한 배포의 패키지나 소스 빌드 전환을 권고하고 있습니다.

## 워드프레스는 위험한가요?

워드프레스 자체 사용이 이번 결함의 원인이 아닙니다. 하지만 워드프레스를 구동하는 PHP 버전이 오래되었고, 외부 요청을 받고 있다면 해당 시스템의 핵심 부분에 문제가 있습니다. 관리 화면 본체와 플러그인이 최신 버전이라도 PHP 8.5.11, 8.4.26, 8.3.35, 8.2.34 버전까지 사용 중이라면 이번 수정 사항은 적용되지 않았습니다. PHP 8.1 이전 버전은 PHP 프로젝트의 일반적인 수정 릴리스가 존재하지 않습니다.

워드프레스는 콘텐츠와 설정을 모두 데이터베이스에 저장하고, 페이지를 열 때마다 PHP 코드를 조합하여 실행합니다. 테마나 플러그인은 이 PHP 위에서 작동합니다. 따라서 PHP 자체의 취약점은 워드프레스 사용자에게 그대로 전달되지만, 이는 워드프레스 자체의 취약성 번호와는 다릅니다. 플러그인의 방치는 오랫동안 존재해 온 또 다른 경로입니다. 이번 논의와 플러그인 업데이트 미뤄진 문제는 모두 ‘워드프레스가 잘못했다’는 식으로 단순화할 수 없으며, 두 가지 모두 발생할 수 있지만 해결해야 할 부분은 다릅니다.

워드프레스 관리 화면에서 코어(WordPress)나 플러그인을 업데이트해도 서버에 저장된 PHP 프로그램은 변경되지 않습니다. 관리 화면의 업데이트는 워드프레스 파일에 대한 것이고, PHP 업데이트는 서버 회사 관리 화면이나 직접 서버를 가지고 있다면 해당 OS 패키지에 대한 것입니다.

버전의 모습은 다음과 같습니다.

워드프레스 관리 화면에서 “도구” → “사이트 헬스” → “정보” → “서버” 메뉴로 들어가면 PHP 버전이 표시됩니다. 이는 웹으로 실행되는 PHP와 가장 가까운 형태로 나타납니다. SSH를 통해 서버에 접속하여 `php -v` 명령어를 실행한 결과는 명령어를 위한 PHP일 수 있습니다. 숫자가 두 개로 표시되는 경우, 웹 측 PHP가 우선 적용됩니다.

렌털 서버의 경우, 이용자가 PHP를 직접 컴파일하는 계약은 드물다. 관리 패널에 “PHP 버전”을 전환할 수 있는 회사도 있지만, 회사 측에서 모아서 업그레이드해 주는 회사도 있다. 원고를 모으는 10월 22일 기준으로, 국내 어떤 회사가 업그레이드를 완료했는지 목록은 이 기사에서는 확인되지 않았다. 보려는 것은 서버 회사로부터의 이메일, 관리 화면의 공지, 사이트 헬스 버전의 세 가지이다. “렌털 서버라서 자동으로 업그레이드가 되었다”는 것은 이 세 가지가 모두 일치할 때까지 기다리지 않는다. 오키나와 회사 사이트에서도, 여기가 빈 칸으로 남은 채 주말에 들어가는 사례를 나는 여러 번 목격한다.

제작 회사에 문의할 때는 다음 사항들을 한 문장씩으로 충분합니다. 웹에서 실행되는 PHP 버전은 무엇인가요? 누가 그것을 업데이트하는 계약을 맺고 있나요. 이번에 8.5.12, 8.4.27, 8.3.36, 8.2.35 또는 벤더의 백포트를 언제 적용할지 알려주세요. 적용한 후에는 관리 화면, 폼, 예약 페이지가 열릴 때 누가 확인하나요. 로그인 정보를 채팅으로 전부 보내줄 필요는 없습니다. 버전, 업데이트 담당자, 날짜가 회신되면 대화는 진행될 것입니다.

회사의 웹사이트가 이 PHP 위에 올라가 있는지 확실하지 않은 경우에는 화면을 조작하기 전에 제작 회사나 서버 회사에 문의하는 것이 안전합니다. PHP 업데이트 상황이나 서버를 누가 확인하는지도 모호한 채로 관리 화면의 버튼을 누를 필요가 없습니다. 상담은 ‘문의하기 - 무료 상담’을 통해 받을 수 있습니다. 보안 완전 검사를 약속하는 페이지가 아니지만, 현재 사용 중인 PHP와 업데이트 담당자를 함께 확인하는 통로가 되어줍니다. 宜野湾이 본점이며, 전국은 대면으로, 해외는 온라인으로 상담하고 있습니다.

WordPress를 오랫동안 게시할 때의 유지보수 이야기는, 오키나와 현의社長님의 WordPress 유지보수에 대한 업데이트와 백업 방식에 대한 내용을 다루고 있습니다. 제작 방법 자체는 WordPress 제작입니다.

## PHP를 사용하지 않는 사이트도 위험한가

PHP라는 소프트웨어가 컴퓨터 어딘가에 존재하고, 인터넷을 통해 그 PHP에 요청이 도착하는 것은 서로 다른 문제입니다. 요청이 도착하지 않는다면 이번 안내의 주요 대상이 아니며, 요청이 도착한다면 웹사이트 디자인이 HTML로 처리되느냐 여부도 고려 대상이 될 수 있습니다.

정리해보면 다음과 같습니다.

상태, 이번 공지 내용과의 거리 PHP가 설치되어 있는 것만으로는 웹에 전달되어 있지 않다면, 공식에서 말하는 “요청을 처리하는 PHP”가 아니다. 다만 잊어버린 .php 파일이 공개 디렉토리에 남아있지 않은지 별도로 확인해야 한다. PHP-FPM이 실행되고 있으며, 웹 서버가 그곳으로 요청을 전달하는 대상이다. Nginx이든 Apache이든, 전달된 대상이 PHP라면 같은 Apache에서 mod_php가 활성화된다. 공식에서 위험이 가장 높다고 언급한 구성이다. 애플리케이션 코드의 앞에 성립할 수 있는, 즉 실증적인 사례가 여기에 있다. HTML, CSS, JavaScript만으로 PHP로 전달되는 설정이 없는 그 배포 경로에 대해서는 이번 PHP의 약점을 간과한다. 호스팅의 별도 설정으로 PHP가 활성화되면, 그곳에는 WordPress를 정적 HTML로 작성했지만, 원래 WordPress가 같은 서버에서 살아있는 HTML은 PHP를 고려하지 않는 경우가 있다. 관리 화면이나 xmlrpc.php 등이 남아있다면, PHP 측에서는 PHP를 실행하지 않는 정적 호스팅 요청이 PHP에 도달하지 않기에, 이번의 주요 대상에서 제외된다. 폼의 전송 대상이 다른 PHP라면, 그 전송 대상은 별도로 확인해야 한다.

정적 사이트로 전환하면 이번 문제가 해결될 것입니다. 배포 방식에서 PHP가 제외되었는지 확인해야 합니다.

## 지금 즉시 시행해야 할 대책

업데이트가 핵심입니다. 설정 변경과 WAF는 업데이트 전 시간을 벌기만 하고, 결국에는 구멍은 막을 수 없습니다. 제 입장이었다면, 오늘 안에 버전을 보고 수정 가능한 부분을 바로 수정하고, 수정 불가능한 경우에는 “누가 언제 수정할 것인지”를 오늘 바로 알려드리겠습니다. 권한이 없는 사람이 관리 화면을 억지로 만져서 고친 것처럼 속이는 일은 하지 않겠습니다.

일반적인 경우의 순서는 다음과 같습니다.

- 저희 회사 홈페이지가 워드프레스인지, PHP인지, HTML인지 등을 제작 회사와 서버 회사에 문의합니다.
- 웹에서 실행 중인 PHP 버전을 사이트 건강 정보 또는 서버 회사 안내에서 확인한다.
- 8.2부터 8.5까지라면 공식 수정판 이상인지, 서버 회사에서 “처리 완료” 안내가 있는지 확인하고, 8.1 이하라면 백포팅 가능 여부 및 PHP 버전 상승 가능성을 문의한다.
- 본인만 서버를 직접 다룰 수 있는 사람이 비효율적인 PHP 실행을 중단하는 판단을 내린다. 로그인할 수 없는 사람은 여기서 멈추고 맡기는 것이 타당하다.
- 문의 양식이나 관리 화면의 URL이 의도치 않게 공개된 상태로 남아있는지, 알고 있는 사람들에게 확인을 요청한다.
- 사이트에서 갑자기 익숙하지 않은 광고가 나타나거나, 자신이 쓰지 않은 페이지가 올라오는지 확인한다. 시각적으로는 평범해 보일지라도, 침입 여부를 증명하는 것은 아니다.
- 백업은 언제, 누구의, 어떤 세대의 데이터를 보존하고 있는지 문의한다.
- WAF는 업데이트까지의 지원을 위해 서버 회사에 설치 여부를 확인하고, 업데이트를 완료한 후에도 계속 사용할 것이다.
- 업데이트 후, 탑, 폼, 예약, 관리 화면 로그인 페이지를 확인해 보세요.
- 이번 달을 마무리하지 않고, 매달 버전을 확인하는 담당자를 한 명 정한다.

자체적으로 서버를 관리하는 사람들의 작업은 공식적인 SAPI(PHP-FPM, mod_php, CGI, FrankenPHP, LiteSpeed)의 재고 조사와 더불어, 인터넷상에 떠도는 정보에서 파생된 업데이트를 의미합니다. 수정 사항은 PHP 공식 버전과 OS 벤더 패키지를 혼합하지 않고 읽어 분석합니다. `php -v` 명령이나 웹의 `phpinfo` 결과, 또는 사이트 헬스 상태가 다를 경우 웹 측 문제일 가능성이 높습니다. 임시 설정은 풀(pool)이나 Apache 설정에서 애플리케이션으로 덮어쓰지 못하는 위치에 배치하는 방식으로 공식적으로 권장됩니다. 워커 프로세스의 재시작까지는 효과가 나타나지 않으며, 임시 조치조차 효과가 없다면 문제를 해결할 때까지 인터넷 연결을 중단하는 방안도 고려될 수 있습니다. 이에 대해 NCSC는 또한 중단 여부는 매출 및 공지 효과를 보고, 권한이 있는 사람이 결정하는 문제입니다.

이미 손상되었을 가능성이 있다는 판단은, 이 기사만으로는 할 수 없습니다. 익숙하지 않은 관리자 사용자, 알 수 없는 파일, 야간의 대량 POST, PHP 프로세스가 셸을 실행하고 있는 등과 같은 징후는 CISA도 “의심스러운 움직임으로 확인해 줄 것을 요청”했습니다. 징후가 있을 때는 먼저 백업을 덮어쓰지 않는 것이 안전합니다. 삭제하기 전에, 보게 되는 사람에게 남겨두는 것이 좋습니다. 전부 삭제하고 “정상”으로 되돌리면, 진입점이 남게 됩니다.

## 홈페이지를 장기간 방치하면 어떤 것들이 쌓이는가

입구가 여러 단으로 늘어난다는 의미입니다.

워드프레스 본체 업데이트가 멈추면 본체 측에서 고친 불具合가 남아 있습니다. 플러그인과 테마는 작가가 업데이트를 중단한 순간, 고치는 사람이 없는 코드입니다. PHP 지원 종료는 언어 자체에 수정이 오지 않는 단계입니다. 이번에 8.1 이전이 바로 그 단계에 있습니다.

관리자 계정을 퇴사한 담당자의 이메일 주소로 그대로 두면 비밀번호 재설정 및 서버 회사에 대한 본인 확인이 중단됩니다. 백업이 “어딘가에 있는 걸로” 예상하고 나중에 고장난 것을 복구할 곳이 없게 됩니다. 부정 접속을 알아차리는 데 시간이 늦어지면 변조된 내용이 검색 결과에 나타날 수 있으며, 검색 엔진은 위험한 페이지에 경고를 표시할 수 있습니다. 고객 문의 내용이나 예약 시 개인 정보가 같은 서버에 저장된 경우 유출 상담처는 사이트 디자인을 수정하는 사람과 별도로 개인 정보 담당 부서가 됩니다. 이는 일반적인 상황입니다. 이번에 발생한 2건의 일본 고객 정보 유출 사고에 대한 확인은 아직 이루어지지 않았습니다.

이번 취약성의 근본적인 원인은 PHP를 웹에 노출하는 한도 내에서 워드프레스를 아무리 깨끗하게 정리해도 본체의 데이터 처리 방식이 오래된 경우 데이터가 제대로 전달되지 않는다는 점입니다. 근본적인 원인이 아니라는 점은 방치된 플러그인, 약한 비밀번호, 백업 미비 등의 문제입니다. 이 두 가지는 같은 두려움의 표현으로 섞어서 말하지 않습니다.

저렴한 가격으로 배송한 후 업데이트 책임이 비어있는 구조는 워드프레스의 저렴한 제작과 이후 발생하는 비용에 대해 언급하고 있습니다.

## 홈페이지 관리자가 없을 때

권한 없는 사람이 복구를 시도하며 로그인을 반복하는 이야기가 아닙니다. 우선 확인되는 것은 작동이 아닌 계약의 존재입니다.

흔히 발생하는 문제는 제작사와 유지보수 계약을 체결하지 않은 경우, 담당자가 퇴직한 경우, 제작사가 문을 닫은 경우, 워드프레스에 접속할 수 없는 경우, 서버 계약 번호가 불확실한 경우, 도메인 갱신 이메일이 누구의 수신함인지 모르는 경우, PHP 업로드 방법을 모르는 경우, 수년간 게시물을 작성하지 않은 경우입니다. 이러한 상태에서 ‘일단 관리 화면 비밀번호를 여러 번 시도해 본다’는 것은 잠금만 설정할 뿐이며, PHP는 여전히 오래된 상태로 남아있습니다.

먼저 종이나 메모에 남겨두는 것은 다음과 같습니다. 도메인 이름, 서버 회사 이름(청구 이메일, 신용카드 상세 내역에 자주 남아있습니다), 도메인 관리 회사 이름(서버 회사와 다를 수 있습니다), 워드프레스에 최종적으로 업로드한 사람의 이름, FTP나 관리 화면에 대한 메모가 퇴직자의 PC에 남아있는지 확인합니다. 사이트의 목적(명함 대용인지, 예약인지, 채용인지)을 확인합니다.

전문가에게 의뢰하는 작업은 그 다음 단계입니다. 로그인 복구, PHP 버전 확인, 업데이트 가능 여부 확인, 백업 유무 확인, 불필요한 PHP 중단 확인, 폼이 작동하는지 확인 등의 작업이 필요합니다. 관리 권한이 없는 상태에서 외부인이 마치 마법처럼 접속하는 것은 불가능하며, 계약자 본인 확인은 서버 회사로부터 요청됩니다. 이 단계를 건너뛰라는 요청은 받아들여도 진행될 수 없습니다.

제작 회사와의 협력 없이도 상담 자체는 받고 있습니다. 관리의 위치를 정리하고 업데이트가 가능한 상태로 되돌리는 것까지가 WEBCRAFTS의 작업 범위입니다. 문의는 ‘문의 및 무료 상담’을 이용해 주세요. 요금은 로그인 가능 여부, 서버 계약 정보, 예약 기능 유무에 따라 달라지므로, 이 기사에서는 금액을 언급하지 않습니다. 이노우야 지점에서 청구서와 도메인 이름만 가지고 방문하셔도 됩니다.

## 워드프레스를 그만두고 정적 사이트로 전환하는 것이 좋을지 고민해 보십시오.

이전하는 것이 좋을 사이트와 워드프레스 그대로 유지하는 것이 좋은 사이트가 모두 있습니다. 이번 취약점을 정적화의 강제 이유로 삼지 않습니다.

보안만 놓고 보면 페이지를 열 때마다 PHP와 데이터베이스가 작동하지 않는 구성이 이번처럼 언어 자체의 문제는 간과하게 됩니다. 유지 비용은 업데이트에 드는 노력이 줄어들거나 콘텐츠 발행 절차가 달라질 수 있습니다. 표시 방식은 완성된 HTML을 전달하는 것뿐이므로 빠르기 때문에 쉽게 적용할 수 있습니다. SEO는 URL, 제목, 본문, 검색에 적합한 안내 문구를 옮기면 유지하는 경우가 많습니다. URL을 변경하거나 본문을 줄이면 문제가 발생합니다. 속도가 순위를 보장하는 것은 아닙니다.

이 형태는 정적 HTML만으로는 이메일을 받을 수 없습니다. 외부 폼 서비스나 별도의 수용구가 필요합니다. 블로그를 일주일에 여러 개 발행하고, 회원만 볼 수 있는 페이지가 있다면, 재고와 연동되는 경우, 관리 화면이 남는 워드프레스가 더 편리한 경우가 많습니다. 초기 비용은 정적으로 다시 만드는 것보다 유지보수를 계속하는 데 더 앞서게 됩니다. 장기간 운영 시에는 플러그인 충돌이 줄어드는 대신 폼이나 예약 연결을 직접 관리하는 비용이 발생합니다.

정적 사이트를 구축하는 도구에는 Astro, Hugo, Eleventy 등이 있습니다. Astro는 필요한 페이지를 먼저 HTML로 묶고, 필요한 곳에만 프로그램을 삽입하는 방식의 도구입니다. 저는 정부기관의 사이트나 대규모 사이트까지 Astro로 제작해 왔습니다. 기관명이나 회사명은 공개가 허락된 것들만 노출됩니다. 여기서 그 성과를 언급하는 것만이 합리적입니다. Hugo와 Eleventy 역시 먼저 HTML을 만드는 방식입니다. 제가 납품하는 정적 기반은 Astro입니다. Hugo와 Eleventy를 항상 동일한 조건으로 납품한다고 말하지 않습니다.

세 가지 선택 방법을 동일한 조건에서 제시합니다.

WordPress를 계속해서 PHP, 본체, 플러그인, 백업을 확인한다. 업데이트 담당자가 회사 내에 있는지 외부인지 확인하고, 예약이나 회원이 있다면 여기에서 솔직하게 진행한다. 이번 문제는 PHP만 올려도 충분하다. 올리는 사람이 없다면 유지보수 계약이 우선이다.

현재 워드프레스를 정적 HTML로 작성하는 방법입니다. 외관과 URL을 크게 바꾸고 싶지 않을 때의 임시 방안입니다. 작성 후 원본 워드프레스를 동일한 공개 영역에 남기면 PHP 코드가 남아 있습니다. 이를 중단하는 것이 작업의 끝입니다.

정적 사이트 형태로 구성부터 다시 만들어야 합니다. 페이지 수가 읽히고, 업데이트는 간단한 안내 수준으로, 속도와 업데이트 누락을 줄이고 싶을 때 고려해볼 만한 선택입니다. 초기 재구성 비용은 발생합니다. 전환에 대한 접근 방식은 워드프레스와 아스트로의 역할 분담에 대해 조건에 기반하여 작성했습니다. 宜野湾(요나와)에서의 제작 시작점은 ‘홈페이지 제작 宜野湾’입니다.

## 정적 사이트라면 더 이상 볼 필요가 없을 수 있습니다.

볼 필요가 없습니다. 그것은 PHP와 데이터베이스를 매번 사용하는 공격의 문제일 뿐입니다. 남은 것은 별도의 관리 문제입니다.

호스팅의 공개 설정을 잘못하면 테스트 중인 페이지가 외부에서 보일 수 있습니다. 도메인과 DNS의 업데이트를 중지하면 사이트는 정상 작동하지만 이름이 만료될 수 있습니다. 외부 JavaScript(접근 분석, 예약 위젯, 채팅)는 제공 업체의 변경 시 자신의 HTML이 정확하더라도 표시나 정보 처리 방식이 달라질 수 있습니다. 폼 서비스는 송신 계정이 퇴사자의 상태로 남아있는 등의 문제가 발생할 수 있습니다. Astro 등으로 제작하는 경우, 컴포넌트 라이브러리에 문제가 발생할 수 있습니다. 사이트 본문이 정적이라도 컴포넌트 업데이트는 남아있습니다. GitHub 등의 계정, 공개 권한, 백업, 변조 여부 확인, 누락된 파일 확인 등도 필요합니다. 이는 정적화했더라도 누군가의 작업입니다.

“정적 설정으로 인해 보안이 종료되었다”는 주장은 PHP의 문제를 다른 취약점으로 치환한 것에 불과합니다.

## 웹사이트 확인 시 무엇을 살펴봐야 할까요

외부에서 보이는 것과 관리자만 볼 수 있는 것은 섞지 않습니다. 가격 정보는 이 게시물에 없습니다. 정가를 공표하는 페이지로 메뉴를 정해놓고 있는 WEBCRAFTS 페이지도 현재 WEBCRAFTS에는 존재하지 않습니다.

외부에서는 HTTPS로 설정되어 있거나, 인증서 만료일이 남아 있거나, 관리 화면 URL이 쉽게 찾을 수 있거나, 낡은 워드프레스 화면이 나타나지 않는 경우에만 접속이 가능합니다. PHP 버전 정보는 정확한 버전이 나타나지 않을 수도 있지만, 그렇지 않은 경우가 훨씬 많습니다. 단순히 최신 버전이라는 것을 판단할 수는 없습니다.

관리자의 권한이 없으면 알 수 없는 것은 PHP의 정확한 버전, 플러그인 및 테마 목록과 업데이트 날짜, 관리자 사용자 수, 백업 세대, 서버 로그, WAF 유무입니다. 보안 헤더(브라우저에 “이 사이트는 이렇게 읽습니다”와 전달하는 응답 부가 정보)는 응답을 보면서도 외부에서 확인할 수 있지만, 수정하는 것은 서버 측에서 담당합니다.

가벼운 확인은 “어떤 버전이고, 누가 업데이트를 담당하는지”를 구분하는 대화입니다. 자세한 확인은 로그, 계정, 백업, 공개 금지 파일까지 권한을 얻어 검토하는 작업입니다. 후자에 대해서는 전자의 가격으로 약속하지 않으며, 완전히 안전하다고 말하기는 어렵습니다. 확인된 범위와 확인되지 않은 범위를 문서로 기록하는 것이 확인의 업무입니다.

## 수정 후에도 남은 일

이번 PHP는 수정된 버전으로 올리면 이 두 건에 대해서는 공식적으로 수정이 적용된 상태가 됩니다. 그 다음 달에는 다른 플러그인의 문제점도 자연스럽게 발생합니다. 홈페이지는 공개한 날에 완성되어 이후에는 간판처럼 굳이 유지하는 물건이 아닙니다. 간판의 뒤편에서 PHP와 SSL 인증서, 도메인, 문의가 접수되는 곳이 매달 누군가에게 확인되어야 합니다.

저는 기여와에서 홈페이지를 제작하고 공개된 후 “업데이트는 누가 할 건가”라는 질문이 비어 있는 채로 돌아오는 현장을 여러 번 보았습니다. 이번에는 그 질문이 언어의 본질까지 닿은 시점입니다. 이미 일본 전역에서 진행되고 있다는 점은 언급하지 않습니다. CISA는 공개된 시점에서는 악용을 관측하지 않고 있습니다. 반면에 CERT-EU는 실증 코드가 유통되기 시작했다고 보고 있습니다. 관측의 실마리를 기다렸다가 움직이는 것이 아니라, 저는 그렇게 생각합니다. 모든 것을 정적으로 유지할 필요는 없습니다. 정적이 잘 어울리는 사이트는 잘 맞습니다. 워드프레스 그대로 PHP를 올려 매달 방문자를 결정하는 것이 더 적합한 사이트도 많습니다. 어느 쪽이든 이번 주 PHP를 비워둔 채로 업데이트하지 않는 것이 우선입니다.

안전성 확인, 그 이후 유지보수, 필요하다면 정적 구조로 전환하는 것은 다른 상품 세 가지를 판매하는 이야기가 아니라, 동일 사이트의 ‘다음 달에도 누가 방문할지’에 대한 답변입니다. 현재 사이트를 유지하는 것이 좋을지, 관리 노력을 줄이는 구성으로 바꾸는 것이 좋을지는 예약 및 업데이트 빈도를 확인한 후에 결정합니다. 문의는 상담 문의 또는 무료 상담을 이용해 주세요. 도외 지역에서도 화면 공유를 통해 버전별 읽기 방식에 대해 논의할 수 있습니다.

## 자주 묻는 질문

### 이번 PHP 취약점은 무엇인가요?

2026년 10월 21일에 공개된 PHP 본체의 2건의 보안 취약점입니다. 번호는 CVE-2026-109618과 CVE-2026-109619이며, CVSS v4.0 기준으로 각각 9.2의 심각도를 나타냅니다. PHP에서 웹 요청을 처리하며, 인증 없이 원격 코드 실행으로 이어질 수 있다는 점을 PHP 공식이 밝혔습니다.

### 워드프레스는 위험한가요?

워드프레스 본체에 결함이 있는 것이 아니라, 워드프레스가 실행되는 PHP 버전이 오래되었고 외부 요청을 받는 경우에 해당됩니다. 새로운 PHP 버전에서는 이번 2건에 대해 공식적인 수정 사항이 적용된 상태입니다. 플러그인의 방치는 별도의 문제로 남아 있습니다.

### 워드프레스를 최신 버전으로 업데이트하면 안전해질까요?

이번 두 건에 대해서는 부족합니다. 워드프레스 업데이트는 워드프레스 파일을 교체하는 작업이며, PHP 프로그램은 서버 측 업데이트입니다. 두 작업을 서로 다른 담당의 업무로 구분합니다.

### PHP를 사용해 보지 않았다면 어떤 문제가 있을까요?

해당 웹사이트에 대한 요청이 PHP로 전달되지 않았다면 이번 공지사항의 주요 대상이 아닙니다. 동일한 계약의 서버에서 PHP가 활성화되어 있고, 워드프레스가 백업 파일로 저장되어 있으며, 폼 제출 주소가 PHP로 설정되어 있다면 이는 별개의 문제입니다.

### PHP가 설치되어 있다고 해서 위험한가요?

공식에서 우려하고 있는 것은 웹 요청을 처리하는 PHP입니다. 들어있는 것만으로는 외부에서 실행할 수 없도록 상태를 변경하는 것이 위험한 것입니다. 공개 폴더에 PHP 파일이 남아있는지 여부는 별도의 확인 사항입니다.

### HTML만으로 만드는 정적 사이트는 안전한가요?

PHP로 처리하지 않은 배포는 이번 문제를 일으키지 않습니다. 절대 안전하다고 보장할 수 없습니다. 인증서, 도메인, 외부 스크립트, 폼, 계정, 백업은 그대로 유지됩니다. 자세한 내용은 “정적 사이트라면, 이제 더 볼 필요가 없는 걸까요?”에 자세히 설명되어 있습니다.

### PHP 버전은 어디에서 확인할 수 있나요?

워드프레스에서는 관리 화면의 “도구” → “사이트 헬스” → “정보” → “서버”에서 확인할 수 있습니다. `php -v`와 같은 명령어를 실행하면 웹과 다르게 작동할 수 있습니다. 렌털 서버는 회사 관리 화면과 정보를 통합하여 제공합니다.

### 렌탈 서버 이용자도 대책이 필요한가요?

필요합니다. 이용자가 손을 넣는 범위는 회사마다 다릅니다. 공지사항을 읽고, 사이트 헬스의 버전이 수정판 미만이라면, 회사나 제작사에 “언제 업데이트될지” 문의하는 단계입니다. 자동으로 올라갔다고 생각하는 것은 빠릅니다.

### 홈페이지 관리자가 없는 경우, 어떻게 해야 할까요?

비밀번호를 계속 입력하는 것은 단순히 잠금만 설정하는 것일 뿐이며, PHP는 여전히 오래된 상태로 남아있습니다. 먼저 남는 것은 도메인 이름, 서버 회사, 도메인 관리 회사, 그리고 마지막으로 터치한 사람입니다. 계약자 확인이 불가능하면 내부 업데이트는 시작되지 않습니다. 정리 관련 문의는 문의를 통해 받고 있습니다.

### WordPress를 정적 사이트로 변경할 수 있나요?

할 수 있는 사이트와 중단하는 것이 좋은 사이트가 있습니다. 회원 관리, 예약 기능, 그리고 자주 업데이트되는 콘텐츠가 있는 경우에는 워드프레스 유지보수를 하는 것이 더 적절한 경우가 많습니다. 다만, 단순한 안내 정도라면 정적 사이트로 전환하는 것을 고려해볼 수 있습니다. 원본 PHP 코드를 그대로 남겨두고 작성하면, 이번에 대상이 되는 콘텐츠는 남아있게 됩니다.

### 정적 사이트에서도 SEO는 유지할 수 있습니까?

URL, 제목, 본문, 안내문을 보존하면 유지할 수 있는 경우가 많습니다. 순위 보장은 하지 않습니다. 이전 시 주소를 변경한다면 기존 주소에서 이전하는 것이 필요합니다. 속도만 올리는 것은 내용이 부족하면 평가에 별다른 영향을 주지 않습니다.

### 웹사이트 보안 진단에서는 무엇을 확인하시겠습니까?

겉으로는 HTTPS, 인증서, 낡은 화면, 그리고 남아있는 설치 파일이 보입니다. 내부에는 PHP 버전, 플러그인, 관리자, 백업, 로그 등이 있습니다. WEBCRAFTS는 이 게시글 작성 시점 기준으로 진단 비용을 청구하지 않고 있습니다. 견적은 먼저 확인 범위를 정한 후, 개별적으로 산정됩니다.

### 홈페이지의 유지보수를 외부로 위탁할 수 있나요?

가능합니다. 위탁하면 업데이트 담당자가 비어있지 않게 되기 때문에 이것이 핵심입니다. 매달 무엇을 해야 하는지 쓰지 않는 계약은 단순히 저렴할 뿐이고 내용이 보이지 않습니다. 백업, PHP와 본체 및 플러그인, 폼 도달률이 세 가지가 최소한입니다.

### 이번 취약성으로 인해 실제로 피해가 발생하고 있나요?

CISA는 10월 21일 기준으로 악용 사례를 관측하지 않았다고 보고 있으며, CERT-EU는 실증 코드가 유통되기 시작했다고 보고 있습니다. 관측, 실증 코드, 침해 확인은 별개의 문제입니다. 일본 내 피해 발생 여부는 10월 22일 원고 작성 시점까지 확인되지 않았습니다. 확인되지 않았다는 것은 서둘러 대응할 필요는 없다는 의미입니다.

### 앞으로 어떤 정보에 주의해야 할까요?

PHP 공식 수정본, 제 서버 회사의 “처리 완료” 업데이트, CISA 등이 발행하는 “악용 감지” 업데이트입니다. PHP 8.2는 2026년 12월 31일부로 보안 업데이트가 종료된다고 공식적으로 명시되어 있습니다. 올해 안에 이 내용이 논의될 예정입니다.

## 참조된 공개 정보

확인일은 2026년 10월 22일입니다.

- PHP 공식 뉴스 2026 (보안 공지 및 수정 버전)
- PHP 재단(검증된 실행 방식의 정리)
- CISA(php2shell이라는 명칭, 공개 시점 당시에는 악용 사례가 관측되지 않음)
- 영국 NCSC
- IPA 사전 준비 요청(공개 전 안내, 영향 버전은 당시 불확실)
- ENISA의 다른 공동 성명
- CERT-EU 2026-018 (실증 코드 유통 관련 언급)
- Google Cloud(영향 범위 명확화)

미결산 상태로 남아있는 정보들. NVD의 개별 페이지 점수 내역, JPCERT/CC와 JVN의 이 두 건의 개별 공지, 국내 렌털 서버 각사의 대응 완료, 10월 22일 이후의 악용 관찰, WordPress.org 자체의 성명입니다. 게시물을 찾지 못했다는 것을 “존재하지 않는다”고 쓰지 않습니다.

대상 범위를 초과했습니다. 이 기사는 자사 서버의 침입 조사 절차서가 아닙니다. 개별 사이트가 침해되었는지 여부는 로그와 권한이 없이는 판단할 수 없습니다.

오키나와 홈페이지 제작 공방 WEBCRAFTS, 오키나와현 이노바시 이자 2-20-15 이자 빌딩 2F, 문의 및 무료 상담 (스즈키 타카마사)

『해리 포터와 저주받은 자식』 출간 10주년, 그 인기는 쇠퇴할 새 없이 더욱 새로운 팬층을 양성하고 있다. 특히, 원작을 읽지 않은 층からの流入이 顕著하다. 이는 영화 시리즈의 인지도와 어린이 문학계에서 ‘해리 포터’ 시리즈의 위상이 여전히 높다는 것을 보여준다.

또한, 최근 어린이 문학 작품의 주제가 다양화되고 있는 것도 이 작품의 인기를 지탱하고 있다. 빈곤, 차별, 환경 문제 등 아이들이 직면하는 현실적인 문제들을 제기하고 독자에게 질문을 던짐으로써 아이들의 성장을 촉진하는 역할을 수행한다.

‘해리 포터와 저주받은 자식’ 출간 10주년이라는 시점에 그 영향력은 어린이 문학계 전체에까지 미치고 있다. 이 작품이 어린이 문학의 새로운 흐름을 이끌고 다양한 주제를 다루는 작품들이 잇따라 등장하는 것은 변명할 필요가 없다.

더욱이, 이 작품의 성공은 출판계에도 큰 영향을 미쳤다. 어린이 문학의 출판 부수는 역대 최고를 기록하고, 그 인기를 탄로 다양한 출판사들이 어린이 문학에 힘을 쏟고 있다.

#크로스웨이브 #오키나와마인크라부 #마인크라부 #방과후마인크라부 #오키나와e스포츠부 #관공기관 #대기업 #PHP #PHP취약점 #PHP취약점2026 #CVE-2026-109618 #CVE-2026-109619 #php2shell #PHP2Shell #워드프레스 #워드프레스취약점 #워드프레스보안 #워드프레스보안대책 #워드프레스유지보수 #워드프레스유지보수대행 #워드프레스업데이트 #워드프레스정적화 #홈페이지 #홈페이지제작 #홈페이지유지보수 #홈페이지유지보수대행 #홈페이지보안 #홈페이지보안진단 #웹사이트보안진단 #보안진단 #정적사이트 #정적사이트보안 #정적HTML #Astro #Hugo #Eleventy #정적사이트생성기 #PHP-FPM #mod_php #Apache #Nginx #렌탈서버 #사이트헬스 #WAF #백업 #제작회사 #관리자미제 #홈페이지방치 #이노바 #이노바시 #오키나와 #이자와 #WEBCRAFTS #오키나와홈페이지제작공작WEBCRAFTS #주식회사wEVA #WEVA #스즈키코모치 #보안 #CVE #CVSS #정보보안 #홈페이지유지보수 #웹사이트리뉴얼 #SEO #문의하기

**출처:** [note 원문](https://note.com/webcrafts/n/nb4d6cfacc904)

*번역: Gemma 3(.44) 초벌 + 교정 88청크*

[원문 보기](https://note.com/webcrafts/n/nb4d6cfacc904) | 출처: note.com