[특집] 버전 번호는 거짓말을 한다 — PHP2Shell 이후, 백포트와 지원 종료가 갈라놓은 서버들

이 글이 다루는 것

2026년 10월 21일 PHP2Shell(CVE-2026-109618, CVE-2026-109619) 수정판이 나왔습니다. 사건의 경과와 대응은 앞선 글에 정리했습니다. 이 글은 그 뒤의 질문 하나를 다룹니다.

"내 서버는 정말 고쳐졌는가를 무엇으로 아는가?"

답은 생각보다 복잡합니다. 공식 수정판은 8.2.35 · 8.3.36 · 8.4.27 · 8.5.12인데, 어떤 서버는 8.2.34라고 표시된 채로 이미 고쳐져 있고, 어떤 서버는 8.1이라고 표시된 채로 영영 고쳐지지 않습니다. 결함이 메모리에서 어떻게 작동하는지는 이 글에서도 다루지 않습니다. 대신 '수정'이라는 사실이 버전 번호에 어떻게 담기고, 어떻게 담기지 않는지를 봅니다.

크게 보기

1부 · 같은 번호, 다른 서버

서버 두 대가 있다고 해 봅시다. 둘 다 php -v가 8.2.34를 말합니다. PHP 공지에 따르면 8.2의 수정판은 8.2.35이니 둘 다 낡아 보입니다.

그런데 한 대는 cPanel/CloudLinux 호스팅이고, 한 대는 직접 빌드한 서버라면 이야기가 달라집니다. 영국의 보안 컨설팅 Sockt가 10월 22~23일에 수정 전 번호를 보이던 사이트를 다시 방문해 본 결과, 8.2~8.5에서 여전히 옛 번호를 보이던 25만 6천여 곳의 대부분(93%)이 CloudLinux가 수정 빌드로 안내한 번호(8.2.34 · 8.3.35 · 8.4.26 · 8.5.11) 그대로였습니다. 번호를 올리지 않고 안쪽만 고쳤다는 뜻입니다. 같은 8.2.34가 한쪽에서는 '고쳐진 빌드', 다른 쪽에서는 '고쳐지지 않은 소스'입니다.

레드햇의 보안 문서는 이 상황을 이렇게 설명합니다. "패키지의 버전 번호만 봐서는 취약한지 아닌지 알 수 없다." 번호만 보고 판정하는 보안 점검 도구는 백포트를 모르기 때문에 이미 고친 서버를 취약하다고 알리는 오탐을 낸다는 것도 같은 문서에 적혀 있습니다.

크게 보기

2부 · 백포트란 무엇이고 왜 생겼나

정의

백포트(backport)는 최신 상류 버전에서 보안 결함이 고쳐졌을 때, 그 수정만 떼어 내 배포 중인 옛 버전에 이식하는 일입니다. 레드햇은 대부분의 제품에서 이 방식이 자사의 기본 관행이라고 설명합니다. 수정 하나를 이식할 때 하는 일도 정해져 있습니다.

1. 수정을 다른 변경에서 분리하고
2. 부작용이 없는지 확인하고
3. 이미 배포된 옛 버전에 적용합니다.

왜 이런 방식이 생겼나: 레드햇이 든 사례

레드햇 문서에는 PHP가 실제 예로 나옵니다. RHEL 6가 PHP 5.3을 배포하던 때, 상류 PHP 5.3은 2014년 8월 14일 지원이 끝났습니다. 그 뒤인 10월 14일에 중요도 Important의 버퍼 오버플로(CVE-2014-3670)가 발견되었습니다. 상류에서 고쳐진 버전은 5.4부터였지만, 5.3 사용자가 5.4로 올리면 하위 호환성이 깨질 수 있었습니다. 그래서 레드햇은 5.3에 수정을 이식하는 길을 택했습니다.

이것이 백포트의 논리입니다. 서버 운영자에게 가장 무서운 것은 보안 패치가 아니라 패치 때문에 멀쩡하던 서비스가 깨지는 일입니다. 번호를 얼리고 수정만 이식하면 "업데이트가 안전하다"는 신뢰가 생기고, 그 신뢰가 자동 업데이트를 가능하게 합니다.

