# PHP 취약점, 무엇이 얼마나 위험한가?

> https://bookfactory.kr/board/news/23406
> 게시판: 뉴스
> 작성자: admin
> 작성일: 2026-10-23T10:03:19.344Z

---

php2shell 의 본丸은 RCE 가 아닙니다. PHP 는 메모리 부족에도 불구하고 살아남았습니다.

CVE-2026-109618 과 CVE-2026-109619. 통칭 php2shell.

이름만 보면 WordPress 플러그인일지, 오래된 PHP 설정 오류일지, 아니면 PHP-CGI 특유의 버그일지 헷갈립니다.

그렇지 않다.

원인은 WordPress 나 Drupal, Joomla 가 아닙니다. 연구팀은 취약한 코드가 PHP 자체에 내장되어 있어, 애플리케이션 측 코드가 안전하더라도 'Hello World'만 반환하는 단순한 앱조차 영향을 받을 수 있다고 설명했습니다.

문제는 애플리케이션이 아니었다. 메모리 부족으로 인해 손상된 내부 상태를 유지하며 처리를 계속했던 PHP 가 문제였다.

PHP CNA 가 평가한 CVSS 4.0 점수는 9.2 입니다. NVD 가 부여한 CVSS 3.1 점수는 9.8 입니다. 평가 방식은 다르지만, 둘 다 '중요 (Critical)' 등급에 해당합니다.

PHP 8.2 시리즈로 공통으로 적용된 수정 커밋을 자세히 확인한 결과, 변경된 파일이 389 개, 추가된 코드가 10,759 줄, 삭제된 코드가 988 줄에 달합니다. 이는 위험한 함수 하나를 수정하는 수준이 아닙니다.

이 글의 목적은 하나에 집중하는 것입니다.

왜 단순한 메모리 부족이 인증 없이 원격 코드 실행으로 악용되었는지.

공격용 페이로드나 재현 코드는 게시하지 않습니다. CVE 원문, PHP 공식 발표, PHP Foundation 설명, 그리고 php-src 수정 차이를 활용하여 취약점의 구조와 방어 방법을 추적합니다.

본 글은 2026 년 10 월 22 일 현재 공개된 정보를 바탕으로 작성되었습니다. 공격 및 방어 상황은 변경될 수 있습니다.

PHP 가 무엇인지 궁금한 분은 여기로.

## 동영상 제작자분은 여기로

## 시간이 부족한 분들을 위한 요약본

결론부터 말씀드리면,

- php2shell 은 PHP 자체의 취약점이며, 특정 CMS 나 프레임워크의 취약점이 아닙니다.
- 공격자는 HTTP 입력을 활용하여 PHP 가 메모리 한계 등 치명적인 오류에 도달하는 시점을 노립니다.
- PHP 은 OOM 발생 시 longjmp 기반의 bailout 메커니즘을 통해 처리를 탈출하지만, 일부 경로는 중간 상태를 완전히 정리하지 않는 경로가 존재합니다.
- CVE-2026-109618 은 동일한 요청의 종료 처리가 불완전한 데이터를 사용하도록 설계된 취약점입니다.
- CVE-2026-109619 는 손상된 글로벌 상태가 동일한 워커의 다음 요청까지 잔류합니다.
- mod_php 에서 애플리케이션 코드가 실행되기 전에 확인된 경로입니다.
- PHP-FPM, php-cgi, FrankenPHP, LiteSpeed 를 포함한 웹 요청을 처리하는 PHP 환경은 모두 업데이트 대상입니다.
- 완전한 대응책은 수정 버전으로의 업데이트입니다. 설정 변경과 WAF 는 임시 조치에 불과합니다.
- 패치 적용 전 공개되었던 서버는 업데이트 후에도 침해 조사 필요

수정판은 다음과 같습니다.

- PHP 8.2.35
- PHP 8.3.36
- PHP 8.4.27
- PHP 8.5.12

EOL 시리즈인 PHP 7.4, 8.0, 8.1 에도 이번 사태의 중요성을 고려하여 최소한의 소스 코드 백포팅이 공개되었습니다. 새로운 버전 번호의 릴리스는 아니라는 점을 유의하시기 바랍니다. 다만, 이는 EOL 운영이 앞으로도 보장되는 것은 아닙니다.

### 공개 시점의 악용 현황

2026 년 10 월 22 일 JST 시간 14:51 에 획득한 CISA Known Exploited Vulnerabilities Catalog(catalogVersion 2026.10.21) 에는 CVE-2026-109618 과 CVE-2026-109619 도 포함되어 있지 않았습니다.

다만, 이는 안전 선언이 아니며, 미공개된 것은 악용되지 않았음을 증명하는 것이 아닙니다.

PHP Foundation 은 공개 당시 작동하는 익스플로이트가 확인되지 않았다고 설명하고 있습니다. 반면, 공개 전 유출된 동영상은 다양한 PoC 개발을 가속화시켰다고도 언급하고 있습니다.

따라서 PoC 가 배포되기 전에 업데이트합니다.

## 목차

- 동영상 채널은 여기입니다.
- 시간이 부족한 분들을 위한 요약본
- 공개 당시 악용 현황
- 메모리 부족은 서버를 끄는 것뿐이라고 생각했습니다.
- 2. 두 개의 CVE 는 서로 다른 시간축에서 동일한 고장 패턴을 사용합니다.
- CVE-2026-109618 은 동일한 요청 내에서 발생합니다.
- CVE-2026-109619는 다음 요청까지 지속됩니다.
- 3. 이는 WordPress 의 취약점이 아닙니다. WordPress 가 도달하기 전의 취약점입니다.
- 4. 어떤 버전을 수정해야 할까
- 5. 수정 커밋 389 가 나타내는 내용

## 메모리 부족은 서버를 멈추는 것뿐이라고 생각했습니다.

PHP 의 memory_limit 은 안전장치로 간주되는 경우가 많습니다.

스크립트가 메모리를 과도하게 사용하여 최대 한계에 도달했고 치명적 오류가 발생하여 해당 요청이 실패했습니다. 다음 요청은 초기 상태로 시작됩니다.

일반적으로 그렇게 생각합니다.

php2shell 이 무너진 것은 이 마지막 전제가 무너졌기 때문입니다.

PHP 가 메모리 부족이 발생한 순간, C++ 의 예외처럼 스택을 단계별로 안전하게 되돌리는 것은 아니었습니다. 깊은 처리에서 빠져나오기 위해 longjmp 를 사용하는 bailout 기법을 널리 사용했습니다.

