CVE-2025-66034, 폰트 빌드 파일이 임의의 쓰기 프리미티브가 되는 경우

CVE-2025-66034는 많은 팀이 처음 읽을 때 과소평가하는 종류의 취약점입니다. 영향을 받는 패키지는 다음과 같습니다. 글꼴 도구글꼴 작업을 위한 잘 알려진 Python 라이브러리입니다. 영향을 받는 코드 경로는 fontTools.varLib에서 가변 글꼴을 빌드하는 데 사용됩니다. .designspace 파일을 수정하세요. 버그는 애매한 데모 스크립트에 있는 것이 아닙니다. 이 버그는 업스트림, 배포 및 엔터프라이즈 공급업체 채널 전반에 걸쳐 실제 문서, 실제 다운스트림 패키징 및 실제 수정 노트와 함께 실제 빌드 흐름에 존재합니다. 공식 업스트림 권고에 따르면 취약한 버전은 다음과 같습니다. 4.33.0 다음을 포함하되 이에 국한되지 않습니다. 4.60.2 가 임의의 파일 쓰기로 속일 수 있으며, 이로 인해 악성 .designspace 파일이 처리됩니다. (GitHub)

이것이 중요한 이유는 추상적인 의미의 '글꼴'이 아니기 때문입니다. 최신 소프트웨어 시스템은 모든 것을 자동화하기 때문에 중요합니다. 빌드 작업자는 디자인 에셋을 컴파일합니다. SaaS 플랫폼은 사용자가 제공한 파일을 수집합니다. CI 작업은 리포지토리를 가져와 아티팩트를 생성합니다. 내부 도구는 디자인 파일이 스크립트, 템플릿 또는 아카이브보다 덜 위험하다고 가정하여 신뢰할 수 없는 업로드를 처리합니다. CVE-2025-66034는 이러한 가정을 깨뜨립니다. 이 취약점은 구조화된 디자인 아티팩트가 어떻게 파일 시스템 쓰기 프리미티브가 될 수 있는지, 그리고 잘못된 환경에서는 코드 실행 경로가 될 수 있는지 보여줍니다. (글꼴 도구 문서)

공개 검색의 관점에서 볼 때, 평판이 좋은 결과에서 가장 명확하고 반복되는 프레임은 기술적으로도 올바른 프레임입니다. 글꼴 도구 varLib 활성화하는 버그 임의 파일 쓰기이며, 일부 배포 조건에서는 쓰기가 원격 코드 실행. 이는 업스트림 GitHub 자문, GitLab의 자문 데이터베이스, NVD의 설명 및 이후 여러 보조 설명자가 사용하거나 반영한 프레임워크입니다. 이는 직접적이고 정확하며 모호한 문구 아래에 단서를 묻어두는 것보다 낫습니다. (GitHub)

CVE-2025-66034

AI 해커 도구 무료 체험 >>

CVE-2025-66034의 실제 내용

공식 설명은 주요 권위 있는 출처에서 일관되게 유지되고 있습니다. 취약한 버전의 글꼴 도구에서 글꼴 도구 varLib 명령을 호출하는 코드 또는 fontTools.varLib.main()를 처리할 때 악용될 수 있습니다. .designspace 파일. 이 결함은 비위생적인 파일 이름 처리에서 비롯됩니다. 이 권고에 따르면 공격자는 경로 탐색 시퀀스를 사용하여 임의의 파일 시스템 위치에 출력 파일을 쓸 수 있으며, 제어된 콘텐츠를 출력 파일에 삽입할 수도 있습니다. 이러한 조합을 통해 파일 쓰기에서 코드 실행까지의 경로가 생성됩니다. (GitHub)

Upstream의 권고문은 그 메커니즘에 대해 이례적으로 명확하게 설명합니다. 이 취약점은 "콘텐츠 삽입과 결합된 비위생적인 파일 이름 처리" 때문에 존재한다고 말합니다. 이 권고문은 다른 많은 권고문보다 더 나아가 글꼴 파일을 임의의 파일 시스템 위치에 쓰기, 구성 파일 덮어쓰기, 애플리케이션 파일 및 종속성 손상, 원격 코드 실행 등 가능한 결과를 명시적으로 나열하고 있습니다. 이러한 표현이 중요한 이유는 관리자가 이를 실질적인 영향 반경이 없는 무해한 경로 버그로 취급하고 있지 않다는 것을 알려주기 때문입니다. (GitHub)

패치는 그에 따라 작고 명확하게 드러납니다. 업스트림 커밋의 수정 사항은 가변 글꼴 파일명이 있을 때 다음과 같은 경우만 동작을 변경합니다. OS.경로.기본 이름(VF.파일 이름) 가 사용됩니다. 즉, 출력 경로가 조인되기 전에 디렉토리 구성 요소가 제거됩니다. 나중에 릴리스 노트에는 다음과 같이 쉬운 언어로 설명되어 있습니다. varLib.main. 이것은 익스플로잇 스토리와 패치 스토리가 거의 일대일로 일치하는 드문 경우 중 하나입니다. (GitHub)

또한 신뢰 경계 실패를 쉽게 설명할 수 있습니다. 취약한 흐름은 공격자의 영향을 받은 파일 이름을 마치 안전한 출력 이름인 것처럼 취급했습니다. 일단 해당 파일 이름에 트래버스 마커나 절대 경로 시맨틱이 허용되면, 출력 디렉터리는 더 이상 경계가 아닌 제안이 되었습니다. 이 시점에서 남은 유일한 질문은 대상 환경에 나중에 중요한 파일을 작성할 의미 있는 장소가 있는지 여부였습니다. 실제 환경에서는 대답은 '그렇다'인 경우가 많습니다. (GitHub)

