Co znajdziesz w tym artykule?
Wprowadzenie do problemu / definicja
Amazon Q Developer to asystent programistyczny oparty na AI, zintegrowany z popularnymi środowiskami IDE i narzędziami deweloperskimi. Ujawniona w czerwcu 2026 roku podatność CVE-2026-12957 pokazała, że błędne założenia dotyczące zaufania do konfiguracji projektu mogą prowadzić do bardzo poważnych skutków bezpieczeństwa.
Luka dotyczyła mechanizmu MCP, który umożliwia agentowi AI uruchamianie lokalnych procesów oraz komunikację z narzędziami, API i innymi zasobami deweloperskimi. W praktyce oznaczało to, że odpowiednio przygotowane repozytorium mogło doprowadzić do uruchomienia poleceń na komputerze dewelopera.
W skrócie
Podatność CVE-2026-12957 dotyczyła komponentu Language Servers for AWS, stanowiącego zaplecze działania Amazon Q Developer w środowiskach IDE. Atak wykorzystywał plik konfiguracyjny .amazonq/mcp.json, który po otwarciu repozytorium i zaakceptowaniu zaufania do workspace mógł doprowadzić do uruchomienia lokalnych procesów.
- możliwe było wykonanie dowolnych komend lokalnie,
- procesy dziedziczyły środowisko użytkownika,
- zagrożone były klucze AWS, tokeny CLI, sekrety API i dostęp do agenta SSH,
- producent usunął problem w nowszych wersjach komponentu i zalecił aktualizację wtyczek.
Kontekst / historia
Podatność została ujawniona publicznie 26 czerwca 2026 roku po przejściu procesu skoordynowanego ujawnienia. Problem obejmował współdzielony komponent wykorzystywany przez integracje Amazon Q Developer dla Visual Studio Code, JetBrains, Eclipse oraz Visual Studio.
Zgodnie z informacjami producenta luka dotyczyła wersji Language Servers for AWS starszych niż 1.65.0. Pełna rekomendowana remediacja obejmuje jednak aktualizację do wersji 1.69.0, która eliminuje również drugi problem bezpieczeństwa oznaczony jako CVE-2026-12958.
Sprawa wpisuje się w coraz szerszy trend zagrożeń związanych z agentami AI i konfiguracjami projektów definiującymi zachowanie lokalnych narzędzi. W takim modelu repozytorium przestaje być wyłącznie nośnikiem kodu źródłowego, a staje się także nośnikiem logiki wykonywalnej.
Analiza techniczna
Rdzeniem problemu był brak właściwego egzekwowania granicy zaufania dla konfiguracji MCP. Amazon Q odczytywał plik .amazonq/mcp.json z otwartej przestrzeni roboczej i uruchamiał zdefiniowane w nim serwery MCP, czyli lokalne procesy wykorzystywane przez asystenta AI do komunikacji z narzędziami i usługami.
W podatnej implementacji uruchamiane procesy dziedziczyły pełne środowisko użytkownika. Z punktu widzenia atakującego oznaczało to dostęp do tego samego kontekstu sesji, z którego korzystał deweloper, w tym do aktywnych zmiennych środowiskowych i mechanizmów uwierzytelnienia.
- odczyt kluczy dostępowych i tokenów sesyjnych,
- wykonywanie operacji z użyciem aktywnego kontekstu chmurowego,
- eksfiltracja danych do zewnętrznej infrastruktury,
- potencjalny ruch boczny do systemów wewnętrznych lub środowisk produkcyjnych.
Scenariusz ataku był stosunkowo prosty. Napastnik przygotowywał repozytorium zawierające odpowiednią konfigurację, ofiara klonowała projekt, otwierała go w obsługiwanym IDE i akceptowała zaufanie do workspace. To mogło wystarczyć, aby komponent AI uruchomił wskazany proces bez osobnego, wyraźnego potwierdzenia dla samego wykonania.
Po wdrożeniu poprawki zachowanie zostało zmienione tak, aby niezaufany serwer MCP był wyraźnie sygnalizowany i mógł zostać odrzucony przed wykonaniem. Dodatkowo producent opisał CVE-2026-12958 jako problem związany z brakiem walidacji symlinków, co mogło prowadzić do arbitralnego zapisu plików poza granicą zaufanej przestrzeni roboczej.
Konsekwencje / ryzyko
Najpoważniejszym skutkiem podatności była możliwość przejęcia aktywnych poświadczeń chmurowych dewelopera. W środowiskach, w których stacje robocze mają dostęp do kont AWS, systemów CI/CD, prywatnych rejestrów, sekretów aplikacyjnych lub zasobów produkcyjnych, kompromitacja lokalnej sesji może szybko przekształcić się w incydent o dużej skali.
Ryzyko należy oceniać szerzej niż samo wykonanie kodu lokalnie. Kluczowe znaczenie miał dziedziczony kontekst użytkownika, ponieważ deweloperzy często pracują z uprzywilejowanymi sesjami CLI, agentami SSH i krótkotrwałymi tokenami obecnymi w pamięci procesów lub zmiennych środowiskowych.
Istotny jest również aspekt supply chain. W tym modelu ataku nie trzeba dostarczać klasycznego malware ani exploita pamięciowego. Wystarczy złośliwa konfiguracja projektu, która zostanie potraktowana jako zaufana i uruchomi lokalne procesy w kontekście ofiary.
Rekomendacje
Organizacje korzystające z Amazon Q Developer powinny w pierwszej kolejności zaktualizować podatne komponenty. Zalecane jest wdrożenie wersji Language Servers for AWS 1.69.0 lub nowszej oraz odpowiadających jej aktualnych wersji wtyczek dla wszystkich wspieranych IDE.
Minimalne wersje wskazane przez producenta obejmują:
- Amazon Q Developer for Visual Studio Code: 2.20 lub nowsza,
- Amazon Q Developer for JetBrains: 4.3 lub nowsza,
- Amazon Q Developer for Eclipse: 2.7.4 lub nowsza,
- AWS Toolkit with Amazon Q for Visual Studio: 1.94.0.0 lub nowsza.
Poza aktualizacją warto wdrożyć dodatkowe środki ochronne:
- ograniczyć zaufanie do nowych workspace’ów i traktować konfiguracje repozytorium jako dane nieufne,
- wymagać dodatkowej weryfikacji przed uruchamianiem narzędzi, serwerów MCP i zadań inicjowanych przez agentów AI,
- minimalizować obecność długowiecznych sekretów na stacjach deweloperskich,
- stosować krótkotrwałe poświadczenia i segmentację uprawnień IAM,
- monitorować użycie narzędzi CLI i nietypowe wywołania API z kont deweloperskich,
- objąć kontrolą bezpieczeństwa pliki konfiguracyjne związane z agentami AI, pluginami IDE i integracjami MCP,
- rozważyć uruchamianie narzędzi AI w izolowanych środowiskach roboczych o ograniczonym dostępie do poświadczeń.
Z perspektywy AppSec i DevSecOps warto także rozszerzyć polityki repozytoryjne o skanowanie plików konfiguracyjnych agentów AI. Takie artefakty powinny zostać objęte przeglądami kodu, regułami detekcji i mechanizmami blokującymi nieautoryzowane definicje lokalnych procesów.
Podsumowanie
CVE-2026-12957 pokazuje, że narzędzia AI dla programistów stają się krytycznym elementem modelu bezpieczeństwa organizacji. Problem nie wynikał z klasycznej podatności pamięciowej, lecz z błędnego założenia zaufania wobec konfiguracji dostarczanej przez repozytorium.
W efekcie zwykłe otwarcie projektu mogło doprowadzić do uruchomienia kodu i przejęcia aktywnej sesji chmurowej dewelopera. Dla zespołów bezpieczeństwa to wyraźny sygnał, że integracje MCP, pluginy IDE i agenci AI muszą być traktowani jak uprzywilejowane komponenty środowiska wykonawczego.