GitLab AI Gateway 취약점, 승인된 Duo 액세스를 심각한 RCE 위험으로 전환

GitLab은 승인된 Duo Agent Platform 액세스를 자체 호스팅 게이트웨이에서의 명령 실행으로 이어지게 할 수 있는, CVSS 9.9 등급의 GitLab AI Gateway 취약점을 패치했다. CVE-2026-90970으로 추적되는 이 결함은 제품이 강제해야 했던 경계를 넘는다. 조작된 플로우 구성은 프롬프트 템플릿 샌드박스를 탈출해 게이트웨이에서 임의 명령을 실행할 수 있다.

이 조건은 중요하다. 이는 모든 GitLab 서버에 대한 보고된 제로클릭 침해가 아니며, 익명의 인터넷 사용자에게 즉각적인 액세스를 제공하지도 않는다. 악용하려면 인증과 Duo Agent Platform 액세스가 필요하다. 그러나 GitLab의 심각도 평가는 이러한 조건이 충족된 뒤 발생할 수 있는 결과를 반영한다. 즉, 낮은 복잡도의 네트워크 기반 악용, 추가 사용자 상호작용 불필요, 그리고 기밀성·무결성·가용성 전반에 걸친 잠재적으로 심각한 영향이다.

이번 사건은 통제와 책임 사이에 직접적인 긴장을 만든다. 조직은 코드, 프롬프트, 모델 트래픽을 신뢰 경계 안에 유지하기 위해 AI 인프라를 자체 호스팅한다. 하지만 자체 호스팅은 이 민감한 자료를 처리하는 서비스를 업데이트할 책임 역시 해당 조직에 부여한다. GitLab 호스팅 게이트웨이는 이미 패치됐지만, 영향을 받는 자체 호스팅 게이트웨이 운영자는 직접 업그레이드를 완료해야 한다.

GitLab AI Gateway 취약점으로 달라진 점

CVE-2026-90970은 AI 워크플로 구성 권한을 운영체제 명령 실행으로 이어질 수 있는 경로로 전환한다.

GitLab은 2026년 10월 2일 이 문제를 공개했다. 공개 취약점 기록에 따르면, 영향받는 릴리스에는 18.1.6부터 19.2.4 이전 버전까지의 AI Gateway 버전이 포함된다. 19.3 브랜치는 19.3.2 이전 버전에서 영향을 받고, 19.4 브랜치는 19.4.1 이전 버전에서 영향을 받는다.

이 버전 경계는 GitLab 메인 애플리케이션의 릴리스 이력과 다르다. 따라서 관리자는 AI Gateway 이미지 또는 배포 자체를 확인해야 한다. 게이트웨이가 별도의 배포 수명 주기를 따르는 경우, 눈에 보이는 GitLab 애플리케이션 버전만 확인하면 잘못된 안도감을 줄 수 있다.

수정 버전은 19.2.4, 19.3.2, 19.4.1이다. 운영자는 해당 수정 릴리스 또는 이후 지원 버전으로 이동해야 한다. GitLab 호스팅 게이트웨이는 이미 완화 조치를 받았으므로, GitLab.com 및 GitLab의 관리형 게이트웨이를 사용하는 고객은 동일한 패치 작업에 직면하지 않는다.

취약한 경로는 특별히 조작된 플로우 구성에서 시작된다. 플로우는 프롬프트, 도구, 판단, 작업을 결합할 수 있는 에이전트형 시퀀스를 정의한다. GitLab Duo Agent Platform은 단일한 고립 프롬프트에 답하는 대신, 이러한 구성을 활용해 다단계 소프트웨어 개발 작업을 수행한다.

프롬프트 템플릿은 플로우의 구성과 런타임 데이터를 AI 모델이 처리할 수 있는 지침으로 변환한다. 템플릿 샌드박스는 템플릿 콘텐츠가 안전하지 않은 애플리케이션 또는 운영체제 기능에 도달하는 것을 막기 위해 설계된 제한 환경이다. CVE-2026-90970은 이 경계 내의 부적절한 중화와 관련된다.