디자인스페이스 파일이 장난감 입력이 아닌 이유

이 CVE는 다음과 같은 내용을 이해하면 더 어려워집니다. .designspace 가 실제로 작동합니다. 글꼴 도구 문서에서 설명하는 디자인스페이스 라이브러리 를 디자인스페이스 파일을 읽고, 쓰고, 편집하기 위한 구성 요소로 정의하고 이러한 파일이 축, 소스, 가변 글꼴, 인스턴스 및 관련 데이터를 정의한다고 설명합니다. 디자인스페이스의 varLib 문서에는 가변 글꼴 데이터를 처리, 구축 및 보간하기 위한 패키지로 설명되어 있습니다. 또한 문서에는 디자인스페이스 파일을 사용하여 가변 글꼴을 만드는 데 다음과 같이 사용할 수 있음을 명시적으로 보여줍니다. varLib. 이것은 이론적인 배관이 아닙니다. 프로덕션 워크플로우입니다. (글꼴 도구 문서)

이 문서에서는 파일 이름과 경로가 디자인스페이스 모델의 일부인 이유에 대해서도 설명합니다. 디자인스페이스 파일은 시스템과 리포지토리 간에 이동하기 때문에 디자인스페이스 파일은 다른 파일에 대한 참조를 상대 경로와 함께 저장합니다. 이는 지극히 합리적인 기능입니다. 문제는 파일에 경로가 포함되어 있다는 것이 아닙니다. 문제는 출력 측에서 잘못된 경로 시맨틱을 신뢰했다는 것입니다. 공격자가 생성된 출력의 위치에 영향을 미칠 수 있는 순간, 데이터 설명 파일은 구성이 아니라 쓰기 명령어처럼 보이기 시작합니다. (글꼴 도구 문서)

이것은 많은 엔지니어가 놓치고 있는 광범위한 교훈입니다. 성숙한 자동화에서 데이터 형식은 수동적이지 않습니다. 이름, 경로, 대상, 참조, 템플릿, 규칙, 지시문 및 직렬화 동작을 포함하는 경우가 많습니다. 파이프라인에서 이러한 형식을 읽고, 해결하고, 아티팩트를 방출하는 경우, 의도했든 의도하지 않았든 해당 형식은 제어 경계에 놓이게 됩니다. CVE-2025-66034는 실제로 그 경계가 잘못 분류된 것에 대한 이야기입니다. (글꼴 도구 문서)

AI 해커 도구 무료 받기 >>

단순화된 코드 경로의 취약점

업스트림 어드바이저리에는 필수 취약 라인이 포함됩니다. 개념적인 측면에서는 이전 논리가 이를 수행했습니다:

# 단순화, 개념
파일명 = 공격자_제어된_파일명
output_path = os.path.join(output_dir, filename)
저장(출력_경로)

고정 로직은 이 작업을 대신 효과적으로 수행합니다:

# 단순화, 개념
파일명 = os.path.basename(공격자_제어_파일명)
출력_경로 = os.path.join(output_dir, filename)
저장(출력_경로)

그 차이는 기억하기 전까지는 사소해 보입니다. ../중첩된 상대 경로 또는 절대 스타일 경로 콘텐츠는 자동화 내부에서 수행할 수 있습니다. 한 번의 기본 이름 정규화 단계만으로도 파일 시스템 이스케이프를 정상적인 아티팩트 쓰기로 되돌릴 수 있습니다. 이것이 바로 이 수정이 매우 작고 중요한 이유입니다. (GitHub)

업스트림 권고문은 또한 콘텐츠 삽입이 위험 상황의 일부라고 지적합니다. 이는 단순히 "어딘가에 파일을 쓰는 것"만이 아닙니다. 공격자는 작성되는 내용에도 영향을 미칠 수 있습니다. 따라서 특정 배포에서는 의미 있는 위치에 대한 제어된 쓰기와 제어된 콘텐츠가 일반적인 손상 전용 버그보다 훨씬 더 위험한 원시적인 결과를 초래할 수 있습니다. (GitHub)

점수 분쟁은 숫자보다 더 중요합니다.

CVE-2025-66034의 가장 흥미로운 부분 중 하나는 공개 소스에서 심각도에 대한 의견이 일치하지 않는다는 것입니다. 현재 NVD 페이지에는 NVD에서 할당된 CVSS 3.1 점수가 다음과 같이 표시되어 있습니다. 9.8 크리티컬 벡터 AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H의 CNA 항목은 다음과 같습니다. 6.3 중간 벡터 AV:L/AC:H/PR:N/UI:R/S:C/C:N/I:H/A:L. 이 둘은 가깝지 않습니다. 이는 익스플로잇 가능성과 환경에 대한 매우 다른 가정을 나타냅니다. (NVD)

이러한 의견 불일치는 단순한 사무적 호기심이 아닙니다. 운영상 중요한 문제입니다. GitHub의 채점은 이 문제를 로컬 도구 체인 경로의 사용자 지원, 워크플로 의존적 남용처럼 취급합니다. NVD의 강화는 네트워크에 도달할 수 있고 마찰이 적은 RCE처럼 취급합니다. 두 숫자 모두 대시보드에 맹목적으로 복사하여 "진실"이라고 불러서는 안 됩니다. 진짜 문제는 환경이 신뢰할 수 없는 디자인스페이스 입력을 자동화된 방식으로 처리하는지 여부와 출력 경로가 실행 가능, 배포 가능, 웹 서비스 또는 보안에 민감한 항목과 교차하는지 여부입니다. 일부 환경에서는 GitHub의 낮은 점수가 실질적인 위험을 더 잘 설명할 수 있습니다. 다른 환경에서는 NVD의 더 엄격한 관점이 현실에 더 가까울 수도 있습니다. (NVD)

