u/ExistingVillage9834

Saw a few people spinning up about CVE-2026-42826 since it's carrying a perfect 10.0, so a quick PSA + a point worth discussing.

What it is: a critical information disclosure flaw in Azure DevOps (CWE-200) that allowed unauthenticated remote attackers to disclose sensitive information over the network CVSS 10.0. On paper that's about as bad as it gets: no auth, no user interaction, network vector. CrowdStrike

The part that matters for us: there is nothing to do. Microsoft remediated it entirely in their cloud infrastructure and explicitly stated there's no action for users of the service to take the CVE exists mainly for transparency. If you're on the hosted Azure DevOps Services, you were patched before you ever heard about it. There's no public PoC and the exploit maturity is rated unproven. The Register TheHackerWire

The reason I think it's worth a thread anyway: it's a clean example of why a raw CVSS base score is a terrible prioritization tool on its own. A 10.0 that's already mitigated cloud-side with no PoC is operationally a non-event, while a 6.5 in a transitive dep that's actually reachable in your prod path could ruin your week. The base score doesn't carry that context the temporal and environmental metrics (and honestly, just reading the advisory) do.

It's also a reminder of why Azure DevOps is such a juicy target regardless of this specific bug: these environments routinely hold deployment credentials, cloud secrets, CI/CD tokens, infra configs, and source code. An info-disclosure flaw there isn't theoretical it's a direct line to everything downstream. INE

We all (correctly) migrated off long-lived cloud keys to short-lived OIDC tokens in our pipelines. Good move. But I've been digging into the recent supply chain incidents and the recurring failure isn't the tokens it's how loosely the trust policies are written. Sharing because it's a 10-minute audit that's worth doing today.

The short version of what's going wrong in the wild:

A poisoned NPM package steals a dev's GitHub token, and from there the attacker abuses the GitHub-to-AWS OIDC trust to spin up a new admin role going from a compromised developer machine to full cloud compromise in under 72 hours. The pipeline stops being a build tool and becomes the highest-value target you own. And if your federation is too broad trusting a public provider without strictly pinning claims effectively any user on that platform could assume the role. The kicker: one vulnerable pipeline in a "low-risk" repo plus broad federation can blow your whole security boundary. Google Cloud + 2

Practical things worth checking on your end:

Pin your OIDC sub claim narrowly. Per-repo and per-branch/environment, not org-wide wildcards. repo:org/* is asking for it. Don't trust claims an end user can manipulate.
Stop scanning only direct deps. The uncomfortable stat is that around 95% of vulnerable dependencies are transitive stuff nobody on your team chose. One team found their "simple" app had 18,000+ components, with less than 3% of the attack surface actually being scanned. TFiR Kusari
Prioritize by reachability, not raw CVSS. Most of the CVE noise isn't even in your execution path. Reachability analysis cuts the firefighting dramatically.
Scope pipeline permissions per-job. A build job rarely needs the same blast radius as a deploy job.

That "CVSS 10.0" Azure DevOps CVE (2026-42826) is real, already fixed by Microsoft, and a useful lesson in not panicking at a score

PSA for anyone running OIDC between GitHub Actions and AWS/GCP: go check how your sub claim is scoped right now