이 취약점은 CWE-1336, 즉 템플릿 엔진에서 사용되는 특수 요소의 부적절한 중화로 분류된다. 실질적으로는 공격자가 제어하는 구문이 비활성 데이터가 아니라 실행 가능한 템플릿 동작으로 해석될 수 있다는 뜻이다. 정확한 위험 결과는 주변 애플리케이션, 사용 가능한 기능, 프로세스 권한에 따라 달라진다.

이 결함의 경우 GitLab은 AI Gateway에서 임의 명령 실행이 가능하다고 설명한다. 이는 AI 응답을 조작하는 것보다 더 심각한 결과다. 취약점이 모델 출력을 넘어 게이트웨이를 호스팅하는 일반적인 실행 환경까지 도달한다는 의미다.

AI Gateway와 대규모 언어 모델의 구분은 중요하다. 게이트웨이는 GitLab 기능과 AI 모델 사이에 위치한 독립형 애플리케이션 서비스다. GitLab의 게이트웨이 문서에 따르면, 이 서비스는 AI 네이티브 GitLab Duo 기능에 대한 액세스를 제공한다. 모델 자체로 기능하는 것이 아니라 모델 주변의 애플리케이션 로직과 요청을 처리한다.

따라서 이 취약점은 모델이 독립적으로 탈출 방법을 찾아내거나 행동 안전 지침을 무시했다는 증거가 아니다. 보고된 메커니즘은 템플릿 처리 과정의 소프트웨어 취약점이다. 다만 그 입력이 에이전트형 구성 표면을 통해 들어온다.

이 사실은 이번 사건을 익숙한 보안 범주 안에 두지만, 그 환경은 위험도를 높인다. AI 게이트웨이는 소스에서 유래한 컨텍스트, 워크플로 지침, 인증 자료, 모델 백엔드 연결을 처리할 수 있다. 이런 접점에서의 명령 실행 취약점은 잘못된 프롬프트나 신뢰할 수 없는 답변 이상의 정보를 노출할 수 있다.

GitLab은 CVE-2026-90970의 광범위한 악용을 공개적으로 설명하지 않았다. 현재 उपलब्ध한 기록 역시 공격자가 이 취약점을 실제 운영 환경에 사용했음을 입증하지 않는다. 특히 공개 이후 잠재적 공격자에게 더 명확한 표적이 제공된 상황에서, 관리자는 이 확인 공백을 안전의 증거로 해석해서는 안 된다.

따라서 즉각적인 변화는 운영 측면에 있다. 이전까지 통제된 내부 구성 요소로 여겨졌던 자체 호스팅 AI Gateway는 이제 긴급한 버전 확인, 패치, 업그레이드 후 검토가 필요하다. 위험도는 메인 GitLab 인터페이스가 공개돼 있는지 여부만으로 판단할 수 없다.

인증된 샌드박스 탈출이 9.9 등급을 받는 이유

이 취약점은 공격 가능한 주체를 제한하는 전제 조건이 존재하더라도, 샌드박스가 실패할 경우 잠재적 영향이 광범위하기 때문에 심각하다.

GitLab은 CVE-2026-90970에 CVSS 3.1 기본 점수 9.9를 부여했다. 공개된 벡터는 AV:N/AC:L/PR:L/UI:N/S:C/C:H/I:H/A:H다. 각 요소는 인증이 필요한 결함이 어떻게 심각도 척도의 최상단에 위치할 수 있는지 설명한다.

네트워크 공격 벡터는 잠재적 공격자가 게이트웨이 호스트에 대한 로컬 셸 액세스를 가질 필요가 없음을 의미한다. 관련 서비스는 네트워크로 접근 가능한 애플리케이션 기능을 통해 악성 구성을 수신할 수 있다. 네트워크 접근 가능하다는 것이 반드시 전체 공용 인터넷에 노출돼 있다는 뜻은 아니지만, 물리적 또는 로컬 액세스를 넘어 가능한 공격 경로를 확장한다.

낮은 공격 복잡도는 악용이 좁은 경쟁 조건이나 특수한 배포 상태에 의존하지 않음을 뜻한다. 권한이 전혀 필요 없는 것은 아니지만, 낮은 수준의 권한만 요구된다. 사용자는 인증돼 있어야 하며 Duo Agent Platform 액세스 권한을 가져야 한다.

