70% of internet hacked by AI... this Is crazy

🖼️ 인포그래픽

🖼️ 4컷 인포그래픽

💡 한 줄 결론

70% of internet hacked by AI... this Is crazy를 중심으로, 문제의 위치는 웹사이트의 기반 엔진이다. 영상은 PHP 자체의 두 취약점이 원격 코드 실행과 서버 메모리 노출을 가능하게를 핵심 판단 포인트로 압축 정리한다.

📌 핵심 요점

1. 문제의 위치는 웹사이트의 기반 엔진이다. 영상은 PHP 자체의 두 취약점이 원격 코드 실행과 서버 메모리 노출을 가능하게 한다고 설명한다. 따라서 WordPress나 플러그인 업데이트만으로는 해결되지 않으며, 서버에서 실행하는 PHP를 갱신해야 한다는 주장이다.
2. AI가 취약점 발견과 공격 재현을 함께 가속한다. 발표자는 오래된 보안 의심을 AI가 작동하는 공격으로 발전시켰고, 다른 연구자도 유출된 단서와 에이전트를 이용해 약 90분 만에 공격 개념증명을 만들었다고 전한다.
3. 공개와 패치 사이의 시간이 중요해졌다. 영상은 취약점 정보, 시연 영상, 선행 배포된 패치가 공격자에게 단서를 제공했다고 설명한다. 다만 영상 시점에 성공적인 침입이 확인된 것은 없다고 명시한다.
4. 위험은 PHP를 넘어 비밀정보와 연결 권한으로 이어진다. 앱에 포함된 키, 공개된 MCP 설정, 호스팅 플랫폼에 저장된 비밀정보를 사례로 들며, AI 도구의 접근 권한과 사용량 과금도 점검 대상으로 제시한다.
5. 대응은 다섯 가지 점검을 반복하는 방식이다. 웹사이트의 PHP 상태, 로컬 AI 도구의 키, 외부 서비스 연결, 보관 데이터와 복구 수단, 주간 보안 점검을 확인하라는 제안이다.

🧩 배경과 문제 정의

영상은 AI가 널리 쓰이는 웹 기반 소프트웨어의 취약점을 찾아내고, 다른 AI가 이를 공격으로 재현하는 속도까지 높인다는 문제를 제기한다. 중심 사례는 WordPress·Laravel·Drupal 등의 기반으로 소개되는 PHP이며, 발표자는 웹사이트 코드보다 서버에서 실행되는 언어 엔진을 갱신해야 하는 상황이라고 설명한다.

이후 논점은 앱과 설정 파일의 API 키, 외부 서비스 연결 권한, 복구 준비로 확장된다. 문제 정의는 ‘내 사이트가 이미 해킹됐는가’에만 머물지 않는다. 무엇을 실행하고 있는지, 어떤 키와 권한이 남아 있는지, 문제가 생겼을 때 복구할 수 있는지를 운영자가 파악하고 있느냐가 핵심이다. 아래 사건과 수치는 제공된 영상의 설명을 정리한 것으로, 독립적으로 확인된 사실과는 구분해야 한다.

🕒 시간순 섹션별 상세정리

1. 인터넷 70% 경고와 PHP 엔진의 취약점

• 도입부는 인터넷의 70%가 공격 가능해졌다고 주장하며, 일본 총리와 NSA의 긴급 대응 요구 및 OpenAI 모델의 취약점 발견을 보여준다. 이어 사업체가 점검할 다섯 항목을 예고한다. [00:47]
• PHP는 WordPress가 사용하는 프로그래밍 언어로 드러난다. 발표자는 WordPress만으로 웹사이트의 약 40%를 차지하고, 다른 PHP 기반 서비스까지 포함하면 영향 범위가 크다고 드러낸다. [01:09]
• 영상은 두 버그를 ‘PHP to shell’, 심각도 9.2로 보여준다. 문제가 플러그인이 아닌 PHP 자체에 있으므로 서버의 PHP를 갱신해야 하며, 공유 호스팅에서는 업체가 조치해야 한다고 강조한다. [01:40]

2. 공격 방식과 오래된 의심을 검증한 AI

• 첫 취약점은 로그인 없이 특수 요청으로 서버가 공격자의 코드를 실행하게 하고, 두 번째는 서버 메모리에서 비밀번호·세션 토큰·API 키 등이 노출될 수 있게 한다는 설명이다. [02:06]
• 새 WordPress·Drupal 및 단순 출력 페이지에서도 재현됐다고 전하며, 문제를 약 2012년부터 존재한 언어 수준의 결함으로 묘사한다. 2024년 감사에서 의심했지만 악용 가능성을 입증하지 못해 수정이 지연됐다는 주장도 나온다. [02:42]
• PHP 보안 경력 20년인 연구자가 OpenAI 프로그램에서 AI를 활용해 공격을 입증했고, 다른 보안업체도 Gemini로 같은 버그를 찾았다고 보여준다. 발표자는 한 연구자가 일주일에 수행한 일이 기존에는 최상급 팀에 수개월 걸렸을 것이라는 평가를 인용한다. [03:18]

