Copy English

Why

Four incidents in four months, and the interesting thing is not that they happened but that they share a root the usual threat model draws outside the boundary. On 2026-06-25 a compromised third-party vendor injected a wallet-drainer into Polymarket's frontend; about $2.94M left at least 11 wallets, the stolen pUSD was bridged from Polygon to Ethereum and consolidated into roughly 1,893 ETH, and every affected user was reimbursed — the vendor has still not been named publicly. On 2026-08-13 Trezor disclosed that its fulfilment partner ShipMonk had been breached, exposing 13,689 customers (11,742 with name, email, phone and shipping address; 1,947 partially) who ordered between 2026-05-10 and 2026-08-08 across seven countries — and ShipMonk's own root cause was a vulnerability in Metabase, a third party of the third party. On 2026-08-16 Bits of Gold, holder of Israel's first VASP licence, disclosed roughly 200,000 customers exposed through unauthorised access to a third-party support and analytics system. And back on 2026-05-22, $700,000 left a Polymarket internal top-up wallet in 5,000-POL batches every 30 seconds because a six-year-old private key was still valid. The reflex answer to the frontend case is to lock third-party scripts down with SRI and CSP, and that is exactly where the reflex fails. SRI verifies that a file matches a hash — the malicious script came from the trusted vendor's own infrastructure, so it was the expected file. CSP is a whitelist of where a script may load from — the vendor was on the whitelist. Both answer "was this script authorized?" and the attack's entire premise is that it was. The question worth building around is the one neither control asks: what is this authorized script allowed to do?

How it works

The build is an inventory and a containment test, in that order. Inventory: for one real frontend, list every third-party script and every vendor holding customer PII, and go one layer down where it is discoverable — ShipMonk's exposure arrived through Metabase, and a list that stops at direct vendors would have missed it. Capability rather than origin: for each entry, write what it could do if it turned hostile today, and for scripts make the test concrete — can it reach the wallet-signing path at all? Containment: since SRI and CSP shrink the origin set and nothing else, the thing worth prototyping is isolation — moving the signing surface into an origin that third-party JavaScript cannot address, and treating "our own page may prompt for a signature" as itself a privilege to be scoped rather than an ambient property of the site. Then the same question turned inward: a private key that has been valid for six years has a blast radius measured in years, so rotation age belongs in the inventory next to the vendors, not in a separate ops checklist. One consumer-side corollary was parked here for want of anywhere better; it now has its own card. See pick-a-signer-not-a-brand, which turns audit history, signing scheme, entropy source and fulfilment handling into a selection procedure rather than a maxim. July's Coldcard defect is the inside-the-device version of the same lesson: a 2021 build-configuration error routed seed generation to a software PRNG instead of the STM32 hardware RNG, leaving roughly 40 bits of effective entropy on Mk2/Mk3 devices, and at least 1,719 BTC — about $111M across more than 5,200 addresses — was swept once someone noticed. ShipMonk is the who-shipped-the-device version, and the leaked list is worse than it looks precisely because no key was touched: a verified roster of hardware-wallet owners with delivery addresses is raw material for targeted phishing and for the physical coercion this space calls a wrench attack, and it appears in no threat model drawn around the device.

Where it lands in Jayverse

• Wallet: isolate the signing surface from third-party scripts. Test capability, not origin — no vendor script on jaylabs.xyz, even a whitelisted one, should be able to reach the wallet-signing path.
• Rabbit portal: inventory every third-party script and PII-holding vendor, one layer past direct vendors. ShipMonk's exposure arrived through Metabase; a list that stops at direct vendors on the portal would miss the same kind of second-layer risk.
• gitboard: add a key/vendor rotation-age row. Track relayer and admin key age next to the vendor inventory so a six-year-old key doesn't sit unnoticed the way the Polymarket top-up wallet's did.

← All Knowledge Notes · Workspace Index · Top ↑

Copy 한국어

신뢰된 서드파티 — 아무도 그리지 않는 폭발 반경

2026년 사고 네 건, 뿌리는 하나 — 내가 승인한 협력사. 그리고 가장 먼저 손이 가는 통제인 SRI·CSP는 그중 어느 것도 막지 못했을 것입니다.

아직 범위 미정 — 실제 프론트엔드 하나의 인벤토리부터: 모든 서드파티 스크립트, 고객 개인정보를 쥔 모든 협력사, 그리고 알아낼 수 있는 범위에서 그 협력사의 협력사까지. 출처: 폴리마켓 2026-05-22·2026-06-25 사고, Trezor/ShipMonk 공지 2026-08-13, Bits of Gold 공지 2026-08-16.

왜

