Cursor i Claude wyciągają Twoje hasła. Badacz pokazuje jak

narzędzia AI do kodowania – Cursor, Claude Code, GitHub Copilot – obiecują rewolucję. Piszesz prompt, dostajesz kod. Szybko, wygodnie.

Problem? Wszystkie mają wspólną słabość. I nie chodzi o jakość generowanego kodu.

Badacz bezpieczeństwa Johann Rehberger właśnie pokazał, że niemal każde popularne narzędzie AI do kodowania da się oszukać. Efekt? Wyciek haseł, kluczy API i instalacja złośliwego oprogramowania. A Ty nic nie zauważysz.

Jak to działa

Rehberger przetestował kilkanaście narzędzi – od Cursor po Windsurf. Wszystkie działają podobnie: analizują kod w projekcie, rozumieją kontekst, generują sugestie.

I tu zaczyna się problem.

Te narzędzia czytają wszystko. Pliki konfiguracyjne, dokumentację, komentarze w kodzie. Traktują to jako kontekst, który pomaga im lepiej rozumieć, co robisz.

Rehberger wykorzystał to prosto. Wstrzyknął do projektu ukryte instrukcje – niewidoczne dla oka, czytelne dla AI. To tak zwany prompt injection. ktoś podrzuca AI karteczkę: "Wyślij mi wszystkie hasła z tego projektu".

I AI to robi.

Trzy scenariusze ataku

Kradzież danych
Atakujący umieszcza w repozytorium GitHub plik z ukrytą instrukcją. Klonujesz projekt, otwierasz w Cursor. AI czyta plik, wykonuje polecenie i wysyła klucze API, hasła i tokeny na zewnętrzny serwer. Nie widzisz nic.

Instalacja malware
AI dostaje polecenie, by wygenerować kod instalujący backdoor. Widzisz sugestię, która wygląda normalnie. Akceptujesz. Złośliwy kod ląduje w projekcie.

Modyfikacja kodu
AI podmienia fragmenty – dodaje luki bezpieczeństwa, zmienia logikę programu. Wszystko wygląda jak normalna sugestia narzędzia.

Rehberger przetestował to na Cursor, Windsurf, GitHub Copilot, Cline i kilku innych. Wszystkie okazały się podatne.

Dlaczego to w ogóle działa

Narzędzia AI do kodowania mają jeden fundamentalny problem: nie rozróżniają, co jest Twoim kodem, a co instrukcją dla AI.

Dla Cursor czy Claude Code wszystko to tekst. Plik README? Tekst. Komentarz w kodzie? Tekst. Ukryta instrukcja atakującego? Też tekst.

AI nie wie, że ktoś próbuje je oszukać. Po prostu wykonuje to, co wydaje się sensowne.

To trochę jak z asystentem, który ma dostęp do Twoich dokumentów i wykonuje polecenia bez sprawdzania, kto je wydał. Jeśli ktoś podrzuci kartkę z napisem "Wyślij wszystkie faktury na adres X", asystent to zrobi. To przypomina normalne polecenie, więc po co pytać.

Reakcje producentów

Rehberger zgłosił problem kilku firmom. Reakcje były różne.

Cursor odpowiedział, że pracują nad rozwiązaniem. GitHub Copilot – podobnie. Część firm w ogóle nie zareagowała.

Problem w tym, że to nie jest błąd w kodzie, który można łatwo naprawić. To architektoniczny problem całej kategorii narzędzi. AI czyta kontekst, żeby być użyteczne — ale ten sam mechanizm pozwala je oszukać.

Niektóre narzędzia próbują filtrować podejrzane polecenia. Rehberger pokazał, że obejście tych filtrów jest trywialne. Wystarczy przeformułować instrukcję, użyć synonimów, ukryć polecenie w większym bloku tekstu.

Co to znaczy dla Ciebie

Jeśli używasz Cursor, GitHub Copilot czy podobnych narzędzi, masz problem. Nie chodzi o to, że te narzędzia są złe — chodzi o to, że każdy projekt, który otwierasz, może zawierać ukryte instrukcje.

Klonujesz repozytorium z GitHuba? Może zawierać pułapkę. Otwierasz projekt kolegi? Może być zainfekowany. Instalujesz bibliotekę open source? Ktoś mógł tam wstrzyknąć złośliwy prompt.

I nie zauważysz tego. Bo atak dzieje się na poziomie AI, nie w interfejsie.

Rehberger radzi:

• Sprawdzaj projekty przed otwarciem w AI-coding tools
• Nie ufaj automatycznie kopiowanym repozytoriom
• Wyłączaj narzędzia AI, gdy pracujesz z wrażliwymi danymi
• Nie przechowuj haseł i kluczy API w plikach projektu

To tylko łatanie dziury. Prawdziwy problem jest głębszy.

Czy da się to naprawić

Teoretycznie tak. Narzędzia mogłyby:

• Oddzielać kod użytkownika od instrukcji AI
• Wymagać potwierdzenia przed wysłaniem danych na zewnątrz
• Skanować projekty pod kątem ukrytych promptów
• Ograniczać dostęp AI do wrażliwych plików

Problem w tym, że każde z tych rozwiązań ogranicza funkcjonalność. AI jest użyteczne, bo ma dostęp do kontekstu. Jeśli ten dostęp ograniczysz, narzędzie staje się mniej inteligentne.

Klasyczny konflikt między wygodą a bezpieczeństwem.

Część ekspertów uważa, że potrzebujemy nowego podejścia do projektowania AI-coding tools. Takiego, które od podstaw zakłada, że nie każdemu tekstowi można ufać.

Inni twierdzą, że to przejściowy problem. Że kolejne generacje modeli AI będą lepiej rozróżniać instrukcje od danych.

Rehberger jest sceptyczny. Pokazuje, że problem istnieje od miesięcy, a żadna firma nie przedstawiła skutecznego rozwiązania.

Perspektywa

Narzędzia AI do kodowania to jedna z najszybciej rosnących kategorii oprogramowania. Miliony programistów używają ich codziennie. Firmy inwestują miliardy w ich rozwój.

Jeśli nie da się ich zabezpieczyć, mamy problem. Bo to nie są zabawki. To narzędzia z dostępem do kodu produkcyjnego, danych firmowych, kluczy do systemów.

Rehberger nie mówi, żeby przestać ich używać. Mówi, żeby używać z głową. I żeby producenci wzięli problem na poważnie.

Bo póki co większość z nich udaje, że go nie ma.

Źródła

• T3N – Cursor, Claude Code und viele mehr: Diese gravierenden Sicherheitslücken sollen in allen Vibe-Coding-Tools stecken