3. 공개 조율의 혼선과 짧아진 공격 개발 시간

• 8월 19일 발견, 이틀 뒤 WordPress 공격 재현, 24일 PHP 신고 후 약 두 달간 수정 준비가 진행됐다는 순서를 제시한다. 이후 취약점 번호와 잘못된 심각도, 공격 시연 영상, 선행 배포된 패치가 공개 단서가 됐다고 보여준다. [04:08]
• PHP 내부를 잘 모른다는 연구자가 유출 영상의 단서를 에이전트에 제공했고, 약 90분과 4,000회의 테스트로 작동하는 개념증명을 얻었다고 전해진다. 영상은 공격 개발 기간을 Log4j 당시 15일과 이번의 반나절로 비교한다. [04:44]
• 허니팟에서 공개 전 공격 시도가 관측됐다고 말하면서도 성공적인 침입은 확인되지 않았다고 단서를 단다. 한 스캐너가 관측한 PHP 설치 1억 6,700만 개 중 71%가 공식 수정이 없는 구버전이며, 초기 12시간에 약 20만 개가 패치됐다는 수치도 제시한다. [05:21]

4. 키 유출 사례와 공격·방어 AI의 접근성

• 일본 기업들의 침해 공개와 앱에 남겨진 키, Railway의 비밀정보 저장 시스템 침해 주장을 보여준다. 공개 MCP 설정 스캔에서는 비밀정보 약 2만 4,000개와 여전히 유효한 항목 2,000개 이상이 발견됐다고 전해진다. [06:20]
• 프랑스 슈퍼마켓 최대 약 700곳의 냉장 제어 공격을 물리적 피해 사례로 들지만, 사용된 공격 수단은 알려지지 않았다고 드러낸다. 이어 높은 보안 분석 능력을 가진 모델의 접근이 제한돼 있다는 논점으로 이동한다. [07:08]
• 공개 모델의 공격 능력과 저렴한 공격 재현 사례, 안전 필터 제거 사례를 보여준다. 발표자는 방어용 최상위 모델의 제한적 접근과 공개 모델의 추격을 대비하며, 패치와 앱 속 키가 공격 단서가 된다고 주장한다. [08:03]

5. 첫 번째 점검인 웹사이트와 호스팅 상태

• WordPress의 사이트 건강 정보에서 PHP 버전을 확인하고, 구버전이면 호스팅 업체에 조치를 묻도록 권한다. 외부 검사 결과가 ‘알 수 없음’이면 버전이 숨겨졌을 수 있으므로 안전 판정으로 받아들이지 말라고 보여준다. [08:52]
• 도메인별 PHP 버전, 업데이트 시점, 업데이트 후 재시작 여부를 서면으로 확인하라고 제안한다. 파일을 갱신했어도 기존 프로세스가 계속 실행 중일 수 있다는 것이 재시작을 묻는 이유다. [09:15]
• 모르는 관리자, 업로드 폴더의 새 파일, 예상하지 못한 리디렉션을 침입 의심 징후로 제시한다. 이런 경우 사이트를 내리고 도움을 받으라고 권한 뒤 관련 점검 자료를 안내한다. [09:38]

6. 로컬 키와 연결 권한, 보관 데이터 점검

• 두 번째 점검은 에이전트·MCP 설정과 프로젝트 환경 파일의 키다. 키를 마스킹해 목록화하고, 불필요한 키 정리·공개 저장소 관련 키 교체·AI 사용료 한도 설정과 MCP 서버의 출처 확인을 권한다. [10:34]
• 세 번째 점검은 Google과 자동화·협업 서비스의 외부 앱 연결이다. 미사용 연결을 제거하고 읽기 전용 등 최소 권한을 부여하며, 앱에 키를 남기지 않고 팀원별 관리자 계정을 사용하라고 제안한다. [11:10]
• 네 번째 점검은 불필요한 계정과 데이터를 줄이는 것이다. 외부 로그인 활용, 인증 앱 기반 2단계 인증, 실제 복원한 백업, 고액 거래 시 기존 번호로 재확인하는 절차를 제시한다. [11:38]

7. 주간 점검 자동화와 발표자의 정리 사례

• 다섯 번째 점검은 앞선 항목을 반복하는 주간 점검이다. 웹사이트 헤더, 로컬 에이전트·MCP 설정의 마스킹된 키, 연결 서비스와 권한, 최근 7일의 관련 보안 권고를 확인해 문제와 변경점만 보고하는 프롬프트를 보여준다. [12:27]
• 발표자는 자신의 환경에서 GitHub에 오래 남은 키, 파일 전체 접근이 가능한 비공식 MCP 서버, Google 연결 앱 11개와 과도한 메일 권한, 지출 한도가 없는 키를 발견했다고 드러낸다. [12:55]
• 키 두 개 교체, 서버 제거, Google 연결 앱을 약 다섯 개로 축소하는 데 AI를 활용해 약 30분이 걸렸다고 전해진다. 마지막에는 자료 활용을 안내하고 노출 여부를 즉시 점검하라고 촉구한다. [13:19]

