Анонс Istio 1.30.4

Цей реліз містить виправлення безпеки. Ця примітка до релізу описує, що відрізняється між Istio 1.30.3 та 1.30.4.

Оновлення безпеки

Детальнішу інформацію див. у ISTIO-SECURITY-2026-006.

CVE Envoy

• CVE-2026-73513: (оцінка CVSS 7.5): Виправлено heap use-after-free у oghttp2 при отриманні HTTP/2 трейлерів без прапорця END_STREAM.
• CVE-2026-73552: (оцінка CVSS 7.5): Виправлено помилку, де safe_regex не вдавався (fail open) на не-UTF-8 байтах заголовків у політиках RBAC з негативним співпадінням.
• CVE-2026-73512: (оцінка CVSS 7.5): Виправлено use-after-free у обробнику HTTP датаграм QUIC.
• CVE-2026-73547: (оцінка CVSS 7.5): Виправлено аномальне завершення у ext_authz при обробці CONNECT запитів без заголовка :path.
• CVE-2026-73549: (оцінка CVSS 5.3): Виправлено аномальне завершення для scoped IPv6 клієнтських адрес з HTTP/3.
• CVE-2026-50572: (оцінка CVSS 5.9): Виправлено use-after-free у ext_authz raw HTTP клієнті.
• CVE-2026-73546: (оцінка CVSS 7.4): Виправлено збережену cross-site scripting вразливість у HTML інтерфейсі статистики.
• CVE-2026-48521: (оцінка CVSS 5.9): Виправлено null-pointer dereference під час вибору connection-pool HTTP/3 на основі ALPN.
• CVE-2026-73551: (оцінка CVSS 5.3): Виправлено нормалізацію URL крапки та двокрапки сегментів шляху з параметрами.
• CVE-2026-73511: (оцінка CVSS 5.3): Виправлено співпадіння шляху для per-segment параметрів.
• CVE-2026-73548: (оцінка CVSS 7.5): Виправлено cross-user отруєння відповіді на загальних HTTP upgrades.
• CVE-2026-73550: (оцінка CVSS 7.5): Виправлено вичерпування памʼяті HTTP/2 через відкинуті дубльовані заголовки Host.
• CVE-2026-73553: (оцінка CVSS 7.5): Виправлено оминання RBAC через ignore_path_parameters_in_path_matching.

CVE Istio

• GHSA-qm8v-g4f9-qhjx (оцінка CVSS 6.8, Помірний): BackendTLSPolicy не вдається (fails open) до plaintext на sidecar проксі, коли його CA посилання невирішене.

Інші виправлення безпеки Istio

• Виправлено прогалину у валідації EnvoyFilter, де необмежений вираз proxyVersion для співпадіння міг спричинити надмірне споживання памʼяті та CPU istiod під час компіляції regex. Вираз співпадіння тепер обмежено 1024 символами. Авторство: Цю проблему повідомив Artem Cherezov.

Зміни

