OpenAI 모델이 찾은 PHP 취약점 ‘php2shell’｜우리 사이트는 AI 에이전트 프롬프트로 점검하세요

현지 시간 10월 21일, PHP 개발진이 긴급 보안 업데이트를 내놓았습니다. 함께 공개된 두 취약점의 이름은 ‘php2shell’입니다. 인증 없이 보낸 요청 하나로 서버에서 공격자의 코드가 실행될 수 있는 수준이라, 미국 NSA와 일본 총리까지 즉시 업데이트를 요청했습니다.

이번 발견에는 OpenAI의 모델이 사용됐습니다. 14년 동안 PHP 안에 숨어 있던 결함을 AI가 찾아냈고, 같은 시기에 다른 보안 회사들도 AI로 같은 문제를 찾았습니다.

PHP는 전 세계 웹사이트의 약 70%가 사용합니다. 워드프레스 기반 교회 홈페이지, 행사 신청 페이지, 사역 단체 사이트도 대부분 여기에 해당합니다. 우리 사이트가 영향을 받는지 확인하고 실제로 패치하는 일이 이번 주에 해야 할 일입니다.

이 글에서는 관련 기사 세 개를 정리하고, 그 대응을 AI 브라우저 에이전트에게 맡기는 프롬프트를 소개합니다.

기사 1｜PHP, 14년 된 치명적 취약점 두 개 긴급 패치

PHP 공식 사이트는 10월 20일 사전 공지를 내고, 21일 14:00 UTC(한국 시간 21일 밤 11시)에 보안 업데이트를 배포했습니다.

공식 공지는 업데이트만이 안전한 선택이며 완전한 우회책은 없다고 밝혔습니다. memory_limit, 업로드 크기 제한 같은 임시 설정도 안내했지만, 노출을 줄일 뿐 서버를 안전하게 만들지는 않는다고 덧붙였습니다. 특히 Apache mod_php 환경은 애플리케이션 코드가 실행되기 전에 공격이 성공할 수 있어 위험이 가장 큽니다.

Cloudflare는 이 결함들이 PHP 5.4 이후의 모든 웹 서버에 영향을 준다고 설명했습니다. 오래된 호스팅에 방치된 사이트도 예외가 아닙니다. Cloudflare 블로그

기사 2｜OpenAI “AI가 공격자보다 먼저 찾았다”

Fortune에 따르면 첫 결함은 8월 1일, AI 보안 기업 Calif가 OpenAI의 GPT-5.6 Sol로 찾아냈습니다. OpenAI의 오픈소스 보안 지원 프로그램 ‘Patch the Planet’의 일환이었습니다. 이후 OpenAI가 추가 부분을 찾아내면서 처음 생각보다 훨씬 심각하다는 사실이 드러났습니다.

8월 19일에는 구글 계열 보안 기업 Wiz가 Gemini와 GPT-5.6 Sol, 자체 도구를 함께 써서 같은 취약점을 독립적으로 발견했습니다. 결국 이 결함을 찾은 쪽은 모두 AI를 사용했습니다.

OpenAI는 이를 “최근 기억에 남을 만큼 영향력이 큰 취약점”이라고 부르며, PHP 재단·Wiz·Cloudflare·Quarkslab·미국 정부 기관과 함께 두 달간 패치와 공개 일정을 조율했다고 밝혔습니다. 패치 확인용 php2shell-checker도 GitHub에 공개했습니다. PPC Land

기사에 인용된 전문가들은 이번 일을 ‘AI 변곡점’으로 봅니다. AI 덕분에 오래 묻힌 결함을 찾기 쉬워졌지만, 공개된 정보를 실제 공격으로 바꾸는 속도도 빨라졌다는 뜻입니다.

기사 3｜정부 사이트까지 내렸다, 그런데 이미 유출

The National은 각국의 대응을 전했습니다. 네덜란드·핀란드·프랑스·호주는 일부 정부 서비스를 잠시 내리고 패치를 적용했습니다. NSA는 바로 업데이트할 수 없다면 완전히 대응할 때까지 시스템을 오프라인으로 두라고 권고했고, CISA도 신속한 설치를 촉구했습니다.

다만 OpenAI의 “공격자보다 먼저”라는 설명과 다른 보도도 있습니다. Cloudflare는 공식 공개 전에 취약점이 유출됐고, 고객 사이트를 노린 공격과 차단 규칙을 피하려는 변형 시도까지 관찰했다고 밝혔습니다. Fortune은 한 스타트업이 소스 코드와 쿠키 데이터를 탈취당했다는 증언도 전했습니다.

