PHP2Shell에서 SW 공급망 이슈를 직접 경험하다. (feat. docker)

📖 목차

소프트웨어 공급망의 패치 전파 지연을 직접 경험하다

2026년 10월 21일(KST), 어떤 보안 엔지니어가 엠바고를 깨트리고 PHP2Shell이라고 불리는 PHP RCE(원격코드실행)에 대한 내용을 PHP 개발진들이 대응하기도 전에 공개한 사고가 일어났다.

CVE-2026-109618 — OOM 처리 과정의 메모리 손상
CVE-2026-109619 — 해제된 메모리를 참조하는 전역 상태 문제

두 취약점 모두 CVSS v4.0 기준 9.2점으로 알려졌으며, PHP-FPM을 포함한 웹 요청 처리 환경이 영향 범위에 해당했다.

대략 당일 오후 11시쯤(KST), PHP 개발팀은 PHP 8.5.12, 8.4.27, 8.3.36, 8.2.35를 긴급 배포하면서 즉시 업데이트할 것을 권고했다.

문제는 내가 운영 중인 이 블로그도 공식 Docker 이미지를 사용하고 있어 해당 취약점의 영향권에 포함되어 있었다.

보안 패치 전파 타임라인

2026년 10월 21~22일(KST), 아래는 당시 내가 수집한 내용을 AI를 통해 정리한 표이다.

순서	사건	확인된 결과
1	PHP 긴급 보안 권고 및 수정 버전 공개	PHP 8.4.27 릴리스
2	WordPress Docker 이슈 #1021 생성	공식 이미지 긴급 업데이트 요청
3	docker-library/php PR #1694 생성	PHP 버전 및 빌드 설정 수정
4	PR #1694 CI 검증	68개 검사 통과
5	PR #1694 병합	`e3eaff8` 커밋 반영
6	official-images PR #22541 생성	PHP 공식 이미지 정의 갱신 요청
7	PR #22541 검증 진행	65/71 → 68/71 → 69/71
8	마지막 이미지 조합 검증	8.3 FPM 및 8.5 CLI 테스트 대기
9	CI 댓글 작성 오류 발생	PR 댓글 잠금과 Diff Comment 자동화 충돌
10	PR #22541 검증 완료 및 병합	`tianon` 관리자가 병합
11	Docker Hub 배포 대기	병합 직후 PHP 이미지 갱신 미확인
12	WordPress 이미지 갱신 대기	PHP 8.4.27 반영 이미지 확보 대기

이와 같은 타임라인을 당시 실시간으로 겪으며 소프트웨어 공급망 이슈를 직접 경험해보게 되었다.

WordPress의 Docker 공식 이미지 공급망

아래 도표는 PHP 공급망의 구조를 표시하였다.

PHP Release (당시 보안취약점 Fix 릴리즈)
        |
        v
docker-library/php
        |
        | PR #1694
        | Dockerfile 및 버전 정의 갱신
        v
docker-library/official-images
        |
        | PR #22541
        | 공식 이미지 정의 검증 및 병합
        v
Docker Official Images Build
        |
        | PHP 이미지 빌드 및 배포
        v
php:이미지 이름
        |
        | 갱신된 PHP 베이스 이미지에 의존된 WP 이미지의 리빌드
        v
WordPress Official Image Rebuild
        |
        v
wordpress:php(버전)
        |
        | docker compose pull
        | 컨테이너 재생성![[Title.png]]
        v
Production

PHP Release (당시 보안취약점 Fix 릴리즈)
        |
        v
docker-library/php
        |
        | PR #1694
        | Dockerfile 및 버전 정의 갱신
        v
docker-library/official-images
        |
        | PR #22541
        | 공식 이미지 정의 검증 및 병합
        v
Docker Official Images Build
        |
        | PHP 이미지 빌드 및 배포
        v
php:이미지 이름
        |
        | 갱신된 PHP 베이스 이미지에 의존된 WP 이미지의 리빌드
        v
WordPress Official Image Rebuild
        |
        v
wordpress:php(버전)
        |
        | docker compose pull
        | 컨테이너 재생성![[Title.png]]
        v
Production

하위 이미지가 공식 PHP 이미지를 기반으로 생성되는 구조이므로, 상위 이미지가 변경된 뒤에도 WordPress 이미지의 재빌드와 배포가 필요하다.

즉, 패치 적용 시간은 단일 프로젝트의 수정 완료 시간이 아니라 여러 시스템의 처리 시간과 이슈에 영향을 받는다.

PR에 쏟아진 댓글이 CI 작업에 영향을 주다.

이번 사건에서 예상하지 못한 문제는 GitHub PR에 쏟아진 댓글이었다. 긴급 업데이트를 기다리는 사용자들이 PR에 몰려들었고, 폭포와 같이 쏟아진 댓글에 대해 관리자는 과도한 활동을 제한하기 위해 댓글을 잠갔다.

문제는 이 과정에서 Diff Comment 자동화가 다음 오류를 발생시켰다.

Unhandled error: HttpError:
Unable to create comment because issue is locked.

Unhandled error: HttpError:
Unable to create comment because issue is locked.

자동화가 검증 결과를 댓글로 작성하려고 했지만, 잠금 정책 때문에 실패한 것이었다. 이후 해당 검사는 성공 상태로 변경됐으며, 관리자는 불필요한 활동이 실제 병합 작업을 방해하고 있다고 댓글을 달았다.

다만 이 댓글 작성 오류가 전체 배포 지연의 직접적인 원인이었다고 단정할 수는 없지만, 이미지 공급 파이프라인 중 댓글 작성 기능에 대한 제한이 결합될 경우, 예상하지 못한 권한 충돌이 발생할 수 있음을 보여준 흥미로운 사건이었다.