우분투의 보안 공지가 유용한 이유는 구체적인 운영 언어로 위험을 표현하고 있기 때문입니다. 사용자나 자동화된 시스템이 속아서 특수하게 만들어진 악성 코드를 추출하는 경우 .designspace 파일을 사용하면 공격자가 대상 디렉터리 외부에 임의의 파일을 작성하여 원격 코드 실행을 초래할 수 있습니다. 이 표현은 버그가 실제 존재하고, 영향을 미치는 경로가 실제 존재하며, 배포 컨텍스트에 따라 파일 쓰기에서 RCE로 넘어가는 것이 얼마나 쉬운지가 결정된다는 성숙한 중간 지점을 포착하고 있습니다. (우분투)

이것이 바로 숙련된 보안 팀이 이러한 CVE를 읽는 방법입니다. 심각도는 식별자만의 속성이 아닙니다. 심각도는 원시적인 요소, 트리거 경로, 주변 자동화, 공격자가 제어하는 바이트가 최종적으로 착륙하는 위치의 산물입니다. 최고의 방어 프로그램은 "이것이 중요한가?"만 묻지 않습니다. "이것이 실제 파이프라인에서 신뢰 경계를 넘을 수 있는가?"라고 묻습니다. CVE-2025-66034는 두 번째 질문이 더 중요한 이유를 보여주는 강력한 예입니다. (NVD)

프로덕션에서 이 버그가 실제로 발생하는 경우

실제로 노출되는 경로에는 몇 가지 그럴듯한 경로가 있습니다. 첫 번째는 사용자가 제공한 정보를 받아들이는 모든 서비스나 작업입니다. .designspace 파일에 저장하고 글꼴 도구 varLib 또는 fontTools.varLib.main(). 두 번째는 리포지토리 기반 자동화로, 풀 리퀘스트, 패키지 가져오기, 동기화된 에셋 번들 또는 디자인 핸드오프가 신뢰할 수 있는 빌드 워커가 나중에 컴파일하는 악성 파일을 도입하는 경우입니다. 세 번째는 간접 종속성 사용으로, 더 큰 플랫폼에서는 다음을 포함합니다. 글꼴 도구 가 런타임 어딘가에 존재하고, 보안팀은 게시글이 올라올 때까지 글꼴 처리 경로가 존재한다는 사실을 깨닫지 못합니다. 공식 문서와 다운스트림 공급업체의 공지를 보면 이러한 시나리오가 억지스러운 추상화가 아님을 알 수 있습니다. (글꼴 도구 문서)

IBM 게시판은 다운스트림에 대한 영향력을 보여주기 때문에 특히 유용합니다. IBM의 Maximo 애플리케이션 스위트 시각적 검사 구성 요소 게시판에 따르면 이 구성 요소는 다음과 같이 명시되어 있습니다. 글꼴 도구 종속성이 CVE-2025-66034에 취약하고 버전이 식별됩니다. 9.1.10 영향을 받는 릴리스에 대한 수정된 릴리스로 9.1.x 버전을 지원합니다. IBM의 왓슨 음성 서비스 카트리지 게시판은 다음과 같이 말합니다. 글꼴 도구 는 서비스 런타임에도 사용되어 버전에 영향을 미칩니다. 4.0.0 통해 5.3.0의 수정 사항과 함께 5.3.1. 이러한 종류의 의존성 체인 예시는 방어자가 주의해야 합니다. (IBM)

배포 패키징도 비슷한 이야기를 들려줍니다. Debian의 소스 패키지 추적기에 따르면 최신 제품군에서는 이 문제가 해결된 것으로 표시되지만, 이전 제품군은 일부 트랙에서 DSA가 없으면 취약한 상태로 남아 있습니다. 우분투의 USN-7917-1에는 수정 사항이 발표되었으며 특히 CVE-2025-66034가 우분투에 영향을 미친다고 명시되어 있습니다. 24.04 LTS, 25.04및 25.10를 수정하기 위해 해당 패키지 버전을 게시했습니다. 이는 단순히 PyPI 위생 문제가 아니라는 뜻입니다. 팀들은 또한 OS 패키지 사본을 인벤토리화해야 합니다. (security-tracker.debian.org)

실질적인 요점은 간단합니다. "노출되었습니까?"라는 질문에 다음과 같은 항목만 체크해서는 대답할 수 없습니다. 요구 사항.txt. 기본 이미지, 배포 패키지, 서비스 런타임, 공급업체 제품 및 다음을 호출하는 모든 내부 도구를 살펴봐야 합니다. varLib 직접. 조직에서 디자인 자동화, 문서 변환, 브랜드 자산 처리 또는 글꼴 패키징을 다루는 경우 해당 인벤토리 작업은 선택 사항이 아닙니다. (security-tracker.debian.org)

CVE-2025-66034

AI 해커 도구 무료 체험 >>

보안 팀이 사용할 수 있는 간단한 사실

아래 표에는 업스트림 권고, NVD, 릴리스 노트, 배포 공지 및 다운스트림 공급업체 게시판에서 가장 유용한 정보가 요약되어 있습니다. (GitHub)

