PHP 메모리 손상 취약점 실제 공격 확인과 버전별 업데이트

무슨 일이 생겼나요

KISA 보호나라는 2026-10-21 PHP의 메모리 손상 취약점에 대한 업데이트를 권고했어요. 메모리를 요청마다 사용하는 작업 공간이라고 생각하면 이해하기 쉬워요. 작업 공간을 정리하면서 아직 확인하지 않은 메모를 읽거나, 이미 버린 메모를 다음 작업의 지시로 착각하는 것과 비슷해요. PHP가 요청을 처리하고 정리하는 과정에서 이런 잘못된 참조가 생길 수 있어요.

대상은 CVE-2026-109618과 CVE-2026-109619예요. 메모리는 프로그램이 처리 중인 내용을 잠시 보관하는 공간이에요. 해당 취약점은 이 공간의 상태나 사용 기간을 잘못 다루는 문제이며, 공격자가 서버에서 의도한 코드를 실행하게 되는 원격 코드 실행으로 이어질 수 있어요.

두 취약점 모두 실제 공격에 쓰이고 있음(CISA KEV 등재)이 확인됐어요. CISA KEV는 실제 공격에 사용된 것으로 알려진 취약점을 모아 둔 목록이며, 두 취약점의 등재일은 2026-10-26이에요. 목록에 적힌 조치기한은 2026-10-29예요. 이 기한을 모든 독자에게 똑같이 적용되는 의무로 해석할 수는 없지만, 실제 악용 사실은 업데이트 우선순위를 높여야 할 근거예요.

기술적으로는 (초급 개발자용)

두 취약점의 유형은 메모리 손상이에요. 연결된 CWE는 소프트웨어 약점의 종류를 구분하는 분류예요. CWE-1325는 연속적인 메모리 할당을 적절히 통제하지 못하는 문제, CWE-416은 해제된 메모리를 다시 사용하는 문제, CWE-755는 예외 상황을 적절히 처리하지 못하는 문제, CWE-824는 초기화되지 않은 포인터에 접근하는 문제를 뜻해요. 포인터는 메모리의 위치를 가리키는 값이에요. 두 취약점에 같은 CWE가 연결돼 있어도 발생 과정까지 같다는 뜻은 아니에요.

CVE-2026-109618은 메모리가 부족해진 상황을 처리하는 흐름과 관련돼 있어요. PHP는 메모리 부족이 발생하면 진행 중인 처리에서 빠져나와 요청 처리를 중단하는데, 일부 처리 흐름은 이 상황에 맞게 메모리 상태를 준비하지 못할 수 있어요. 이후 요청을 정리하면서 내용이 제대로 정해지지 않은 메모리를 읽거나 그 값에 따라 처리 방향을 결정할 수 있어요. 공격자가 메모리 부족 상황을 유발하는 방식으로 이 상태를 만들면 원격 코드 실행으로 이어질 수 있어요.

CVE-2026-109619는 여러 요청을 처리하는 동안 유지되는 전역 상태와 관련돼 있어요. 전역 상태는 처리 흐름 전반에서 함께 참조하는 정보예요. 이 정보가 특정 요청의 메모리를 가리키다가 적절히 초기화되지 않거나, 초기화된 뒤 다시 이전 요청의 메모리를 가리킬 수 있어요. 해당 메모리가 해제된 뒤에도 그 참조가 남으면, 후속 요청이 오래된 정보를 읽거나 그 값에 따라 처리 방향을 결정할 수 있어요. 이런 상태를 유발하는 방식으로 원격 코드 실행이 가능해질 수 있어요. 다만 공격에 필요한 구체적인 요청 내용이나 서비스 설정 조건은 여기서 단정할 수 없어요.

NVD는 두 취약점을 각각 CVSS 4.0 기준 9.2, 심각도 CRITICAL로 평가했으며 NVD 게시일은 2026-10-21이에요. CVSS는 취약점의 기술적 심각도를 공통 기준으로 나타내는 점수예요. 이 점수는 개별 서버의 공격 성공 확률이나 피해 규모를 뜻하지 않아요. 이번에는 높은 기술적 심각도와 별개로 CISA KEV 등재를 통한 실제 악용 사실도 확인됐으므로, 사용 버전과 해결 버전의 비교가 우선이에요.

누가 영향을 받나요

일반 사용자