데비안의 보안 FAQ도 같은 취지입니다. 안정판(stable)에서는 새 상류 버전으로 옮기는 것이 좋은 해법이 아니고 관련 변경을 백포트하는 것이 기본이며, 그 이유는 "릴리스가 가능한 한 적게 바뀌어서 보안 수정 때문에 무언가가 예기치 않게 깨지는 일이 없게" 하기 위해서라고 합니다. 반대로 백포트가 불가능할 만큼 소스를 많이 고쳐야 하는 경우에는 새 상류 버전으로 옮기는 예외가 있다고도 적혀 있습니다.

대가: 번호가 정보를 잃는다

백포트의 대가는 번호가 수정 여부를 말해 주지 못한다는 것입니다. 그래서 배포판들은 번호 대신 다른 증거를 냅니다.

• 레드햇은 모든 보안 권고에 CVE 번호를 붙입니다. 2000년 1월부터 해 온 일이라고 합니다. 또 권고를 기계가 읽는 형식으로 옮긴 OVAL 정의를 제공해, 제3자 점검 도구가 백포트를 감안하게 합니다.
• 데비안 FAQ는 안전한 버전인지 알려면 패키지 변경 이력(changelog)을 보거나, 정확한 버전 번호를 보안 권고의 번호와 비교하라고 안내합니다.

이번 사건에서 갈린 길

같은 취약점을 두고 환경마다 다르게 고쳤습니다. 아래 위젯에서 환경을 눌러 보세요.

눈여겨볼 대목이 몇 가지 있습니다.

• 데비안은 이번에 번호를 올렸습니다. 12(bookworm)는 8.2.32-1~deb12u1에서 8.2.35-1~deb12u1로, 13(trixie)은 8.4.24-1~deb13u1에서 8.4.27-1~deb13u1로 올라 PHP 공지의 번호와 직접 비교됩니다. 위에서 본 FAQ의 '백포트가 어려우면 새 상류 버전으로' 예외가 쓰인 것으로 보이지만, 공개된 트래커에는 이유가 적혀 있지 않아 추정입니다.
• 우분투는 상류 번호를 두고 뒤의 접미사만 올립니다. 22.04는 8.1.2-1ubuntu2.28, 24.04는 8.3.6-0ubuntu0.24.04.13입니다. PHP가 정식 수정판을 내지 않은 8.1도 22.04에서는 고쳐졌습니다. 14.04~20.04는 수정 패키지가 있지만 Ubuntu Pro(ESM) 가입자에게만 제공됩니다.
• cPanel EasyApache 4는 7.4 · 8.0 · 8.1용 패키지(ea-php74 7.4.33-19, ea-php80 8.0.30-12, ea-php81 8.1.34-5)를 냈습니다. 겉 번호는 마지막 공식 릴리스(7.4.33 등) 그대로이고 뒤의 빌드 번호만 오릅니다.
• 아마존 리눅스 2023은 php8.2~8.5를 10월 22일에 고쳤지만 php8.1은 'No Fix Planned'입니다. AL2의 기본(Core) php도 같습니다.

크게 보기

3부 · 지원 종료의 지도

백포트는 누군가 수명이 남은 지원 체계를 운영할 때만 가능합니다. 그래서 다음 질문은 "내 PHP 가지가 지금 어디에 있는가"입니다.

PHP의 규칙은 단순합니다. 각 가지는 2년의 활성 지원(버그와 보안 수정을 정기 릴리스로)을 받고, 이어서 2년의 보안 지원(치명적 보안 문제만, 필요할 때만 릴리스)을 받은 뒤 지원이 끝납니다.

이 지도에서 이번 사건의 의미가 드러납니다.

• 수정판이 나온 곳은 8.2~8.5뿐입니다. 이 중 8.2는 12월 31일에 보안 지원이 끝나, 두 달 뒤에는 같은 일이 생겨도 공식 수정판이 나오지 않습니다.
• 8.1은 2025년 12월 31일에 종료됐습니다. 불과 10개월 전입니다. PHP는 7.4 · 8.0 · 8.1용으로 최소 소스 패치를 공개했지만 정식 릴리스는 아닙니다. 직접 빌드할 수 있는 조직이 아니면 쓸 수 없고, 배포판이 같은 일을 대신해 주는 경우에만 일반 운영자가 혜택을 받습니다.
• 7.3 이하는 공식 길이 없습니다. 우분투 Pro(ESM)나 상용 연장 지원 같은 경로가 있을 뿐입니다.