🧾 결론

• 제목의 ‘70%’는 실제 해킹된 사이트 비율로 읽어서는 안 된다. 영상은 PHP의 보급 범위와 잠재적 노출을 강조하면서도 성공적인 침입은 확인되지 않았다고 말한다.
• 웹사이트 운영자는 화면이나 플러그인 상태뿐 아니라 서버의 실제 PHP 버전, 업데이트 시점, 재시작 여부를 확인해야 한다는 것이 영상의 실무적 결론이다.
• AI는 공격 개발을 돕는 동시에 방어 점검에도 활용된다. 발표자가 제안하는 운영 방식은 변경점과 문제만 짧게 보고받고, 키·권한·연결을 지속해서 정리하는 것이다.

📈 투자·시사 포인트

• 보안 대응 속도: 영상의 설명대로 공격 재현 시간이 짧아진다면, 취약점 발견 능력과 함께 패치 배포·적용·재시작을 신속하게 수행하는 운영 역량이 중요해진다.
• 호스팅과 유지보수 책임: 공유 호스팅이나 대행 제작 사이트에서는 운영자가 PHP를 직접 갱신하기 어려울 수 있다. 서비스 제공자가 지원 버전과 조치 내역을 설명할 수 있는지가 점검 기준이다.
• AI 서비스의 비용 노출: API 키 유출은 데이터 접근뿐 아니라 사용료 청구로 나타날 수 있다는 것이 영상의 경고다. 키 관리와 지출 한도는 함께 살펴볼 항목이다.
• 투자 판단의 한계: 영상은 보안 수요를 생각할 소재를 제공하지만, 특정 기업의 매출·수익성·가치평가 자료는 제시하지 않는다. 이를 개별 종목의 투자 근거로 곧바로 연결하기는 어렵다.

⚠️ 불확실하거나 확인이 필요한 부분

• ‘인터넷 70%’라는 제목은 실제 침해 규모를 입증하지 않는다. 영상에 등장하는 PHP 보급률, 스캐너가 관측한 설치 수, 구버전 비중도 서로 다른 지표이므로 구분해야 한다.
• 취약점 이름, 심각도 9.2, 영향받는 버전, 공식 수정 지원 범위는 영상의 주장이다. 제공된 자료에는 취약점 식별번호나 공식 권고문 원문이 없어 정확한 적용 조건과 수정 버전을 확인할 수 없다.
• 영상은 성공적인 침입이 확인되지 않았다고 말하면서 공격 시도와 공격 도구 제작을 소개한다. 공격 가능성·탐지된 시도·실제 침해를 같은 의미로 취급해서는 안 된다.
• 자막 기반 정리: 타임스탬프가 있는 자막을 기준으로 정리했으며, 고유명사·수치·인용은 원문 확인 필요 시 별도 검증한다.
• 영상 속 주장: 발표자의 해석·전망·비교는 확인된 외부 사실이 아니라 영상 속 주장으로 분리해 읽는다.
• 검증 필요: 수치, 기업 실적, 정책·시장 전망은 발행 전 최신 자료로 별도 검증이 필요하다.

✅ 액션 아이템

• 각 도메인의 실제 PHP 버전을 확인하고, 호스팅 업체에 업데이트 시점과 PHP 재시작 여부를 서면으로 요청한다. WordPress에서는 도구 → 사이트 건강 → 정보 → 서버 경로를 점검한다.
• 모르는 관리자 계정, 업로드 폴더의 새 파일, 추가하지 않은 리디렉션을 확인한다. 의심 징후가 있으면 영상의 제안대로 사이트를 일시 중단하고 전문가의 대응을 받는다.
• AI 에이전트·MCP 설정과 프로젝트 환경 파일의 키를 서비스·파일 위치별로 목록화하되 값을 마스킹한다. 공개 저장소에 노출된 키는 교체하고, 불필요한 키와 AI 서비스 지출 한도를 정리한다.
• Google과 자동화·협업 서비스의 외부 앱 연결을 검토한다. 사용하지 않는 연결은 제거하고, 남은 연결에는 필요한 최소 권한만 부여하며 공유 관리자 계정은 개인별 계정으로 바꾼다.

❓ 열린 질문

• 우리 사이트에서 실제로 실행 중인 PHP는 무엇이며, 호스팅 업체가 적용한 수정과 재시작을 어떤 근거로 확인할 수 있는가?
• AI가 공격 개발을 가속한다는 영상의 사례에서, 일반적인 운영 조직이 확보할 수 있는 실제 대응 시간은 얼마나 되는가?
• 사용 중인 에이전트와 MCP 서버는 어떤 파일·메일·서비스에 접근할 수 있으며, 그중 현재 업무에 필요한 권한은 무엇인가?