PHP를 사용하는 웹서비스에서는 서버의 요청 처리 과정이 영향을 받을 수 있어요. 일반 이용자가 화면에서 PHP 사용 여부나 서버 버전을 알아내기는 어려워요. 웹사이트를 방문했다는 사실만으로 개인 기기가 이 취약점에 감염됐다고 판단할 수는 없으며, 이번 업데이트의 직접적인 대상은 PHP를 실행하는 환경이에요.

직접 운영하는 사이트가 있거나 외부 업체에 운영을 맡겼다면, 담당자에게 PHP 사용 계열과 해결 버전 적용 여부를 확인하세요. 서비스를 이용하기만 하는 사람은 서버의 PHP를 직접 업데이트할 수 없어요. 서비스에 로그인하거나 페이지가 정상적으로 열린다는 사실만으로 서버의 취약점이 해결됐다고 볼 수도 없어요.

개발자

PHP로 작성한 애플리케이션의 소스만 검토해서 이번 문제의 해결 여부를 판단할 수는 없어요. 취약점은 PHP 자체의 메모리 처리와 관련돼 있으므로, 개발 환경뿐 아니라 실제 서비스에서 실행되는 PHP 버전을 확인해야 해요. 요청 처리가 중단되거나 다음 요청으로 넘어가는 과정이 관련돼 있다는 점도 함께 이해해 두세요.

업데이트를 준비할 때는 현재 사용 중인 PHP 계열의 해결 버전을 기준으로 배포 대상을 정하세요. 적용 후에는 주요 요청이 정상적으로 처리되는지와 오류가 발생한 요청 이후에도 서비스가 정상적으로 동작하는지 확인하세요. 정상 동작 검사는 업데이트에 따른 서비스 문제를 찾는 데 도움이 되지만, 취약점 해결을 확인하려면 실제 실행 버전도 따로 확인해야 해요.

서버·장비 담당자

PHP 8.2는 8.2.35 미만, PHP 8.3은 8.3.36 미만, PHP 8.4는 8.4.27 미만, PHP 8.5는 8.5.12 미만이 영향 범위예요. 두 CVE 모두 같은 버전 경계가 적용돼요. 각 계열의 해결 기준은 PHP 8.2의 8.2.35 이상, PHP 8.3의 8.3.36 이상, PHP 8.4의 8.4.27 이상, PHP 8.5의 8.5.12 이상이에요.

패키지 업데이트가 끝났다는 결과와 서비스에 해결 버전이 적용됐다는 결과를 구분해서 확인하세요. 명령줄에서 확인한 PHP와 웹 요청을 처리하는 PHP가 같은 대상인지도 점검해야 해요. 실제 공격에 쓰이는 취약점이므로 외부 요청을 처리하는 PHP 환경의 적용 상태를 우선 확인하고, 제조사 공지의 업데이트 절차를 따르세요.

지금 할 일

1. 운영 중인 서비스에서 PHP를 사용하는지 확인하고, 사용한다면 PHP 8.2, PHP 8.3, PHP 8.4, PHP 8.5 중 어느 계열인지와 현재 버전을 기록하세요. 외부 운영 업체가 관리한다면 해당 정보를 담당자에게 확인하세요.
2. 현재 버전을 계열별 영향 범위와 비교하세요. PHP 8.2의 8.2.35 미만, PHP 8.3의 8.3.36 미만, PHP 8.4의 8.4.27 미만, PHP 8.5의 8.5.12 미만이면 두 취약점의 업데이트 대상이에요.
3. 제조사 공지의 업데이트 절차를 따르세요. 목표 버전은 사용 중인 계열에 맞춰 PHP 8.2는 8.2.35 이상, PHP 8.3은 8.3.36 이상, PHP 8.4는 8.4.27 이상, PHP 8.5는 8.5.12 이상으로 정하세요.
4. 운영 환경에 맞는 방식으로 업데이트를 적용하세요. 아래 패키지 업데이트 명령은 PHP 외의 패키지도 함께 갱신할 수 있으므로 적용 대상을 확인하세요. 명령이 성공했다는 이유만으로 해당 PHP 계열의 해결 버전이 설치됐다고 판단하지 마세요.
5. 업데이트 후 실제 웹 요청을 처리하는 PHP에도 해결 버전이 적용됐는지 확인하세요. 실행 환경에 반영하기 위한 절차 역시 제조사 공지의 업데이트 절차를 따르세요.
6. 주요 서비스 기능과 요청 처리 중 발생한 오류를 점검하고, 적용한 PHP 계열과 버전 및 서비스 확인 결과를 운영 기록에 남기세요. 관리하는 다른 PHP 실행 환경에도 영향 범위에 해당하는 버전이 남아 있는지 확인하세요.