사용자 상호작용 불필요는 구성이 취약한 경로에 도달한 뒤 다른 사람이 파일을 열거나, 대화상자를 승인하거나, 악성 링크를 방문할 필요가 없다는 뜻이다. 이 특성은 신뢰된 자동화가 두 번째 사람의 조치 없이 제출된 구성을 처리하는 협업 개발 환경에서 특히 중요하다.

변경된 범위 구성 요소는 특히 중요하다. 이는 악용이 원래의 취약한 구성 요소가 나타내는 보안 권한을 넘어선 리소스에 영향을 줄 수 있음을 나타낸다. 여기서는 템플릿 입력이 승인된 에이전트 워크플로 안에서 시작하지만, 게이트웨이의 명령 실행 환경으로 넘어갈 수 있다.

마지막 세 지표는 기밀성, 무결성, 가용성에 대한 높은 잠재적 영향을 기록한다. 명령 실행은 이론적으로 접근 가능한 정보를 읽고, 게이트웨이 리소스를 수정하거나, 서비스를 중단하는 데 사용될 수 있다. 실제 피해는 여전히 배포 아키텍처, 프로세스 권한, 네트워크 도달 가능성, 사용 가능한 자격 증명에 따라 달라진다.

이러한 맥락은 두 가지 오해를 막는다. 이 취약점을 “인증 필요”라고 부르는 것은 일반적인 계정 수준 문제로 치부하는 데 사용돼서는 안 된다. 이를 “원격 코드 실행”이라고 부르는 것 역시 모든 익명 방문자가 즉시 GitLab 환경을 침해할 수 있다는 뜻으로 받아들여서는 안 된다.

관련 공격자는 이미 유효한 사용자일 수 있다. 탈취된 계정, 도난당한 토큰 또는 과도한 권한이 부여된 자동화 ID를 제어하는 사람일 수도 있다. 합법적인 액세스가 인프라에 대한 무제한 권한과 동일한 경우는 드물기 때문에, 보안 경계는 인증 이후에도 계속 작동해야 한다.

에이전트 시스템은 이 구분을 더 시급하게 만든다. 이들은 구조화된 지침을 받아 개발 서비스 전반에서 일련의 작업을 수행할 수 있다. 플로우를 정의할 권한을 가진 사용자는 광범위한 애플리케이션 기능을 필요로 할 수 있지만, 그 사용자가 플로우를 해석하는 서비스의 운영체제 권한까지 상속받아서는 안 된다.

취약한 샌드박스는 이러한 분리를 유지하기 위한 장치였다. 이 장치의 실패는 구성 언어를 실행 가능 표면으로 바꾼다. 이것이 GitLab AI Gateway 취약점의 핵심적인 역전이다. 에이전트 작업을 통제하기 위해 설계된 기능이 자체 격리 계층을 우회하는 경로가 된다.

템플릿 인젝션은 프롬프트 인젝션과도 다르다. 프롬프트 인젝션은 모델에 전송되는 지침을 조작해 모델의 동작을 바꾸거나 컨텍스트 데이터를 노출하려 한다. 템플릿 인젝션은 그러한 프롬프트를 구성하거나 렌더링하는 소프트웨어를 겨냥한다. 템플릿 엔진이 안전하지 않은 객체나 기능을 노출하면, 모델이 어떻게 응답하는지와 관계없이 서버 측 실행으로 이어질 수 있다.

CWE-1336은 이 실패 유형을 공식화한다. 템플릿 엔진 취약점은 소프트웨어가 템플릿 엔진이 실행 가능한 구문으로 취급하는 요소를 중화하지 못할 때 발생한다. 가장 안전한 대응은 모델에 또 다른 행동 지침을 제공하는 것이 아니다. 공격자가 제어하는 데이터가 실행 가능한 템플릿 콘텐츠가 되지 못하도록 막는 소프트웨어 수정이다.

이 차이는 사고 검토 방식에 반영돼야 한다. 팀은 애플리케이션 권한, 구성 이력, 게이트웨이 로그, 컨테이너 활동, 다운스트림 자격 증명을 조사해야 한다. AI 대화 기록만 검토하면 게이트웨이 프로세스 또는 주변 런타임에서 발생한 활동을 놓치게 된다.

