Veeam, HashiCorp and Django Patch Critical Flaws in the Same Week: What to Check

Three software vendors patched critical flaws this week, and none of the bugs are related to each other. Veeam, HashiCorp and the Django project each pushed fixes rated 9.0 or higher. It is a reminder that critical vulnerability patching is not a single event on the calendar. It is a queue that never really empties.

Veeam’s backup console gets a second critical round

Veeam published its bulletin on 4 August. It covers four flaws in Service Provider Console, known as VSPC. Many managed service providers use VSPC to run backups for their clients. The worst flaw, CVE-2026-58073, scores 9.5. It lets an unauthenticated attacker impersonate a managed backup agent and steal its credentials. A second flaw, CVE-2026-58072, scores 9.0. It allows an arbitrary file write on the management server. Veeam says that write can lead to full remote code execution.

Two further high-severity bugs round out the set. One is a memory-exhaustion denial of service, CVE-2026-58067, scored 8.7. The other briefly exposes the proxied appliance API with Portal Administrator rights, CVE-2026-58071, scored 8.2. All four affect VSPC 9.2.1.33875 and every earlier version 9 build. The fix is version 9.3.0.35057, released 29 July.

This is VSPC’s second critical patch cycle in about three months. Businesses that outsource backup management to an MSP should ask about it. Treat it as routine patch management, not a one-off check. Ask which console build the provider runs, and when they last updated it.

A perfect 10 in HashiCorp’s Terraform MCP Server

HashiCorp’s advisory is tracked internally as HCSEC-2026-23. It covers terraform-mcp-server, a tool that lets AI coding assistants query and manage Terraform infrastructure. The headline bug, CVE-2026-16498, carries the maximum CVSS score of 10.0. In the server’s stateless HTTP mode, the underlying MCP library never assigns unique session identifiers. The credential cache built on top of it cannot reliably tell one user from another. One person’s Terraform token can end up serving somebody else’s request.

A related bug, CVE-2026-16496, hits the stateful mode that HashiCorp actually recommends for shared, centralised deployments. Anyone who obtains another user’s session ID can reach that person’s Terraform organisations and workspaces. A third issue, CVE-2026-14869, was found by researcher Juan Pablo Martinez Kuhn at Coinspect. It let an unauthenticated client redirect the server’s bearer token to an address of its own choosing. The redirect used a query parameter the server failed to validate.

All three are fixed in version 1.1.0, released 14 July, with a further hardening update in version 1.2.0 on 4 August. HashiCorp says deployments running only in local, single-user stdio mode were never exposed. Anyone who set up a shared Terraform MCP server for a team should act now. Put the upgrade at the top of this week’s critical vulnerability patching queue. That shared setup is exactly the configuration HashiCorp promoted when the tool went generally available in June.

Django closes a file-write path in GeoDjango

The Django project released its own fixes on 4 August too, bringing Django 6.0.8 and 5.2.17. The most serious of the four, CVE-2026-15307, sits in GeoDjango’s spatial lookups. Those lookups accepted string and dictionary values that the GDALRaster class then read as raster files. Depending on the driver, that could trigger a write to disk or an outbound network request under the Django process’s own permissions.

Exploiting the bug needs a staff account with view permission on a model that has a spatial field. An attacker would reach it through the admin changelist filter. So this is not an anonymous, internet-facing bug. It still matters for any site that gives outside contractors or junior staff limited admin access.

The other three fixes are lower stakes. One is a moderate stored cross-site scripting issue in how the admin renders URLField links. Another is a moderate denial-of-service bug from deeply nested geometry collections, which could crash the process with a segmentation fault. The last is a low-severity memory exhaustion path in the language-code cache. Django now caps nested geometry input at 198 collections and rejects language codes over 500 characters. Older, unsupported branches such as 5.1, 5.0 and 4.2 were not evaluated and may carry the same issues. Django’s fixes are the smallest item on this week’s critical vulnerability patching list, but still worth clearing on the next release cycle.

Why critical vulnerability patching can’t wait for exploitation

As of 5 August, none of the eleven CVEs across all three advisories appears in CISA’s Known Exploited Vulnerabilities catalogue, and no working public exploit has surfaced for any of them either. That is the best moment to patch: before an attacker has bothered to build the tooling. Waiting for exploitation before acting turns a routine update into an incident response.

The three bugs share a shape worth noticing. Each one lives in infrastructure that businesses trust to run quietly in the background: a backup console, an AI-assistant integration layer, a web framework. None of them is a public-facing application that people watch closely. That is exactly the kind of software an external penetration test is built to catch. So is a plain vulnerability assessment, done before an attacker gets there first. A high CVSS score is where the analysis starts, not where it ends, as Aardwolf’s look at a modestly scored but actively exploited Cisco firewall bug showed. Treat this week’s three advisories as a short, practical case for keeping critical vulnerability patching on a fixed schedule, not just a reactive one.