항목	중요한 사항
취약한 구성 요소	`fontTools.varLib`특히 `main()` 코드 경로
트리거	악성 `.designspace` 파일
영향을 받는 버전	`>= 4.33.0` 그리고 `< 4.60.2`
업스트림 버전 수정	`4.60.2`
보안 변경	공격자의 영향을 받은 파일 이름 값의 기본 이름만 사용하세요.
업스트림 이슈 프레임워크	임의 파일 쓰기와 콘텐츠 삽입으로 인해 잠재적으로 RCE가 발생할 수 있습니다.
NVD CVSS	`9.8 크리티컬`
GitHub CNA CVSS	`6.3 중간`
우분투 노트	영향을 받는 `24.04 LTS`, `25.04`, `25.10`고정 패키지 버전 게시
데비안 노트	최신 제품군에서는 수정되었으며, 이전 제품군은 트래커 상태에서 취약한 상태로 유지됩니다.
다운스트림 예시	IBM 맥시모 시각 검사, IBM 왓슨 음성 서비스 카트리지

일부 환경에서 파일 쓰기가 RCE가 되는 이유

모든 임의 파일 쓰기가 즉시 RCE가 되는 것은 아닙니다. 이는 분명히 말할 가치가 있습니다. 하지만 방어자들은 "항상 RCE는 아니다"라는 말을 "대부분 무해하다"고 지나치게 확대해석해서는 안 됩니다. 자동화된 환경에서 쓰기 프리미티브는 실행 가능한 곳, 가져온 곳, 제공되는 곳, 체인의 다음 단계가 신뢰하는 곳 등 네 곳 중 한 곳에 출력될 수 있을 때마다 매우 위험해집니다. 여기에는 애플리케이션 코드 디렉터리, Python 모듈 경로, 플러그인 폴더, 템플릿 디렉터리, 빌드 컨텍스트, 배포 번들, 콘텐츠 유형을 실행 동작에 매핑하는 웹 액세스 가능 위치가 포함됩니다. 구성 덮어쓰기와 악성 코드 인젝션에 대한 업스트림 권고의 언급이 여기서 중요한 단서입니다. (GitHub)

더 미묘한 점도 있습니다. 쓰기 작업이 코드 실행으로 이어지지 않더라도 높은 신뢰도의 무결성 인시던트가 될 수 있습니다. 종속성을 손상시키거나, 향후 빌드를 오염시키거나, 애플리케이션 자산을 변경하거나, 나중에 동작을 변경하는 방식으로 구성을 수정하는 것만으로도 보안에 큰 영향을 미칠 수 있습니다. 많은 팀이 '즉각적인 셸' 결과만을 과대평가하고 지속적인 아티팩트 중독을 과소평가합니다. CI/CD 및 빌드 시스템에서 포이즌된 결과물을 통한 지속성은 그만큼 위험할 수 있습니다. (GitHub)

그렇기 때문에 NVD와 GitHub의 점수 분할이 엔지니어링 문제에서 벗어나지 않아야 합니다. 글꼴 처리 워커가 실행 경로, 민감한 마운트, 프로덕션으로의 경로가 없는 격리된 스크래치 디렉터리에만 쓰는 경우, 폭발 반경이 더 낮습니다. 동일한 작업자가 광범위한 파일 시스템 액세스 권한으로 실행되거나 패키징, 배포 또는 웹 계층과 상태를 공유한다면 위험 상황은 즉시 달라집니다. 이는 이론이 아닙니다. 이것이 바로 최신 소프트웨어 공급망이 구축되는 방식입니다. (NVD)

타임라인 및 해결 방법, 소식통의 말

GitHub 권고문은 2025년 11월 28일에 게시되었습니다. NVD 기록에는 같은 날짜에 게시된 후 자체 CVSS 해석을 추가한 NVD 분석이 나와 있습니다. 업스트림 릴리스 노트는 다음을 보여줍니다. 4.61.0 2025년 11월 28일에 다음과 같은 명시적인 메모를 남겼습니다. varLib.main 는 이제 경로 통과 공격을 방지하기 위해 기본 이름만 사용하며, 이는 CVE-2025-66034를 수정합니다. 그런 다음 백포트 릴리스를 표시합니다, 4.60.2의 광범위한 지원 변경을 다운스트림 파이썬 3.9 사용자에게 강요하지 않고 보안 수정 사항을 적용하기 위해 특별히 2025년 12월 9일에 4.61.0. 이는 잘 처리된 릴리스 응답입니다. (GitHub)

우분투는 2025년 12월 9일에 CVE-2025-66034를 이전 버전과 함께 묶어 공개 공지를 했습니다. 글꼴 도구 XXE 버그, CVE-2023-45139. 이 페어링은 팀에게 이번이 처음이 아니라는 점을 상기시켜 주기 때문에 유용합니다. 글꼴 도구 는 보안 관련 방식으로 입력-신뢰 경계를 넘었습니다. Debian의 트래커는 나중에 여러 제품군에 걸쳐 혼합된 상태를 반영하며, 이는 "업스트림 패치"가 "모든 곳에 패치"를 의미한다고 가정하지 않고 패키지 출처를 인벤토리화해야 할 필요성을 다시 한 번 강조합니다. (우분투)

2026년 초까지 다운스트림 엔터프라이즈 공급업체는 취약한 종속성이 포함된 영향을 받는 제품에 대한 공지를 계속 게시하고 있었습니다. IBM의 2026년 3월 Maximo Visual Inspection에 대한 공지와 2026년 2월 Watson Speech Services에 대한 공지가 그 예입니다. 이러한 지연은 실제 에코시스템에서 흔히 볼 수 있는 현상입니다. 또한 대규모 제품 스택과 컨테이너 이미지가 관련된 경우 "몇 달 전에 직접 종속성을 업그레이드했다"는 것만으로는 안심할 수 없는 이유를 설명해 줍니다. (IBM)

CVE-2025-66034

AI 해커 도구 무료 받기 >>

자체 코드베이스에서 찾아야 할 사항

