Google이 활발히 악용되는 Android 취약점을 패치했습니다. 기업은 이를 AI 보안 문제로도 취급해야 합니다

Google은 최근 수백만 대의 기기에 영향을 미치는, 활발히 악용되고 있는 Android 취약점을 패치했습니다.

대부분의 팀은 이 문장을 읽고 이를 모바일 패치 문제로 취급할 것입니다.

그것이 틀린 것은 아닙니다.

하지만 불충분합니다.

2026년에 해킹된 모바일 기기는 단순한 기기 문제가 아닙니다. 그것은 AI 보안 (AI security) 문제도 될 수 있습니다.

직원들은 업무용 이메일, SaaS 대시보드, MFA(다요소 인증) 승인, 브라우저 세션, 파일 액세스, 채팅 앱, 그리고 AI 도구를 위해 Android 폰을 사용합니다. 그들은 업무 데이터를 ChatGPT, Gemini, Claude, Copilot 및 기타 AI 플랫폼에 붙여넣습니다. 그들은 모바일 기기에서 로그인을 승인합니다. 그들은 모바일 브라우저에서 내부 문서를 읽습니다. 그들은 하루 종일 기업용 앱과 개인용 도구 사이를 오갑니다.

따라서 Android 취약점이 활발히 악용될 때, 보안 팀은 다음과 같이 질문해서는 안 됩니다:

“우리가 기기를 패치했는가?”

그들은 또한 다음과 같이 질문해야 합니다:

“해당 기기가 침해될 경우, 어떤 기업 데이터, AI 활동, SaaS 액세스 및 프롬프트 워크플로 (prompt workflows)가 노출될 수 있는가?”

이것이 대부분의 조직이 여전히 놓치고 있는 부분입니다.

Google이 패치한 내용

Security Affairs에 따르면, Google은 Android 전반에 걸친 124개의 취약점을 수정하는 2026년 6월 Android 보안 업데이트를 출시했습니다.

가장 중요한 것은 CVE-2025-48595입니다.

이는 CVSS 점수가 8.4인 Android Framework 취약점입니다. 이는 Android 14, Android 15, Android 16 및 Android 16 QPR2에 영향을 미칩니다.

Google은 CVE-2025-48595가 제한적이고 표적화된 공격 (targeted exploitation)을 받고 있을 가능성이 있다는 징후가 있다고 밝혔습니다.

이 문제는 정수 오버플로 (integer overflow)로 인해 발생하며, 취약한 기기에서 코드 실행 (code execution) 및 권한 상승 (privilege escalation)으로 이어질 수 있습니다. 권한 상승은 공격자가 제한된 액세스에서 시스템에 대한 더 깊은 제어로 이동할 수 있게 하므로 중요합니다.

Security Affairs는 또한 Google이 공격자, 전달 방법 또는 피해자 수를 공개적으로 밝히지 않았다고 언급했습니다.

이러한 세부 정보의 부족은 활발히 악용되는 취약점 사례에서 일반적입니다. 하지만 이는 기업이 행동하기 전에 완벽한 정보가 나오기를 기다려서는 안 된다는 의미이기도 합니다.

취약점이 이미 악용되고 있다면, 패치 윈도우 (patch window)는 더 이상 이론적인 문제가 아닙니다.

현실의 문제입니다.

권한 상승 (Privilege Escalation)이 중요한 이유

권한 상승 (Privilege escalation)이 항상 공격의 첫 번째 단계인 것은 아닙니다.

종종, 이는 첫 번째 거점 (foothold)을 위험하게 만드는 단계가 됩니다.

악성 앱, 피싱 링크, 익스플로잇 체인 (exploit chain), 또는 탈취된 기기 세션은 제한된 액세스로 시작될 수 있습니다. 하지만 권한 상승에 성공하면, 공격자는 기기 리소스, 앱 데이터, 토큰 (tokens), 파일, 클립보드 활동, 브라우저 세션, 또는 기업용 애플리케이션에 대해 더 깊은 액세스 권한을 얻을 수 있습니다.

