보안이슈

ArubaOS-CX 버퍼 오버플로(CVE-2026-73749)|영향 범위와 대응

인증 없이 높은 권한의 원격 코드 실행이 가능한 ArubaOS-CX 취약점의 영향 분기와 고정 버전, 관리망 통제를 다룹니다.

ArubaOS-CX 버퍼 오버플로(CVE-2026-73749)|영향 범위와 대응
ArubaOS-CX 버퍼 오버플로(CVE-2026-73749)|영향 범위와 대응

취약점의 성격

HPE Networking이 2026년 9월 1일 공개한 CVE-2026-73749는 AOS-CX의 특정 데몬이 비정상 입력을 처리하는 과정에서 발생하는 버퍼 오버플로 취약점입니다. CVSS 3.1 기준 9.8점이며, 인증되지 않은 원격 공격자가 영향을 받는 서비스에 특수 제작 패킷을 보내면 운영체제에서 높은 권한으로 코드를 실행할 수 있습니다. 네트워크 스위치의 관리 기능과 제어 기능을 담당하는 운영체제에서 권한 높은 코드가 실행될 수 있다는 점 때문에, 단순 관리 페이지 결함이 아니라 장비 신뢰 경계 전체를 재확인해야 하는 문제입니다.

HPE 권고에는 다수의 AOS-CX 취약점이 함께 실렸지만, 상위 인계에서 독립 분석 대상으로 지정된 항목은 이 가운데 유일한 Critical 등급인 CVE-2026-73749입니다. 같은 권고에 포함된 고위험 항목을 한 글에서 반복 열거하기보다, 이 취약점의 비인증 패킷 처리 경로와 릴리스별 교체 기준에 집중하는 편이 실제 조치에 도움이 됩니다. 공격에 계정이나 사용자 동작이 필요하지 않으므로 관리 인터페이스가 인터넷에 직접 공개되지 않았더라도 관리 VLAN, 운영 도구, 인접 네트워크에서 서비스로 도달하는 경로를 확인해야 합니다.

영향 릴리스 판별

ArubaOS-CX 버퍼 오버플로(CVE-2026-73749)|영향 범위와 대응의 영향 조건과 대응 흐름
영향 조건과 대응 순서

HPE가 제시한 영향 범위는 AOS-CX 10.18.0001, 10.17.1021 이하, 10.16.1051 이하, 10.13.1180 이하, 그리고 유지보수 종료 상태인 10.10.1180 이하입니다. 자산 목록에는 스위치 모델명만 저장하지 말고 실제 AOS-CX 빌드, 관리 주소, 관리 VLAN, 운영 역할, 이중화 상대를 함께 기록해야 합니다. 같은 제품군도 릴리스 분기와 지원 상태에 따라 선택할 수정판과 변경 위험이 달라집니다.

유지보수가 종료된 소프트웨어는 권고가 명시적으로 제외하지 않는 한 영향 대상으로 취급됩니다. 특히 10.10.x 분기는 오래된 구조 때문에 내부에서 확인된 Critical 취약점만 수정됐다는 HPE 설명을 함께 고려해야 합니다. 10.10.1181로 올렸다는 사실만으로 장기 조치를 끝내기보다, 지원되는 분기로 이동할 수 있는지 별도 계획을 세우는 편이 안전합니다. 지원 종료 분기는 HPE가 노출 여부를 평가하지 않았으므로, 지원 릴리스로 이동해야 공식 수정 상태를 지속적으로 검증할 수 있습니다.

패킷 경로와 운영 영향

공격 흐름은 네트워크에서 접근 가능한 공격자가 영향을 받는 데몬으로 조작된 패킷을 보내는 단계에서 시작합니다. 데몬의 입력 검증이 버퍼 경계를 지키지 못하면 메모리 손상이 발생하고, 성공한 경우 높은 권한의 원격 코드 실행으로 이어집니다. 스위치 운영체제의 권한 높은 실행은 구성 변경, 관리 자격증명 노출, 트래픽 가시성 훼손, 장비 가용성 저하로 연결될 수 있으므로 패치 전후의 구성과 로그를 함께 보존해야 합니다.

