"AI 보안" 태그로 연결된 2개 게시물개의 게시물이 있습니다.

무슨 결함인가​

Anthropic의 Chrome Extension Claude for Chrome(v1.0.69 이하)에서 권한이 전혀 없는 다른 Extension 하나가, 사용자 동의 한 번 없이 Claude 에이전트를 통째로 빌려 Gmail, Google Drive, GitHub의 데이터를 조회하고 외부로 빼낼 수 있는, 발신자 신원 검증이 빠진 결함이 공개됐어요.

LayerX Security가 2026-05-07에 공개했고, 발견자가 붙인 이름은 ClaudeBleed입니다. 2014년 OpenSSL의 Heartbleed, 2017년 Cloudflare의 Cloudbleed 계보를 잇는 "데이터가 새어 나온다"는 작명을 오마주했습니다. Anthropic은 하루 앞선 5월 6일 v1.0.70으로 부분 패치를 배포했지만, 같은 연구자가 약 3시간 만에 우회 경로를 찾아 함께 공개했습니다. 5월 13일 현재까지 추가 패치는 발표되지 않았으며, CVE 번호도 아직 할당되지 않았습니다.

요약 표​

externally_connectable은 누구를 신뢰하는가​

Chrome Extension 매니페스트의 externally_connectable 키는 "이 Extension의 메시지 채널을 누가 호출해도 되는가"를 선언합니다. 보통 두 가지 형태로 씁니다.

// 형태 A — 다른 Extension ID로 한정
{
  "externally_connectable": {
    "ids": ["<신뢰하는 Extension ID>"]
  }
}

// 형태 B — 특정 웹 출처(origin)로 한정
{
  "externally_connectable": {
    "matches": ["*://*.claude.ai/*"]
  }
}

Claude for Chrome은 두 번째 형태로, claude.ai 출처에서 실행되는 페이지 스크립트가 Extension에 메시지를 보낼 수 있도록 열어 뒀습니다. 사용자 입장에서 Claude 사이드 패널과 claude.ai가 한 몸처럼 동작해야 하니, 설계 의도는 자연스럽습니다.

문제는 origin이 답할 수 있는 질문의 범위입니다. origin은 "이 코드가 어느 페이지 컨텍스트에서 실행되는가"는 알지만, "그 컨텍스트 안에서 누가 그 코드를 실행시켰는가"는 모릅니다. Chrome의 Extension 모델은 임의의 Extension이 자기 content script를 다른 출처의 페이지에 주입할 수 있게 허용하며, 매니페스트의 "world": "MAIN" 옵션을 켜면 그 스크립트는 페이지 자체의 자바스크립트 컨텍스트에서 돕니다.

