Introduction
An improper authentication flaw in Azure DevOps let a user holding nothing more than Project Reader access start pipeline runs they were never entitled to start, and with them, run code on pipeline agents. Agents typically hold job tokens and service connections into build, deployment, and cloud infrastructure. A read-only foothold in a project could therefore translate into execution inside the systems that ship an organization's software.
Microsoft rates CVE-2026-109467 at CVSS 3.1 9.9 (Critical). Microsoft has fixed the hosted Azure DevOps service on its side, while self-hosted Azure DevOps Server 2025 installations need Patch 9.
Technical information
Root cause
The weakness is classified as CWE-287, Improper Authentication, meaning the server does not sufficiently prove that an actor is who, or what, it claims to be before honoring a request. The official description reads: "Improper authentication in Azure DevOps allows an authorized attacker to execute code over a network."
The MSRC FAQ makes this more concrete. An attacker with Project Reader access can send a specially crafted network request that triggers unauthorized pipeline execution, which may allow code execution on pipeline agents. No additional user interaction is required.
CWE-287 is an abstract classification. It does not tell us whether the underlying defect involves tokens, sessions, federation, or some other mechanism, and Microsoft has not said. The documented part is the access boundary that fails. A role intended for viewing project content can start pipeline runs, a capability that should require far more.
Why scope is changed
The CVSS vector published by Microsoft is:
CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:C/C:H/I:H/A:L
- Attack Vector: Network. The request is sent over the network.
- Attack Complexity: Low.
- Privileges Required: Low. The FAQ identifies this as Project Reader access, so exploitation is not anonymous.
- User Interaction: None.
- Scope: Changed. The flaw lives in the server, but the damage happens on pipeline agents, a different security authority.
- Confidentiality: High, Integrity: High, Availability: Low. The impact is mainly exposure and tampering, with little risk of an outage.
Microsoft also publishes a temporal score of 8.6, based on exploit code maturity Unproven, remediation level Official Fix (RL:O), and report confidence Confirmed. NVD displays the Microsoft-supplied score and notes that it has not yet provided its own assessment.
The reader role understates the blast radius
Microsoft's agent security guidance notes that pipeline scripts can access resources through job access tokens even when the initiating user's account lacks direct access, and that resources may be reachable across projects. Self-hosted agents also run under whatever service account they were installed with, and pipelines may be authorized to use service connections into cloud subscriptions.
So an assessment that stops at "the attacker is only a reader" misses the resources that become reachable once a pipeline run executes attacker-influenced work on an agent.
Attack flow (as documented)
Based solely on the MSRC description, the sequence is:
- The attacker obtains an identity with Project Reader access to a project in an affected Azure DevOps organization or Azure DevOps Server collection.
- The attacker sends a specially crafted network request to the server.
- Because of the improper authentication, the server starts a pipeline run the reader is not authorized to start.
- The run executes on a pipeline agent, giving the attacker code execution in the agent's context, with access to whatever the job token, agent account, and authorized service connections allow.
Microsoft has not disclosed the vulnerable endpoint, request format, specific component, or agent operating system involved, and Azure DevOps Server is closed source. The public record describes the access required and the outcome, but nothing that would let anyone reproduce the exploit.
Exploitation status
- MSRC lists Exploited: No and Publicly disclosed: No, with exploitability assessment N/A.
- Exploit code maturity is Unproven, which does not prove that no private exploit exists.
- No exact entry appeared in the CISA KEV catalog version 2026.11.10, released November 10, 2026.
- No threat actor has been attributed to this CVE in the reviewed material.
Patch information
Microsoft has released an official fix. How you get it depends on whether you use the cloud service or run your own server. MSRC's Security Updates table, published November 10, 2026, has two product rows:
- Azure DevOps (cloud service): fixed by Microsoft on its side, with no build number listed.
- Azure DevOps Server 2025 (self-hosted): Security Update at aka.ms/devopsserverpatch9, Patch 9.
The CNA-supplied data on NVD uses the same boundaries. Azure DevOps Server 2025 is affected from 1.0.0.0 up to, but not including, Patch 9. The cloud service is marked affected only up to the date of publication. That means Microsoft fixed the hosted service before the CVE went public, and cloud tenants have nothing to install. Self-hosted administrators must install the patch themselves.
About Patch 9
The Azure DevOps Server release notes list Patch 9 with a release date of October 13, 2026, roughly four weeks before MSRC published the CVE. Microsoft shipped the fix first and disclosed later, so anyone who installed Patch 9 in October is already protected. The release notes describe Patch 9 only in general terms, as including "fixes for security vulnerabilities in Azure DevOps Server," with no CVE IDs or code changes listed. The link between Patch 9 and this CVE comes from the MSRC Security Updates table and the matching NVD version boundary, not from the release notes.
Patch 9 is the only version MSRC lists as the fix. Patch 1 through Patch 8 do not fix this CVE, so any Azure DevOps Server 2025 instance below Patch 9 remains vulnerable.
Verifying the download
Microsoft published a SHA256 hash for the patch file:
- File:
devopsserverpatch9 - SHA256:
8860146214BEC8D3BA685F79058EC88B735E4858569FE35477AC364CCFFFF875
Before installing, run PowerShell's file hash cmdlet with the SHA256 algorithm on the downloaded file and compare the output against this value.
What the fix likely changes
There is no public commit, diff, or code snippet. From the advisory's description, the patch most likely adds proper identity and permission checks to the server path that starts pipeline runs, so that a read-only project member can no longer start a run and therefore cannot get code onto an agent. This is our inference from the advisory, not something Microsoft has documented. Microsoft has not said which API endpoint or component changed.
Complementary pipeline hardening
Microsoft's general pipeline security guidance is worth applying alongside, not instead of, Patch 9. None of these controls is documented as preventing exploitation of this CVE:
- Run self-hosted agents under the lowest-privileged account possible.
- Dedicate separate agent pools to specific projects to reduce lateral movement and cross-contamination.
- Use Microsoft-hosted pools where possible, which provide a clean virtual machine per run.
- Scope service connections to the resources they need instead of granting broad subscription-level contributor access.
- Authorize service connections per pipeline instead of granting access to all pipelines.
Affected systems and versions
Per the CVE record and the CNA data on NVD:
- Azure DevOps (cloud service): affected from
1.0.0up to the date of publication (November 10, 2026). Microsoft fixed it on the service side, and customers need to take no action. - Azure DevOps Server 2025: affected from
1.0.0.0up to, but not including, Patch 9. This covers the base release and Patch 1 through Patch 8.
These are the record's literal version expressions. The affected product entries do not identify any other Azure DevOps Server releases. An attack requires an identity with at least Project Reader access and network reachability to the server.
Vendor security history
This is not the first critical authentication issue in Azure DevOps. CVE-2025-29813 was a separate Azure DevOps elevation of privilege vulnerability involving authentication bypass by assumed immutable data, rated CVSS 3.1 10.0. In that case Microsoft stated the issue had already been fully mitigated in the service and that users had no action to take, and it published the CVE for transparency.
CVE-2026-109467 follows a similar pattern for the cloud service, but differs for self-hosted customers, who must install Patch 9.
Microsoft's September 2026 report on Storm-3068 shows why pipeline access matters. That actor took over an identity through a self-service password reset process, registered its own authentication methods, enumerated Azure DevOps resources, and modified pipelines to harvest Kubernetes credentials, committing seven stolen kubeconfig files to a repository. Investigators reconstructed the activity from Azure DevOps audit logs and Git history. The report describes abuse of legitimate services rather than a software exploit and does not reference CVE-2026-109467. It should not be read as attribution.
References
- NVD entry for CVE-2026-109467
- CVE Record for CVE-2026-109467
- MSRC Security Update Guide: CVE-2026-109467
- Azure DevOps Server Release Notes (Microsoft Learn)
- Azure DevOps Server 2025 Patch 9 download
- October Patches for Azure DevOps Server (Azure DevOps Blog)
- CWE 287: Improper Authentication (MITRE)
- CISA Known Exploited Vulnerabilities catalog feed
- Secure agents, projects, and containers (Microsoft Learn)
- Service connections in Azure Pipelines (Microsoft Learn)
- MSRC Security Update Guide: CVE-2025-29813
- Beyond source code: A path to the keys to the kingdom (Microsoft Security Blog)
- Azure DevOps Server product page
- Azure DevOps product page
- What is Azure DevOps? (Microsoft Learn)