관리망이 별도 VLAN이라는 사실은 출발점일 뿐 완료 조건이 아닙니다. 점프 서버, 네트워크 관리 시스템, 자동화 플랫폼, 모니터링 서버, 무선 관리망, 원격 유지보수 경로가 해당 VLAN에 진입할 수 있다면 각 출발지의 필요성을 다시 검토해야 합니다. 방화벽 정책은 장비 관리 주소로 향하는 트래픽을 최소 허용하고, 계정 사용과 구성 변경이 중앙 로그에 남도록 정리해야 합니다. HPE는 CLI와 웹 관리 인터페이스를 전용 Layer 2 세그먼트 또는 VLAN에 제한하고, Layer 3 이상 방화벽 정책과 회계·감사 통제를 함께 사용할 것을 권고합니다.

수정 버전과 변경 계획

HPE가 제시한 고정 버전은 AOS-CX 10.18.1002 이상, 10.17.1030 이상, 10.16.1060 이상, 10.13.1190 이상, 10.10.1181 이상입니다. 현재 분기에 맞는 수정 빌드를 선택하되 장비 모델 지원, 부트 이미지, VSX·스태킹 구성, 기능 라이선스, 주변 장비 호환성을 릴리스 노트와 대조해야 합니다. 한 번에 전체 장애 도메인을 교체하지 말고, 이중화 상대와 트래픽 우회 경로를 기준으로 순서를 정하는 것이 좋습니다.

변경 전에는 실행 중인 이미지, 시작 이미지, 구성 백업, 관리 접근 정책, CPU·메모리, 인터페이스 오류, 라우팅 인접성, VSX 상태를 기준선으로 저장합니다. 첫 장비를 업그레이드한 뒤에는 단순 부팅 성공만 확인하지 말고 제어 평면 수렴과 실제 포워딩, 원격 관리, 로깅, 자동화 작업을 점검해야 합니다. 기준선과 차이가 없을 때 다음 장애 도메인으로 진행하면 패치 자체가 야기하는 운영 중단을 줄일 수 있습니다.

점검 순서

  1. AOS-CX 자산의 모델, 실제 빌드, 관리 주소, 관리 VLAN을 수집합니다.
  2. 영향 버전 표와 대조하고 지원 종료 분기를 별도로 표시합니다.
  3. 관리 서비스에 도달 가능한 점프 서버와 운영 도구를 목록화합니다.
  4. 관리 인터페이스를 전용 세그먼트와 최소 허용 방화벽 정책으로 제한합니다.
  5. 분기별 고정 버전을 선택하고 이중화 구조에 맞춰 순차 업그레이드합니다.
  6. 라우팅, 포워딩, VSX, 관리 접속, 중앙 로그를 기준선과 비교합니다.

패치 완료 증거에는 장비별 설치 빌드와 변경 시각, 적용한 접근제어 정책, 업그레이드 전후 상태, 담당자 검증 결과를 함께 남기는 편이 좋습니다. CVE 번호만 닫아 놓으면 다음 자산 감사에서 실제로 어느 스위치가 수정됐는지 재현하기 어렵습니다. 자산 식별, 경로 축소, 고정 릴리스, 사후 검증을 하나의 작업 기록으로 묶으면 CVE-2026-73749 대응을 운영 가능한 상태로 유지할 수 있습니다.

사후 확인과 롤백

업그레이드 이후에는 관리 데몬의 예기치 않은 재시작, 장비 재부팅, 구성 변경, 새 관리 계정, 방화벽 거부 로그를 관찰합니다. 공격 코드를 시험하지 않고도 기존 중앙 로그와 구성 이력을 이용해 비정상 접근과 변경을 확인할 수 있습니다. 관리 시스템에서 평소와 다른 출발지나 시간대의 접속이 보이면 변경 작업 기록과 분리해 조사해야 합니다.

