July 2026: two high-severity advisories, both on paths that need no login

· JD + AI · Umbraco

July 2026: two high-severity advisories, both on paths that need no login

Two things in July forced work. On 7 July Umbraco patched a high-severity flaw in the Delivery API. On 28 July it patched a high-severity flaw in Umbraco Forms. Neither one required an authenticated user, and if you have not done both, go check your version numbers before you read the rest of this.

Everything else the month produced was the same December date argued from four directions. That is the actual story of July, and it is worth telling, but the patches come first.

7 July: the Delivery API handed protected content to people who should not have it

The advisory is by Andy Butland on Umbraco's own blog. Affected: Umbraco 13.0.0-13.15.0, 17.0.0-17.5.2 and 18.0.0-18.0.1. Fixed in 13.15.1, 17.5.3 and 18.0.2, published as GHSA-wr57-hqmp-fgvh, with Ardya Suryadinata credited for the disclosure.

The mechanism is the part to understand, because it decides whether you are affected. Protected content could be retrieved by unauthorized callers when that content is picked on an unprotected document and pulled into the response through output expansion. A similar path exposed referenced items that configuration was supposed to restrict by type. Output expansion is not an exotic setting. It is the thing you switch on the first time a front end needs picked content in one request instead of three, and members-only content picked onto a public page is an ordinary content model rather than a mistake. Umbraco Cloud sites on the latest minor were patched the same day; anything not already on 13.15.x, 17.5.x or 18.0.x needed a minor upgrade first. 13.15.1 also moved the MessagePack dependency off a version flagged as vulnerable, which is a free win if you were behind.

23 to 28 July: Forms accepted submissions that were never finished

Rick Butterfield published the heads-up on 23 July: patch coming on 28 July at 08:00 UTC, severity high, affected ranges disclosed (Forms 13.0.0-13.9.7, 17.0.0-17.4.6, 18.0.0-18.0.4) and details deliberately withheld until release. It landed on schedule. The patch post, also by Butterfield, gives the fix versions: 13.9.8, 17.4.7 and 18.0.5, with Cloud upgraded automatically and Ismael Machuca credited.

The flaw was in how Forms handled submission progression. It could be manipulated so the server treated a form as complete early, and in the advisory's words "an unauthenticated user could finalise a submission without completing the intended submission flow". Server-side validation that normally runs before acceptance could be skipped, and configured workflows still fired. Single-page forms are affected too, which is the sentence people skip when they assume "multi-page" means "not us".

That last detail is why the package bump is the easy half. If one of your forms triggers anything downstream, a CRM record, a notification, a fulfilment step, then the entries stored between whenever you went vulnerable and the day you patched are the thing to audit. The code is fixed by NuGet. The junk that already reached your CRM is not.

Both were unauthenticated, and both sat on surface we add on purpose

A backoffice vulnerability needs someone logged in. These two needed nobody. The Delivery API and public forms are the two things a current Umbraco build most often exposes to the open internet deliberately, because that is what headless and lead capture are for.

Five years ago the advisory pattern for this CMS skewed towards the backoffice, where the blast radius is bounded by who has an account. "Headless plus a contact form" is a different risk profile from an all-in-one MVC site with a login-gated admin, and July is the month the advisory record started to look like the architecture we have all been shipping.

Everything else in July was the December date

Corné Hoskam went from 13.5.2 to 17.5.3 in about two hours on Umbraco Cloud, .NET 8 to .NET 10 included, and reports that the TinyMCE-to-Tiptap data migration ran without him touching it. Read the caveats before you quote the two hours at a client. His site had no custom backoffice code, and he says plainly that if you depend on v13 community packages or custom backoffice work, "the heavy parts of the upgrade are in there". He also puts Umbraco 13's end of life in December of this year, citing Umbraco's own lifecycle page. We only have his post for that date, not the vendor page itself, so confirm it on umbraco.com before a budget depends on it.

Tim Gaunt argues the opposite case on his own company's blog at TSD Digital, and does it well: "End-of-life is a date on the vendor's calendar. It isn't a fact about the customer's business." He still runs an Umbraco v4 site on purpose. His distinction between a managed risk and plain neglect, built on exposure and containment rather than version numbers, is the most useful thing anyone wrote about upgrades this month. TSD sells long-tail support and its own Umbraco-derived product, so this is not a disinterested position. It is still the right one.