• Виправлено ситуацію взаємного блокування, через яку под агента вузла istio-cni міг не запускатися (наприклад, після перезавантаження вузла), оскільки втулок CNI пропускав створення клієнта Kubernetes для власного пода агента лише в разі увімкнення режиму ambient. Тепер попередня перевірка виконується також у режимі sidecar, тому под агента більше не блокується через kubeconfig, який він ще не встиг записати. (Тікет #60668)

• Виправлено помилку, через яку мережевий шлюз віддаленого кластера міг зникати з міжмережевої маршрутизації після оновлення облікових даних і не відновлюватися до перезапуску istiod. Тепер під час заміни реєстру на місці новий реєстр підключається до обробників агрегатного контролера, щоб його майбутні події, пов’язані зі шлюзами та сервісами, передавалися, а також шлюзи перезавантажуються один раз для врахування тих, що були виявлені під час синхронізації перед заміною. (Тікет #60920)

• Виправлено проблему в розгортаннях із кількома кластерами, через яку оновлення istio-remote-secret віддаленого кластера могло призвести до остаточного видалення фрагментів точок доступу для сервісів зі стабільними точками доступу в цьому кластері, що робило їх недоступними між кластерами до перезапуску istiod.(Тікет #61043)

• Виправлено гонитву під час запуску istiod, коли проба готовності могла повідомляти про готовність до того, як виділений сервер вебхуків для введення та перевірки (--httpsAddr, стандартне значення :15017) почав приймати з’єднання, що призводило до періодичних тайм-аутів з повідомленням failed calling webhook під час створення ресурсів одразу після того, як istiod став готовим. Це не впливає на розгортання, у яких веб-хуки використовують основний HTTP-сервер (порожнє значення --httpsAddr). (Тікет #61049)

• Виправлено проблему, через яку шлюзи вхідного трафіку оминали проксі waypoint для багатокластерних сервісів, коли віддалені робочі навантаження перебували в іншій мережі, що призводило до того, що політики авторизації не застосовувалися. (Тікет #61092)

• Виправлено проблему, через яку ресурси Deployment проксі шлюзу могли постійно не створюватися при запуску istiod. (Тікет #61095)

• Виправлено проблему, через яку под, обраний за допомогою workloadSelector у ServiceEntry, міг запускатися без цього сервісу в конфігурації вхідного трафіку свого sidecar. Трафік на цей порт не оброблявся відповідно до протоколу, заявленого в ServiceEntry, а PeerAuthentication на рівні порту не застосовувалася. Под не відновлювався самостійно; проблему можна було вирішити лише шляхом перезапуску istiod. (Тікет #61157)

• Виправлено проблему, через яку istio-cni вважав hostNetwork pod придатними для зарахування до ambient mesh. (Тікет #61168)

• Виправлено витік файлових дескрипторів у агенті вузла istio-cni: коли сканування procfs знаходило більше одного мережевого простору імен для одного пода, файловий дескриптор netns програшного кандидата відкидався без закриття, закріплюючи простір імен у ядрі до збирання сміття.

• Виправлено зовнішні провайдери SDS, налаштовані через extensionProviders, для використання налаштованого hostname сервісу як gRPC authority.

• Виправлено витік goroutine в процесі обрання лідера istiod, через який під час кожного циклу виборів (втрата та повторне здобуття лідерства) відбувався витік одного goroutine аж до завершення процесу. (Тікет #60843)

• Виправлено проблему, через яку використання CPU istiod зростало зі збільшенням кількості ресурсів AuthorizationPolicy. (Тікет #61254)

• Виправлено вирішення конфліктів ListenerSet для конфліктів hostname та протоколу. Конфліктні слухачі тепер коректно відхиляються, а стани статусу ListenerSet звітуються у відповідності з Gateway API 1.5. (PR #60775)

• Виправлено помилку, через яку перепідключення ztunnel (таке як періодичне перевикористання зʼєднання від keepaliveMaxServerConnectionAge) спричиняло повний push робочого навантаження (WDS). Istiod тепер призначає кожному WDS ресурсу версію на основі контенту і, коли перепідключений клієнт повідомляє версії, які він вже тримає через initial_resource_versions, повторно надсилає лише ресурси, що змінилися, поки клієнт був відключений. Старіші версії ztunnel, що не повідомляють версії, продовжують отримувати повний набір. (Тікет #1966)

• Виправлено генератор XDS api (обслуговування конфігурації MCP) таким чином, щоб він вимагав підтвердженої ідентичності панелі управління. Раніше будь-який клієнт, який міг підключитися до порту XDS Istiod, міг читати конфігурацію Istio у всіх просторах імен. Стандартно ENABLE_XDS_API_GENERATOR_AUTH=true; у разі необхідності для забезпечення сумісності вимкніть цю опцію за допомогою ENABLE_XDS_API_GENERATOR_AUTH=false.

• Виправлено проблему в API Gateway, через яку міжпросторові TLS-посилання certificateRef або caCertificateRef вирішувалися до перевірки авторизації ReferenceGrant, внаслідок чого статус ResolvedRefs слухача міг розкривати інформацію про наявність Secret або ConfigMap, на які посилалися, навіть якщо жоден дозвіл не дозволяв таке посилання. Тепер авторизація виконується першою, повертаючи RefNotPermitted для будь-якого посилання між просторами імен, яке не дозволено дозволом. Подяка: Про цю проблему повідомив Darryl Jaskolski.

• Виправлено уразливість SSRF під час отримання параметра jwksUri у методі RequestAuthentication istiod. Тепер istiod у стандартному режимі блокує на рівні викливу локальні адреси мережі та відомі адреси метаданих хмарних сервісів (наприклад, 169.254.169.254) і відхиляє отримані відповіді, які не є дійсними JWKS. Приватні та loopback діапазони залишаються доступними і можуть бути заблоковані за допомогою BLOCKED_CIDRS_IN_JWKS_URIS.

• Виправлено ситуацію, коли кілька анотацій sidecar.istio.io/* (proxyImage, bootstrapOverride, logLevel, componentLogLevel, agentLogLevel) інтерполювалися в шаблони інʼєкції sidecar/gateway без екранування вихідних даних, що могло дозволити спеціально сформованому значенню анотації ввести додаткові поля у згенеровану специфікацію pod або deployment. Тепер ці анотації послідовно екрануються у кожному приймачі шаблону. Подяка: Ця вразливість була виявлена та повідомлена localhost-detect.