끝나지 않는 인내의 시간. PR 병합 이후에도 끝나지 않은 업데이트

어찌저찌 docker-library/official-images의 PR ‘#22541’이 병합됐다. 하지만 그 직후 확인한 Docker Hub에서는 여전히 새로운 PHP 버전이 반영된 WordPress 이미지를 확인할 수 없었다.

당연하게도, 위의 작업은 공식 PHP 이미지에 PR 병합 이후 CD가 진행됐을 뿐, 이후 해당 PHP 이미지를 참조하는 도커 공식 이미지들이 반영되어야 했기 때문이다.

그렇게 소프트웨어 공급망 이슈에 갇히다.

그렇게 도커 공식 이미지들에 반영되기 전의 공백 시간에 갇히게 되었다.

이러한 상황에서 이슈 중간 PHP 이미지가 빌드 되었을때 수동으로 PHP와 WordPress 이미지를 빌드하여 다시 블로그를 기동할 수 있었다.

하지만, 공식 이미지가 빌드되는 시간 예측 vs 내가 직접 빌드하는 시간에 대한 비교를 해보았을 때 정확한 시간을 예상하지 못했고 무엇보다 새벽 시간이다보니 피로도 때문에 방향을 바꾸게 되었다.

당시 상태를 확인하려고 간단하게 watch 명령어로 봤던 명령어. (서버는 UTC 시간 기준이다.)

Every 60.0s: sudo docker compose pull wordpress && sudo docker run --rm wordpress:ph...  {hostname}: Wed Oct 21 15:41:08 2026

 Image wordpress:php--- Pulling

 Image wordpress:php--- Pulled

PHP 8.4.26 (cli) (built: Oct 21 2026 00:33:09) (NTS)

Copyright (c) The PHP Group

Built by https://github.com/docker-library/php

Zend Engine v4.4.26, Copyright (c) Zend Technologies

    with Zend OPcache v8.4.26, Copyright (c), by Zend Technologies

Every 60.0s: sudo docker compose pull wordpress && sudo docker run --rm wordpress:ph...  {hostname}: Wed Oct 21 15:41:08 2026

 Image wordpress:php--- Pulling

 Image wordpress:php--- Pulled

PHP 8.4.26 (cli) (built: Oct 21 2026 00:33:09) (NTS)

Copyright (c) The PHP Group

Built by https://github.com/docker-library/php

Zend Engine v4.4.26, Copyright (c) Zend Technologies

    with Zend OPcache v8.4.26, Copyright (c), by Zend Technologies

그래서 내가 내린 결론은 WordPress 공식 이미지가 갱신될 때까지 블로그를 중지하고, Shell 스크립트로 WordPress 이미지를 주기적으로 Pull하여 내부 PHP 버전을 확인하도록 했다. PHP 8.4.27이 확인되면 서비스를 재기동하도록 설정한 뒤, tmux 세션에서 실행해 두고 잠을 자러 갔다.

이후 일어나서 확인해보니 새벽 3시(KST)에 완료되어 다시 기동된 블로그 기록을 확인하게 되었다.

소프트웨어 공급망 이슈에 대한 경험

이번 사건은 공급망이 공격당한 사례가 아니다. 정상적인 소프트웨어 공급망에서 긴급 보안 수정 사항이 하위 사용자에게 전달되는 과정을 직접 관찰한 사례다.

이와 같은 공급망 이슈를 겪으면서 내가 운영한 인프라에서 얻은 점은 다음과 같다.

Upstream의 패치가 프로덕션 패치로 바로 이어지지 않는다.
상위 프로젝트가 취약점을 해결해도 하위 이미지와 운영 컨테이너가 자동으로 안전해지지는 않는다. 하위 이미지도 반영해야하는 시간이 소요되고 이는 곧 이번과 같은 취약점 이슈에 있어 공급망 공백동안 인프라가 위험에 노출 되는 상황에 놓이게 된다.
이미지 의존성은 보안 대응 시간에도 영향을 준다.
베이스 이미지, 공식 이미지 정의, CI 검증, 레지스트리 배포 등 여러 단계가 존재하며, 각각의 지연이 누적되어 예상한 시간보다 더 지체 될 수 있다.
인프라 운영자는 최종적으로 배포된 데이터를 검증해야 한다.
GitHub PR의 성공 여부가 아니라 실제 사용하는 컨테이너에 수정 버전이 적용됐는지가 최종 판단 기준이다.

이번 이슈를 경험하며 이후 블로그 아키텍처에 대한 고민

PHP 보안 취약점으로 블로그가 여러번 공격 시도 및 실제로 당했던 경험(백업은 착실히 해둬서 바로 롤백했다.)을 토대로 이전부터 구성에 대해 고민하긴 했었는데 이번 PHP 공급망 이슈가 블로그 아키텍처에 대한 고민을 확실하게 내려준 것 같다.

오래전 티스토리나 네이버 블로그등을 쓰며 인터렉티브하게 사이트 UI/UX를 수정했던 경험을 토대로 WordPress를 선택하고 지금까지 운영하면서 만족하면서 썼다.

하지만, 이제는 움직여야할 때가 온것 같다. 현 블로그 구성을 보았을 때, 동적 런타임 환경(Dynamic Runtime Environment)보다는 정적 페이지여도 충분해보인다. 이번 일을 통해 블로그 아키텍처 구성에 대하여 다시 바라보는 질문을 스스로 하게 되었다.

이후, 블로그에 조만간 큰 변화가 있을지도 모르겠다.

BANSEOK