[tocmat] CVE-2022-21824

tocmat - CVE-2022-21824

CVE-2022-21824는 “프로토타입 오염(Prototype Pollution)” 계열 이슈로 분류되는 경우가 많고, 실제로는 Node.js 런타임의 특정 동작(예: console.table 경로)과 맞물릴 때 경고로 뜨는 패턴이 자주 보입니다.
운영 환경에서는 “tocmat” 자체가 무엇이든, 어떤 프로세스가 어떤 Node.js 버전을 포함/사용하는지를 먼저 확정하는 게 핵심입니다. (실무 기준으로 보면, 취약점 이름보다 “실제 포함된 컴포넌트/버전”이 복구 속도를 좌우합니다.)

문서 범위: 일반오류형(확장형 매뉴얼) / 목표: 영향 확인 → 단기 완화 → 패치/복구 → 재발 방지

개요

핵심 요약
- 스캐너/진단 도구에서 “tocmat - CVE-2022-21824”로 표시되더라도, 실제 원인은 대개 tocmat이 포함한 Node.js(또는 번들된 런타임/라이브러리)일 수 있습니다.
- 대응은 “서비스 중단 최소화” 관점에서 ① 식별 → ② 단기 완화 → ③ 안전 버전으로 업데이트 순으로 진행합니다.

영향(운영 관점)
- 프로세스 비정상 동작/예외 증가, 일부 요청에서 기능 오작동 가능
- 로그/모니터링 상 에러율 상승, 일부는 DoS 형태(과도한 예외·메모리)로 나타날 수 있음
- “취약점 존재” 자체보다 외부 입력이 해당 취약 동작 경로로 들어갈 수 있는지가 실질 위험도를 결정

우선순위
1) 포함 여부 확정 2) 버전/빌드 확인 3) 패치 적용

- “tocmat”이 Tomcat(자바)처럼 보이는 이름이라도, 진단 결과가 Node.js CVE라면 운영 구성요소(사이드카, 빌드툴, 관리 콘솔, 프록시)에 Node가 섞여 있을 가능성이 큽니다.

환경

기록해야 할 항목(필수)
- tocmat 구성: 단일 바이너리/컨테이너/VM/온프렘/클라우드 매니지드 여부
- 실행 프로세스 목록(서비스/관리도구/배치 포함)
- Node.js 포함 방식: 시스템 설치 / 컨테이너 베이스 이미지 / 앱 번들 / 빌드 스테이지 전용
- 배포 경로: CI/CD 파이프라인, 이미지 태그/해시, 롤백 방법

# (리눅스 예시) 실행 중 프로세스에서 node 흔적 확인
ps aux | egrep -i "node|npm|yarn|pnpm" | head

# (컨테이너 예시) 이미지 내부 node 버전 확인
node -v
npm -v

# (패키지 매니저/배포물 예시) lockfile/번들 내 node 엔진/버전 단서 확인
cat package.json | sed -n '1,160p'
ls -al | egrep -i "package-lock|yarn.lock|pnpm-lock"

※ 컨테이너 기반이면 “런타임 컨테이너”와 “빌드 컨테이너”를 분리해서 확인하세요. 빌드 단계에만 node가 있고 런타임에는 없다면, 스캐너가 빌드 아티팩트/레이어를 잡아낸 것인지도 함께 판단해야 합니다.

증상

자주 나타나는 징후
- 취약점 스캐너(호스트/컨테이너/리포지토리)가 CVE-2022-21824를 탐지
- 보안 게이트(배포 차단 정책)에서 High 등급으로 빌드/배포 실패
- 특정 요청 처리 시 예외 로그가 증가(특히 입력 데이터가 예상과 다를 때)

# (예시 로그 형태) 진단 도구/CI 출력에서 흔히 보이는 패턴
Vulnerability detected: CVE-2022-21824
Component: nodejs (or node) / Severity: High
Path: /usr/local/bin/node  (or /app/node_modules/...)
Image: your-registry/your-image:tag

주의
- “tocmat”이라는 표시가 실제 제품명/프로세스명이 아닐 수 있습니다.
- 스캐너가 “취약점 DB 매칭”으로 표시하는 이름과, 운영에서 실행되는 실제 바이너리/라이브러리는 다를 수 있으니 경로(Path)를 가장 먼저 보세요.

1차 점검

체크리스트(빠르게 결론 내기)
1) 경고가 가리키는 파일 경로에 실제로 node가 존재하는가?
2) 해당 node가 런타임에서 실행되는가 아니면 빌드/테스트 도구에만 존재하는가?
3) node 버전이 안전 버전(패치 포함)인지 확인했는가?
4) 외부 입력이 취약 동작 경로로 들어갈 수 있는 구조인가(콘솔 출력/테이블 출력 등 포함)?

# (리눅스/컨테이너) node 버전 확정
which node || command -v node
node -v

# (런타임 실행 여부) 현재 실행 중인 node 프로세스 확인
pgrep -a node || true

# (컨테이너) 실행 레이어에 node가 있는지, 빌드 레이어만 있는지 점검(멀티스테이지 빌드라면 특히 중요)
# - 런타임 이미지에서 node -v가 안 나오면, 빌드 전용일 수 있음