보안 기업 Ox Security의 모셰 시만 토브 부스탄은 이렇게 말했습니다. “공개된 PHP 서버를 아직 패치하지 않았다면, 이미 노출됐다는 가정에서 출발하라.”

교회 사이트 관리자가 막히는 지점

기사를 읽고 나면 할 일은 분명합니다. 하지만 실제로 손을 대려면 질문이 이어집니다.

• 우리 사이트가 PHP를 쓰는지부터 모르겠다. 웹 제작 업체가 만들어 주고 끝났다.
• 호스팅 화면에 ‘PHP 8.3’이라고 보이는데, 이게 8.3.36인지 그 이전인지 어디서 보나?
• 공유 호스팅이라 직접 바꿀 수 없다면 무엇을 요청해야 하나?
• Cloudflare를 쓰고 있으니 괜찮은 것 아닌가?

마지막 질문이 특히 위험합니다. Cloudflare는 무료 요금제까지 차단 규칙을 기본 적용했지만, PHP 자체를 업데이트해야 하며 WAF는 패치를 대신하지 않는다고 분명히 밝혔습니다. 보안 플러그인 설치나 비밀번호 변경도 마찬가지입니다.

대응은 AI 에이전트에게, 판단 기준은 프롬프트에

AI가 취약점을 찾는 시대라면, 패치와 검증도 AI의 도움을 받을 수 있습니다. Aside처럼 AI 에이전트가 내장된 브라우저는 사용자가 이미 로그인한 호스팅 관리 화면과 워드프레스 관리자에서 직접 화면을 읽고 작업합니다. Aside 소개 정리

다만 관리 권한을 가진 에이전트에게 “PHP 업데이트해 줘”라고만 말하면 위험합니다. 백업 없이 버전을 바꾸거나, 버튼을 누른 사실만으로 완료를 보고하거나, WAF 설정을 패치로 착각할 수 있습니다.

아래 프롬프트는 이번 php2shell 대응에서 필요한 판단을 순서대로 담았습니다.

이 프롬프트에는 CVE 번호나 수정 버전을 일부러 적지 않았습니다. 에이전트가 실행하는 시점에 php.net과 호스팅사 공지를 직접 조회하게 했습니다. 이번처럼 후속 공지나 추가 패치가 나와도 같은 프롬프트를 다시 쓸 수 있습니다.

복사해서 쓰는 PHP 보안 패치 프롬프트

첫 줄의 [웹사이트 주소]만 자신이 관리하는 사이트 주소로 바꿔서 사용하세요.

대상 웹사이트: [웹사이트 주소]

내가 관리하는 위 웹사이트에 대해, PHP 사용 여부를 확인하고 필요한 PHP 보안 업데이트를 실제로 적용해줘. 변경 후에는 패치 반영 여부와 사이트 정상 작동을 검증해줘.

현재 Aside에서 사용할 수 있는 로그인 세션과 관리 권한으로 작업을 진행해. 일반적인 조회·백업·같은 지원 계열의 보안 패치·검증은 불필요한 재확인 없이 수행해.

작업 범위는 입력한 웹사이트와 그 사이트를 운영하는 관리 대상 환경으로 한정해. 관련 없는 사이트나 외부 서비스까지 변경 범위를 넓히지 마.

## 1. PHP 사용 여부부터 확인

입력한 주소와 실제 연결되는 운영 사이트를 확인한 뒤, PHP 사용 여부를 조사해.

확인 수단:
- 일반적인 페이지 조회, 응답 헤더, 페이지 소스
- 사용 중인 CMS나 웹 애플리케이션의 확인 가능한 정보
- 로그인된 사이트 관리자와 호스팅 관리 화면
- 허용된 서버 관리 기능에서 확인할 수 있는 설정과 실행 환경

외부에서 보이는 흔적은 단서로 활용하고, 가능하면 관리 화면이나 서버 정보로 확인해.

