GitLab AI Gateway 취약점, 샌드박스 우회 및 명령 실행 가능

연구자들이 임의 명령 실행으로 이어지는 경로를 발견한 후 GitLab은 10점 만점에 9.9점으로 평가된 GitLab AI Gateway 취약점을 패치했습니다. 이 결함은 자체 호스팅 게이트웨이에 영향을 미치며 GitLab Duo Agent Platform에 접근할 수 있는 인증된 사용자가 필요합니다. 특별히 조작된 custom flow는 프롬프트 템플릿 샌드박스를 벗어나 게이트웨이 프로세스의 권한으로 명령을 실행할 수 있습니다.

이번 사건은 모든 GitLab 배포에 영향을 주는 원격 악용 가능 결함보다 범위가 좁습니다. GitLab 호스팅 게이트웨이는 회사가 패치했으며, 해당 서비스를 사용하는 고객은 게이트웨이를 직접 업데이트할 필요가 없습니다. 자체 호스팅 AI Gateway를 운영하는 조직에는 즉각적인 책임이 있습니다.

이 구분은 핵심적인 긴장을 만듭니다. 자체 호스팅은 조직에 AI 처리, 인프라 및 데이터 경로에 대한 더 큰 통제권을 제공합니다. 동시에 패치, 모니터링 및 격리 의무를 고객에게 이전합니다. 이 경우 신뢰할 수 있는 환경 내부에 배치된 구성 요소가 명령 실행의 표적이 되었습니다.

이 취약점은 CVE-2026-90970으로 추적됩니다. GitLab은 2026년 10월 2일 AI Gateway 버전 19.2.4, 19.3.2 및 19.4.1을 출시했습니다. 회사는 영향을 받는 운영자에게 즉시 업데이트할 것을 촉구했지만, 공개 권고문에는 우회 방법이나 세부적인 침해 탐지 지침이 포함되지 않았습니다.

GitLab AI Gateway 취약점은 즉각적인 업데이트가 필요합니다

긴급한 사실은 간단합니다. 영향을 받는 자체 호스팅 게이트웨이에는 단순히 GitLab 애플리케이션을 업데이트하는 것이 아니라 패치된 AI Gateway 버전이 필요합니다.

GitLab의 중요 패치 권고문은 수정된 세 가지 버전인 19.2.4, 19.3.2 및 19.4.1을 명시합니다. 관련 버전 번호는 AI Gateway 구성 요소에 속합니다. 연결된 GitLab 인스턴스의 버전과 혼동해서는 안 됩니다.

영향 범위는 AI Gateway 18.1.6부터 시작합니다. 여기에는 19.2.4 이전 버전, 19.3.2 이전의 19.3 버전, 그리고 19.4.1 이전의 19.4 버전이 포함됩니다. 이전 지원 브랜치를 실행하는 조직은 적절한 패치 릴리스를 선택해야 합니다.

18.x 및 19.1 계열 설치 환경에서는 표현 방식도 중요합니다. GitLab은 10월 권고문에서 19.2.4보다 낮은 수정 게이트웨이 릴리스를 나열하지 않았습니다. 해당 계열의 운영자는 이전 브랜치에 그대로 머무는 것이 보호를 제공한다고 가정해서는 안 됩니다.

자체 호스팅 AI Gateway는 일반적으로 컨테이너 또는 Helm 배포를 통해 별도 서비스로 실행됩니다. 기본 GitLab 애플리케이션을 업데이트했다고 해서 게이트웨이 이미지가 교체되었다는 사실이 자동으로 증명되지는 않습니다. 관리자는 게이트웨이 배포 자체를 검사하고 실행 중인 이미지 태그를 확인해야 합니다.

GitLab은 권고문을 게시하기 전에 자체 호스팅 게이트웨이 고객에게 연락했다고 밝혔습니다. 또한 수정 사항이 이미 GitLab 호스팅 게이트웨이에 적용되었다고 말했습니다. 이에 따라 GitLab.com, GitLab Dedicated 및 GitLab 호스팅 게이트웨이에 연결된 자체 관리 인스턴스가 보호됩니다.

이 범위 때문에 자산 식별이 첫 번째 운영 과제가 됩니다. 보안 팀은 조직이 GitLab Duo를 사용한다는 사실은 알고 있을 수 있지만, 어떤 게이트웨이 모델이 이를 지원하는지는 모를 수 있습니다. 이 서비스는 GitLab이 운영할 수도 있고 고객 환경 내에 배포될 수도 있습니다.