게이트웨이는 root로 실행되지 않더라도 흔히 권한이 높은 통합 위치에 놓인다. GitLab 인스턴스, 모델 서버, 관측 시스템 또는 내부 네트워크 서비스와 통신할 수 있다. 운영자는 한 컨테이너에서의 명령 실행이 자동으로 전체 인프라 침해를 의미한다고 가정하지 말고, 이러한 연결을 매핑해야 한다.

컨테이너화는 적절히 구성된 경우 영향을 줄일 수 있지만, 사고 자체를 없애지는 못한다. 침해된 컨테이너는 마운트된 시크릿, 서비스 토큰, 네트워크로 접근 가능한 시스템 또는 프로세스가 처리하는 데이터를 여전히 노출할 수 있다. 과도한 권한, 쓰기 가능한 마운트, 광범위한 네트워크 경로는 피해 범위를 확대한다.

따라서 9.9 점수는 모든 영향 환경이 최대 피해를 입었다는 증거가 아니라, 최악의 경우를 표준화해 평가한 결과다. 관리자는 이 점수를 실제 배포 아키텍처와 함께 검토해야 한다. 올바른 결론은 침해의 자동 확인이 아니라 긴급한 조사와 완화 조치다.

자체 호스팅은 데이터 통제를 패치 책임과 맞바꾼다

자체 호스팅 게이트웨이의 보안 약속은 고객이 이를 핵심 인프라로서 인벤토리화하고, 격리하며, 업데이트하고, 모니터링할 수 있을 때에만 유효하다.

GitLab은 관리형, 하이브리드, 완전 자체 호스팅 AI 구성을 지원한다. 관리형 구성에서는 GitLab이 게이트웨이를 운영하고 선택된 외부 모델 제공업체에 연결한다. 자체 호스팅 배포에서는 게이트웨이와 모델 경로를 고객이 통제하는 인프라 내부에 둔다.

그 아키텍처는 엄격한 프라이버시, 데이터 상주, 네트워크 격리 요구사항을 지원할 수 있습니다. GitLab의 셀프 호스팅 가이드에 따르면 조직은 AI 인프라를 완전히 통제하기 위해 자체 게이트웨이와 모델을 운영할 수 있습니다. 완전 셀프 호스팅 구성은 일반 인터넷 접속이 제한적이거나 전혀 없는 네트워크에서도 운영할 수 있습니다.

CVE-2026-90970은 그 선택의 다른 측면을 드러냅니다. 고객은 배치 위치와 데이터 흐름을 통제하지만, 배포된 게이트웨이의 유지보수 책임도 집니다. GitLab은 고객이 통제하는 환경 내부에서 실행되는 컨테이너를 임의로 업데이트할 수 없습니다.

AI 게이트웨이는 더 익숙한 개발 인프라와 나란히 배치되기 때문에 이 책임의 주체가 불분명해질 수 있습니다. 플랫폼 팀이 GitLab 애플리케이션을 관리하는 한편, 머신러닝 팀은 모델 서버를 유지보수할 수 있습니다. 별도의 그룹이 컨테이너 플랫폼이나 네트워크 제어를 담당할 수도 있습니다.

어느 팀도 게이트웨이 이미지를 명시적으로 소유하지 않으면, 패치 상태는 이러한 경계 사이에서 누락될 수 있습니다. 관리형 게이트웨이는 공급업체가 배포를 통제하므로 이러한 특정 조정 문제를 피할 수 있습니다. 셀프 호스팅에는 게이트웨이를 별도의 프로덕션 서비스로 취급하는 내부 프로세스가 필요합니다.

첫 번째 핵심 지점은 인벤토리입니다. 조직은 GitLab의 관리형 게이트웨이, 셀프 호스팅 게이트웨이 또는 하이브리드 구성을 사용하는지 파악해야 합니다. 하이브리드 배포에서는 일부 요청은 고객 인프라를 사용하고 다른 요청은 GitLab 관리형 서비스를 사용할 수 있으므로 기능 수준의 이해가 필요합니다.