다음 사항을 주의해.
- 주소에 .php가 없거나 PHP 관련 응답 헤더가 없다는 이유만으로 PHP 미사용이라고 판단하지 마.
- wp-content 같은 경로만으로 현재 PHP가 실행 중이라고 확정하지 마. 정적 복제 사이트일 수도 있어.
- 화면이 JavaScript 기반이더라도 관리 대상 백엔드나 CMS에서 PHP를 사용하는지 확인해.
- CDN이나 프록시 때문에 원본 환경을 알 수 없다면 추가 관리 정보가 필요하다고 표시해.

PHP 사용 여부는 다음 중 하나로 분류하고 근거를 기록해.
1. PHP 사용 확인
2. PHP 사용 추정 — 추가 확인 필요
3. PHP 미사용 확인
4. 확인 불가 — 관리 정보나 접근 권한 부족

PHP 미사용이 확인되면 PHP 관련 변경은 생략하고 그 근거를 보고해. 확인 불가 상태를 ‘안전함’이나 ‘PHP 미사용’으로 처리하지 마.

## 2. PHP를 사용하는 경우 실제 버전과 취약점 확인

PHP 사용이 확인되면 다음을 조사해.
- 실제 웹 요청을 처리하는 PHP의 정확한 버전과 확인 가능한 패키지 빌드
- 호스팅 업체와 PHP 업데이트를 관리하는 위치
- PHP 실행 방식과 대상 사이트에 연결된 실행 환경
- 사용 중인 CMS·프레임워크 및 PHP 변경과 관련된 호환성 정보
- 현재 백업 상태와 복원 방법

워드프레스 사이트라면 ‘도구 → 사이트 건강 → 정보 → 서버’를 우선 확인해. 다른 CMS나 자체 개발 사이트는 해당 관리 화면과 호스팅 설정을 활용해.

취약점 번호나 수정 버전을 미리 고정하지 말고, 실행 시점의 공식 정보를 조회해.
- PHP 공식 공지: https://www.php.net/
- PHP 지원 버전: https://www.php.net/supported-versions.php
- 사용 중인 운영체제·배포판·호스팅사의 공식 보안 공지

현재 환경에 영향을 주는 보안 취약점과 수정 버전을 대조해.

호스팅사나 배포판이 기존 버전에 보안 수정만 적용하는 백포트 방식을 사용한다면, 버전 숫자만으로 미패치라고 판단하지 말고 해당 취약점의 수정 여부를 공식 자료로 확인해.

터미널에서 표시되는 PHP 버전과 실제 웹사이트에 적용된 PHP 버전이 일치한다고 가정하지 마.

이미 필요한 패치가 적용돼 있다면 불필요한 변경을 하지 말고, 확인 근거와 함께 ‘이미 패치됨’으로 보고해.

## 3. 변경 전 백업과 복구 준비

변경이 필요하면 먼저 운영 상태를 복구할 수 있는 백업을 확보해.

- 사이트 파일과 관련 설정을 백업해.
- 데이터베이스를 사용하는 사이트라면 데이터베이스도 포함해.
- 호스팅 스냅샷이나 기존 백업 기능을 우선 활용해.
- 백업 완료 여부, 생성 시각, 비공개 보관 위치와 복원 방법을 확인해.
- 변경 전 PHP 설정과 주요 기능의 동작 상태를 기록해.

복구 가능한 백업을 확보할 수 없다면 운영 환경 변경 전에 그 문제와 필요한 조치를 알려줘.

로그인이나 인증이 필요하면 내가 해당 화면에서 직접 완료하도록 요청하고, 완료 후 이어서 진행해. 비밀번호·인증키·쿠키 등 민감한 정보는 출력하거나 보고서에 기록하지 마.

## 4. 필요한 보안 업데이트 적용

지원 중인 PHP 계열을 사용한다면 같은 계열의 공식 보안 수정판을 우선 적용해. 보안 문제 해결에 필요한 최소한의 변경부터 진행해.

지원 종료 버전이라면 다음을 확인해.
- 공급사의 검증된 보안 백포트 제공 여부
- 지원 중인 PHP 계열로 전환할 수 있는지
- 전환 시 CMS·프레임워크·테마·플러그인·확장 모듈의 호환성

호스팅 관리 화면이나 실제로 허용된 서버 관리 수단으로 업데이트해. 사용할 수 없는 SSH·API·관리 권한이 있다고 가정하지 마.

필요한 PHP 실행 프로세스의 재시작이나 교체를 수행하고, 해당 사이트를 서비스하는 PHP 풀·컨테이너·서버에 수정된 실행 환경이 반영됐는지 확인해.