팀은 배포 기록, 컨테이너 인벤토리, Helm 릴리스 및 GitLab Duo 구성을 통해 이 구분을 확인해야 합니다. GitLab 제품명만으로 게이트웨이 소유권을 추론해서는 안 됩니다. 자체 관리 GitLab 인스턴스도 GitLab 호스팅 게이트웨이를 사용할 수 있습니다.

CVE 레코드는 이 취약점의 CVSS 3.1 벡터에서 기밀성, 무결성 및 가용성 영향을 모두 최대로 부여합니다. 점수가 10점이 아닌 9.9점인 이유는 악용에 낮은 권한이 필요하기 때문입니다. 사용자 상호작용은 필요하지 않으며, 취약한 서비스는 네트워크를 통해 접근할 수 있습니다.

낮은 권한이 익명 접근을 의미하지는 않습니다. GitLab은 공격자가 인증을 받고 Duo Agent Platform 접근 권한을 보유해야 한다고 밝혔습니다. 이 요구 사항은 초기 공격자 집단을 좁히지만, 탈취된 계정과 잠재적으로 악의적인 내부자는 포함됩니다.

이 결함은 초기 접근 이후 보안 경계를 넘습니다. AI flow 작업 권한이 있는 사용자가 게이트웨이에서 운영체제 명령을 실행할 권한까지 얻어서는 안 됩니다. 이 취약점은 애플리케이션 수준의 접근을 더욱 민감한 실행 환경에 대한 제어로 전환합니다.

운영자는 업데이트를 독립적인 증거가 필요한 별도의 변경으로 취급해야 합니다. GitLab 변경 티켓이 완료되었다고 해서 AI Gateway가 안전하다는 사실이 입증되지는 않습니다. 올바른 증거는 실행 중인 게이트웨이 버전과 모든 복제본에 걸친 검증된 롤아웃입니다.

이 검증에는 개발, 스테이징, 재해 복구 및 일시적으로 축소된 환경이 포함되어야 합니다. 네트워크 연결 또는 자격 증명을 유지하는 잊힌 게이트웨이 인스턴스도 여전히 중요합니다. 비활성 인터페이스가 접근 불가능한 서비스를 보장하지는 않습니다.

Custom Flow가 템플릿 데이터를 실행 가능한 동작으로 전환했습니다

핵심 실패는 AI 모델이 위험한 명령을 작성했다는 점이 아닙니다. 템플릿 경계가 조작된 데이터가 실행 가능한 애플리케이션 동작에 도달하도록 허용했다는 점입니다.

GitLab은 이 문제를 custom flow 프롬프트 템플릿의 부적절한 무력화로 설명합니다. custom flow는 Duo Agent Platform 내에서 구성 가능한 다단계 AI 워크플로입니다. YAML 정의에서 프롬프트, 구성 요소, 라우팅 결정 및 도구를 결합할 수 있습니다.

회사의 custom flow 문서는 이러한 정의가 일반적인 프롬프트 텍스트 이상인 이유를 보여 줍니다. Flow는 생성, 테스트, 게시, 프로젝트용 활성화 및 GitLab 활동을 통한 트리거가 가능합니다. 이들은 에이전트 주변의 애플리케이션 구성으로 작동합니다.

취약한 경로에는 프롬프트 템플릿 샌드박스가 포함됐습니다. 샌드박스는 템플릿이 안전하지 않은 속성이나 함수에 도달하지 못하도록 설계된 제한적 실행 환경입니다. CVE-2026-90970은 조작된 flow 구성이 이러한 제한을 벗어날 수 있도록 했습니다.

공개 GitLab 공개 티켓은 이 문제의 원인으로 Jinja2 템플릿 렌더링 중 안전하지 않은 메서드 접근을 지목합니다. Jinja2는 텍스트를 변수 및 표현식과 결합하는 Python 템플릿 엔진입니다.

티켓에 따르면 대화 기록에는 LangChain HumanMessage 객체가 포함되어 있었습니다. 템플릿은 해당 객체의 공개 역직렬화 메서드를 호출할 수 있었습니다. 이후 안전하지 않은 직렬화 페이로드가 역직렬화 과정에서 Python이 운영체제 명령을 실행하게 했습니다.

