Introducing the Snowflake and AWS Custom Lens for the AWS Well-Architected Framework

2026-06-10 Nidhi Gupta

Post Syndicated from Nidhi Gupta original https://aws.amazon.com/blogs/architecture/introducing-the-snowflake-and-aws-custom-lens-for-the-aws-well-architected-framework/

Running Snowflake on AWS means navigating two distinct sets of best practices simultaneously: AWS Well-Architected guidance for infrastructure, and Snowflake Well-Architected Framework guidance for compute, data organization, and governance. Without a unified review framework, security controls go unmapped to Snowflake configurations. Production readiness timelines stretch as teams reconcile guidance from two separate review processes, and compliance posture becomes difficult to demonstrate when audit evidence spans disconnected sources. The Snowflake and AWS Custom Well-Architected Framework Lens closes that gap.

The lens brings together AWS Well-Architected best practices and Snowflake guidance into a single review experience, with integrated recommendations that reflect how the two services compose in production. It evaluates your architecture across the seven AWS Well-Architected pillars: security, reliability, performance efficiency, cost optimization, operational excellence, and sustainability. A single review surfaces findings like misconfigured Snowflake network policies alongside Amazon Virtual Private Cloud (Amazon VPC) controls, or cost inefficiencies that span both Snowflake virtual warehouse sizing and Amazon Elastic Compute Cloud (Amazon EC2) instance selection. In this post, we walk through each pillar, the three access points (AWS Management Console, Kiro, and Snowflake Cortex Code), and how to run your first review.

What’s in the lens?

The Snowflake and AWS Custom WAF Lens defines seven pillars for joint Snowflake-on-AWS architectures, drawing from both the seven-pillar AWS Well-Architected Framework and the five-pillar Snowflake Well-Architected Framework.

Pillar 1: Security and identity

Security for Snowflake on AWS requires coordinated identity and access controls across two distinct planes. On the AWS infrastructure side, services like AWS Key Management Service (AWS KMS), AWS IAM Identity Center, and Amazon VPC configurations govern access and encryption. On the Snowflake side, network policies, role-based access control (RBAC) hierarchies, and OAuth or key pair authentication control who can access data. The following table maps the most critical security domains (identity, network, authentication, and authorization) across both services, with integrated recommendations for where the two layers must align to help prevent unauthorized access.

Domain	AWS guidance	Snowflake guidance	Integrated recommendation
Network security	Amazon VPC design, AWS PrivateLink endpoints, AWS service endpoints, Amazon EC2 security groups	Network policies, IP allow lists	Use AWS PrivateLink between Amazon VPC and Snowflake; layer Snowflake network policies on top of EC2 security groups for defense-in-depth
Identity and access	AWS Identity and Access Management (IAM) roles, federation, least privilege	Database roles, role hierarchy, MFA	Federate Snowflake authentication through AWS IAM Identity Center; map identity provider groups to Snowflake database roles for consistent RBAC
Authentication	MFA for human IAM users; integrate with corporate IdP via IAM Identity Center	RSA key pair for service accounts; SAML SSO or OAuth for humans; disable-password only	Store private keys in AWS Secrets Manager; rotate via automation; unified IdP for both systems via SAML federation
Authorization	Service control policies at organization level as hard guardrails; permission boundaries on delegated roles	Role hierarchy with inheritance; SECURITYADMIN for grants separate for SYSADMIN	Map AWS IAM roles 1:1 to Snowflake functional roles with workload identity federation

Pillar 2: Data governance and compliance

Protecting data itself, independent of who accesses it, spans two complementary layers. On the AWS infrastructure side, services like AWS KMS, AWS IAM Identity Center, and Amazon Simple Storage Service (Amazon S3) lifecycle policies govern encryption, classification, and retention of data at rest. On the Snowflake side, dynamic data masking, row access policies, Tri-Secret Secure, and automatic classification protect sensitive data at the query layer. The following table maps the most critical governance domains (classification, dynamic data masking, lineage, retention, and compliance) across both systems, with integrated recommendations for maintaining consistent data protection end-to-end.

Domain	AWS guidance	Snowflake guidance	Integrated recommendation
Data protection	AWS KMS customer-managed keys, Amazon S3 encryption	Dynamic masking, row access policies, Tri-Secret Secure	Use AWS KMS with Snowflake Tri-Secret Secure for dual-custody encryption; apply Snowflake masking policies for column-level protection
Audit and compliance	AWS CloudTrail, AWS Config, AWS Security Hub	Event tables, Account Usage, Access History, Sensitive data classification	Stream Snowflake audit logs to Amazon CloudWatch or Amazon OpenSearch Service using Amazon S3 and Amazon EventBridge for consolidated compliance monitoring. AWS provides compliance-enabling capabilities; your team uses them to support and demonstrate compliance.
Row access policies	AWS Lake Formation row-level filters, Amazon S3 Access Points for team-scoped access	Row access policies for multi-tenant isolation or regional data residency; role-based row visibility	Define row-level security once in Snowflake (single enforcement point); restrict AWS-side to pipeline service account

Pillar 3: Reliability

Reliability in a Snowflake on AWS architecture depends on how well the two systems coordinate during failure scenarios, from AWS infrastructure disruptions to Snowflake service availability events. The following table covers the key reliability domains, including cross-Region replication, failover configuration, and workload isolation, with integrated guidance for building a resilient architecture across both systems.

Domain	AWS guidance	Snowflake guidance	Integrated recommendation
Disaster recovery	Multi-AZ, cross-Region replication, Amazon Route 53 failover	Database replication, failover groups, client redirect	Configure Snowflake cross-Region replication to a secondary AWS Region; use Snowflake client redirect for automated failover to the secondary Region
Data durability	Amazon S3 11-nines durability, versioning	Time Travel, Fail-safe, zero-copy clones	Align Snowflake Time Travel retention with Amazon S3 versioning policies; use zero-copy clones for pre-deployment testing without storage overhead
Recovery objectives	RTO and RPO planning, backup strategies	Replication lag monitoring, failover SLAs	Define joint RTO and RPO targets that account for both Snowflake replication lag and AWS infrastructure recovery time

Pillar 4: Performance optimization

Performance efficiency for Snowflake on AWS requires tuning at both the infrastructure and application levels. AWS instance selection, network throughput, and storage configuration directly affect how Snowflake warehouses perform. Snowflake-specific patterns like warehouse sizing, query optimization, and clustering keys determine how efficiently compute is used. The following table covers the primary performance domains with integrated recommendations for both layers.

Domain	AWS guidance	Snowflake guidance	Integrated recommendation
Compute sizing	Amazon EC2 instance selection, automatic scaling	Warehouse sizing, multi-cluster warehouses, auto-suspend	Right-size Snowflake warehouses based on query profiling; use multi-cluster warehouses for concurrency scaling aligned with application tier automatic scaling
Data organization	Amazon S3 partitioning, file format optimization	Clustering keys, search optimization, materialized views	Optimize Amazon S3 staging file sizes for Snowpipe ingestion; apply clustering keys on frequently filtered columns, ordered from lowest to highest cardinality Note: This ordering is specific to Snowflake’s micro-partition architecture. Unlike traditional databases where high-cardinality columns are typically indexed first, Snowflake achieves better partition pruning when the lowest-cardinality column leads the clustering key.
Caching and latency	Amazon CloudFront, Amazon ElastiCache	Result cache, warehouse cache, query acceleration	Design query patterns to maximize Snowflake result cache hits; use Amazon ElastiCache for application-layer caching of frequently accessed Snowflake results

Pillar 5: Cost optimization and FinOps

Cost optimization across Snowflake and AWS involves two distinct billing models that you must manage together. AWS infrastructure costs follow a consumption and reservation model, and Snowflake charges are driven by compute credits and storage. Without a unified view, teams often optimize one application at the expense of the other. The following table addresses the key cost domains with integrated recommendations for reducing spend across both billing models.

Domain	AWS guidance	Snowflake guidance	Integrated recommendation
Cost visibility	AWS Cost Explorer, AWS Budgets, AWS Cost and Usage Reports (CUR)	Resource monitors, account usage views, credit tracking	Combine AWS Cost Explorer data with Snowflake credit consumption in an integrated FinOps dashboard; tag resources with matching cost-center labels
Compute efficiency	AWS Savings Plans, Amazon EC2 Spot Instances Note: Savings Plans and Spot apply to customer-managed AWS compute (ETL pipelines, application tier) that feeds Snowflake, not to Snowflake warehouse compute itself.	Auto-suspend, warehouse right-sizing, serverless features	Pair Snowflake capacity commitments with AWS Savings Plans for predictable baseline; use auto-suspend aggressively for development warehouses
Storage efficiency	Amazon S3 lifecycle policies, S3 Intelligent-Tiering	Time Travel retention optimization, transient tables	Align Snowflake Time Travel retention (1 day for development, 90 days for regulated data) with Amazon S3 lifecycle transitions to Amazon S3 Glacier

Pillar 6: Operational excellence

Operational excellence for Snowflake on AWS means building observability, automation, and incident response workflows that span both applications. Amazon CloudWatch, AWS Systems Manager, and Snowflake’s query history and task monitoring each provide partial visibility, but a well-operated architecture connects them into a coherent operational picture. The following table covers the core operational domains with integrated guidance for managing both applications as a single system.

Domain	AWS guidance	Snowflake guidance	Integrated recommendation
Monitoring	Amazon CloudWatch, AWS X-Ray, Amazon OpenSearch Service	Snowsight dashboards, Account Usage, query history	Export Snowflake metrics to Amazon CloudWatch using Amazon S3 integration for unified operational dashboards
Automation and IaC	AWS CloudFormation, AWS Cloud Development Kit (AWS CDK), Terraform	Snowflake Terraform provider, CI/CD pipelines	Manage Snowflake objects alongside AWS infrastructure in the same Terraform state; use CI/CD pipelines for database migration workflows
Incident response	Amazon EventBridge, Amazon Simple Notification Service (Amazon SNS), AWS Lambda auto-remediation	Alerts, resource monitors, task monitoring	Trigger AWS Lambda auto-remediation from Snowflake resource monitor alerts via notification integrations and Amazon SNS

Pillar 7: Sustainability

This is the first joint ISV-AWS WAF lens to treat the sustainability pillar as a first-class concern. For Snowflake on AWS, sustainability decisions span AWS Region selection and energy efficiency choices on the infrastructure side, and warehouse consolidation, query efficiency, and data lifecycle management on the Snowflake side. The following table covers the sustainability domains with integrated recommendations that reduce the environmental footprint of your combined architecture.

Domain	AWS guidance	Snowflake guidance	Integrated recommendation
Region selection	AWS Customer Carbon Footprint Tool, region-level carbon intensity	Snowflake Region availability	Select AWS Regions aligned with sustainability goals for non-latency-sensitive Snowflake workloads; prefer secondary Regions with high renewable energy percentages for DR
Compute efficiency	AWS Compute Optimizer, Amazon EC2 Auto Scaling	Warehouse auto-suspend, serverless tasks	Enforce aggressive auto-suspend policies for development and batch workloads to alleviate idle compute; prefer serverless features for intermittent workloads
Data lifecycle	Amazon S3 Intelligent-Tiering, Amazon S3 Glacier lifecycle policies	Time Travel retention, transient tables, zero-copy clones	Minimize storage footprint by aligning Time Travel retention to actual recovery needs; replace full data copies with zero-copy clones for development and testing
Query efficiency	Batch and real-time processing best practices	Query profiling, clustering keys, materialized views, result caching	Optimize query patterns to reduce total compute-seconds; apply clustering keys to avoid full table scans

Three ways to use the lens

You can access the lens across three environments, each designed for a different workflow and team preference. Whether your team works primarily in the AWS Management Console, prefers an AI-assisted review inside an IDE, or operates within Snowflake, you can run a full Well-Architected review without switching contexts.

1. AWS Well-Architected Tool console

The lens is available directly in the AWS Well-Architected Tool console for structured reviews against your Snowflake on AWS workloads. A structured questionnaire covers all seven pillars with Snowflake-specific questions, and each best practice is risk-rated as High Risk, Medium Risk, or No Risk Identified. The review generates an improvement plan with prioritized actions and links to AWS and Snowflake documentation, milestone tracking to measure progress over time, and PDF or JSON export for stakeholder reporting and compliance evidence.

AWS Well-Architected Tool console showing the Snowflake and AWS custom lens applied to a workload

To get started:

Download the Snowflake AWS Custom Lens JSON file to your local computer.
Sign in to the AWS Well-Architected Tool console and choose Custom lenses in the navigation pane.
Choose Create custom lens, upload the downloaded JSON file, and choose Submit.

2. Kiro

For teams that prefer an AI-assisted, conversational approach, the Snowflake and AWS WAF Lens is available as a Kiro Power, an integrated capability within Kiro, the AI-powered IDE of AWS. The review runs conversationally inside the IDE with checkbox-based questions for each pillar, so you can avoid navigating a separate console. Findings are classified using a Red, Yellow, Green system for quick risk identification. Recommendations are organized into three time horizons: Now (1–2 weeks), Next (30–60 days), and Later (90 or more days). The output includes automation mapping for Proactive Health Checks and Blueprint defaults, and supports both customer-ready and internal delivery plan formats. Guidance is context-aware, accounting for your specific workload type, compliance requirements, and multi-Region needs.

Kiro IDE running the Snowflake WAF Power with checkbox questions for the security pillar

To get started:

Download the Snowflake WAF Power to your local computer and unzip it.
In Kiro, choose Open Folder and select the unzipped folder.
Enter “Run a Snowflake and AWS WAF review” in the chat to begin.

3. Snowflake Cortex Code

In addition to using the AWS Well-Architected Tool and Kiro, you can also opt for the Cortex Code coding assistant path. The joint Well-Architected review is packaged as a Cortex Code skill that you can invoke to start the review process. When invoked, the skill opens with an architecture overview and asks how you want to proceed. You can run the full review interactively with AI-guided recommendations. Cortex Code is available as both a CLI and directly within Snowsight, so you can choose whichever fits your workflow.

Option A: Cortex Code CLI (local terminal)

Cortex Code CLI prompt running the joint-waf-aws-lens skill in a terminal window

To get started:

1. Download the Cortex Code zip file for AWS WAF Lens to a location that you want on your local computer and unzip it.

Open a terminal window on your computer and enter cortex skill add <path_to_the_unzipped_folder> at the shell prompt. The following screenshot shows an example.

Terminal output confirming successful addition of the joint-waf-aws-lens skill to Cortex Code

Launch Cortex Code CLI by entering cortex at the shell prompt.
In the Cortex Code CLI chat window, enter invoke the joint-waf-aws-lens skill to get started.

Option B: Cortex Code in Snowsight (browser-based)

For teams that prefer to stay within the Snowflake UI, Cortex Code is also available directly in Snowsight, with no local install required.

Cortex Code assistant panel in Snowsight with the joint-waf skill loaded as context

To get started:

Download the Cortex Code zip file for AWS WAF Lens and unzip it.
In Snowsight, navigate to Projects > Workspaces and open (or create) a workspace where you want to run this skill.
Choose the Cortex Code icon in the lower-right corner of Snowsight to open the assistant panel.
Choose + Add context in the chat area of the assistant panel and select Upload Skill Folder(s), then choose the unzipped skill folder.
In the message box, enter run the joint-waf skill and press Enter to begin the review.

How the pillars come together

What makes this lens unique is that it integrates AWS infrastructure guidance directly into Snowflake-specific best practices.

Rather than running separate reviews for each application, the lens helps identify Snowflake architectural risks alongside the corresponding AWS remediation paths, showing where both layers need to be aligned.

Built for Snowflake on AWS

This lens reflects integrated expertise across both services:

Unified security model – AWS provides network isolation, encryption infrastructure, and identity federation. Snowflake provides data-layer protections like dynamic masking, row access policies, and Tri-Secret Secure. The lens shows how these layers compose into a coherent security posture.
FinOps integration – The cost pillar addresses the challenge of optimizing spend across two billing models: AWS infrastructure costs and Snowflake consumption costs.
Operational coherence – The operational excellence pillar bridges AWS-native observability (Amazon CloudWatch, Amazon OpenSearch Service) and Snowflake-native monitoring (Snowsight, Account Usage), so you can build connected dashboards and incident response workflows that span both services.
Sustainability as a first-class pillar – This is the first joint ISV-AWS WAF lens to include sustainability as a first-class pillar. It combines AWS Region selection strategies with warehouse consolidation, query efficiency optimization, and data lifecycle management.

Getting started with the Snowflake and AWS WAF Lens

To get the most out of your first review, start with the Security and Reliability pillars, where integrated AWS and Snowflake guidance surfaces the highest-impact findings for most production workloads. Use the improvement plan output to prioritize actions across your team, and export the results as PDF or JSON for stakeholder reporting and compliance evidence.

The following resources will help you go deeper on the AWS services and Snowflake capabilities referenced throughout this post.

What’s next

This is the first release of the Snowflake and AWS WAF Lens, and we’re actively expanding its coverage with deeper guidance on Snowflake on AWS architecture.

We’re committed to making Snowflake on AWS well-architected in the cloud. Start your first review in either the AWS Well-Architected Tool or Snowflake Cortex Code CLI today, or reach out to your AWS account team or Snowflake account team to schedule a guided workshop.

About the authors

Now available: Amazon EC2 M9g and M9gd instances powered by new AWS Graviton5 processors

2026-06-10 Esra Kayabali

Post Syndicated from Esra Kayabali original https://aws.amazon.com/blogs/aws/now-available-amazon-ec2-m9g-and-m9gd-instances-powered-by-new-aws-graviton5-processors/