CMS·테마·플러그인·라이브러리는 이번 보안 조치나 호환성 확보에 필요한 범위에서 업데이트해. 관련 없는 기능 변경이나 대규모 일괄 업데이트를 함께 진행하지 마.

유료 결제, 다른 사이트에도 영향을 주는 공용 서버 변경, 장시간 서비스 중단, 데이터 삭제 또는 중대한 호환성 변경이 필요하면 구체적인 조치와 예상 영향을 먼저 제시하고 확인을 받아.

## 5. 패치가 막히면 가능한 조치와 미완료 사항 구분

호스팅 권한이나 공급사 지원 부족으로 패치할 수 없다면 다음을 정확히 보고해.
- 어디까지 확인했는지
- 무엇이 작업을 막고 있는지
- 어떤 접근 권한이나 호스팅사 조치가 필요한지
- 현재 가능한 임시 보호 수단은 무엇인지

기존 WAF나 서버 접근 제한 등 임시 보호 수단을 검토하되, 정상적인 사이트 이용에 미치는 영향을 확인해.

보안 플러그인 설치, 비밀번호 변경, WAF 설정, CMS 점검 모드만으로 PHP 런타임 패치가 완료됐다고 판단하지 마. 적용했다면 ‘임시 완화 조치’로 별도 기록해.

검증되지 않은 패치 스크립트나 출처 불명의 플러그인은 사용하지 마.

호스팅사에 요청해야 한다면 확인된 환경과 관련 취약점을 포함한 구체적인 요청문을 작성해줘. 실제 문의 발송은 내가 확인한 후 진행해.

## 6. 적용 후 실제 반영 여부와 사이트 검증

업데이트 후 실제 웹 요청을 처리하는 PHP 버전이나 수정된 빌드를 다시 확인해.

호스팅 화면의 ‘PHP 8.x’ 같은 계열 선택 표시나 업데이트 버튼을 누른 사실만으로 완료 판정하지 마. 공개 phpinfo 페이지를 만들지 않는 방법으로 확인해.

사이트에 존재하는 기능 중 다음을 점검해.
- 메인 페이지와 주요 메뉴
- 대표 콘텐츠 페이지
- 관리자 화면과 로그인
- 검색, 이미지 표시 및 필요한 관리 기능
- 문의·신청·회원·결제 기능의 화면과 오류 여부
- 확인 가능한 서버 및 애플리케이션 오류 로그

실제 주문·결제·신청을 생성하거나 이메일·알림을 발송하는 테스트는 별도 확인 없이 실행하지 마. 취약점 재현 공격이나 무차별 스캔도 수행하지 마.

침해가 의심되는 계정·파일·설정·비정상 동작을 발견하면 근거와 로그를 보존하고 알려줘. 의심 데이터를 무작정 삭제하지 마.

장애 발생 시 영향 범위를 확인하고 최소한의 변경으로 복구해. 변경 이후 생성된 게시물·신청·주문 등을 잃지 않도록 데이터베이스 전체를 무조건 과거 상태로 되돌리지 마.

복구 과정에서 취약한 버전으로 돌아갔다면 보안 조치가 미완료임을 명확히 표시해.

## 7. 최종 결과 보고

첫 줄에 최종 상태를 다음 중 하나로 표시해.
- PHP 미사용 확인 — PHP 패치 불필요
- PHP 사용 여부 확인 불가
- 이미 필요한 패치 적용됨
- 필요한 PHP 보안 패치 적용 및 검증 완료
- 임시 완화만 적용 — 패치 미완료
- 접근 권한 또는 공급사 지원 부족으로 미적용

이어서 다음 내용을 표로 정리해.
- 대상 주소와 실제 확인한 운영 환경
- PHP 사용 여부와 판단 근거
- 적용 전후 PHP 버전 또는 패키지 빌드
- 점검한 취약점과 공식 근거
- 백업 상태와 복원 수단
- 실제 수행한 변경
- 기능별 검증 결과
- 확인하지 못한 부분과 남은 조치

직접 수행한 작업, 확인만 한 사항, 제안만 한 사항을 구분해. 확인한 범위의 결과를 정확하게 보고하고, 사이트 전체의 완전한 보안을 보장하는 표현은 사용하지 마.

사용하기 전에 확인할 것