역직렬화는 저장되거나 전송된 데이터를 다시 프로그램 객체로 변환합니다. 선택된 형식이 해당 객체를 재구성하는 동안 코드를 호출할 수 있으면 위험해집니다. 신뢰할 수 없는 pickle 콘텐츠를 로드하는 것은 안전하지 않기 때문에 Python pickle 데이터가 잘 알려진 예입니다.

보고된 개념 증명은 2단계 flow를 사용했습니다. 첫 번째 모델 상호작용이 대화 기록을 채웠습니다. 이후 템플릿 평가가 그 기록 객체에 접근해 위험한 역직렬화 경로를 트리거했습니다.

이 순서는 이 문제가 기본적인 셸 인젝션 버그와 다르다는 점을 보여 줍니다. 악성 값은 셸로 전달되는 직접 명령 매개변수로 나타날 필요가 없었습니다. 대신 개별적으로는 의미 있는 여러 기능이 실행 체인을 형성했습니다.

Flow는 구성 가능한 프롬프트 콘텐츠를 허용했습니다. 템플릿 엔진은 애플리케이션 객체를 받았습니다. 한 객체는 역직렬화 메서드를 노출했습니다. 허용된 직렬화 형식은 코드를 호출할 수 있었습니다. 이러한 조건이 결합되어 의도된 샌드박스를 무력화했습니다.

모델 자체는 신뢰할 수 있는 보안 경계가 아니었습니다. 모델은 상태 간 flow 진행을 도왔지만, 명령은 결정론적인 애플리케이션 동작을 통해 실행되었습니다. 모델 출력만 필터링해서는 취약한 객체와 템플릿 간의 관계를 해결할 수 없습니다.

이 구분은 조직이 AI 보안 실패를 분류할 때 중요합니다. 프롬프트 인젝션은 지시문을 통해 모델을 조작하려는 시도를 설명합니다. CVE-2026-90970은 프롬프트 템플릿이 진입점을 제공하더라도 모델 주변 시스템의 소프트웨어 취약점입니다.

따라서 전통적인 애플리케이션 보안 관행은 여전히 필수적입니다. 템플릿 입력에는 엄격한 검증이 필요하고, 노출된 객체에는 최소한의 인터페이스가 필요하며, 위험한 역직렬화 형식은 공격자가 제어하는 데이터를 처리해서는 안 됩니다. 샌드박스 역시 내부에서 사용 가능하게 만든 정확한 객체를 대상으로 테스트해야 합니다.

보고된 명령은 Duo Workflow Service 프로세스의 권한으로 실행되었습니다. 이는 즉각적인 운영체제 권한을 서비스 계정의 권한으로 제한합니다. 그러나 게이트웨이는 민감한 연결을 처리하고 신뢰할 수 있는 인프라 내부에 위치하므로 서비스 수준의 실행은 여전히 심각합니다.

실질적인 영향은 배포 아키텍처에 따라 달라집니다. 네트워킹이 제한된 최소 권한 컨테이너는 광범위하게 연결된 서비스보다 후속 침투 경로가 적습니다. 어느 구성도 패치의 필요성을 없애지는 않습니다. 공격자는 여전히 의도하지 않은 코드 실행 권한을 얻게 되기 때문입니다.

이 메커니즘은 거의 최고 수준의 심각도를 설명합니다. 공격자는 인증된 Duo 지원 ID로 시작하지만, 그 결과 실행은 게이트웨이의 보안 컨텍스트로 넘어갑니다. 이러한 범위 변화가 9.9점 평가의 핵심입니다.

자체 호스팅은 통제권과 보안 책임을 함께 이전합니다

이번 사건은 자체 호스팅 AI 인프라의 상충 관계를 드러냅니다. 처리를 가까이 유지하는 것은 게이트웨이도 고객의 운영 신뢰 경계 안에 배치한다는 의미입니다.

GitLab은 AI Gateway를 GitLab Duo 기능과 AI 모델을 연결하는 독립형 서비스로 설명합니다. 고객은 GitLab의 관리형 게이트웨이를 사용하거나 GitLab Duo Self-Hosted와 함께 자체 게이트웨이를 운영할 수 있습니다.

