AI가 40년 된 기술 부채를 갚게 만들고 있다: PHP2Shell 사건

AI is forcing us to pay off 40 years of technical debt

Nov 4, 2026•pseudolus•View Original

TL;DR Highlight

AI가 PHP의 오래된 크래시 버그를 원격 코드 실행 취약점으로 바꿔냈다

Who Should Read

레거시 PHP·오픈소스 의존성을 운영하며 AI 시대의 보안 패치 부담이 걱정되는 백엔드 개발자

Core Mechanics

PHP2Shell은 2024년 제보된 낡은 버그였다
- 메모리 할당이 데이터보다 작은 out-of-memory 오류였다.
- 보통은 프로그램이 죽는 정도라 우선순위가 낮아 방치됐다.
AI 도구로 2주 만에 코드 실행까지 연결됐다
- OpenAI 후원으로 Calif가 PHP 감사를 하던 중 연구원이 AI 도구로 임의 코드 실행 방법을 찾았다.
- 단순 크래시가 심각한 취약점으로 바뀌었다.
AI는 지루한 추론을 대신해 줬다
- Suman Jana 교수는 메모리상 점프 위치와 덮어쓸 비트 순서를 정하는 일이 '로켓 과학은 아니지만 고통스러운 추론'이라고 했다.
- 이 부분을 AI가 잘했다고 평가했다.
AI 혼자 한 건 아니다
- Calif, OpenAI, Wiz 연구진은 보안과 PHP 양쪽에 깊은 지식이 있었다.
- Jana 교수는 AI가 혼자 다 할 수는 없지만 상위 0.1% 전문가의 생산성을 크게 높인다고 했다.
버그 찾기와 고치기는 비대칭이다
- 패치는 공격 경로를 모두 막으면서 기존 기능도 깨지 않아야 한다.
- PHP 엔지니어 4명이 패치에 두 달을 썼다.
방어 쪽 대안은 토큰 기부와 형식 검증이다
- 프론티어 랩이 토큰 예산을 오픈소스 버그 탐색에 기부하는 방안이 언급됐다.
- LLM이 패치와 증명을 만들고 증명 검사기만 비LLM으로 두는 방식이 소개됐다.

Community Reactions

오래 묵은 취약점은 AI 이전부터 사람이 방치한 것이라는 의견
- HTTP2Shell/Brotli2Shell이 더 심각했다는 댓글이 있었다.
- 8년간 코드에 있었고 8개월간 수정이 미배포였으며 4명 이상이 독립적으로 지적했다는 타임라인이 제시됐다.
AI로 5~7년 묵은 부채를 처리하고 있다는 경험
- 조사와 테스트에 드는 시간을 AI가 줄여 줬다는 후기가 있었다.
- 마지막에 테스트 케이스를 돌려 기대한 수정인지 직접 확인한다고 했다.
AI가 새 기술 부채를 더 빨리 만든다는 반론
- 아무도 코드를 이해하지 못한 채 기계를 믿게 된다는 의견이 여럿 나왔다.
- 최신 모델을 high로 써도 AI의 수정이 좁고 깨지기 쉬워 꼼꼼히 읽어야 한다는 경험이 있었다.
빚 갚기가 아니라 끝없는 땜질일 수 있다는 의견
- 일부 부채는 재구조화가 필요해 변경마다 새 문제 위험이 있다는 지적이 있었다.
- 공격자 AI를 피하려 계속 코드를 갈아엎게 될 수 있다는 의견이었다.

How to Apply

오늘 PHP·CMS 버전과 보안 업데이트 확인하기
- WordPress·Drupal과 PHP 런타임의 패치 적용 여부를 지금 점검하라.
- 업데이트 알림은 다음 주로 미루지 말고 바로 적용하라.
방치된 크래시 버그를 보안 이슈로 재분류하기
- 이슈 트래커에서 out-of-memory나 크래시 리포트만 따로 필터링하라.
- 각 건에 메모리 오염 가능성을 질문하고 우선순위를 다시 매겨라.
AI 수정안은 테스트와 직접 리뷰로 검증하기
- AI가 낸 패치는 기존 기능 회귀 테스트를 반드시 돌려라.
- 통과해도 좁은 수정인지 코드를 직접 읽어 확인하라.

