CVE-2026-59728

Astro w wersjach od 10.0.3 do 11.0.3 ma podatność w adapterze Vercel, gdzie funkcja /_isr akceptuje x_astro_path na podstawie tylko nagłówka x-vercel-isr, co pozwala nieuwierzytelnionym żądaniom GET renderować trasy chronione tylko przez reguły ścieżek Vercel edge lub podzielone edge middleware.

Astro przed wersją 8.1.2, adapter Netlify konwertuje każdy wpis image.remotePatterns na wyrażenie regularne zapisywane do .netlify/v1/config.json pod images.remote_images dla listy dozwolonych obrazów CDN Netlify. W packages/integrations/netlify/src/index.ts, funkcja remotePatternToRegex() escapuje kropki w wartościach hostname, ale interpoluje dosłowne wartości pathname bez escapowania metaznaków wyrażeń regularnych, takich jak ., +, ?, (, i [, więc restrykcyjna ścieżka, np. /img/v1.0/file, pasuje również do ścieżek sąsiadujących z metaznakami, w tym ścieżek przekraczających segment. Netlify egzekwuje wygenerowane wyrażenie regularne bezpośrednio, a funkcja pomocnicza matchPattern() w Astro nie ponownie weryfikuje żądania, co pozwala na optymalizację obrazów na już dozwolonym hoście, który deklarowana ścieżka miała wykluczyć. Problem naprawiono w wersji 8.1.2.

Astro to framework webowy dla stron opartych na treści. Od wersji 7.0.0 do 7.0.6 komponowalny potok astro/hono instaluje security.checkOrigin tylko przez prymityw middleware(), podczas gdy actions() i pages() mogą wywoływać kod użytkownika niezależnie. Zamontowanie actions() przed middleware(), jak w przykładzie advanced-routing i dokumentacji Cloudflare Hono, pozwala na wykonanie żądań akcji w formacie formularza z innego pochodzenia przed sprawdzeniem pochodzenia, a użycie pages() bez middleware() pomija sprawdzenie dla punktów końcowych i stron na żądanie. Błąd umożliwia ślepą, tylko do zapisu, podatność na fałszowanie żądań między witrynami (CSRF) z użyciem ciasteczek ofiary przeciwko ActionHandler.handle i PagesHandler.handleWithErrorFallback, gdy manifest.checkOrigin jest włączony; atakujący może wywołać akcję zmieniającą stan lub handler punktu końcowego, ale nie może odczytać odpowiedzi z innego pochodzenia. Domyślny niekomponowalny potok astro() nie jest dotknięty. Problem naprawiono w wersji 7.0.6.

Astro to framework webowy dla stron opartych na treści. Od wersji 2.9.0 do 7.1.0 generator CSS dla View Transition po stronie serwera interpoluje właściwości animacji do elementu stylu inline bez ich escapowania dla kontekstów CSS i HTML. Wartość animacji View Transition kontrolowana przez atakującego, taka jak czas trwania, może zakończyć wygenerowany element stylu i wstrzyknąć dowolny HTML lub JavaScript. Dotknięty kod to packages/astro/src/runtime/server/transition.ts; renderTransition przekazuje sheet.toString() do markHTMLString(), podczas gdy addAnimationProperty serializuje czas trwania przez toTimeValue() i obsługuje również easing, direction, delay, fillMode i name. Wykorzystanie wymaga trasy na żądanie lub renderowanej po stronie serwera, aby przekazać dane kontrolowane przez atakującego do definicji animacji View Transition i może wykonać dowolny JavaScript w pochodzeniu dotkniętej aplikacji, umożliwiając dostęp do wrażliwych danych strony i uwierzytelnionych akcji dostępnych dla ofiary. Problem naprawiono w wersji 7.1.0.

W Astro w wersjach od 8.1.0 do 11.0.1, gdy opcja trailingSlash: 'always' jest skonfigurowana, serwer standalone @astrojs/node dodaje końcowy ukośnik do ścieżek żądań i wysyła przekierowanie 301. Ścieżki zaczynające się od /\ (ukośnik-odwrotny ukośnik) nie są rozpoznawane jako wewnętrzne, więc serwer odsyła surową ścieżkę w nagłówku Location. Ponieważ przeglądarki traktują \ jako / zgodnie ze specyfikacją WHATWG URL, wynikowe przekierowanie może prowadzić do zewnętrznego hosta.

Astro to framework webowy dla stron opartych na treści. Wersje przed 7.0.6 są podatne na XSS poprzez nieuciekające nazwy atrybutów spread w renderHTMLElement. Poprawka dla CVE-2026-54298 dodała zabezpieczenie INVALID_ATTR_NAME_CHAR w addAttribute(), ale druga ścieżka renderowania atrybutów, renderHTMLElement(), nie została zaktualizowana i interpoluje nazwę atrybutu bez ucieczki, co pozwala na atak XSS. Problem został naprawiony w wersji 7.0.6.

W Astro w wersjach od 3.10.0 do 7.0.3, gdy dyrektywy transition:persist, transition:scope lub transition:persist-props są zastosowane do komponentu hydratowanego po stronie klienta (client:*), Astro kopiuje wartość dyrektywy do renderowanego elementu <astro-island> bez kodowania HTML. Jeśli programista odzwierciedli dane kontrolowane przez atakującego w jednej z tych dyrektyw, atakujący może wyrwać się z atrybutu i wstrzyknąć dowolny kod HTML/JavaScript do wyjścia renderowanego po stronie serwera, co prowadzi do odbitego XSS.

Astro w wersji 6.4.7 zawiera podatność polegającą na podejmowaniu decyzji autoryzacyjnych na częściowo zdekodowanej ścieżce URL po osiągnięciu limitu iteracyjnego dekodera. Późniejsze dopasowanie reguł przepisywania wykonuje dodatkową operację decodeURI(), co może umożliwić ominięcie zabezpieczeń i dostęp do chronionych tras.