조직은 데이터 이동, 모델 접근, 네트워크 경로 및 인프라 정책을 통제하기 위해 자체 호스팅을 선택하는 경우가 많습니다. 이러한 이점은 규제 환경이나 엄격한 내부 통제가 필요한 배포에서 중요할 수 있습니다. 동시에 고객이 인벤토리화하고 유지해야 하는 또 하나의 프로덕션 서비스를 만듭니다.

GitLab AI Gateway 취약점은 이 운영 세부 사항을 주요 보안 문제로 전환합니다. GitLab은 자신이 관리하는 게이트웨이에 직접 수정 사항을 배포할 수 있었습니다. 자체 호스팅 고객은 자신의 업그레이드를 일정에 맞춰 수행하고 검증해야 합니다.

이 패턴은 데이터베이스, ID 서비스 및 CI 러너에서 익숙합니다. 차이는 AI 게이트웨이가 한때 더 명확히 분리되어 있던 시스템들을 연결한다는 점입니다. 이들은 사용자, 소스 리포지토리, 에이전트 워크플로, 모델 제공업체, 그리고 때로는 실행 도구 사이에 위치합니다.

따라서 침해된 게이트웨이는 고립된 챗봇 인터페이스보다 더 큰 주의를 받아야 합니다. 구성에 따라 프롬프트 콘텐츠, 워크플로 상태, 서비스 자격 증명, 제공업체 연결 또는 내부 개발 활동에 관한 메타데이터를 접할 수 있습니다.

그렇다고 CVE-2026-90970이 연결된 모든 비밀 정보를 노출했다는 뜻은 아닙니다. GitLab의 권고문은 확인된 데이터 탈취나 완전한 침해 후 경로를 보고하지 않습니다. 올바른 결론은 임의 명령 실행이 추가 접근으로 이어질 수 있는 신뢰할 만한 경로를 만든다는 것입니다.

팀은 게이트웨이를 권한이 높은 통합 서비스로 평가해야 합니다. 프로세스 ID, 마운트된 파일, 환경 변수, 네트워크 경로 및 연결된 서비스 계정이 피해 범위를 결정합니다. 이러한 통제는 패치 전 노출을 재구성할 때 중요해집니다.

컨테이너화는 경계를 의도적으로 구성할 때에만 도움이 된다. 컨테이너는 여전히 네트워크 서비스에 접근하고, 마운트된 시크릿을 읽거나 데이터를 외부로 전송할 수 있다. 실질적인 보안 수준은 런타임 권한과 주변 정책에 달려 있다.

GitLab의 설치 가이드는 AI Gateway 컨테이너의 아웃바운드 네트워크 접근을 제한할 것을 권장한다. 이그레스 제어는 침해된 프로세스가 접촉할 수 있는 대상지를 제한한다. 명령 실행의 활용 가능성을 줄일 수는 있지만, 로컬 영향까지 제거하지는 않는다.

네트워크 세분화는 또 다른 격리 계층을 제공한다. 게이트웨이에는 정의된 GitLab 및 모델 엔드포인트에 대한 접근이 필요하지만, 내부 네트워크 전체에 대한 무제한 접근이 필요한 경우는 드물다. 좁은 허용 목록은 예상치 못한 수평 이동을 더 어렵게 만든다.

자격 증명 설계도 그만큼 중요하다. 환경에 직접 저장된 장기 시크릿은 침해 이후 매력적인 표적이 된다. 단기 자격 증명, 격리된 서비스 계정, 최소 범위 권한은 서비스 침해 이후의 피해를 줄일 수 있다.

보안팀은 누가 사용자 지정 플로우를 생성하거나 수정할 수 있는지도 검토해야 한다. GitLab 문서는 여러 워크플로에서 플로우 관리 작업을 Maintainer나 Owner 같은 역할에 할당한다. 정확한 노출 범위는 여전히 제품 구성과 영향을 받는 구현에 따라 달라진다.

이 권고문은 보편적으로 필요한 하나의 프로젝트 역할을 명시하는 대신 “Duo Agent Platform access”라는 더 넓은 표현을 사용한다. 관리자는 문서 예시를 결정적인 익스플로잇 전제 조건으로 바꿔 해석해서는 안 된다. 실제 권한과 과거 플로우 변경 내역을 검토해야 한다.

