A2UI CVE-2026-10032: przycisk agenta AI musi mieć bezpieczną akcję

Wpis GitHub Advisory Database zaktualizowany 2 października opisuje CVE-2026-10032 w @a2ui/web_core. Problem dotyczy wersji od 0.9.0 do wersji niższych niż 0.10.2. Nota projektu była opublikowana już w sierpniu; aktualizacja bazy nie oznacza odkrycia podatności w październiku.

Autorzy A2UI wskazują, że adres kontrolowany przez agenta trafiał do funkcji openUrl bez sprawdzenia schematu URI. Opisują możliwość wykonania JavaScript w kontekście aplikacji po kliknięciu wygenerowanego przycisku. Poprawka jest dostępna od 0.10.2 i ogranicza tę akcję do poprawnych adresów HTTP lub HTTPS.

Kogo dotyczy problem

Oceny potrzebują zespoły, których aplikacje wykorzystują wskazany pakiet do renderowania interfejsu i obsługi akcji agenta. Samo używanie modelu językowego albo czatu AI nie oznacza używania podatnego komponentu. Właściciel aplikacji powinien ustalić wersję faktycznie dostarczaną przeglądarce, także przez zależności pośrednie i wcześniej zbudowane zasoby.

Wniosek Breachroad: opis przycisku i wykonywane działanie wymagają osobnej oceny. Etykieta „Otwórz dokument” może wyglądać znajomo, ale nie potwierdza bezpieczeństwa danych akcji. To aplikacja musi egzekwować reguły, zanim uruchomi funkcję wybraną przez agenta.

Co zrobić z poprawką

Źródłem informacji o naprawie jest zmiana w repozytorium A2UI. Rekomendujemy aktualizację do wspieranej wersji zawierającej tę poprawkę oraz ponowne zbudowanie i wdrożenie aplikacji. Zmiana pliku zależności nie aktualizuje automatycznie zasobów, które użytkownicy już otrzymują z serwera lub CDN.

Kontrola powinna objąć miejsce, w którym adres jest interpretowany. Sprawdzenie, że wartość jest tekstem, nie potwierdza schematu ani odbiorcy. Własne funkcje katalogu również wymagają przeglądu: naprawa jednej akcji nie stanowi dowodu bezpieczeństwa wszystkich rozszerzeń.

Przykład szkoleniowy: otwieranie faktury

Rozważmy nasz fikcyjny scenariusz. Asystent proponuje przycisk „Sprawdź fakturę” w firmowym portalu. Pracownik widzi poprawnie brzmiącą etykietę, natomiast aplikacja otrzymuje osobno adres i typ działania. Bezpieczny proces sprawdza te dane według swojej polityki, zamiast uznawać zgodny język odpowiedzi za potwierdzenie zaufania.

Poza poprawką CVE firma może dopuścić otwieranie dokumentów wyłącznie z uzgodnionych domen, ograniczyć przekazywane parametry i zachować niezależną autoryzację operacji finansowych. Są to nasze propozycje kontroli biznesowych. Sam adres HTTPS nie potwierdza, że odbiorca jest właściwy ani że użytkownik powinien przekazać mu dane.

Cztery decyzje dla zespołu

1. Właściciel: wskaż osobę odpowiadającą za pakiet renderujący oraz katalog akcji. Dostawca modelu nie jest automatycznie właścicielem kodu przeglądarki.
2. Zakres: zinwentaryzuj akcje otwierające adresy, wysyłające dane i zmieniające stan. Określ osobną politykę dla każdej z nich.
3. Weryfikacja: w kontrolowanym środowisku sprawdź odrzucanie niedozwolonych schematów i obsługę błędnego adresu bez wykonania akcji. Używaj danych testowych.
4. Zgłoszenie: rejestruj identyfikator akcji i wynik walidacji. Zespół wsparcia powinien wiedzieć, jak zgłosić podejrzany przycisk bez kopiowania poufnego dokumentu do zgłoszenia.

Pracowników warto nauczyć zatrzymania procesu, gdy działanie asystenta jest nieoczekiwane. Nie należy jednak przenosić na nich obowiązku rozpoznawania ukrytej implementacji przycisku. To zadanie zabezpieczeń aplikacji.

Szkolenia z cyberbezpieczeństwa i bezpiecznego używania AI pomagają przećwiczyć podział odpowiedzialności między pracownikiem, IT i właścicielem procesu. Szersze granice wykonywania działań opisujemy w artykule o architekturze sandboxa dla agentów AI.

Fakty i nasze wnioski

Zakres wersji i mechanizm CVE pochodzą z not A2UI i GitHuba, a informacja o zmianie z repozytorium projektu. Scenariusz faktury, podział odpowiedzialności i propozycje kontroli są opracowaniem Breachroad. Opis podatności nie jest dowodem incydentu w konkretnej organizacji. Stan źródeł sprawdziliśmy 4 października 2026 roku.