Try It

복사해서 바로 해보기

# Claude 또는 ChatGPT에 붙여넣기 (원문 아이디어의 간이 버전: 크래시 버그를 보안 관점으로 재검토)

아래는 우리 프로젝트에 보고된 크래시/메모리 오류 버그 리포트와 관련 코드다.
{{버그 리포트와 코드}}

각 버그에 대해 다음을 답해라.
1. 단순 크래시로 끝나는가, 아니면 메모리 덮어쓰기나 코드 실행으로 이어질 수 있는가?
2. 이어질 수 있다면 어떤 조건이 필요한가?
3. 패치할 때 기존 기능을 깨지 않으려면 어떤 회귀 테스트가 필요한가?

확실하지 않은 부분은 추측하지 말고 '확인 필요'라고 표시해라.

이어서 해 볼 것: 위험도가 높다고 나온 건 하나를 골라 패치안을 받고, 직접 테스트를 돌려 검증하라.

Terminology

out-of-memory 오류데이터를 담을 메모리 칸이 데이터보다 작게 잡혀 생기는 오류다. 작은 상자에 큰 물건을 넣으려는 상황과 비슷하다.

임의 코드 실행공격자가 서버에서 원하는 명령을 돌릴 수 있는 상태다. 남의 집 열쇠를 복사해 마음대로 드나드는 것과 같다.

형식 검증(formal verification)코드나 패치가 맞다는 것을 수학적 증명으로 확인하는 방식이다. 테스트 샘플이 아니라 전체 경우를 따진다.

기술 부채당장 편하려고 미룬 수정이 쌓여 나중에 갚아야 하는 비용이다. 카드값처럼 이자가 붙는다.

Related Resources

AI가 40년 된 기술 부채를 갚게 만들고 있다: PHP2Shell 사건

AI is forcing us to pay off 40 years of technical debt

Nov 4, 2026•pseudolus•View Original

TL;DR Highlight

AI가 PHP의 오래된 크래시 버그를 원격 코드 실행 취약점으로 바꿔냈다

Who Should Read

레거시 PHP·오픈소스 의존성을 운영하며 AI 시대의 보안 패치 부담이 걱정되는 백엔드 개발자

Core Mechanics

PHP2Shell은 2024년 제보된 낡은 버그였다
- 메모리 할당이 데이터보다 작은 out-of-memory 오류였다.
- 보통은 프로그램이 죽는 정도라 우선순위가 낮아 방치됐다.
AI 도구로 2주 만에 코드 실행까지 연결됐다
- OpenAI 후원으로 Calif가 PHP 감사를 하던 중 연구원이 AI 도구로 임의 코드 실행 방법을 찾았다.
- 단순 크래시가 심각한 취약점으로 바뀌었다.
AI는 지루한 추론을 대신해 줬다
- Suman Jana 교수는 메모리상 점프 위치와 덮어쓸 비트 순서를 정하는 일이 '로켓 과학은 아니지만 고통스러운 추론'이라고 했다.
- 이 부분을 AI가 잘했다고 평가했다.
AI 혼자 한 건 아니다
- Calif, OpenAI, Wiz 연구진은 보안과 PHP 양쪽에 깊은 지식이 있었다.
- Jana 교수는 AI가 혼자 다 할 수는 없지만 상위 0.1% 전문가의 생산성을 크게 높인다고 했다.
버그 찾기와 고치기는 비대칭이다
- 패치는 공격 경로를 모두 막으면서 기존 기능도 깨지 않아야 한다.
- PHP 엔지니어 4명이 패치에 두 달을 썼다.
방어 쪽 대안은 토큰 기부와 형식 검증이다
- 프론티어 랩이 토큰 예산을 오픈소스 버그 탐색에 기부하는 방안이 언급됐다.
- LLM이 패치와 증명을 만들고 증명 검사기만 비LLM으로 두는 방식이 소개됐다.

Community Reactions

