솔직히 말하면 저도 처음엔 "CSS가 공격 벡터?" 하고 웃었습니다. 우리가 매일 padding 1px 맞추느라 전전긍긍하는 그 CSS가요? 그런데 dev.to에 올라온 CVE-2026-2441 분석 글을 읽고 나서 웃음이 싹 사라졌습니다. Chrome의 Blink 엔진이 @font-feature-values 규칙을 파싱하는 과정에서 Use-After-Free 취약점이 발견됐고, CVSS 8.8—"단순히 페이지 방문만으로 원격 코드 실행"이 가능한 수준이었습니다. 사용자 입장에서는 아무 다운로드도, 아무 클릭도 하지 않았는데 CSS 한 줄이 메모리를 오염시키는 겁니다.
무슨 일이 벌어진 건가요
문제의 핵심은 이렇습니다. Chrome이 CSS의 폰트 피처 맵을 순회(iteration)하는 도중에 그 맵 자체가 삭제될 수 있었다는 거예요. C++ 코드에서 auto&로 라이브 구조체를 참조하며 루프를 돌리는데, 공격자가 스크립트나 이벤트를 통해 맵을 강제로 해제하고, 해제된 메모리에 악성 페이로드를 채워 넣으면—브라우저는 이미 사라진 메모리를 "아직 유효하다"고 믿고 실행합니다. Figma에서 디자인할 때는 폰트 styleset(retro) 같은 규칙이 그냥 예쁜 타이포그래피 옵션인데, 브라우저 내부에서는 C++로 파싱되는 실행 가능한 로직이라는 사실을 다시 한번 실감합니다.
Google의 수정은 의외로 단순했습니다. 원본 맵을 직접 순회하지 않고 std::move로 안전한 복사본을 만든 뒤 그 위에서 루프를 도는 방식이에요. 화려하진 않지만 효과적이죠. 사실 이건 프론트엔드 개발자에게도 익숙한 패턴입니다—React에서 상태 배열을 직접 mutate하지 않고 스프레드 연산자로 복사한 뒤 업데이트하는 것과 본질적으로 같은 원리니까요.
"CSS는 스타일일 뿐"이라는 착각
이 사건이 불편한 이유는, CSS를 "안전한 선언형 언어"로 취급해 온 우리의 멘탈 모델을 정면으로 부순다는 겁니다. 실제로 프론트엔드 보안 점검 목록에서 CSS 관련 항목을 본 적 있으신가요? 대부분 XSS, CSRF, 의존성 취약점 정도만 신경 쓰죠. 하지만 브라우저 입장에서 CSS는 HTML·JS와 동등하게 파싱·해석·실행되는 코드입니다.
이 지점에서 시멘틱 태그와 접근성 이야기가 자연스럽게 연결됩니다. velog의 시멘틱 태그 글에서 지적한 것처럼, div 수프로 도배된 마크업은 SEO나 스크린 리더만의 문제가 아닙니다. 구조가 불분명한 DOM은 CSP(Content Security Policy) 규칙 적용도 까다롭게 만들고, 인라인 스타일 주입 공격의 표면적을 넓힙니다. <header>, <main>, <article> 같은 시멘틱 구조가 잡혀 있으면 특정 영역에만 스타일 스코프를 한정하는 전략—이를테면 @layer나 CSS Modules—을 적용하기가 훨씬 수월합니다. 접근성과 보안은 사실 같은 뿌리에서 자라나는 셈이에요.
SCSS 전처리기, 편하지만 경계해야 할 것
SCSS 조건문·반복문 글에서 본 @for와 nth() 패턴을 생각해 봅시다. @for $i from 1 through 7 같은 반복문이 외부 입력(사용자 제공 테마 값, CMS에서 내려오는 변수 등)과 결합되면 어떻게 될까요? SCSS는 빌드 타임에 컴파일되니까 런타임 공격과는 다르다고 안심할 수 있지만, 빌드 파이프라인 자체가 오염되면 이야기가 달라집니다. 최근 공급망 공격(Supply Chain Attack) 트렌드를 감안하면, node_modules 안의 SCSS 의존성이 악성 @import를 끼워 넣는 시나리오는 충분히 현실적입니다. 번들 사이즈뿐 아니라 빌드 산출물의 무결성까지 체크해야 하는 시대인 거죠.
프론트엔드 보안 점검 체크리스트
이번 사건을 계기로 제가 팀 내부에 공유한 체크리스트를 정리합니다.
- 브라우저 버전 강제 업데이트 정책: Chrome 145.0.7632.75 이상, Chromium 기반 브라우저 포함. CI/CD의 Playwright·Cypress 러너 이미지도 확인하세요.
- CSP에
style-src명시적 제한:unsafe-inline제거, nonce 기반 스타일 허용으로 인라인 CSS 주입을 차단합니다. - 시멘틱 마크업 + 스타일 스코핑:
@layer, CSS Modules, Shadow DOM 등으로 스타일 영향 범위를 최소화합니다. - SCSS 의존성 감사:
npm audit외에 빌드 산출물 diff를 CI에서 자동 비교해 예상치 못한 CSS 변경을 잡아냅니다. - 서드파티 폰트·아이콘 서브리소스 무결성(SRI):
<link>태그에integrity해시를 적용합니다. - Lighthouse 보안 탭 + 접근성 탭 동시 점검: 보안과 a11y는 같은 맥락에서 리뷰해야 빈틈이 줄어듭니다.
전망: CSS도 Rust로 다시 쓰는 날이 올까
Mozilla는 이미 Stylo(Servo의 CSS 엔진)를 Rust로 재작성해 Firefox에 탑재했고, Google도 Chromium에 Rust를 점진적으로 도입 중입니다. 하지만 Blink의 CSS 파서 전체를 Rust로 포팅하려면 수백만 줄의 C++ 레거시를 넘어야 합니다. 그때까지 이런 Use-After-Free 류의 메모리 안전성 버그는 계속 나올 겁니다.
결국 우리가 할 수 있는 건 "CSS는 그냥 스타일"이라는 방심을 버리는 것입니다. Zustand로 전역 상태를 깔끔하게 관리하고, 디자인 토큰으로 일관성을 잡고, SCSS 조건문으로 반응형을 우아하게 처리하는 것—이 모든 "좋은 프론트엔드 관행"의 토대에 보안이 깔려 있어야 합니다. font-variant-alternates: styleset(retro) 한 줄이 원격 코드 실행 벡터가 되는 세상이니까요. 1px의 어긋남도 못 참는 우리라면, 보안의 어긋남은 더더욱 못 참아야 하지 않겠습니까.