가장 먼저 확인해야 할 것은 조직에서 다음과 같은 기능을 사용하는지 여부입니다. 글꼴 도구 전혀 사용하지 않습니다. 두 번째는 varLib그리고 세 번째는 신뢰할 수 없거나 반신뢰된 .designspace 파일이 해당 경로에 도달할 수 있습니다. 팀들은 종종 첫 번째 질문에서 멈추고 진짜 문제를 놓치는 경우가 많습니다. 한 모드에서 사용되는 안전한 종속성이 다른 모드에서는 안전하지 않을 수 있습니다. 이 CVE는 흐름에 따라 다릅니다. 종속성 인벤토리와 사용 인벤토리가 모두 필요합니다. (GitHub)

당연한 정적 검사부터 시작하세요. 검색 fontTools.varLib, varLib.main, python3 -m fontTools.varLib및 글꼴 도구 varLib 리포지토리, 빌드 스크립트, Docker파일, CI 정의 및 내부 도구 전반에서 사용할 수 있습니다. 다음 항목도 검색하세요. .designspace 아티팩트 파이프라인을 공급하는 리포지토리에 있는 파일을 찾습니다. 목표는 패키지를 찾는 것만이 아닙니다. 파일이 동작이 되는 신뢰 경계를 찾는 것입니다. 바로 이 취약점이 존재하는 곳입니다. (GitHub)

간단한 셸 감사를 통해 의외로 많은 것을 얻을 수 있습니다:

rg -n "fontTools\\.varLib|varLib\\.main|fonttools varLib|python3 -m fontTools\\.varLib" .
find . -유형 f -이름 "*.designspace"
파이썬 - <<'PY'
importlib.metadata를 m으로 가져옵니다.
try:
    print("fonttools version:", m.version("fonttools"))
예외를 제외하고
    print("fonttools가 이 환경에 설치되지 않았습니다")
PY

컨테이너화된 워크로드를 실행하는 경우 호스트뿐만 아니라 이미지와 기본 이미지 내부에서도 동일한 로직을 반복하세요. 많은 팀이 기본 앱 종속성이 정리된 지 한참 후에 유틸리티 컨테이너, 작업자 이미지 또는 노트북 환경에서 취약한 복사본을 발견합니다. 다음과 같은 라이브러리에서 특히 그렇습니다. 글꼴 도구 핵심 애플리케이션 코드가 아닌 디자인, 시각화, ML 또는 보고 툴체인을 통해 환경에 진입합니다. (security-tracker.debian.org)

의심스러운 디자인스페이스 입력에 대한 방어적 구문 분석기 검사

즉시 패치를 할 수 없는 경우에도 즉시 노출을 줄여야 합니다. 간단한 제어 방법 중 하나는 .designspace 파일 이름 관련 필드에 디렉토리 구분 기호, 트래버스 마커 또는 명백히 안전하지 않은 출력 이름이 포함된 경우 입력합니다. 그렇다고 패치를 대체할 수는 없습니다. 인벤토리를 조사하고 수정하는 동안 시간을 벌고 가장 명백한 악용 경로를 줄일 수 있습니다. 업스트림 수정 자체는 기본적으로 코드 수준에서 이 원칙을 적용하고 있습니다. (GitHub)

다음과 같은 작은 파이썬 게이트가 CI 또는 인테이크 서비스에 도움이 될 수 있습니다:

pathlib에서 PurePosixPath, PureWindowsPath를 가져옵니다.
xml.etree.ElementTree를 ET로 가져옵니다.

def is_unsafe_filename(value: str) -> bool:
    값이 아닌 경우
        반환 False
    bad_markers = ["...", "/", "\\\\", "\\x00"]
    if any(bad_markers의 값에 m이 있으면):
        return True
    #는 절대형 이름도 거부합니다.
    if PurePosixPath(value).is_absolute():
        True를 반환합니다.
    PureWindowsPath(value).is_absolute():
        반환 True
    반환 False

def validate_designspace(경로: str) -> list[str]:
    tree = ET.parse(path)
    root = tree.getroot()
    findings = []
    for elem in root.iter():
        for attr in ("파일 이름", "경로"):
            val = elem.attrib.get(attr)
            if val 및 is_unsafe_filename(val):
                findings.append(f"unsafe {attr}={val!r} in ")
    결과 반환

# 사용
issues = validate_designspace("candidate.designspace")
이슈가 있으면
    raise SystemExit("거부된 디자인스페이스:\\n" + "\\n".join(issues))

이는 의도적으로 보수적인 기준입니다. 일부 합법적인 워크플로우에서는 문서 내에서 상대적인 소스 참조를 허용해야 할 수도 있습니다. 그러나 출력 이름 지정과 생성된 아티팩트 배치에 영향을 미치는 모든 경로의 경우 엄격한 유효성 검사를 수행하는 것이 올바른 자세입니다. CVE-2025-66034의 핵심 교훈은 파일 시스템 의도를 사용하기 전에 정규화해야 하며, 주변 파일 형식이 "데이터처럼 보인다고 해서" 신뢰해서는 안 된다는 것입니다. (글꼴 도구 문서)

모니터링 및 탐지, 방어자가 실제로 계측해야 할 사항

가장 쉽게 모니터링할 수 있는 것은 CVE의 존재 여부가 아니라 익스플로잇으로 인해 발생하는 동작입니다. 감시 대상 글꼴 도구 varLib 또는 python3 -m fontTools.varLib 프로세스가 승인된 빌드 출력 디렉터리 외부에 작성하는 것을 방지합니다. 애플리케이션 디렉터리에서 새로 생성된 글꼴과 유사하거나 예기치 않은 파일이 있는지 확인합니다, 사이트 패키지, 배포 작업 공간 또는 글꼴 처리 작업 중 웹 서비스 위치로 이동합니다. 주의 사항 .designspace 트래버스 마커가 포함된 입력 또는 의심스러운 확장자를 가진 출력 이름. 완벽한 지표는 아니지만 실용적인 지표입니다. (GitHub)