자체 호스팅은 여전히 유효한 아키텍처 선택지다. 교훈은 관리형 서비스가 항상 더 안전하다는 것이 아니다. 데이터 통제, 소프트웨어 통제, 사고 대응 책임은 함께 따라온다는 점이다.

관리형 게이트웨이는 공급업체 운영에 대한 신뢰를 집중시킨다. 자체 호스팅 게이트웨이는 고객의 패치, 격리, 모니터링에 대한 신뢰를 집중시킨다. CVE-2026-90970은 완화 경계가 호스팅 경계를 정확히 따른다는 점에서 이러한 교환 관계를 드러낸다.

엔터프라이즈 구매자에게 보안 검토는 제품 기능과 배포 소유권을 모두 다뤄야 한다. 데이터가 어디로 이동하는지에 관한 질문에는 각 구성 요소를 누가 패치하는지에 관한 질문이 뒤따라야 한다. 운영 소유권이 없는 아키텍처 다이어그램은 불완전하다.

패치는 결함을 막지만 탐지에 대한 질문은 남긴다

업데이트는 알려진 취약 경로를 차단하지만, 공개 권고문은 이전 침해가 전혀 없었다는 사실을 운영자가 어떻게 입증해야 하는지는 알려주지 않는다.

10월 4일 기준, GitLab은 CVE-2026-90970이 실제 환경에서 악용되고 있다고 공개적으로 밝히지 않았다. 이는 안심할 만한 요소지만, 영향을 받은 모든 배포가 손대지 않은 상태였다는 증거는 아니다.

공개된 기술 세부 정보는 신속한 패치의 중요성을 높인다. 공개 티켓은 취약한 객체 관계를 설명하고 스테이징 환경에서 명령 실행에 성공했다고 보고한다. 방어자와 공격자는 모두 이 자료를 연구할 수 있다.

GitLab은 invisiblemeerkat으로 알려진 HackerOne 연구자에게 책임 있는 공개에 대한 공로를 돌렸다. 책임 있는 보고는 GitLab이 수정 사항을 준비하고 영향을 받은 고객에게 연락할 시간을 제공했다. 하지만 공개 이후에도 패치되지 않은 배포의 노출 기간을 없애지는 못했다.

인증 요구 사항은 위협 헌팅의 방향을 정해야 한다. 보안팀은 Duo Agent Platform ID, 플로우 관리 이벤트, 사용자 지정 플로우 정의 변경부터 확인해야 한다. 이러한 기록을 취약 기간 중 게이트웨이 활동과 연관 분석해야 한다.

특히 대화 기록 객체에 접근하거나 메서드를 호출하는 템플릿 등 비정상적인 플로우 구성은 검토가 필요하다. 예상치 못한 플로우 생성, 편집, 게시 또는 실행은 추가적인 맥락을 제공할 수 있다. 정상적으로 보이는 플로우 이름이 의심스러운 템플릿 동작을 덮어서는 안 된다.

게이트웨이 프로세스 활동도 중요하다. 자식 프로세스, 셸 호출, 예상치 못한 바이너리, 비정상적인 파일 접근, 아웃바운드 연결은 명령 실행을 나타낼 수 있다. 유용한 데이터는 이미 활성화된 컨테이너, 호스트, 클라우드 텔레메트리에 따라 달라진다.

컨테이너 재시작은 로컬 증거를 지울 수 있다. 따라서 중앙화된 로그와 런타임 보안 텔레메트리는 현재 실행 중인 컨테이너만 검사하는 것보다 더 유용하다. 침해가 의심된다면 인프라를 교체하기 전에 이용 가능한 로그를 보존해야 한다.

운영자는 게이트웨이 프로세스가 접근할 수 있는 시크릿을 검토해야 한다. 교체 결정은 공포가 아니라 증거와 노출 수준을 따라야 한다. 로그가 명령 실행을 가리킨다면 읽을 수 있는 자격 증명이 접근되었을 수 있다고 가정해야 한다.

GitLab 및 모델 공급자에 대한 게이트웨이 연결도 별도로 주의해야 한다. 명령 실행 권한을 얻은 공격자는 토큰 재사용, 구성 검사 또는 연결된 서비스 접근을 시도할 수 있다. 공개 기록은 그러한 활동이 발생했다고 확인하지 않는다.

