지키는 장비와 뚫리는 장비는 한 끗 차이 — PAN-OS CVE-2026-0322 코드 인젝션 대응 메모

이미지 출처: CISA KEV

2024년 봄, GlobalProtect 취약점(CVE-2024-3400) 때문에 전 세계 보안 담당자들이 주말에 방화벽 앞에 붙어 있었던 일을 기억하는 분들이 꽤 있을 것 같다. 나도 그때 로그를 밤새 뒤졌다. 그런데 Palo Alto Networks PAN-OS에서 코드 인젝션(Code Injection) 취약점이 또 하나 공개됐다. 이번 번호는 CVE-2026-0322. 방화벽은 네트워크 맨 앞에서 모든 트래픽을 보는 장비라서, 이 장비가 공격자 뜻대로 코드를 실행한다면 사실상 성문을 열어주는 것과 같음. 그래서 이번 글은 "무엇이 위험한가"보다는 "우리 장비는 지금 괜찮은가, 어떻게 확인하고 막을까"에 초점을 맞춰 정리해봤다.

핵심 요약

• CVE-2026-0322는 PAN-OS에서 외부 입력이 제대로 걸러지지 않아 의도하지 않은 코드가 실행될 수 있는 코드 인젝션 취약점임.
• 영향받는 버전과 심각도는 Palo Alto 보안 권고문에서 정확히 확인하고, 해당되면 수정 버전으로 올리는 것이 1순위임.
• 패치 전까지는 관리 인터페이스·포털 노출을 줄이고, 비정상 프로세스·설정 변경·외부 통신 로그를 중점적으로 봐야 함.

1. 코드 인젝션이 방화벽에서 특히 무서운 이유

코드 인젝션은 개념만 보면 단순함. 프로그램이 사용자 입력을 "데이터"로만 다뤄야 하는데, 검증이 허술하면 그 입력이 "코드"로 해석되어 실행돼 버리는 구조. 웹 애플리케이션에서 자주 보던 유형인데, 이게 방화벽 OS에서 터지면 이야기가 달라짐.

• 권한이 높음 — 방화벽 프로세스는 대부분 높은 권한으로 돌기 때문에, 한 번 실행되면 장비 전체 장악으로 이어질 수 있음.
• 보는 눈이 적음 — 서버에는 EDR을 깔지만 방화벽 내부에는 그런 에이전트가 없음. 탐지가 늦어지기 쉬움.
• 내부망의 관문 — VPN 세션, 정책, 인증 정보가 다 모여 있는 곳이라 침투 이후 횡적 이동의 발판이 됨.

공격 흐름을 굳이 개념으로만 그려보면, 공격자가 취약한 입력 지점에 조작된 값을 보내고 → 장비가 그 값을 처리하는 과정에서 코드로 해석하고 → 이후 지속성 확보나 설정 탈취로 넘어가는 식임. 구체적인 페이로드는 여기서 다루지 않고, 방어자는 각 단계마다 어떤 흔적이 남는지만 알면 충분하다고 생각함.

2. 지금 바로 확인할 것

• 버전 확인 — 운영 중인 PAN-OS 버전(Panorama, Prisma Access 포함)을 정리하고, Palo Alto 보안 권고문(security.paloaltonetworks.com)의 영향 범위와 대조하기.
• 노출 면 확인 — 관리 인터페이스(웹 UI, SSH)가 인터넷이나 넓은 내부 대역에 열려 있는지. GlobalProtect 포털·게이트웨이를 쓰고 있는지도 같이 체크.
• KEV 등재 여부 — CISA KEV 목록에 올라와 있다면 이미 실제 공격이 관측됐다는 뜻이니 우선순위를 최상단으로 올리기.

3. 로그에서 볼 것

개인적으로는 패치보다 이 단계를 먼저 하는 걸 추천하는 편이다. 이미 당했는데 패치만 하면 흔적이 덮여버리기 때문임.

• 시스템·관리 로그 — 평소 없던 시간대의 관리자 로그인, 알 수 없는 출발지 IP의 웹 UI 접근, 실패 후 갑자기 성공하는 패턴.
• 설정 변경 이력(Config Log) — 누가 했는지 모르는 정책 추가, 관리자 계정 생성, 로깅 설정 비활성화.
• 장비발 외부 통신 — 방화벽 자신이 출발지인 낯선 외부 연결. 방화벽이 먼저 바깥으로 말을 거는 건 업데이트 서버 정도 말고는 드묾.
• 장애·재부팅 이력 — 이유 없는 프로세스 크래시나 재시작은 공격 시도의 부산물일 수 있음.
• Tech Support File 분석 — 의심스러우면 TSF를 떠서 벤더나 침해대응 팀에 분석 의뢰하는 것도 방법.

4. 완화 조치, 우선순위대로

• 1순위: 수정 버전으로 업그레이드 — 권고문의 fixed 버전으로 올리기. 핫픽스가 단계적으로 나오는 경우가 많으니 본인 트레인에 맞는 버전을 꼭 확인.
• 2순위: 관리 평면 격리 — 관리 인터페이스는 전용 관리망이나 점프 서버에서만 접근되게 Permitted IP를 좁히기. 인터넷 노출은 절대 금지.
• 3순위: Threat Prevention 시그니처 — 구독 중이라면 해당 CVE용 위협 ID가 배포됐는지 확인하고 차단 액션으로 적용.
• 4순위: 침해 의심 시 재구축 관점 — 흔적이 나왔다면 패치로 끝내지 말고 관리자 계정·API 키·VPN 인증서 교체, 필요하면 공장 초기화 후 재구성까지 고려.

5. 해보면서 느낀 점

방화벽 취약점이 나올 때마다 드는 생각인데, 결국 사고를 키우는 건 취약점 자체보다 "관리 화면이 바깥에 열려 있었다"는 기본 설정 문제인 경우가 많은 것 같다. 패치는 벤더가 주지만, 노출 면을 줄이는 건 운영자가 평소에 해둬야 하는 일이다 보니 이번 기회에 관리 접근 정책을 한 번 싹 정리해두면 다음 CVE 때 훨씬 마음이 편할 거다.

혹시 운영 중인 환경에서 비슷한 로그 패턴을 보셨거나, 패치 적용하면서 겪은 이슈가 있다면 댓글로 공유해 주세요. 같이 정리하면서 더 단단하게 막아보아요!