What landed in CVE-land this week: federation, registries, and the slow death of perimeter assumptions

Mondays are for sorting through the wreckage of the prior week. The disclosure firehose ran hot through the back half of May, and four families of vulnerability stood out, not because any single CVE was novel, but because their aggregate pattern matters: identity-plane assumptions are failing, supply-chain trust is degrading at the registry boundary, multi-tenant isolation continues to be aspirational, and the API gateway is the new perimeter that nobody is testing as one.

This is the weekly CVE digest. We pulled from the public ledger, our own scanner telemetry, and the small army of red-team probes that landed in our continuous monitoring suite this cycle (20 RED-APIGW-EXT, 16 RED-FEDCHAIN-EXT, 18 RED-TENANT-EXT, and 18 RED-CONTREG-EXT, for the operators reading along).

1. Federation, again: SAML and OIDC are leaking trust at the seams

The week's most consequential cluster is OIDC + SAML federation, specifically the seam between identity provider and relying party. CVE-2026-32104 (a token-substitution flaw in a popular OIDC middleware) and CVE-2026-31987 (a SAML assertion-replay window) both share a common defect: the relying party trusts a claim that the IdP never authoritatively signed, or signs a claim the IdP never issued.

What changed this week is exploitability. Two of the disclosures came with working PoCs. Both PoCs reuse a pattern we have been instrumenting since March: forge or steal a partial assertion, splice it into a valid envelope, and rely on the relying party to validate the envelope rather than the inner claim. The pattern is older than either CVE. The fact that it ships in middleware that thousands of teams reach for as a "secure default" is what makes the disclosures expensive.

A defensible posture today does three things. First, verify the inner claim, not just the outer signature. Second, bind the assertion to a transport-layer fingerprint where the standard permits, which kills cross-binding replay outright. Third, age-out assertions aggressively. Five minutes is the IETF default for a reason; we still see 24-hour windows in production.

# A quick triage probe for the OIDC token-substitution class.
# Replay a captured id_token from one client_id against another in the same realm.
curl -sS -X POST "https://idp.example/oauth2/userinfo" \
  -H "Authorization: Bearer $CAPTURED_ID_TOKEN_FROM_CLIENT_A" \
  -H "X-Client-Id: client-b-distinct-from-issuer" \
  | jq '.sub, .aud'
# If `aud` does not match `X-Client-Id` AND userinfo returns 200, the
# relying party is not validating the audience claim.

This is a defender's test, not an attacker's payload. Run it against your own surface. If it returns a 200 with the wrong aud, you have the same defect class as the week's federation CVEs.

2. Container registry abuse moves from theoretical to practiced

CVE-2026-29155 is the more interesting of two registry-side disclosures, because it weaponizes a feature, not a bug. The OCI distribution spec permits referenced manifests, which means a registry client following a tag may end up pulling a multi-arch index whose constituent manifests live in a different repository, or even a different registry altogether. The vulnerable client follows the reference without re-validating the trust chain. Push a poisoned tag in a low-privilege namespace and you can hijack what an unrelated tenant pulls.

The mitigation is policy, not patch. Most production registries can be configured to refuse cross-namespace manifest references; almost none ship with that policy on by default. We added eighteen probes to the RED-CONTREG-EXT family this cycle that exercise this exact behavior, and the early read across continuous-monitoring scans is that roughly two-thirds of audited registries accept the cross-reference and a non-trivial subset will also serve it to a downstream puller without warning.

The defensive checklist is unromantic. Pin to digest, not tag. Sign manifests with cosign and verify on the way in. Configure your registry to refuse cross-namespace manifest references. Re-validate the trust chain on every pull rather than caching by tag.

3. Multi-tenant IDOR: the bug that will not die

The third cluster is multi-tenant IDOR. CVE-2026-28771 is the headline (a SaaS billing portal that derived tenant scope from a client-supplied header), but the long tail is what matters. Eighteen of our new RED-TENANT-EXT probes are variations on the same theme: the application authenticates the user, then derives "which tenant is this user acting on" from a parameter the user controls.

Patterns we see this week:

• A tenant_id query parameter that the server uses to scope a query, with authorization checks only on the user, not on the tuple of (user, tenant_id).
• A JWT that includes the user's tenant claim, but the server prefers a query-parameter override "for support tooling," which the production app never disables.
• A subdomain-based routing rule where the path under tenant-a.example.com/api/... is rewritten to a shared backend that uses the user's identity but a hostname-derived tenant identifier, and the hostname header is trivially spoofable on a misconfigured reverse proxy.

If your application has a tenant dimension, the most useful single test is to authenticate as a real user in tenant A, then replay the request with the tenant identifier from tenant B in every place it appears (header, query, body, path, JWT claim). If any field-flip returns data, you have an authorization gap. We do this on every continuous-monitoring scan now, and the hit rate is higher than it should be.

4. The API gateway is the new perimeter

Twenty fresh API-gateway disclosures landed this cycle, ranging from request-smuggling at the gateway-to-origin hop (CVE-2026-30214) to header-injection that bypasses gateway-level WAF rules (CVE-2026-29903). The unifying observation is that the API gateway is now treated as the front door, but it is rarely tested as a perimeter device. It accumulates routing rules, transformation logic, auth shims, and rate-limit policy, and the assumption is that each component layered on top is configured correctly, in concert with every other component, on every route.

That assumption breaks. The week's smuggling CVE works because the gateway and the origin disagree on how to interpret a header that controls request boundaries. The header-injection CVE works because the WAF strips a header on the way in but a transformation policy re-adds it on the way out, after the WAF has finished inspecting. Both bugs are well within the gateway's own contract. Both ship as default routes.

The defense is to test the gateway like a perimeter device. Send the malformed input. Compare what the gateway accepts against what the origin parses. Diff the header set in each direction. Validate that every WAF rule sees the request the origin sees, not the request the client sent.

What the week says about the next one

Four families. One pattern. Trust boundaries that are documented in the design and skipped in the implementation. The defensible response is not patch velocity, it is continuous probing of the boundaries themselves. The CVEs above will be replaced by next week's CVEs in the same families, and the only way to know whether your particular instance is exposed is to test it on every change, on every dependency bump, on every routing rule edit.