AWS Graviton processors have improved steadily across generations, with each iteration delivering advances in compute performance, price-performance, and energy efficiency. At re:Invent 2025, we announced Amazon EC2 M9g, the first Graviton5-powered instances, in preview. Since then, customers have tested M9g across a wide range of workloads and shared their results. ClickHouse saw a 36% performance boost compared to M8g, with zero code changes. Honeycomb achieved 36% better throughput per core compared to Graviton4, across a 6-month A/B test of production observability workloads. HubSpot deployed M9g for MySQL databases and saw query duration drop by up to 60%. Today, M9g instances are generally available, alongside the new M9gd instances for customers who need high-speed, low-latency local NVMe SSD storage. Both are powered by Graviton5, the most powerful and most energy efficient processor AWS has ever built.

While many Arm-based instances have been introduced across the industry, no one comes close to the breadth and depth of the AWS Graviton footprint. After five generations of custom silicon and eight years of continuous investment, Graviton powers over 350 instance types serving more than 120,000 customers, from startups to large enterprises, a robust ISV partner ecosystem, and a broad set of managed services. You can use Graviton for a broad variety of workloads, including web applications, microservices, analytics, databases, machine learning (ML) inference, electronic design automation (EDA), gaming, and video encoding. As workloads grow more compute-intensive and data-driven, many have asked for more processing power, along with greater network and storage bandwidth to move more data and complete workloads faster. We’ve also designed these instances to efficiently package compute, memory, and I/O to maximize energy utilization.

As AI shifts from answering questions to taking actions, running code, using tools, evaluating results, and orchestrating multi-step tasks, the demand for CPU compute is growing rapidly. Graviton5 is built for this shift. With 192 cores, a 5x larger L3 cache, up to 33% lower inter-core latency, and DDR5 memory delivering high bandwidth, Graviton5 helps agents spend less time waiting on CPU-bound steps, processing more instructions, handling large numbers of concurrent environments, and keeping accelerators moving.

Meta is deploying Graviton at scale starting with tens of millions of cores to support its agentic AI efforts, making Meta one of the largest Graviton customers in the world. Agentic AI workloads, including real-time reasoning, code generation, and the orchestration of multi-step tasks, are CPU-intensive and benefit from the higher compute performance, larger caches, higher memory bandwidth, and core density in Graviton5.

What’s new in M9g and M9gd
Built on the sixth-generation AWS Nitro System, M9g instances are powered by AWS Graviton5 processors that deliver higher compute performance, larger caches, and improved memory and I/O scalability compared to Graviton4 processors. Graviton5 offers up to 25% better compute performance compared to Graviton4-based instances, with up to 35% faster performance for web applications, up to 35% for machine learning inference, and up to 30% for databases. As the first CPU in the AWS fleet to support the latest generation of PCIe Gen6 and DDR5-8800 memory, AWS Graviton5 instances deliver the fastest memory of any processor instances in the cloud, and 5 times more L3 cache compared to the previous generation. These improvements also come with better energy efficiency, helping you meet sustainability targets without compromising capability.

Networking and storage bandwidth have been expanded to keep pace with compute growth. M9g and M9gd instances offer up to 15% higher network bandwidth and 20% higher Amazon Elastic Block Store (Amazon EBS) bandwidth on average across sizes, with up to twice the network bandwidth for the largest instance size. M9g and M9gd instances also support Instance Bandwidth Configuration (IBC), a feature that helps you adjust the allocation of bandwidth between Amazon EBS and Amazon Virtual Private Cloud (Amazon VPC) networking for an Amazon EC2 instance by up to 25%. IBC can help optimize performance for workloads with specific bandwidth requirements, such as database read and write performance, query processing, and logging. These enhancements support faster data movement and improved throughput for workloads that rely on high I/O performance.

Security and isolation are foundational requirements for running workloads in the cloud. Within the Nitro System, the AWS Nitro Hypervisor is designed to isolate instances from each other as well as AWS operators. With M9g and M9gd instances we are raising the bar on security even further with the introduction of Nitro Isolation Engine. Nitro Isolation Engine is an enhancement to the Nitro System, which enforces isolation of instances and harnesses formal verification to provide assurances of isolation with mathematical precision. Nitro Isolation Engine is a purpose-built component that is responsible for enforcing isolation between virtual machines, including mediation of all access to virtual machine memory, CPU register state, and I/O devices through a minimal set of APIs. Nitro Isolation Engine leverages formal verification, a technique to mathematically demonstrate that the hardware or software behaves as intended, and not just in specific test cases. This intensive verification technique establishes Nitro as the first formally verified cloud hypervisor, pioneering a new standard for mathematically proven cloud security.

M9g instances provide one vCPU for every four GiB of memory and are well suited for a broad range of general-purpose workloads, including application servers, microservices, midsize data stores, gaming servers, caching fleets, containerized applications, large-scale Java applications, code repositories, web applications, and agentic AI.

For workloads that need high-speed, low-latency local storage, M9gd instances provide up to 11.4 TB of NVMe SSD storage and 30% higher IOPS and storage performance compared to Graviton4-based M8gd instances. M9gd instances are well suited for general-purpose workloads that require a balance of compute and memory with high-speed, low-latency local storage, including application servers, microservices, gaming servers, midsize key-value data stores, caching fleets, data logging, media processing, batch and log processing, and applications that need temporary storage such as caches and scratch files.

Here are the key specifications across the family:

M9g	vCPUs	Memory (GiB)	Network bandwidth (Gbps)	EBS bandwidth (Gbps)
medium	1	4	Up to 15	Up to 12
large	2	8	Up to 15	Up to 12
xlarge	4	16	Up to 15	Up to 12
2xlarge	8	32	Up to 17	Up to 12
4xlarge	16	64	Up to 17	Up to 12
8xlarge	32	128	17	12
12xlarge	48	192	25	18
16xlarge	64	256	34	24
24xlarge	96	384	50	36
48xlarge	192	768	100	72
metal-48xl	192	768	100	72

M9gd instances include local NVMe SSD storage. The table below shows the instance storage for each size. Compute, memory, network, and EBS bandwidth specifications are the same as M9g.

M9gd	vCPUs	Memory (GiB)	Instance storage (GB)	Network bandwidth (Gbps)	EBS bandwidth (Gbps)
medium	1	4	1 x 59 NVMe SSD	Up to 15	Up to 12
large	2	8	1 x 118 NVMe SSD	Up to 15	Up to 12
xlarge	4	16	1 x 237 NVMe SSD	Up to 15	Up to 12
2xlarge	8	32	1 x 475 NVMe SSD	Up to 17	Up to 12
4xlarge	16	64	1 x 950 NVMe SSD	Up to 17	Up to 12
8xlarge	32	128	1 x 1900 NVMe SSD	17	12
12xlarge	48	192	3 x 950 NVMe SSD	25	18
16xlarge	64	256	1 x 3800 NVMe SSD	34	24
24xlarge	96	384	3 x 1900 NVMe SSD	50	36
48xlarge	192	768	3 x 3800 NVMe SSD	100	72
metal-48xl	192	768	3 x 3800 NVMe SSD	100	72

Now available
M9g and M9gd instances are available in the US East (N. Virginia), US East (Ohio), US West (Oregon), and Europe (Frankfurt) Regions. M9g and M9gd instances are available for purchase through Savings Plans, On-Demand, Spot Instances, Dedicated Instances, or Dedicated Hosts. For more information, visit Amazon EC2 pricing.

To get started with M9g and M9gd instances, several resources are available. The AWS Graviton Getting Started Guide is a technical guide covering how to build, run, and optimize workloads on Graviton-based instances. The Graviton Savings Dashboard helps you track and measure the cost savings from running workloads on Graviton-based instances. And AWS Transform is an AI-powered service that automates code transformations for migrating Java applications from x86 to Graviton-based Amazon EC2 instances, handling compatibility analysis, automated recompilation, dependency updates, and validation.

To learn more about Graviton-based instances, visit AWS Graviton Processors or Level up your compute with AWS Graviton.

— Esra

Zendure SolarFlow 800 Pro: Was It Worth It?

2026-06-10 BeardedTinker

Post Syndicated from BeardedTinker original https://www.youtube.com/watch?v=CFAhlM_lnS4

Republicans vs. the Fourteenth Amendment | The David Frum Show

2026-06-10 The Atlantic

Post Syndicated from The Atlantic original https://www.youtube.com/watch?v=FjOo4aL5QDQ

[$] AI agent runs amok in Fedora and elsewhere

2026-06-10 jzb

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

Agentic AI systems can be used to do a variety of things
autonomously on behalf of a human user: open or manage bugs, generate
code, submit pull-requests, and (apparently) even complain about
rejection. In May, a Fedora developer discovered that an allegedly
rogue agent had been pestering the project in a number of ways:
reassigning bugs, fabricating unhelpful replies to bugs, and even
persuading maintainers to merge questionable code into the Anaconda
installer. It also submitted a number of pull requests (PRs),
some accepted, to several upstream projects. The Fedora account
associated with the agent has had its group privileges revoked and the
messes have been mopped up, but the motive behind the agent’s actions is still
a mystery.

Buildroot 2026.05 released

2026-06-10 jzb

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

Version
2026.05 of the Buildroot tool
has been released. Buildroot simplifies and automates the process of
building embedded Linux systems using cross-compilation. Notable
changes in this release include support for Arm Neoverse cores,
addition of XFS rootfs generation, as well as many package updates and
bug fixes. See the CHANGES
file for the full list.

Security updates for Wednesday

2026-06-10 jzb

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

Security updates have been issued by AlmaLinux (poppler), Debian (dnsmasq, mistral, okular, openssl, poppler, and strongswan), Fedora (exim, firefox, pcs, putty, and xorg-x11-server), Mageia (freeciv, golang-x-net, jq, libssh, libxmp, libxpm, minetest, ruby-net-ssh, tor, and wireshark), SUSE (389-ds, ack, agama-web-ui, amazon-ssm-agent, avahi, dpkg, elemental-register, elemental-system-agent, elemental-toolkit, ggml-devel-9500, go1.25, go1.26, kernel, kubernetes1.23, kubernetes1.24, kubernetes1.26, libsoup, mariadb, netty, netty-tcnative, NetworkManager, nginx, perl-CryptX, perl-XML-LibXML, podofo, polkit, python-Django, python-requests, samba, strongswan, vim, and xen), and Ubuntu (cyborg, gdk-pixbuf, golang-golang-x-net-dev, nginx, node-lodash, openssl, openssl, openssl1.0, qemu, tomcat9, tomcat10, and vim).

Route public traffic to private applications with Cloudflare

2026-06-10 Enrique Somoza

Post Syndicated from Enrique Somoza original https://blog.cloudflare.com/private-origins-dns-routing/

For most of the Internet’s history, public and private infrastructure operated as separate worlds. Public applications lived behind content delivery networks (CDNs) and web application firewalls (WAFs). Private applications lived behind virtual private networks (VPNs), firewalls, and separate operational stacks. We think that distinction is becoming obsolete.

Many of the applications organizations care about are not public websites. They are internal APIs, AI agent backends, MCP servers, operational tools, and services that were never designed to be exposed to the public Internet. Yet these applications still need modern security, performance, and programmability services. Security should be a property of the traffic reaching an application, not an accident of where the application happens to sit.

Until now, applying those services to private applications often required public IPs, firewall exceptions, connector software, or complex networking. As a result, many private applications missed out on capabilities such as WAF, bot management, rate limiting, caching, traffic acceleration, rewrites, and Workers, despite needing the same protections and controls as public-facing applications.

Today, we’re launching Application Services for Private Origins in closed beta for eligible Enterprise customers. Customers can now securely route traffic to private origins without exposing those origins to the public Internet. This allows Cloudflare’s security, performance, and programmability services to protect applications running on private networks, just as they do for public Internet applications.

WAF rules, bot management, rate limiting, caching, rewrites, and Workers can now sit in front of private origins without requiring public IP exposure, inbound firewall rules, or cloudflared running on the origin.

Four use cases, one application layer

This routing model builds on connectivity patterns Cloudflare already supports today through Cloudflare Tunnel, Cloudflare One Client, and private network integrations. For years, Cloudflare Tunnel has allowed customers to route public traffic to private applications through cloudflared. This new capability extends the same model to existing Cloudflare WAN or Cloudflare Mesh connectivity without requiring connector software running on the origin.

Much of that connectivity is orchestrated through Cloudflare’s private networking routing layer that determines how traffic reaches private destinations across Cloudflare Tunnels, Virtual Networks, Cloudflare Mesh, and other connectivity models. Customers can define their routing behavior through APIs and the dashboard instead of managing separate networking stacks for each product.

We have extended Cloudflare’s private networking layer directly into the application services stack, allowing security and performance proxy infrastructure to treat private IPs as valid origin targets for public hostnames. As a result, the same private IPs previously reachable only through Cloudflare Tunnel, Cloudflare One, Cloudflare Mesh, or Cloudflare WAN can now sit behind Cloudflare’s security, performance, and programmability services the same way public origins already do.

This also creates a more unified model across Cloudflare products. Workers VPC bindings and Spectrum private origin routing now rely on the same underlying private connectivity layer, giving customers a single source of truth for controlling how private traffic moves through their Cloudflare environment.

Application traffic now falls into four combinations based on where users come from and where applications live:

The combination on the upper right is what Cloudflare has always done: users on the Internet reach applications on the Internet, with Cloudflare in the middle. The bottom right is Cloudflare One: users on private networks reach public services securely.

The upper left is what we are shipping today. The bottom left, private-to-private, is what we are building toward next.

What is shipping today

Until now, getting public traffic to a private origin often meant making tradeoffs. Customers could use Cloudflare Tunnel, which runs cloudflared, our connector software, on or near the origin, or Cloudflare Load Balancing with private origin pools for health checks and failover. In many cases, organizations also maintained parallel infrastructure such as public-facing load balancers, reverse proxies, mTLS between hops, and TLS termination across multiple layers. As a result, applying Cloudflare’s full Application Services stack to private applications often required additional complexity, operational overhead, or separate products. Application Services for Private Origins removes those tradeoffs.

What was missing was a path for customers who already operate Cloudflare WAN (IPsec tunnels, GRE tunnels, CNI links) or Cloudflare Mesh. They had built private connectivity into Cloudflare for site-to-site networking and Zero Trust, and they wanted to use that same connectivity for public traffic to private origins. That is what Application Services for Private Origins delivers.

When you toggle Use private network routing on a proxied A or AAAA record, Cloudflare’s WAF, rate limiting, caching, bot management, and transform rules all run as normal on Cloudflare’s network. The only difference is the final hop: instead of reaching the origin over the public Internet, Cloudflare routes the connection through your existing private network connectivity.

The toggle is enabled automatically for RFC 1918 private IPv4 ranges (10.x.x.x, 172.16.x.x–172.31.x.x, and 192.168.x.x), RFC 6598 CGNAT ranges (100.64.x.x–100.127.x.x), and RFC 4193 Unique Local IPv6 Addresses (FC00::/7), since these addresses are only reachable within private networks. For public IP addresses that are reachable only through your private network or tunnel, you can enable the toggle manually.

What the API looks like

For customers automating deployments through the API, private routing is simply an additional attribute on a standard DNS record.

POST /zones/{zone_id}/dns_records
{
 "type": "A",
 "name": "app.example.com",
 "content": "10.0.0.50",
 "ttl": 300,
 "proxied": true,
 "use_private_routing": true
}

Behind the scenes, Cloudflare’s proxy platform determines where to send traffic for app.example.com by querying Cloudflare’s Origin API. The response includes metadata indicating that the destination should be reached through a private network path:

{
 "zone_name": "example.com",
 "ipv4_addresses": ["10.0.0.50"],
 "use_private_routing": true
}

The use_private_routing flag is the key signal. When our proxy sees it, instead of attempting to connect directly to the private IP address over the public Internet, it hands the request to our private networking layer, which then routes the connection across the customer’s existing private network connectivity, whether that’s IPsec, GRE, Cloudflare Tunnel, CNI, or Cloudflare Mesh.

Beyond HTTP: Spectrum and Workers VPC

The same routing model now extends beyond HTTP applications. The origin does not have to be a web server. It can be a TCP database, a UDP logging endpoint, or a private API that Workers call directly. The common thread is that Cloudflare sits between your traffic and your private network, applying the same security, performance, and routing layer regardless of protocol or where the request originated.

Spectrum, Cloudflare’s Layer 4 proxy, can now sit in front of TCP and UDP services running on private IPs. Instead of creating a load balancer pool as an intermediary, Spectrum applications can specify a virtual_network_id directly on the origin configuration. When you create a Spectrum application, you can include the virtual network ID alongside your private origin IP:

{
 "protocol": "tcp/22",
 "dns": {
   "type": "CNAME",
   "name": "ssh.example.com"
 },
 "origin_direct": ["tcp://10.0.0.50:22"],
 "virtual_network_id": "fab9ac85-491b-44c8-b7ae-dd44d4f4672e"
}

When you create or update a Spectrum application with a private origin and virtual network, Cloudflare verifies that the IP address matches a route in your Cloudflare Tunnel before the configuration is saved. If no matching route exists, the API rejects the request and the application is not created. Once saved, Spectrum hands the connection to your virtual network, which routes it through the associated tunnel, via the same path that HTTP traffic uses when you enable private network routing on a DNS record. In this initial release, Spectrum private origins are supported through Cloudflare Tunnel. Support for additional private network connectivity options will follow in future releases.

This means you can now put Spectrum in front of any TCP/UDP service running on a private IP. The service stays private. No public IP, connector software, or load balancer required.

Workers VPC closes the loop for code running on Cloudflare. A binding tells the Workers runtime to route through the same private path as DNS records. Browsers, mobile apps, Workers, and AI agents all reach your private origins through Cloudflare: DNS records for Internet traffic, bindings for Workers.

What comes next

Public-to-private routing is in closed beta today, and we are targeting GA (General Availability) in Q4 2026.

Beyond GA, we are building toward private-to-private traffic flows: users, services, and AI agents on private networks securely reaching applications on other private networks, with Cloudflare’s application services sitting in the middle.

We are moving toward a model where the same Cloudflare infrastructure can secure traffic regardless of whether the user or the origin is public.