두 번째 핵심 지점은 버전 파악입니다. 운영자는 개념 검증 시스템과 분리된 환경을 포함하여 모든 셀프 호스팅 게이트웨이 인스턴스를 식별해야 합니다. 격리된 배포라도 직접적인 인터넷 트래픽을 받을 수 없을 뿐, 인증된 내부자나 탈취된 ID에 대해서는 여전히 취약할 수 있습니다.

세 번째 핵심 지점은 패치입니다. 영향을 받는 설치 환경에는 눈에 보이는 GitLab 애플리케이션의 업데이트만이 아니라 수정된 게이트웨이 버전이 필요합니다. 팀은 배포 증적을 보존하고, 이전 이미지 다이제스트를 기록하며, 워크로드가 의도한 버전으로 재시작되었는지 확인해야 합니다.

네 번째 핵심 지점은 노출 분석입니다. 관리자는 취약 기간 동안 Duo Agent Platform에 접근할 수 있었던 사용자와 서비스 계정을 식별해야 합니다. 또한 누가 플로를 생성하거나 수정할 수 있었는지, 그리고 그러한 작업이 활용 가능한 감사 기록을 남겼는지도 판단해야 합니다.

다섯 번째는 런타임 검토입니다. 패치 후 조사에서는 게이트웨이 프로세스 동작을 정상 기준선과 비교해야 합니다. 예상치 못한 하위 프로세스, 명령 인터프리터, 파일 변경, 새로운 아웃바운드 연결 또는 비정상적인 컨테이너 재시작은 조사할 가치가 있습니다.

시크릿에는 특별한 주의가 필요합니다. GitLab의 설치 문서는 게이트웨이가 서명된 JSON Web Tokens를 사용해 요청을 인증한다고 설명합니다. 셀프 호스팅 서비스는 런타임 환경을 통해 구성 값과 키도 전달받습니다. 이러한 메커니즘은 정상 운영에 필요하지만, 침해된 프로세스가 접근할 수 있는 모든 자격 증명은 교체가 필요할 수 있습니다.

설치 가이드는 AI Gateway와 Duo Agent Platform을 별도 서명 키 쌍을 사용하는 별개의 서비스로도 설명합니다. 이러한 분리는 방어자에게 유용한 검토 프레임워크를 제공합니다. 두 서비스, 그 신뢰 관계, 그리고 그 사이에서 사용되는 자격 증명을 모두 평가해야 합니다.

네트워크 설계는 결과를 크게 바꿀 수 있습니다. 모델 서버와 좁게 정의된 GitLab 엔드포인트에만 연결할 수 있는 게이트웨이는 내부 네트워크 전반에 광범위하게 접근할 수 있는 게이트웨이보다 공격 기회가 적습니다. 이그레스 제한, 워크로드 ID, 읽기 전용 파일 시스템, 최소한의 컨테이너 권한은 여전히 의미 있는 통제 수단입니다.

그러나 네트워크 격리는 패치를 대체하기보다 보완해야 합니다. 취약한 내부 서비스는 또 다른 침해된 내부 계정이나 워크로드로부터 공격받을 수 있습니다. 세분화는 이동과 데이터 접근을 제한하지만, 안전하지 않은 템플릿 처리를 수정하지는 않습니다.

운영자는 게이트웨이를 통과하는 데이터도 고려해야 합니다. 셀프 호스팅은 프롬프트에 독점 소스 코드, 이슈 맥락 또는 내부 지침이 포함될 수 있기 때문에 선택되는 경우가 많습니다. 악용이 발생했다면 조사관은 게이트웨이 컨테이너 내부에 어떤 파일이 있었는지만이 아니라, 게이트웨이가 어떤 정보에 접근할 수 있었는지를 파악해야 합니다.

이 작업은 CI 러너, 아티팩트 리포지토리 및 시크릿 관리자를 보호하는 것과 같은 운영 범주에 속합니다. 이 모든 서비스는 개발자가 제어하는 입력을 자동화된 작업으로 변환합니다. 그 유용성은 권한 있는 연결성에서 비롯되며, 이는 격리와 업데이트 주기가 중요한 이유이기도 합니다.

