턱스케어(TuxCare)의 국내 독점 총판 쿠도커뮤니케이션이 공식 지원이 끝난 구버전 PHP에 ‘PHP2Shell’ 취약점 2건의 보안 수정을 얹은 패키지로 대응하는 방안을 내놨다. 대상은 CVE-2026-109618과 CVE-2026-109619이며, 이 발표는 27일 서울신문과 데일리시큐를 통해 보도됐다.
시점이 중요한 이유는 문제가 두 건에서 끝나지 않았기 때문이다. 같은 발표에 따르면 한국인터넷진흥원(KISA)은 10월 24일 공지에서 신규 취약점 CVE-2026-115560이 10월 21일 배포된 PHP 보안 업데이트만으로는 해결되지 않는다고 안내했다 (서울신문). 구버전용 패치를 검토하는 기업도 이 취약점은 따로 따져야 한다.
이 글은 백포트 패치가 겨냥한 취약점과 그 밖에 남는 문제, PHP 계열별 공식 대응, 자주 인용되는 숫자의 의미, 서버 운영자의 확인 순서를 차례로 정리한다. 솔루션 공급사의 설명과 보안 기관·기업의 설명은 누가 말했는지 밝혀 나눠 적는다.
쿠도커뮤니케이션 발표의 핵심은 버전을 두고 수정만 얹는 방식이다
턱스케어는 연장 수명 주기 지원 솔루션 ‘ELS(Endless Lifecycle Support) for Runtimes’로 지원 종료 PHP를 포함한 대상 환경에 보안 업데이트를 제공한다고 밝혔다. 회사가 내세운 핵심은 기존 버전 계열을 유지한 채 최신 보안 수정사항만 반영하는 ‘백포트(Backport)’ 방식이다 (서울신문).
서울신문 기사 첫머리에 실린 발표의 요지는 세 줄이다.
- 턱스케어 국내 독점 총판으로서 지원 종료 PHP 환경의 보안 유지 방안을 제시한다.
- PHP2Shell 취약점 2건에 대응하는 패치를 제공해 상위 버전 전환이 어려운 기업을 지원한다.
- 추가로 발견된 취약점은 별도 점검이 필요하며, 패치 적용부터 실행 환경 확인까지 강조한다.
이 내용은 솔루션을 공급하는 회사의 설명이다. 데일리시큐 보도에서도 쿠도커뮤니케이션은 턱스케어 국내 독점 총판사로서 관련 솔루션을 공급하고 있다고 소개됐고, 실제 적용 가능 여부는 운영체제, PHP 버전, 패키지 구성 및 사용 중인 확장 모듈에 따라 확인해야 한다는 단서가 붙었다 (데일리시큐).
이번 PHP 패키지가 어떤 운영체제와 PHP 버전 조합을 지원 대상으로 삼는지는 확인되지 않았다.
10월 20일 예고부터 27일 보도까지, 공지는 이렇게 이어졌다
이번 사안은 일주일 남짓한 사이에 예고, 권고, 추가 공지가 잇따랐다. 아래 날짜는 각 출처가 적은 날이며, 27일은 쿠도커뮤니케이션 발표가 보도된 날이다.
| 날짜 | 주체 | 내용 |
|---|---|---|
| 10월 20일 | PHP 보안팀 | CVSS v4.0 9.2점 취약점 2건의 보안 업데이트 예고 (안랩) |
| 10월 21일 | PHP 보안팀 | 정식 보안 권고문 발표, 8.2~8.5 계열 수정 버전 배포 (안랩) |
| 10월 21일 | KISA | PHP 보안 업데이트 권고 발표 (CEONEWS) |
| 10월 24일 | KISA | CVE-2026-115560 공지, 21일 업데이트만으로는 해결되지 않는다고 안내 (서울신문) |
| 10월 27일 | 쿠도커뮤니케이션 | 턱스케어 ELS 백포트 패키지 대응 방안 보도 (데일리시큐) |
정부의 추가 지원은 22일 보도 시점에 ‘검토’ 단계였다. CEONEWS는 10월 22일 오전 현재 확인되는 정부 조치를 보안 안내와 업데이트 권고, 지원책 검토 단계로 구분했고, 과기정통부가 중소기업 긴급 패치 지원 등 추가 지원책을 검토 중인 것으로 보도됐다고 전했다 (CEONEWS). 그 뒤 지원책이 확정됐는지는 확인되지 않았다.
지원이 끝난 PHP 계열에는 정규 수정 버전이 나오지 않았다
PHP 보안팀이 21일 정식 수정 버전을 낸 것은 8.2부터 8.5까지 네 계열이다 (안랩). 그보다 오래된 계열은 사정이 다르다. 안랩에 따르면 PHP 보안팀은 사안의 심각성을 고려해 PHP 7.4, 8.0, 8.1의 소스 코드에 적용할 수 있는 최소한의 보안 수정 사항을 제공했지만, 이는 일반적인 보안 지원이 재개됐다는 의미는 아니다.
| PHP 계열 | 공식 대응 | 운영자가 확인할 것 |
|---|---|---|
| 8.5 | 8.5.12 수정 버전 배포 | 공식 릴리스면 8.5.12 이상인지, 배포판·관리형이면 공급업체 수정 내역 |
| 8.4 | 8.4.27 수정 버전 배포 | 공식 릴리스면 8.4.27 이상인지, 배포판·관리형이면 공급업체 수정 내역 |
| 8.3 | 8.3.36 수정 버전 배포 | 공식 릴리스면 8.3.36 이상인지, 배포판·관리형이면 공급업체 수정 내역 |
| 8.2 | 8.2.35 수정 버전 배포 | 공식 릴리스면 8.2.35 이상인지, 배포판·관리형이면 공급업체 수정 내역 |
| 7.4·8.0·8.1 | 소스 코드용 최소 보안 수정 제공, 일반 지원 재개는 아님 | 직접 빌드 가능 여부, 배포판·연장 지원 업체 패키지 |
| 8.1 이하 | PHP 개발팀 정규 보안 업데이트 대상 아님 | 운영체제 공급업체 안내, 지원 버전 이전 계획 |
표의 수정 버전과 7.4·8.0·8.1 관련 내용은 안랩, 8.1 이하 항목은 CEONEWS 설명을 따랐다. 표의 수정 버전 번호는 PHP 보안팀이 10월 21일 공개한 공식 릴리스 기준이다. 안랩은 리눅스 배포판이나 관리형 서비스 환경에서는 공급업체가 별도로 제공하는 보안 수정 사항도 확인할 필요가 있다고 적었다 (안랩).
CEONEWS는 일부 운영체제 공급업체가 별도의 보안 패치를 제공할 수 있지만 운영자가 공급업체의 안내를 확인해야 한다고 적었다. kilho.net도 7.4·8.0·8.1에는 소스 빌드용 최소 백포트만 제공된다며 배포판·LTS 업체 패키지를 확인하라고 정리했다 (kilho.net).
이를 바탕으로 구버전 운영자가 고를 수 있는 길을 세 갈래로 나눠 볼 수 있다. 이 분류는 이 글의 정리다.
- 지원되는 계열(8.2~8.5)로 올린 뒤 해당 수정 버전을 적용한다.
- 7.4·8.0·8.1이라면 PHP 보안팀의 소스 코드용 최소 수정을 직접 빌드한다. 일반 지원이 재개된 것은 아니다.
- 운영체제 공급업체나 연장 지원 업체의 패키지를 쓰되, 지원 범위와 적용 조건을 먼저 확인한다.
턱스케어 ELS를 세 번째 갈래의 선택지 가운데 하나로 보는 것은 이 글의 해석이다. 안랩은 장기적으로는 지원되는 PHP 버전으로 전환하는 것이 필요하다고 적었다 (안랩).
백포트 패키지는 전환을 준비하는 동안의 대응으로 제시됐다
회사 설명대로라면 PHP 상위 버전으로 즉시 전환하기 어려운 기업도 지원 대상 환경에서는 보안 수정사항이 적용된 패키지로 취약점에 대응하면서, 애플리케이션 호환성 검증과 단계적인 업그레이드를 준비할 수 있다 (서울신문). 업그레이드를 건너뛰는 수단이 아니라 준비하는 동안의 공백을 메우는 수단으로 설명한 셈이다.
바로 올리지 못하는 이유도 발표에 담겼다. 기존 애플리케이션이나 확장 모듈과의 호환성 문제로 상위 버전 전환에 상당한 시간이 걸릴 수 있고, 운영을 외부 업체에 맡긴 경우에는 실제 사용 중인 PHP 환경과 패치 적용 여부를 확인하는 과정도 필요하다는 설명이다.
구대완 턱스케어 한국지사 대표는 “중요한 것은 전환을 준비하는 동안에도 보안 업데이트가 이어질 수 있도록 지원 체계를 확보하는 것”이라고 말했다. 그는 “긴급 보안 조치와 중장기 업그레이드 계획을 함께 추진해야 한다”고도 했다 (서울신문).
발표가 패키지 적용 전에 확인하라고 꼽은 항목은 네 가지다.
- 운영체제(OS)
- PHP 버전
- 패키지 구성
- 사용 중인 확장 모듈
이 방식이 남기는 과제도 있다. 버전 계열을 그대로 두는 만큼 상위 버전 이전이라는 숙제는 사라지지 않는다는 것이 이 글의 해석이다. 또 발표가 패치를 제공한다고 밝힌 PHP2Shell 취약점은 2건이므로, 그 뒤 공지된 취약점은 다음 절처럼 따로 확인해야 한다.
CVE-2026-115560은 21일 업데이트와 별개로 다뤄야 한다
서울신문이 전한 발표 내용에 따르면 KISA는 10월 24일 공지에서 CVE-2026-115560이 특정 세션 설정 조합에서 발생할 수 있다고 밝혔다. 영향을 받는 환경에는 파일 업로드 진행 상황 추적 기능을 비활성화하고 모든 PHP 작업 프로세스를 재시작하는 임시 조치를 권고했다 (서울신문).
비교해 볼 대목은 앞선 취약점의 완화책이다. 안랩은 CVE-2026-109619와 관련해 session.upload_progress.enabled=0 설정을 적용하고 PHP 워커 프로세스를 재시작하는 방안이 제시됐다고 전했다 (안랩). kilho.net은 공식 공지가 세션 업로드 진행률 기능 등을 CVE-2026-109619의 확인된 경로로 들면서, 이 경로들을 막아도 다른 변형 경로는 남는다고 밝혔다고 정리했다 (kilho.net).
KISA가 말한 ‘파일 업로드 진행 상황 추적 기능’과 안랩이 적은 설정 항목은 같은 기능을 가리키는 것으로 보이지만, 이름을 근거로 한 이 글의 해석이다. CVE-2026-115560과 CVE-2026-109619가 기술적으로 어떤 관계인지도 확인되지 않았다.
| 취약점 | 보도된 성격 | 보도된 대응 |
|---|---|---|
| CVE-2026-109618 | 메모리 부족 처리 과정의 데이터 손상, 인증 없는 원격 코드 실행 가능(안랩) | 21일 수정 버전, 메모리·업로드 크기·요청 처리 제한 조정 완화책(안랩), 턱스케어 패키지 지원(회사 발표) |
| CVE-2026-109619 | 해제된 메모리와 관련된 내부 상태 재사용, 인증 없는 원격 코드 실행 가능(안랩) | 21일 수정 버전, 업로드 진행률 설정 끄기·워커 재시작 완화책(안랩), 턱스케어 패키지 지원(회사 발표) |
| CVE-2026-115560 | 특정 세션 설정 조합에서 발생 가능(KISA 공지, 서울신문 전언) | 21일 업데이트만으로는 해결 안 됨, 업로드 진행 추적 비활성화·모든 PHP 작업 프로세스 재시작 임시 조치 |
완화책에는 대가가 따른다. 안랩은 이런 조치가 특정 공격 경로의 위험을 줄일 뿐 취약점을 완전히 해결하지 못하고, 서버의 성능과 서비스 기능에 영향을 미칠 수 있다고 설명했다 (안랩).
kilho.net은 공식 공지가 CVE-2026-109618 완화책으로 제시한 memory_limit = -1 설정이 물리 메모리가 넉넉하지 않은 서버에서는 OOM Killer가 핵심 데몬을 강제 종료시키는 장애로 이어질 수 있다고 짚었다 (kilho.net).
숫자는 피해 규모가 아니라 점검할 범위를 알려 준다
자주 인용되는 숫자는 각각 다른 것을 잰다.
- CVSS v4.0 9.2점: 안랩과 CEONEWS는 CVE-2026-109618과 CVE-2026-109619가 모두 이 점수를 받았다고 전했다 (안랩·CEONEWS). 취약점의 심각도 평가이며, 실제 피해가 얼마나 났는지를 말하는 수치는 아니다.
- 112,183개: AhnLab TIP이 소개한 인터넷 자산 검색 기반 조사에서 한국에서 관측된, 취약한 PHP 버전을 쓰는 것으로 추정되는 호스트 수다. 전체의 약 4.35%로 집계됐다 (안랩). 관측 시점은 확인되지 않았다.
- 약 5,900개 기업·기관과 약 3만 곳: CEONEWS가 전한 C-TAS 참여 기업·기관 수와 CISO 신고 의무 대상 기업 수로, 22일 보도에서 보안 조치 안내 대상으로 인용된 집단의 규모다 (CEONEWS).
안랩은 호스트 수치가 추정치이며 모든 호스트가 이번 취약점에 영향을 받거나 실제 공격 가능한 상태라는 의미는 아니라고 밝혔다. CEONEWS도 보안 공지를 받았다는 사실과 실제 서버의 취약점이 제거됐다는 사실은 다르다고 짚었다.
이 집계에서 지원 종료 계열의 비중은 확인되지 않아, 구버전용 패치가 필요한 국내 서버 규모를 이 숫자로 가늠하기는 어렵다.
서버를 운영한다면 이 순서로 확인한다
침해 사고가 의심되면 재시작 전에 외부 접속 차단과 증거 보존, 신고·전문가 대응을 우선한다. 재시작으로 메모리에 남은 공격 흔적이 사라질 수 있다는 설명과 침해 흔적 발견 시 증거를 보존하라는 안내를 함께 반영한 이 글의 절차 해석이다 (스페셜타임스·CEONEWS).
발표와 보안 업체·매체의 안내를 겹쳐 보면, 침해가 의심되는 경우를 제외한 일반적인 패치 확인 순서는 아래와 같다. 순서는 이 글이 묶은 것이다.
- PHP 자산과 공급 경로 파악: 자사의 PHP 사용 여부와 버전, 패키지 공급 경로를 우선 파악해야 한다 (서울신문). CEONEWS는 대표 홈페이지 외에 쇼핑몰, 채용 사이트, 협력업체 포털, 외주 개발 뒤 관리가 중단된 홈페이지, 클라우드 및 컨테이너 환경도 확인 대상으로 꼽았다.
- 실행 방식 확인: 안랩은 PHP 보안팀이 PHP-FPM, Apache의 mod_php, php-cgi, FrankenPHP, LiteSpeed 등에 영향이 있을 수 있다고 설명했고, mod_php 환경은 상대적으로 위험도가 높은 환경으로 평가됐다고 전했다 (안랩).
- 계열에 맞는 수정 적용: PHP 공식 릴리스를 쓰는 8.2~8.5 환경은 위 표의 수정 버전을 적용한다. 지원 중인 계열이라도 배포판이나 관리형 서비스로 PHP를 받는다면 공급업체의 패키지와 취약점별 수정 내역을 확인한다. 8.1 이하는 운영체제 공급업체나 연장 지원 업체의 패키지와 적용 조건을 확인한다. CEONEWS는 업데이트 전에는 백업과 호환성 검증을 진행하고, 작업 시간과 복구 절차도 마련해야 한다고 정리했다 (CEONEWS). kilho.net은 자원봉사자가 운영하는 Remi 저장소에 발표 당일 업데이트가 올라오지 않는다고 공식 공지가 밝혔다고 전했다 (kilho.net).
- CVE-2026-115560 임시 조치 검토: 영향을 받는 환경이라면 KISA가 권고한 업로드 진행 상황 추적 기능 비활성화와 모든 PHP 작업 프로세스 재시작을 검토한다.
- 실제 반영 확인: 패키지 업데이트 뒤 실제 웹서비스를 처리하는 PHP 프로세스에 수정사항이 반영됐는지 검증한다. kilho.net은 CLI 버전과 웹 서버가 연동하는 PHP 프로세스의 버전이 다를 수 있고, 확인용으로 만든 진단 파일은 점검 직후 삭제하라고 안내했다.
- 침해 흔적 점검: CEONEWS는 보안 업데이트를 적용해도 과거의 침해 가능성까지 사라지지 않는다며, 로그와 낯선 파일, 알 수 없는 관리자 계정을 살피고 흔적이 나오면 증거를 보존하라고 정리했다 (CEONEWS).
- 위탁·호스팅 확인: 외부 웹호스팅을 쓰는 기업은 운영업체에 자사 서비스의 취약점 영향 여부와 보안 조치 완료 여부를 확인할 필요가 있다 (서울신문).
웹 방화벽 규칙은 보조 수단으로 다뤄진다. CEONEWS는 방화벽 규칙과 접근 차단은 PHP 개발팀이 권고하는 보안 업데이트를 대신할 수 없다고 짚었다 (CEONEWS).
아직 확인되지 않은 것
- 턱스케어 ELS가 CVE-2026-115560에 대한 수정 패키지를 제공하는지
- 이번 PHP 패키지를 쓸 수 있는 운영체제와 PHP 버전의 구체적 목록, 비용
- CVE-2026-115560의 정식 수정 버전이 배포됐는지와 그 일정
- 정부의 중소기업 긴급 패치 지원이 확정됐는지, 확정됐다면 대상과 절차
- 국내 실제 공격·피해 규모
- 국내에서 관측된 추정 호스트 가운데 지원 종료 계열의 비중
후속 공지는 PHP 공식 홈페이지와 KISA 보안 공지에서 확인할 수 있다. 안랩은 PHP 공식 홈페이지에서 최신 보안 공지를 지속적으로 확인하라고 권고했다 (안랩).
관련 글: PHP 세 번째 취약점, 21일 패치로 안 막히는 조건과 지금 할 일 · PHP 취약점 2건에 정부 ‘주의’ 경보…버전별 업데이트 기준
