'CSS 익스플로잇'의 진실 — 크롬 취약점이 남긴 교훈

선언형 언어라 "안전하다"고 여겨지던 CSS가 보안 뉴스의 주인공이 됐다. 크롬의 렌더링 엔진 Blink에서 CSS의 @font-feature-values 규칙 처리와 얽힌 Use After Free(UAF) 취약점, CVE-2026-2441이 공개된 것이다. CSS-Tricks의 Lee Meyer는 이 사건을 해부하며 'CSS 익스플로잇'이라는 자극적인 헤드라인과 실제 공격 구조 사이의 간극을 파고든다. 스타일시트 한 줄이 정말 브라우저를 뚫을 수 있는지, 프런트엔드 개발자가 무엇을 해야 하는지 정리했다.

"조작된 HTML 페이지를 통해 원격 공격자가 샌드박스 안에서 임의 코드를 실행할 수 있게 했다."CSS-Tricks (CVE-2026-2441 설명 인용)

무슨 일인가

크롬이 @font-feature-values 규칙을 파싱하면 내부적으로 CSSFontFeaturesValueMap이라는 객체가 만들어지는데, 이를 떠받치는 HashMap 자료구조의 메모리 관리에 결함이 있었다. 해제된 메모리를 다시 참조할 수 있게 된 틈을 악성 자바스크립트가 타입 혼동(type confusion)으로 악용하면, 브라우저 샌드박스 안에서 임의 코드 실행까지 이어진다. 즉 CSS는 취약점을 '여는 방아쇠'였고, 실제 공격을 수행한 것은 자바스크립트였다. 크롬 145.0.7632.75, 엣지 145.0.3800.58 이상으로 패치가 배포됐으니 크로미움 계열 브라우저는 즉시 업데이트하는 것이 답이다.

여러 시각

'CSS와 보안'이라는 오래된 질문에 이번 사건은 새로운 각도를 더한다.

• CSS-Tricks(Chris Coyier) — 일찍이 :visited 방문 기록 탐지, 속성 선택자 키로거 같은 순수 CSS 공격 벡터를 검토한 뒤 "CSS 자체는 특별히 위험한 보안 문제가 아니다"라고 정리했다. 언어로서의 CSS는 안전하다는 이 통념이, 이번엔 언어가 아니라 '엔진 구현'에서 깨질 수 있음이 드러난 셈이다.
• web.dev(How Browsers Work) — 브라우저 동작 원리 관점에서 보면 Blink·Gecko·WebKit 같은 렌더링 엔진은 CSS를 파싱해 내부 객체로 변환하는데, 바로 그 파싱 파이프라인이 공격 표면이 된다. 어떤 입력이든 파서를 거치는 순간 보안의 영역에 들어간다는 각도다.

왜 중요한가

이번 취약점의 본질은 CSS 문법이 아니라 C++ 기반 엔진의 메모리 안전성 문제다. 파이어폭스가 CSS 엔진을 Rust로 새로 쓰면서 이런 계열의 버그를 원천 차단한 것과 대비되며, 크로미움도 Rust 도입을 늘려가는 배경이 여기에 있다. 동시에 이 사건은 기술 커뮤니케이션의 문제이기도 하다. 'CSS 익스플로잇'이라는 헤드라인만 보면 스타일시트를 겁내게 되지만, 실제 실행 벡터는 자바스크립트였다. 원인과 방아쇠를 구분하지 못하면 엉뚱한 곳에 방어선을 치게 된다.

실무 적용

• 크로미움 기반 환경(브라우저는 물론 일렉트론·임베디드 웹뷰 포함)의 보안 패치 추적과 최소 버전 정책을 점검한다.
• 서드파티 CSS와 사용자 생성 스타일은 신뢰 경계 밖으로 두고, CSP와 외부 스타일시트 무결성 검증(SRI)을 기본으로 깐다.
• 보안 공지를 리포팅할 때 '트리거'와 '실행 벡터'를 구분해 기록한다 — QA에서 재현 조건과 근본 원인을 분리하는 습관과 같다.

Kenny의 관점

"CSS니까 안전하다"는 가정은 사실 언어에 대한 신뢰가 아니라 엔진 구현에 대한 신뢰였다는 걸 이번 사건이 보여준다. 프런트엔드 개발자가 엔진의 메모리 버그를 직접 고칠 수는 없지만, 패치 배포 속도와 웹뷰 업데이트 체계는 우리 손에 있는 방어선이다. 그리고 QA 관점에서 이 글의 진짜 교훈은 헤드라인 리터러시다 — 자극적인 제목 앞에서 공포가 아니라 '무엇이 방아쇠이고 무엇이 실행 벡터인가'를 묻는 침착함이, 팀의 대응 품질을 가른다.

출처

• CSS-Tricks: An Exploit … in CSS?! ↗
• CSS-Tricks: CSS Security Vulnerabilities ↗
• web.dev: How browsers work ↗