크게 보기

4부 · 숫자로 보는 풍경

워드프레스 사이트의 세 칸

워드프레스가 공개하는 통계(wordpress.org/about/stats, 10월 24일 확인)에서 PHP 버전 분포를 이번 수정이 닿는 정도로 묶어 보았습니다.

• 공식 수정판이 있고 지원이 이어지는 칸(8.3 이상)은 43.3%입니다.
• 수정판은 있지만 연말에 지원이 끝나는 칸(8.2)이 23.8%입니다.
• 공식 수정판이 없는 칸(8.1 이하)은 32.9%이고, 그중 7.4가 15.6%로 가장 큽니다.

주의할 점이 있습니다. 이 통계는 업데이트 확인을 보낸 워드프레스 사이트의 자기 보고라서 웹 전체를 대표하지 않습니다. 또 32.9%는 '취약한 사이트의 비율'이 아닙니다. 우분투 22.04나 cPanel EA4의 고친 패키지를 쓰는 사이트도 이 칸에 들어 있기 때문입니다. 반대로 8.3 이상 칸에 있어도 수정판으로 올리지 않았으면 취약합니다. 버전 분포는 '수정이 닿을 수 있는 사이트의 상한과 하한'이지 취약 비율이 아닙니다.

웹 전체: 버전이 보이는 곳만 보인다

W3Techs(10월 24일)에 따르면 PHP를 쓰는 사이트 중 8.x는 65.4%, 7.x는 26.8%, 5.x는 7.7%입니다. PHP 5와 4를 합쳐 약 7.8%가 8년 넘게 지원이 끝난 가지입니다.

Sockt의 조사는 다른 각도입니다. Sockt가 분석한 사이트 중 헤더 등으로 PHP 버전을 읽을 수 있던 곳은 6,381,009곳입니다. 그중 8.1 이하가 3,175,713곳(49.8%), 8.2~8.5가 3,205,296곳(50.2%)입니다. PHP 5 이하만 58만 곳이 넘습니다. 버전 노출은 PHP 매뉴얼이 끄라고 권하는 설정(expose_php)이고 많은 보안 담당자가 끄기 때문에, 이 숫자는 끄지 않은 사이트의 분포입니다.

"24%"의 정확한 의미

Sockt는 수정 전 번호를 보이던 사이트 중 무작위 100만 곳(번호를 읽을 수 있던 964,653곳)을 10월 22~23일에 다시 방문했습니다. 응답한 824,947곳의 결과는 다음과 같습니다.

• 24.3%는 수정판 번호를 보였습니다. 번호를 올린 사이트라 확실합니다.
• 23.3%는 호스팅거 관리형 호스팅입니다. 호스팅사가 "번호는 그대로이고 수정만 넣었다"고 밝혀 아마 고쳤을 것으로 추정됩니다.
• 52.4%는 옛 번호 그대로라 밖에서는 구분이 불가능합니다. 악용을 시도해 봐야 아는데, 그것은 합법적인 조사가 아닙니다.

Sockt 스스로도 이를 분명히 합니다. 수정한 사이트가 얼마나 되는지 모르고, 많은 사이트가 조용히 고쳤을 수도 있고, 아직 못 고친 곳도 많을 것이라는 입장입니다. "24%만 고쳤다"로 읽는다면 이 조사의 결론이 아닙니다. 이 조사로 알 수 있는 것은 번호가 바뀐 사이트의 수입니다.

크게 보기

크게 보기

5부 · 누가 얼마나 빨리 고쳤나

고쳤는가와 함께 중요한 것은 얼마나 빨리입니다. 확인되는 날짜를 모았습니다.