파일 무결성 모니터링이 있는 경우 일반 알림 대신 타겟팅된 정책을 사용하는 것이 좋습니다. A varLib 프로세스는 매우 지루한 쓰기 프로필을 가져야 합니다. 알려진 출력 루트에서만 아티팩트를 생성해야 합니다. 그 루트 밖의 모든 것은 기본적으로 의심스러운 것입니다. 이런 종류의 좁은 동작 기대치는 CVE ID가 언급된 서명을 기다리는 것보다 훨씬 더 유용합니다. (GitHub)

간단한 Linux 감사 규칙 세트는 작업자를 조사하거나 일시적으로 강화할 때 도움이 될 수 있습니다:

# /srv/font-build/out을 승인된 출력 루트로 바꿉니다.
auditctl -w /srv/font-build/out -p wa -k fontbuild_out
auditctl -a always,exit -F arch=b64 -S openat,creat,rename,unlink,unlinkat \\
  -F exe=/usr/bin/python3 -k py_file_ops

애플리케이션 측에서는 모든 애플리케이션의 소스를 기록합니다. .designspace 파일, 확인된 출력 디렉터리, 정규화 후 최종 아티팩트 이름, 사용된 정확한 라이브러리 버전 등을 확인합니다. 좋은 사고 대응은 어떤 작업자가 속았을지 추측하는 것이 아니라 빌드 체인을 재구성하는 것에서 시작됩니다. 이번 버그와 같이 "어떤 인터넷에 연결된 엔드포인트가 튀어나왔나?"가 아니라 "어떤 신뢰할 수 있는 자동화가 파일을 처리했나?"가 흥미로운 질문인 경우에는 두 배로 중요합니다(GitHub)

먼저 패치하되 올바르게 패치하기

깔끔한 업스트림 해답은 다음과 같이 업그레이드하는 것입니다. 폰트 도구 4.60.2 또는 그 이후 버전입니다. 이것이 자문, NVD 및 GitLab에서 명명한 고정 버전입니다. 다음을 수행할 수 있는 브랜치에 있는 경우 4.61.0 또는 그 이후 버전에서 호환성 문제 없이 보안 변경을 수행할 수 있습니다. 중요한 점은 일반적인 호환성 변경에 그치지 않고 pip 설치 -U 를 클릭하고 완료되었다고 가정합니다. 디자인스페이스 입력을 처리하는 각 위치에서 실행 중인 정확한 버전을 확인해야 합니다. (GitHub)

직접 파이썬 환경을 수정하는 방법은 간단합니다:

python -m pip install --upgrade "fonttools>=4.60.2"
파이썬 - <<'PY'
importlib.metadata를 m으로 가져옵니다.
print(m.version("fonttools"))
PY

OS 패키지 환경은 별도의 처리가 필요합니다. 우분투는 USN-7917-1에 영향을 받는 릴리스에 대한 고정 패키지 버전을 게시했습니다. Debian의 트래커는 제품군별로 혼합된 상태를 보여줍니다. 공급업체 어플라이언스 및 상용 소프트웨어 스택은 패키지 관리자 조치가 아닌 제품별 업데이트가 필요할 수 있습니다(IBM 게시판에서 명확히 알 수 있듯이). 이것이 바로 종속성 수정이 출처를 인식해야 하는 이유입니다. PyPI, apt, 컨테이너 및 제품 번들은 서로 다른 속도로 이동합니다. (우분투)

CVE-2025-66034

AI 해커 도구 무료 체험 >>

오늘 패치를 할 수 없는 경우

일부 팀은 공급업체 호환성, 고정된 이미지, 변경 창 또는 제품 지원 경계에 의해 고정될 수 있습니다. 이러한 상황에서도 여전히 유용한 제어 기능이 있습니다. 가능한 최소한의 파일 시스템 권한으로 글꼴 처리 워크로드를 실행하세요. 전용 출력 디렉터리를 마운트합니다. 쓰기 가능한 애플리케이션 또는 패키지 경로를 워커와 공유하지 마세요. 신뢰할 수 없는 모든 파일을 거부하거나 격리합니다. .designspace 입력. 빌드 스크래치 공간과 배포 아티팩트를 분리하세요. 업스트림 수정은 보안상의 이유로 경로 구성 요소를 제거하므로 임시 완화 조치는 운영상 동일한 경계를 적용해야 합니다. (GitHub)

컨테이너 격리는 익스플로잇 경로가 파일 쓰기가 가능한 위치에 따라 달라지기 때문에 특히 효과적입니다. 워커의 쓰기 가능한 뷰가 좁고 일회용인 경우 프리미티브는 그 가치를 많이 잃게 됩니다. 읽기 전용 루트 파일시스템과 시크릿, 배포 매니페스트, 코드 경로가 없는 명시적으로 마운트된 쓰기 가능한 스크래치 디렉터리 하나가 있는 것이 좋은 임시 상태입니다. 다시 말해, "임의 파일 쓰기"는 "막다른 스크래치 볼륨에 쓸모없는 파일을 쓰는 것"을 의미하도록 하세요. (우분투)

varLib의 보안 래퍼 패턴

