CVE-2026-73424

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 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 w wersjach 1.0.0 do 4.0.18 ma podatność polegającą na braku escape'owania znaków XML w polach source.title i enclosure.type w generatorze RSS. Atakujący kontrolujący te wartości może wstrzyknąć dowolny XML do kanału RSS, co może prowadzić do fałszywych metadanych, przekierowań na złośliwe strony lub błędnego parsowania przez czytniki RSS. W trybie SSR zanieczyszczony kanał jest serwowany każdemu subskrybentowi. Naprawiony w wersji 4.0.19.

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.