의심스러운 증거가 있다면 패치가 조사의 끝이 되어서는 안 된다. 업데이트는 알려진 코드 경로를 제거하지만, 탈취된 자격 증명을 폐기하거나 다른 곳에서 이루어진 변경을 되돌리지는 않는다. 사고 대응 절차는 여전히 필요하다.

주의해야 할 역사적 이유도 있다. 보안 보고에서는 같은 9.9 등급과 같은 CWE-1336 취약점 범주를 가진 이전 2026년 AI Gateway 이슈인 CVE-2026-1868을 식별했다. 이 결함 역시 조작된 플로우 콘텐츠와 가능한 코드 실행을 포함했다.

두 개의 고심각도 템플릿 엔진 이슈가 모든 사용자 지정 플로우가 안전하지 않다는 것을 증명하는 것은 아니다. 그러나 에이전트 시스템 내부에서 템플릿, 애플리케이션 객체, 직렬화가 어떻게 만나게 되는지 더 면밀히 검토할 근거는 된다.

이러한 반복은 보안 테스트가 고립된 구성 요소뿐 아니라 조합도 다뤄야 함을 시사한다. 샌드박스는 문자열에 대해서는 올바르게 동작하면서도 풍부한 프레임워크 객체가 컨텍스트에 들어오면 실패할 수 있다. 한 계층에서 안전한 메서드도 템플릿이 이를 호출할 수 있다면 위험해질 수 있다.

에이전트 플랫폼은 여러 유연한 메커니즘을 결합하기 때문에 이 문제를 심화한다. 프롬프트, 도구, 기록, 라우팅 로직, 모델 응답, 애플리케이션 API는 반복되는 단계 전반에서 상호작용한다. 한 단계에서 도입된 상태는 나중에 실행 가능한 입력이 될 수 있다.

조직은 배포 전 테스트에 적대적인 사용자 지정 플로우를 추가해야 한다. 테스트에는 메서드 접근, 객체 순회, 직렬화 경계, 다단계 상태 변경이 포함되어야 한다. 단일 패스 프롬프트 스캔으로는 보고된 익스플로잇 체인을 재현할 수 없다.

또한 템플릿을 코드에 준하는 아티팩트로 취급해야 한다. 검토, 소유권, 변경 이력, 배포 통제는 잠재적 영향에 맞춰야 한다. 파일을 “구성”이라고 부른다고 런타임 동작을 바꿀 수 있는 능력이 줄어들지는 않는다.

GitLab은 익스플로잇에 필요한 모든 조건을 공개적으로 상세히 설명하지 않았다. 이는 확신 있는 노출 평가를 제한한다. 팀은 공개된 전제 조건을 최소 조건으로 활용해야 하며, 명시되지 않은 조건이 안전을 보장한다고 가정해서는 안 된다.

대응이 효과적인지 보여줄 세 가지 신호

다음 단계는 패치 적용률, 실제 악용의 증거, 그리고 사용자 지정 플로우 격리에 대한 GitLab의 더 깊은 대응에 달려 있다.

첫 번째 신호는 19.2.4, 19.3.2, 19.4.1 또는 그 이후의 수정 버전을 실행하는 자체 호스팅 게이트웨이의 비율이다. 각 조직은 모든 환경과 복제본에서 이를 측정해야 한다. 이러한 배포는 고객 네트워크 내부에 있으므로 업계 전체 수치는 공개되지 않을 수 있다.

신속한 적용은 공개 이후 도달 가능한 공격 표면을 줄일 것이다. 느린 적용은 특히 AI 서비스가 기존 취약점 관리 인벤토리 밖에 있는 경우 위험을 연장할 것이다. 게이트웨이 소유권은 패치 대시보드에서 확인 가능해져야 한다.

두 번째 신호는 악용 상태의 변화다. GitLab, CISA, 사고 대응 기업, 영향을 받은 고객은 지표나 확인된 사례를 공개할 수 있다. 활성 악용 보고가 나오면 우선순위는 예방적 패치에서 더 폭넓은 사고 대응으로 전환될 것이다.

방어자는 공개된 개념 증명과 관찰된 공격을 구분해야 한다. 기술적 재현은 문서화된 조건에서 결함이 작동한다는 사실을 증명한다. 공격자가 운영 환경의 고객을 침해했다는 사실까지 입증하지는 않는다.