넉 달에 네 건인데, 흥미로운 건 사고가 났다는 사실이 아니라 네 건이 공유하는 뿌리를 통상적인 위협 모델이 경계 바깥에 그린다는 점입니다. 2026-06-25, 침해된 서드파티 협력사가 폴리마켓 프론트엔드에 지갑 드레이너 스크립트를 주입해 최소 11개 지갑에서 약 294만 달러가 빠져나갔고, 탈취된 pUSD는 폴리곤에서 이더리움으로 브릿지돼 약 1,893 ETH로 합쳐졌습니다. 전액 보상은 이뤄졌지만 문제의 협력사 이름은 지금도 공개되지 않았습니다. 2026-08-13, Trezor는 물류 파트너 ShipMonk의 침해로 고객 13,689명(전체 노출 11,742명 — 이름·이메일·전화·배송지, 부분 노출 1,947명)이 드러났다고 공지했습니다. 대상은 7개국에서 2026-05-10~08-08 사이 주문한 고객이고, ShipMonk 쪽 원인은 Metabase의 취약점 — 협력사의 협력사입니다. 2026-08-16, 이스라엘 최초 VASP 라이선스 보유사 Bits of Gold가 서드파티 지원·분석 시스템 무단 접근으로 약 20만 명이 노출됐다고 공지했습니다. 그리고 2026-05-22에는 6년 된 개인키가 여전히 유효했다는 이유로 폴리마켓 내부 충전 지갑에서 30초마다 5,000 POL씩 70만 달러가 빠져나갔습니다. 프론트엔드 건에 대한 반사적 답은 "서드파티 스크립트를 SRI·CSP로 잠근다"이고, 바로 그 지점에서 반사가 빗나갑니다. SRI는 파일이 해시와 일치하는지 검증하는데, 악성 스크립트는 신뢰된 협력사 자신의 인프라에서 왔으므로 기대된 그 파일이 맞았습니다. CSP는 스크립트를 어디서 불러올 수 있는지의 화이트리스트인데, 그 협력사는 화이트리스트에 있었습니다. 둘 다 "이 스크립트는 승인되었는가?"에 답하고, 공격의 전제가 바로 승인되어 있었다는 것입니다. 만들 가치가 있는 질문은 두 통제 모두 묻지 않는 쪽입니다 — 승인된 이 스크립트가 무엇을 할 수 있게 되어 있는가?

동작 방식

만들 것은 인벤토리와 봉쇄 테스트이고 순서가 그대로입니다. 인벤토리: 실제 프론트엔드 하나를 대상으로 모든 서드파티 스크립트와 고객 개인정보를 쥔 모든 협력사를 적고, 알아낼 수 있는 한 한 겹 더 내려갑니다 — ShipMonk의 노출은 Metabase를 통해 왔고, 직접 협력사에서 멈춘 목록은 그것을 놓쳤을 것입니다. 출처가 아니라 권한: 각 항목에 대해 "오늘 적대적으로 돌아서면 무엇을 할 수 있는가"를 적고, 스크립트는 검사를 구체화합니다 — 지갑 서명 경로에 닿을 수 있는가? 봉쇄: SRI·CSP는 출처 집합만 줄이므로, 프로토타이핑할 가치가 있는 것은 격리입니다 — 서명 표면을 서드파티 JS가 주소 지정할 수 없는 오리진으로 옮기고, "우리 페이지가 서명을 요청할 수 있다"는 것 자체를 사이트의 기본 성질이 아니라 범위를 정해야 할 권한으로 다루는 것. 그다음 같은 질문을 안쪽으로 돌립니다: 6년간 유효했던 개인키의 폭발 반경은 연 단위로 측정되므로, 키 교체 연한은 별도 운영 체크리스트가 아니라 협력사 목록 옆 같은 인벤토리에 들어가야 합니다. 소비자 쪽 따름정리 하나가 마땅한 자리가 없어 여기 얹혀 있었는데, 이제 자기 카드가 생겼습니다 — pick-a-signer-not-a-brand 가 감사 이력·서명 방식·엔트로피 소스·물류 위탁을 격언이 아니라 선택 절차로 바꿉니다. 7월의 Coldcard 결함이 같은 교훈의 "기기 안" 판본입니다 — 2021년의 빌드 설정 오류가 시드 생성을 STM32 하드웨어 RNG 대신 소프트웨어 PRNG로 흘려보내 Mk2/Mk3에 유효 엔트로피 약 40비트만 남겼고, 누군가 알아챈 뒤 5,200개 넘는 주소에서 최소 1,719 BTC(약 1억 1,100만 달러)가 쓸려 나갔습니다. ShipMonk는 같은 교훈의 "기기를 배송한 사람" 판본이고, 유출된 목록이 겉보기보다 나쁜 이유는 키가 하나도 건드려지지 않았다는 바로 그 점 때문입니다: 배송지가 붙은 하드웨어 월렛 보유자 명부는 표적 피싱과 이 바닥이 렌치 공격이라 부르는 물리적 강압의 완벽한 원재료인데, 기기를 중심으로 그린 어떤 위협 모델에도 등장하지 않습니다.

Jayverse에서의 위치

• Wallet: 서명 표면을 서드파티 스크립트로부터 격리한다. 출처가 아니라 권한을 테스트한다 — jaylabs.xyz의 어떤 벤더 스크립트도, 화이트리스트에 있더라도 지갑 서명 경로에 닿을 수 없어야 한다.
• Rabbit 포털: 직접 벤더를 한 단계 넘어서 서드파티 스크립트와 PII 보유 벤더를 전수조사한다. ShipMonk의 유출은 Metabase를 통해 일어났다. 포털에서 직접 벤더까지만 확인하는 목록은 같은 종류의 2차 리스크를 놓친다.
• gitboard: 키/벤더 로테이션 연차를 행으로 추가한다. 벤더 인벤토리 옆에 릴레이어와 관리자 키의 연차를 추적해, Polymarket 충전 지갑의 6년 된 키처럼 묵혀지는 일을 막는다.

← 전체 기술 노트 · 워크스페이스 인덱스 · 맨 위 ↑