Yaook

By thread

yaook@lists.alasca.cloud

July 2026

1 participants
2 messages

Re: [Announce] [Security Advisory][neutron] CVE-2026-55707

by Stefan Hoffmann

A small correction: you need to update the Neutron operator, not Keystone. On 7/29/26 17:03, Stefan Hoffmann via Announce wrote: > Hi Yaook users, > > OpenStack published a CVE for neutron. > > Tim Shephard reported that a project member can use PUT > /v2.0/subnetpools/{id}/onboard_network_subnets to onboard subnets from > another project's shared network into the caller's own subnetpool. The > API only checks that the supplied network_id is visible to the caller. > If the network is RBAC or globally shared, the check passes, and > Neutron updates every matching subnet on that network to use the > caller-controlled subnetpool. If the caller's subnetpool is associated > with an address scope, the victim router interface is synced with the > attacker-controlled address scope. > > This lets a shared-network consumer mutate another project's > persistent subnet state and alter L3 routing, NAT, and address-scope > behavior for victim routers. > > The following images are vulnerable: > neutron images before 1.0.206 > yaook release before 3.1.1 > If this image is used in your cluster for the neutron-api deployment, > the cluster is vulnerable. > The fixed image has been built in a private pipeline[2] which has been > published alongside this advisory[1] to prove the image provenance. > > We recommend to immediately add a YAOOK_OP_VERSIONS_OVERRIDE[3] > variable to your Keystone operator container to pull the image before > the YAOOK comprehensive release is ready. > > operator: > extraEnv: > - name: YAOOK_OP_VERSIONS_OVERRIDE > value: | > { > "registry.yaook.cloud/yaook/neutron-2023.2": > "registry.yaook.cloud/yaook/neutron-2023.2:1.0.206", > "registry.yaook.cloud/yaook/neutron-2024.1": > "registry.yaook.cloud/yaook/neutron-2024.1:1.0.206", > "registry.yaook.cloud/yaook/neutron-2024.2": > "registry.yaook.cloud/yaook/neutron-2024.2:1.0.206", > "registry.yaook.cloud/yaook/neutron-2025.1": > "registry.yaook.cloud/yaook/neutron-2025.1:1.0.206", > "registry.yaook.cloud/yaook/neutron-2025.2": > "registry.yaook.cloud/yaook/neutron-2025.2:1.0.206", > "registry.yaook.cloud/yaook/neutron-2026.1": > "registry.yaook.cloud/yaook/neutron-2026.1:1.0.206" > } > > More info can be found in our security advisory[1]. > > Regards > Stefan > > [1] https://yaook.cloud/security-advisories-cve-2026-55707/ > [2] > https://gitlab.com/yaook-security/images/neutron/-/pipelines/2699882611 > [3] > https://docs.yaook.cloud/user/references/env-reference.html#envvar-YAOOK_OP… > > > _______________________________________________ > Announce mailing list -- announce(a)lists.alasca.cloud > To unsubscribe send an email to announce-leave(a)lists.alasca.cloud -- Stefan Hoffmann DevOps Engineer Cloud&Heat Technologies GmbH Königsbrücker Straße 96 | 01099 Dresden +49 351 479 367 36 stefan.hoffmann(a)cloudandheat.com | www.cloudandheat.com Green, Open, Efficient. Ihr Cloud-Service- und Cloud-Technologie-Provider aus Dresden. https://www.cloudandheat.com/ Commercial Register: District Court Dresden Register Number: HRB 30549 VAT ID No.: DE281093504 Managing Director: Nicolas Röhrs Authorized signatory: Dr. Marius Feldmann

July 30, 2026

[Security Advisory][neutron] CVE-2026-55707

by Stefan Hoffmann

Hi Yaook users, OpenStack published a CVE for neutron. Tim Shephard reported that a project member can use PUT /v2.0/subnetpools/{id}/onboard_network_subnets to onboard subnets from another project's shared network into the caller's own subnetpool. The API only checks that the supplied network_id is visible to the caller. If the network is RBAC or globally shared, the check passes, and Neutron updates every matching subnet on that network to use the caller-controlled subnetpool. If the caller's subnetpool is associated with an address scope, the victim router interface is synced with the attacker-controlled address scope. This lets a shared-network consumer mutate another project's persistent subnet state and alter L3 routing, NAT, and address-scope behavior for victim routers. The following images are vulnerable: neutron images before 1.0.206 yaook release before 3.1.1 If this image is used in your cluster for the neutron-api deployment, the cluster is vulnerable. The fixed image has been built in a private pipeline[2] which has been published alongside this advisory[1] to prove the image provenance. We recommend to immediately add a YAOOK_OP_VERSIONS_OVERRIDE[3] variable to your Keystone operator container to pull the image before the YAOOK comprehensive release is ready. operator: extraEnv: - name: YAOOK_OP_VERSIONS_OVERRIDE value: | { "registry.yaook.cloud/yaook/neutron-2023.2": "registry.yaook.cloud/yaook/neutron-2023.2:1.0.206", "registry.yaook.cloud/yaook/neutron-2024.1": "registry.yaook.cloud/yaook/neutron-2024.1:1.0.206", "registry.yaook.cloud/yaook/neutron-2024.2": "registry.yaook.cloud/yaook/neutron-2024.2:1.0.206", "registry.yaook.cloud/yaook/neutron-2025.1": "registry.yaook.cloud/yaook/neutron-2025.1:1.0.206", "registry.yaook.cloud/yaook/neutron-2025.2": "registry.yaook.cloud/yaook/neutron-2025.2:1.0.206", "registry.yaook.cloud/yaook/neutron-2026.1": "registry.yaook.cloud/yaook/neutron-2026.1:1.0.206" } More info can be found in our security advisory[1]. Regards Stefan [1] https://yaook.cloud/security-advisories-cve-2026-55707/ [2] https://gitlab.com/yaook-security/images/neutron/-/pipelines/2699882611 [3] https://docs.yaook.cloud/user/references/env-reference.html#envvar-YAOOK_OP… -- Stefan Hoffmann DevOps Engineer Cloud&Heat Technologies GmbH Königsbrücker Straße 96 | 01099 Dresden +49 351 479 367 36 stefan.hoffmann(a)cloudandheat.com | www.cloudandheat.com Green, Open, Efficient. Ihr Cloud-Service- und Cloud-Technologie-Provider aus Dresden. https://www.cloudandheat.com/ Commercial Register: District Court Dresden Register Number: HRB 30549 VAT ID No.: DE281093504 Managing Director: Nicolas Röhrs Authorized signatory: Dr. Marius Feldmann

July 29, 2026