여기서 권한 0짜리 Extension이란, manifest.json에 permissions(tabs, storage, cookies 등)도 host_permissions(https://mail.google.com/* 같은 사이트 접근 권한)도 적지 않은 Extension을 말합니다. 사용자가 설치할 때 "이 Extension은 ~ 권한이 필요합니다" 같은 경고 화면이 거의 뜨지 않거나 가장 가벼운 형태로만 뜹니다. 그런데 content_scripts 항목은 권한 요청이 아니라 "어떤 페이지에서 이 자바스크립트를 실행해 달라"는 등록이라, 별도 권한 없이도 매니페스트에 적은 origin(여기서는 *://*.claude.ai/*)에 자기 스크립트를 끼워 넣을 수 있습니다.

즉 권한 0짜리 Extension 하나가:

1. content script로 claude.ai에 스크립트를 한 장 주입하고,
2. 그 스크립트가 페이지 컨텍스트에서 chrome.runtime.sendMessage("<Claude Extension ID>", {...}) 한 줄을 실행하면,
3. Claude Extension 입장에서는 "claude.ai에서 들어온 정상 메시지"로 보입니다.

Claude Extension의 ID(fcoeoabgfenejglbffodgkkbkcdhcgfn)는 Chrome Web Store에 그대로 공개돼 있고, Extension ID는 비밀이 아닙니다. 결과적으로 origin 화이트리스트는 ACL이 아니라 누구나 통과시키는 표지판에 가깝습니다.

LayerX는 이 호출로 도달 가능한 핸들러 중 하나로 onboarding_task를 지목했는데, 이 핸들러는 외부에서 받은 텍스트를 그대로 Claude의 작업 프롬프트로 흘려보냅니다. 즉 메시지 한 통이면 임의 프롬프트 실행과 같습니다.

공격 사슬​

전체 동작은 한 장으로 정리됩니다.

여기까지가 진입입니다. Extension ID와 origin만 알면 누구든 Claude 에이전트의 작업 큐에 항목을 하나 밀어 넣을 수 있습니다. 그 다음 단계, 즉 "어떻게 사용자 몰래 그 작업을 끝까지 수행하게 만드는가"가 아래 4가지 공격 기법으로 나뉩니다.

4가지 공격 기법​

1. Confused Deputy​

Claude Extension은 "claude.ai에서 온 메시지면 정상"이라는 전제로 동작합니다. 그러나 실제 메시지를 만든 주체는 사용자가 띄운 claude.ai 페이지가 아니라, 사용자가 설치해 둔 다른 Extension이 페이지 위에 얹어 놓은 스크립트입니다. 정당한 권한을 가진 대리인(Claude Extension)이 자기 권한 밖의 호출자(악성 Extension)를 위해 일하게 되는, 교과서적인 confused deputy 구도입니다.

이 구도가 위험한 이유는 권한 상승의 비용이 0이라는 점입니다. 공격 Extension은 호스트 권한도, 탭 권한도, storage도 필요 없습니다. content script 하나만 선언하면 끝납니다.

2. 승인 루핑(Approval Looping)​

Claude는 민감한 작업을 수행하기 전 사용자에게 확인을 받는 단계를 거칩니다. 그런데 그 확인이 "지금 이 특정 행동에 대한 동의"가 아니라 "지금 사용자가 활성화한 모드"로만 검사되기 때문에, 같은 채널로 "Yes, proceed"에 해당하는 메시지를 반복 전송하면 확인 흐름을 그대로 통과시킬 수 있습니다.

토큰이 특정 행동에 바인딩돼 있지 않은 탓입니다. 한 번 받은 동의가 다음 동의가 필요한 자리에서 다시 통하면, 동의 절차는 이름만 남고 실제 통제력을 잃습니다.

3. DOM 라벨 위장​

Claude 에이전트는 페이지의 DOM을 읽어 어떤 버튼이 무슨 동작인지 판단합니다. 악성 Extension이 DOM을 살짝 바꿔 두면(예를 들어 "외부에 공유" 버튼의 라벨을 "피드백 요청"으로) 에이전트의 인식과 실제 동작이 어긋납니다. 에이전트는 무해한 작업으로 알고 누르지만, 실제 클릭은 원래 핸들러를 그대로 부릅니다.

이 기법은 ClaudeBleed에만 국한되지 않는, 브라우저 안에서 도는 모든 AI 에이전트의 일반 약점에 가깝습니다. 에이전트가 의미를 DOM에서 끌어내는 한, DOM을 만질 수 있는 쪽이 의미를 다시 정의할 수 있습니다.

4. Privileged Mode 우회​

Claude for Chrome은 두 가지 모드를 둡니다. Ask before acting(매 행동마다 확인)과 Act without asking(자율 수행). v1.0.70 패치는 Ask 모드에서 외부 메시지가 임의 행동을 일으키지 못하도록 사이드 패널 안에 명시적 승인 흐름을 추가했습니다.

하지만 LayerX는 공격자가 사이드 패널의 초기화 흐름을 가로채 Act without asking 쪽으로 진입시키는 우회 경로를 약 3시간 만에 확인했습니다. 모드 전환이 사용자에게 통보되지 않기 때문에, 사용자는 자기 Extension이 자율 모드로 돌고 있는지 알 길이 없습니다.

요약하면 패치는 증상인 승인 UI 흐름만 가렸을 뿐, 원인인 메시지 발신자 신원 검증 부재는 손대지 못했습니다. 발신자가 누구인지 확인하지 못하는 한 어느 모드에서든 우회 경로는 다시 열립니다.

이 결함으로 가능한 위협 시나리오​

이 결함이 가능하게 만드는 작업은 평범한 사용자 시나리오로 옮기면 그대로 사고로 이어집니다.

• Gmail의 받은편지함을 요약시켜 외부 주소로 메일 발송
• Google Drive 비공개 문서에 공유 링크를 발급해 외부 노출
• GitHub 비공개 리포지토리의 파일 내용을 챗 응답에 끼워 빼내기
• 사용자 대신 메일 발송, 문서 삭제로 흔적 정리
• 외부 캘린더 초대, Slack 메시지 발송 같은 OAuth 권한 위임 작업 일반

세 가지가 함께 성립한다는 점이 무겁습니다. 공격 Extension에 별도 권한이 필요 없고, 사용자 상호작용도 필요 없으며, EDR이나 안티바이러스 관점에서는 정상 Extension의 정상 호출처럼 보입니다.

특히 사내 표준 브라우저에 권장 Extension 목록만 통제하는 조직에서는, Claude for Chrome이 그 권장 목록에 있고 사용자가 자율적으로 다른 Extension 하나를 추가했다는 사실만으로 위협 모델이 무너집니다.

공개 타임라인​

보고에서 패치까지 9일, 패치에서 우회 공개까지 1일입니다. 빠르게 막은 흔적은 있지만, "누가 메시지를 보냈는지 다시 설계하는" 종류의 수정은 그 사이에 들어가지 못한 모양새입니다.

사용자가 오늘 할 일​

근본 패치가 발표되기 전까지, 권장 조치는 단순합니다.

1) Claude for Chrome Extension 끄기 또는 제거하기​