내가 관리 권한을 가진 사이트에만 사용하세요. 프롬프트도 “내가 관리하는 웹사이트”로 범위를 정해 두었습니다. 다른 사람의 사이트를 점검하거나 공격 재현을 하는 용도가 아닙니다.

에이전트가 쓸 브라우저에서 호스팅 관리 화면과 사이트 관리자에 미리 로그인해 두세요. 2단계 인증 화면이 나오면 에이전트가 요청할 때 직접 완료하면 됩니다.

다른 AI 브라우저 에이전트를 쓴다면 세 번째 문단의 Aside를 사용하는 도구 이름으로 바꾸면 됩니다. SSH로 서버에 접속하는 코딩 에이전트에 쓸 때는 허용할 서버 관리 수단을 먼저 알려 주세요.

이번 취약점은 미루기 어렵습니다. 평소라면 주일과 행사 직전을 피하라고 권하겠지만, php2shell은 이미 공격이 관찰됐습니다. 바로 작업할 수 없다면 그 사실과 임시 조치를 보고서에 남기고, 가장 빠른 시간에 패치하세요.

자주 묻는 질문

Cloudflare를 쓰고 있으면 패치하지 않아도 되나요?

아닙니다. Cloudflare는 차단 규칙을 적용했지만 PHP 업데이트가 필요하다고 밝혔습니다. 공격자들이 규칙을 피하려고 공격 형태를 바꾸는 시도도 관찰됐습니다.

호스팅사가 PHP를 관리하면 저는 할 일이 없나요?

호스팅사가 업데이트를 적용했는지 확인해야 합니다. 적용이 안 됐다면 에이전트가 확인한 환경 정보를 담아 요청문을 작성해 줍니다. 문의 발송은 사용자가 확인한 뒤 진행합니다.

PHP 7.4나 8.1을 쓰는 오래된 사이트는 어떻게 하나요?

8.1 이하는 공식 업데이트가 없습니다. 호스팅사나 배포판이 보안 백포트를 제공하는지 확인하고, 지원 중인 버전으로 옮길 수 있는지 테마·플러그인 호환성을 점검해야 합니다. 프롬프트는 이 과정에서 중대한 호환성 변경이 필요하면 먼저 확인을 받도록 했습니다.

보고서에 ‘패치 완료’가 나오면 사이트가 완전히 안전한가요?

아닙니다. 이 프롬프트는 PHP 런타임 보안 업데이트를 다룹니다. 패치 전에 이미 침해됐을 가능성, 플러그인 취약점, 약한 관리자 비밀번호는 따로 살펴야 합니다. 에이전트가 의심 흔적을 발견하면 삭제하지 않고 보고하도록 했습니다.

phpinfo 페이지를 만들면 버전 확인이 쉽지 않나요?

쉽지만 위험합니다. 공개된 phpinfo 페이지는 서버 경로와 설정을 누구에게나 보여 줍니다. 관리 화면이나 서버 내부에서 확인하도록 했습니다.

AI가 찾은 취약점, 대응도 AI와 함께

php2shell은 AI가 오래된 결함을 찾아내는 속도를 보여 줬습니다. 같은 속도가 공격자에게도 주어졌다는 점이 이번 사건의 교훈입니다.

작은 교회 사이트일수록 담당자 한 명이 모든 것을 챙깁니다. 위 프롬프트를 복사해 주소 한 줄만 바꾸고, 에이전트가 확인·백업·패치·검증을 마치게 하세요. 사람은 결과 보고서의 첫 줄과 ‘남은 조치’를 읽고 결정하면 됩니다.

자료 확인: 2026년 10월 22일. 기사 내용은 PHP 공식 공지, Cloudflare, Fortune, PPC Land, The National 보도를 바탕으로 정리했습니다. 발견 경위와 유출 여부는 각 기관의 주장이 엇갈리며, 이후 공지에 따라 내용이 바뀔 수 있습니다. 특정 사이트에 이 프롬프트를 실행해 검증한 체험기는 아닙니다.

#PHP #php2shell #보안업데이트 #OpenAI #웹사이트관리 #Aside #AI에이전트 #프롬프트 #워드프레스 #교회홈페이지

이 글이 도움이 되셨나요?

좋아요를 눌러주시고, 댓글로 궁금하신 점을 남겨주세요. 여러분의 질문이 다음 글을 만드는 데 큰 도움이 됩니다.

더 깊은 미디어와 AI 정보는 카카오톡 오픈채팅방에서 만나보실 수 있습니다.