Friday, 25 September 2026

Switzerland's parliament refers a motion ordering a sovereign government cloud and independent data-exchange platform to the Federal Council, over the Federal Council's own recommendation to reject it

Switzerland's Federal Assembly's own Curia Vista record for motion 24.3209, "Für eine souveräne digitale Infrastruktur in der Schweiz im Zeitalter der künstlichen Intelligenz," shows its status moved to "Überwiesen an den Bundesrat" (referred to the Federal Council) on 2026-09-23, with the National Council's own committee deliberation on the motion recorded as concluded shortly before (Swiss Federal Assembly, Curia Vista, 2026-09-23/BusinessStates?$format=json)). The Council of States adopted the motion first, in March 2026, by a 31:11 vote (Netzwoche, 2026-03-23); the referral status now recorded is the outcome for a motion that has cleared both parliamentary chambers, despite the Federal Council formally recommending rejection. The motion instructs the Federal Council to submit a legal revision letting the federal government, cantons, research institutions and the private sector jointly advance, co-finance, steer and monitor a sovereign digital infrastructure, specifically an independent cloud service and an independent data-exchange platform intended to host administration, industry and critical-infrastructure data inside Switzerland ("Die Motion verlangt eine Gesetzesrevision, damit der Bund gemeinsam mit Kantonen, Forschungsinstitutionen und Privatwirtschaft den Aufbau einer souveränen digitalen Infrastruktur vorantreiben, mitfinanzieren, steuern und überwachen kann," translated from German, Laux Lawyers AG, 2026-09). The Federal Council's own rejection cited existing legal bases under the EMBAG federal-IT-infrastructure act and ongoing work on Swiss digital-sovereignty strategy as already covering the request (Netzwoche, 2026-03-23); parliament decided further legislative action is required regardless.

This is a directional, strategic-level signal rather than an immediate operational obligation: the Federal Council must still draft and pass the legislation before any sovereign-cloud or exchange-platform requirement takes effect. It is nonetheless the trigger event for a legislative process that will determine where and by whom federal, cantonal and critical-infrastructure workloads may legally be hosted, with downstream implications for data-residency and supply-chain risk assessments across the constituency this brief serves. Public-sector IT and procurement teams tracking Swiss Government Cloud planning should treat this motion as the point at which a domestic-hosting requirement moved from proposal to a parliamentary mandate the Federal Council cannot simply decline.

CVE-2026-5430, WSO2 API Manager, API Control Plane, Traffic Manager, Universal Gateway: a JWT algorithm-confusion bypass reaches full administrative control of the API gateway, exploited since 13 September (CVSS 10.0/9.8)

WSO2's API management stack sits between client applications and the backend services, keys and secrets it fronts, so a broken authentication boundary at the gateway compromises everything behind it. CVE-2026-5430 is exactly that break: a JSON Web Token verifier that should refuse any token signed with an algorithm it does not support instead accepts it, so a forged token is treated as a legitimate, admin-scoped session (WSO2, 2026-05-03). The bug reaches WSO2 API Manager, API Control Plane, Traffic Manager and Universal Gateway across the release lines WSO2's advisory lists (4.1.0 through 4.6.0), and needs no credentials and no user interaction, WSO2 rates it CVSS 10.0 on multi-tenant deployments and 9.8 on single-tenant, where impact stays inside one security-authority boundary. WSO2 published the fix on 2026-05-03; four months later, on 2026-09-13, exposure-management firm watchTowr's honeypot network caught the first forged-token exploitation attempt in the wild, and watchTowr says it "easily reproduced" the vulnerability based on the vendor's own patch (SecurityWeek, 2026-09-16). CISA added CVE-2026-5430 to its Known Exploited Vulnerabilities catalog on 2026-09-24, alongside an unrelated Adobe Commerce flaw (CISA, 2026-09-24).

The forged admin token is not a narrow read-only leak: watchTowr's Yordan Ganchev describes it as yielding "access to every API backend endpoint and its credentials, consumer keys and secrets for every registered application," and notes the gateway is "by definition made to intercept API requests on their way to internal systems," turning a compromised node into what he calls a "Lateral Movement-as-a-Service" product for reaching everything the gateway fronts (SecurityWeek, 2026-09-16). Ganchev also cautions that the observed attack targeted the wrong WSO2 product in watchTowr's own honeypot mix, but the same forged payload worked when replayed against the correct one; a coincidence that will not repeat on every real deployment. One notable inconsistency for defenders relying on the KEV catalog alone: CISA's own alert lists this addition as "WSO2 Multiple Products Path Traversal Vulnerability", a title that matches neither WSO2's advisory nor any researcher account, all of which agree this is a JWT-signature bypass, not path traversal (CISA, 2026-09-24; WSO2, 2026-05-03). A team that searches its KEV feed only for "path traversal" risks missing that this is the entry meant.

Kill chain: an attacker crafts a JWT whose header names a signing algorithm the gateway's verifier does not support, then presents it at the API Manager, Control Plane, Traffic Manager or Universal Gateway front door (T1190, exploiting the public- or partner-facing gateway interface); the verifier's missing algorithm check accepts the token instead of rejecting it, so the forged credential (T1606, Forge Web Credentials) is treated as an authenticated, administrator-scoped session with no legitimate login behind it. From that session the attacker can read every backend endpoint's credentials, every registered application's consumer keys and secrets, and tap API traffic passing through the gateway to internal systems.

Hunt and detection, telemetry class first: in gateway and Carbon HTTP access and authentication logs, look for admin-scoped sessions or privileged API calls with no corresponding identity-provider login event in the same window, that absence, not any single request, is the signal. Where a WAF or reverse proxy in front of the gateway logs JWT or Authorization header fields, check for alg values a correctly configured verifier should never have accepted. In application and consumer-key audit trails, flag reuse, mass export, or unexpected changes to registered applications' keys and secrets immediately following an anomalous authentication event. Start any hunt at 2026-09-13, the date of watchTowr's first observed exploitation attempt, and only look earlier with a specific reason to. Triage: a legitimate admin session traces back to a real, logged identity-provider authentication; an admin-scoped session or privileged API call with nothing behind it in the identity provider's own logs is the discriminator; an old version banner or a single stray Bearer token alone is not enough to escalate on.

Hardening: inventory every WSO2 API Manager, API Control Plane, Traffic Manager and Universal Gateway node (including partner-facing, OEM and forgotten lab instances) and bring each to its fixed update level (community users can apply WSO2's published fixes directly from its carbon-apimgt and product-apim repositories; support subscribers apply the corresponding WSO2 Updates release). Where immediate patching is not possible, remove management and gateway interfaces from public exposure. Because upgrading fixes the software but says nothing about the window between May and the patch date, any node found running below the fixed level should be treated as untrusted: rotate consumer keys, application secrets and admin credentials, and review every registered application and backend the gateway fronted before trusting it again (WSO2, 2026-05-03; Inception Security, 2026-09-21).