CVE-2025-65019

Astro to framework webowy dla stron opartych na treści. Przed wersją 7.3.2 pipeline renderowania JSX i MDX traktuje tekstowe dzieci elementów script i style jako zaufany HTML, nie odróżniając treści generowanej przez kompilator od dynamicznych wartości wyrażeń, co pozwala na wstrzyknięcie dowolnego HTML i JavaScript. Problem jest ograniczony do dzieci script i style renderowanych przez astro:jsx, w tym komponentów MDX, i może prowadzić do reflected lub stored XSS w obrębie domeny aplikacji.

W frameworku Astro od wersji 7.1.0 do 7.3.3 generator CSS View Transition po stronie serwera nie utrzymuje właściwości animacji tekstowych w wygenerowanych deklaracjach. Aplikacja przekazująca dane kontrolowane przez atakującego do właściwości takich jak duration, delay, easing, direction, fillMode lub nazwy animacji może pozwolić separatorom CSS zakończyć deklarację i dodać reguły wybrane przez atakującego do renderowanej strony. Wstrzyknięty CSS może ukrywać lub przemieszczać treść, dodawać wygenerowany tekst i fałszować interfejs. Problem naprawiono w wersji 7.3.3.

Astro to framework webowy dla stron opartych na treści. Przed wersją 11.1.3 adapter @astrojs/node buduje URL żądania z nagłówka Host, a nieprawidłowy port może uczynić ten URL nieprawidłowym. Ścieżka odzyskiwania używa tego samego nieprawidłowego hosta i wyrzuca nieprzechwycony TypeError: Invalid URL przed rozpoczęciem routingu. W domyślnej konfiguracji standalone żądanie zwraca odpowiedź HTTP 500 i serwer kontynuuje działanie, ale gdy włączony jest staticHeaders, synchroniczny handler nie łapie wyjątku i proces Node zostaje zakończony. Proxy i CDN, które odrzucają nieprawidłowe nagłówki Host, zapobiegają dotarciu tej ścieżki do origin. Problem dotyczy tylko dostępności i nie ujawnia danych ani nie pozwala na wykonanie kodu. Problem został naprawiony w wersji 11.1.3.

Astro od wersji 5.2.0 do 8.2.4 ma podatność w adapterze @astrojs/netlify, która generuje wyrażenia regularne dla list dozwolonych obrazów Netlify Image CDN bez zakotwiczenia ich do początku URL. Pozwala to atakującemu kontrolować host URL, podczas gdy dozwolony origin pojawia się tylko w ścieżce lub zapytaniu. Nieuwierzytelnione żądanie do publicznego punktu /.netlify/images może spowodować, że Image CDN pobierze adresy URL wybrane przez atakującego, potencjalnie docierając do usług wewnętrznych. Problem naprawiono w wersji 8.2.4.

Astro to framework webowy dla stron opartych na treści. Przed wersją 7.2.4, Astro usuwał skonfigurowaną ścieżkę bazową (base path) z nazw ścieżek żądań za pomocą sprawdzenia prefiksu bez weryfikacji granicy segmentu ścieżki. Przy bazie "/app", żądanie do "/appX/admin" wewnętrznie rozwiązywało się do chronionej trasy "/admin", podczas gdy middleware obserwował "/appX/admin" w context.url.pathname. W aplikacjach autoryzujących trasy z prefiksem bazowym przez sprawdzanie context.url.pathname, nieuwierzytelniony zdalny atakujący mógł ominąć autoryzację middleware opartą na nazwie ścieżki i dotrzeć do chronionych tras. Problem naprawiono w wersji 7.2.4.

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.