설명: 웹 서버에서 PHP가 하는 일부터 로그인 우회와 원격 코드 실행의 차이, 위험도 표, 점검과 패치까지 쉽게 설명합니다.
23시에 인터넷이 멈추는 걸까?
2026년 10월 21일 23시(한국시간)는 인터넷이 폭발하는 시각이 아니라 보안 수정판이 나올 예정이던 시각이었다. PHP 공식 수정판은 실제로 공개됐다. 이제 운영자는 '준비'에서 '설치하고 확인'으로 넘어가야 한다.
PHP 자체의 문제이므로 WordPress 관리자 비밀번호를 복잡하게 만드는 것만으로 해결되지 않는다. 일반 방문자는 자신이 관리하지 않는 서버를 고칠 수 없으니 긴급 본인 확인을 사칭하는 메시지에 주의하자.
PHP는 무슨 일을 할까? 온라인 상점의 뒷방 이야기
PHP는 웹 서버에서 실행되는 프로그램 언어다. 고객이 구매 버튼을 누르면 로그인과 재고를 확인하고 가격을 조회하고 주문을 저장하는 일을 맡을 수 있다. WordPress 블로그와 쇼핑몰, 사내 게시판에도 쓰인다. 결제 자체는 다른 업체가 처리할 수도 있다. 화면에 보이지 않는 일꾼이라고 생각하면 된다.
F12를 누르면 PHP 코드를 볼 수 있을까?
Chrome 등의 개발자 도구를 F12로 열면 HTML(페이지 구조), CSS(모양), JavaScript(화면 동작)를 살펴볼 수 있다. PHP는 서버에서 먼저 실행되고 결과만 브라우저로 전달된다. 주방의 요리법은 숨겨지고 접시만 나오는 셈이다.
Network에서 새로고침한 뒤 문서 요청의 Headers를 살펴보자. X-Powered-By: PHP/... 같은 응답 헤더나 .php 주소는 단서가 될 수 있지만, 없어도 PHP를 사용할 수 있다. F12만으로 취약 여부를 판정할 수 없다.
| 기술 | 하는 일 |
|---|---|
| HTML / CSS | 페이지 구조 / 디자인 |
| JavaScript | 브라우저 동작, 서버 개발에도 사용 |
| PHP | 서버의 로그인·조회·기록 처리 |
| Python / Java / Go | 비슷한 서버 작업도 할 수 있는 다른 언어 |
| SQL | 데이터베이스에 질문하거나 데이터를 변경하는 언어 |
| P2P | 컴퓨터끼리 통신하는 방식이지 프로그래밍 언어가 아님 |
SQL은 PHP를 대체하는 언어가 아니라 PHP가 데이터베이스에 정보를 요청할 때 함께 사용할 수 있는 언어다.
공식 발표와 소문의 차이
2026년 10월 22일 확인된 공식 정보: PHP는 10월 21일 두 취약점의 수정판을 공개했다. 각각 CVSS v4.0 9.2/10으로 평가된다. 이 숫자는 침해 확률 92%가 아니다.
| PHP 계열 | 수정된 버전 |
|---|---|
| 8.2 | 8.2.35 |
| 8.3 | 8.3.36 |
| 8.4 | 8.4.27 |
| 8.5 | 8.5.12 |
CVE-2026-109618은 메모리 부족 처리 중 내부 데이터가 잘못된 상태로 남는 문제다. CVE-2026-109619는 이전 요청의 내부 정보가 제대로 지워지지 않아 다음 요청에서 잘못 사용되는 문제다. 두 문제 모두 조건에 따라 로그인하지 않은 공격자의 원격 코드 실행으로 이어질 수 있다. Apache mod_php에서는 애플리케이션 코드가 실행되기 전 공격이 성공하는 사례가 확인됐다. PHP-FPM 등도 점검 대상이다.
PHP 프로젝트는 8.1 이하 버전을 일반적으로 지원하지 않는다. 일부 운영체제·장기 지원 공급업체는 보안 패치를 구버전에 이식하므로 공급업체 공지를 확인해야 한다. PHP 개발팀은 예외적으로 7.4·8.0·8.1용 소스 패치도 제공했다. 8.2의 지원 종료 예정일은 2026년 12월 31일이다.
흥미롭게도 첫 문제의 징후는 2024년에 발견됐다. PHP Foundation은 수정 설계와 인력 부족으로 대응이 지연됐다고 설명한다. 실험에서 공격에 성공했다는 사실과 모든 사이트가 실제로 침해됐다는 주장은 구분해야 한다. 공개 시점에 유통 중인 시연 코드에서 작동하는 공격을 확인하지 못했다는 설명도 이후의 안전을 보장하지는 않는다.
로그인 비밀번호를 건너뛰는 것과 서버 명령 실행은 다르다
인증 우회는 로그인 검사를 속이는 일이고, 원격 코드 실행(RCE)은 서버에서 허가되지 않은 명령을 실행시키는 일이다. PHP 공식은 이번 두 문제 모두 특정 조건에서 로그인 없는 RCE로 이어질 수 있다고 발표했다.
특히 Apache mod_php의 첫 번째 취약점은 WordPress 같은 사이트 프로그램이 시작되기 전에 악용되는 사례가 입증됐다. PHP-FPM도 애플리케이션 경로를 통한 위험이 확인됐다. 실제 피해는 PHP 실행 권한, 데이터베이스 연결, 네트워크 분리에 따라 달라진다.
인터넷 공개와 사내망: 무엇을 먼저 고칠까?
| 상태 | 우선순위 | 이유와 조치 |
|---|---|---|
| 외부 공개 + 미패치 + 개인정보 다량 | 최우선 | 누구나 접근 가능한 경로와 큰 피해 규모: 즉시 패치, 필요 시 차단, 로그 보존 |
| 외부 공개 + 미패치 + 사내 DB 연결 | 최우선 | 공개 사이트가 내부 데이터의 입구가 될 수 있음: DB 권한·연결 제한과 패치 |
| 외부 공개 + 미패치 + 중요 정보 적음 | 높음 | 변조·공격 발판 위험: 업데이트와 불필요한 기능 제한 |
| 사내망 전용 + 미패치 + 기밀 정보 | 높음 | 감염된 직원 PC·VPN을 통한 경로 가능: 패치와 접근 점검 |
| 사내망 전용 + 미패치 + 정보 적음 | 중간~높음 | 다른 시스템으로 이동할 위험: 격리와 업데이트 |
| 패치 완료 + 중요 정보 | 침해 조사 지속 | 패치 이전 침입은 남을 수 있음: 과거 로그 확인 |
| PHP 미사용 확인 | 직접 영향 없음 | 별도 관리 도구와 협력 업체는 확인 |
공개 여부, 데이터 가치, PHP 실행 권한, 다른 서버와의 연결, 업데이트 상태가 겹칠수록 급하다. 사내망이라는 이유만으로 안심할 수 없다.
내 서버가 대상인지 확인하는 순서
PHP 사용 위치 → 실제 웹 서버의 버전 → 공식 영향 버전 → 패치 적용 여부를 확인한다. WordPress는 도구 → 사이트 건강 → 정보 → 서버에서 PHP 버전을 찾을 수 있다. WordPress나 플러그인 업데이트와 PHP 업데이트는 별개다.
호스팅 업체에 맡겼다면 누가 언제 PHP를 업데이트하는지 확인한다. 직접 운영한다면 php -v로 명령줄 버전을 볼 수 있지만 웹에서 사용하는 PHP와 다를 수 있으므로 PHP-FPM·컨테이너·OS 패키지도 점검한다. 남의 사이트에 침입 시험을 해서는 안 된다.
WordPress 업데이트 버튼만 누르면 되나?
수정판 8.2.35 / 8.3.36 / 8.4.27 / 8.5.12가 공개됐다. WordPress 업데이트와 별도로 서버의 PHP를 갱신해야 한다.
WordPress 본체·플러그인 업데이트와 서버의 PHP 업데이트는 서로 다르다. WordPress에서 도구 → 사이트 건강 → 정보 → 서버로 들어가 PHP 버전을 확인하자. 호스팅 이용자는 제공업체의 공식 안내를, 직접 운영하는 관리자는 PHP 설치 위치와 백업·복원 계획을 점검한다.
패치가 공개됐으므로 대상 버전을 대조하고 공식 지침에 따라 적용한 뒤 로그인·게시·문의 양식을 테스트한다. 운영 중인 서버에서 생각 없이 설정을 바꾸는 것은 보안보다 값비싼 운 시험에 가깝다.
패치 전후, 실제로 할 일
수정판 8.2.35 / 8.3.36 / 8.4.27 / 8.5.12가 공개됐다. WordPress 업데이트와 별도로 서버의 PHP를 갱신해야 한다.
수정판 적용 전에는 서버 목록, 책임자, 복원 가능한 백업과 복구 절차를 정리한다. 공식 수정판이 나왔으므로 제공업체 설명대로 실행 중인 PHP를 업데이트하고 필요한 서비스를 다시 시작한다. 로그인, 글쓰기, 주문, 문의 양식, 연동 기능을 시험한다.
즉시 수정하기 어렵다면 외부 접근을 줄이고 데이터베이스 권한을 제한하고 웹 방화벽을 보조적으로 쓴다. 하나의 설정 변경이나 업로드 차단만으로 두 취약점이 모두 해결된다고 믿지 않는다. 피해가 클 수 있다면 일시적인 서비스 중단·격리도 검토한다.
이미 침해되었을 가능성이 있으면 로그와 증거를 보존하고 이상한 계정·파일·통신을 조사한다. 패치는 고장 난 자물쇠를 고치는 일이지 이미 도둑맞은 명단을 되찾는 마법은 아니다. AI 자동화로 공격이 빨라질 수 있어도 모든 사이트가 이미 침해되었다는 뜻은 아니다.
PHP를 안 쓰는 사이트는?
실제로 PHP를 실행하지 않는 정적 웹사이트 또는 JavaScript·TypeScript 서비스는 PHP 자체의 결함에 직접 노출되지 않는다. 그러나 별도 관리 도구나 외부 서비스, 장비 내부에 PHP가 있을 수 있다. Cloudflare를 이용한다고 원본 서버의 PHP까지 자동으로 고쳐지지는 않는다.
어디에 PHP가 있고, 누가 업데이트하며, 이후 어떻게 점검할지만 먼저 정리하자.
평범한 이용자의 할 일
방문자가 다른 회사의 서버를 고칠 수는 없다. '지금 즉시 계정을 다시 인증하라'는 이메일이 와도 링크를 누르지 말고 평소 이용하는 공식 앱이나 웹사이트로 직접 들어가 확인하자.
자주 묻는 질문
PHP를 다른 언어로 바꾸면 되나? 전면 재개발보다 해당 보안 수정판 적용이 우선이다. 다른 언어에도 결함이 있다.
모두 비밀번호를 바꿔야 하나? 이번 발표만으로 일괄 변경할 필요는 없다. 실제 침해 통지가 오면 공식 서비스에서 확인하자.
Cloudflare나 웹 방화벽이 있으면 안전한가? 도움이 될 수 있지만 PHP 자체 패치를 대신하지 않는다.
9.2점은 92% 공격 성공률인가? 아니다. 위험의 심각도를 나타내는 수치다.
결론
정해진 시각은 인터넷 폭발 시간이 아니라 수리 부품의 도착 시간이었다. 부품은 도착했다. 남은 일은 실제 웹서버의 PHP 버전과 수정 여부를 확인하고, 기능 점검과 필요한 침해 조사를 하는 것이다. WordPress만 업데이트한 채 PHP를 방치하면 간판만 새것이고 문고리는 고장 난 가게가 된다. 2026년 10월 22일 01:26 JST 기준.
PHP Security Team, 2026-10-20: https://www.php.net/archive/2026.php#2026-10-20-1
IPA, 2026-10-21: https://www.ipa.go.jp/security/security-alert/2026/pre-alert20261021.html
WordPress documentation: https://wordpress.org/documentation/article/site-health-screen/
Cloudflare Workers languages: https://developers.cloudflare.com/workers/languages/
PHP manual, basic web execution: https://www.php.net/manual/en/tutorial.firstpage.php
Chrome DevTools, Network requests and response headers: https://developer.chrome.com/docs/devtools/network/reference
CERT-EU Security Advisory 2026-018, 2026-10-20/21: https://cert.europa.eu/publications/security-advisories/2026-018/
PHP official support periods: https://www.php.net/supported-versions.php
PHP Security Advisory, 2026-10-21: https://www.php.net/archive/2026.php
PHP Foundation, background and disclosure, 2026-10-21: https://thephp.foundation/blog/2026/10/21/todays-php-security-release-and-how-were-strengthening-php-security/
CVE-2026-109618 (PHP advisory): https://github.com/php/php-src/security/advisories/GHSA-w8hw-w9fx-j79w
CVE-2026-109619 (PHP advisory): https://github.com/php/php-src/security/advisories/GHSA-6wmf-4rv5-p3rp