세 번째 신호는 AI Gateway의 구조적 보안 변화다. 좁은 범위의 패치는 공개된 메서드 호출을 차단할 수 있다. 더 광범위한 대응은 어떤 객체가 템플릿에 도달하는지 줄이고, 위험한 직렬화를 금지하거나, 사용자 지정 플로우 주변의 격리를 강화할 수 있다.

보고된 체인은 기능 조합에서 발생했기 때문에 이러한 설계 대응이 중요하다. 하나의 페이로드를 막는 것도 유용하지만, 안전하지 않은 기능 경계를 제거하는 것이 변형 공격에 대해 더 강한 보호를 제공한다.

GitLab의 향후 릴리스 노트와 코드 변경은 어느 계층이 수정되었는지 명확히 해야 한다. 관리자는 플로우 검증, 감사 이벤트, 탐지 쿼리, 이전 게이트웨이 브랜치에 지원되는 업그레이드 경로를 다루는 새로운 지침을 주시해야 한다.

엔터프라이즈 고객은 지금 이 사고를 활용해 자체 운영 모델을 점검할 수 있다. 중요한 질문은 소프트웨어 인벤토리에 GitLab이 있는지가 아니다. AI Gateway가 별도로 소유되고, 패치되고, 로깅되고, 격리된 서비스로 존재하는지다.

플로우를 만드는 개발자도 구성에 부여된 신뢰를 재고해야 한다. 사용자 지정 플로우는 여러 단계에 걸쳐 도구와 애플리케이션 데이터를 조율할 수 있다. 자동화 스크립트와 CI 정의에 적용하는 것과 같은 회의적인 시각을 적용해야 한다.

보안 검토자는 네 가지 경계를 매핑해야 한다. 누가 플로우를 작성할 수 있는지, 템플릿이 어떤 객체에 접근할 수 있는지, 플로우가 어떤 도구를 호출할 수 있는지, 게이트웨이 프로세스가 어떤 권한을 보유하는지다. 여러 경계에 걸친 약점은 제한적인 접근을 인프라 제어로 바꿀 수 있다.

GitLab Duo를 사용하는 지식 근로자가 이 권고문 때문에 일상 업무를 중단할 필요는 없다. 대부분은 게이트웨이 소유권을 직접 확인할 수 없다. 독립적인 테스트를 시도하기보다 조직의 지침을 따르고 예상치 못한 플로우 동작을 보고해야 한다.

관리자가 취해야 할 조치는 더 명확하다. 호스팅 모델을 식별하고, 실행 중인 게이트웨이 버전을 확인하며, 올바른 패치를 배포하고, 의심스러운 활동이 보이는 곳에서 증거를 보존해야 한다. 취약 기간 전반의 플로우 변경과 게이트웨이 텔레메트리를 검토해야 한다.

패치 후에는 그 결과를 지속 가능한 운영 기록에 문서화해야 한다. 이전 버전, 배포 시간, 영향을 받은 환경, 검증 방법, 위협 헌팅 결과를 기록한다. 이러한 증거는 향후 감사와 사고 재구성을 지원한다.

GitLab AI Gateway 취약점은 궁극적으로 AI 애플리케이션 로직이 전통적인 실행 가능 소프트웨어가 되는 지점에 대한 경고다. 실패는 프롬프트 템플릿에서 시작해 프레임워크 객체를 거쳐 운영체제 명령으로 끝났다.

“AI”라는 이름만큼이나 이 경로에 더 주목할 필요가 있다. 모델은 워크플로에 영향을 줄 수 있지만, 신뢰할 수 없는 입력이 코드가 되는지를 결정하는 것은 여전히 일반적인 소프트웨어 경계다. 조직에는 두 계층 모두를 둘러싼 통제가 필요하다.

조직에서 GitLab Duo를 운영한다면 오늘 한 가지 구체적인 질문을 해보라. 그러한 요청을 처리하는 게이트웨이는 누가 소유하는가? 답이 여러분의 팀이라면 GitLab의 수정 릴리스와 버전을 대조해 확인하라. 그런 다음 모니터링이 예상치 못한 명령, 변경된 플로우 또는 아웃바운드 연결을 드러낼 수 있는지 테스트하라. 패치는 공개된 GitLab AI Gateway 취약점을 막지만, 지속적인 안전은 다음 권고문 이후에도 남아 있는 인벤토리, 격리, 증거에 달려 있다.