명확히 하자면, CVE-2025-48595가 AI 프롬프트 (prompts)나 SaaS 데이터를 훔치는 데 사용되고 있다는 공개적인 증거는 없습니다.

그것이 주장은 아닙니다.

진정한 요점은 이러한 결함이 더 광범위한 공격 체인 (attack chain)의 일부가 될 수 있다는 것입니다.

그리고 만약 탈취된 기기가 AI 도구, 업무 데이터, SaaS 앱, 인증, 그리고 브라우저 기반 워크플로 (workflows)에 사용된다면, 그 체인은 기업의 AI 활동에까지 도달할 수 있습니다.

이것이 바로 모바일 엔드포인트 보안 (mobile endpoint security)이 이제 AI 보안과 겹치는 이유입니다.

취약점 자체가 AI 결함이기 때문이 아닙니다.

기기가 바로 기업 데이터와 AI가 만나는 지점이기 때문입니다.

이것이 왜 AI 보안 문제가 되는가

AI 도입은 엔드포인트 침해 (endpoint compromise)의 가치를 변화시켰습니다.

몇 년 전만 해도, 침해된 휴대폰은 이메일, 파일, 연락처, 또는 로그인 세션을 노출할 수 있었습니다.

그것만으로도 이미 심각한 문제였습니다.

이제 동일한 환경에 AI 사용을 추가해 보십시오.

직원들은 다음과 같은 목적으로 모바일 기기를 사용할 수 있습니다:

• ChatGPT, Gemini, Claude, Copilot, 또는 Perplexity 접속
• AI 도구에 고객 데이터 붙여넣기
• 내부 문서 요약
• CRM 메모를 바탕으로 영업 이메일 초안 작성
• 스크린샷 또는 파일 분석
• 모바일 브라우저를 통한 AI 사용
• MFA 앱을 통한 로그인 승인
• 관리되지 않는 네트워크에서 SaaS 대시보드 열기
• 개인 계정과 기업 계정 간의 데이터 이동

이는 더 넓은 공격 표면 (risk surface)을 생성합니다.

이제 직원들은 AI 도구, SaaS 앱, 브라우저 세션, 업무용 이메일 및 인증 워크플로우 (authentication workflows)에 접속하기 위해 Android 기기를 사용합니다. 이는 모바일 침해 (mobile compromise)가 단순한 파일 이상의 것을 노출할 수 있음을 의미합니다. 직원들이 AI 시스템으로 전송하는 데이터가 노출될 수 있습니다.

이것이 바로 AI 데이터 유출 방지 (AI data leakage prevention)가 AI 모델이나 챗봇 인터페이스뿐만 아니라 엔드포인트 (endpoint) 계층을 포함해야 하는 이유입니다.

위험은 단지 "누군가가 AI에 민감한 데이터를 붙여넣었다"는 것에 그치지 않습니다.

위험 요소는 다음과 같습니다:

누가 붙여넣었는가?

어떤 기기에서 했는가?

해당 기기는 관리되고 있었는가?

세션 (session)이 보호되었는가?

데이터가 제출되기 전에 분류 (classified)되었는가?

해당 AI 도구가 승인되었는가?

프롬프트 (prompt)가 기록되었는가?

해당 동작이 차단되었는가, 경고되었는가, 아니면 허용되었는가?

오늘날 대부분의 조직은 이러한 질문에 명확하게 답할 수 없습니다.

이것이 바로 AI 보안 격차 (AI security gap)입니다.

패치 격차 (Patch Gap)가 진정한 기업 리스크입니다

Android 패치에는 알려진 구조적 문제가 있습니다.

Pixel 기기는 보통 업데이트를 빠르게 받습니다. 하지만 다른 제조사들은 패치가 사용자에게 도달하기 전, 추가적인 테스트, 커스터마이징, 그리고 통신사나 OEM의 배포 시간이 필요한 경우가 많습니다.

Security Affairs는 이러한 파편화된 업데이트 모델로 인해 취약점이 공개된 후에도 일부 사용자가 몇 주 또는 몇 달 동안 노출된 상태로 남을 수 있다고 지적했습니다.

공격자들은 이를 이해하고 있습니다.

