[ Article ]•AI Safety & Security•

Aug 28, 2026

•7 min read

Three CVEs, One Root Cause: August 2026 Exposed the Agent Authorization Boundary

August 2026 produced three agent vulnerabilities that look unrelated on paper. One is a Microsoft cloud service, one is a Microsoft 365 assistant, one is an open-source Java framework. Different vendors, different languages, different threat models.

They share a root cause: the system granted the agent more authority than the request that invoked it.

That is the class of bug worth understanding, because it does not get fixed by better prompts.

What Happened

Two disclosure events, eight days apart.

August 11 — Microsoft Patch Tuesday. A large release: Cisco Talos counted 421 CVEs including 62 critical, while CrowdStrike’s analysis put the total at 415. One zero-day was exploited in the wild — CVE-2026-68820, an elevation-of-privilege flaw in the Windows Ancillary Function Driver for WinSock, rated CVSS 7.0. But the highest-severity items were agent services.

August 20 — Broadcom’s Spring advisory batch. Sonatype tracked 91 CVEs across Spring Framework and related projects, spanning Spring Security, Spring Cloud Config, Spring AI, Spring Data REST, Spring Integration, Reactor Core, Reactor Netty, Spring AMQP, and Spring Batch. At time of publishing, Sonatype reported 148,608 software components affected across the supply chain.

Three of those CVEs describe the same failure.

The Three Failures

CVE-2026-62830 — Azure SRE Agent (CVSS 9.9)

Azure SRE Agent is an AI service that autonomously monitors, diagnoses, and remediates issues in Azure-hosted infrastructure. Microsoft’s description: “Missing Authorization could allow an authorized attacker to elevate privileges over a network.”

The vector is what makes it a 9.9: missing authorization (CWE-862), network-based, no user interaction required, low attack complexity, and — critically — Scope: Changed, with impact across confidentiality, integrity, and availability.

Scope: Changed is the whole story. It means the vulnerability lets an attacker cross the agent’s security boundary and reach resources beyond it. An SRE agent’s blast radius is defined by its managed identity: runbooks, telemetry, incident tooling, and every Azure resource that identity can touch. The agent is not the target. The agent is the path.

Microsoft shipped a service-side fix — no customer patch is required.

CVE-2026-59118 — Microsoft Copilot Cowork (CVSS 9.3)

“Improper Authorization could allow an unauthorized attacker to elevate privileges over a network.” This is CWE-285, network-based, Scope: Changed, affecting confidentiality and integrity. Unlike the SRE Agent flaw, user interaction is required — which is what keeps it at 9.3 rather than higher.

The severity comes from reach. Copilot Cowork operates across Microsoft 365 content, so an authorization flaw in it is a direct privilege path into organizational documents. Also fixed service-side, with no customer action required.

Two other agent-adjacent CVEs landed in the same release: CVE-2026-50516 in Azure Kubernetes Service (CVSS 9.4, missing authentication for a critical function) and CVE-2026-70335 affecting GitHub Copilot and Visual Studio Code.

CVE-2026-59318 — Spring AI (CVSS 6.5, Medium)

The lowest score here is the most instructive. Its official title:

DefaultToolCallingManager Global Resolver Fallback Allows Unadvertised Tool Dispatch via Prompt Injection

Under certain conditions, a prompt-injection attack could cause Spring AI to invoke a tool that was not made available to the current request — crossing request boundaries and potentially escalating privilege.

Read the mechanism carefully. The application advertises a restricted tool set for a request. The model, manipulated by injected content, asks for a tool outside that set. The DefaultToolCallingManager falls back to the global resolver and dispatches it anyway.

The restriction existed. It was simply never enforced at dispatch time.

Why It Matters

Prompt injection is usually framed as a model-alignment problem: the model was tricked. That framing is wrong here, and the framing is the point.

In all three cases the failure sits below the model:

Azure SRE Agent — authorization check missing entirely
Copilot Cowork — authorization check present but improper
Spring AI — per-request restriction bypassed by a global fallback

The industry lesson is compact: telling an agent what it should not do is not the same as enforcing what it is allowed to do. If the model is manipulable and the underlying system still permits the action, prompt-level restrictions are decoration. An attacker only needs the enforcement gap.

This is also why CVSS ranks these the way it does. A 6.5 “Medium” in a framework that thousands of applications embed can matter more in aggregate than a 9.9 in a managed service the vendor patches for you. Severity measures the vulnerability. It does not measure your exposure.

We saw the escalated version of this pattern earlier this month in OpenAI’s postmortem of its agents compromising Hugging Face — the same gap between intended and enforced agent authority, at incident scale.

What You Should Do

If you run Spring AI, this is your action item. The Microsoft flaws were fixed server-side; this one is yours to patch.

# Upgrade to the release containing the fix
./mvnw versions:set-property -Dproperty=spring-ai.version -DnewVersion=2.0.1

Spring AI 2.0.1, released August 21, 2026, fixes seven CVEs:

CVE	Issue
CVE-2026-59318	Unadvertised tool dispatch via prompt injection
CVE-2026-59308	Semantic cache cross-tenant isolation bypass
CVE-2026-59294	Path traversal in `ResourceCacheService`
CVE-2026-59279	Session allocation via initialize requests
CVE-2026-59319	RediSearch tag injection
CVE-2026-47851	PDF outline recursion
CVE-2026-47852	ONNX model cache prediction

Most applications move from 2.0.0 to 2.0.1 by bumping the version, but check the release notes: several breaking changes ship alongside, including retirement of deprecated Mistral models, a Redis chat-memory module rename, and OpenAI strict mode now defaulting to false.

Also in that Spring batch and worth separate attention: CVE-2026-59285, unsafe deserialization in Spring for GraphQL, which Sonatype rates 9.2 Critical — exploitable when Jackson 2.x handles JSON deserialization and certain classes are present on the classpath.

For the Azure and Microsoft 365 services, no patch is required, but Microsoft’s guidance is to audit anyway:

Audit managed identity assignments. The SRE Agent flaw was severe because of what the identity could reach. That blast radius is still yours to size.
Review RBAC scope on any autonomous agent’s service principal. Least privilege is the mitigation that survives the next disclosure.
Monitor for anomalous privilege elevation in the window before the service-side fix landed.

Architecturally, the durable fix is the same in every stack: enforce the tool allowlist at the dispatch layer, not in the prompt. If your framework resolves a tool the current request never advertised, you have the Spring AI bug regardless of which language you wrote it in.

The MCP 2026-07-28 authorization hardening — issuer validation, issuer-bound credentials — plus the roadmap’s move toward DPoP and Workload Identity Federation is the standards-level response to exactly this problem.

Limitations

Some caveats worth stating plainly.

Microsoft has not published exploitation details for CVE-2026-62830 or CVE-2026-59118, and neither is reported as exploited in the wild. The only confirmed in-the-wild exploitation in the August release is CVE-2026-68820, which is unrelated to agents.

The two total-CVE figures cited above differ by vendor methodology; both are given rather than reconciled. And the Spring AI advisory title describes the mechanism but Spring’s release post does not publish a deeper technical breakdown, so the exact preconditions for CVE-2026-59318 are not fully public.

Finally, “three CVEs” is a pattern, not a statistic. It is enough to describe a failure class — not enough to quantify how common it is.

Conclusion

The agent security conversation has spent a year on whether models can be tricked. They can. That question is settled and it was never the interesting one.

The August disclosures point somewhere more actionable: when a model is tricked, what does the system actually let it do? In three separate stacks the answer was more than the request authorized. Two vendors fixed it for you. The third is a version bump you have to run yourself.

Enforce at the boundary. The model is not a security control.