php -v

sudo apt update && sudo apt upgrade

sudo dnf upgrade

바로 업데이트하기 어렵다면

• 바로 업데이트하기 어렵다면 제조사 공지에서 임시 대응 안내를 먼저 확인하세요. 그 안내와 서비스 운영 조건에 맞춰 PHP 서비스로 들어오는 접근을 제한하거나 외부 노출을 줄이는 방안을 검토할 수 있어요. 이런 조치를 취해도 메모리 처리 문제가 수정되는 것은 아니므로 해결 버전 적용을 계속 준비해야 해요.

업데이트 후 확인

• 명령줄에서 확인한 버전이 사용 계열의 해결 기준을 충족하는지 확인하세요. PHP 8.2는 8.2.35 이상, PHP 8.3은 8.3.36 이상, PHP 8.4는 8.4.27 이상, PHP 8.5는 8.5.12 이상이에요.
• 웹 요청을 실제로 처리하는 PHP의 적용 버전도 확인하세요. 명령줄에서 조회한 실행 환경과 서비스 실행 환경이 다르면 명령줄 결과만으로 확인을 끝내지 마세요.
• 업데이트 후 주요 요청의 응답과 서비스 오류 기록을 확인하세요. 요청 처리 중 오류가 발생한 뒤에도 후속 요청이 정상적으로 처리되는지 점검하되, 이 결과만으로 취약점 해결을 입증했다고 해석하지 마세요.
• 두 CVE의 적용 완료 여부를 함께 기록하세요. 버전 경계는 같지만, 운영 기록에는 CVE-2026-109618과 CVE-2026-109619가 모두 이번 업데이트 대상이었다는 점을 남겨 두세요.

해외 동향 (NVD·CISA KEV)

실제 공격에 쓰이고 있음(CISA KEV 등재) — 미국 사이버보안·기반시설보안청(CISA)이 실제 악용을 확인한 취약점 목록에 CVE-2026-109618(2026.10.26 등재), CVE-2026-109619(2026.10.26 등재)이 올라 있어요.

제조사 공식 공지

• https://www.php.net/archive/2026.php#2026-10-21-5
• https://github.com/php/php-src/security/advisories/GHSA-w8hw-w9fx-j79w
• https://github.com/php/php-src/security/advisories/GHSA-6wmf-4rv5-p3rp

자주 묻는 질문

Q. 두 취약점은 아직 공격 가능성만 제기된 상태인가요?

아니요. CVE-2026-109618과 CVE-2026-109619는 모두 실제 공격에 쓰이고 있음(CISA KEV 등재)이 확인됐어요. 등재일은 2026-10-26이고, 조치기한은 2026-10-29로 기재돼 있어요. 다만 이 사실만으로 특정 서버가 이미 공격받았다고 판단할 수는 없어요.

Q. 랜섬웨어 공격에도 사용됐다는 뜻인가요?

두 취약점의 CISA KEV 랜섬웨어 사용 항목은 모두 Unknown이에요. 랜섬웨어는 데이터를 잠그거나 접근을 막고 대가를 요구하는 악성 프로그램이에요. Unknown은 랜섬웨어 사용 여부가 확인되지 않았다는 의미이며, 사용되지 않았다는 뜻은 아니에요. 실제 공격 사용 여부와 랜섬웨어 사용 여부는 구분해서 읽어야 해요.

Q. PHP 버전 확인과 패키지 업데이트만 하면 조치가 끝나나요?

명령 실행 뒤에도 확인이 필요해요. 패키지 업데이트가 해당 PHP 계열의 해결 버전을 설치했는지, 실제 서비스를 처리하는 PHP에 그 버전이 반영됐는지 확인해야 해요. 두 취약점의 해결 버전 경계는 같으므로 사용 중인 계열의 기준을 충족하는 버전을 적용하고, 제조사 공지의 업데이트 절차에 따라 서비스 동작까지 점검하세요.