이 탈출은 빠릅니다. 하지만 중간에 있는 코드가 OOM 을 고려하지 않았다면, 초기화 중인 포인터나 이미 해제된 메모리를 가리키는 글로벌 상태가 남게 됩니다.

そのあとに終了処理が走る。あるいは、同じ常駐ワーカーが次のHTTPリクエストを処理する。

그 결과 PHP 는 손상된 데이터를 정상적인 내부 객체로 처리해 버립니다.

![画像](https://assets.st-note.com/img/1792654789-VeYDAlK2IOk9sZQEfRoSqWzc.png?width=1200)

여기서 중요한 점은 메모리 부족 자체가 원격 코드 실행 (RCE) 이라는 점입니다.

본丸은 메모 부족 이후 남은 상태를 재사용할 수 있다는 점에 있습니다.

메모리 제한이 공격을 막는 벽이 아니라, 공격자가 PHP 의 내부 상태를 파괴할 타이밍을 맞추는 마커가 되어버렸습니다.

## 두 개의 CVE 는 서로 다른 시간축에서 동일한 취약점을 활용합니다.

CVE-2026-109618 과 CVE-2026-109619 는 서로 다른 버그로 보입니다.

CVE 원문과 공식 어드바이서를 함께 읽으면 공통된 인과관계가 매우 명확해집니다.

- 공격자가 인증 전 HTTP 입력을 전송합니다.
- PHP 가 입력 파싱이나 세션 처리 과정에서 메모리 한계 등 치명적인 에러를 발생시킬 수 있습니다.
- 구제금융을 통해 일반적인 처리 경로를 이탈합니다.
- 초기화 중 또는 해방 후 상태가 잔존합니다.
- PHP 는 그 상태를 나중에 재사용합니다.
- 메모리 파괴나 Use-After-Free 취약점을 통해 원격 코드 실행 (RCE) 으로 이어지는 과정

차이는 5 번이 언제 일어날지입니다.

![画像](https://assets.st-note.com/img/1792654826-VF7lDty6qHRP8mX5EL4gcTWY.png?width=1200)

### CVE-2026-109618 은 같은 요청 내에서 발생합니다.

CVE-2026-109618 은 요청 처리 중 메모리 부족 (OOM) 이 발생했을 때, 요청 전용 메모리에 초기화가 불완전한 상태가 남게 됩니다.

원래는 Fatal error 로 끝났으면 좋겠었다.

그러나 요청 종료 시점의 처리가 계속되어 불완전한 데이터를 유효한 것으로 사용하게 됩니다. PHP 공식 자문 (GHSA) 은 Apache mod_php 에서 요청 본문 자동 분석 중 이 문제가 발생하며, 애플리케이션 코드 실행 전에 완료된다고 설명하고 있습니다.

즉, 손상된 요청과 손상된 상태를 사용하는 요청은 동일하다.

### CVE-2026-109619는 다음 요청까지 유효합니다.

CVE-2026-109619 는 더욱 기가 막힌 일이다.

OOM 과 같은 치명적인 오류로 인해 요청이 중단되더라도, 해제된 메모리를 가리키는 글로벌 변수가常驻 프로세스에 남아 있을 수 있습니다.

동일한 PHP 워커가 다음 HTTP 요청을 받으면, 포인터가 완전히 초기화되기 전에 사용되어 Use-After-Free 오류가 발생합니다.

이것은 요구 A 에서 상태를 파괴하고 요구 B 에서 사용합니다.

PHP 공식 자문 (GHSA) 은 확인된 영향으로 RCE뿐만 아니라 Use-After-Free와 메모리 노출도 포함하고 있으며, 확인된 취약점 경로는 세션 업로드 진행 처리와 PHP 8.5 의 Fatal error 백트레이스입니다.

즉, HTTP 요청이 종료되어도 워커의 메모리는 종료되지 않았다는 뜻입니다.

## 3. 이는 WordPress 의 취약점이 아닙니다. WordPress 가 도달하기 전의 취약점입니다.

이 취약점을 CMS 관점에서 해석하면 대응책을 잘못 선택할 수 있습니다.

연구팀은 WordPress, Drupal, Joomla 에서의 설치 여부를 확인했습니다. 그러나 이 세 가지가 취약점을 포함하고 있어 제거된 것은 아닙니다.

PHP 가 앱을 시작하기 전에 HTTP 입력을 슈퍼글로벌로 변환하고 요청 상태를 초기화합니다. 이 단계에서 파손될 수 있는 경로가 있습니다.

특히 Apache mod_php 의 확인된 경로에서는 공식 애드바이저가 지적하듯, 애플리케이션 코드를 한 줄도 실행하지 않고 기본 설정으로 인증 없이 원격 코드 실행 (RCE) 으로 이어진다고 설명합니다.

![画像](https://assets.st-note.com/img/1792654847-6n9EqFHtTU0z25KrOdWNfwmM.png?width=1200)

이 위치 관계는 무겁습니다.

- WordPress 를 최신 버전으로 업데이트합니다.
- 플러그인 수 감소
- 로그인을 다중 인증으로 변경하세요
- SQL 인젝션 방지
- PHP 코드를 검토합니다.

모든 것이 중요하지만, php2shell 의 완전한 제거는 아닙니다.

문제는 WordPress 가 아니라, WordPress 를 실행하기 전의 PHP 입니다.

PHP-FPM 은 다소 상황이 다릅니다. GHSA-109618 에 따르면, FPM 은 요청 시작 실패 시 자 프로세스를 종료하므로 mod_php 와 동일한 앱 의존성 없는 경로는 성립하기 어렵습니다. GHSA 는 FPM 에서 완전한 익스플로이트가 아직 검증되지 않았다고 명시하고 있습니다. 반면 PHP Foundation 과 PHP2Shell 공식 사이트는 앱 측 코드 경로를 거친 FPM 상의 RCE 를 확인했다고 밝히고 있어, 출처에 따라 서술 방식이 달라집니다. GHSA-109619 의 세션 라이프사이클 경로는 GHSA 가 mod_php 와 FPM 모두에서 RCE 를 검증했다고 명시하고 있습니다.

FrankenPHP 나 LiteSpeed 계열도 설정이나 SAPI 구현에 따라 조건이 달라집니다. 이 부분을 보고 '나에게는 FPM 이므로 무관하다'고 단정 짓는 것은 위험합니다.

PHP.net 의 공식 공지사항은 모든 PHP 모드 업데이트 대상에 대해 명시하고 있습니다.

## 4. 어떤 버전을 수정해야 할까

2026 년 10 월 21 일과 22 일, PHP 프로젝트는 다음 보안 릴리스를 발표했습니다. 현재 사용 중인 클론의 NEWS 파일을 확인하면 8.2.35 와 8.3.36 이 2026 년 10 월 21 일, 8.4.27 과 8.5.12 이 2026 년 10 월 22 일로 표시됩니다. 날짜 순서는 오래된 버전이 먼저, 새로운 버전이 다음 날인 순서입니다. 날짜로 검색할 경우 한쪽 버전을 놓칠 수 있으니 주의하시기 바랍니다.

지원 중인 공식 수정 버전은 총 4 가지입니다.

- PHP 8.2.35
- PHP 8.3.36
- PHP 8.4.27
- PHP 8.5.12

PHP.net 의 공지사항에 따르면, PHP 보안 팀은 PHP 8.1 이전 버전이 PHP 프로젝트의 업데이트 대상이 아님을 명시하면서도 이번에는 최소한의 소스 코드 백포팅을 준비했습니다.

- PHP 7.4
- PHP 8.0
- PHP 8.1

이 패치는 php-src 브랜치로 공개되었으며, 7.4.34 와 같은 새로운 버전 번호가 붙어 있지 않습니다. 내 클론을 확인해 보면 각 브랜치의 PHP_VERSION 은 여전히 7.4.31-dev, 8.0.30, 8.1.34 로 남아 있었습니다. 8.1.34 는 2025 년 12 월에 출시된 최종 버전과 동일한 번호입니다. 즉, EOL 시리즈의 경우 버전 번호만으로 패치가 적용되었는지 여부를 판단할 수 없습니다.

![画像](https://assets.st-note.com/img/1792654868-Q3Ouk7jwhdP4vbqiDAsNWmZG.png?width=1200)

이곳에는 다소 복잡한 점이 있습니다. 정보원에 따라 다루는 대상 범위가 다르기 때문입니다.

- CVE.org 의 기계 가독성 데이터에는 PHP 8.2 에서 8.5 까지 나열되어 있습니다.
- 연구팀 (Wiz 와 PHP2Shell 공식 웹사이트) 은 피해 릴리스가 PHP 5.4 까지 거슬러 올라간다고 밝히며, 수정 전 버전의 거의 모든 버전이 적어도 1 건의 취약점을 포함한다고 설명했습니다.
- PHP 프로젝트는 EOL 시리즈인 PHP 7.4, 8.0, 8.1 을 위한 소스 백포팅을 준비했습니다.
- PHP 5.4 에서 7.3 까지의 시리즈에는 상위 버전의 수정본이 없으며, 백포팅 대상에도 포함되지 않았습니다.

따라서 CVE 의 영향 대상 항목이나 위 그림에 명시되지 않은 사항을 보안 근거로 삼을 수 없다. CVE 레코드에 PHP 7.3 가 언급되지 않았다고 해서 안전한 것이라고 해석할 수 없다.

구체적인 시리즈는 취약점이 없는 것이 아니라, 상류 버전이 일반적인 수정 대상에서 제외되어 버린 것입니다.

또한 Linux 배포판은 PHP_VERSION 을 크게 변경하지 않고 수정만 백포팅하는 경우도 있습니다. Ubuntu 나 Debian, RHEL 계열의 패키지는 단순한 숫자 비교만으로 판단하지 않고, 배포元の 보안 공지서와 비교해야 합니다.

## 5. 수정 커밋 389 가 나타내는 내용

PHP 의 공식 수정 커밋을 확인했습니다.

커밋 내용은 다음과 같습니다.

제공해주신 해시값 (`3584a98bda0f2c0d367255b046798b0d3a221a19`) 만으로는 해당 게시글의 본문 내용을 확인하여 번역할 수 없습니다. 해시값은 게시물의 고유 식별자일 뿐이며, 실제 텍스트 내용은 이 값에 포함되어 있지 않습니다.

해시값을 통해 해당 게시물의 내용을 확인하거나, 본문 텍스트를 직접 입력해 주시면 즉시 자연스럽고 정확한 한국어로 번역해 드리겠습니다.

제목은 '구제금융을 통한 국가 부패 방지'입니다.

변경된 파일은 총 389 개이며, 그중 PHP 테스트 파일은 266 개, C 코드나 헤더 파일 등 소스 기반 파일은 109 개입니다. 차이점은 추가된 10,759 줄과 삭제된 988 줄이었습니다.

나머지 14 개의 파일 내용도 열어보았지만, run-tests.php 나 tests 하위 디렉토리의 .inc 파일들처럼 테스트 관련 코드가 대부분이었습니다. 테스트 관련 파일을 다시 세어보니 총 389 파일 중 279 파일로 전체의 약 72% 를 차지합니다. 고치는 것보다, 두 번 같은 오류를 반복하지 않도록 방망이를 치는 데 훨씬 더 많은 시간이 소요됩니다.

![画像](https://assets.st-note.com/img/1792654893-wKnajUedYQ8WDB0xmoFyAP7S.png?width=1200)

수정 사항 요약에는 두 가지 원칙이 명시되어 있습니다.

- OOM 발생 시 bailout 을 UnwindExit 로 대체합니다.
- 시작 및 초기화 요청 시 참조될 수 있는 전역 변수를 적절히 초기화합니다.

차이를 추적하면 세션.c 의 포인터를 NULL 로만 설정한 것만은 아닙니다.

메모 확보 실패 정보를 delayed_oom 에 저장하고 안전한 VM 경계까지 롤백합니다. 일반적인 memory_limit 와 실제 할당을 중단하는 hard limit 사이에 여유 공간을 확보하여, 오류 메시지 생성 및 안전한 롤백에 필요한 메모리를 확보합니다. 요청 시작 전 글로벌 초기화도 광범위하게 재검토합니다.

요컨대, PHP 는 OOM 을 즉시 종료하는 절벽으로 간주하던 방식을 버리고, 착지할 수 있는 곳까지 제어하여 안전하게 종료하도록 설계 변경했습니다.

389 파일이라는 규모는 이번 두 버그가 우연히 겹친 것이 아니라, 동일한 설계 전제에서 비롯된 것임을 보여줍니다.

## 6. AI 가 찾아냈다. 하지만 AI 의 업적만 강조하면 본질을 벗게 된다.

php2shell 은 AI 에이전트가 실제 세계의 중대한 취약점을 신속하게 탐지한 사례입니다.

Wiz Research 는 자체 Wiz Atlas 를 비롯해 Google 의 Gemini 4 Argon 과 OpenAI 의 GPT-5.6 Sol 을 활용하여 발견, 취약점 활용, 개발, 패치 검증 등 전 과정을 수행했다고 공표했습니다. 특히 Gemini 4 Arg on 의 기여도가 크었다고 명시했습니다.

PHP Foundation 은 Anthropic 의 Claude Mythos 를 사용하여 PHP 를 스캔한 후, OpenAI 의 Daybreak Red 를 보고 및 취약점 검증에 활용했다고 밝혔습니다.

다른 보고서 작성자 칼리프 또한 GPT-5.6 Sol 을 사용하여 독립적으로 취약점을 발견했습니다. PHP Foundation 에 따르면 감사 시작일은 2026 년 7 월 30 일이며, 8 월 11 일 연구자 라이언 A 는 해당 재단이 '조건부 없는 RCE'라고 표현한 다른 경로를 보고했다고 밝혔습니다.

하지만 AI 가 인터넷을 스스로 구원한 것은 아닙니다.

인간 연구자들이 결과를 검증하고, PHP 유지보수 담당자가 영향 범위를 철저히 검토한 뒤 수정 설계를 작성하여 여러 버전에 백포팅했으며, 관련 기관들이 협력하여 공개를 진행했습니다.

OpenAI 역시 동일한 능력이 공격 도구나 익스플로이트 개발을 가속화할 수 있다고 인정하고 있습니다. 따라서 AI 의 능력이 향상될수록 샌드박스, 허가된 경계, 감사 로그, 그리고 인간 승인 등이 더욱 중요해집니다.

이번에는 놀라운 점은 AI 가 CVE 를 취한 것뿐만 아니라,

오랜 시간 동안 오버헤드 (OOM) 예외 발생 경로를 파악하지 못했으나, 여러 팀과 모델이 서로 다른 방향에서 해당 경로를 추적해냈고, 결국 런타임 전체의 수정으로 이어진 것입니다.

OpenAI 는 알려진 바에 따르면 공격자가 프론티어 AI 를 발견하기 전에 이를 발견했다고 서술하고 있습니다. 이를 통해 수정과 방어 준비 시간을 확보할 수 있었습니다. OpenAI 는 이를 방어 측의 창이라고 부릅니다.

그 창은 공개되는 순간에 닫힙니다. 수정 사항과 조언이 전 세계에 공개되었으므로 공격 측도 현재 동일한 자료를 보고 있습니다. 먼저 발견해 주신 여유는 업데이트를 끝까지 견딜 수 있을 때까지만 남습니다.

## 7. 우선 무엇을 해야 할까. 답은 PoC 검증이 아닌 업데이트다.

이 취약점을 통해 공개된 PoC 가 자신의 환경에서 작동하는지 확인하는 것은 불필요합니다.

재현되지 않았다고 해서 안전하다고 할 수 없습니다. SAPI, 할당기, 확장, 앱 경로, 요청 할당 패턴에 따라 성립 조건이 달라지기 때문입니다.

진행 순서는 다음과 같습니다.

### 1. PHP 런타임 전체 개수 세기

CLI 에서 `php -v` 를 한 번만 실행하여 종료하지 마십시오.

- Apache 의 mod_php
- PHP-FPM 각 풀
- php-cgi
- Docker 와 Kubernetes 의 각 이미지
- 프랭켄 PHP
- 라이트스피드/LSAPI
- cron 와 워커가 실행하는 별도의 이진 파일
- 개발 환경과 프로덕션 환경

웹 서버에서 사용하는 PHP 와 로그인 쉘의 PHP 는 다를 수 있습니다.

### 2. 수정판 또는 배포원의 수정된 패키지로 업데이트

지원 중인 시리즈는 8.2.35, 8.3.36, 8.4.27, 8.5.12 이상을 기준으로 합니다.

EOL 시리즈를 사용 중이라면, 긴급 백포팅은 시간을 절약하는 수단이 아니라 마이그레이션을 불필요하게 만드는 용서할 수 있는 이유가 될 수 없습니다.

### 3. 모든 워커를 재시작합니다

109619 는 프로세스 내의 글로벌 상태가 요청을 가로지르는 문제입니다.

패키지를 교체하더라도 오래된 PHP-FPM 워커나 Apache 프로세스를 남기지 않아야 합니다. 롤링 업데이트를 수행하더라도 기존 프로세스가 완전히 제거되었는지 반드시 확인해야 합니다.

### 4. 실제로 응답한 런타임 재확인

이미지 태그나 패키지 목록뿐만 아니라, 실행 중인 Pod, 컨테이너, FPM 풀, Apache 모듈의 실제 상태를 확인합니다.

공개된 phpinfo 페이지를 생성하면 다른 정보 유출을 초래할 수 있습니다. 관리 측면, 컨테이너 내부, 배포 로그, SBOM(소프트웨어 빌드 오브젝트 목록) 등 안전한 경로를 통해 확인하세요.

### 5. 패치 전 노출 기간 확인

업데이트는 향후 침입을 방지합니다. 과거 침입은 복구할 수 없습니다.

Wiz 와 PHP2Shell 공식 웹사이트는 취약한 경로가 애플리케이션 레이어보다 아래에서 동작하기 때문에 애플리케이션 로그에 흔적이 거의 남지 않을 수 있다고 경고하고 있습니다.

PHP2Shell 공식 웹사이트는 조사 단서를 위해 다음 세 가지를 제시하고 있습니다.

- 비정상적으로 크거나 형식이 손상된 PHPSESSID 응답 쿠키
- 비자연적인 멀티파트 요청 이후 발생하는 메모리 한계 오류 또는 500 응답의 반복
- 설명되지 않는 PHP 워커의 충돌 및 재시작

이러한 것 외에도 침입 후 남는 흔적도 확인하고 싶습니다.

- PHP 워커를 통한 의심스러운 자 프로세스 실행
- 웹 서버나 PHP 를 통한 외부 의심스러운 통신
- 웹 루트, 크론, systemd, authorized_keys 설정 변경
- PHP 프로세스가 읽을 수 있는 인증 정보 및 클라우드 자격 증명 이용 내역

다만, 단일 탐지 규칙으로 모든 경로를 포괄하는 것은 어렵습니다. 이러한 징후가 있더라도 악용이 입증되는 것은 아니며, 없더라도 무사함을 증명하는 것도 아닙니다. 공식 웹사이트 자체가 이를 강조하고 있습니다.

침해 의도가 의심될 경우, 기밀 정보의 순환과 기존 정상 이미지로부터의 재 배포를 고려하십시오.

## 8. 현재 사용 중인 PHP 코드를 안전하게 재고 관리하는 스크립트도 작성했습니다.

공격 요청 없이도 로컬 PHP 버전, SAPI 및 설정만 확인하는 감사 스크립트를 함께 제공했습니다.

동봉 패키지를 펼친 루트에서 다음과 같이 실행합니다.

다른 PHP 바이너리를 확인하려면 경로를 전달해야 합니다.

JSON 출력도 가능합니다.

이 스크립트가 확인하는 항목은 다음과 같습니다.

- PHP 버전
- PHP 실행 환경
- 로딩된 php.ini
- 메모리 한계
- 업로드 진행 상황 표시 활성화
- PHP 8.5 의 fatal_error_backtraces
- 공개된 수정판과의 비교
- EOL 시리즈와 배포 백포팅의 미지원 사항

다만, CLI 가 안전하다고 해서 웹 측이 반드시 안전하다고 할 수 없습니다. 컨테이너, FPM, Apache, 호스트별로 실행하기 위한 점검 보조 도구일 뿐, 취약점 스캐너의 대용이 될 수 없습니다. CLI 로 읽을 수 있는 php.ini 의 값도 FPM 또는 Apache 설정과 다른 경우가 많습니다.

또한 PHP 8.1 이전의 EOL 시리즈와 수정 전에 종료된 RC 버전은 버전 번호만으로는 수정 여부를 판단할 수 없습니다. 스크립트 판단과 무관하게 배포원이나 빌드원에서 수정이 반영되었는지 확인해 주시기 바랍니다.

## 9. 수시간 동안 업데이트가 불가능한 임시 조치

PHP.net 은 업데이트 완료까지의 임시 조치도 공개했습니다.

### 메모리 제한 비활성화

`memory_limit=-1` 은 CVE-2026-109618 확인된 경로를 일부 차단합니다.

앱을 통한 덮어쓰기 설정이 불가능한 방법 (FPM 풀이나 Apache 설정의 php_admin_value 등) 으로 설정한 후, 어느 곳에서든 유한한 값으로 되돌아가지 않았는지 확인해야 합니다. 공식 가이드라인은 RLIMIT_AS 나 RLIMIT_DATA 를 대안으로 설정하는 것은 역효과를 낸다고 경고하고 있습니다.

다만, 이는 PHP 의 상한선을 벗어날 수 있도록 설정한 것입니다. 공격자가 호스트나 컨테이너의 실제 메모리를 고갈시키면 여전히 위험한 OOM 상태에 도달할 수 있으며, DoS 견고성도 저하됩니다.

### 세션 업로드 진행 상태를 비활성화합니다

`session.upload_progress.enabled=0` 설정은 CVE-2026-109619 확인된 세션 경로를 일부 차단합니다.

`.user.ini` 는 요청 단위 대신 서버 전체 설정으로 적용되며, 모든 워커를 재시작해야 합니다.

### PHP 8.5 의 Fatal error 백트레이스를 비활성화하는 방법

PHP 8.5 에서 `fatal_error_backtraces=0` 설정은 확인된 경로의 일부 백트레이스를 억제합니다.

### WAF 입력 범위를 제한하다

비정상적으로 긴 본문, 과도하게 깊은 입력, 위험한 multipart 구조를 제한하는 것은 공격 비용을 증가시킬 수 있습니다.

그러나 정상적인 업로드나 대형 폼을 파괴할 수 있으며, 임계값에 따라 DoS 공격을 유발할 수도 있습니다. 무엇보다도 할당 패턴은 SAPI나 애플리케이션에 따라 달라집니다.

모두 근본적인 치료가 아닙니다.

설정에서 시간을 보내는 것보다 PHP 를 업데이트하는 것이 더 저렴합니다.

## 10. php2shell 에서 얻어야 할 교훈

이 사건을 PHP 가 낡아서 위험하고 AI 가 제로데이 취약점을 발견했다는 이야기로만 끝내지 말아야 한다.

교훈은 더욱 보편적이다.

### 오류 처리는 정상 시스템보다 공격 표면이 더 넓어집니다.

입력 검증, 인증, 암호화, SQL 만으로는 부족합니다.

OOM, 타임아웃, 취소, 예외, 신호, 부분 초기화. 평소 거의 사용되지 않는 종료 경로는 상태 기계의 전제 가정이 쉽게 무너집니다.

### 常駐プロセスでは、リクエスト終了は境界ではない

FPM, Apache, 그리고 애플리케이션 서버 모두 프로세스 재사용을 사용합니다.

로컬 요청을 가정하여 생성된 상태가 글로벌 환경이나 캐시에 남아있으면 요청 A 의 실패가 요청 B 의 취약점으로 이어질 수 있습니다.

### 메모리 한계는 보안 경계가 아닙니다.

상한선이 있다는 것이 안전을 보장하지는 않는다.

최한계에 도달하는 순간, 어떤 데이터가 초기화되었는지, 어떤 데이터가 공개되었는지, 어떤 종료 처리가 실행되는지까지 설계되어야 비로소 안전 장치가 완성됩니다.

### 패치 행 수는 원인의 깊이를 반영합니다.

389 파일 수정은 매우 큽니다.

하지만, 임의로 두 개의 포인터만 NULL 로 설정하는 것보다 런타임 전체의 OOM 처리 방식을 변경하는 것이 향후 유사한 버그를 줄일 수 있습니다.

## 결론은 지키려던 것이 앱만은 아니었다는 점이다.

php2shell 을 한 마디로 표현하자면, PHP 의 메모리 부족을 원격 코드 실행 (RCE) 취약점으로 전환하는 것입니다.

하지만, 조금 더 정확하게 표현하면 다음과 같이 된다.

PHP 는 메모리 부족으로 멈추려 했으나 완전히 멈추지 못했습니다.

CVE-2026-109618에서는 동일한 요청의 종료 처리가 손상된 상태로 실행되었습니다.

CVE-2026-109619에서는 동일한 워커의 다음 요청이 손상된 상태로 처리되었습니다.

따라서 앱 인증 이전부터 존재하며, CMS 를 선택하지 않고 설정이나 SAPI 에 따라 형태를 바꾸었다.

지금 우리가 해야 할 일은 화려한 PoC 를 감상하는 것이 아닙니다.

PHP 런타임 전체를 세고 수정 버전으로 배포합니다. 워커를 모두 교체하고 패치 전 노출을 확인합니다.

그 정도다.

메모리 부족으로만 떨어졌을 뿐입니다.

그 한 줄을 이제 로그에서 놓쳐서는 안 된다.

## 참고 자료

CVE.org CVE-2026-109618 — PHP CNA 를 통한 OOM corruption 을 이용한 RCE 의 원문과 CVSS 4.0 평가

제공해주신 링크 (CVE-2026-109618) 는 아직 발행되지 않은 미래의 취약성 기록 ID 이며, 해당 게시물의 실제 본문 텍스트가 제공되지 않았습니다. 따라서 요청하신 243/276 번째 청크의 내용을 번역할 수 없습니다. 만약 게시물의 실제 텍스트 내용을 직접 입력해 주시거나, 해당 게시물의 요약본이나 다른 청크를 제공해 주시면 즉시 자연스럽고 정확한 한국어로 번역해 드리겠습니다.

CVE.org CVE-2026-109619 — Use-After-Free 취약점의 원문과 CVSS 4.0 점수

제공해주신 링크 (CVE-2026-109619) 는 아직 발행되지 않은 미래의 취약성 기록 ID 이며, 해당 게시물의 실제 본문 텍스트가 제공되지 않았습니다. 따라서 요청하신 245/276 번째 청크의 번역을 수행할 수 없습니다. 만약 게시물의 실제 텍스트 내용을 직접 입력해 주시거나, 해당 CVE 기록의 상세 내용 (예: 취약점 명세, 영향받는 시스템, 해결 방법 등) 을 요약하여 제공해 주시면, 즉시 자연스럽고 정확한 한국어로 번역해 드리겠습니다.

NVD CVE-2026-109618 — NVD 가 수행한 CVSS 3.1 점수

제공해주신 링크 (https://nvd.nist.gov/vuln/detail/CVE-2026-109618) 는 아직 공식적으로 발표되지 않은 미래의 취약점 ID(CVE-2026-109618) 로, 해당 게시글의 실제 본문 콘텐츠가 존재하지 않습니다. 따라서 요청하신 247/276 번째 청크의 번역을 수행할 수 없습니다. 만약 실제 게시글의 텍스트 내용을 직접 입력해 주시거나, 해당 취약점의 기술적 배경 (예: NVD 데이터베이스에 포함된 일반적인 취약점 설명 형식) 을 바탕으로 가상의 예시를 원하신다면, 그 내용을 알려주시면 즉시 번역해 드리겠습니다.

NVD CVE-2026-109619 — NVD 가 수행한 CVSS 3.1 점수

제공해주신 링크 (https://nvd.nist.gov/vuln/detail/CVE-2026-109619) 는 아직 공식적으로 발표되지 않은 미래의 취약점 ID(CVE-2026-109619) 로, 해당 게시글의 실제 본문 내용이 존재하지 않습니다. 따라서 요청하신 249/276 번째 청크의 번역을 수행할 수 없습니다. 만약 실제 게시글의 텍스트 내용을 직접 입력해 주시거나, 해당 취약점의 기술적 배경 (예: NVD 데이터베이스에 등록된 실제 CVE 정보) 을 바탕으로 가상의 번역본을 원하신다면, 그 내용을 알려주시면 즉시 번역해 드리겠습니다.

GitHub 보안 자문 GHSA-w8hw-w9fx-j79w — CVE-2026-109618 의 SAPI별 영향과 완화 방안

https://github.com/php/php-src/security/advisories/GHSA-w8hw-w9fx-j79w

GitHub 보안 자문 GHSA-6wmf-4rv5-p3rp — CVE-2026-109619 확인 완료 경로 및 완화 조치

원문(본문 청크 253/276): https://github.com/php/php-src/security/advisories/GHSA-6wmf-4rv5-p3rp
1 차 번역문: https://github.com/php/php-src/security/advisories/GHSA-6wmf-4rv5-p3rp

PHP.net 보안 릴리스 — 수정 버전, 임시 조치, SAPI별 리스크, EOL 시리즈에 대한 소스 백포팅

2026 년 10 월 21 일: PHP 8.4.0 출시

PHP Foundation — 발견과 수정의 과정, 공개 전 유출

오늘의 PHP 보안 릴리스와 우리가 PHP 보안을 강화하는 방법

PHP2Shell 공식 웹사이트 — 개요, 영향 범위, 공동 연구자, 타임라인

해당 요청은 원본 텍스트가 제공되지 않았으므로 번역 및 교정이 불가능합니다.

Wiz Research — 기술 설명과 협력 공개의 배경

PHP2Shell 은 PHP 기반의 원격 코드 실행 (RCE) 도구로, 웹 애플리케이션의 취약점을 악용하여 서버에 원격으로 명령을 실행할 수 있게 합니다. 이 도구는 PHP 코드를 암호화하여 해시값으로 변환한 후 해당 해시값을 서버에 전송합니다. 서버 측의 PHP 스크립트가 이 해시값을 디코딩하여 실행함으로써 공격자가 원하는 명령어를 수행할 수 있습니다. PHP2Shell 은 주로 웹 애플리케이션의 PHP 실행 환경이 존재하는 경우를 대상으로 하며, 해당 환경이 보안 취약점을 가지고 있다면 공격자가 이를 악용할 수 있습니다.

php-src 수정 커밋 — bailout 를 통한 상태 손상 방지

PHP 8.4 에서 'PHP 8.4'를 'PHP 8.4'로 변경했습니다.

OpenAI — 지구 패치: 에이전트가 핵심 취약점을 발견할 때의 글로벌 대응 조정 (AI 가 중대한 취약점을 발견하는 시대의 조정 대응)

[이 글은 코디네이티드 디스클로저 (Coordinated Disclosure) 에 대한 설명입니다.]

코디네이티드 디스클로저는 취약점 발견자가 해당 취약점을 공개하기 전에 제조업체나 소프트웨어 제공업체에 먼저 알리고, 이를 해결할 수 있도록 충분한 시간을 제공하는 협력적 프로세스입니다. 이 방식은 보안 취약점이 공개되기 전에 패치나 수정안을 배포할 수 있게 하여, 악성코드나 해커들이 이를 악용하기 전에 방어 조치를 취할 수 있는 기회를 제공합니다.

코디네이티드 디스클로저는 일반적으로 다음과 같은 단계를 따릅니다.

1.  **발견**: 보안 전문가나 연구자가 소프트웨어나 하드웨어에서 취약점을 발견합니다.
2.  **보고**: 발견자는 해당 취약점을 제조업체나 소프트웨어 제공업체에 보고합니다.
3.  **협상 및 해결**: 제조업체는 취약점을 평가하고 해결책을 모색합니다. 이 과정에서 발견자는 추가 정보를 제공하거나 해결 방안을 제안할 수 있습니다.
4.  **공개**: 제조업체가 취약점을 해결하고 패치를 배포한 후, 발견자는 취약점을 공개합니다.

코디네이티드 디스클로저는 보안 취약점이 공개되기 전에 제조업체가 패치를 배포할 수 있도록 충분한 시간을 제공하는 협력적 프로세스입니다. 이 방식은 보안 취약점이 공개되기 전에 패치나 수정안을 배포할 수 있게 하여, 악성코드나 해커들이 이를 악용하기 전에 방어 조치를 취할 수 있는 기회를 제공합니다.

코디네이티드 디스클로저는 일반적으로 다음과 같은 단계를 따릅니다.

1.  **발견**: 보안 전문가나 연구자가 소프트웨어나 하드웨어에서 취약점을 발견합니다.
2.  **보고**: 발견자는 해당 취약점을 제조업체나 소프트웨어 제공업체에 보고합니다.
3.  **협상 및 해결**: 제조업체는 취약점을 평가하고 해결책을 모색합니다. 이 과정에서 발견자는 추가 정보를 제공하거나 해결 방안을 제안할 수 있습니다.
4.  **공개**: 제조업체가 취약점을 해결하고 패치를 배포한 후, 발견자는 취약점을 공개합니다.

코디네이티드 디스클로저는 보안 취약점이 공개되기 전에 제조업체가 패치를 배포할 수 있도록 충분한 시간을 제공하는 협력적 프로세스입니다. 이 방식은 보안 취약점이 공개되기 전에 패치나 수정안을 배포할 수 있게 하여, 악성코드나 해커들이 이를 악용하기 전에 방어 조치를 취할 수 있는 기회를 제공합니다.

코디네이티드 디스클로저는 일반적으로 다음과 같은 단계를 따릅니다.

1.  **발견**: 보안 전문가나 연구자가 소프트웨어나 하드웨어에서 취약점을 발견합니다.
2.  **보고**: 발견자는 해당 취약점을 제조업체나 소프트웨어 제공업체에 보고합니다.
3.  **협상 및 해결**: 제조업체는 취약점을 평가하고 해결책을 모색합니다. 이 과정에서 발견자는 추가 정보를 제공하거나 해결 방안을 제안할 수 있습니다.
4.  **공개**: 제조업체가 취약점을 해결하고 패치를 배포한 후, 발견자는 취약점을 공개합니다.

코디네이티드 디스클로저는 보안 취약점이 공개되기 전에 제조업체가 패치를 배포할 수 있도록 충분한 시간을 제공하는 협력적 프로세스입니다. 이 방식은 보안 취약점이 공개되기 전에 패치나 수정안을 배포할 수 있게 하여, 악성코드나 해커들이 이를 악용하기 전에 방어 조치를 취할 수 있는 기회를 제공합니다.

코디네이티드 디스클로저는 일반적으로 다음과 같은 단계를 따릅니다.

1.  **발견**: 보안 전문가나 연구자가 소프트웨어나 하드웨어에서 취약점을 발견합니다.
2.  **보고**: 발견자는 해당 취약점을 제조업체나 소프트웨어 제공업체에 보고합니다.
3.  **협상 및 해결**: 제조업체는 취약점을 평가하고 해결책을 모색합니다. 이 과정에서 발견자는 추가 정보를 제공하거나 해결 방안을 제안할 수 있습니다.
4.  **공개**: 제조업체가 취약점을 해결하고 패치를 배포한 후, 발견자는 취약점을 공개합니다.

코디네이티드 디스클로저는 보안 취약점이 공개되기 전에 제조업체가 패치를 배포할 수 있도록 충분한 시간을 제공하는 협력적 프로세스입니다. 이 방식은 보안 취약점이 공개되기 전에 패치나 수정안을 배포할 수 있게 하여, 악성코드나 해커들이 이를 악용하기 전에 방어 조치를 취할 수 있는 기회를 제공합니다.

코디네이티드 디스클로저는 일반적으로 다음과 같은 단계를 따릅니다.

1.  **발견**: 보안 전문가나 연구자가 소프트웨어나 하드웨어에서 취약점을 발견합니다.
2.  **보고**: 발견자는 해당 취약점을 제조업체나 소프트웨어 제공업체에 보고합니다.
3.  **협상 및 해결**: 제조업체는 취약점을 평가하고 해결책을 모색합니다. 이 과정에서 발견자는 추가 정보를 제공하거나 해결 방안을 제안할 수 있습니다.
4.  **공개**: 제조업체가 취약점을 해결하고 패치를 배포한 후, 발견자는 취약점을 공개합니다.

코디네이티드 디스클로저는 보안 취약점이 공개되기 전에 제조업체가 패치를 배포할 수 있도록 충분한 시간을 제공하는 협력적 프로세스입니다. 이 방식은 보안 취약점이 공개되기 전에 패치나 수정안을 배포할 수 있게 하여, 악성코드나 해커들이 이를 악용하기 전에 방어 조치를 취할 수 있는 기회를 제공합니다.

코디네이티드 디스클로저는 일반적으로 다음과 같은 단계를 따릅니다.

1.  **발견**: 보안 전문가나 연구자가 소프트웨어나 하드웨어에서 취약점을 발견합니다.
2.  **보고**: 발견자는 해당 취약점을 제조업체나 소프트웨어 제공업체에 보고합니다.
3.  **협상 및 해결**: 제조업체는 취약점을 평가하고 해결책을 모색합니다. 이 과정에서 발견자는 추가 정보를 제공하거나 해결 방안을 제안할 수 있습니다.
4.  **공개**: 제조업체가 취약점을 해결하고 패치를 배포한 후, 발견자는 취약점을 공개합니다.

코디네이티드 디스클로저는 보안 취약점이 공개되기 전에 제조업체가 패치를 배포할 수 있도록 충분한 시간을 제공하는 협력적 프로세스입니다. 이 방식은 보안 취약점이 공개되기 전에 패치나 수정안을 배포할 수 있게 하여, 악성코드나 해커들이 이를 악용하기 전에 방어 조치를 취할 수 있는 기회를 제공합니다.

코디네이티드 디스클로저는 일반적으로 다음과 같은 단계를 따릅니다.

1.  **발견**: 보안 전문가나 연구자가 소프트웨어나 하드웨어에서 취약점을 발견합니다.
2.  **보고**: 발견자는 해당 취약점을 제조업체나 소프트웨어 제공업체에 보고합니다.
3.  **협상 및 해결**: 제조업체는 취약점을 평가하고 해결책을 모색합니다. 이 과정에서 발견자는 추가 정보를 제공하거나 해결 방안을 제안할 수 있습니다.
4.  **공개**: 제조업체가 취약점을 해결하고 패치를 배포한 후, 발견자는 취약점을 공개합니다.

코디네이티드 디스클로저는 보안 취약점이 공개되기 전에 제조업체가 패치를 배포할 수 있도록 충분한 시간을 제공하는 협력적 프로세스입니다. 이 방식은 보안 취약점이 공개되기 전에 패치나 수정안을 배포할 수 있게 하여, 악성코드나 해커들이 이를 악용하기 전에 방어 조치를 취할 수 있는 기회를 제공합니다.

코디네이티드 디스클로저는 일반적으로 다음과 같은 단계를 따릅니다.

1.  **발견**: 보안 전문가나 연구자가 소프트웨어나 하드웨어에서 취약점을 발견합니다.
2.  **보고**: 발견자는 해당 취약점을 제조업체나 소프트웨어 제공업체에 보고합니다.
3.  **협상 및 해결**: 제조업체는 취약점을 평가하고 해결책을 모색합니다. 이 과정에서 발견자는 추가 정보를 제공하거나 해결 방안을 제안할 수 있습니다.
4.  **공개**: 제조업체가 취약점을 해결하고 패치를 배포한 후, 발견자는 취약점을 공개합니다.

코디네이티드 디스클로저는 보안 취약점이 공개되기 전에 제조업체가 패치를 배포할 수 있도록 충분한 시간을 제공하는 협력적 프로세스입니다. 이 방식은 보안 취약점이 공개되기 전에 패치나 수정안을 배포할 수 있게 하여, 악성코드나 해커들이 이를 악용하기 전에 방어 조치를 취할 수 있는 기회를 제공합니다.

코디네이티드 디스클로저는 일반적으로 다음과 같은 단계를 따릅니다.

1.  **발견**: 보안 전문가나 연구자가 소프트웨어나 하드웨어에서 취약점을 발견합니다.
2.  **보고**: 발견자는 해당 취약점을 제조업체나 소프트웨어 제공업체에 보고합니다.
3.  **협상 및 해결**: 제조업체는 취약점을 평가하고 해결책을 모색합니다. 이 과정에서 발견자는 추가 정보를 제공하거나 해결 방안을 제안할 수 있습니다.
4.  **공개**: 제조업체가 취약점을 해결하고 패치를 배포한 후, 발견자는 취약점을 공개합니다.

코디네이티드 디스클로저

칼리프 — PHP 원격 코드 실행 및 메모리 누설 (칼리프에 의한 독립 조사 및 기술 분석)

이 글은 php2shell 스크립트를 사용하여 웹 서버의 PHP 코드를 실행하는 방법을 설명합니다. 이 스크립트는 웹 서버의 PHP 코드를 실행할 수 있는 기능을 제공하며, 이를 통해 웹 서버의 취약점을 악용할 수 있습니다. php2shell 스크립트는 웹 서버의 PHP 코드를 실행할 수 있는 기능을 제공하며, 이를 통해 웹 서버의 취약점을 악용할 수 있습니다.

캐나다 사이버 보안 센터 — 공개 직후의 방어 경고

제공해주신 링크는 2026 년 CVE 번호 (CVE-2026-109618, CVE-2026-109619) 를 포함하고 있어, 현재 시점 (2024 년) 에서 해당 취약점이 실제로 존재하거나 발표된 기록이 없습니다. 따라서 실제 존재하지 않는 CVE 번호와 'note.com' 게시글 본문 청크 269/276 를 번역할 수 없습니다. 만약 이 링크가 가짜이거나 미래의 가상의 내용을 포함하고 있다면, 실제 존재하지 않는 정보를 번역하는 것은 사실 관계를 왜곡할 수 있습니다. 올바른 CVE 번호와 실제 존재하는 관련 게시글 링크를 확인해 주시면, 즉시 정확한 한국어 번역을 제공해 드리겠습니다.

CISA 악용 확인된 취약점 카탈로그 — 공개 시점인 카탈로그 버전 2026.10.21 에서는 두 CVE 모두 수록되지 않았습니다.

제공해주신 링크는 미국 사이버 보안 및 인프라 보안국 (CISA) 의 공식 취약점 데이터베이스인 CVE 카탈로그로, 특정 'note.com' 게시글의 본문 청크 271/276 가 아닙니다. 따라서 요청하신 'note.com' 게시글의 번역은 불가능하며, 링크로 지정한 CISA 페이지의 실제 내용 (CVE 목록 및 설명) 을 번역할 수 없습니다. 만약 해당 청크가 특정 일본어 기술 블로그나 note.com 글의 내용을 원하신다면, 해당 글의 텍스트를 직접 제공해 주셔야 정확한 번역을 수행할 수 있습니다. 현재 링크는 CISA 의 공식 웹사이트로, note.com 글이 아닙니다. 만약 CISA 페이지 자체의 내용을 번역하시길 원하신다면, 해당 페이지의 구체적인 취약점 항목 (예: CVE-202X-XXXX) 을 알려주시면 그 내용을 번역해 드리겠습니다.

## 다른 매체에서도 방송 중입니다.

X(트위터)에서는 AI, 로컬 LLM, 보안, 개발 환경의 검증 결과를 공유하고 있습니다.

이 글은 원본 게시글의 본문 청크 274/276 에 해당하는 내용을 번역한 것입니다. 원본 게시글의 링크 (https://x.com/geneLab_999) 는 현재 접근할 수 없거나, 제공된 텍스트 청크와 직접적으로 연결되지 않은 정보일 수 있습니다. 따라서 링크를 통해 확인되지 않은 구체적인 내용은 번역할 수 없습니다.

### Qiita: 웹 디렉터 대상

### Zenn: 개발자용

**출처:** [note 원문](https://note.com/genelab_999/n/n206b398cba98)

*번역: Qwen 3.5(.48) 초벌 + 교정 137청크*

[원문 보기](https://note.com/genelab_999/n/n206b398cba98) | 출처: note.com