chrome://extensions 에서 Claude for Chrome 항목의 토글을 끄는 것만으로 공격 표면이 즉시 사라집니다. 자주 안 쓴다면 제거가 가장 깔끔합니다. 데스크톱 클라이언트나 웹 claude.ai 사용에는 영향이 없습니다.

2) 끌 수 없다면 민감 세션과 분리하기​

Claude for Chrome을 켜 둔 프로파일에는 Gmail, Google Drive, GitHub 같은 민감 서비스에 로그인하지 않습니다. Chrome 프로파일 분리(다른 사용자) 또는 별도 브라우저(Chrome Canary, Firefox 등)로 일/개인 작업과 AI 에이전트 작업을 분리해 둡니다.

3) 다른 Extension도 함께 점검하기​

ClaudeBleed의 트리거는 "다른 Extension 하나"입니다. 사용 중인 Extension의 수와 신뢰도를 같이 봅니다.

chrome://extensions  →  세부 정보  →  사이트 액세스 / 권한

설치 출처가 불분명하거나, 더 이상 안 쓰는 Extension은 이 기회에 정리해 둡니다. content script 권한이 광범위한 Extension(예: <all_urls>)일수록 위험 가중치가 높습니다.

4) 조직 단위 통제가 가능한 경우​

ChromeOS/Chrome Enterprise 환경에서는 ExtensionInstallBlocklist로 Claude for Chrome Extension ID(fcoeoabgfenejglbffodgkkbkcdhcgfn)를 막거나, ExtensionInstallAllowlist로 허용 Extension 목록을 좁힌 뒤 차차 풀어 가는 방식이 안전합니다. BYOD 환경이면 사용자 공지와 함께 자율 비활성화를 권고합니다.

정리​

• ClaudeBleed의 본질은 코드 한 줄짜리 버그가 아니라 origin을 신원으로 착각한 설계에 있습니다. Chrome Extension 모델이 허용하는 content script + MAIN world 조합 앞에서 origin 화이트리스트는 ACL 노릇을 못 합니다.
• v1.0.70 패치는 승인 UI 흐름을 추가했지만, 메시지 발신자 신원 검증 부재라는 원인은 그대로 남았습니다. 그래서 Act without asking 모드를 강제 진입시키는 우회 경로가 같은 날 다시 열렸습니다.
• 에이전트가 강할수록 누가 부르는지를 더 정밀히 따져야 합니다. 발신자 인증(서명 토큰, Extension ID 화이트리스트), 행동-바인딩된 일회성 동의가 합쳐져야 비로소 동의가 동의로 기능합니다.
• 추가 패치 전까지는 Claude for Chrome 사용을 잠시 멈추는 게 가장 단순하고 확실한 완화입니다. 끌 수 없다면 민감 세션과 프로파일을 분리합니다.

이번 사건이 Anthropic만의 문제로 끝나지 않을 가능성도 함께 짚어 둬요. 브라우저 안에서 도는 AI 에이전트 Extension은 모두 같은 함정(외부 메시지 채널, DOM을 통한 의미 인식, 자율 모드의 UX/보안 트레이드오프) 위에 서 있어요. ClaudeBleed는 그 함정 중 첫 번째 사례로 기록될 공산이 커요.