Chris Osterhout at Diagram, an agency that implements Umbraco commercially, makes the case for 17 as more than an escape hatch, on the argument that AI checks belong inside the editorial workflow rather than in reports afterwards: "AI can become part of the publishing process instead of another tool you use afterward". The mechanism he describes, drafted metadata and accessibility checks that can hold a publish, is buildable on 17 today. The piece is marketing shaped as strategy, and the strategy is sound anyway.

Underneath all of it, .NET. Microsoft's .NET Team shipped .NET 11 Preview 6, which matters to Umbraco not because you should install a preview but because 17 targets .NET 10 and 11 is what the next LTS conversation will be about. Pablo Lopes announced a free .NET Modernization for Beginners course built around the GitHub Copilot modernization agent; it targets legacy ASP.NET rather than Umbraco, but it produces exactly the artefacts Hoskam produced by hand, an assessment, a plan and a task list. David Ortinau's post on CoreCLR and the Mono timeline is in this month's set because it rides the .NET 11 thread; if you only run Umbraco on the web it changes nothing for you, and saying so is better than padding it.

On the front end, Next.js 16.3.0-preview.10 went out with prefetch and route-cache work. There is no human author on it, only Vercel's release bot. A preview is not something to ship, but prefetching is the seam where a Delivery API-backed front end wins or loses its response times, so read it before 16.3 goes stable.

Umbraco's own July was about agents

Five of the fourteen sources in this post, 36%, come from Umbraco's own blog. Three of those are the advisories above, where the vendor is the only correct source. The other two are product announcements, and a vendor writing about its own launch is an announcement rather than analysis. Four more come from Microsoft's .NET blog, which is the same relationship one layer down.

Bolette Kern announced Umbraco Automate, a drag-and-drop automation product for Umbraco 17+, open source, with no cap on runs or actions and first-party connectors for Forms, Deploy, Engage, Commerce, Workflow and UI Builder. The interesting part is not the canvas, it is that the connectors ship from HQ, which is what decides whether this survives contact with a real client workflow.

Phil Whittaker's post on MCP as a platform is the more consequential of the two: a shared Base MCP SDK under every Umbraco MCP server, a CLI exposing the same toolset over a different transport, MCP chaining so a package author can compose existing document and media tools instead of reimplementing them, and hosted MCP as a streamable HTTP endpoint with OAuth. Whittaker says Umbraco as a remote MCP will be available on all Umbraco Cloud tiers in the summer of 2026. That is the vendor's own roadmap statement, so weigh it as one.

Adjacent to that, Jeff Handley shipped v2.0 of the official MCP C# SDK against the 2026-07-28 spec revision, which drops the initialize handshake and the Mcp-Session-Id header in favour of self-contained stateless requests, while staying backward compatible with v1 code. If you are building an Umbraco MCP server, the transport just changed underneath you and the sticky-session problem went away with it.

The best engineering writing of the Umbraco month carries no byline at all. The page credits nobody; the post is written in the first person by Examine's maintainer, on the Shazwazza blog, which is Shannon Deminick's. GitHub Next's agentic workflows ran against Examine on a schedule for two months: 124 successful Perf Improver runs, 24 merged performance PRs, three shipped releases, and ManagedQuery down from 11.42 ms to 2.17 ms on a 1,000-document index with allocations from 1,323 KB to 371 KB. The author also sells ExamineX, a managed hosted service running on the same internals, and says so in the post. The benchmarks are in the repo next to the code they measure, which is more than most AI-productivity claims come with.

What this month should change

Umbraco spent July shipping surface that answers to machines and patching surface that answered to strangers. Those are different codebases and I am not claiming the new one is unsafe. The narrower claim is harder to argue with: the share of an Umbraco install that responds to an unauthenticated request has grown with every release since the Delivery API landed, hosted MCP on every Cloud tier grows it again, and July is the first month where both high-severity advisories landed in exactly that shape.

So the thing to change is inventory, not attitude. If you cannot answer "which endpoints on this site respond without a backoffice session, and what can each of them see" in ten minutes from a document you already keep, you will be answering it under time pressure on the day of the next advisory. Gaunt's line is the counterweight and it points the same way: an old version somebody is watching beats a current one nobody is. The inventory is the watching. Version numbers only tell you what to do next.

Sources

umbraco · umbraco-cms · umbraco-apis · umbraco-cloud · product · community · release · sitecore-search

2026 © Umbracolombia - All rights reserved.