VS Code i GitHub Codespaces: automatyczne konfiguracje mogą otworzyć drogę do RCE i ataków na łańcuch dostaw - Security Bez Tabu

VS Code i GitHub Codespaces: automatyczne konfiguracje mogą otworzyć drogę do RCE i ataków na łańcuch dostaw

Wprowadzenie do problemu / definicja luki

Badacze wskazują na ryzykowną cechę integracji Visual Studio Code z GitHub Codespaces: repozytorium (lub PR) może dostarczyć pliki konfiguracyjne, które w Codespaces są automatycznie respektowane, a w pewnych scenariuszach prowadzą do uruchomienia poleceń bez wyraźnej zgody użytkownika. Taki mechanizm, choć projektowany pod wygodę, tworzy wektor „one-click” pod zdalne wykonanie kodu (RCE) i nadużycia w stylu supply chain.

W skrócie

  • Atakujący może umieścić złośliwe polecenia w plikach .vscode/*.json lub .devcontainer/devcontainer.json, które Codespaces/VS Code mogą wykonać podczas otwierania repo/PR.
  • Celem bywa eksfiltracja tokenów GitHub, sekretów Codespaces i innych danych środowiskowych, a następnie eskalacja do ataku na łańcuch dostaw (np. przejęcie kontekstu maintenera).
  • Orca opisuje m.in. wektory: tasks.json z auto-run na folderOpen, wstrzyknięcia przez PROMPT_COMMAND w terminalu oraz komendy w devcontainer.json uruchamiane po inicjalizacji kontenera.
  • Microsoft miał potwierdzić, że zachowanie jest „by design”.

Kontekst / historia / powiązania

GitHub Codespaces to chmurowe środowisko developerskie mocno zintegrowane z repozytoriami: w praktyce VS Code „w chmurze” z uwierzytelnieniem GitHub i kontenerami (Ubuntu). To daje szybkość uruchomienia i powtarzalność, ale jednocześnie zwiększa wagę tego, co repozytorium może „wnieść” do środowiska poprzez konfiguracje.

Wątek łączy się też z szerszym problemem: granicą między „konfiguracją” a „wykonaniem”. Oligo opisało wcześniej klasę ryzyk, gdzie przeglądarka może oddziaływać na lokalne usługi (tzw. „0.0.0.0 Day”), co w łańcuchu z innymi słabościami może ułatwiać dostęp do usług developerskich wystawionych lokalnie.

Analiza techniczna / szczegóły luki

Z perspektywy technicznej to nie jedna „dziura CVE”, tylko kombinacja domyślnych zachowań i zaufania do plików repozytorium w środowisku, które ma dostęp do tokenów i sekretów.

Najważniejsze ścieżki nadużyć (wg Orca i podsumowania SecurityWeek):

  1. Auto-run zadań VS Code
    • Repozytorium może zawierać .vscode/tasks.json z zadaniami typu shell i opcją uruchomienia przy otwarciu folderu (np. runOn: folderOpen).
    • Orca twierdzi, że w Codespaces domyślne ustawienia sprzyjają wykonywaniu takich zadań, co pozwala np. na wysłanie zmiennych środowiskowych na zewnętrzny serwer (eksfiltracja).
  2. Wstrzyknięcie przez konfigurację terminala (PROMPT_COMMAND)
    • .vscode/settings.json może wpływać na zintegrowany terminal; na linuksowych Codespaces wykonywanie przez bash sprawia, że pewne wstrzyknięcia są powtarzalne i „pewne” w praktyce.
  3. Devcontainer jako nośnik poleceń
    • .devcontainer/devcontainer.json może zawierać komendy uruchamiane po przygotowaniu środowiska (np. po inicjalizacji kontenera), co daje kolejny moment wykonania kodu kontrolowanego przez repo.
  4. Łańcuchy i rozszerzenia VS Code
    • Po uzyskaniu wykonania kodu atakujący może iść dalej: tworzyć/instalować złośliwe rozszerzenia VS Code, prowadzić do XSS w kontekście narzędzi developerskich, a nawet łączyć to z innymi klasami błędów (np. dostęp do usług lokalnych).

Warto odnotować element „statusu”: według opisu, zgłoszono sprawę do Microsoftu, a odpowiedź miała wskazywać, że to zachowanie jest intencjonalne.

Praktyczne konsekwencje / ryzyko

Najbardziej realistyczny scenariusz ryzyka to atak przez złośliwy PR lub repo, które maintener/recenzent otwiera w Codespaces „dla wygody”.

Skutki mogą obejmować:

  • Kradzież tokenu GitHub (o uprawnieniach ofiary) i wykorzystanie go do działań w repozytoriach (read/write w kontekście użytkownika), włącznie z wprowadzaniem zmian i przygotowaniem kolejnych złośliwych PR-ów.
  • Eksfiltrację sekretów Codespaces oraz innych danych w środowisku (np. klucze do usług chmurowych używane w dev/test).
  • Supply chain: jeśli wycieknie token maintenera, atakujący może wykonać ruchy, które wyglądają jak działania zaufanego opiekuna projektu.

Dodatkowy aspekt: GitHub wskazuje wprost, że – jak przy każdym narzędziu dev – należy pracować tylko na repozytoriach, które się zna i którym się ufa, co w tym kontekście staje się bardzo praktyczną zasadą, nie ogólnikiem.

Rekomendacje operacyjne / co zrobić teraz

Poniżej zestaw działań „tu i teraz”, które zwykle dają najlepszy efekt koszt/korzyść:

  1. Zero-trust dla repo/PR w Codespaces
  • Nie otwieraj w Codespaces niezweryfikowanych forków i PR-ów od nieznanych kont, jeśli to nie jest absolutnie konieczne.
  1. Ogranicz automatyzacje VS Code
  • W środowiskach firmowych rozważ politykę wymuszającą bezpieczne ustawienia dla zadań automatycznych (np. wyłączenie auto-run zadań w workspace) oraz twarde zasady dot. zaufania do workspace. (Szczegóły konfiguracji zależą od tego, jak zarządzasz VS Code/Codespaces w organizacji, ale cel jest jeden: repo nie powinno samoczynnie uruchamiać poleceń).
  1. Przeglądaj pliki „wysokiego ryzyka” w PR-ach
  • Traktuj jako „red flags” zmiany w:
    • .vscode/tasks.json, .vscode/settings.json
    • .devcontainer/devcontainer.json
    • skrypty bootstrap/instalacyjne uruchamiane na starcie środowiska
      W praktyce to odpowiednik przeglądu zmian w CI/CD — tylko że dotyczy środowiska developera.
  1. Minimalizuj ekspozycję sekretów w Codespaces
  • Uporządkuj, jakie sekrety w ogóle są dostępne w Codespaces; GitHub daje mechanizmy zarządzania sekretami dla Codespaces — korzystaj z nich świadomie i ograniczaj do minimum.
  • Pamiętaj o ograniczeniach typu „secrets nie są przekazywane do forków” (to pomaga, ale nie rozwiązuje scenariusza maintenera otwierającego PR w Codespaces).
  1. Detekcja i reakcja
  • Dodaj alerty na nietypowe zachowania: nagłe połączenia wychodzące z Codespaces, nietypowe użycie tokenów, podejrzane zmiany w plikach .vscode/ i .devcontainer/.

Różnice / porównania z innymi przypadkami (jeśli dotyczy)

  • „Konfiguracja jako kod” vs „wykonanie jako skutek uboczny”: tu problemem nie jest klasyczna luka w parserze, tylko fakt, że „konfiguracja projektu” potrafi inicjować wykonywanie poleceń. To upodabnia ryzyko do nadużyć w pipeline’ach (CI), tylko przeniesionych na stację roboczą (w tym wypadku: chmurową).
  • Łańcuch z innymi klasami błędów: np. jeśli środowisko developerskie wystawia lokalne usługi albo da się je osiągnąć przez obejścia sieciowe/przeglądarkowe, wektor może się wzmocnić (stąd częste odwołania do „0.0.0.0 Day” jako elementu łańcucha).

Podsumowanie / kluczowe wnioski

  • GitHub Codespaces i VS Code przyspieszają pracę, ale w zamian podnoszą stawkę zaufania do zawartości repozytorium (w tym plików konfiguracyjnych).
  • Najgroźniejszy scenariusz jest prosty: maintener otwiera złośliwy PR w Codespaces → uruchamia się polecenie → wyciek tokenu/sekretów → supply chain.
  • Najbardziej praktyczne mitigacje to: ograniczyć auto-run, twardo egzekwować zasady zaufania do repo/PR, przeglądać .vscode/ i .devcontainer/ jak „krytyczną powierzchnię”, oraz minimalizować sekrety dostępne w Codespaces.

Źródła / bibliografia

  1. SecurityWeek – opis problemu i konsekwencji dla Codespaces (5 lutego 2026) (SecurityWeek)
  2. Orca Security – analiza techniczna wektorów i scenariuszy ataku (4 lutego 2026) (Orca Security)
  3. GitHub Docs – Security in GitHub Codespaces (GitHub Docs)
  4. GitHub Docs – Secrets dla Codespaces (zarządzanie sekretami konta) (GitHub Docs)
  5. Oligo Security – „0.0.0.0 Day” (kontekst łańcuchów ataku i dostępu do usług lokalnych) (Oligo Security)