판정 가이드(운영 입장)
- 런타임에서 node가 실행 중이고 버전이 취약 범위라면: 즉시 패치 계획 수립
- 런타임에 node가 없고 빌드 레이어에서만 탐지라면: 빌드 이미지를 분리/정리 또는 스캔 대상 정책 조정(보안팀 합의 필요)
- “번들된 node”라면: 상위 제품(tocmat) 업데이트 또는 번들 교체가 우선

심화 분석

왜 Node.js CVE가 tocmat로 뜨나?
- 보안 도구가 “애플리케이션 이름” 대신 “탐지 지점(패키지/이미지/경로)”을 대표 라벨로 보여주기 때문입니다.
- 예: tocmat 컨테이너 안에 node 런타임이 포함되어 있거나, 관리 UI/배치 작업이 node로 구성된 경우

기술적 관점(요지)
- CVE-2022-21824는 프로토타입 오염(Prototype Pollution) 취약점으로 분류되며,
- 특정 입력을 다루는 과정에서 Object 프로토타입에 예상치 못한 영향이 생길 수 있는 케이스로 보고됩니다.
- 다만 “항상 원격 코드 실행”처럼 단정하기보다는, 우리 서비스에서 해당 코드 경로가 외부 입력과 연결되는지를 확인하는 게 중요합니다.

# (코드 관점 점검 포인트 예시)
# - 사용자 입력(요청/메시지/파일) 값을 그대로 console.table(...)에 넣는 코드가 있는지
# - 디버그/운영 로그에서 구조화된 데이터를 테이블로 출력하는 경로가 있는지

# 검색 예시(리포지토리)
grep -RIn --exclude-dir=node_modules "console\.table" .

실제 사용 시에는 “외부 입력 → 로깅/테이블 출력 → 프로세스 영향” 연결이 있는지, 그리고 “권한 없는 원격 사용자”가 그 경로를 만들 수 있는지까지 확인하면 우선순위를 더 정확히 잡을 수 있습니다.

복구

권장 복구 흐름
1) 안전한 버전으로 업데이트(가장 확실한 해결)
2) 즉시 업데이트가 어렵다면 단기 완화(입력 경로 차단/코드 경로 회피) + 변경관리 기록
3) 배포 후 재스캔 및 모니터링으로 “탐지 해소”와 “장애 없음”을 동시에 확인

업데이트(일반 가이드)
- 노드 런타임이 직접 설치되어 있다면: OS 패키지/공식 배포판 기준으로 안전 버전으로 상향
- 컨테이너라면: 베이스 이미지를 최신 보안 패치 포함 버전으로 교체 후 재빌드
- 번들(상위 제품 내 포함)이라면: tocmat 제품 업데이트/핫픽스 적용이 우선

# (컨테이너 예시) 베이스 이미지/런타임 업데이트 후 재빌드
# - 예시는 개념용이며, 조직 표준 이미지/레지스트리 정책을 따르세요.
docker build -t your-image:patched .
docker run --rm your-image:patched node -v

# 배포 후 점검(예시)
curl -fsS https://your-service/healthz

단기 완화(업데이트 전 임시)
- 외부 입력이 console.table 등 “테이블 출력 경로”로 들어가지 않도록 차단/검증 강화
- 문제 코드 경로가 디버그/옵션일 경우 운영에서 비활성화
- WAF/게이트웨이에서 비정상 파라미터(프로토타입 키 유사 패턴) 필터링을 임시 적용(과차단 주의)

단기 완화는 “위험도 낮추기”일 뿐, 보안 감사/게이트를 통과하려면 최종적으로 패치(버전 상향)가 필요할 때가 많습니다.

재발 방지

운영 프로세스
- SBOM/컴포넌트 인벤토리 유지(이미지 해시, 런타임 버전, 번들 포함 관계)
- “빌드 이미지”와 “런타임 이미지” 분리(멀티스테이지 빌드 정착)
- 보안 스캔 기준: 런타임 레이어 중심 + 예외 승인 워크플로 명문화

기술적 가드레일
- 외부 입력의 객체 키 화이트리스트/스키마 검증(특히 로그/디버그 출력 전)
- 의존성 업데이트 정책(정기 업데이트, LTS 추적, 긴급 패치 창구)
- 모니터링: 에러율/메모리/CPU 급증 알림 + 릴리즈별 비교

릴리즈 체크(추천)
- 배포 전: 이미지/호스트 스캔 결과(해당 CVE 포함 여부) 확인
- 배포 후: 동일 조건 재스캔 + 서비스 지표(에러율, 지연, 리소스) 확인
- 기록: “탐지 ID / 영향 컴포넌트 / 버전 / 조치일 / 롤백 포인트”를 변경관리 티켓에 남기기

결과

완료 기준
- (필수) 스캐너/CI 게이트에서 CVE-2022-21824 탐지가 해소됨
- (필수) 운영 지표 이상 없음(에러율/지연/리소스)
- (권장) 어떤 구성요소가 원인이었는지(tocmat 내부/외부, 런타임/빌드) 문서화 완료

다음에 같은 유형이 재발하면, “tocmat이라는 표기”에 끌려가기보다 탐지 경로(Path) → 실제 실행 여부 → 버전 순서로 보면 훨씬 빨리 정리됩니다.