팀에 필요한 경우 varLib를 사용하는 경우 가장 안전한 패턴은 임의의 입력에서 직접 호출하는 대신 명시적 경계 검사로 래핑하는 것입니다. 래퍼는 설치된 버전을 확인하고, 들어오는 입력의 유효성을 검사해야 합니다. .designspace를 제한된 작업 디렉토리 내에서 실행하고 정규화 후 생성된 모든 출력 이름을 기록합니다. 이렇게 하면 위험한 로우레벨 호출이 감사 가능한 작업으로 바뀝니다. 공식 수정 사항에서는 최종 출력 이름에 공격자가 제어하는 입력의 디렉터리 의도가 포함되어서는 안 된다는 불변의 원칙을 알려줍니다. (GitHub)

래퍼 스켈레톤은 다음과 같이 보일 수 있습니다:

pathlib에서 Path를 가져옵니다.
importlib.metadata를 m으로 가져옵니다.
서브프로세스 가져오기
임시 파일 가져오기
import shutil

min_safe = (4, 60, 2)

def parse_version(v: str):
    반환 튜플(int(x) for x in v.split(".")[:3])

def ensure_safe_fonttools():
    version = m.version("fonttools")
    if parse_version(version) < MIN_SAFE:
        raise RuntimeError(f"안전하지 않은 폰트 도구 버전: {version}")

def build_varfont(designspace: str, outdir: str):
    ensure_safe_fonttools()
    findings = validate_designspace(designspace)
    if findings:
        raise RuntimeError("거부된 디자인스페이스:\\n" + "\\n".join(findings))

    work = tempfile.mkdtemp(접두사="varlib-")
    try:
        safe_out = Path(outdir).resolve()
        safe_out.mkdir(parents=True, exist_ok=True)
        subprocess.run(
            ["python3", "-m", "fontTools.varLib", designspace, "--output-dir", str(safe_out)],
            cwd=work,
            check=True,
        )
    마지막으로
        shutil.rmtree(work, ignore_errors=True)

이렇게 한다고 해서 빌드 체인의 모든 위험이 마술처럼 사라지는 것은 아니지만 올바른 습관을 기를 수 있습니다. 버전 확인. 입력 유효성을 검사합니다. 작업 디렉터리를 좁히세요. 출력을 최신 상태로 유지하세요. 디자인 아티팩트는 달리 입증되지 않는 한 신뢰할 수 없는 것으로 취급하세요. CVE-2025-66034는 이러한 단계를 건너뛰는 팀에게 불이익을 주는 버그입니다. (GitHub)

같은 교훈을 더 크게 만드는 관련 CVE

가장 관련성이 높은 형제 자매는 CVE-2023-45139, 또 다른 글꼴 도구 결함을 발견했습니다. NVD와 GitHub의 권고에 따르면 공격자가 SVG 테이블로 후보 글꼴을 구문 분석할 때 임의의 엔티티를 확인하여 로컬 파일 포함 또는 서버 측 웹 요청을 가능하게 하는 하위 집합 모듈의 XXE 문제라고 설명합니다. 이 문제는 다음 버전에서 수정되었습니다. 4.43.0. 여기서 중요한 것은 버그가 동일하다는 것이 아닙니다. 두 인시던트 모두 글꼴 도구 파일 및 파서 신뢰 경계를 넘나들며 작동하는 경우, 많은 팀이 CVE로 인해 문제가 발생하기 전에는 보안이 중요한 것으로 분류하지 않았을 것입니다. (NVD)

더 광범위한 관련 패턴은 CVE-2025-4517여기서 NVD는 신뢰할 수 없는 타르 아카이브를 추출할 때 추출 디렉터리 외부에서 임의의 파일 시스템 쓰기를 설명합니다. 타르파일 필터 설정을 사용할 수 있습니다. 이는 다른 구성 요소와 다른 형식이지만 보안 교훈은 익숙합니다. 전송 데이터가 경로 의미를 자동화된 워크플로로 몰래 가져오는 것처럼 보이는 형식이 갑자기 편리한 API가 파일 시스템 경계 문제가 되는 것입니다. (NVD)

동일한 아이디어가 CVE-2026-32060의 경로 탐색 결함을 설명합니다. apply_patch 샌드박스 봉쇄가 없는 경우 구성된 작업 공간 디렉터리 외부에서 파일 쓰기 또는 삭제를 허용합니다. 다른 에코시스템, 동일한 엔지니어링 진실: 자동화 표면이 파일 이름이나 경로에 영향을 미칠 수 있다면 이는 단순한 기능 표면이 아니라 공격 표면의 일부입니다. (NVD)

이들을 하나로 묶는 것은 공급업체, 언어, 제품 카테고리가 아닙니다. "입력 데이터"와 "파일 시스템에 대한 명령어" 사이의 경계가 침식되는 것입니다. 신뢰할 수 있는 자동화 시스템 내부에서 이러한 침식이 발생하면 올바른 심각도 질문은 "익스플로잇이 얼마나 정교한가?"가 아닙니다. "구조화된 파일에 실수로 어떤 권한을 부여했나?"입니다. 이것이 바로 CVE-2025-66034에 대해서도 올바른 렌즈입니다. (NVD)

CVE-2025-66034

AI 해커 도구 무료 체험 >>

레드 팀원과 버그 현상금 사냥꾼이 주의해야 할 사항

공격적인 성향의 독자들에게 CVE-2025-66034의 흥미로운 부분은 원시적인 것뿐만 아니라 배포 추적에 있습니다. 가장 좋은 표적은 일반적인 개발자 노트북이 아닙니다. 타사 디자인 또는 에셋 파일을 자동으로 처리한 다음 나머지 스택이 신뢰하는 위치로 출력을 이동하는 시스템입니다. 관리되는 글꼴 서비스, 디자인 자산을 위한 CI 파이프라인, 내부 브랜딩 생성기, 콘텐츠 플랫폼 또는 다음을 포함하는 ML/보고 파이프라인이 여기에 해당할 수 있습니다. 글꼴 도구 간접적으로. 취약점 자체는 업스트림에서 문서화되어 있으며, 실제 작업은 취약점 주변의 신뢰 체인을 식별하는 것입니다. (GitHub)