참고​

• A Flaw in Claude's Browser Extension Allows Any Extension to Hijack It (LayerX Security, ClaudeBleed 원 공시)
• Vulnerability in Claude Extension for Chrome Exposes AI Agent to Takeover (SecurityWeek, 사건 요약과 Anthropic 대응)
• Researcher hacks Claude Code Chrome fix in 3 hours (Cybernews, 3시간 우회 보도)
• ClaudeBleed Vulnerability Lets Hackers Hijack Claude Chrome Extension to Steal Data (Hackread, 연구자 코멘트 포함)
• externally_connectable (Chrome Developers, 매니페스트 키 공식 문서)

732바이트짜리 파이썬 스크립트 하나로 2017년 이후 빌드된 거의 모든 주요 리눅스 배포판에서 root를 따낼 수 있습니다. 이번에 공개된 커널 논리 버그 Copy Fail 이야기예요.

표준 라이브러리만 쓰고, race condition도 없고, 배포판별 오프셋도, 컴파일된 셸코드 페이로드도 필요 없습니다. Ubuntu, RHEL, Amazon Linux, SUSE에서 같은 스크립트가 그대로 돕니다. 어제(2026-04-29) 공개됐고, 발견자는 한국 보안업체 Theori의 Taeyang Lee, 도구는 자체 AI 코드 감사기 Xint Code입니다.

Dirty COW/Dirty Pipe와 무엇이 다른가​

이 자리는 익숙합니다. 2016년의 Dirty COW, 2022년의 Dirty Pipe도 모두 비특권 사용자가 페이지 캐시에 손을 대서 setuid 바이너리를 갈아치우는 LPE였습니다. 그런데 그 둘과 Copy Fail의 결정적인 차이는 race가 없다는 점입니다.

"직선형 논리 버그"라는 표현이 이 결함을 잘 짚습니다. 흐름이 분기 없이 일자로 흐르고, 각 단계가 의도대로 떨어지면 페이지 캐시의 정해진 위치에 정해진 바이트가 쓰입니다. 운영자 입장에서는 가장 무서운 형태의 LPE인데, 패치하기 전까지는 누구나 한 번에 성공하기 때문입니다.

세 가지 변경의 우연한 교차점​

Copy Fail은 단일 버그가 아닙니다. 시기가 다른 세 가지 커널 변경이 한 자리에서 만나면서 만들어진 함정입니다.

각각만 보면 그럴듯한 변경입니다. 문제는 셋이 만나는 지점입니다.

1. splice()로 읽기 전용 파일의 페이지 캐시 페이지를 AF_ALG의 TX scatterlist에 그대로 참조로 넣습니다.
2. 2017년 인-플레이스 최적화가 그 TX scatterlist를 그대로 쓰기 가능한 dst scatterlist로 재사용합니다.
3. authencesn은 dst[assoclen + cryptlen] 위치에 ESN 임시값(4바이트)을 씁니다. 그 자리가 1번에서 체인된 페이지 캐시 페이지입니다.

그 결과 비특권 사용자가 임의 파일의 페이지 캐시에 결정론적인 4바이트 쓰기를 하게 됩니다. 거의 10년 동안 조용히 익스플로잇 가능한 상태로 있었습니다.

익스플로잇 흐름​

PoC는 copy.fail에 공개돼 있고 본문에는 옮기지 않습니다. 동작 원리는 다음과 같습니다.

순서를 풀면 이렇습니다.

1. AF_ALG 소켓을 열어 authencesn(...) 알고리즘에 bind합니다.
2. 타깃 setuid 바이너리(/usr/bin/su 등)를 열어 그 페이지 캐시 페이지를 splice()로 소켓의 TX scatterlist에 주입합니다.
3. 쉘코드를 4바이트 단위로 잘라, 매번 위치 계산을 맞춰 sendmsg() + splice() 페어를 반복합니다.
4. recv()를 호출하면 복호화 동작이 이뤄지며 authencesn이 ESN 임시값을 dst(즉 손에 들어온 페이지 캐시 페이지)에 4바이트씩 기록합니다.
5. 마지막으로 execve("/usr/bin/su"). 손상된 페이지 캐시에서 로드된 setuid 바이너리가 쉘코드를 root 권한으로 실행합니다.