오래 묵은 취약점은 AI 이전부터 사람이 방치한 것이라는 의견
- HTTP2Shell/Brotli2Shell이 더 심각했다는 댓글이 있었다.
- 8년간 코드에 있었고 8개월간 수정이 미배포였으며 4명 이상이 독립적으로 지적했다는 타임라인이 제시됐다.
AI로 5~7년 묵은 부채를 처리하고 있다는 경험
- 조사와 테스트에 드는 시간을 AI가 줄여 줬다는 후기가 있었다.
- 마지막에 테스트 케이스를 돌려 기대한 수정인지 직접 확인한다고 했다.
AI가 새 기술 부채를 더 빨리 만든다는 반론
- 아무도 코드를 이해하지 못한 채 기계를 믿게 된다는 의견이 여럿 나왔다.
- 최신 모델을 high로 써도 AI의 수정이 좁고 깨지기 쉬워 꼼꼼히 읽어야 한다는 경험이 있었다.
빚 갚기가 아니라 끝없는 땜질일 수 있다는 의견
- 일부 부채는 재구조화가 필요해 변경마다 새 문제 위험이 있다는 지적이 있었다.
- 공격자 AI를 피하려 계속 코드를 갈아엎게 될 수 있다는 의견이었다.

How to Apply

오늘 PHP·CMS 버전과 보안 업데이트 확인하기
- WordPress·Drupal과 PHP 런타임의 패치 적용 여부를 지금 점검하라.
- 업데이트 알림은 다음 주로 미루지 말고 바로 적용하라.
방치된 크래시 버그를 보안 이슈로 재분류하기
- 이슈 트래커에서 out-of-memory나 크래시 리포트만 따로 필터링하라.
- 각 건에 메모리 오염 가능성을 질문하고 우선순위를 다시 매겨라.
AI 수정안은 테스트와 직접 리뷰로 검증하기
- AI가 낸 패치는 기존 기능 회귀 테스트를 반드시 돌려라.
- 통과해도 좁은 수정인지 코드를 직접 읽어 확인하라.

Try It

복사해서 바로 해보기

# Claude 또는 ChatGPT에 붙여넣기 (원문 아이디어의 간이 버전: 크래시 버그를 보안 관점으로 재검토)

아래는 우리 프로젝트에 보고된 크래시/메모리 오류 버그 리포트와 관련 코드다.
{{버그 리포트와 코드}}

각 버그에 대해 다음을 답해라.
1. 단순 크래시로 끝나는가, 아니면 메모리 덮어쓰기나 코드 실행으로 이어질 수 있는가?
2. 이어질 수 있다면 어떤 조건이 필요한가?
3. 패치할 때 기존 기능을 깨지 않으려면 어떤 회귀 테스트가 필요한가?

확실하지 않은 부분은 추측하지 말고 '확인 필요'라고 표시해라.

이어서 해 볼 것: 위험도가 높다고 나온 건 하나를 골라 패치안을 받고, 직접 테스트를 돌려 검증하라.

Terminology

out-of-memory 오류데이터를 담을 메모리 칸이 데이터보다 작게 잡혀 생기는 오류다. 작은 상자에 큰 물건을 넣으려는 상황과 비슷하다.

임의 코드 실행공격자가 서버에서 원하는 명령을 돌릴 수 있는 상태다. 남의 집 열쇠를 복사해 마음대로 드나드는 것과 같다.

형식 검증(formal verification)코드나 패치가 맞다는 것을 수학적 증명으로 확인하는 방식이다. 테스트 샘플이 아니라 전체 경우를 따진다.

기술 부채당장 편하려고 미룬 수정이 쌓여 나중에 갚아야 하는 비용이다. 카드값처럼 이자가 붙는다.

AI가 40년 된 기술 부채를 갚게 만들고 있다: PHP2Shell 사건

TL;DR Highlight

Who Should Read

Core Mechanics

Community Reactions

How to Apply

Try It

Terminology

관련 논문

Related Resources

AI가 40년 된 기술 부채를 갚게 만들고 있다: PHP2Shell 사건

TL;DR Highlight

Who Should Read

Core Mechanics

Community Reactions

How to Apply

Try It

Terminology

관련 논문

Related Resources