The end state is a world where an employee on Cloudflare One Client accessing wiki.company.internal gets the same WAF, rate limiting, and bot management protections as a customer accessing a public API. An AI agent consuming a proprietary internal API runs through the same security stack as a browser. Service-to-service traffic across clouds and data centers gets the same controls as Internet traffic, even when neither the user nor the server sits on the public Internet.

Get started today

Routing to private origins is available today in closed beta for eligible Enterprise customers. Reach out to your Cloudflare account team to request access. Once enabled, follow our developer documentation, which walks through the full setup. You will need Cloudflare One connectivity (IPsec, GRE, CNI, or Cloudflare Mesh) and a return route for Cloudflare’s source IP range 100.64.0.0/12 in your private network.

Questions or feedback? Join the conversation in our community forums or reach out to your account team.

Exit Through the Gift Shop: Souvenirs

2026-06-10 The History Guy: History Deserves to Be Remembered

Post Syndicated from The History Guy: History Deserves to Be Remembered original https://www.youtube.com/watch?v=XVTw4clFaz8

NSO Group Hacking WhatsApp Despite Court Order

2026-06-10 Bruce Schneier

Post Syndicated from Bruce Schneier original https://www.schneier.com/blog/archives/2026/06/nso-group-hacking-whatsapp-despite-court-order.html

WhatsApp has caught the NSO Group phishing its users, in violation of a court order.

CVE-2026-10520, CVE-2026-10523 – Multiple critical vulnerabilities affecting Ivanti Sentry

2026-06-10 Rapid7

Post Syndicated from Rapid7 original https://www.rapid7.com/blog/post/etr-cve-2026-10520-cve-2026-10523-multiple-critical-vulnerabilities-affecting-ivanti-sentry

Overview

On June 9, 2026, Ivanti published a security advisory for two critical vulnerabilities affecting Ivanti Sentry (formerly known as MobileIron Sentry), which per the vendor website is an “in-line gateway that manages, encrypts, and secures traffic between the mobile device and back-end enterprise systems”. The most severe issue, CVE-2026-10520, is an OS command injection vulnerability with a CVSS score of 10.0 that allows a remote unauthenticated attacker to achieve remote code execution (RCE) with root privileges. The second vulnerability, CVE-2026-10523, is an authentication bypass vulnerability with a CVSS score of 9.9 that allows a remote unauthenticated attacker to create arbitrary administrative accounts and obtain full administrative access. Ivanti has stated that they are not aware of any customers being exploited by either of these vulnerabilities at the time of disclosure.

CVE	CVSSv3.1	CWE
CVE-2026-10520	10.0 (Critical)	OS Command Injection (CWE-78)
CVE-2026-10523	9.9 (Critical)	Authentication Bypass Using an Alternate Path or Channel (CWE-288)

On June 10, 2026, watchTowr published a technical analysis of CVE-2026-10520 that includes a proof-of-concept (PoC) exploit for unauthenticated RCE. Given the trivial nature of exploitation and the availability of a public PoC, exploitation in-the-wild is likely to begin. Ivanti Sentry has featured on the CISA KEV list twice in the past (for the vulnerabilities CVE-2023-38035 and CVE-2020-15505), so we know threat actors will likely target this product.

Organizations running affected versions of Ivanti Sentry should remediate these issues on an urgent basis before exploitation in-the-wild begins.

Technical overview for CVE-2026-10520

Based upon the technical analysis by watchTowr, CVE-2026-10520 resides in the ConfigServiceController class within the Sentry web application, which is accessible via a POST request to the unauthenticated endpoint /mics/api/v2/sentry/mics-config/handleMessage.

The handleMessage endpoint accepts an attacker supplied message parameter that is parsed as an internal configuration command. This ultimately results in arbitrary OS command execution as root with an attacker control OS command. Shown below is an example HTTP request generated by the public PoC to execute the id command on an affected system:

POST /mics/api/v2/sentry/mics-config/handleMessage HTTP/1.1
Host: [redacted]
User-Agent: python-requests/2.33.0
Accept-Encoding: gzip, deflate
Accept: */*
Connection: keep-alive
Content-Type: application/x-www-form-urlencoded
Content-Length: 161
message=execute+system+%2Fconfiguration%2Fsystem%2Fcommandexec+%3Ccommandexec%3E%3Cindex%3E1%3C%2Findex%3E%3Creqandres%3Eid%3C%2Freqandres%3E%3C%2Fcommandexec%3E

Mitigation guidance

A vendor-supplied update is available to remediate both CVE-2026-10520 and CVE-2026-10523. The following versions of Ivanti Sentry are affected:

Ivanti Sentry 10.7.0 and below
Ivanti Sentry 10.6.1 and below
Ivanti Sentry 10.5.1 and below

The following fixed versions of Ivanti Sentry remediate both vulnerabilities:

Ivanti Sentry 10.7.1
Ivanti Sentry 10.6.2
Ivanti Sentry 10.5.2

Given the critical severity of these vulnerabilities, the availability of a public PoC exploit for CVE-2026-10520, and the unauthenticated attack vector, Rapid7 strongly recommends updating affected Ivanti Sentry appliances on an urgent basis, outside of normal patching cycles.

For the latest mitigation guidance, please refer to the vendor’s security advisory.

Rapid7 customers

Exposure Command, InsightVM, and Nexpose

Exposure Command, InsightVM, and Nexpose customers can assess exposure to CVE-2026-10520 and CVE-2026-10523 with unauthenticated vulnerability checks expected to be available in the June 11 content release.

Updates

June 10, 2026: Initial publication.

Завръщането на американско-китайската дружба

2026-06-10 Искрен Иванов

Post Syndicated from Искрен Иванов original https://www.toest.bg/zavrushtaneto-na-amerikansko-kitayskata-druzhba/

Завръщането на американско-китайската дружба

Геополитическите нагласи на Великите сили, независимо от стратегическата им култура, винаги са били насочени към търсене на най-рационалния път за защита на националния им интерес. Ако това важи с пълна сила за САЩ, то е също толкова валидно за Китай. Разликата между Вашингтон и Пекин е, че американците представят интереса си като свой и на съюзниците си, а китайците имат навика да го представят като всеобщ.

Отношенията между двете държави никога не са били еднозначни, а Студената война е може би най-ценният урок какво може да се очаква, когато триъгълната дипломация работи в полза на нечия „дружба“, без тази дружба да представлява съюз. Дали ще станем свидетели на възстановяването на подобно приятелство между двете Велики сили и какви са основните предпоставки това да (не) се случи? Отговорът на този въпрос може да се окаже път към разплитането на сложната геополитическа ситуация, в която се намира светът, докато във Вашингтон управлява втората администрация на Тръмп, а в Китай вече говорят за политическо безсмъртие.

Стратегическите култури на САЩ и Китай

При опитите за сравнение между Америка и Китай може да паднем в капана на простия факт, че историческият подход изобщо не следва да бъде водещ в анализа на отношенията между Вашингтон и Пекин. Китай е страна с хилядолетна история, докато американското политическо житие е богато, но все още младо.

Тези отношения могат да бъдат обективно оценени чрез внимателен анализ на отделните понятийни категории, които двете държави използват, за да подсигурят изпълнението на приоритетите си. А това неизбежно ни отвежда до факта, че много експерти по Китай не владеят мандарин и обикновено използват английски преводи, които са също толкова подвеждащи, колкото и разсъжденията на авторите им. Може би единственото изключение от това правило е Хенри Кисинджър, който е толкова свързан с китайската история и култура, че е може би единственият американец, който в най-пълна степен може да се нарече истински познавач на Китай.

Завръщането на американско-китайската дружба — Съветникът на САЩ по национална сигурност Хенри Кисинджър и председателят на Китайската комунистическа партия Мао Дзъдун с премиера на Китай Джоу Ънлай (на заден план), Пекин, началото на 70-те години. Източник: Oliver Atkins (Jiang-original uploader on en wiki), Public domain, via Wikimedia Commons

Американската стратегическа култура винаги е била насочена към една цел: САЩ да доминират системата на международните отношения във всичките ѝ състояния. Тази идея се корени дълбоко в американския Manifest destiny, от една страна, и в идеите на бащите основатели, от друга, които виждат в разума, а не в монарха архитекта на политическото развитие на младата държава.

От момента, в който САЩ излизат на световната карта с Испано-американската война от 1898 г., те успяват последователно да овладеят ключови сектори от глобалната политика, така че светът става „американски“. Такава е системата от началото на XX век, когато европейските колониални империи все още доминират системата във военно и културно отношение. Макар и европоцентрична, тази система на практика е икономически протекторат на САЩ, които стават основен европейски кредитор, същевременно измествайки британския флот от господстващата му роля в моретата и океаните и създавайки „меката сила“ за „империята на свободата“.

Геополитическото противопоставяне със СССР също е американоцентрично по две причини. Първо, оказва се, че съветските ядрени оръжия на практика не могат да защитят Москва, тъй като това би означавало ядрен апокалипсис – факт, който поколения съветски лидери прагматично отчитат. Второ, макар и военно двуполюсен, светът на Студената война е икономически еднополюсен, тъй като доларът бързо става основна резервна валута. Еднополюсният период на 90-те години и първото десетилетие след 11 септември 2001 г. бяха пикът на американската хегемония, след което за пръв път тя беше поставена на карта от Китай.

И за пръв път Америка нямаше отговор на въпроса какво да прави.

За разлика от стратегическата култура на САЩ, китайската е комплексна и не може да бъде изчерпана с единна цел. И все пак, ако трябва да резюмираме с една дума културното наследство на Конфуций, Лаодзъ, Менций и поколенията от философи, творили в древния период на Китай, ще видим, че това е понятието хармония.

Китайската идея за лидерство днес почива върху три основни стълба. Първият е установяването на многополюсен световен ред, който – подобно на огромна пирамида на привилегиите – функционира на базата на трибутарната дипломация. Дипломация, в която няма съюзници и врагове, а само „приятели“. Някои от тези приятелства са далечни, други – близки, а трети – „без граници“.

Тук идва и вторият стълб, който включва утвърждаването на Китай като глобален икономически център, координиращ приятелите си в рамките на йерархична структура, но тя не е колективна система за сигурност или военен съюз, а система от взаимноизгодни икономически отношения.

И накрая, не бива да забравяме ролята на социализма с китайски характеристики, който обрисува ролята на лидера (председателя) като политически стълб на китайския суверенитет, а националното единство – като необходимо условие за връщането от века на унижението към славните времена, когато Китай е бил Велика сила. Такава е и стратегическата цел на китайските управляващи от Дън Сяопин насам.

Американско-китайската дружба преди и след разпада на СССР

В геополитически план американската победа в Студената война би била далеч по-трудна, ако не беше съветско-китайската схизма и не беше постигнато стратегическо сближаване с Пекин. Първото ниво, на което следва да търсим причините за тези процеси, е създаването на Новия Китай (Китайската народна република) и формирането на идеологията му. За разлика от съветската интерпретация на марксистката икономическа теория, която просто механично добавя към идеите на Маркс труда на Ленин „Какво да се прави?“, като по този начин създава политическото учение марксизъм-ленинизъм, китайските лидери представят един далеч по-изтънчен идеологически синтез.

В маоизма този синтез създава визия за съвременния свят и за мястото на Китай в него – теорията за „трите свята“ на Мао ясно позиционира сътрудничеството между Пекин и Глобалния юг като основен инструмент в стратегическата надпревара с империалистическите държави от Първия свят (САЩ и СССР) и държавите от Втория свят в лицето на европейците и Япония.

В дънизма идеите на Маркс придобиват динамични философски измерения, които целеполагат сближаването на Китай с изконния враг – Япония, и с неговия най-близък съюзник – САЩ, като път към отварянето и към възхода на китайската икономика на глобалната сцена. Паралелно с това китайските лидери очертават политиката си за мирно съжителство с останалите държави, опитвайки се да позиционират Китай като медиатор, а не като потенциален хегемон в международната система.

Мисълта на Си Дзинпин представлява истинска революция в идеите на китайските лидери, сравнима по значимост единствено с тази на Мао Дзъдун. Сегашният лидер на Китай окончателно изчиства социализма с китайски характеристики от статичните тълкувания на марксизма, формално обвързани със старото съветско мислене, и лансира динамична система от идеи, които целят както гарантирането на китайската политическа стабилност, така и националното обединение – нещо, което нито един от предишните китайски лидери не успява да постигне.

Най-значими за Китай обаче са постиженията на Си Дзинпин на геополитическата сцена, които намират отражение в доктрината му за мирния възход на Пекин в противовес с мирното съжителство, което неговите предшественици разбират като политика на консенсуализъм с останалите Велики сили и по-конкретно със САЩ. Тук е мястото да кажем, че за разлика от останалите китайски лидери, Си има завидното качество да облича идеите си в дрехите на класическата китайска философия, което им придава още по-голяма легитимност пред останалите азиатски държави.

Така стигаме и до логичния отговор на въпроса, който си поставихме: не, старата китайска дружба със САЩ няма как да бъде възродена, или поне не във вида, в който тя съществуваше по времето на Студената война. Китай уверено се е устремил към възход, а дали той ще бъде мирен, или не, ще покаже времето, защото тези процеси зависят не от намерението на лидерите, а от обективния баланс на силите в международния пъзел.

Америка, от друга страна, няма намерение да се разделя с философията си, тъй като дори Доналд Тръмп вижда американското глобално лидерство като приоритет, макар и по един особено превратен начин – като хегемония. В същото време не бива да правим генерализации, че капанът на Тукидид не е единственият сценарий, който може да се реализира, ако в даден момент отношенията между САЩ и Китай отново се влошат.

От капана на Тукидид към конфуцианската хармония

Всъщност има един сигурен факт – на сегашния етап САЩ разбират, че не могат без Китай, и Китай разбира, че не може без САЩ. В този смисъл двете държави действително поддържат дружбата си дотолкова, доколкото тя е взаимноизгодна. Това състояние няма да позволи на капана на Тукидид да се затвори, тъй като Америка няма намерение да разполага войски в Тайван, а Китай все още не е дал зелена светлина на Северна Корея да изнудва Вашингтон с новите си ракети.

Към това се прибавя невъзможността на двете държави да водят война една срещу друга – Китай все още няма паритет със САЩ, а Америка сериозно се изтощи в резултат на операцията „Епична ярост“. За добро или за лошо, принципът на хармонията, който в продължение на хилядолетия управляваше Азия, започва да се очертава като все по-привлекателен за останалата част от света, която се чуди кой ще е следващият регион, където предстои локален конфликт.

Същевременно Вашингтон и Пекин вече се намират в състояние на нова Студена война поради непримиримостта на Русия във войната с Украйна и опитите на Иран да се сдобие с оръжия за масово унищожение. Америка не може да си позволи да изостави Израел – сигнал, който дава не само администрацията на Тръмп, но и няколко последователни президентски администрации преди него.

Китай от своя страна би бил изключително уязвим без партньор като Москва или без присъствие в Близкия изток, чрез което да проектира влияние на глобалните икономически пазари. В този смисъл стратегическото противопоставяне между САЩ и Китай е неизбежно, но конфликтът между тях не е необходимост. Добрата новина е, че на този етап и двамата лидери разбират това и се стараят надпреварата между държавите им да остане в икономическата сфера.

Тук, разбира се, е добре да посочим болезнената за двете сили реалност –

САЩ следва да отчетат, че светът няма как да продължи да бъде еднополюсен, тъй като Китай вече проектира сила сред онези режими, които не се самоопределят като либерални демокрации.

Да, китайската формула може да звучи утопично и нереално за западните политици, но за Афганистан, Бруней, Мозамбик и ЮАР тя е алтернатива. Китай, от друга страна, трябва да се примири, че многополюсният свят също е непостижим, тъй като, ако Русия успее да възвърне влиянието си от съветската ера, приятелството без граници между Москва и Пекин бързо ще се срути. Същото е валидно и за стремежа на Пекин да се превърне в глобален икономически център – макар и възможно на теория, на практика няма как трибутарната имперска дипломация да успее през XXI век.

В тези условия формирането на двуполюсен модел между Вашингтон и Пекин остава най-големият гарант за глобалния мир и стабилност. Китайската позиция по отношение на иранската ядрена програма е най-сериозното доказателство в тази посока, тъй като това ще даде възможност на Америка да довърши започнатото, а на Китай – най-сетне да реализира обединението с Тайван. В тези условия светът най-сетне ще получи възможност да се разправи с истинските заплахи, които много анализатори наричат нови, макар те да не са толкова нови: тероризмът, екстремизмът, поляризацията, фундаментализмът.

Възстановяването на новата дружба между САЩ и Китай, с други думи, реализира конфуцианската хармония, а не капана на Тукидид. Тя е възможност балансът на силите в международната система да се върне отново към времето, когато политиците преговаряха с политици, а не с терористи. Вашингтон и Пекин имат потенциала да извършат този преход.

Първата стъпка към този процес е окончателното прекратяване на иранската ядрена програма и позиционирането на Тайван отново в китайската орбита. Ако планът на САЩ и Китай сработи, това означава, че е налице нов формат на сътрудничество между тях, който може успешно да разреши и останалата част от наболелите точки в глобалния дневен ред.

Алтернативата на тези механизми остава капанът на Тукидид, или по-ясно казано, война между Вашингтон и Пекин. Последиците ще са осезаеми най-вече в две посоки: рухване на глобалната икономика и възможност за ядрена ескалация между двете държави. Бъдеще, което едва ли Доналд Тръмп и Си Дзинпин биха пожелали.

Заглавно изображение: Американският президент Доналд Тръмп и членове на делегацията му разговарят с генералния секретар на Китайската комунистическа партия и президент на Китай Си Дзинпин през юни 2019 г. в Осака на среща на Г20

Beam Pipe

2026-06-10 xkcd.com

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

'If you keep trying to spray your collaborators with the beam when they're not looking, I'm turning off the ion source and NO one will get to play with the beam!' --Physics's mom

Patch Tuesday – June 2026

2026-06-10 Adam Barnett

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

Microsoft is publishing 200 vulnerabilities on June 2026 Patch Tuesday. Microsoft is not aware of exploitation in the wild for any of these vulnerabilities, and is aware of public disclosure for three. This is similar to last month’s Patch Tuesday, however several of last month’s vulnerabilities ended up on CISA KEV in the days following their publication. So far this month, Microsoft has provided patches to address 360 browser vulnerabilities, which is an order of magnitude more than has been typical in any given month over the past few years. As usual, browser vulns are not included in the Patch Tuesday count above. Indeed, the vast, and presumably sustained, uptick in the number of browser vulnerabilities has led to Microsoft no longer enumerating Chromium CVEs in the Security Update Guide. Other vulnerability categories, especially Linux kernel vulnerabilities, are seeing a similar increase in AI-assisted vulnerability reports.

What’s the opposite of coordinated disclosure?

In recent weeks, an independent vulnerability researcher going by the pseudonym Nightmare Eclipse has attracted significant attention by publishing details of six Microsoft vulnerabilities, including elevation of privilege vulnerabilities in Defender, and a Secure Boot disk encryption bypass. The researcher provided full proof-of-concept code for some, and provided significant-but-incomplete detail around the path to exploitation for others. Microsoft has confirmed that these disclosures were not coordinated, and it is clear that the relationship between this researcher and Microsoft is less than cordial. Two of the disclosures emerged in the hours after last month’s Patch Tuesday, which provides maximum visibility, while limiting Microsoft’s ability to respond without out-of-cycle patches.

At time of writing, Microsoft has provided mitigation advice and patches for CVE-2026-33825, CVE-2026-45585, CVE-2026-45498, and CVE-2026-41091, leaving only two elevation of privilege vulnerabilities unpatched, known as MiniPlasma and GreenPlasma. However, a recent blog post by Nightmare Eclipse with the title “7” has been widely interpreted to mean that there is at least one more vulnerability to come. The post contained no content other than an image of Albert Vesker, a character from the Resident Evil video game series who formerly worked as a researcher for a technology corporation before going rogue. Any inference around the possible meaning of the image is left as an exercise for the reader.

Given the timing of last month’s disclosures in the hours following Patch Tuesday, a further high-friction disclosure today would perhaps be unsurprising. Indeed, a new blog post and a new GitHub account from the same researcher have emerged in the hours following Microsoft’s publication of the June 2026 Patch Tuesday updates. The apparent seventh disclosure is nicknamed RoguePlanet, and appears to describe another elevation of privilege to SYSTEM in Defender.

It is not at all difficult to understand why Microsoft and many blue team practitioners are deeply alarmed by the partial or even full disclosure of proof-of-concept code for an ongoing series of vulnerabilities affecting fully-patched Windows systems. However, multiple leading voices in the broader vulnerability disclosure community have expressed concern that Microsoft’s invocation of the Digital Crimes Unit in a May 27, 2026 blog post may yet prove counterproductive, especially if it causes other researchers to back away from mutually beneficial engagements with MSRC. A few days later, MSRC issued a further statement clarifying that they have no intention of pursuing action against security researchers, but only those who break the law or engage in malicious activity causing real harm. For now, one safe conclusion is that this unusually sensational Microsoft vulnerability management story arc is far from over.

HTTP/2: denial of service

Every so often, a new round of denial of service vulnerabilities emerge which affect web servers implementing HTTP/2 and HTTP/3 standards. This class of vulnerabilities is likely to expand further as researchers, including the discoverers of CVE-2026-49160, use advances in LLM capability to probe not just specific software, but also the standards on which software rests. Microsoft warns that exploitation leads to uncontrolled resource consumption over a network, and expects that exploitation is more likely. The advisory credits both a third-party research firm and OpenAI’s Codex.

Microsoft has not yet directly addressed another HTTP/2 vulnerability which allows trivial denial-of-service against the default HTTP/2 configuration of multiple web server platforms, including Microsoft IIS. CVE-2026-49975, also known as HTTP/2 Bomb, became public knowledge a week ago. This denial of service works by exhausting memory on the target server, and unlike a distributed denial of service attack, there is no requirement that an attacker control a large amount of bandwidth. Patches are available for NGINX and Apache, with IIS presumably to follow at some point. If practically possible, disabling HTTP/2 is a valid mitigation.

PowerToys: SYSTEM EoP

The Microsoft PowerToys utility provides a wide variety of useful control and configuration options for Windows power users which aren’t otherwise easily accessible. It turns out that PowerToys also offers an undocumented extra: local elevation of privilege to SYSTEM via successful exploitation of CVE-2026-42902. It is worth noting that the fix was included in PowerToys v0.99.1 on April 29, 2026, without any apparent mention in the release notes. Attackers with patch-diffing toolkits may well take note of this discrepancy.

Microsoft lifecycle update

There are no significant Microsoft product lifecycle changes this month. SQL Server 2016 moves beyond regular extended support and into the pay-to-play Extended Security Updates (ESU) phase after July 14, 2026. On that same date, SharePoint 2016 and 2019 will also move past extended support, but since there’s no ESU available, the only remaining option for fully-supported self-hosted SharePoint after the middle of next month will be SharePoint Subscription Edition.

Summary charts

Vulnerabilities by Product Family

Apps vulnerabilities

CVE	Title	Exploitation status	Publicly disclosed?	CVSS v3 base score
CVE-2026-45650	Microsoft Bing Search Spoofing Vulnerability	Exploitation Less Likely	No	4.3
CVE-2026-49161	Microsoft PC Manager Security Feature Bypass Vulnerability	Exploitation Unlikely	No	7.8
CVE-2026-42902	Microsoft PowerToys Elevation of Privilege Vulnerability	Exploitation Less Likely	No	7.8
CVE-2026-45649	Office for Android Spoofing Vulnerability	Exploitation Unlikely	No	7.1
CVE-2026-44803	Windows Graphics Component Remote Code Execution Vulnerability	Exploitation More Likely	No	7.8
CVE-2026-44812	Windows Graphics Component Remote Code Execution Vulnerability	Exploitation More Likely	No	7.8

Azure vulnerabilities

CVE	Title	Exploitation status	Publicly disclosed?	CVSS v3 base score
CVE-2026-32193	Azure Kubernetes Service (AKS) Remote Code Execution Vulnerability	Exploitation Unlikely	No	8.8
CVE-2026-47643	Azure Stack Edge Remote Code Execution Vulnerability	Exploitation Unlikely	No	9.8
CVE-2026-41098	Azure Stack Edge Spoofing Vulnerability	Exploitation Less Likely	No	8.4

Developer Tools vulnerabilities

CVE	Title	Exploitation status	Publicly disclosed?	CVSS v3 base score
CVE-2026-45490	.NET SDK Elevation of Privilege Vulnerability	Exploitation Less Likely	No	7.8
CVE-2026-45491	.NET Tampering Vulnerability	Exploitation Unlikely	No	6.2
CVE-2026-45591	ASP.NET Core Denial of Service Vulnerability	Exploitation Less Likely	No	7.5
CVE-2026-45644	Microsoft Live Share Canvas SDK Elevation of Privilege Vulnerability	Exploitation Less Likely	No	8.0
CVE-2026-45482	Microsoft Visual Studio Code CoPilot Chat Extension Security Feature Bypass Vulnerability	Exploitation Less Likely	No	8.4
CVE-2026-40376	Visual Studio Code Elevation of Privilege Vulnerability	Exploitation Less Likely	No	7.5
CVE-2026-47281	Visual Studio Code Elevation of Privilege Vulnerability	Exploitation Unlikely	No	9.6
CVE-2026-47284	Visual Studio Code Information Disclosure Vulnerability	Exploitation Less Likely	No	6.5
CVE-2026-47292	Visual Studio Code MSSQL Extension Remote Code Execution Vulnerability	Exploitation Less Likely	No	7.8
CVE-2026-48569	Visual Studio Code Security Feature Bypass Vulnerability	Exploitation Less Likely	No	7.1
CVE-2026-47287	Visual Studio Code Tampering Vulnerability	Exploitation Less Likely	No	6.5

ESU vulnerabilities

CVE	Title	Exploitation status	Publicly disclosed?	CVSS v3 base score
CVE-2025-10263	ARM: CVE-2025-10263 Completion of affected memory accesses might not be guaranteed by completion of a TLBI [kernel]	Exploitation Less Likely	No	9.3
CVE-2026-44815	DHCP Client Service Remote Code Execution Vulnerability	Exploitation Less Likely	No	9.8
CVE-2026-49160	HTTP.sys Denial of Service Vulnerability	Exploitation More Likely	Yes	7.5
CVE-2026-47291	HTTP.sys Remote Code Execution Vulnerability	Exploitation More Likely	No	9.8
CVE-2026-45642	Microsoft Azure Attestation service and Device Health Attestation Service Spoofing Vulnerability	Exploitation Less Likely	No	3.9
CVE-2026-45637	Microsoft DWM Core Library Elevation of Privilege Vulnerability	Exploitation Less Likely	No	7.8
CVE-2026-45504	Microsoft Exchange Server Elevation of Privilege Vulnerability	Exploitation Unlikely	No	8.8
CVE-2026-45502	Microsoft Exchange Server Information Disclosure Vulnerability	Exploitation Unlikely	No	5.0
CVE-2026-45503	Microsoft Exchange Server Information Disclosure Vulnerability	Exploitation Unlikely	No	8.1
CVE-2026-45583	Microsoft Exchange Server Remote Code Execution Vulnerability	Exploitation Less Likely	No	7.5
CVE-2026-45500	Microsoft Exchange Server Spoofing Vulnerability	Exploitation Less Likely	No	6.1
CVE-2026-45501	Microsoft Exchange Server Spoofing Vulnerability	Exploitation Less Likely	No	6.5
CVE-2026-47631	Microsoft Exchange Server Spoofing Vulnerability	Exploitation Less Likely	No	8.1
CVE-2026-42986	Microsoft Graphics Component Elevation of Privilege Vulnerability	Exploitation More Likely	No	7.8
CVE-2026-41092	Microsoft Kinect Elevation of Privilege Vulnerability	Exploitation Less Likely	No	7.8
CVE-2026-45606	Microsoft UxTheme Library (uxtheme.dll) Denial of Service Vulnerability	Exploitation Less Likely	No	5.5
CVE-2026-42980	NT OS Kernel Elevation of Privilege Vulnerability	Exploitation More Likely	No	7.8
CVE-2026-42916	NT OS Kernel Elevation of Privilege Vulnerability	Exploitation Less Likely	No	7.8
CVE-2026-47289	Remote Desktop Client Remote Code Execution Vulnerability	Exploitation Less Likely	No	8.8
CVE-2026-47653	Remote Desktop Client Remote Code Execution Vulnerability	Exploitation Unlikely	No	8.8
CVE-2026-48563	Remote Desktop Client Remote Code Execution Vulnerability	Exploitation Less Likely	No	7.5
CVE-2026-42909	Remote Desktop Client Remote Code Execution Vulnerability	Exploitation Unlikely	No	7.5
CVE-2026-42992	Remote Desktop Client Remote Code Execution Vulnerability	Exploitation Less Likely	No	7.5
CVE-2026-44799	Remote Desktop Client Remote Code Execution Vulnerability	Exploitation Less Likely	No	7.5
CVE-2026-44801	Remote Desktop Client Remote Code Execution Vulnerability	Exploitation Less Likely	No	7.5
CVE-2026-42985	Remote Desktop Client Remote Code Execution Vulnerability	Exploitation More Likely	No	8.8
CVE-2026-42993	Remote Desktop Client Remote Code Execution Vulnerability	Exploitation Less Likely	No	7.5
CVE-2026-45588	Secure Boot Security Feature Bypass Vulnerability	Exploitation Less Likely	No	7.9
CVE-2026-48568	Secure Boot Security Feature Bypass Vulnerability	Exploitation Less Likely	No	7.9
CVE-2026-48570	Secure Boot Security Feature Bypass Vulnerability	Exploitation Less Likely	No	7.9
CVE-2026-48573	Secure Boot Security Feature Bypass Vulnerability	Exploitation Less Likely	No	7.9
CVE-2026-48575	Secure Boot Security Feature Bypass Vulnerability	Exploitation Less Likely	No	7.9
CVE-2026-48576	Secure Boot Security Feature Bypass Vulnerability	Exploitation Less Likely	No	7.9
CVE-2026-48578	Secure Boot Security Feature Bypass Vulnerability	Exploitation Less Likely	No	7.9
CVE-2026-45656	UEFI Secure Boot Security Feature Bypass Vulnerability	Exploitation Less Likely	No	7.8
CVE-2026-8863	UEFI Secure Boot Security Feature Bypass Vulnerability	Exploitation Less Likely	No	7.8
CVE-2026-34335	Windows Ancillary Function Driver for WinSock Elevation of Privilege Vulnerability	Exploitation Unlikely	No	7.0
CVE-2026-45601	Windows Ancillary Function Driver for WinSock Elevation of Privilege Vulnerability	Exploitation Less Likely	No	7.0
CVE-2026-45598	Windows Ancillary Function Driver for WinSock Elevation of Privilege Vulnerability	Exploitation Less Likely	No	7.0
CVE-2026-45596	Windows Ancillary Function Driver for WinSock Elevation of Privilege Vulnerability	Exploitation Less Likely	No	7.0
CVE-2026-45638	Windows Ancillary Function Driver for WinSock Elevation of Privilege Vulnerability	Exploitation Less Likely	No	7.8
CVE-2026-45603	Windows Ancillary Function Driver for WinSock Elevation of Privilege Vulnerability	Exploitation Less Likely	No	7.0
CVE-2026-42911	Windows Ancillary Function Driver for WinSock Elevation of Privilege Vulnerability	Exploitation Less Likely	No	7.0
CVE-2026-45594	Windows Application Identity (AppID) Information Disclosure Vulnerability	Exploitation Less Likely	No	5.5
CVE-2026-45655	Windows BitLocker Security Feature Bypass Vulnerability	Exploitation Less Likely	No	5.3
CVE-2026-45658	Windows BitLocker Security Feature Bypass Vulnerability	Exploitation More Likely	No	7.8
CVE-2026-50507	Windows BitLocker Security Feature Bypass Vulnerability	Exploitation More Likely	Yes	6.8
CVE-2026-45640	Windows Bluetooth Port Driver Elevation of Privilege Vulnerability	Exploitation Less Likely	No	7.0
CVE-2026-45605	Windows Bluetooth Service Elevation of Privilege Vulnerability	Exploitation Less Likely	No	7.8
CVE-2026-47656	Windows Boot Manager Security Feature Bypass Vulnerability	Exploitation Less Likely	No	7.9
CVE-2026-45586	Windows Collaborative Translation Framework (CTFMON) Elevation of Privilege Vulnerability	Exploitation More Likely	Yes	7.8
CVE-2026-42987	Windows Deployment Services (WDS) Remote Code Execution	Exploitation Less Likely	No	8.1
CVE-2026-33828	Windows Device Health Attestation (DHA) Elevation of Privilege Vulnerability	Exploitation Unlikely	No	7.8
CVE-2026-45634	Windows DHCP Client Information Disclosure Vulnerability	Exploitation Unlikely	No	5.5
CVE-2026-45608	Windows DHCP Client Information Disclosure Vulnerability	Exploitation Unlikely	No	6.8
CVE-2026-41108	Windows DNS Client Elevation of Privilege Vulnerability	Exploitation Unlikely	No	7.0
CVE-2026-42905	Windows DWM Core Library Elevation of Privilege Vulnerability	Exploitation More Likely	No	7.8
CVE-2026-42983	Windows DWM Core Library Elevation of Privilege Vulnerability	Exploitation Less Likely	No	7.8
CVE-2026-44802	Windows DWM Core Library Elevation of Privilege Vulnerability	Exploitation Less Likely	No	7.8
CVE-2026-45602	Windows Dynamic Host Configuration Protocol (DHCP) Tampering Vulnerability	Exploitation Less Likely	No	9.1
CVE-2026-42836	Windows Function Discovery Service (fdwsd.dll) Elevation of Privilege Vulnerability	Exploitation Less Likely	No	7.0
CVE-2026-44803	Windows Graphics Component Remote Code Execution Vulnerability	Exploitation More Likely	No	7.8
CVE-2026-44812	Windows Graphics Component Remote Code Execution Vulnerability	Exploitation More Likely	No	7.8
CVE-2026-42972	Windows Hyper-V Information Disclosure Vulnerability	Exploitation Less Likely	No	5.5
CVE-2026-45607	Windows Hyper-V Remote Code Execution Vulnerability	Exploitation Less Likely	No	8.4
CVE-2026-45641	Windows Hyper-V Remote Code Execution Vulnerability	Exploitation Less Likely	No	8.4
CVE-2026-45592	Windows Internet (wininet.dll) Elevation of Privilege Vulnerability	Exploitation Unlikely	No	7.8
CVE-2026-42903	Windows Kerberos Denial of Service Vulnerability	Exploitation Unlikely	No	6.5
CVE-2026-42914	Windows Kerberos Denial of Service Vulnerability	Exploitation Less Likely	No	5.3
CVE-2026-47288	Windows Kerberos Key Distribution Center (KDC) Remote Code Execution	Exploitation Unlikely	No	7.1
CVE-2026-48583	Windows Kernel Elevation of Privilege Vulnerability	Exploitation Less Likely	No	7.8
CVE-2026-45653	Windows Kernel Elevation of Privilege Vulnerability	Exploitation Unlikely	No	7.0
CVE-2026-42984	Windows Kernel Elevation of Privilege Vulnerability	Exploitation Unlikely	No	7.0
CVE-2026-45595	Windows Mark of the Web Security Feature Bypass Vulnerability	Exploitation Less Likely	No	5.4
CVE-2026-48574	Windows Media Remote Code Execution Vulnerability	Exploitation Less Likely	No	7.8
CVE-2026-45636	Windows NTFS Remote Code Execution Vulnerability	Exploitation Less Likely	No	7.8
CVE-2026-50508	Windows NTLM Spoofing Vulnerability	Exploitation More Likely	No	6.5
CVE-2026-45487	Windows Program Compatibility Assistant Service Elevation of Privilege Vulnerability	Exploitation Unlikely	No	7.8
CVE-2026-42828	Windows Projected File System Elevation of Privilege Vulnerability	Exploitation Less Likely	No	7.8
CVE-2026-42837	Windows Projected File System Elevation of Privilege Vulnerability	Exploitation Less Likely	No	7.8
CVE-2026-42969	Windows Push Notification Information Disclosure Vulnerability	Exploitation Unlikely	No	5.5
CVE-2026-42971	Windows Push Notification Information Disclosure Vulnerability	Exploitation Less Likely	No	5.5
CVE-2026-42970	Windows Push Notification Information Disclosure Vulnerability	Exploitation Less Likely	No	5.5
CVE-2026-42973	Windows Push Notification Information Disclosure Vulnerability	Exploitation Less Likely	No	5.5
CVE-2026-42978	Windows Push Notifications Elevation of Privilege Vulnerability	Exploitation Unlikely	No	7.8
CVE-2026-42977	Windows Push Notifications Elevation of Privilege Vulnerability	Exploitation Unlikely	No	7.8
CVE-2026-42979	Windows Push Notifications Elevation of Privilege Vulnerability	Exploitation Unlikely	No	7.8
CVE-2026-42991	Windows Push Notifications Elevation of Privilege Vulnerability	Exploitation Unlikely	No	7.8
CVE-2026-45639	Windows Remote Desktop Protocol (RDP) Information Disclosure Vulnerability	Exploitation Less Likely	No	7.5
CVE-2026-42908	Windows Remote Desktop Protocol (RDP) Information Disclosure Vulnerability	Exploitation Less Likely	No	7.5
CVE-2026-45593	Windows SDK Elevation of Privilege Vulnerability	Exploitation Less Likely	No	7.8
CVE-2026-42906	Windows Shell Information Disclosure Vulnerability	Exploitation Less Likely	No	5.5
CVE-2026-42907	Windows Shell Information Disclosure Vulnerability	Exploitation Less Likely	No	6.5
CVE-2026-47648	Windows Storage Elevation of Privilege Vulnerability	Exploitation Unlikely	No	7.0
CVE-2026-42915	Windows TCP/IP Denial of Service Vulnerability	Exploitation Less Likely	No	5.7
CVE-2026-42904	Windows TCP/IP Elevation of Privilege Vulnerability	Exploitation Unlikely	No	9.6
CVE-2026-42968	Windows Telephony Server Information Disclosure Vulnerability	Exploitation Less Likely	No	5.5
CVE-2026-42912	Windows Telephony Service Elevation of Privilege Vulnerability	Exploitation Less Likely	No	7.0
CVE-2026-40409	Windows Universal Disk Format File System Driver (UDFS) Elevation of Privilege Vulnerability	Exploitation Less Likely	No	7.8
CVE-2026-40404	Windows Universal Disk Format File System Driver (UDFS) Elevation of Privilege Vulnerability	Exploitation Less Likely	No	7.8
CVE-2026-45599	Windows UPnP Device Host Remote Code Execution Vulnerability	Exploitation Less Likely	No	8.1
CVE-2026-45635	Windows UPnP Device Host Remote Code Execution Vulnerability	Exploitation Less Likely	No	8.1
CVE-2026-42989	Winlogon Elevation of Privilege Vulnerability	Exploitation More Likely	No	7.8

Mariner vulnerabilities

CVE	Title	Exploitation status	Publicly disclosed?	CVSS v3 base score
CVE-2026-40930	LIBPNG: Chunk smuggling in push-mode APNG parser via unconsumed chunk body	n/a	No	5.4

Microsoft Dynamics vulnerabilities

CVE	Title	Exploitation status	Publicly disclosed?	CVSS v3 base score
CVE-2026-40371	Microsoft Dynamics 365 (on-premises) Elevation of Privilege Vulnerability	Exploitation Less Likely	No	8.8

Microsoft Office vulnerabilities

CVE	Title	Exploitation status	Publicly disclosed?	CVSS v3 base score
CVE-2026-44822	Microsoft Excel Information Disclosure Vulnerability	Exploitation Unlikely	No	8.2
CVE-2026-45455	Microsoft Excel Information Disclosure Vulnerability	Exploitation Less Likely	No	3.3
CVE-2026-45469	Microsoft Excel Remote Code Execution Vulnerability	Exploitation Less Likely	No	7.8
CVE-2026-44817	Microsoft Excel Remote Code Execution Vulnerability	Exploitation Unlikely	No	7.8
CVE-2026-44818	Microsoft Excel Remote Code Execution Vulnerability	Exploitation Less Likely	No	7.0
CVE-2026-44820	Microsoft Excel Remote Code Execution Vulnerability	Exploitation Less Likely	No	7.8
CVE-2026-44823	Microsoft Excel Remote Code Execution Vulnerability	Exploitation Less Likely	No	7.8
CVE-2026-45459	Microsoft Excel Security Feature Bypass Vulnerability	Exploitation Less Likely	No	3.3
CVE-2026-47293	Microsoft Office Click-To-Run Elevation of Privilege Vulnerability	Exploitation Less Likely	No	7.0
CVE-2026-45485	Microsoft Office Information Disclosure Vulnerability	Exploitation Less Likely	No	3.3
CVE-2026-44821	Microsoft Office Information Disclosure Vulnerability	Exploitation Less Likely	No	5.5
CVE-2026-45460	Microsoft Office Information Disclosure Vulnerability	Exploitation Unlikely	No	4.7
CVE-2026-45483	Microsoft Office Project Server Spoofing Vulnerability	Exploitation Less Likely	No	4.6
CVE-2026-45475	Microsoft Office Remote Code Execution Vulnerability	Exploitation Less Likely	No	7.8
CVE-2026-45472	Microsoft Office Remote Code Execution Vulnerability	Exploitation Less Likely	No	8.4
CVE-2026-45474	Microsoft Office Remote Code Execution Vulnerability	Exploitation Less Likely	No	8.4
CVE-2026-44819	Microsoft Office Remote Code Execution Vulnerability	Exploitation Less Likely	No	7.8
CVE-2026-44824	Microsoft Office Remote Code Execution Vulnerability	Exploitation Less Likely	No	7.8
CVE-2026-45461	Microsoft Office Remote Code Execution Vulnerability	Exploitation Less Likely	No	8.4
CVE-2026-45645	Microsoft Office Remote Code Execution Vulnerability	Exploitation Less Likely	No	7.8
CVE-2026-45463	Microsoft Office Remote Code Execution Vulnerability	Exploitation Less Likely	No	8.4
CVE-2026-45456	Microsoft Outlook and Word Remote Code Execution Vulnerability	Exploitation Less Likely	No	8.4
CVE-2026-45458	Microsoft Outlook and Word Remote Code Execution Vulnerability	Exploitation Less Likely	No	8.4
CVE-2026-47635	Microsoft Outlook and Word Remote Code Execution Vulnerability	Exploitation Less Likely	No	8.4
CVE-2026-45484	Microsoft SharePoint Elevation of Privilege Vulnerability	Exploitation Less Likely	No	8.8
CVE-2026-45454	Microsoft SharePoint Remote Code Execution Vulnerability	Exploitation Less Likely	No	6.5
CVE-2026-47298	Microsoft SharePoint Server Remote Code Execution Vulnerability	Exploitation Less Likely	No	8.0
CVE-2026-45467	Microsoft SharePoint Server Spoofing Vulnerability	Exploitation Less Likely	No	4.6
CVE-2026-45468	Microsoft SharePoint Server Spoofing Vulnerability	Exploitation Less Likely	No	4.6
CVE-2026-45479	Microsoft SharePoint Server Spoofing Vulnerability	Exploitation Less Likely	No	4.6
CVE-2026-45453	Microsoft SharePoint Server Spoofing Vulnerability	Exploitation Less Likely	No	5.4
CVE-2026-47636	Microsoft SharePoint Server Spoofing Vulnerability	Exploitation Less Likely	No	5.4
CVE-2026-47637	Microsoft SharePoint Server Spoofing Vulnerability	Exploitation Less Likely	No	4.6
CVE-2026-47638	Microsoft SharePoint Server Spoofing Vulnerability	Exploitation Less Likely	No	4.6
CVE-2026-47639	Microsoft SharePoint Server Spoofing Vulnerability	Exploitation Unlikely	No	5.4
CVE-2026-47641	Microsoft SharePoint Server Spoofing Vulnerability	Exploitation Less Likely	No	4.6
CVE-2026-33113	Microsoft SharePoint Server Spoofing Vulnerability	Exploitation Less Likely	No	5.4
CVE-2026-45462	Microsoft SharePoint Server Spoofing Vulnerability	Exploitation Less Likely	No	4.6
CVE-2026-45464	Microsoft SharePoint Server Spoofing Vulnerability	Exploitation Less Likely	No	5.4
CVE-2026-45465	Microsoft SharePoint Server Spoofing Vulnerability	Exploitation Less Likely	No	5.4
CVE-2026-47634	Microsoft SharePoint Server Spoofing Vulnerability	Exploitation More Likely	No	7.3
CVE-2026-47640	Microsoft SharePoint Server Spoofing Vulnerability	Exploitation Unlikely	No	4.6
CVE-2026-45481	Microsoft SharePoint Server Spoofing Vulnerability	Exploitation More Likely	No	7.3
CVE-2026-48560	Microsoft SharePoint Server Spoofing Vulnerability	Exploitation Less Likely	No	5.4
CVE-2026-48562	Microsoft SharePoint Server Spoofing Vulnerability	Exploitation Less Likely	No	4.6
CVE-2026-42835	Microsoft Teams for Android Information Disclosure Vulnerability	Exploitation Less Likely	No	8.1
CVE-2026-45466	Microsoft Word Information Disclosure Vulnerability	Exploitation Unlikely	No	3.3
CVE-2026-45471	Microsoft Word Remote Code Execution Vulnerability	Exploitation Less Likely	No	7.8
CVE-2026-45486	Microsoft Word Remote Code Execution Vulnerability	Exploitation Less Likely	No	7.8
CVE-2026-45643	Microsoft Word Remote Code Execution Vulnerability	Exploitation Less Likely	No	7.8
CVE-2026-45457	Microsoft Word Remote Code Execution Vulnerability	Exploitation Less Likely	No	7.8
CVE-2026-45649	Office for Android Spoofing Vulnerability	Exploitation Unlikely	No	7.1
CVE-2026-44803	Windows Graphics Component Remote Code Execution Vulnerability	Exploitation More Likely	No	7.8
CVE-2026-44812	Windows Graphics Component Remote Code Execution Vulnerability	Exploitation More Likely	No	7.8

Open Source Software vulnerabilities

CVE	Title	Exploitation status	Publicly disclosed?	CVSS v3 base score
CVE-2026-11463	USCiLab Cereal Shared Pointer type confusion	n/a	No	7.3
CVE-2026-49975	Apache HTTP Server: mod_http2 denial of service	n/a	No	7.5
CVE-2026-50265	Rejected reason: This CVE ID was assigned as a duplicate of CVE-2026-50292	n/a	No	5.3
CVE-2026-40930	LIBPNG: Chunk smuggling in push-mode APNG parser via unconsumed chunk body	n/a	No	5.4
CVE-2026-10879	DBI versions before 1.648 for Perl have a heap overflow when preparsing SQL statements with more than 9 binders	n/a	No	8.6
CVE-2026-50261	Xorg-x11-server: xorg-x11-server-xwayland: xorg-x11-server: use-after-free in syncchangecounter()	n/a	No	7.8
CVE-2026-50256	Xorg-x11-server: xorg-x11-server-xwayland: xorg-x11-server: stack buffer overflow in font alias resolution due to libxfont2 name length mismatch	n/a	No	7.8
CVE-2026-50262	Xorg-x11-server: xorg-x11-server-xwayland: xorg-x11-server: out-of-bounds read/write in glx changedrawableattributes	n/a	No	5.5
CVE-2026-50260	Xorg-x11-server: xorg-x11-server-xwayland: xorg-x11-server: use-after-free in freecounter()	n/a	No	6.6
CVE-2026-50259	Xorg-x11-server: xorg-x11-server-xwayland: xorg-x11-server: stack buffer overflow in xkb setmap request via mapwidths indexing	n/a	No	7.8
CVE-2026-50257	Xorg-x11-server: xorg-x11-server-xwayland: xorg-x11-server: use-after-free in misyncdestroyfence()	n/a	No	6.6
CVE-2026-50258	Xorg-x11-server: xorg-x11-server-xwayland: xorg-x11-server: stack buffer overflow in xkb key types due to unchecked shift levels	n/a	No	7.8
CVE-2026-50263	Xorg-x11-server: xorg-x11-server-xwayland: xorg-x11-server: use-after-free information disclosure in createsaverwindow()	n/a	No	5.5

Other vulnerabilities

CVE	Title	Exploitation status	Publicly disclosed?	CVSS v3 base score
CVE-2026-45476	Microsoft Azure Network Adapter Elevation of Privilege Vulnerability	Exploitation Less Likely	No	8.2
CVE-2026-26142	Nuance PowerScribe Remote Code Execution Vulnerability	Exploitation Less Likely	No	9.8

Server Software vulnerabilities

CVE	Title	Exploitation status	Publicly disclosed?	CVSS v3 base score
CVE-2026-45504	Microsoft Exchange Server Elevation of Privilege Vulnerability	Exploitation Unlikely	No	8.8
CVE-2026-45502	Microsoft Exchange Server Information Disclosure Vulnerability	Exploitation Unlikely	No	5.0
CVE-2026-45503	Microsoft Exchange Server Information Disclosure Vulnerability	Exploitation Unlikely	No	8.1
CVE-2026-45583	Microsoft Exchange Server Remote Code Execution Vulnerability	Exploitation Less Likely	No	7.5
CVE-2026-45500	Microsoft Exchange Server Spoofing Vulnerability	Exploitation Less Likely	No	6.1
CVE-2026-45501	Microsoft Exchange Server Spoofing Vulnerability	Exploitation Less Likely	No	6.5
CVE-2026-47631	Microsoft Exchange Server Spoofing Vulnerability	Exploitation Less Likely	No	8.1

System Center vulnerabilities

CVE	Title	Exploitation status	Publicly disclosed?	CVSS v3 base score
CVE-2026-45647	Microsoft Defender for Endpoint for Mac Elevation of Privilege Vulnerability	Exploitation Less Likely	No	5.5

Windows vulnerabilities

CVE	Title	Exploitation status	Publicly disclosed?	CVSS v3 base score
CVE-2025-10263	ARM: CVE-2025-10263 Completion of affected memory accesses might not be guaranteed by completion of a TLBI [kernel]	Exploitation Less Likely	No	9.3
CVE-2026-44815	DHCP Client Service Remote Code Execution Vulnerability	Exploitation Less Likely	No	9.8
CVE-2026-49160	HTTP.sys Denial of Service Vulnerability	Exploitation More Likely	Yes	7.5
CVE-2026-47291	HTTP.sys Remote Code Execution Vulnerability	Exploitation More Likely	No	9.8
CVE-2026-45642	Microsoft Azure Attestation service and Device Health Attestation Service Spoofing Vulnerability	Exploitation Less Likely	No	3.9
CVE-2026-44810	Microsoft Cryptographic Services Elevation of Privilege Vulnerability	Exploitation Less Likely	No	8.4
CVE-2026-45637	Microsoft DWM Core Library Elevation of Privilege Vulnerability	Exploitation Less Likely	No	7.8
CVE-2026-42986	Microsoft Graphics Component Elevation of Privilege Vulnerability	Exploitation More Likely	No	7.8
CVE-2026-41092	Microsoft Kinect Elevation of Privilege Vulnerability	Exploitation Less Likely	No	7.8
CVE-2026-45606	Microsoft UxTheme Library (uxtheme.dll) Denial of Service Vulnerability	Exploitation Less Likely	No	5.5
CVE-2026-42980	NT OS Kernel Elevation of Privilege Vulnerability	Exploitation More Likely	No	7.8
CVE-2026-42916	NT OS Kernel Elevation of Privilege Vulnerability	Exploitation Less Likely	No	7.8
CVE-2026-47289	Remote Desktop Client Remote Code Execution Vulnerability	Exploitation Less Likely	No	8.8
CVE-2026-47653	Remote Desktop Client Remote Code Execution Vulnerability	Exploitation Unlikely	No	8.8
CVE-2026-47654	Remote Desktop Client Remote Code Execution Vulnerability	Exploitation Unlikely	No	7.5
CVE-2026-48563	Remote Desktop Client Remote Code Execution Vulnerability	Exploitation Less Likely	No	7.5
CVE-2026-42909	Remote Desktop Client Remote Code Execution Vulnerability	Exploitation Unlikely	No	7.5
CVE-2026-42913	Remote Desktop Client Remote Code Execution Vulnerability	Exploitation Unlikely	No	7.5
CVE-2026-42992	Remote Desktop Client Remote Code Execution Vulnerability	Exploitation Less Likely	No	7.5
CVE-2026-44799	Remote Desktop Client Remote Code Execution Vulnerability	Exploitation Less Likely	No	7.5
CVE-2026-44801	Remote Desktop Client Remote Code Execution Vulnerability	Exploitation Less Likely	No	7.5
CVE-2026-42985	Remote Desktop Client Remote Code Execution Vulnerability	Exploitation More Likely	No	8.8
CVE-2026-42993	Remote Desktop Client Remote Code Execution Vulnerability	Exploitation Less Likely	No	7.5
CVE-2026-45588	Secure Boot Security Feature Bypass Vulnerability	Exploitation Less Likely	No	7.9
CVE-2026-48568	Secure Boot Security Feature Bypass Vulnerability	Exploitation Less Likely	No	7.9
CVE-2026-48570	Secure Boot Security Feature Bypass Vulnerability	Exploitation Less Likely	No	7.9
CVE-2026-48573	Secure Boot Security Feature Bypass Vulnerability	Exploitation Less Likely	No	7.9
CVE-2026-48575	Secure Boot Security Feature Bypass Vulnerability	Exploitation Less Likely	No	7.9
CVE-2026-48576	Secure Boot Security Feature Bypass Vulnerability	Exploitation Less Likely	No	7.9
CVE-2026-48578	Secure Boot Security Feature Bypass Vulnerability	Exploitation Less Likely	No	7.9
CVE-2026-45654	Secure Boot Security Feature Bypass Vulnerability	Exploitation Less Likely	No	7.9
CVE-2026-45656	UEFI Secure Boot Security Feature Bypass Vulnerability	Exploitation Less Likely	No	7.8
CVE-2026-8863	UEFI Secure Boot Security Feature Bypass Vulnerability	Exploitation Less Likely	No	7.8
CVE-2026-45648	Windows Active Directory Domain Services Remote Code Execution Vulnerability	Exploitation Unlikely	No	8.8
CVE-2026-42829	Windows Administrator Protection Secure Feature Bypass Vulnerability	Exploitation Less Likely	No	7.8
CVE-2026-34335	Windows Ancillary Function Driver for WinSock Elevation of Privilege Vulnerability	Exploitation Unlikely	No	7.0
CVE-2026-45601	Windows Ancillary Function Driver for WinSock Elevation of Privilege Vulnerability	Exploitation Less Likely	No	7.0
CVE-2026-45598	Windows Ancillary Function Driver for WinSock Elevation of Privilege Vulnerability	Exploitation Less Likely	No	7.0
CVE-2026-45596	Windows Ancillary Function Driver for WinSock Elevation of Privilege Vulnerability	Exploitation Less Likely	No	7.0
CVE-2026-45638	Windows Ancillary Function Driver for WinSock Elevation of Privilege Vulnerability	Exploitation Less Likely	No	7.8
CVE-2026-45603	Windows Ancillary Function Driver for WinSock Elevation of Privilege Vulnerability	Exploitation Less Likely	No	7.0
CVE-2026-42911	Windows Ancillary Function Driver for WinSock Elevation of Privilege Vulnerability	Exploitation Less Likely	No	7.0
CVE-2026-45594	Windows Application Identity (AppID) Information Disclosure Vulnerability	Exploitation Less Likely	No	5.5
CVE-2026-45655	Windows BitLocker Security Feature Bypass Vulnerability	Exploitation Less Likely	No	5.3
CVE-2026-45658	Windows BitLocker Security Feature Bypass Vulnerability	Exploitation More Likely	No	7.8
CVE-2026-50507	Windows BitLocker Security Feature Bypass Vulnerability	Exploitation More Likely	Yes	6.8
CVE-2026-45640	Windows Bluetooth Port Driver Elevation of Privilege Vulnerability	Exploitation Less Likely	No	7.0
CVE-2026-45605	Windows Bluetooth Service Elevation of Privilege Vulnerability	Exploitation Less Likely	No	7.8
CVE-2026-47656	Windows Boot Manager Security Feature Bypass Vulnerability	Exploitation Less Likely	No	7.9
CVE-2026-45586	Windows Collaborative Translation Framework (CTFMON) Elevation of Privilege Vulnerability	Exploitation More Likely	Yes	7.8
CVE-2026-44809	Windows Common Log File System Driver Elevation of Privilege Vulnerability	Exploitation Unlikely	No	7.8
CVE-2026-42987	Windows Deployment Services (WDS) Remote Code Execution	Exploitation Less Likely	No	8.1
CVE-2026-33828	Windows Device Health Attestation (DHA) Elevation of Privilege Vulnerability	Exploitation Unlikely	No	7.8
CVE-2026-45634	Windows DHCP Client Information Disclosure Vulnerability	Exploitation Unlikely	No	5.5
CVE-2026-45608	Windows DHCP Client Information Disclosure Vulnerability	Exploitation Unlikely	No	6.8
CVE-2026-41108	Windows DNS Client Elevation of Privilege Vulnerability	Exploitation Unlikely	No	7.0
CVE-2026-42905	Windows DWM Core Library Elevation of Privilege Vulnerability	Exploitation More Likely	No	7.8
CVE-2026-44811	Windows DWM Core Library Elevation of Privilege Vulnerability	Exploitation Less Likely	No	7.8
CVE-2026-44808	Windows DWM Core Library Elevation of Privilege Vulnerability	Exploitation Less Likely	No	7.8
CVE-2026-44807	Windows DWM Core Library Elevation of Privilege Vulnerability	Exploitation Less Likely	No	7.8
CVE-2026-42983	Windows DWM Core Library Elevation of Privilege Vulnerability	Exploitation Less Likely	No	7.8
CVE-2026-44802	Windows DWM Core Library Elevation of Privilege Vulnerability	Exploitation Less Likely	No	7.8
CVE-2026-44813	Windows DWM Core Library Elevation of Privilege Vulnerability	Exploitation Less Likely	No	7.8
CVE-2026-44804	Windows DWM Core Library Elevation of Privilege Vulnerability	Exploitation Less Likely	No	7.8
CVE-2026-48566	Windows DWM Core Library Information Disclosure Vulnerability	Exploitation Less Likely	No	5.5
CVE-2026-44814	Windows DWM Core Library Information Disclosure Vulnerability	Exploitation Less Likely	No	5.5
CVE-2026-45602	Windows Dynamic Host Configuration Protocol (DHCP) Tampering Vulnerability	Exploitation Less Likely	No	9.1
CVE-2026-42836	Windows Function Discovery Service (fdwsd.dll) Elevation of Privilege Vulnerability	Exploitation Less Likely	No	7.0
CVE-2026-44803	Windows Graphics Component Remote Code Execution Vulnerability	Exploitation More Likely	No	7.8
CVE-2026-44812	Windows Graphics Component Remote Code Execution Vulnerability	Exploitation More Likely	No	7.8
CVE-2026-42910	Windows Hotpatch Monitoring Service Elevation of Privilege Vulnerability	Exploitation Less Likely	No	7.8
CVE-2026-42972	Windows Hyper-V Information Disclosure Vulnerability	Exploitation Less Likely	No	5.5
CVE-2026-45607	Windows Hyper-V Remote Code Execution Vulnerability	Exploitation Less Likely	No	8.4
CVE-2026-45641	Windows Hyper-V Remote Code Execution Vulnerability	Exploitation Less Likely	No	8.4
CVE-2026-47652	Windows Hyper-V Remote Code Execution Vulnerability	Exploitation Less Likely	No	8.2
CVE-2026-45592	Windows Internet (wininet.dll) Elevation of Privilege Vulnerability	Exploitation Unlikely	No	7.8
CVE-2026-42903	Windows Kerberos Denial of Service Vulnerability	Exploitation Unlikely	No	6.5
CVE-2026-42914	Windows Kerberos Denial of Service Vulnerability	Exploitation Less Likely	No	5.3
CVE-2026-47288	Windows Kerberos Key Distribution Center (KDC) Remote Code Execution	Exploitation Unlikely	No	7.1
CVE-2026-48583	Windows Kernel Elevation of Privilege Vulnerability	Exploitation Less Likely	No	7.8
CVE-2026-45653	Windows Kernel Elevation of Privilege Vulnerability	Exploitation Unlikely	No	7.0
CVE-2026-42984	Windows Kernel Elevation of Privilege Vulnerability	Exploitation Unlikely	No	7.0
CVE-2026-45657	Windows Kernel Remote Code Execution Vulnerability	Exploitation Less Likely	No	9.8
CVE-2026-45600	Windows Kernel-Mode Driver Elevation of Privilege Vulnerability	Exploitation Unlikely	No	7.8
CVE-2026-45604	Windows Managed Installer Information Disclosure Vulnerability	Exploitation Less Likely	No	5.5
CVE-2026-45595	Windows Mark of the Web Security Feature Bypass Vulnerability	Exploitation Less Likely	No	5.4
CVE-2026-48574	Windows Media Remote Code Execution Vulnerability	Exploitation Less Likely	No	7.8
CVE-2026-48565	Windows Narrator Braille Elevation of Privilege Vulnerability	Exploitation Less Likely	No	7.8
CVE-2026-44805	Windows Network Controller (NC) Host Agent Denial of Service Vulnerability	Exploitation Unlikely	No	5.5
CVE-2026-45636	Windows NTFS Remote Code Execution Vulnerability	Exploitation Less Likely	No	7.8
CVE-2026-50508	Windows NTLM Spoofing Vulnerability	Exploitation More Likely	No	6.5
CVE-2026-42981	Windows Performance Monitor Remote Code Execution Vulnerability	Exploitation Less Likely	No	8.1
CVE-2026-42974	Windows Performance Monitor Remote Code Execution Vulnerability	Exploitation Less Likely	No	8.1
CVE-2026-45487	Windows Program Compatibility Assistant Service Elevation of Privilege Vulnerability	Exploitation Unlikely	No	7.8
CVE-2026-42828	Windows Projected File System Elevation of Privilege Vulnerability	Exploitation Less Likely	No	7.8
CVE-2026-42837	Windows Projected File System Elevation of Privilege Vulnerability	Exploitation Less Likely	No	7.8
CVE-2026-42969	Windows Push Notification Information Disclosure Vulnerability	Exploitation Unlikely	No	5.5
CVE-2026-42971	Windows Push Notification Information Disclosure Vulnerability	Exploitation Less Likely	No	5.5
CVE-2026-42970	Windows Push Notification Information Disclosure Vulnerability	Exploitation Less Likely	No	5.5
CVE-2026-42973	Windows Push Notification Information Disclosure Vulnerability	Exploitation Less Likely	No	5.5
CVE-2026-42978	Windows Push Notifications Elevation of Privilege Vulnerability	Exploitation Unlikely	No	7.8
CVE-2026-42977	Windows Push Notifications Elevation of Privilege Vulnerability	Exploitation Unlikely	No	7.8
CVE-2026-42979	Windows Push Notifications Elevation of Privilege Vulnerability	Exploitation Unlikely	No	7.8
CVE-2026-42991	Windows Push Notifications Elevation of Privilege Vulnerability	Exploitation Unlikely	No	7.8
CVE-2026-45639	Windows Remote Desktop Protocol (RDP) Information Disclosure Vulnerability	Exploitation Less Likely	No	7.5
CVE-2026-42908	Windows Remote Desktop Protocol (RDP) Information Disclosure Vulnerability	Exploitation Less Likely	No	7.5
CVE-2026-45593	Windows SDK Elevation of Privilege Vulnerability	Exploitation Less Likely	No	7.8
CVE-2026-42906	Windows Shell Information Disclosure Vulnerability	Exploitation Less Likely	No	5.5
CVE-2026-42907	Windows Shell Information Disclosure Vulnerability	Exploitation Less Likely	No	6.5
CVE-2026-47648	Windows Storage Elevation of Privilege Vulnerability	Exploitation Unlikely	No	7.0
CVE-2026-42915	Windows TCP/IP Denial of Service Vulnerability	Exploitation Less Likely	No	5.7
CVE-2026-42904	Windows TCP/IP Elevation of Privilege Vulnerability	Exploitation Unlikely	No	9.6
CVE-2026-42968	Windows Telephony Server Information Disclosure Vulnerability	Exploitation Less Likely	No	5.5
CVE-2026-42912	Windows Telephony Service Elevation of Privilege Vulnerability	Exploitation Less Likely	No	7.0
CVE-2026-45597	Windows UI Automation Manager (uiamanager.dll) Elevation of Privilege Vulnerability	Exploitation Unlikely	No	7.0
CVE-2026-40409	Windows Universal Disk Format File System Driver (UDFS) Elevation of Privilege Vulnerability	Exploitation Less Likely	No	7.8
CVE-2026-40404	Windows Universal Disk Format File System Driver (UDFS) Elevation of Privilege Vulnerability	Exploitation Less Likely	No	7.8
CVE-2026-45599	Windows UPnP Device Host Remote Code Execution Vulnerability	Exploitation Less Likely	No	8.1
CVE-2026-45635	Windows UPnP Device Host Remote Code Execution Vulnerability	Exploitation Less Likely	No	8.1
CVE-2026-42989	Winlogon Elevation of Privilege Vulnerability	Exploitation More Likely	No	7.8

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

CVE	Title	Exploitation status	Publicly disclosed?	CVSS v3 base score
CVE-2026-49160	HTTP.sys Denial of Service Vulnerability	Exploitation More Likely	Yes	7.5
CVE-2026-50507	Windows BitLocker Security Feature Bypass Vulnerability	Exploitation More Likely	Yes	6.8
CVE-2026-45586	Windows Collaborative Translation Framework (CTFMON) Elevation of Privilege Vulnerability	Exploitation More Likely	Yes	7.8

Critical RCEs

CVE	Title	Exploitation status	Publicly disclosed?	CVSS v3 base score
CVE-2025-10263	ARM: CVE-2025-10263 Completion of affected memory accesses might not be guaranteed by completion of a TLBI [kernel]	Exploitation Less Likely	No	9.3
CVE-2026-47643	Azure Stack Edge Remote Code Execution Vulnerability	Exploitation Unlikely	No	9.8
CVE-2026-44815	DHCP Client Service Remote Code Execution Vulnerability	Exploitation Less Likely	No	9.8
CVE-2026-47291	HTTP.sys Remote Code Execution Vulnerability	Exploitation More Likely	No	9.8
CVE-2026-26142	Nuance PowerScribe Remote Code Execution Vulnerability	Exploitation Less Likely	No	9.8
CVE-2026-47281	Visual Studio Code Elevation of Privilege Vulnerability	Exploitation Unlikely	No	9.6
CVE-2026-45602	Windows Dynamic Host Configuration Protocol (DHCP) Tampering Vulnerability	Exploitation Less Likely	No	9.1
CVE-2026-45657	Windows Kernel Remote Code Execution Vulnerability	Exploitation Less Likely	No	9.8
CVE-2026-42904	Windows TCP/IP Elevation of Privilege Vulnerability	Exploitation Unlikely	No	9.6

Future of Ubuntu MATE

2026-06-09 jzb

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

Thomas Ward has published
an update about the future of the Ubuntu MATE project, which did not have a
26.04 release with the other Ubuntu flavors in
April:

There is a new team working on Ubuntu MATE who have stepped up to
help take over flavor management. They haven’t formally introduced
themselves yet, but I can safely say that other developers HAVE
stepped up for the future of the MATE flavor, despite its prior team
lead having stepped down.

[…] Ultimately, this means that they are working to cover the
missed items and gaps, and may quite possibly have a 26.10 release in
October of 2026, which I believe they most likely are targeting.

This also means that bugs in the MATE environment and in packages
they normally would have shipped had they have a 26.04 release are
still going to get attention and fixes. So, effectively, nothing has
changed. The only difference is that there was no 26.04 installer
image released.

For those looking to install a MATE desktop on a “clean” install of
Ubuntu 26.04, Ward suggests installing Ubuntu Server and then
installing the ubuntu-mate-desktop package.

[$] Eliminating long-lived credentials with trusted publishing

2026-06-09 jzb

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

Trusted
publishing is an authentication mechanism that relies on
short-lived credentials to reduce the risk of supply-chain attacks. At
the 2026 Open
Source Summit North America, Mike Fiedler walked the audience
through why trusted publishing exists, how it works, and made the case
for its adoption. It is not a silver bullet against all attacks, but
it does offer protection against theft of long-lived credentials used
to publish to package registries.

Anthropic Claude Fable 5 on AWS: Mythos-class capabilities with built-in safeguards now available

2026-06-09 Channy Yun (윤석찬)

Post Syndicated from Channy Yun (윤석찬) original https://aws.amazon.com/blogs/aws/anthropic-claude-fable-5-on-aws-mythos-class-capabilities-with-built-in-safeguards-now-available/

Today, we’re announcing the availability of Claude Fable 5 on Amazon Bedrock and Claude Platform on AWS. Claude Fable 5 makes Mythos-level capabilities available to customers, with strong safeguards designed to make it safe for broader use. Fable 5 is state-of-the-art on nearly all tested benchmarks and delivers exceptional performance in software engineering, knowledge work tasks, and vision – built for ambitious, long running work.

With Claude Fable 5 on Bedrock, you can build within your existing AWS environment and scale inference workloads. You can also use Claude Fable 5 through the Claude Platform on AWS, giving you Anthropic’s native platform experience.

According to Anthropic, Claude Fable 5 represents a step-change in what you can accomplish with AI models. Here is what makes this model different:

Long-running, asynchronous execution — Claude Fable 5 handles complex tasks that previous models could not sustain, executing coding and knowledge work tasks for extended periods without intervention.
Advanced vision capabilities — Claude Fable 5 understands diagrams, charts, and tables nested in files and PDFs. This opens up research and document-heavy work in finance, legal, analytics, architecture, and gaming. In coding, the model implements designs with high fidelity and uses vision to critique its output against goals.
Proactive self-verification — The model self-updates skills based on learnings, develops its own harnesses and evaluations.

Claude Fable 5 includes safeguards that limit its performance in specific areas where misuse risk is elevated. Harmful prompts related to cybersecurity, biology, chemistry, and health fall back to receive a response from Opus 4.8 instead. Anthropic is able to expand access to nearly all of Claude Fable 5’s state-of-the-art capabilities by developing more powerful safeguards. The same model without these limits is Claude Mythos 5 and it will only be available to a small group of vetted customers.

Claude Fable 5 model in action
You can use Claude Fable 5 in both Amazon Bedrock and Claude Platform on AWS. This post will cover guidance on how to access and use on Amazon Bedrock. For guidance on the Claude Platform on AWS, visit the documentation to learn more.

To get started with Amazon Bedrock, you can access the model programmatically now using the Anthropic Messages API to call the bedrock-runtime or bedrock-mantle endpoints through Anthropic SDK. You can sole keep using the Invoke and Converse API on bedrock-runtime through the AWS Command Line Interface (AWS CLI) and AWS SDK.

In order to access Claude Fable 5 model, you must opt into data sharing by using the Data Retention API and setting provider_data_sharing before you can invoke the models. There is no console user interface for this setting at launch.

curl -X PUT https://bedrock-mantle.us-east-1.api.aws/v1/data_retention \
  -H "x-api-key: <your-bedrock-api-key>" \ 
  -H "Content-Type: application/json" \
  -d '{ "mode": "provider_data_share" }'

This mode allows Amazon Bedrock to retain and share your inference data with model providers per their requirements. Anthropic requires 30-day inputs and outputs retention, as well as human review. To learn more, visit the Amazon Bedrock abuse detection.

Let’s start with Anthropic SDK for Python using the Messages API on bedrock-mantle endpoint. Install Anthropic SDK.

pip install anthropic

Here is a sample Python code to call Claude Fable 5 model:

import anthropic

client = anthropic.Anthropic(
    base_url="https://bedrock-mantle.us-east-1.api.aws/anthropic",
    api_key= <your-bedrock-api-key>
)

message = client.messages.create( 
     model="anthropic.claude-fable-5", 
	 max_tokens=4096, 
	 messages=[ 
	     { "role": "user", 
		   "content": "Design a distributed architecture on AWS in Python that should support 100k requests per second across multiple geographic regions", 
		 }, 
	 ], 
)

print(message.content[0].text)

To learn more, check out Anthropic Messages API code examples and notebook examples for multiple use cases and a variety of programming languages.

You can also use Claude Fable 5 with the Invoke API and Converse API on bedrock-runtime endpoint. Here’s a example to call Converse API for a unified multi-model experience using the AWS SDK for Python (Boto3):

import boto3 
bedrock_runtime = boto3.client("bedrock-runtime", region_name="us-east-1") 
response = bedrock_runtime.converse( 
    modelId="us.anthropic.claude-fable-5", 
    messages=[ 
        { 
            "role": "user", 
            "content": [ 
                { 
                    "text": "Design a distributed architecture on AWS in Python that should support 100k requests per second across multiple geographic regions." 
                } 
            ] 
        } 
    ], 
    inferenceConfig={ 
        "maxTokens": 4096 
    } 
) 
print(response["output"]["message"]["content"][0]["text"])

To learn more, visit code examples that show how to use Amazon Bedrock Runtime with AWS SDKs.

Things to know
Let me share some important technical details that I think you’ll find useful.

Model access — Claude Fable 5 access is gradually expanding for all AWS accounts. If your account doesn’t have access yet, it will be enabled soon depending on your Bedrock usage. If you want to get access to this model quickly, contact your usual AWS Support.
Pricing — When a harmful prompt is routed to Opus 4.8 instead of Fable 5, you pay only Opus prices. If a request is blocked mid-conversation, initial tokens are charged at Fable rates and subsequent tokens at Opus rates. To learn more, visit the Amazon Bedrock pricing page.
Data retention — For Fable 5, Mythos 5, and future models on Bedrock with similar or higher capability levels, Anthropic will require 30-day retention for all traffic on Mythos-class models. Retaining data for a limited period allows Anthropic to detect patterns of misuse that are not visible from a single exchange. Once you opt into data retention, your data will leave AWS’s data and security boundary.
Claude Mythos 5 on Bedrock (Limited Preview) — You can also use Anthropic’s most capable model for cybersecurity and life sciences, including vulnerability discovery, drug design, and biodefense screening. Access is currently limited due to the dual-use nature of these domains. To learn more, visit the model card documentation.

Now available
Anthropic’s Claude Fable 5 model is available today on Amazon Bedrock in the US East (N. Virginia) and Europe (Stockholm) Regions; check the full list of Regions for future updates. Claude Fable 5 is also available on the Claude Platform on AWS in North America, South America, Europe, and Asia Pacific.

Give Claude Fable 5 a try with the Amazon Bedrock APIs, in the Claude Platform on AWS, and send feedback to AWS re:Post for Amazon Bedrock or through your usual AWS Support contacts.

— Channy

Updated on June 9, 2026 — You can use the console on bedrock-runtime engine. The console support on bedrock-mantle is coming soon.

Beyond JSON blobs: Implementing the VARIANT data type in Apache Iceberg V3

2026-06-09 Arun Shanmugam

Post Syndicated from Arun Shanmugam original https://aws.amazon.com/blogs/big-data/beyond-json-blobs-implementing-the-variant-data-type-in-apache-iceberg-v3/

Apache Iceberg V3 introduces the VARIANT data type. VARIANT provides data engineers with a high-performance, native solution for managing semi-structured data within the data lake. Consider a massive fleet of IoT sensors: street-level temperature probes, air quality monitors, and vehicle telemetry. Each device emits data in unique JSON structures that constantly evolve with firmware updates.

Historically, engineers were forced to store these payloads as STRING blobs. This legacy approach mandates expensive CPU-intensive parsing at runtime and inflates storage costs with redundant raw text. VARIANT solves these inefficiencies by employing a shredded, binary-encoded format. This allows query engines to skip irrelevant data and access specific nested fields with columnar speed, effectively bridging the gap between the flexibility of JSON and the performance of a structured schema.

VARIANT is stored in Parquet as a three-part group: binary metadata (type and dictionary info), a binary value (the full variant for fallback), and a typed_value group where individual JSON fields are shredded into separate Parquet columns. When you query a specific field, Spark prunes the typed_value group to include only the requested sub-columns. It always retains metadata and the value fallback, so it avoids reading the entire document. This approach delivers two concrete benefits:

Reduced query processing time: Queries access only the fields they need without deserializing entire JSON documents. This reduces the amount of data scanned and the time spent on deserialization.
Lower storage footprint: Binary encoding compresses more efficiently than raw text, reducing storage costs.

Fields inside the JSON become individually accessible columns under the hood. A query that needs one value out of a deeply nested document no longer must read and deserialize the entire thing. You maintain schema flexibility while gaining the performance characteristics of structured columnar storage.

This post is part 1 of a two-part series. We walk through the basics: creating an Iceberg V3 table with a VARIANT column, inserting semi-structured data, and querying it with variant_get(). In Part 2, we scale to millions of rows and benchmark VARIANT against traditional string storage. We measure the difference in query performance and storage footprint.

Solution overview

This walkthrough demonstrates an end-to-end workflow for working with semi-structured data using the VARIANT data type in Apache Iceberg V3 on Amazon EMR Serverless. Raw JSON payloads are ingested and converted to binary VARIANT format using parse_json(). The data is stored in an Iceberg V3 table where the engine shreds the structure into columnar Parquet sub-columns. You can then query the data efficiently using variant_get() to extract specific fields without deserializing the entire document. AWS Glue Data Catalog manages the table metadata. Amazon Simple Storage Service (Amazon S3) provides the underlying storage.

Note: Check the Apache Iceberg documentation for the latest information on specification status and engine compatibility. Additionally, Fine-Grained Access Control (FGAC) through AWS Lake Formation is not currently supported for the VARIANT data type.

How VARIANT works

When you insert a JSON document into a VARIANT column, Spark converts it from a JSON string into the Variant binary format. During writes, the engine can shred the structure. It extracts individual fields and stores them as native Parquet-typed sub-columns within the VARIANT column’s typed_value group. Fields that are not shredded remain in the binary value column as a fallback. This is conceptually similar to how a columnar table stores each column independently. The difference is that the sub-columns live within a single VARIANT column, and the engine handles the shredding schema automatically.

At query time, when you ask for a specific field using variant_get(), Spark reads only the sub-column that contains that field. It does not need to load or parse the rest of the document. For workloads that repeatedly query a handful of fields out of large, complex JSON payloads, this can significantly reduce the amount of data scanned. It also reduces the time spent deserializing it.

The variant_get() function uses JSON path syntax to navigate the structure. You can extract scalar values with an explicit type (optional), access nested objects, and reach into arrays by index. The function signature is the following.

variant_get(column, '$.path.to.field', 'type')

Where column is the VARIANT column name, the second argument is a JSON path expression, and the optional third argument specifies the expected return type (such as 'string', 'int', or 'double'). When the type argument is omitted, the function returns a VARIANT value that preserves the original encoding.

Running Iceberg V3 on Amazon EMR Serverless

Amazon EMR Serverless 8.0 ships with Apache Spark 4.0.1, which includes native support for Iceberg V3 and the VARIANT data type. You do not need to install additional libraries or configure custom JARs. Amazon EMR Serverless manages the compute infrastructure and scales resources up and down based on workload demand. You can focus on the data rather than the cluster.

While this post uses Amazon EMR Serverless, Iceberg V3 VARIANT support is also available on Amazon EMR on EC2 and Amazon EMR on EKS. You can choose the deployment model that fits your environment.

Getting started

The following walkthrough creates an Iceberg V3 table with a VARIANT column, inserts a set of IoT sensor events, and runs queries to extract fields from the semi-structured payload. Each step includes the code you need to run it on Amazon EMR Serverless.

Prerequisites

Before you begin, verify you have the following:

An AWS account with permissions to create Amazon EMR Serverless applications and access Amazon Simple Storage Service (Amazon S3).
An Amazon S3 bucket for storing Iceberg table data and scripts.
AWS Glue Data Catalog configured for metadata management.
An IAM execution role with permissions for Amazon EMR Serverless, Amazon S3, AWS Glue, and Amazon CloudWatch Logs.
AWS Command Line Interface (AWS CLI) installed and configured.Note: Running this solution in your AWS account might incur charges for Amazon EMR Serverless, Amazon S3, and AWS Glue. Refer to the respective pricing pages for cost details.

Step 1: Initialize a Spark session with Iceberg V3

Start by creating a Spark session configured to use the Iceberg catalog backed by AWS Glue. The key settings are the Iceberg Spark extensions and the AWS Glue catalog implementation. Replace <YOUR_S3_BUCKET> with your bucket name.

from pyspark.sql import SparkSession
from pyspark.sql.functions import col, parse_json

spark = SparkSession.builder \
    .appName("IcebergV3VariantDemo") \
    .config("spark.sql.extensions",
            "org.apache.iceberg.spark.extensions.IcebergSparkSessionExtensions") \
    .config("spark.sql.catalog.glue_catalog",
            "org.apache.iceberg.spark.SparkCatalog") \
    .config("spark.sql.catalog.glue_catalog.warehouse",
            "s3://<YOUR_S3_BUCKET>/warehouse/") \
    .config("spark.sql.catalog.glue_catalog.catalog-impl",
            "org.apache.iceberg.aws.glue.GlueCatalog") \
    .config("spark.sql.catalog.glue_catalog.io-impl",
            "org.apache.iceberg.aws.s3.S3FileIO") \
    .getOrCreate()

When running on Amazon EMR Serverless, some Spark configurations might be set at the application or job level. The configuration shown here is included in the script for completeness. Depending on your Amazon EMR Serverless application settings, you might not need to specify all these properties in the script.

Step 2: Create an Iceberg V3 table with a VARIANT column

Create a namespace and table. The format version must be set to 3 for VARIANT data type support. The following table models IoT sensor events with a few standard columns and a VARIANT column for the semi-structured payload.

spark.sql("CREATE NAMESPACE IF NOT EXISTS glue_catalog.iceberg_v3_demo")

spark.sql("""
CREATE TABLE IF NOT EXISTS glue_catalog.iceberg_v3_demo.sensor_events (
    event_id STRING,
    device_id STRING,
    event_timestamp TIMESTAMP,
    event_data VARIANT
)
USING iceberg
TBLPROPERTIES (
    'format-version' = '3'
)
""")

The event_data column is declared as VARIANT. Iceberg stores it in Parquet as a binary-encoded VARIANT structure (metadata, value, and optional shredded sub-columns) rather than as a plain text string.

Step 3: Insert semi-structured data

To insert JSON data into a VARIANT column, use the parse_json() function. This converts a JSON string into the binary VARIANT format at write time. The following example creates a small DataFrame of IoT events and appends them to the table.

import json
from pyspark.sql.functions import current_timestamp
from pyspark.sql.types import StructType, StructField, StringType

# Sample IoT events with nested JSON payloads
events = [
    ("evt_001", "sensor_001", json.dumps({
        "device": {"manufacturer": "SensorTech", "model": "ST-200",
                   "firmware_version": "3.1.4"},
        "sensors": {"temperature": 22.5, "humidity": 61.3,
                    "air_quality": {"pm25": 12.4, "co2": 415}},
        "network": {"connection": "WiFi", "latency_ms": 42},
        "alerts": [{"severity": "low", "message": "Calibration due"}]
    })),
    ("evt_002", "sensor_002", json.dumps({
        "device": {"manufacturer": "IoTCorp", "model": "IC-500",
                   "firmware_version": "2.8.1"},
        "sensors": {"temperature": 34.1, "humidity": 78.9,
                    "air_quality": {"pm25": 142.7, "co2": 1850}},
        "network": {"connection": "LTE", "latency_ms": 210},
        "alerts": [{"severity": "critical",
                    "message": "Temperature threshold exceeded"},
                   {"severity": "high",
                    "message": "Poor air quality detected"}]
    })),
    ("evt_003", "sensor_003", json.dumps({
        "device": {"manufacturer": "SmartDevices", "model": "SD-100",
                   "firmware_version": "1.5.9"},
        "sensors": {"temperature": 18.7, "humidity": 45.2,
                    "air_quality": {"pm25": 8.1, "co2": 390}},
        "network": {"connection": "Ethernet", "latency_ms": 5},
        "alerts": []
    })),
]

schema = StructType([
    StructField("event_id", StringType(), False),
    StructField("device_id", StringType(), False),
    StructField("event_data", StringType(), False),
])

df = spark.createDataFrame(events, schema)
df = df.withColumn("event_timestamp", current_timestamp())

# Convert JSON string to VARIANT using parse_json
df = df.withColumn("event_data", parse_json(col("event_data")))

df.writeTo("glue_catalog.iceberg_v3_demo.sensor_events").append()
print("Data inserted successfully.")

The parse_json() call is the key step. It takes the raw JSON string and encodes it into the binary VARIANT format before writing to the Iceberg table.

Step 4: Query VARIANT data with variant_get()

Once the data is in the table, you can extract individual fields from the VARIANT column using variant_get(). The following queries demonstrate three common patterns: simple field extraction, deep nested access with filtering, and array element access.

The following queries are shown as raw SQL for readability. To run them in your PySpark script, wrap each query in a spark.sql() call. For example: spark.sql("SELECT ...").show().

Query 1: Simple field extraction

Extract top-level sensor readings from the payload.

SELECT
    event_id,
    device_id,
    variant_get(event_data, '$.sensors.temperature', 'double') AS temperature,
    variant_get(event_data, '$.sensors.humidity', 'double') AS humidity
FROM glue_catalog.iceberg_v3_demo.sensor_events

This query reads only the temperature and humidity sub-columns from the VARIANT data. It does not parse or load the rest of the JSON document.

Query 2: Deep nested access with filtering

Reach into nested objects and filter on a value buried inside the structure.

SELECT
    device_id,
    variant_get(event_data, '$.sensors.air_quality.pm25', 'double') AS pm25,
    variant_get(event_data, '$.sensors.air_quality.co2', 'int') AS co2_level,
    variant_get(event_data, '$.device.manufacturer', 'string') AS manufacturer
FROM glue_catalog.iceberg_v3_demo.sensor_events
WHERE variant_get(event_data, '$.sensors.air_quality.pm25', 'double') > 100.0

The WHERE clause filters directly on a nested VARIANT field. Spark evaluates the predicate against the shredded sub-column without deserializing the full payload.

Query 3: Array element access

Access elements inside a JSON array stored within the VARIANT column.

SELECT
    event_id,
    device_id,
    variant_get(event_data, '$.alerts[0].severity', 'string') AS first_alert_severity,
    variant_get(event_data, '$.alerts[0].message', 'string') AS first_alert_message
FROM glue_catalog.iceberg_v3_demo.sensor_events
WHERE variant_get(event_data, '$.alerts[0].severity', 'string') = 'critical'

Array indexing uses standard bracket notation in the JSON path. This query finds events where the first alert has critical severity and returns the alert details.

Query results showing simple field extraction, nested access with filtering, and array element access from the VARIANT column

Figure 1: Query results showing simple field extraction, nested access with filtering, and array element access from the VARIANT column.

Submitting the job to Amazon EMR Serverless

To run this on Amazon EMR Serverless, save the preceding code as a single PySpark script (for example, iceberg_v3_variant_demo.py), upload it to Amazon S3, and submit it as a job. Replace the placeholder values with your own.

Before submitting the job, make sure you have created an Amazon EMR Serverless application. For instructions, see Getting started with Amazon EMR Serverless in the Amazon EMR documentation.

# Upload script to S3
aws s3 cp iceberg_v3_variant_demo.py \
    s3://<YOUR_S3_BUCKET>/scripts/ \
    --region <REGION>

# Submit the job
aws emr-serverless start-job-run \
    --application-id <APPLICATION_ID> \
    --execution-role-arn arn:aws:iam::<ACCOUNT_ID>:role/EMRServerlessExecutionRole \
    --job-driver '{
        "sparkSubmit": {
            "entryPoint": "s3://<YOUR_S3_BUCKET>/scripts/iceberg_v3_variant_demo.py"
        }
    }' \
    --configuration-overrides '{
        "monitoringConfiguration": {
            "cloudWatchLoggingConfiguration": {
                "enabled": true,
                "logGroupName": "/aws/emr-serverless/applications/<APPLICATION_ID>"
            }
        }
    }' \
    --region <REGION>

Use cases

VARIANT fits naturally into workloads where the data is semi-structured and the schema is not fully known in advance. Some use cases include the following:

IoT and sensor data: Device fleets produce telemetry in varying JSON formats that evolve with firmware updates. VARIANT stores these payloads without requiring a fixed schema, and queries can extract specific readings without scanning the entire document.
Clickstream analytics: User behavior events on websites and mobile apps carry different attributes depending on the action. Page views, clicks, form submissions, and purchases each have their own structure. VARIANT accommodates these data types in a single column.
Log analytics: Application logs, infrastructure metrics, and audit trails often arrive as unstructured or loosely structured JSON. VARIANT lets you ingest them as is and query specific fields on demand, without defining a schema up front.

Clean up

To avoid ongoing charges, delete the resources you created:

Drop the Iceberg table and namespace using Spark SQL.

spark.sql("DROP TABLE IF EXISTS glue_catalog.iceberg_v3_demo.sensor_events")
spark.sql("DROP NAMESPACE IF EXISTS glue_catalog.iceberg_v3_demo")

Stop and delete the Amazon EMR Serverless application.

aws emr-serverless delete-application --application-id <APPLICATION_ID> --region <REGION>

Delete the S3 objects and bucket used for table data, scripts, and logs.

aws s3 rm s3://<YOUR_S3_BUCKET>/warehouse/ --recursive
aws s3 rm s3://<YOUR_S3_BUCKET>/scripts/ --recursive

Conclusion

Apache Iceberg V3’s VARIANT type provides an efficient way to store and query semi-structured data in your data lake. Columnar storage and shredding reduce storage costs, and direct field access through variant_get() removes the need to parse JSON strings at query time. On Amazon EMR Serverless, you get this capability without managing infrastructure.

In Part 2 of this series, we scale to millions of rows and benchmark VARIANT against traditional string storage. We measure query performance and storage footprint under realistic workloads.

To learn more about Apache Iceberg on AWS, see Apache Iceberg on AWS prescriptive guidance. For more information about Amazon EMR Serverless, see the Amazon EMR Serverless documentation.

About the authors

Automate medical record digitization with Amazon Bedrock Data Automation and AWS HealthLake

2026-06-09 Gerardo Alarcon Rivas

Post Syndicated from Gerardo Alarcon Rivas original https://aws.amazon.com/blogs/architecture/automate-medical-record-digitization-with-amazon-bedrock-data-automation-and-aws-healthlake/

Healthcare providers manage millions of paper medical records that remain disconnected from modern clinical systems. Clinicians make decisions without full patient histories, organizations spend millions on manual data entry, and critical information stays trapped in formats that modern applications can’t read. The technical challenge is clear: how do you transform unstructured, scanned documents into standardized, interoperable health data at scale, without building custom machine learning (ML) models or hand-coding document parsers for every form type.

In this post, you learn how to build an automated, serverless pipeline that converts scanned PDF medical records into FHIR R4-compliant data using Amazon Bedrock Data Automation and AWS HealthLake. We walk through the architecture, explain how each AWS service connects to the next, show you what the pipeline looks like when it runs, and get you deployed in under 20 minutes. For advanced configuration, troubleshooting, and customization options, see the GitHub repository.

The challenge with paper medical records

Healthcare organizations face a compounding problem. Paper records don’t only create storage challenges, they create care gaps. When a patient arrives at a new facility, clinicians often proceed with incomplete information because retrieving and interpreting historical records takes too long. Manual digitization is expensive, error-prone, and doesn’t scale.

The solution requires more than scanning documents. It requires extracting structured, clinically meaningful data and storing it in a format that integrates with existing systems. That’s where Fast Healthcare Interoperability Resources (FHIR) comes in. FHIR is the healthcare industry’s standard for exchanging electronic health information.

Solution overview

This solution uses an event-driven, serverless architecture to automate the full journey from PDF upload to queryable FHIR data. No custom machine learning models or manual template configuration are required.

AWS services used:

Amazon Bedrock Data Automation (BDA): Extracts over 50 structured clinical fields from scanned PDFs using advanced AI capabilities, including patient demographics, diagnoses with ICD-10 codes, medications, vital signs, and lab results.
AWS Lambda: Two serverless functions orchestrate the pipeline: a BDA Trigger function that fires when a PDF is uploaded, and a FHIR Processor function that converts extracted JSON into FHIR R4 format.
Amazon Simple Storage Service (Amazon S3): Input and output buckets with event notifications drive the pipeline automatically, with no polling or scheduled jobs required.
AWS HealthLake: A FHIR R4-compliant, HIPAA-eligible data store that validates, indexes, and exposes data through standard FHIR API endpoints.
AWS CloudFormation: Provisions the entire infrastructure as code in a single automated deployment (approximately 15–20 minutes).
Amazon CloudWatch and AWS CloudTrail: Provide end-to-end monitoring, logging, and audit trails across all pipeline components.
AWS Key Management Service (AWS KMS): Encrypts AWS HealthLake data at rest using customer managed keys.

Important: This solution is a demonstration sample designed for use with synthetic data only. It’s not production-ready for real Protected Health Information (PHI) without additional HIPAA security controls. See the Security considerations section before deploying in any environment with real patient data.

Architecture

End-to-end architecture showing the event-driven pipeline from PDF upload to FHIR-compliant data storage

Figure 1: End-to-end architecture showing the event-driven pipeline from PDF upload to FHIR-compliant data storage

The pipeline runs in three phases, each building on the last.

Phase 1: Infrastructure deployment

AWS CloudFormation provisions all required resources in a single stack: Amazon S3 input and output buckets, two Lambda functions, AWS Identity and Access Management (IAM) roles with least-privilege permissions, AWS KMS keys, CloudWatch log groups, and an AWS HealthLake FHIR R4 datastore. The entire environment, including all service-to-service permissions, is version-controlled and repeatable.

Phase 2: Event-driven data processing

The processing pipeline is fully event-driven. No scheduler or orchestration service is required. Each step triggers the next automatically:

PDF Upload → S3 Input Bucket
S3 Event → Triggers BDA Lambda function
BDA Processing → Extracts over 50 clinical fields with confidence scores
JSON Storage → S3 Output Bucket
S3 Event → Triggers FHIR Processor Lambda function
FHIR Conversion → Creates FHIR R4 Bundle (JSON + NDJSON)
HealthLake Import → Automatic NDJSON ingestion and validation
FHIR API Access → Query using HealthLake endpoints

Phase 3: Query and analytics

After the data is in AWS HealthLake, it’s immediately queryable using standard FHIR R4 API endpoints. Python scripts authenticate using AWS Signature Version 4 (SigV4) and support searches by patient, condition, medication, or lab result type.

How the services connect

Understanding the service interconnections is key to customizing or extending this solution.

Amazon S3 as the pipeline backbone

Amazon S3 plays a dual role: it’s both the entry point for raw PDFs and the handoff layer between processing stages. Amazon S3 event notifications remove the need for polling. When a PDF lands in the input bucket, the BDA Lambda fires immediately. When BDA writes its JSON output to the output bucket, the FHIR Processor Lambda fires automatically. This decoupled design means that each stage can scale independently.

Amazon Bedrock Data Automation as the intelligence layer

BDA serves as the intelligence layer. When Lambda triggers the extraction job, BDA retrieves the PDF from Amazon S3 and applies a custom medical blueprint, which is a schema defining the over 50 clinical fields to extract. The service understands document structure without requiring templates or training data. Each extracted field is returned with a confidence score (0.0–1.0), which the FHIR Processor Lambda uses to apply validation thresholds before conversion.

AWS Lambda as the transformation layer

The two Lambda functions are intentionally narrow in scope:

The BDA Trigger Lambda receives the Amazon S3 event, constructs the BDA API call, and submits the processing job.
The FHIR Processor Lambda reads BDA’s JSON output, maps each extracted field to the appropriate FHIR R4 resource type, assembles a FHIR Bundle, exports it as NDJSON, and triggers an AWS HealthLake import job.

This separation of concerns makes each function independently testable and replaceable.

AWS HealthLake as the FHIR data store

AWS HealthLake receives the NDJSON import, validates each resource against the FHIR R4 specification, creates relationships between resources (for example, linking Condition resources to their Patient), indexes data for efficient querying, and generates unique FHIR resource IDs. The result is a fully queryable FHIR data store accessible through authenticated API calls.

IAM roles as the security fabric

Each service communicates with the next using IAM roles with least-privilege permissions. There are no hardcoded credentials and no overly broad policies. Lambda functions assume roles that grant only the specific actions they need (for example, bedrock-data-automation:InvokeDataAutomationAsync and s3:GetObject for the BDA Trigger Lambda).

Walkthrough

This walkthrough takes you from prerequisites through deployment and verification.

Prerequisites

Before deploying, confirm you have the following:

Required software:

Python 3.10 or later.
Poetry (Python dependency management).
AWS Command Line Interface (AWS CLI) configured with appropriate credentials.

Verify your Poetry installation:

poetry --version

If you need to install Poetry:

curl -sSL https://install.python-poetry.org | python3 -

Required AWS permissions:

You need IAM permissions for the following services:

Amazon Bedrock Data Automation.
AWS CloudFormation (create, update, and delete stacks).
Amazon S3 (create buckets, upload and download objects).
AWS Lambda (create and update functions).
AWS Identity and Access Management (IAM) (create roles and policies).
AWS HealthLake (create data stores).

Supported AWS Regions:

This solution currently supports us-east-1 (US East N. Virginia) and us-west-2 (US West Oregon) only. These are the Regions where Amazon Bedrock Data Automation is available.

Deploy the pipeline

Deployment takes approximately 15–20 minutes. Run the following four commands to go from zero to a fully deployed pipeline:

# 1. Clone the repository and install dependencies
git clone <repository-url>
cd Medical-Record-Digitization-and-FHIR-Integration-Pipeline
poetry install

# 2. Configure your environment
poetry run python src/utils/setup_env.py

# 3. Deploy the CloudFormation stack (approximately 15 minutes)
poetry run python src/automation/deploy.py

# 4. Verify deployment
aws cloudformation describe-stacks \
  --stack-name bda-medical-records-stack \
  --query 'Stacks[0].StackStatus'
# Expected output: "CREATE_COMPLETE"

The deployment creates the following resources:

Amazon Bedrock Data Automation blueprint and project (custom medical records schema with over 50 fields).
Amazon S3 input and output buckets with automatic event notifications.
Two AWS Lambda functions (BDA Trigger and FHIR Processor).
AWS HealthLake FHIR R4 data store.
AWS Identity and Access Management (IAM) roles and policies with least-privilege permissions.
Amazon CloudWatch log groups for all Lambda executions.

For manual environment configuration, advanced deployment options, and troubleshooting, see the GitHub repository.

See it in action

After it’s deployed, upload a sample medical record to trigger the full pipeline. You can use the sample provided in the GitHub repository.

# Get your input bucket name from the CloudFormation stack output
INPUT_BUCKET=$(aws cloudformation describe-stacks \
  --stack-name bda-medical-records-stack \
  --query 'Stacks[0].Outputs[?OutputKey==`InputBucketName`].OutputValue' \
  --output text)

# Upload a sample PDF (use the synthetic records included in the repository)
aws s3 cp samples/medical-record-sample.pdf s3://$INPUT_BUCKET/

# Track BDA processing jobs
poetry run python src/utils/track_bda_jobs.py

Within 2–3 minutes, Amazon Bedrock Data Automation processes the PDF and the FHIR Processor Lambda imports the results into HealthLake. View the extracted data:

poetry run python src/utils/view_results.py

Example output:

Found 8 result files in output bucket
Processing: medical-record-sample_results.json

Patient Information:
---------------------
Name: Wilkins, Samantha
Patient ID: A1B2C3D4
Date of Birth: 10/28/1953

Conditions (5 found):
- Hypothyroidism (ICD-10: E03.9) - Confidence: 0.98
- Vitamin D Deficiency (ICD-10: E55.9) - Confidence: 0.95
- Hypertension (ICD-10: I10) - Confidence: 0.97
- Osteoarthritis (ICD-10: M19.90) - Confidence: 0.92
- Gastroesophageal Reflux Disease (ICD-10: K21.9) - Confidence: 0.96

Medications (4 found):
- Levothyroxine 100 mcg daily
- Vitamin D3 2000 IU daily
- Lisinopril 10 mg daily
- Omeprazole 20 mg daily
Lab Results (16 tests):
TSH: 2.3 mIU/L (Normal range: 0.4-4.0) ✓
Vitamin D: 28 ng/mL (Normal range: 30-100) ⚠
Blood Pressure: 128/82 mmHg (Stage 1 Hypertension) ⚠

[✅] FHIR conversion complete
[✅] Imported to HealthLake datastore: ds-abc123xyz456

Query FHIR data from AWS HealthLake

After ingestion, query your data using the interactive FHIR query interface:

poetry run python src/utils/query_medical_data.py

Supported FHIR query patterns:

# Search by patient name
Patient?name=Wilkins

# Get conditions for a specific patient
Condition?patient=Patient/47ef817a-9826-4498-b693-2af5eb2b5250

# Get lab results only
Observation?category=laboratory

# Get vital signs only
Observation?category=vital-signs

# Get all medications
MedicationRequest

Python example, authenticated FHIR API call:

import boto3, requests, os
from botocore.auth import SigV4Auth
from botocore.awsrequest import AWSRequest

session = boto3.Session()
credentials = session.get_credentials()
region = os.environ.get('AWS_REGION', 'us-west-2')
datastore_id = os.environ.get('DATASTORE_ID')

url = f'https://healthlake.{region}.amazonaws.com/datastore/{datastore_id}/r4/Patient?name=Wilkins'
request = AWSRequest(method='GET', url=url, headers={'Accept': 'application/fhir+json'})
SigV4Auth(credentials, 'healthlake', region).add_auth(request)

response = requests.get(url, headers=dict(request.headers))
print(response.json())

Security considerations

This is a demonstration sample for synthetic data only. Do not use with real Protected Health Information (PHI) without implementing the controls listed in the following sections.

Security controls included in this sample:

IAM roles with least-privilege permissions.
Amazon S3 bucket access controls (private by default).
AWS KMS encryption for AWS HealthLake data at rest.
AWS service-to-service authorization using IAM roles.
Amazon CloudWatch logging for audit trails.

Additional controls required for production PHI workloads:

AWS HealthLake is a HIPAA Eligible Service. Customers must review the AWS Shared Responsibility Model to understand their security and compliance obligations. Before processing real patient data, implement the following:

AWS Business Associate Addendum (BAA): Required under HIPAA before processing PHI on AWS.
Amazon Virtual Private Cloud (Amazon VPC) isolation: Lambda functions and AWS HealthLake in private subnets with AWS PrivateLink.
Comprehensive logging: AWS CloudTrail, AWS Config, Amazon S3 access logs, and Amazon VPC flow logs.
Encryption in transit: TLS 1.2 or later. Use Amazon VPC endpoints to avoid public internet exposure.
Access controls: Multi-factor authentication (MFA), role-based access control (RBAC), temporary credentials, and regular access reviews.
Compliance monitoring: AWS Security Hub with HIPAA compliance checks.
Data lifecycle management: Retention policies, secure deletion, and data loss prevention (DLP) controls.

For full guidance, see the AWS HIPAA Compliance page.

Pricing

The following estimates apply to testing with approximately 100 medical records per month in the US West (Oregon) Region:

Service	Usage	Estimated monthly cost
Amazon Bedrock Data Automation	100 pages (approximately $0.20–$0.30/page)	$20–$30
AWS HealthLake	5 GB storage + 100 queries	$15–$20
AWS Lambda	200 invocations (512 MB, approximately 30s avg)	$5–$10
Amazon S3	1 GB storage + 200 requests	$1–$2
AWS KMS	1 customer managed key	$1
Total approximately $50–$100/month

For production workloads processing 10,000 records per month, expect costs in the range of $2,000–$3,000/month. The primary cost drivers are BDA (charged per page), HealthLake (charged per search request), and VPC endpoints (hourly PrivateLink charges in production deployments).

Cost optimization tips:

Delete the CloudFormation stack when not actively testing: aws cloudformation delete-stack --stack-name bda-medical-records-stack.
Set up AWS Budgets alerts to catch unexpected costs early.
Monitor Lambda duration in CloudWatch to optimize function execution time.

Clean up

To avoid ongoing charges, delete the CloudFormation stack when you’re done:

aws cloudformation delete-stack --stack-name bda-medical-records-stack
aws cloudformation wait stack-delete-complete --stack-name bda-medical-records-stack

For cleanup of manually created Amazon Bedrock Data Automation projects and S3 bucket contents, see the GitHub repository.

What’s next

After you deploy, you can extend this foundation to:

Integrate with existing electronic health records (EHR) systems through FHIR APIs.
Build analytics dashboards using Amazon Quick Sight.
Add natural language search with Amazon Kendra.
Add Amazon Simple Queue Service (Amazon SQS) as a buffer between Amazon S3 events and the BDA Trigger Lambda to handle burst uploads and manage BDA concurrency limits at scale.
Orchestrate with AWS Step Functions for error handling, retry logic, and routing low-confidence extractions to human review.
Implement real-time, high-volume processing with Amazon Kinesis Data Streams for continuous ingestion from multiple sources.

Conclusion

In this post, you saw how Amazon Bedrock Data Automation, AWS Lambda, Amazon S3, and AWS HealthLake work together to automate the transformation of scanned medical records into FHIR R4-compliant data. The event-driven architecture removes manual data entry, scales without custom machine learning models, and makes historical records accessible to modern care delivery systems.

Key takeaways:

Amazon Bedrock Data Automation extracts over 50 structured clinical fields from PDFs without template configuration.
AWS Lambda orchestrates the pipeline with two focused, event-driven functions.
Amazon S3 event notifications decouple each stage, so each can scale independently.
AWS HealthLake validates, indexes, and exposes FHIR R4 data through standard APIs.
Security controls are the customer’s responsibility under the AWS Shared Responsibility Model.

To explore the full source code, advanced configuration options, and customization guidance, visit the GitHub repository.

Additional resources

For more information, see the following additional resources:

This solution is intended for educational purposes using synthetic data. Review the security considerations and consult your compliance team before deploying in any environment with real patient data.

About the authors

Can You Use Project Nomad on a MacBook? ARM Support Status and Workarounds

2026-06-09 Crosstalk Solutions

Post Syndicated from Crosstalk Solutions original https://www.youtube.com/shorts/ymi6RKpR5cA