패치가 출시되면 방어자는 수정 사항을 얻지만, 공격자 또한 신호를 얻습니다. 그들은 패치를 역공학 (reverse engineer)하여 취약한 코드 경로를 식기하고, 아직 업데이트되지 않은 기기를 찾아낼 수 있습니다.

기업 입장에서 리스크는 단순히 Google이 패치를 출시했는지 여부가 아닙니다.

진정한 리스크는 비즈니스 시스템에 접속하는 모든 직원 기기가 실제로 패치를 받았는지 여부입니다.

이 지점에서 보안 태세 (security posture)가 복잡해집니다.

어떤 기기는 기업에서 관리합니다.

어떤 기기는 BYOD (Bring Your Own Device)입니다.

어떤 기기는 개인 프로필을 통해 업무용 앱에 접속합니다.

어떤 기기는 구버전의 OS를 사용합니다.

어떤 기기는 관리되지 않는 브라우저를 사용합니다.

어떤 기기는 개인 계정을 통해 AI 도구에 접속합니다.

어떤 기기는 IT 부서의 눈에 보이지 않습니다.

마지막 부분이 가장 중요합니다.

보이지 않는 것은 보호할 수 없습니다.

모바일 기기가 Shadow AI 게이트웨이가 되고 있습니다

Shadow AI (그림자 AI)는 보통 웹이나 SaaS 문제로 논의됩니다.

직원들이 승인되지 않은 AI 도구를 사용합니다. 민감한 데이터를 붙여넣습니다. 개인 계정을 생성합니다. 보안 팀은 가시성 (Visibility)을 잃게 됩니다.

하지만 모바일 기기는 이 문제를 더 어렵게 만듭니다.

직원이 낮 동안에는 관리되는 노트북에서 승인된 AI 도구를 사용할 수 있지만, 밤에는 개인용 Android 폰을 사용하여 동일한 작업을 계속할 수 있습니다. 그들은 모바일 AI 앱에 메모를 붙여넣을 수 있습니다. 스크린샷을 업로드할 수 있습니다. 고객 정보를 요약할 수 있습니다. AI에게 기밀 내부 콘텐츠를 다시 작성해 달라고 요청할 수 있습니다.

직원의 관점에서는 이것이 무해하게 느껴집니다.

보안의 관점에서는 이것이 사각지대 (Blind spot)를 만듭니다.

조직은 다음 사항에 대해 가시성을 확보하지 못할 수 있습니다:

• 어떤 AI 도구가 사용되고 있는지
• 어떤 계정이 사용되고 있는지
• 어떤 데이터가 붙여넣어지고 있는지
• 프롬프트 (Prompt)에 개인정보 (PII), 자격 증명 (Credentials), 소스 코드 또는 금융 데이터가 포함되어 있는지
• 해당 활동이 패치된 기기에서 발생하는지 아니면 패치되지 않은 기기에서 발생하는지
• AI 도구가 승인되었는지 아니면 관리되지 않는 도구인지

이것이 바로 Shadow AI 발견 (Shadow AI discovery)이 단순한 거버넌스 차원의 권장 사항이 아니라 실제적인 요구 사항이 되고 있는 이유입니다.

Android 결함은 이와 동일한 더 큰 문제를 상기시켜 줍니다.

기업 데이터는 더 이상 관리되는 노트북을 통해서만 이동하지 않습니다.

데이터는 브라우저, 모바일 기기, AI 도구, 개인 계정, 복사된 텍스트, 파일, 스크린샷, 채팅 및 프롬프트를 통해 이동합니다.

보안 팀이 기존의 경로만 모니터링한다면, 새로운 경로를 놓치게 될 것입니다.

전통적인 엔드포인트 사고방식만으로는 부족한 이유

전통적인 엔드포인트 보안 (Endpoint security)은 기기 상태, 멀웨어 탐지, 패치 상태 및 액세스 제어 (Access control)에 집중합니다.

이러한 요소들은 여전히 중요합니다.

하지만 AI 워크플로 (Workflow)는 다른 질문을 던집니다:

AI 상호작용을 통해 엔드포인트를 떠나고 있는 데이터는 무엇인가?