버그 바운티를 염두에 두고 이 글을 읽는 방어자라면 우선순위를 정하는 것도 올바른 방법입니다. 어떤 서비스가 사용자가 제어하는 디자인 또는 글꼴 관련 입력을 변환하는지 물어보세요. 어떤 리포지토리가 계약자, 고객 또는 외부 협력자의 디자인 자산을 허용하는지 물어보세요. "파일만 생성하기 때문에" 광범위한 쓰기 권한을 가진 백그라운드 작업자가 있는지 물어보세요. 이러한 시스템이 바로 이와 같은 CVE가 라이브러리 위생 문제를 넘어 환경 문제가 되는 시스템입니다. (글꼴 도구 문서)

이미 지속적인 검증을 수행하는 팀에게 Penligent와 같은 플랫폼은 "AI가 CVE를 해결한다"는 마술 같은 주장이 아니라 CVE-2025-66034가 강제하는 질문을 운영하기 위한 방법으로 자연스럽게 자리 잡을 것입니다. Penligent는 AI 기반 침투 테스트 플랫폼으로 자신을 소개하지만, 여기서 더 적절한 운영 용도는 대상 환경이 신뢰할 수 없는 아티팩트를 처리하는지 식별하고, 생성된 파일이 어디에 있는지 추적하고, 신뢰 경계 가정이 실제로 적용되는지 검증하는 제어된 검증입니다. (펜리전트)

이 CVE는 환경에 민감하기 때문에 중요합니다. 정적 SBOM 매칭은 취약한 버전이 존재한다는 것을 알려줍니다. 다음 여부는 알려주지 않습니다. .designspace 입력에 도달할 수 있는지, 작업자가 민감한 경로에 쓰기 가능한 액세스 권한이 있는지, 출력이 실행 가능한지, 보정 컨트롤에 실제로 폭발 반경이 포함되어 있는지 등을 확인합니다. 유효성 검사 중심의 워크플로는 종속성 목록만으로는 이러한 질문에 훨씬 더 잘 답할 수 있습니다. 바로 이 점에서 AI 지원 테스트 플랫폼은 그 기능을 과대 포장하지 않으면서도 유용할 수 있습니다. (NVD)

이번 주 강력한 반응의 모습

CVE-2025-66034에 대한 강력한 단기 대응은 복잡하지는 않지만 신중한 접근이 필요합니다. 모든 장소 파악 글꼴 도구 가 설치되어 있습니다. 모든 장소 식별 varLib 가 사용됩니다. PyPI 복사본을 다음 위치에 패치합니다. 4.60.2 이상으로 업데이트하세요. 해당되는 경우 배포 및 제품 업데이트를 적용합니다. 신뢰할 수 없는 배포 거부 .designspace 파일을 삭제합니다. 출력 디렉터리를 제한하세요. 최근 글꼴 처리 작업에서 의심스러운 쓰기나 예기치 않은 아티팩트가 있는지 감사하세요. 입력 파일을 출력 경로에 연결하는 로그를 보존합니다. 이것만으로도 "보통일 수도 있고, 중요할 수도 있는" 모호한 문제에서 구체적이고 관리 가능한 엔지니어링 작업으로 전환할 수 있습니다. (GitHub)

약한 대응도 마찬가지로 설명하기 쉽습니다. 직접 종속성 하나만 업데이트하고, 배포 패키지를 무시하고, 작업자에게 과도한 권한을 부여하고, 디자인 파일이 정상이라고 가정하고, NVD-GitHub CVSS 분할을 조치를 미루는 이유로 취급하는 식이죠. 이것이 바로 최신 자동화 버그가 성숙한 조직을 통해 계속 빠져나가는 방식입니다. 수정이 어렵기 때문이 아니라 실패할 때까지 문화적으로 그 경계가 보이지 않기 때문입니다. (NVD)

최종 평가

CVE-2025-66034는 글꼴과 관련된 것이기 때문에 흥미롭지 않습니다. 구조화된 파일을 중심으로 더 많은 자동화를 구축할수록 해당 파일이 수동적인 콘텐츠에서 벗어나 제어 표면이 되기 시작한다는 현대 시스템에서 반복되는 보안의 진실을 포착하고 있기 때문에 흥미롭습니다. In fontTools.varLib안에 있는 파일 이름입니다. .designspace 문서를 너무 많이 신뢰했습니다. 이 신뢰 오류로 인해 일상적인 빌드 흐름이 임의의 파일 쓰기 프리미티브로 바뀌었고, 올바른 환경에서는 RCE로 바뀌었습니다. (GitHub)

좋은 소식은 올해 가장 명확한 수정 사항 중 하나라는 점입니다. 취약한 범위가 공개되었습니다. 패치가 공개되었습니다. 릴리스 노트는 공개됩니다. 배포 공지는 공개됩니다. 다운스트림 엔터프라이즈 게시판은 공개됩니다. 진짜 문제는 버그가 무엇인지 이해하지 못하는 것입니다. 자체 파이프라인이 여전히 설계 및 아티팩트 입력을 '무해한 데이터'로 취급하면서 파일 시스템에 대한 지나치게 많은 권한을 부여하고 있는 부분에 대해 솔직해지는 것입니다. 이것이 바로 CVE-2025-66034의 진정한 교훈이며, 단일 패키지보다 더 큰 문제입니다. (GitHub)