PoC가 이렇게 짧은 이유는 모든 단계가 표준 syscall과 표준 라이브러리만 쓰기 때문입니다. 컴파일러도, 외부 페이로드도 필요 없습니다.

왜 이게 무서운가​

세 가지가 겹칩니다.

먼저 디스크를 건드리지 않습니다. 손상은 페이지 캐시에서만 일어나기 때문에 디스크 파일의 해시는 그대로입니다. AIDE/Tripwire 같은 무결성 모니터링이 잡지 못합니다. 재부팅하거나 페이지가 evict되면 캐시는 정상 복원되지만, 그 사이에 익스플로잇은 끝납니다.

다음으로 페이지 캐시는 호스트 전체가 공유합니다. 컨테이너는 같은 호스트 커널의 같은 페이지 캐시를 봅니다. 즉 비특권 컨테이너 안에서 일으킨 4바이트 쓰기가 호스트의 setuid 바이너리, 또는 옆 컨테이너의 read-only mount 파일을 손상시킬 수 있습니다. K8s 노드, 멀티테넌트 SaaS, 공유 CI 러너가 1순위 위험군입니다. namespace 격리만 쓰는 컨테이너 모델이 이 한 줄짜리 버그 앞에서 그대로 뚫립니다.

마지막으로 CVSS는 7.8(High)로 매겨졌습니다. Critical이 아닌 이유는 로컬 액세스가 필요해서일 뿐이고, 한번 로컬이 잡히면 결정론적으로 root까지 직행합니다. 실무 영향은 Critical과 다를 게 없습니다.

AI가 한 시간 만에 찾았다는 것의 의미​

이 발견의 또 다른 화제는 도구입니다. 발견자는 Theori의 Taeyang Lee, 도구는 자체 개발한 AI 기반 보안 스캐너 Xint Code입니다. 단일 오퍼레이터 프롬프트로 Linux 커널의 crypto/ 서브시스템 전체를 약 한 시간 동안 감사했고, 이 버그가 가장 심각한 항목으로 보고됐습니다.

AI가 사람보다 똑똑해서 찾은 것은 아닙니다. "AF_ALG와 splice가 만나는 자리가 실은 거대한 비특권 공격 표면"이라는 가설을 사람이 정해주면, AI는 그 가설을 전체 코드 경로에 결정론적으로 적용해 보는 일을 사람과 비교가 안 되게 잘합니다. 그렇게 10년 동안 사람 손에 안 잡힌 코드 경로 하나를 끄집어냈습니다.

The Register는 Trend Micro Zero Day Initiative의 Dustin Childs를 인용해 "최근 취약점 제보 폭증의 가장 큰 변수는 AI 기반 버그 발견"이라고 보도했습니다. 이 흐름이 운영자 입장에서 의미하는 건 단순합니다. 패치 사이클이 더 짧아져야 하고, 오늘 멀쩡해 보이는 코드가 내일도 멀쩡하리라 가정하지 말아야 한다는 것입니다.

공개 타임라인​

보고에서 메인라인 패치까지 9일이 걸렸습니다. 빠른 편입니다. 그러나 메인라인 패치와 각 배포판의 안정 커널이 사용자 손에 들어오는 시점 사이에는 늘 며칠에서 몇 주의 갭이 있고, 그 사이가 운영자에게 가장 위험한 구간입니다.

운영자 대응 가이드​

즉시 완화, 정식 패치, 검증 세 단계로 나눠 봅니다.

1) 즉시 완화: algif_aead 모듈 차단 (재부팅 불필요)​

LUKS, kTLS, IPsec은 AF_ALG 사용자 공간 인터페이스가 아닌 다른 경로를 쓰기 때문에 영향이 없습니다. 영향을 받는 건 OpenSSL의 afalg 엔진처럼 AF_ALG를 명시적으로 호출하는 경우뿐입니다. 즉 일반 서버에서는 모듈 차단으로 인한 부작용이 거의 없습니다.

단, 차단이 가능한지부터 확인해야 합니다. RHEL 9/10 일부 빌드는 algif_aead가 LKM이 아니라 커널 빌트인이고, 그러면 modprobe로 막을 수 없습니다.

# 모듈로 로드돼 있는지
lsmod | grep algif_aead

# 빌트인인지 (filename: (builtin) 이면 차단 불가)
modinfo algif_aead 2>/dev/null | head -3