교훈은 관리형 AI 인프라가 언제나 더 안전하다는 것이 아닙니다. 관리형 서비스는 공급업체의 책임을 집중시키고 고객의 패치 작업을 줄이지만, 고객은 서로 다른 신뢰, 데이터 상주 및 종속성 관련 절충안을 받아들입니다. 교훈은 치명적인 게이트웨이 결함이 나타날 때 셀프 호스팅이 누가 대응해야 하는지를 바꾼다는 점입니다.

이전의 9.9 취약점은 이것이 일회성 패치 이상의 문제임을 보여준다

CVE-2026-90970은 2026년에 공개 문서화된 두 번째 9.9 등급 GitLab AI Gateway 템플릿 이슈로, 아키텍처 검토의 필요성을 더욱 뒷받침합니다.

2026년 2월, GitLab은 AI Gateway의 Duo Workflow Service 구성 요소에서 CVE-2026-1868을 해결했습니다. GitLab의 공개 CVE 할당 기록은 조작된 Duo Agent Platform 플로 정의를 통해 사용자 제공 데이터가 안전하지 않게 템플릿 확장되는 문제를 설명합니다.

이전 취약점은 동일한 CVSS 3.1 벡터와 9.9 심각도 점수를 받았습니다. 수정된 릴리스에는 AI Gateway 버전 18.6.2, 18.7.1 및 18.8.1이 포함되었습니다. GitLab은 내부 팀 구성원이 해당 결함을 발견한 것으로 공로를 인정했습니다.

현재 기록에 따르면 새 취약점은 버전 18.1.6부터 시작해 19.4 계열까지 이어지는 이후 릴리스 라인에 영향을 미칩니다. 두 이슈의 공개 설명에는 모두 조작된 플로 정의 또는 구성, 템플릿 처리, 낮은 권한의 인증된 접근, 그리고 명령 실행 가능성이 포함됩니다.

그 유사성이 패치가 같은 방식으로 실패했다는 증거는 아닙니다. 공개 취약점 요약은 CVE-2026-90970이 회귀인지, 이전 수정의 불완전성인지, 아니면 별개의 안전하지 않은 템플릿 경로인지 판단하기에는 지나치게 제한적입니다. 이러한 가능성을 확정된 사실로 취급하면 증거를 과장하게 됩니다.

그럼에도 방어자는 10월 공개를 고립해서 평가해서는 안 됩니다. 동일한 광범위한 신뢰 경계 주변에서 발생한 두 건의 치명적 발견은 플로 구성 처리가 더 심층적인 테스트를 받아야 함을 시사합니다. 한 줄짜리 버전 업그레이드는 공개된 경로를 차단할 수 있지만, 더 광범위한 설계상의 질문을 해결하지 못할 수 있습니다.

이 이야기의 주요 대립은 플랫폼의 거버넌스 약속과 실행 가능한 구성 표면이라는 현실 사이에 있습니다. GitLab은 에이전트 기반 플로를 확립된 개발 프로세스 내에서 작동하는 통제된 자동화로 제시합니다. 권한을 가진 플로 작성자가 게이트웨이 수준의 명령으로 넘어갈 수 있다면 이러한 통제의 가치는 사라집니다.

이 문제는 GitLab의 제품 범주에만 국한되지 않습니다. AI 게이트웨이, 에이전트 오케스트레이터 및 워크플로 엔진은 모두 유연한 사용자 입력을 권한 있는 작업으로 변환합니다. 제품 인터페이스가 이를 선언형 파일로 제시하더라도, 구성 형식은 프로그래밍 언어가 될 수 있습니다.

이러한 유연성은 반복되는 보안 절충안을 만듭니다. 고객은 리포지토리를 검사하고, 도구를 호출하며, 이벤트에 대응하고, 여러 단계의 목표를 완료할 수 있는 맞춤형 에이전트를 원합니다. 새로운 도구, 표현식, 템플릿 변수 또는 플러그인이 추가될 때마다 오케스트레이션 계층이 안전하게 해석해야 하는 범위가 확대됩니다.

엄격한 구성 언어는 위험을 줄일 수 있지만 고객 맞춤화를 제한합니다. 유연한 언어는 더 많은 워크플로를 지원하지만, 성숙한 샌드박싱, 파서 제어, 권한 경계 및 보안 테스트가 필요합니다. 하나의 프로세스가 신뢰할 수 없는 템플릿을 렌더링하면서 가치 있는 인프라 접근 권한까지 보유할 때 위험은 증가합니다.

