Veeam, Terraform MCP, Django Patch Critical Flaws, Led by CVSS 10.0 Cross-Tenant Bug

What to prioritize when the CVSS numbers mislead

The summary lists the CVEs and fixes accurately. What it omits is the page's central argument: the headline scores do not give you a priority order, and two independent reasons cut against reading them that way.

First, the numbers are on different scales — Veeam scores on CVSS 4.0, the HashiCorp records on 3.1 — so the Veeam 9.5 and the Terraform 10.0 are not the same measurement. Second, the Veeam 9.5 (CVE-2026-58073, unauthenticated managed-agent credential theft) carries a high attack-complexity rating in its vector; "unauthenticated" here does not mean a straight-line exploit.

Which Terraform flaw is actually in reach depends on config

The 10.0 (CVE-2026-16498) and the 8.9 (CVE-2026-16496) are the same isolation failure in different modes, and which one applies to you is a configuration question, not a severity ranking:

flowchart TD
    A[Terraform MCP Server transport] --> B{Mode}
    B -->|stdio, local single-user| C[Unaffected]
    B -->|Streamable HTTP, stateless| D[CVE-2026-16498 10.0<br/>no unique session IDs]
    B -->|Streamable HTTP, stateful DEFAULT| E[CVE-2026-16496 8.9<br/>session ID sole cache key]

Stateless mode (the 10.0) must be deliberately enabled. Stateful mode (the 8.9) is the default for a central deployment — so for most shared installs the lower-scored bug is the one in reach. A third flaw, CVE-2026-14869 (SSRF, 8.6), lets an unauthenticated caller on the HTTP listener make the server send its bearer token to an attacker endpoint by passing the Terraform address as a query parameter instead of a header.

Interim mitigation (Terraform MCP)

If you cannot upgrade to 1.1.0+ immediately, the page states two actions: restrict network access to the Streamable HTTP listener to trusted users, and treat MCP session IDs as sensitive values. Note a version discrepancy the reader should verify: HashiCorp's umbrella bulletin lists affected versions 0.2.1–1.0.0, while the individual CVE records begin at 0.3.0; both agree 1.1.0 is the first fixed release.

Django: why the exploitation history doesn't fully carry over

The GeoDjango fix for CVE-2026-15307 is a backward-incompatible change — spatial lookups no longer accept dict values or non-GEOSGeometry strings (direct model-field assignments still do). The page adds context the summary lacks: Django's GIS code was actively exploited earlier in 2026 via CVE-2026-1207 (PostGIS raster SQL injection), with CrowdSec observing first attacks Feb 26 and steady probing since. But that reconnaissance fingerprints PostGIS-backed Django from outside, whereas the new flaw's documented route requires a staff account with view permission — so the existing probing "stops a step short of an actual way in." What carries over is attacker scrutiny on this code, not a ready exploit path.

The specific hardening limits are worth noting for detection: the GEOS DoS (CVE-2026-15830) is now capped at 198 collections, and the language-code DoS (CVE-2026-15337) now rejects codes over 500 characters. Django's older unsupported branches (5.1, 5.0, 4.2) were not evaluated and may also be affected.