롤백은 이전 취약 버전으로 장기간 돌아가는 해결책이 아니라 서비스 복구를 위한 제한된 절차입니다. 새 이미지에서 운영 장애가 발생하면 콘솔 접근과 저장된 구성으로 서비스를 안정화하고, 원인을 확인한 뒤 지원되는 수정 분기에서 대체 빌드를 선택해야 합니다. 롤백 동안에도 관리 경로 제한을 유지하고 재적용 기한을 변경 기록에 남겨야 임시 복구가 영구 미조치로 굳어지지 않습니다.

자산 분류와 우선순위

우선순위는 인터넷 노출 여부 하나로 정하지 않습니다. 관리 데몬으로 패킷 전송이 가능한 내부 구간의 수, 운영 자동화 계정의 권한, 스위치가 담당하는 서비스의 중요도, 이중화 가능 여부, 현재 릴리스의 지원 상태를 함께 점수화하는 편이 좋습니다. 코어 또는 데이터센터 경계 스위치처럼 장애 영향이 큰 장비는 긴급성이 높지만 변경 위험도 크므로, 접근 경로를 먼저 줄이고 검증된 유지보수 창에서 업그레이드하는 두 단계 계획이 적합합니다.

자산관리 자료와 장비 자체 출력이 다를 수 있으므로 중앙 목록만으로 완료 판정을 내리지 않습니다. 장비에서 확인한 실행 이미지와 시작 이미지가 일치하는지, 재부팅 뒤에도 고정 릴리스가 유지되는지 검증해야 합니다. 예비 장비나 장기 보관 장비도 네트워크에 다시 투입될 수 있으므로 이미지 저장소와 표준 구성 템플릿을 수정해 취약 빌드가 재배포되지 않도록 관리합니다.

로그와 구성 무결성

원격 코드 실행 가능성을 고려하면 패치 전에 시스템 로그, 관리자 인증 기록, 구성 변경 이력, 원격 로깅 상태를 보존하는 것이 좋습니다. 평소 사용하지 않는 관리 주소의 접속, 새 계정이나 권한 변경, 예상하지 않은 구성 저장, 관리 데몬 재시작을 변경 작업 시간과 구분해 검토합니다. 외부 IOC를 임의로 가정하기보다 조직이 보유한 기준선과 승인 기록을 이용해 비정상 변화를 찾는 방식이 안전합니다.

백업 구성도 무조건 신뢰하지 말고 생성 시각과 승인된 변경 내역을 맞춰봐야 합니다. 이상 징후가 발견된 장비는 단순 업그레이드만으로 조사 흔적을 덮지 않도록 로그와 구성 사본을 먼저 확보하고, 관리 자격증명과 자동화 토큰의 교체 범위를 정합니다. 패치 뒤에는 중앙 관리 시스템이 새 빌드를 정확히 인식하고 취약 버전 정책에서 장비를 제외했는지 확인해야 합니다.

관리 인터페이스의 IPv4 정책만 고치고 IPv6 경로나 별도 서비스 VRF를 남기지 않도록 주소 체계를 모두 대조합니다. 외부 유지보수 계정과 임시 방화벽 예외도 만료 시각을 확인하고, 고정 릴리스 적용 뒤에는 임시 허용 규칙을 회수해 관리망의 최소 접근 상태를 복원합니다.

확인한 출처

  1. HPESBNW05134 rev.1 - Multiple Vulnerabilities in HPE Networking AOS-CXHPE Networking · 공식 자료
  2. Signed text for HPESBNW05134HPE Networking · 공식 자료

사실관계와 수치는 연결된 자료에서 다시 확인할 수 있습니다.

독자 의견

의견을 남겨주세요

0

아직 등록된 댓글이 없습니다.

개인정보·광고·외부 연락처는 입력하지 마세요.