Did every Loom deployment expose super-admin access?

No. The advisory limits the affected condition to deployments lacking both a Cognito user pool and an active external identity provider. A deployment with a working provider followed a different authentication path. Teams should still verify the installed version and run anonymous denial tests because configuration can drift or an IdP can become unreachable. Forks may also retain old authentication code.

Does loopback-only development mode make a deployed listener safe?

The 1.6.1 behavior reserves the bypass for an explicit local-development opt-in and a loopback request. It also rejects forwarding headers for that path. Operators still need to keep the opt-in out of deployed configuration and confirm startup behavior behind their actual proxy. Loopback development mode is narrow. It is a convenience, not an authentication design for a shared environment.

Can an AI gateway prevent CVE-2026-103956 exploitation?

An AI gateway on authenticated user-or-agent-to-LLM HTTP traffic cannot repair missing authentication on Loom's administrative API. Its relevant control starts later, after Loom authenticates the caller and constructs a model request. The gateway can then apply identity-bound policy to that routed request and preserve a decision record. The exposed management plane needs the vendor patch plus working identity and network controls.

Loom CVE-2026-103956: An IdP-Less Deployment Granted Super-Admin Access

Loom CVE 2026 103956 turned one fresh-deployment state into full administrative access. With no Amazon Cognito user pool and no active external identity provider, the Loom for AWS backend assigned any incoming request a fixed super-admin identity. No Authorization header was required. AWS Labs published the advisory on October 2, 2026, rated it CVSS 10.0, and identified 1.6.1 as the patched release. I would treat the first network-reachable minute as the start of production for any agent control plane that stores credentials and MCP configuration.

TL;DR

CVE-2026-103956 affected the precise state where Loom had neither a Cognito user pool nor an active external identity provider.
Reachable unauthenticated clients could receive every scope and administer agents, memories, credentials, settings and security configuration.
Loom 1.6.1 makes local development bypass explicit, loopback-only and fail-closed for other requests.
Keep the backend unreachable until identity works, then test anonymous denial and scoped access before opening the listener.

Loom CVE 2026 103956 had a narrow trigger and total impact

The AWS Labs security advisory describes a two-part condition: no configured Cognito user pool and no active external identity provider. In that state, get_current_user returned the fixed t-admin and g-admins-super identity unconditionally, with every system scope.

A network client able to reach the backend could read or change agents and memories, plus credentials and settings. Security or authorizer configuration was also exposed. The same access permitted agent invocation.

The CVSS vector records network reachability and low complexity, with no privileges or user interaction. It also records changed scope and high impact across confidentiality, integrity, and availability. The advisory reports no active exploitation. This article makes no claim of a breach or campaign.

The vulnerable interval begins before agent setup finishes

The dangerous state is common during installation. An operator deploys the backend and opens a security group for testing, planning to connect Entra ID or another provider next. Meanwhile, the identity configuration remains empty as the admin page appears in a browser. In the vulnerable versions, that sequence made missing identity behave like successful super-admin authentication.

Put the deployment sheet on a conference-room screen. Mark the backend listener in red, and keep it red until the IdP returns a valid token and an anonymous request gets 401. A low-privilege test identity must also get 403 on an admin route. Agent catalog setup waits behind those tests. Identity should be the first dependency proved and the last dependency permitted to fail open.

Version 1.6.1 makes local development an explicit exception

AWS Labs states in the version 1.6.1 release notes that the no-Cognito and no-IdP bypass previously activated automatically. Now, the release requires LOOM_ALLOW_UNAUTHENTICATED_LOCAL_DEV as an explicit opt-in and limits the bypass to loopback clients. Every other request fails closed with 401.

The patched source adds another safeguard. A request carrying proxy forwarding headers cannot qualify for the loopback bypass, and startup checks reject risky deployed combinations. This matters because a widened FORWARDED_ALLOW_IPS setting could otherwise make a forged X-Forwarded-For value appear local.

A local-development switch belongs on a developer machine. A deployment manifest or task definition should reject it during review. So should a Helm values file.

A safe deployment gate proves identity before reachability

Upgrade every affected deployment and fork to 1.6.1 or later. Before exposing the backend beyond loopback, require evidence for four states.

An anonymous request must return a recorded 401 response. A valid low-scope identity reaches its permitted route but gets 403 on an administrative route. A valid administrator reaches the intended admin route. If the IdP is lost, the result is denial instead of a fallback identity.

Network restrictions reduce exposure during the change, yet the vendor advisory says they do not fully close the issue without upgrading. Record the image digest and Loom version. Add the IdP issuer and test identities, then put the route results and reviewer in the same release artifact.

Re-run the gate after proxy changes. Forwarded-header trust alters the assumptions behind loopback detection. The MCP security guide provides the broader control context for platforms that store MCP connections.

The management-plane defect sits outside DeepInspect's boundary

CVE-2026-103956 is a Loom management-plane authentication defect. DeepInspect does not patch Loom, configure Cognito, restrict the Loom admin listener, or repair an exposed API. Those duties remain with the Loom operator, along with the network and identity or deployment systems that own the control plane.

A separate path begins after the management plane is secured. An authenticated Loom user or agent may send an HTTP request to an LLM carrying application-supplied identity, prompt content, a model destination, and delegated workflow context. The AI agent authorization guide covers policy at that request boundary. The post-authentication gap explains why a valid login still leaves each model request needing its own authorization decision.

DeepInspect

DeepInspect sits between authenticated users or agents and HTTP-based LLM endpoints. For Loom model traffic routed through that boundary, it evaluates application-supplied identity, request classification, model destination, and policy before forwarding. Every outcome creates a signed, tamper-evident per-decision record outside Loom's write path, including permits, modifications and blocks.

That scope begins after CVE-2026-103956 has been fixed and the Loom management plane has passed its identity gate. It gives the separate outbound AI request path deterministic authorization and evidence without claiming to secure the admin API. Book a technical deep dive at deepinspect.ai.