PHP 보안 취약점 긴급 업데이트 총정리｜CVE-2026-109618·109619·워드프레스 버전 확인·해킹 위험·해결 방법
위 영상은 워드프레스 PHP 업데이트 절차를 설명하는 일반 안내 영상이며, 이번 취약점 자체의 분석 영상은 아닙니다.
PHP 보안 취약점 2건이 발견되면서 전 세계 웹사이트 운영자들에게 긴급 업데이트 권고가 내려졌습니다. 한국인터넷진흥원(KISA)은 2026년 10월 21일 PHP에서 발생한 CVE-2026-109618과 CVE-2026-109619 취약점에 대한 보안 공지를 발표하고, 영향을 받는 PHP 버전의 즉각적인 업데이트를 권고했습니다.
이번 보안 문제는 일반적인 홈페이지 오류와 다릅니다. 공격자가 로그인이나 관리자 인증 없이 취약한 PHP 서버에 악의적인 요청을 전송하여 임의의 코드를 실행할 수 있는 원격 코드 실행(RCE) 취약점이기 때문입니다.
특히 PHP는 워드프레스, 온라인 쇼핑몰, 기업 홈페이지, 게시판, 다양한 웹서비스에서 사용하는 서버 측 프로그래밍 언어입니다. PHP 자체의 취약점이기 때문에 영향을 받는 범위가 상당히 넓습니다.
더욱 주의해야 할 점은 워드프레스 관리자 비밀번호를 바꾸거나 보안 플러그인을 설치하는 것만으로 이번 PHP 취약점을 완전히 해결할 수 없다는 사실입니다. 서버에서 실행되는 PHP 버전 자체를 보안 패치가 적용된 버전으로 업데이트해야 합니다.
그렇다면 내 홈페이지는 안전할까요? PHP 버전은 어디에서 확인하고, 워드프레스·카페24·티스토리 운영자는 각각 어떻게 대처해야 할까요? 이번 글에서는 공식 발표 내용과 실제 점검 방법을 함께 정리했습니다.
- 발표일: 2026년 10월 21일
- 발견된 취약점: CVE-2026-109618, CVE-2026-109619
- 심각도: CVSS v4.0 기준 각각 9.2점(Critical)
- 주요 위험: 인증 없는 원격 코드 실행, 민감한 메모리 정보 노출 가능성
- 패치 버전: PHP 8.2.35, 8.3.36, 8.4.27, 8.5.12
- 구버전: PHP 8.1 이하 공식 보안 지원 종료
- 긴급 조치: 버전 확인 → 백업 → 호환성 점검 → 업데이트 → 이상 징후 점검
- 공식 문의: KISA 사이버민원센터 118
1. PHP 보안 취약점 긴급 경고, 무엇이 발생했나?
2026년 10월 21일 PHP 개발팀은 두 건의 심각한 취약점을 해결한 긴급 보안 업데이트를 공개했습니다. 한국인터넷진흥원 역시 같은 날 'PHP 제품 보안 업데이트 권고' 공지를 게시했습니다.
이번에 확인된 문제는 PHP가 메모리 부족 상황이나 이미 해제된 메모리 정보를 처리하는 과정에서 발생하는 결함입니다.
공격자가 취약한 서버에 특수하게 구성된 요청을 보내면 PHP 내부 처리 과정에서 메모리 상태가 비정상적으로 바뀌고, 특정 조건에서 외부 공격자가 원하는 코드가 실행될 수 있습니다.
원격 코드 실행은 단순히 홈페이지 화면을 바꾸는 문제를 넘어섭니다. 악용에 성공하면 해당 PHP 프로세스가 가진 권한 범위 내에서 파일에 접근하거나, 데이터를 변경하거나, 추가적인 악성 프로그램을 실행할 가능성이 생깁니다.
즉 이번 사안은 웹사이트의 디자인 문제나 플러그인 충돌 문제가 아니라 서버에서 프로그램을 실행하는 기반 기술 자체의 보안 문제입니다.
이번 취약점은 보안 연구자들 사이에서 PHP2Shell이라는 이름으로도 알려졌습니다. 다만 PHP2Shell은 두 CVE를 가리키는 별칭이며, 공식적으로 식별할 때에는 CVE 번호를 함께 확인하는 것이 정확합니다.
2. PHP란 무엇이고 전 세계 웹사이트가 위험한 이유
PHP는 웹서버에서 프로그램을 실행해 동적인 웹페이지를 만드는 데 널리 사용되는 프로그래밍 언어입니다.
사용자가 홈페이지에 접속하면 서버의 PHP 프로그램이 데이터베이스에서 필요한 정보를 가져오고, 로그인 상태나 게시글 정보 등을 처리하여 브라우저에 보여줄 화면을 생성할 수 있습니다.
대표적으로 워드프레스, 드루팔, 줌라 등 다양한 콘텐츠 관리 시스템이 PHP를 사용합니다. 오래된 기업 홈페이지나 자체 제작한 쇼핑몰 역시 PHP 기반으로 구축된 사례가 많습니다.
이번 뉴스에 등장한 '전 세계 웹사이트 75%'라는 표현은 PHP 사용률이 매우 높다는 의미로 이해할 수 있습니다. 다만 웹 기술 통계는 조사 시점과 분석 대상에 따라 수치가 다릅니다. 최근 해외 보도에서는 약 69~70% 수준의 수치도 제시됐습니다.
중요한 것은 모든 웹사이트가 무조건 위험하다는 뜻이 아니라, 취약한 PHP 런타임을 사용하는 서비스가 매우 광범위하게 존재할 수 있다는 점입니다.
PHP를 사용하지 않는 정적 HTML 웹사이트나 다른 서버 기술을 사용하는 서비스는 이번 PHP 취약점에 직접 해당하지 않습니다. 반대로 화면이 멀쩡하게 표시되는 웹사이트라도 서버가 취약한 PHP 버전으로 작동하고 있다면 점검 대상입니다.
3. CVE-2026-109618 취약점이란? 예외 상황 처리 오류
CVE-2026-109618은 PHP의 메모리 부족 상황 처리와 관련된 심각한 취약점입니다.
프로그램이 메모리를 확보하지 못하거나 예상하지 못한 오류가 발생했을 때 내부 상태를 적절하게 정리하지 못하면 이후 처리 과정에서 유효하지 않은 메모리 정보를 참조할 수 있습니다.
정상적인 프로그램이라면 요청 처리를 안전하게 중단하고 필요한 자원을 정리해야 합니다. 하지만 특정 오류 처리 경로에서 초기화되지 않은 데이터를 잘못 사용하면 메모리 손상으로 이어질 수 있습니다.
이 취약점이 특히 위험한 이유는 일부 서버 구성에서 로그인하지 않은 외부 사용자의 요청만으로도 취약한 코드 경로에 접근할 가능성이 있다는 점입니다.
이를 악용한 공격이 성공하면 해당 서버에서 임의 코드를 실행할 수 있습니다. 다만 실제 공격 성공 여부와 영향은 서버 구성 및 보안 조치 상태 등에 따라 달라집니다.
이번 취약점은 관리자 계정의 비밀번호가 유출되어 발생하는 일반적인 계정 탈취 사고와는 성격이 다릅니다. 따라서 관리자 비밀번호 변경만으로 근본적인 문제가 해결되지 않습니다.
4. CVE-2026-109619 취약점이란? 해제 후 사용 오류
CVE-2026-109619는 Use After Free, 즉 해제 후 사용과 관련된 취약점입니다.
컴퓨터 프로그램은 작업에 필요한 메모리를 확보하고 사용이 끝나면 그 메모리를 반환합니다. 그런데 반환한 메모리를 가리키는 정보가 적절히 초기화되지 않으면 이후 요청에서 이미 유효하지 않은 데이터를 다시 사용할 수 있습니다.
PHP에서는 요청을 처리하는 동안 사용한 내부 상태가 다음 작업에 영향을 주지 않도록 정리되어야 합니다. 하지만 특정 상황에서 오래된 내부 상태가 남아 있을 수 있다는 문제가 확인됐습니다.
이처럼 메모리 관리 과정에서 발생한 오류는 프로그램 충돌이나 예기치 않은 동작을 일으킬 수 있고, 공격자가 이를 악용하면 코드 실행 등의 보안 문제로 이어질 수 있습니다.
| 구분 | CVE-2026-109618 | CVE-2026-109619 |
|---|---|---|
| 취약점 유형 | 예외·메모리 부족 상황 처리 오류 | 해제된 메모리 관련 상태 재사용 |
| 주요 문제 | 초기화되지 않은 메모리 처리 | 오래된 내부 상태 참조 |
| 예상 영향 | 원격 코드 실행 가능 | 원격 코드 실행·정보 노출 가능 |
| 심각도 | Critical, 9.2 | Critical, 9.2 |
| 대응 방법 | 보안 패치 적용 | 보안 패치 적용 |
두 취약점의 원인은 다르지만 대응 원칙은 같습니다. PHP 개발팀이 공개한 보안 패치가 적용된 버전으로 신속하게 업데이트해야 합니다.
5. PHP 보안 취약 버전과 안전한 업데이트 버전 비교
가장 먼저 확인해야 할 사항은 현재 운영 중인 웹서버의 PHP 버전입니다.
KISA는 PHP 8.2, 8.3, 8.4, 8.5 계열의 보안 패치 기준을 명확하게 안내했습니다.
| PHP 계열 | 취약한 버전 | 패치 적용 버전 |
|---|---|---|
| PHP 8.2 | 8.2.35 미만 | 8.2.35 이상 |
| PHP 8.3 | 8.3.36 미만 | 8.3.36 이상 |
| PHP 8.4 | 8.4.27 미만 | 8.4.27 이상 |
| PHP 8.5 | 8.5.12 미만 | 8.5.12 이상 |
| PHP 8.1 이하 | 공식 지원 종료, 관련 취약점 영향 가능 | 지원 중인 계열로 업그레이드 |
주의할 점은 PHP 8.1 이하 버전이 안전하다는 의미가 아니라는 것입니다. 오히려 공식 보안 지원이 종료된 구버전은 일반적인 PHP 개발팀의 긴급 업데이트 대상에서 제외되므로 신속한 업그레이드 계획이 필요합니다.
일부 리눅스 배포판이나 기업용 보안 유지보수 서비스는 구버전 PHP 패키지에 보안 수정 사항을 별도로 적용할 수 있습니다. 이 경우 단순한 버전 문자열만 보지 말고 운영체제 공급사의 보안 공지와 적용된 패치 내용을 확인해야 합니다.
또한 PHP 8.2 계열은 2026년 12월 31일 공식 보안 지원 종료가 예정되어 있습니다. 따라서 신규 업그레이드라면 호환성이 확인된 PHP 8.3 이상 계열을 우선 검토하는 편이 장기적인 유지보수에 유리합니다.
서버에 표시되는 PHP 버전이 기준보다 낮다면 업데이트 또는 공급사 패치 적용 여부를 즉시 확인해야 합니다.
6. 내 웹사이트 PHP 버전 확인 방법
PHP 보안 취약점 대응에서 가장 중요한 첫 단계는 현재 웹사이트에 어떤 PHP 버전이 적용돼 있는지 확인하는 것입니다.
워드프레스 사용자라면 다음 순서로 확인할 수 있습니다.
- 워드프레스 관리자 화면에 로그인합니다.
- 왼쪽 메뉴에서 '도구'를 선택합니다.
- '사이트 건강' 또는 '사이트 상태' 화면으로 이동합니다.
- '정보' 탭을 선택합니다.
- '서버' 항목을 펼칩니다.
- PHP 버전 항목을 확인합니다.
워드프레스의 사이트 건강 화면은 PHP 버전을 보여주는 기능입니다. 여기에서 서버의 PHP를 직접 업그레이드하는 것은 일반적으로 불가능하며, 실제 변경은 호스팅 업체의 관리 화면이나 서버 관리자가 수행합니다.
서버를 직접 관리하는 경우에는 터미널에서 아래 명령어로 설치된 PHP 명령줄 환경의 버전을 확인할 수 있습니다.
다만 이 명령어는 CLI 환경의 PHP 버전을 보여줍니다. 웹사이트가 실제 사용하는 PHP-FPM이나 Apache PHP 모듈의 버전과 다를 수 있으므로 웹서비스에 연결된 PHP 실행 환경을 별도로 확인해야 합니다.
관리자 권한이 없는 일반 호스팅 이용자는 서버에 파일을 임의로 올려 확인하기보다 호스팅 관리 화면을 확인하거나 업체 고객센터에 문의하는 것이 안전합니다.
7. 워드프레스 PHP 보안 업데이트 방법
워드프레스 운영자에게 이번 취약점은 특히 중요합니다. 워드프레스는 PHP로 동작하기 때문에 서버의 PHP 런타임이 영향을 받는 버전이라면 취약점 노출 가능성이 있습니다.
하지만 워드프레스 자체의 보안 업데이트만으로 이번 문제를 해결할 수 있다고 생각해서는 안 됩니다.
예를 들어 워드프레스 관리자 화면에서 코어와 플러그인을 최신 버전으로 바꾸더라도 호스팅 서버의 PHP가 8.3.35라면 이번 취약점에 대한 PHP 패치는 적용되지 않은 상태일 수 있습니다.
워드프레스 PHP 긴급 업데이트 순서
- 현재 PHP 버전을 확인합니다.
- 웹사이트 파일과 데이터베이스를 백업합니다.
- 사용 중인 테마와 플러그인의 새 PHP 버전 호환성을 확인합니다.
- 가능하면 테스트 사이트에서 호환성을 점검합니다.
- 호스팅 관리 화면에서 보안 패치 버전을 선택합니다.
- 사이트 접속과 관리자 화면, 게시글 작성, 로그인 기능을 테스트합니다.
- 쇼핑몰이라면 주문·결제·환불 기능도 점검합니다.
- 오류 로그를 확인하고 이상 징후를 살펴봅니다.
긴급 보안 패치는 신속하게 적용해야 하지만, 사전 백업과 호환성 확인 없이 무작정 서버 설정을 바꾸면 기존 사이트 기능에 문제가 생길 수 있습니다.
특히 오래된 유료 테마, 자체 제작 플러그인, 맞춤형 PHP 코드를 사용하는 경우 테스트 환경에서 먼저 점검하는 것이 좋습니다.
8. 카페24·일반 웹호스팅·티스토리도 영향이 있을까?
이번 PHP 보안 취약점의 영향 여부는 어떤 서비스 이름을 사용하느냐보다 실제 서버에서 PHP가 어떻게 실행되고 있는지에 따라 달라집니다.
카페24는 2026년 10월 21일 PHP 긴급 보안 취약점에 대응하기 위한 임시 보안 조치 작업을 공지했습니다. PHP 5.4 이상이 제공되는 서비스를 대상으로 관련 설정을 조정하고 추가 대응 작업을 진행한다고 안내했습니다.
다만 이러한 임시 설정 변경은 위험을 줄이기 위한 조치이지, 모든 공격을 차단하는 완전한 해결책으로 간주해서는 안 됩니다.
| 운영 방식 | PHP 대응 주체 | 이용자 조치 |
|---|---|---|
| 워드프레스 독립 호스팅 | 호스팅 업체 또는 서버 관리자 | PHP 버전 확인과 패치 요청 |
| 카페24 웹호스팅 | 카페24 및 계약 서비스 관리자 | 긴급 공지와 개별 사이트 버전 확인 |
| 자체 VPS·서버 | 운영자·시스템 관리자 | OS 패키지·런타임 패치 적용 |
| 관리형 워드프레스 | 관리형 호스팅 사업자 | 실제 적용 버전과 패치 완료 여부 확인 |
| 티스토리 기본 블로그 | 플랫폼 사업자 | 개별 PHP 업데이트보다 플랫폼 공지 확인 |
티스토리 이용자는 별도로 PHP 서버를 설치하고 관리하는 구조가 아닙니다. 따라서 일반적인 티스토리 블로그 운영자가 이 취약점 때문에 직접 PHP 파일을 업로드하거나 서버 설정을 변경할 필요는 없습니다.
다만 티스토리 블로그와 별도로 운영하는 자체 홈페이지, 웹호스팅, PHP 기반 서비스가 있다면 해당 서버는 별도로 확인해야 합니다.
호스팅 업체가 PHP 업데이트를 완료했다고 하더라도 자신이 운영하는 특정 도메인이나 독립 환경에 실제로 적용됐는지 확인하는 것이 좋습니다.
9. 해외 정부기관 웹사이트가 일시 중단된 이유
PHP 보안 취약점이 국제적인 문제로 확산되면서 일부 유럽 국가에서는 정부기관 웹사이트와 공공서비스 운영을 예방 차원에서 일시 중단하는 사례가 발생했습니다.
네덜란드 정부는 2026년 10월 21일 PHP 취약점으로 인해 일부 정부 웹사이트를 예방적으로 오프라인 전환했다고 공식 발표했습니다.
해외 보도에 따르면 독일, 프랑스, 벨기에, 핀란드 등에서도 다양한 기관과 조직이 영향을 받거나 선제적인 대응 조치를 진행했습니다.
왜 웹사이트를 아예 중단했을까요? 패치가 적용되지 않은 서버를 인터넷에 계속 연결해 두는 경우 악성 요청에 노출될 가능성이 있기 때문입니다.
물론 웹사이트 운영 중단이 곧 해킹 피해가 발생했다는 의미는 아닙니다. 일부 기관은 취약점 악용을 예방하기 위한 조치로 서비스를 일시적으로 중단했습니다.
서비스를 잠시 중단하는 손실보다 서버 장악이나 정보 유출 가능성을 우선적으로 막겠다는 위험 관리 판단으로 이해할 수 있습니다.
10. PHP 보안 취약점 악용 시 발생할 수 있는 피해
원격 코드 실행 취약점이 악용되면 공격자가 서버에서 원하지 않는 프로그램을 실행할 가능성이 있습니다.
예상할 수 있는 피해 유형으로는 서버 내부 파일 접근, 데이터 변조, 민감한 정보 노출, 악성코드 설치, 서비스 중단 등이 있습니다. 다만 실제 피해 범위는 PHP 프로세스의 권한과 다른 보안 설정에 따라 달라집니다.
특히 회원정보와 주문정보를 저장하는 사이트, 관리자가 직접 업로드 기능을 제공하는 게시판, 외부 서비스와 연동된 PHP 애플리케이션이라면 보안 점검이 중요합니다.
| 이상 징후 | 확인할 사항 |
|---|---|
| 갑작스러운 서버 오류 | PHP 오류·웹서버 로그 확인 |
| 알 수 없는 파일 생성 | 파일 변경 내역과 접근 권한 확인 |
| 비정상적인 트래픽 증가 | 요청 패턴과 WAF 탐지 기록 확인 |
| 웹사이트 내용 변조 | 최근 변경된 파일·계정 점검 |
| 알 수 없는 프로세스 실행 | 시스템 프로세스와 보안 이벤트 확인 |
| 데이터베이스 이상 | 접근 기록 및 비인가 변경 여부 확인 |
그러나 위 증상들은 다른 원인으로도 나타날 수 있습니다. 증상만으로 이번 PHP 취약점이 악용됐다고 확정할 수는 없습니다.
만약 침해가 의심된다면 서버를 무작정 초기화하거나 로그를 삭제하지 않는 것이 좋습니다. 필요한 경우 외부 네트워크 접근을 제한하고 증거를 보존한 뒤 보안 담당자에게 조사를 요청해야 합니다.
11. PHP 서버 관리자 긴급 보안 조치 순서
PHP 서버를 직접 관리하는 운영자는 보안 업데이트뿐 아니라 업데이트 전후 상태 확인도 함께 수행해야 합니다.
권장 점검 순서는 다음과 같습니다.
- 외부에서 접근할 수 있는 PHP 서버와 애플리케이션을 확인합니다.
- 사용 중인 PHP 버전과 실행 방식(PHP-FPM, mod_php 등)을 조사합니다.
- 공식 보안 패치 또는 배포판 공급사의 수정 패키지 적용 여부를 확인합니다.
- 애플리케이션 파일과 데이터베이스를 백업합니다.
- 운영 환경에 맞는 PHP 보안 업데이트를 적용합니다.
- 필요한 PHP 서비스와 관련 프로세스를 안전하게 재시작합니다.
- 실제 웹 요청을 처리하는 PHP 버전이 변경됐는지 확인합니다.
- 홈페이지 기능과 오류 로그, 보안 이벤트를 점검합니다.
- 의심스러운 공격 흔적이 있으면 별도의 침해 사고 조사를 진행합니다.
서비스를 재시작하지 않거나 잘못된 PHP 실행 환경을 업데이트하면 서버에 보안 패치가 설치됐더라도 실제 사이트에서는 이전 PHP가 계속 작동할 수 있습니다.
또한 웹방화벽(WAF)이나 침입방지 시스템은 위험을 줄이는 보조 수단이 될 수 있지만 이번 PHP 취약점의 완전한 해결책은 아닙니다. PHP 개발팀 역시 패치 업데이트가 핵심 대응이라고 안내했습니다.
관리 중인 서버가 여러 대라면 각각의 서버에 패치가 적용됐는지 별도로 확인해야 합니다.
12. PHP 8.1 이하 구버전 사용자 주의사항
PHP 8.1 이하 버전을 계속 사용하는 운영자는 이번 사건을 계기로 운영 환경 전체를 점검할 필요가 있습니다.
구버전은 오래된 프로그램과의 호환성 때문에 사용되는 경우가 많습니다. 예를 들어 10년 전에 만든 게시판이나 자체 제작 쇼핑몰은 최신 PHP에서 일부 기능이 작동하지 않을 수 있습니다.
하지만 오래된 사이트가 현재 잘 표시된다고 해서 보안상 안전하다는 의미는 아닙니다. 공식 지원이 종료된 PHP 버전은 새롭게 발견되는 취약점에 대해 일반적인 업데이트를 받지 못할 수 있습니다.
이번 취약점은 PHP 8.1 이하 구버전에도 영향을 줄 수 있으므로, 공식 패치가 적용되는 지원 중인 버전으로 전환하는 것이 원칙입니다.
특히 PHP 7 계열을 사용하는 경우에는 단순히 버전 숫자만 바꾸기보다 오래된 코드와 데이터베이스 연결 방식, 플러그인 호환성을 함께 검토해야 합니다.
임시 보안 설정을 적용했더라도 장기적인 해결을 위해서는 지원 중인 PHP 계열로의 이전 계획을 세워야 합니다.
13. PHP 보안 업데이트 상황별 실제 적용 사례
다음은 홈페이지 운영 환경에 따라 어떤 조치를 해야 하는지 이해할 수 있도록 구성한 가상 사례입니다.
✅ 사례 1. 워드프레스 블로그가 PHP 8.3.35를 사용하는 경우
워드프레스 관리자 화면에서 PHP 8.3.35가 확인됐다고 가정해 보겠습니다. 이 버전은 이번 취약점에 대한 공식 패치 기준인 PHP 8.3.36보다 낮습니다.
운영자는 파일과 데이터베이스를 백업한 뒤 호스팅 업체에서 PHP 8.3.36 이상 보안 패치 버전으로 업데이트해야 합니다. 완료 후에는 사이트 건강 화면에서 실제 버전을 재확인해야 합니다.
✅ 사례 2. 오래된 회사 홈페이지가 PHP 7.4를 사용하는 경우
회사의 자체 홈페이지가 PHP 7.4 기반으로 제작돼 있다면 단순한 패치 적용만으로 문제가 해결되지 않을 수 있습니다. 해당 버전은 공식 지원이 종료된 상태이기 때문입니다.
관리자는 호스팅 업체에 임시 위험 완화 조치와 장기 업그레이드 방법을 문의하고, 개발 담당자와 협력해 지원 중인 PHP 계열로 이전해야 합니다.
✅ 사례 3. 티스토리 블로그만 운영하는 경우
티스토리 블로그에 글과 사진을 게시하는 일반 운영자는 PHP 서버 자체를 관리하지 않습니다. 따라서 워드프레스 독립 호스팅과 동일한 방식의 PHP 업데이트를 할 필요는 없습니다.
다만 별도의 도메인에 설치한 PHP 기반 홈페이지나 웹프로그램을 운영하고 있다면 그 서버는 별도로 점검해야 합니다.
✅ 사례 4. 카페24 호스팅 이용자인 경우
카페24는 이번 취약점에 대해 서비스 차원의 긴급 보안 설정 작업을 공지했습니다. 하지만 모든 개별 사이트의 PHP 업그레이드가 완료됐다는 의미로 단정해서는 안 됩니다.
관리 화면에서 현재 PHP 버전을 확인하고, 필요하면 카페24 고객센터에 보안 패치 적용 여부 및 구버전 이전 방법을 문의하는 것이 좋습니다.
14. PHP 보안 취약점 관련 자주 묻는 질문 TOP5
Q1. PHP 보안 취약점이 발견됐으면 내 홈페이지도 이미 해킹된 것인가요?
아닙니다. 취약점이 존재한다는 사실과 실제 침해 사고가 발생했다는 사실은 다릅니다. 다만 취약한 PHP 버전으로 외부 요청을 처리하는 서버라면 공격에 노출될 수 있으므로 보안 패치와 이상 징후 점검이 필요합니다.
Q2. PHP 8.2.35나 8.3.36으로 업데이트하면 해결되나요?
이번에 발표된 두 취약점에 대한 수정 사항이 포함된 공식 버전입니다. PHP 8.4 계열은 8.4.27, PHP 8.5 계열은 8.5.12 이상으로 업데이트해야 합니다. 다만 서버의 다른 취약점까지 모두 해결된다는 의미는 아닙니다.
Q3. 워드프레스 플러그인을 업데이트하면 PHP 문제도 해결되나요?
아닙니다. 워드프레스 플러그인 업데이트와 서버 PHP 런타임 업데이트는 서로 다른 작업입니다. 이번 취약점은 PHP 자체의 문제이므로 실제 PHP 실행 환경에 보안 패치가 적용되어야 합니다.
Q4. PHP 버전을 업데이트하면 홈페이지가 오류를 일으킬 수 있나요?
가능합니다. 오래된 플러그인이나 테마, 자체 제작 코드가 새 PHP 버전과 호환되지 않을 수 있습니다. 따라서 백업과 테스트를 권장합니다. 다만 보안 위험이 큰 상황에서는 업데이트를 장기간 미루지 말고 호스팅 업체와 신속하게 대응해야 합니다.
Q5. PHP 보안 업데이트는 무료인가요?
PHP는 오픈소스 소프트웨어이며 공식 보안 수정 사항 자체는 무료로 제공됩니다. 다만 호스팅 상품의 변경, 개발자 작업, 오래된 프로그램의 호환성 수정이나 서버 이전에는 별도의 비용이 발생할 수 있습니다.
15. 결론｜PHP 보안 취약점 긴급 업데이트 공식 바로가기
이번 PHP 보안 취약점 사건에서 가장 중요한 결론은 서버가 사용하는 PHP 버전을 확인하고, 공식 보안 패치가 적용된 상태로 신속하게 업데이트해야 한다는 것입니다.
2026년 10월 21일 공개된 CVE-2026-109618과 CVE-2026-109619는 PHP의 메모리 처리 과정에 발생하는 심각한 취약점입니다. 공격에 성공할 경우 관리자 로그인 없이 서버에서 임의의 코드를 실행할 수 있어 위험성이 높습니다.
KISA는 PHP 8.2.35, 8.3.36, 8.4.27, 8.5.12 이상으로 업데이트할 것을 권고했습니다. PHP 8.1 이하 버전은 지원 중인 PHP 계열로 이전해야 합니다.
워드프레스 사용자는 사이트 건강 화면에서 PHP 버전을 확인하고, 실제 업데이트는 호스팅 업체의 관리 화면이나 서버 관리자를 통해 진행해야 합니다. 카페24 등 웹호스팅 이용자는 사업자의 공지와 개별 서버의 보안 조치 적용 여부를 확인하는 것이 좋습니다.
반면 티스토리처럼 플랫폼 사업자가 운영하는 서비스는 일반 이용자가 별도로 PHP를 업그레이드하는 구조가 아닙니다.
모든 웹사이트가 같은 수준의 위험에 노출된 것은 아니지만, 취약한 PHP 환경을 방치하면 악성 요청에 노출될 수 있습니다. 보안 패치와 백업, 접근 기록 점검을 함께 진행해야 합니다.
아래에서 공식 보안 공지와 PHP 업데이트 정보를 직접 확인할 수 있습니다.
🚨 KISA PHP 긴급 보안 공지 바로가기 ⬇️ PHP 공식 보안 업데이트 다운로드 🔎 PHP 버전별 공식 지원 상태 확인 🛠️ 워드프레스 PHP 버전 확인 방법 📢 카페24 PHP 긴급 보안 작업 공지보안 취약점에 관한 상담이나 침해 사고 관련 도움이 필요하다면 한국인터넷진흥원 사이버민원센터 국번 없이 118번을 통해 안내받을 수 있습니다.
작성 기준: 2026년 10월 22일. PHP 개발팀, 한국인터넷진흥원, 워드프레스 공식 문서 및 호스팅 사업자 공지를 기준으로 작성했습니다. 사진은 이해를 돕기 위한 PHP·서버·보안 관련 이미지이며 실제 취약점 악용 현장을 촬영한 것은 아닙니다.