LKM인 경우, modprobe로 차단합니다.

echo 'install algif_aead /bin/true' | sudo tee /etc/modprobe.d/disable-algif_aead.conf
sudo rmmod algif_aead 2>/dev/null || true

/bin/false 대신 /bin/true를 쓰는 이유는 다른 모듈이 의존성으로 algif_aead를 끌어올 때 modprobe가 에러를 뱉지 않도록 하기 위해서입니다. 어느 쪽이든 모듈은 올라오지 않습니다.

빌트인인 경우, modprobe 차단은 효과가 없습니다. 두 가지 우회 중 하나를 씁니다.

• SELinux/AppArmor로 AF_ALG 사용을 제한합니다. 일반 사용자 도메인에서 socket(AF_ALG, ...) 호출 자체를 막는 정책입니다. 정책 변경이라 운영 검증이 필요합니다.
• 정식 패치 일정을 앞당깁니다. 빌트인 환경에서는 사실상 이 옵션이 가장 현실적입니다.

2) 정식 패치 (재부팅 필요, kpatch 가능 시 무중단)​

RHEL/Rocky/Alma:

sudo dnf updateinfo list cves | grep CVE-2026-31431  # RHSA 발행 확인
sudo dnf update kernel kernel-core kernel-modules
sudo reboot

Ubuntu/Debian:

sudo apt update
apt list --upgradable 2>/dev/null | grep -E '^linux-(image|generic|headers)'
sudo apt install --only-upgrade linux-image-$(uname -r | sed 's/-generic//')-generic
sudo reboot
# Ubuntu Pro의 경우
sudo pro status
canonical-livepatch status   # 라이브 패치 발행 여부

라이브 패치(kpatch/canonical-livepatch)가 발행돼 있다면 재부팅 없이 적용 가능합니다. 프로덕션 노드는 우선 라이브 패치로 막은 뒤 다음 정기 점검 창에서 재부팅하는 편이 안전합니다.

3) 검증​

uname -r

# RHEL 계열
rpm -q --changelog kernel-core | grep -i 31431 | head

# Debian/Ubuntu 계열
apt changelog linux-image-$(uname -r) 2>/dev/null | grep -i 31431 | head

CHANGELOG에 CVE 번호가 보이면 패치된 빌드입니다. 라이브 패치를 적용한 경우에는 kpatch list 또는 canonical-livepatch status로 적재된 패치 목록을 함께 확인합니다.

배포판 대응 현황​

여러 배포판이 초기에 "Moderate"로 분류했다가 PoC 공개와 함께 "High"로 재분류한 점도 이번 사례의 특징입니다. race 없는 LPE의 운영 영향이 통상 분류보다 크다는 걸 확인한 결과입니다.

정리​

• Copy Fail은 race 없는 결정론적 LPE입니다. 패치 전까지는 누구나 한 번에 root를 따냅니다.
• 단일 버그가 아니라 2011, 2014, 2017년에 들어간 세 변경의 우연한 교차점에서 만들어졌습니다.
• 페이지 캐시 쓰기 프리미티브라 디스크 무결성 검사로는 잡히지 않고, 컨테이너 격리만으로는 막지 못합니다.
• 즉시 완화는 algif_aead 모듈 차단이지만 빌트인 환경에서는 무효입니다. 환경부터 확인해야 합니다.
• 정식 패치는 재부팅이 필요합니다. kpatch나 canonical-livepatch가 가능한 환경이면 무중단 적용을 우선 검토합니다.

다음 글에서는 이 글에서 다루지 않은 두 가지를 따로 봐요. 컨테이너 탈출(user namespace 경계에서의 동작 검증), 그리고 AI 기반 보안 스캐너를 운영 파이프라인에 도입할 때의 트레이드오프예요.

참고​

• copy.fail — Theori의 공식 공시 페이지, 기술 분석과 PoC 원본
• Bugcrowd: What we know about Copy Fail — 운영자 관점 영향 정리
• OpenCVE: CVE-2026-31431 — CVSS, EPSS, 영향 제품 메타데이터
• Red Hat: CVE-2026-31431 — RHSA/완화 가이드
• GeekNews 토픽 — 한국 커뮤니티 토론 (특히 builtin 환경 토론)
• 메인라인 패치 커밋 a664bf3d603d (2017년 인-플레이스 최적화 72548b093ee3 되돌림)