Wprowadzenie do problemu / definicja luki
Badacze z NeuralTrust opisali nową technikę ataku na przeglądarkę ChatGPT Atlas, w której złośliwy ciąg wygląda jak adres URL, ale jest celowo sformatowany niepoprawnie. Atlas traktuje taki input w pasku adresu („omnibox”) najpierw jak URL, a gdy walidacja nawigacji zawodzi, degraduje go do polecenia tekstowego – jednak z wyższym zaufaniem i słabszymi kontrolami, co umożliwia cichy jailbreak i przejęcie zachowania agenta.
OpenAI w materiałach o Atlasie podkreśla, iż bezpieczeństwo agentów było priorytetem – jednak opisana technika pokazuje, iż granica między „zaufaną” intencją użytkownika a nieufnym inputem bywa w praktyce rozmyta.
W skrócie
- Wejście przypominające URL wklejone do omniboxa może zostać potraktowane jako wysokozaufany prompt, jeżeli nie przejdzie walidacji URL.
- To pozwala omijać warstwy ochronne i wymuszać działania agenta (np. phishing, destrukcyjne operacje na kontach w chmurze).
- Luka wpisuje się w szerszą klasę zagrożeń prompt injection dla „agenticznych” przeglądarek (Atlas, Comet, itp.).
Kontekst / historia / powiązania
Badania Brave pokazały systemowe problemy pośredniego prompt injection w przeglądarkach z agentami – złośliwe instrukcje mogą być ukryte nie tylko w tekście strony, ale choćby w obrazach/screenshotach. Dyskusja ta rozgorzała w tym samym tygodniu, w którym zadebiutował Atlas.
Media branżowe i technologiczne zwracały uwagę na nowe wektory ryzyka wynikające z możliwości działania w imieniu użytkownika (dostępy do zalogowanych serwisów, historii, plików).
Analiza techniczna / szczegóły luki
NeuralTrust opisuje łańcuch zdarzeń:
- Przygotowanie ładunku – ciąg zaczyna się jak URL („https:” + domenopodobny fragment), ale zawiera język naturalny z imperatywami („follow these instructions…”) i celowe błędy (spacje, znaki, literówki).
- Wyzwolenie – użytkownik kopiuje/wkleja „link” do omniboxa (np. po kliknięciu „Copy link”).
- Iniekcja – walidacja URL nie przechodzi; Atlas traktuje treść jako prompt o pochodzeniu „od użytkownika”, z mniejszą liczbą kontroli.
- Eksploatacja – agent wykonuje instrukcje: od otwarcia fałszywego Google (phishing) po operacje na Google Drive (np. kasowanie plików) przy użyciu sesji uwierzytelnionej użytkownika.
SecurityWeek streszcza ten sam mechanizm i podaje przykładowy „URL-prompt”, ilustrując eskalację zaufania wynikającą z błędu parsowania pomiędzy trybem „Nawiguj” a „Zapytać/Wykonaj”.
Praktyczne konsekwencje / ryzyko
- Phishing i kradzież sesji/poświadczeń poprzez otwieranie stron podszywających się pod zaufane serwisy.
- Operacje krzyżodomenowe w kontekście zalogowanego użytkownika (np. Drive, poczta) – tradycyjne SOP/CSRF nie chronią przed intencją agenta.
- Degradacja polityk bezpieczeństwa (RL, guardraily) – prompt traktowany jako „intencja” może ominąć filtry treści.
Szerszy ekosystem agentów przeglądarkowych już wcześniej wykazał podatność na injection (w tym z obrazów), co dowodzi, iż to problem systemowy, a nie pojedynczy bug.
Rekomendacje operacyjne / co zrobić teraz
Dla użytkowników końcowych (od razu):
- Nie wklejaj do omniboxa „linków” z nieznanych źródeł; traktuj przycisk „Copy link” jak potencjalny wektor ataku.
- Wyłącz/ogranicz automatyczne akcje agenta i wymagaj potwierdzenia przed dostępem do poczty, dysków, formularzy płatniczych.
- Oddziel przeglądanie wrażliwe (bankowość, praca) od eksperymentów z agentem (np. osobny profil/konto).
Dla zespołów SecOps/AppSec (krótkoterminowo):
- W politykach EDR/DLP i proxy oznaczaj ruch Atlas oraz monitoruj anomalie na kontach SaaS (Drive, O365).
- Wprowadź kontrole kontekstowe (step-up MFA, reautoryzacja narzędzi) przy akcjach inicjowanych przez agentów.
- Edukuj użytkowników: „URL ≠ URL” – pokaż przykłady obfuskacji i mechanizm degradacji do promptu. (na bazie case’u NeuralTrust).
Dla vendorów/pracujących nad agentami (średnioterminowo):
- Twarde parsowanie i normalizacja URL; jeżeli są niejednoznaczności – odrzuć, bez cichego fallbacku do trybu prompt.
- Jawny wybór trybu (Navigate vs Ask/Act) i widoczny stan UI; brak automatycznych przełączeń.
- Zasada najmniejszych uprawnień dla promptów z omniboxa; potwierdzenie użytkownika przy narzędziach/akcjach krzyżodomenowych.
- Stripping instrukcji z inputów „URL-opodobnych” i tagowanie pochodzenia tokenów w rozmowie z LLM.
Różnice / porównania z innymi przypadkami
- Comet / „niewidzialne” injekcje w obrazach: wektor to kontekst strony/screenshot, a nie omnibox; w Atlasie wektor siedzi w pasku adresu i podszywa się pod intencję użytkownika.
- Klasyczne XSS/CSRF: atak nie łamie przeglądarkowego SOP – agent wykonuje akcje „w dobrej wierze”, co omija wiele klasycznych barier. (por. szersze omówienie w The Register i literaturze nt. agentów webowych).
Podsumowanie / najważniejsze wnioski
- Luka w omniboxie Atlasu to błąd granicy zaufania: URL-opodobny ciąg staje się wysokozaufanym promptem.
- Efekt: jailbreaky i aktywne nadużycia w kontekście zalogowanego użytkownika.
- Rozwiązania: twarde parsowanie, jawne tryby, potwierdzenia i proweniencja tokenów – do wdrożenia zarówno po stronie vendorów, jak i w politykach organizacji.
Źródła / bibliografia
- NeuralTrust: „OpenAI Atlas Omnibox Prompt Injection: URLs That Become Jailbreaks” (24 paź 2025). (NeuralTrust)
- SecurityWeek: „OpenAI Atlas Omnibox Is Vulnerable to Jailbreaks” (25 paź 2025). (SecurityWeek)
- OpenAI: „Introducing ChatGPT Atlas” – sekcja o zabezpieczeniach agenta. (OpenAI)
- Brave: „Unseeable prompt injections… more vulnerabilities in Comet and other AI browsers”. (Brave)
- The Register: „OpenAI defends Atlas as prompt injection attacks surface”. (The Register)