따라서 방어에는 여러 독립적인 계층이 필요합니다. 파서는 신뢰할 수 없는 값을 데이터로 취급해야 합니다. 템플릿 환경은 가능한 한 최소의 객체 집합만 노출해야 합니다. 권한 부여는 플로를 제출할 수 있는 주체를 제한해야 합니다. 게이트웨이 런타임은 최소한의 파일 시스템, 네트워크 및 자격 증명 접근 권한만 가져야 합니다.

감사 가능성은 또 다른 계층을 제공합니다. 플로 생성 및 수정 이벤트는 특정 인간 또는 서비스 ID에 귀속될 수 있어야 합니다. 조직은 제출된 구성과 이후의 게이트웨이 활동을 연결할 수 있어야 합니다. 이러한 연결 고리가 없으면 악용을 확인하거나 배제하기가 훨씬 어려워집니다.

이전 취약점은 팀이 업그레이드 검증을 처리하는 방식도 바꿉니다. 최신 수정 이미지가 성공적으로 시작되었음을 확인하는 것만으로는 충분하지 않습니다. 운영자는 이전 레플리카, 캐시된 이미지, 테스트 클러스터 및 재해 복구 환경에 영향을 받는 버전이 남아 있지 않은지 확인해야 합니다.

분리된 환경은 특히 오해를 부를 수 있습니다. 일반 인터넷 접속의 부재는 일부 외부 위협을 줄이지만, 보안 공지와 패치의 전달을 지연시킬 수 있습니다. 해당 환경 내부의 권한 있는 사용자는 여전히 취약점이 요구하는 애플리케이션 기능에 접근할 수 있습니다.

회의적인 평가는 여전히 알려지지 않은 사항도 인정해야 합니다. 공개 기록은 아직 개념 증명, 상세 호출 경로 또는 확인된 악용 텔레메트리를 제공하지 않습니다. 또한 모든 배포에 적용되는 보편적인 악용 후 지표 집합도 식별하지 않습니다.

이러한 공백은 관찰된 공격에 대한 확신 있는 주장을 제한하지만, 패치 권고를 약화하지는 않습니다. 공급업체가 확인한 9.9 점수의 명령 실행 취약점은 즉각적인 완화를 정당화하기에 충분한 위험을 제시합니다. 공개 악용 증거를 기다리는 것은 불확실성을 예방 가능한 노출과 맞바꾸는 일이 됩니다.

더 강력한 장기적 질문은 현재의 신뢰 맥락에서 템플릿 처리가 계속 필요한지입니다. GitLab은 고객이 패치할 시간을 가진 뒤 더 많은 기술적 세부 사항을 공개함으로써 향후 위험을 줄일 수 있습니다. 근본 원인 정보는 운영자가 어떤 경계가 실패했는지, 어떤 보완 통제가 가장 중요한지를 이해하는 데 도움이 됩니다.

한편 고객은 맞춤형 에이전트 플로를 코드로 취급해야 합니다. 이는 CI 구성에 준하는 검토, 소유권, 변경 통제 및 테스트를 받을 가치가 있습니다. 플랫폼이 그 내용을 작업으로 전환한다면, 시각적 또는 선언형 인터페이스가 워크플로를 비실행형으로 만들지는 않습니다.

방어자가 다음으로 주시해야 할 사항

다음 평가는 세 가지 신호, 즉 패치 도입률, GitLab의 근본 원인 공개, 실제 악용 관련 증거에 따라 달라져야 합니다.

첫 번째 신호는 셀프 호스팅 운영자가 수정된 AI Gateway 버전에 얼마나 신속하게 도달하는지입니다. GitLab은 호스팅 서비스를 통제하지만, 사설 인프라 내부의 모든 고객 배포를 측정할 수는 없습니다. 보안 팀은 일반적인 소프트웨어 업데이트 보고에 게이트웨이가 포함된다고 가정하지 말고 자체적인 완료 증적을 수립해야 합니다.