Amazon Linux의 공개 이슈 트래커(#1148)에는 공개 약 10시간 전인 10월 21일 04:19(UTC)에 수정 요청이 올라왔고, 메인테이너가 06:23에 "인지하고 있으며 업데이트를 준비 중"이라고 답했습니다. 수정 패키지는 이튿날 나왔고 이슈는 10월 22일 07:17에 닫혔습니다. 공개 직후 몇 시간 동안 이슈에는 일정을 묻는 사용자들의 댓글이 이어졌습니다.

이 표에서 읽을 것은 비난이 아니라 구조입니다. 상류 공개와 사용자의 서버 사이에는 배포판이라는 층이 있고, 그 층의 속도가 사용자의 노출 기간을 정합니다. 직접 빌드나 공식 Docker 이미지는 공개와 거의 동시에 올릴 수 있지만 그 대가로 운영을 직접 합니다. 반대로 배포판 패키지는 하루 이틀의 차이가 있어도 호환성을 맡아 줍니다. 어느 쪽이 맞는지가 아니라, 자기 서버가 어느 층에 있고 그 층이 보통 얼마나 걸리는지 알아 두라는 것이 요점입니다.

6부 · 고쳐지지 않는 구간의 선택지

8.1 이하이거나 배포판이 고치지 않는 구간에 있다면 길은 넷입니다.

크게 보기

판단 순서는 대개 이렇습니다. (1) 가능한 한 올린다. (2) 올릴 수 없으면 배포판이 이미 고친 패키지로 옮긴다. (3) 이전 일정이 정해져 있다면 그 사이만 연장 지원이나 소스 패치로 다리를 놓는다. 이전 계획 없는 연장 지원은 문제를 미루는 비용을 매달 내는 일에 가깝습니다. 앞선 글의 임시 완화 조치(방화벽 규칙 등)는 이 모든 선택에서 보조 수단일 뿐입니다.

아마존 리눅스 사용자에게 구체적으로는 이렇습니다. AL2023의 php8.1은 수정 계획이 없으므로 php8.2 이상 패키지로 옮겨야 하고, AL2의 기본 php도 수정 계획이 없으므로 수정이 나온 php8.2 Extra로 옮기는 길이 있습니다. 이 경우에도 8.2는 연말까지입니다.

7부 · 내 서버가 정말 고쳐졌는지 확인하는 순서

질문에 답하다 보면 결론에 닿는 흐름도를 만들었습니다.

배포판 패키지의 경우 확인에 쓰는 일반적인 방법을 적어 둡니다. 패키지에 따라 변경 이력에 CVE 번호를 적는 방식이 다를 수 있으므로, 정본은 각 배포판의 보안 트래커입니다.

# 설치된 PHP의 번호 (상류 번호 + 배포판 접미사)
php -v

# 데비안·우분투: 변경 이력에 CVE 번호가 있는지
apt changelog php8.3-cli | grep -i CVE-2026-109618

# 레드햇 계열·아마존 리눅스
rpm -q --changelog php | grep -i CVE-2026-109618

네 가지를 덧붙입니다.

1. 갱신 뒤에는 재시작합니다. 패키지를 갱신해도 이미 떠 있는 PHP-FPM · Apache 프로세스가 새 코드로 다시 시작되지 않았다면 옛 코드가 메모리에 남아 있을 수 있습니다. 앞선 글의 점검표에서도 가장 먼저 꼽은 항목입니다.
2. 컨테이너는 이미지를 바꿔야 합니다. 호스트의 PHP를 고쳐도 컨테이너 안의 PHP는 그대로입니다. 공식 php 이미지는 8.4.27 같은 상류 번호 태그로 갱신되었으므로 이미지를 다시 받아 재배포해야 합니다.
3. 버전 노출을 끄는 것은 양날입니다. expose_php를 끄면 공격자가 버전을 훑는 일이 어려워지지만, 외부 점검 도구도 같은 이유로 판단이 불가능해집니다(Sockt의 '판별 불가 52%'가 그 모습입니다). 끄는 대신 내부에서 확인하는 체계를 갖추어야 합니다.
4. 점검 도구의 경고를 번호로 반박하지 않습니다. 점검 도구가 "취약"이라고 알릴 때 "우리는 백포트라 괜찮다"고 말하려면, 배포판 권고 번호와 패키지 번호를 적은 증거를 함께 내는 것이 정직한 순서입니다.

8부 · 2026년의 의미: 번호에서 선언으로

버전 번호는 압축된 신호입니다. 하나의 숫자로 수천 개의 변경을 가리키지만, 그 안에 "이 취약점은 고쳐졌다"는 정보는 담겨 있지 않습니다. 백포트가 보편적인 세상에서 번호는 점점 더 불완전한 증거가 됩니다.

그래서 업계는 번호를 보완하는 방법을 오래 모색해 왔습니다.

• CVE 번호를 권고에 붙이는 관행(레드햇은 2000년부터)이 그 시작이었고,
• OVAL처럼 권고를 기계가 읽는 형식으로 내보내 점검 도구가 백포트를 아는 길이 열렸고,
• 최근에는 CSAF 같은 권고 교환 표준과 VEX(어떤 제품이 어떤 취약점의 영향을 받는지 '선언'하는 문서) 같은 형식이 논의됩니다. 이 글을 쓰며 이 부분의 표준 문서까지 확인하지는 못했으므로, 방향만 소개합니다.

방향은 하나입니다. "이 번호면 안전하다"는 추정에서 "이 제품은 이 취약점에 영향을 받지 않는다/고쳐졌다"는 선언으로 옮겨 가는 것입니다.

PHP2Shell이 이 문제를 선명하게 보여 준 이유는 속도입니다. AI가 발견과 입증의 비용을 낮추면 수정판이 나오는 간격은 짧아지고, 사용자 쪽에서 "고쳐졌는가"를 판단하는 일이 더 자주, 더 급하게 닥칩니다. 번호만 보고 판단하는 습관은 오탐과 미탐을 동시에 키웁니다. 코어닷투데이가 앞서 정리한 것처럼 취약점 발견의 속도가 올라간 시대에는, 수정의 속도만이 아니라 수정을 확인하는 속도가 운영의 경쟁력이 됩니다.

오늘 해 볼 만한 일을 하나만 꼽는다면 이것입니다. 운영 중인 서버의 PHP가 어느 층(직접 빌드 · 공식 이미지 · 배포판 패키지 · 호스팅)에서 오는지 목록으로 만들고, 층마다 "무엇으로 고쳐졌음을 확인하는가"를 한 줄씩 적어 두는 것입니다. 그 한 줄이 비어 있는 서버가 다음 번에 가장 오래 노출됩니다.

참고 자료

• Red Hat, "Backporting Security Fixes" (access.redhat.com/security/updates/backporting) — 백포트 정의, RHEL 6 PHP 5.3 사례(CVE-2014-3670), 버전 번호와 점검 도구 오탐, OVAL
• Debian Security FAQ (debian.org/security/faq) — 안정판 백포트 방침, "버전 번호가 취약해 보인다" 항목
• Debian Security Tracker, CVE-2026-109618 · DSA-6574-1 · DLA-4848-1
• Ubuntu Security, CVE-2026-109618 (릴리스별 수정 번호, ESM)
• Red Hat Customer Portal, CVE-2026-109618 (RHSA-2026:87070 외)
• Amazon Linux Security Center, CVE-2026-109618 (ALAS2023-2026-3301~3304, ALAS2PHP8.2-2026-015); amazonlinux/amazon-linux-2023 이슈 #1148
• cPanel, "Critical PHP Security Release - CVE-2026-109618 and CVE-2026-109619" (EasyApache 4 빌드 번호)
• php.net, Supported Versions · End of Life 표 (2026-10-24 확인); php.net 2026-10-21 공지
• WordPress.org, Stats — PHP versions in use (2026-10-24 확인)
• W3Techs, Usage statistics of PHP (2026-10-24)
• Sockt(vu.co.uk), "Who has patched PHP2Shell? I checked nearly 1 million websites" (2026-10-23)
• Hostinger 상태 페이지 공지(번호 변경 없이 수정; Sockt 인용); TuxCare, php2shell patches for EOL PHP (업체 발표)
• docker-library/official-images, library/php (8.x 태그)