기기가 패치되었더라도 AI 도구로 데이터가 유출될 수 있습니다.

사용자가 다요소 인증 (MFA)을 통과하더라도 관리되지 않는 챗봇 (Chatbot)에 기밀 정보를 붙여넣을 수 있습니다.

브라우저 세션 (Browser session)이 정당하더라도 민감한 콘텐츠가 승인되지 않은 AI 어시스턴트 (AI assistant)로 이동할 수 있습니다.

이것이 바로 엔드포인트 보안 (Endpoint security)과 AI 보안 (AI security)이 함께 작동해야 하는 이유입니다.

보안 팀은 기기가 안전한지뿐만 아니라, 액세스 권한이 부여된 후 사용자가 기업 데이터로 무엇을 하고 있는지도 알아야 합니다.

이는 AI 보안이 모델 (Model) 단계에서 시작되어서는 안 된다는 것을 의미합니다.

상호작용이 일어나는 지점에서 시작되어야 합니다.

프롬프트 필드 (Prompt fields).

파일 업로드 (File uploads).

복사 및 붙여넣기 동작 (Copy paste actions).

브라우저 세션 (Browser sessions).

모바일 AI 앱 (Mobile AI apps).

SaaS 워크플로 (SaaS workflows).

에이전트 동작 (Agent actions).

기업 데이터가 AI와 접촉하는 모든 곳에서 보안은 가시성 (Visibility)과 강제 적용 (Enforcement)이 필요합니다.

보안 팀이 지금 즉시 해야 할 일

첫 번째 단계는 명확합니다.

Android 기기를 신속하게 패치하십시오.

하지만 거기서 멈추는 것은 나태한 보안입니다.

기업은 이러한 종류의 취약점을 모바일 AI 노출을 더 광범위하게 검토하기 위한 트리거 (Trigger)로 취급해야 합니다.

보안 팀이 해야 할 일은 다음과 같습니다.

첫째, 어떤 Android 기기가 업무용 이메일, SaaS 앱, 클라우드 스토리지, AI 도구 및 인증 워크플로 (Authentication workflows)에 접근할 수 있는지 식별하십시오.

둘째, 고위험 사용자의 우선순위를 정하십시오. 경영진, 엔지니어, 재무 팀, 법무 팀, 보안 팀, 인사(HR) 팀, 그리고 고객 데이터나 소스 코드에 접근할 수 있는 모든 사람은 가장 먼저 패치되고 점검되어야 합니다.

셋째, 기기 상태 점검 (Device posture checks)을 강제하십시오. 민감한 앱은 구형이거나 규정을 준수하지 않는 기기에서 접근할 수 없어야 합니다.

넷째, BYOD (Bring Your Own Device) 액세스를 검토하십시오. 개인 기기가 AI 도구와 기업 SaaS 시스템에 접근할 수 있다면, 조직은 명확한 정책과 가시성을 갖춰야 합니다.

다섯째, AI 프롬프트 및 파일 흐름을 모니터링하십시오. 보안 팀은 직원이 어떤 AI 도구를 사용하는지, 어떤 데이터를 붙여넣는지, 그리고 해당 활동이 관리되는 기기 또는 관리되지 않는 기기를 통해 발생하는지에 대한 가시성이 필요합니다.

이 지점에서 기업용 AI 보안 방화벽 (enterprise AI security firewall)이 유용해집니다. 단순히 네트워크 액세스뿐만 아니라, AI 상호작용(interaction) 주위에 제어 계층(control layer)을 제공하기 때문입니다.

여섯째, 민감한 데이터가 AI 도구에 입력되기 전에 분류하십시오. 개인정보(PII), 개인 건강정보(PHI), 자격 증명(credentials), 비밀 정보(secrets), 소스 코드(source code), 금융 데이터(financial data) 및 내부 문서는 제출되기 전에 탐지되어야 합니다.

일곱째, 감사 준비(audit readiness)를 위해 AI 활동을 기록(log)하십시오. 민감한 프롬프트(prompt)가 차단되었는지 또는 허용되었는지에 대한 기록이 있어야 합니다.