그 증적에는 배포 환경, 이전 버전, 교체 이미지, 재시작 시간 및 검증 결과가 포함되어야 합니다. 또한 개발 및 재해 복구 시스템도 포함해야 합니다. 조직이 이 인벤토리를 마련하는 데 어려움을 겪는다면, 이 사고는 취약점 자체를 넘어선 소유권 문제를 드러냅니다.

신속한 패치 도입은 기업이 셀프 호스팅 AI 구성 요소를 일반적인 프로덕션 인프라로 관리할 수 있다는 주장을 강화할 것입니다. 느리거나 측정되지 않은 도입은 비공개 배포를 뒷받침하는 통제 논리를 약화할 것입니다. 핵심 미들웨어가 추적되지 않는다면 데이터 지역성은 제한적인 보호만 제공합니다.

두 번째 신호는 GitLab의 더 충실한 기술 설명입니다. 방어자는 CVE-2026-90970이 새로운 템플릿 경로인지, 회귀인지, 또는 이전 결함에 대한 불완전한 완화 조치인지 알아야 합니다. 이 구분은 주변 아키텍처와 테스트 전략에 대한 신뢰도에 영향을 줍니다.

유용한 공개문은 불필요한 익스플로잇 세부 정보를 제공하지 않으면서 취약한 구성 요소, 영향을 받는 권한 경계, 그리고 격리 변경 사항을 설명해야 합니다. 또한 별도의 Agent Platform 및 AI Gateway 서비스에 서로 다른 사고 후 조치가 필요한지도 명확히 해야 합니다.

서로 다른 근본 원인이 확인된다면 광범위한 템플릿 강화가 여러 발견 사례를 통해 효과를 내고 있음을 시사할 수 있습니다. 이전 완화 조치를 우회한 증거가 나온다면, 초기 보안 경계가 포괄적으로 설계되었는지에 관한 더 날카로운 질문이 제기될 것입니다.

세 번째 신호는 악용에 관한 신뢰할 수 있는 증거입니다. GitLab과 보안 기관에서 침해 지표, 알려진 악용 취약점 목록, 또는 수정된 대응 지침이 나오는지 주시해야 합니다. 검증 가능한 텔레메트리를 포함한다면 독립적인 사고 보고서도 중요합니다.

그러한 증거가 나타나기 전까지는 CVE-2026-90970이 실제로 악용되고 있다고 기사에서 서술해서는 안 됩니다. 공개 확인이 없다는 것은 악용이 발생하지 않았다는 확인과는 다릅니다. 조직은 헤드라인만이 아니라 노출 범위와 영향도를 바탕으로 대응 결정을 내려야 합니다.

팀은 네 가지 실질적인 질문부터 시작할 수 있습니다. 자체 호스팅 AI Gateway를 운영하고 있는가? 모든 인스턴스가 19.2.4, 19.3.2, 19.4.1 또는 그 이후 버전을 실행하고 있는가? 영향을 받은 기간 동안 누가 Duo 에이전트 플로우를 수정할 수 있었는가? 게이트웨이 프로세스는 어떤 시스템과 시크릿에 접근할 수 있었는가?

답변은 사고 기록, 구성 이력, 관련 로그와 함께 보존해야 합니다. 배포 메모, 소유권 결정, 검토 증거를 연결해야 하는 팀은 검색 가능한 지식 기반을 유지할 수 있습니다. 문서화만으로 취약점이 해결되지는 않지만, 분산된 증거는 격리 조치와 이후 감사 업무를 지연시킬 수 있습니다.

GitLab AI Gateway 취약점은 결국 에이전트 인프라가 CI 시스템 및 기타 코드 실행 서비스와 동일한 수준의 운영 규율을 적용받는지를 시험합니다. 영향을 받은 게이트웨이에 패치를 적용하고, 실행 중인 이미지를 검증하며, 승인된 플로우 변경 사항을 검토하고, 증거가 이를 뒷받침할 경우 노출된 자격 증명을 교체하며, 게이트웨이의 권한을 축소해야 합니다.

그다음에는 더 어려운 질문을 던져야 합니다. 다음 달 다른 에이전트 구성이 신뢰 경계를 넘는다면, 팀은 사고 중에 인벤토리를 다시 구축하지 않고도 담당자, 영향받는 버전, 접근 가능한 자산, 대응 경로를 파악할 수 있을까요?