여덟째, AI 사용 정책을 엔드포인트(endpoint) 정책과 일치시키십시오. 기기 액세스가 관리되지 않는 상태에서 AI 거버넌스(governance)가 PDF 파일 속에만 머물러 있어서는 안 됩니다.

실질적인 목표는 간단합니다:

패치되지 않았거나 관리되지 않는 엔드포인트가 기업용 AI 데이터로 들어가는 가장 쉬운 경로가 되지 않도록 하십시오.

CVE-2025-48595가 주는 진짜 교훈

CVE-2025-48595는 Android 취약점입니다.

하지만 이 교훈은 Android 그 이상을 의미합니다.

모든 현대적 기업은 연결된 워크플로(workflow) 위에서 운영됩니다.

모바일 기기는 SaaS에 연결됩니다.

SaaS는 ID(identity)에 연결됩니다.

ID는 다요소 인증(MFA)에 연결됩니다.

MFA는 계정 복구(account recovery)에 연결됩니다.

브라우저는 AI 도구에 연결됩니다.

AI 도구는 프롬프트, 파일, 스크린샷, 코드, 노트 및 고객 데이터를 수신합니다.

이는 보안 팀이 더 이상 모바일, SaaS, ID, AI를 별개의 위험 카테고리로 취급해서는 안 된다는 것을 의미합니다.

공격자는 귀사의 내부 카테고리에 관심이 없습니다.

그들은 경로(path)에 관심이 있습니다.

침해된 엔드포인트는 경로입니다.

개인용 AI 계정은 경로입니다.

붙여넣은 고객 명단은 경로입니다.

모니터링되지 않는 프롬프트는 경로입니다.

업무용으로 사용되는 패치되지 않은 Android 기기는 경로입니다.

문제는 귀사의 보안 프로그램이 사고(incident)가 발생하기 전에 그 경로를 볼 수 있느냐 하는 것입니다.

AI 보안은 프롬프트 이전부터 시작됩니다

많은 팀이 여전히 AI 보안이 프롬프트가 모델에 도달할 때 시작된다고 생각합니다.

그것은 너무 늦습니다.

AI 보안은 더 일찍 시작됩니다.

기기에서 시작됩니다.

브라우저에서 시작됩니다.

ID 세션(identity session)에서 시작됩니다.

파일에서 시작됩니다.

클립보드(clipboard)에서 시작됩니다.

앱에서 시작됩니다.

계정에서 시작됩니다.

그리고 사용자 행동(user action)에서 시작됩니다.

민감한 데이터가 AI 도구에 도달할 때쯤이면, 조직은 이미 통제권 싸움에서 부분적으로 패배한 상태입니다.

그렇다고 해서 AI 도입을 차단해야 한다는 의미는 아닙니다.

AI를 차단하면 보통 직원들이 더 나쁜 행동을 하도록 내몰게 됩니다. 그들은 개인 계정, 개인 기기, 그리고 승인되지 않은 앱을 사용하게 됩니다. 이는 가시성(visibility)을 더욱 떨어뜨립니다.

더 나은 해답은 통제된 활성화(controlled enablement)입니다.

직원들이 AI를 사용하게 하십시오.

하지만 데이터가 이동하는 곳에서 보안을 강제하십시오.

프롬프트 필드(prompt fields)를 모니터링하십시오.

민감한 콘텐츠를 분류(classify)하십시오.

위험한 제출(submissions)에 대해 경고하거나 차단하십시오.

관리되지 않는 AI 도구를 탐지하십시오.

활동을 로그(log)로 남기십시오.

AI 액세스를 기기 상태(device posture)와 연동하십시오.

모바일 AI 사용을 기업 보안 표면(enterprise security surface)의 일부로 취급하십시오.

그것이 생산성을 해치지 않으면서 AI 도입을 더 안전하게 만드는 방법입니다.

최종 요약 (Final Takeaway)

Google은 활발히 악용되고 있는 Android 결함을 패치했습니다.

보안 팀은 빠르게 패치해야 합니다.

하지만 동시에 시야를 넓혀(zoom out) 더 큰 그림을 보아야 합니다.