Post Syndicated from LastWeekTonight original https://www.youtube.com/watch?v=RJ2_ragq3zw
Choosing the right workflow orchestration service for your use case: Amazon MWAA and AWS Step Functions
Post Syndicated from Rajkumar Raghuwanshi original https://aws.amazon.com/blogs/big-data/choosing-the-right-workflow-orchestration-service-for-your-use-case-amazon-mwaa-and-aws-step-functions/
Whether you’re processing financial data, managing e-commerce orders, or training machine learning (ML) models, efficiently coordinating complex processes is essential. Amazon Web Services (AWS) offers two services for workflow orchestration: Amazon Managed Workflows for Apache Airflow (Amazon MWAA) and AWS Step Functions.
This post explores how to select the right workflow orchestration service based on your specific use case requirements. We’ll examine key workflow characteristics, present real-world scenarios, and provide practical guidance to help you make an informed decision for your particular needs.
Understanding workflow orchestration requirements
Before exploring specific services, consider the key dimensions that influence workflow orchestration needs:
- Data statefulness: Does your workflow process independent units of work (stateless) or create dependencies where each step modifies data from previous steps (stateful)?
- Execution duration: Are your workflows short-lived (seconds to minutes) or long-running (hours to days)?
- Scheduling requirements: Do you need built-in time-based execution or rely primarily on event triggers?
- Recovery capabilities: How critical is the ability to restart from specific failure points rather than reprocessing entirely?
- Integration complexity: What systems, services, and data sources need to be coordinated?
- Security and access control: Do you need fine-grained permissions for different workflow components?
Let’s explore how these requirements map to real-world use cases and the appropriate orchestration solutions.
Use case: Enterprise data analytics pipeline
This scenario illustrates how Amazon MWAA handles complex, stateful data pipelines with built-in scheduling and granular recovery.
Business challenge
A global financial services company processes massive volumes of transaction data daily, requiring sophisticated data analytics capabilities. Their requirements include:
- Designed to process 5-10 TB of financial transaction data daily
- Running complex extract, transform, and load (ETL) jobs with multiple transformation stages
- Generating regulatory reports for compliance use cases
- Supporting both scheduled batch processing and event-driven workflows
- Capable of handling long-running jobs that can take up to 12 hours
- Ensuring data consistency and integrity throughout the pipeline
Workflow characteristics
- Data statefulness: Highly stateful workflows where each processing step modifies transaction data, creating dependencies throughout the pipeline
- Execution duration: Supports long-running processes extending 2-12 hours
- Scheduling needs: Mixed time-based and event-driven patterns
- Recovery requirements: Critical ability to resume from specific failure points
- Integration complexity: Orchestrates multiple AWS services and external systems
Solution: Amazon Managed Workflows for Apache Airflow (Amazon MWAA)
For this enterprise data analytics scenario, Amazon MWAA provides capabilities that align well with these requirements:
Stateful workflow management
MWAA excels at managing complex, stateful data pipelines where data consistency is critical. When processing terabytes of financial data, MWAA’s ability to resume from the last successful checkpoint helps prevent costly reprocessing and maintain data integrity.
The following code example demonstrates how to structure a complex financial ETL pipeline in MWAA:
This Directed Acyclic Graph (DAG) shows how to define task dependencies for parallel data extraction followed by sequential transformation and loading operations. The >> operator clearly defines the workflow dependencies. Transformation only begins after both extraction tasks complete successfully.
Built-in scheduling capabilities
MWAA includes native scheduling capabilities, making it straightforward to set up recurring workflows without additional services. The schedule_interval parameter in the DAG definition provides flexible scheduling options using cron syntax.
Granular recovery and resume control
During production incidents, operations teams can use the MWAA web interface to restart or bypass specific steps with a few clicks. This capability is important for stateful applications where restarting the entire workflow could compromise data consistency.
The MWAA web interface provides a visual representation of the workflow execution, allowing operators to:
Identify failed tasks – Examine task logs for troubleshooting – Clear the status of specific tasks – Restart execution from specific points
Figure 1: A Directed Acyclic Graph (DAG) in MWAA showing parallel execution ofAmazon Redshift Data APItasks. If any task fails, you can re-run specific tasks rather than restarting from the beginning.
Comprehensive monitoring and operational control
MWAA’s metadata server maintains comprehensive execution logs, enabling organizations to build operational dashboards for: – Real-time workflow monitoring – Task completion rate tracking – Pipeline execution pattern analysis – Optimization opportunity identification
Implementation considerations
- Infrastructure planning: While MWAA requires capacity planning, the automatic scaling capabilities effectively handle variable workloads by setting minimum and maximum worker counts.
- Security model: MWAA uses a shared execution role across DAGs, but you can implement additional security through resource-level policies and separate environments for different teams.
- Cost predictability: The worker-hour pricing model provides predictable costs for long-running jobs, making budget planning more straightforward.
Use case: Real-time serverless application orchestration
This scenario shows how AWS Step Functions handles event-driven, serverless workflows that need to scale automatically with unpredictable traffic.
Business challenge
An e-commerce platform needs to orchestrate real-time order processing workflows that can handle thousands of concurrent orders during peak shopping periods. Their requirements include:
- Designed for processing customer orders in real-time (targeting sub-second response times)
- Coordinating payment validation, inventory checks, and fulfillment
- Integrating with multiple AWS services (AWS Lambda, Amazon Simple Queue Service (Amazon SQS), Amazon Simple Notification Service (Amazon SNS), Amazon DynamoDB)
- Designed to handle traffic spikes during promotional events
- Implementing approval workflows for high-value orders
- Maintaining cost efficiency during variable load periods
Workflow characteristics
- Data statefulness: Primarily stateless processing where each customer order represents an independent transaction
- Execution duration: Supports rapid, real-time processing with sub-second to few-minute response times.
- Event-driven nature: Core architectural pattern where workflows are triggered by specific customer actions
- Integration requirements: Extensive coordination with AWS serverless services
- Scalability needs: Highly unpredictable traffic patterns requiring automatic scaling
Solution: AWS Step Functions
For this real-time e-commerce scenario, AWS Step Functions provides capabilities that align well with these requirements:
Serverless architecture and automatic scaling
Step Functions automatically scales to handle traffic spikes without infrastructure management. During peak shopping events like Black Friday, the service handles increased load without manual intervention.
Event-driven workflow execution
Step Functions is designed for order-triggered workflows that need immediate execution. The following JSON definition shows how to structure an e-commerce order processing workflow:
This Step Functions definition demonstrates several key capabilities: – The ValidatePayment state includes built-in retry logic with exponential backoff – The CheckInventory state uses parallel execution to simultaneously check multiple warehouses – Each Lambda function is called via its Amazon Resource Name (ARN), providing direct integration with AWS services
Figure 2: A complex workflow in AWS Step Functions, involving multiple stages of data processing. The parallel execution doesn’t allow resuming from a specific mid-execution step, but the branching structure provides automated error handling and recovery.
Native AWS service integration
Step Functions provides direct integration with Lambda functions, SQS queues, SNS topics, and DynamoDB, eliminating the need for custom connectors or additional infrastructure components.
Cost-effective pay-per-use model
The pay-per-execution pricing model aligns with variable order volumes, keeping costs minimal during slow periods while scaling automatically during busy times.
Human approval workflow support
Step Functions supports human approval steps, making it suitable for high-value order workflows that require manual review or approval processes.
Implementation considerations
- Error handling: Built-in retry mechanisms and error handling patterns help provide reliable order processing with configurable retry policies.
- Visual monitoring: The Step Functions console provides real-time visibility into order processing status, enabling quick identification of bottlenecks.
- Security model: Fine-grained AWS Identity and Access Management (IAM) roles per step so that payment processing functions have different permissions than inventory management functions.
Choosing the right workflow orchestration service
When selecting between Amazon MWAA and AWS Step Functions, consider these workflow characteristics:
Consider Amazon MWAA when your use case involves:
- Complex stateful data processing where workflows modify data state and require recovery mechanisms to maintain consistency
- Long-running batch jobs executing for hours or days where computational investment is substantial
- Built-in scheduling requirements where regular batch processing needs time-based orchestration
- Granular recovery needs where resuming from specific failure points is business-critical
- Complex task dependencies involving sophisticated relationships between workflow tasks
- Existing Apache Airflow expertise where teams have substantial investment in Apache Airflow knowledge
Consider AWS Step Functions when your use case involves:
- Event-driven serverless workflows triggered by external events requiring immediate response
- Stateless processing where each workflow execution operates independently
- Short to medium duration tasks completing within minutes to hours
- Heavy AWS service integration involving extensive coordination with Lambda functions and other AWS services
- Human approval workflows requiring manual intervention or decision-making
- Variable load patterns with unpredictable traffic requiring automatic scaling
Decision framework
To help guide your decision process, consider the following questions:
Figure 3: Decision tree guiding through key considerations for choosing between Amazon MWAA and AWS Step Functions based on workflow characteristics.
Figure 4: Comprehensive comparison between Amazon MWAA and AWS Step Functions, highlighting decision factors for choosing the right workflow orchestration service.
Conclusion
Both Amazon Managed Workflows for Apache Airflow and AWS Step Functions are workflow orchestration services, each designed to address specific use case requirements. By understanding your workflow characteristics and aligning them with the strengths of each service, you can make an informed decision that supports your business needs.
For complex, stateful workflows with long execution times and sophisticated recovery requirements, Amazon MWAA provides robust capabilities. For event-driven, serverless workflows with tight AWS integration and variable load patterns, AWS Step Functions is a strong fit.
Remember that these services are not mutually exclusive. Many organizations use both to address different workflow orchestration needs across their application portfolio. By focusing on your specific use case requirements, you can select the right tool for each job and build resilient, efficient workflow orchestration solutions on AWS.
If you have questions or feedback about choosing between these services, leave a comment.
About the authors
Real-time CDC from Aurora PostgreSQL to Amazon S3 Tables using Debezium and Firehose
Post Syndicated from Chintan Agrawal original https://aws.amazon.com/blogs/big-data/real-time-cdc-from-aurora-postgresql-to-amazon-s3-tables-using-debezium-and-firehose/
Enterprises running transactional workloads on Amazon Aurora PostgreSQL-Compatible Edition (Aurora PostgreSQL) need their operational data available for analytics. However, analytical queries and cross-database joins compete for resources on OLTP-optimized clusters. Batch exports introduce latency, and when data spans multiple Aurora clusters, there’s no straightforward way to join datasets or run cross-domain analytics. Real-time change data capture (CDC) addresses this by streaming row-level changes into a separate analytics layer. However, most CDC approaches write append-only records that require downstream consumers to reconstruct current state from the change log.
In this post, we show you how to build a CDC pipeline that delivers query-ready Iceberg tables directly. The pipeline captures inserts, updates, and deletes from Aurora PostgreSQL and applies them as row-level operations in Amazon S3 Tables, a capability of Amazon Simple Storage Service (Amazon S3). The destination tables always reflect the current state of the source database. You use Debezium on Amazon MSK Connect for change capture and Amazon Managed Streaming for Apache Kafka (Amazon MSK) for streaming. You also use AWS Lambda to transform CDC events and resolve operation semantics, and Amazon Data Firehose to deliver records into Iceberg tables. You deploy the infrastructure using the AWS Cloud Development Kit (AWS CDK).
Apache Iceberg supports row-level updates, deletes, ACID transactions, schema evolution, and time travel natively. S3 Tables handles Iceberg snapshot management and compaction automatically. With AWS Lake Formation for access control, multiple teams can query the tables through Amazon Athena, Amazon Redshift, or Amazon SageMaker Unified Studio.
Solution overview
The following diagram shows the architecture of the CDC pipeline.
Figure 1. CDC pipeline architecture from Aurora PostgreSQL to Amazon S3 Tables.
The pipeline uses six components:
- Aurora PostgreSQL to Debezium. Debezium runs on MSK Connect in your VPC and uses PostgreSQL’s native logical replication to stream row-level changes from the write-ahead log (WAL), with minimal impact on query performance.
- Debezium to Amazon MSK. The
ByLogicalTableRouterSMT reroutes CDC events from multiple tables into a single topic (aurora.cdc.all-tables), retaining the source table name in each message. - Amazon MSK to Firehose. Firehose connects to the MSK cluster using the IAM access control over AWS PrivateLink and continuously polls the topic for new messages.
- Firehose to Lambda. For each batch, Firehose invokes the Lambda function to decode the Kafka message, flatten the Debezium envelope, and set otfMetadata routing with the destination table and operation type.
- Firehose to S3 Tables. Firehose reads the
otfMetadata, routes each record to the correct Iceberg table, and performs the appropriate row-level operation using configured unique keys (for example,order_idfor orders). S3 Tables handles compaction and snapshot management automatically. - Query and access control. After data lands in S3 Tables, you can query the Iceberg tables with Amazon Athena, Amazon Redshift, or Amazon SageMaker Unified Studio, with AWS Lake Formation managing fine-grained access control.
Firehose supports one MSK topic per delivery stream. The single-topic routing pattern uses a Debezium SMT to consolidate multiple tables into one topic, and a Lambda function to route records to the correct destination. With this, you can serve multiple tables through one Firehose stream, reducing cost and operational complexity.
Debezium event transformation
Debezium produces CDC events in an envelope structure containing both the previous and current state of a row, along with metadata about the source database, table, and operation type. However, Firehose expects records in a flattened JSON format with routing metadata that indicates the target table and operation type.
The Lambda function bridges this gap by performing three operations on each record:
- Decode. When Firehose uses Amazon MSK as a source, it delivers the Kafka message value as a base64-encoded string in the
kafkaRecordValuefield. The function base64-decodes this field to obtain the raw Debezium JSON payload. - Flatten and extract. Pulls the row data from the Debezium envelope. For inserts and updates, the function uses the
afterfield (the row after the change). For deletes, it uses thebeforefield, because theafterfield is null when a row is removed. - Route. Sets the otfMetadata block with
destinationTableName(extracted from the Debeziumsource.tablefield) andoperation(mapped from Debezium’s single-character codes to Firehose’s operation types).
The following table shows how Debezium operation codes map to Firehose Iceberg operations:
| Debezium code | Meaning | Firehose operation |
| c | Row created (insert) | insert |
| u | Row updated | update |
| d | Row deleted | delete |
| r | Snapshot read (initial load) | insert |
When Debezium starts with snapshot.mode=initial, it reads all existing rows and emits them as r (read) events. These represent rows that existed before CDC began, so they are mapped to insert to establish the baseline state in the destination tables.
For example, the function transforms this Debezium envelope:
Into a response record with routing metadata:
The kafkaRecordValue contains the base64-encoded flattened row data (for example, {"order_id": 1, "customer_id": 1, "total_amount": 299.99}), and the otfMetadata block tells Firehose which table to write to and which operation to perform.
With this routing metadata, a single Firehose stream can write to multiple destination tables. For more information, see Route incoming records to different Iceberg tables.
Walkthrough
The following sections walk you through building the CDC pipeline end to end. Before you begin, complete the prerequisites.
Prerequisites
Before you begin, make sure you have the following:
- An AWS account with permissions to create the resources described in this post.
- An existing Amazon Virtual Private Cloud (Amazon VPC) with at least two subnets in different Availability Zones.
- An Aurora PostgreSQL cluster in the same VPC with logical replication enabled (
rds.logical_replication = 1). - Aurora database credentials stored in AWS Secrets Manager. Note the secret ARN for the CDK configuration.
- AWS CDK v2 installed (
npm install -g aws-cdk). - Node.js 18+ and npm.
- AWS Command Line Interface (AWS CLI) v2 installed and configured with appropriate credentials.
- An Amazon S3 general purpose bucket for the Debezium plugin upload and Firehose failed record backup.
- S3 Tables integration with AWS analytics services enabled in your AWS Region (one-time setup).
Step 1: Enable CDC in Aurora PostgreSQL
PostgreSQL supports change data capture through its logical replication framework, which allows database changes to be streamed from the write-ahead log (WAL). Debezium uses this mechanism to continuously read row-level changes and publish them to Kafka topics.
To enable logical replication in Aurora PostgreSQL, configure a custom DB cluster parameter group:
- Create a custom parameter group and set the following parameter:
rds.logical_replication = 1. - Apply the parameter group to your Aurora cluster and reboot the cluster for the change to take effect.
- Connect to your Aurora PostgreSQL cluster and create the source tables:
- Create a publication that defines which tables are included in the change stream. Debezium automatically creates the logical replication slot when the connector starts for the first time, so you don’t need to create one manually.
- Verify the publication was created:
You should see one row returned, confirming the publication is active.
Important: When the Debezium connector starts (Step 6), it creates a replication slot named debezium_slot. This slot retains WAL segments until consumed. If the connector is stopped for an extended period, WAL segments can accumulate and increase storage usage on the Aurora cluster. Monitor the ReplicationSlotDiskUsage Amazon CloudWatch metric for your Aurora cluster.
Step 2: Build and register the Debezium plugin
MSK Connect runs connectors using custom plugins that you upload to Amazon S3. In this step, you download the Debezium PostgreSQL connector, package it as a ZIP file, upload it to S3, and register it with MSK Connect.
First, create an S3 bucket for the plugin, or use an existing metadata management bucket:
Download and package the Debezium connector:
Register the plugin with MSK Connect:
Create a worker configuration that tells MSK Connect to serialize Kafka messages as JSON without schemas:
Note the customPluginArn and workerConfigurationArn from the output. You need these for the CDK configuration in the next step.
Note: The custom plugin and worker configuration are created through the AWS CLI because the Debezium connector JARs must be downloaded from the Debezium project and packaged manually. The remaining infrastructure is deployed using the AWS CDK in the following steps.
Step 3: Configure the CDK project
Clone the sample repository and install dependencies:
Open cdk/lib/v2/config.ts and update the configuration values to match your environment:
Key configuration notes:
- auroraSecurityGroupId. The security group attached to your Aurora cluster. The CDK creates an MSK security group with ingress rules allowing traffic from this security group, and a reverse rule allowing MSK Connect workers to reach Aurora on port 5432.
- tableKeys. The primary key column for each table. Firehose uses these to match incoming records against existing rows for update and delete operations in the Iceberg tables.
- s3TablesBucketName. The name for your S3 table bucket. Table bucket names must be unique for your account in the chosen Region.
Step 4: Deploy the CDK stacks
Deploy all six stacks with a single command. The CDK resolves the dependency order automatically:
When prompted, review the AWS Identity and Access Management (IAM) changes and confirm the deployment. The CDK deploys the following stacks:
| Stack | What it creates |
CdcMskCluster |
Amazon MSK cluster (2x kafka.m5.large brokers) with dual authentication (IAM for Firehose, unauthenticated for Debezium), custom configuration with auto.create.topics.enable=true, security groups with ingress rules for Aurora and MSK Connect workers |
CdcMskConnectIam |
MSK Connect service execution role with permissions for Kafka cluster operations, VPC networking, S3 plugin access, and AWS Secrets Manager; Amazon CloudWatch Logs group for connector logs |
CdcS3Tables |
S3 table bucket, aurora_cdc namespace, two Iceberg tables (orders, products) with column schemas |
CdcLambdaTransform |
Lambda function for CDC event transformation and multi-table routing |
CdcFirehoseRole |
Firehose IAM role with permissions for Amazon MSK, S3 Tables, AWS Glue Data Catalog, AWS Lake Formation, VPC networking, and Lambda invocation |
CdcFirehose |
Firehose delivery stream with MSK as source (private connectivity through AWS PrivateLink), Lambda processing, Apache Iceberg Tables as destination with two table configurations, and S3 backup bucket for failed records |
The MSK cluster takes approximately 25 minutes to create. The Debezium connector takes approximately 5 minutes after the cluster is ready. You can monitor the deployment progress in the AWS CloudFormation console.
After the deployment completes, you can verify the resources in the AWS console. The S3 table bucket shows the two Iceberg tables in the aurora_cdc namespace.
Figure 2. S3 table bucket showing the orders and products Iceberg tables in the aurora_cdc namespace.
The Firehose delivery stream shows the MSK source, Lambda transformation, and Apache Iceberg Tables destination.
Figure 3. Amazon Data Firehose delivery stream with MSK source, Lambda transformation, and Apache Iceberg Tables destination.
The MSK cluster uses dual authentication (IAM for Firehose, unauthenticated for Debezium through TLS_PLAINTEXT), multi-VPC private connectivity for Firehose PrivateLink access, and auto.create.topics.enable=true so Debezium can create topics on first connect. VPC connectivity and the cluster resource policy are configured as CLI steps in Step 5.
Step 5: Enable MSK VPC connectivity, grant Lake Formation permissions, and apply MSK cluster policy
After the CDK deployment completes, enable multi-VPC private connectivity with IAM on the MSK cluster. Firehose requires this to create an AWS PrivateLink endpoint to the MSK brokers. This setting can’t be configured during cluster creation and must be applied as an update, which triggers a rolling broker restart (approximately 20–30 minutes).
Wait for the cluster state to return to ACTIVE before proceeding:
Next, grant the Firehose IAM role permissions through AWS Lake Formation. S3 Tables uses a sub-catalog format for the CatalogId parameter, which differs from the standard AWS Glue Data Catalog. These permissions require a data lake administrator identity.
Grant database-level and table-level permissions to the Firehose role:
Note the CatalogId format: <account-id>:s3tablescatalog/<table-bucket-name>. This is specific to S3 Tables and tells Lake Formation to look up permissions in the S3 Tables catalog rather than the default Glue Data Catalog. For more information, see Integrating Amazon S3 Tables with AWS analytics services.
Next, attach a resource-based policy to the MSK cluster that grants the Firehose service principal permission to create VPC connections:
You can find the <msk-cluster-arn> in the CdcMskCluster stack outputs from Step 4, and the <firehose-role-arn> in the CdcFirehoseRole stack outputs.
Step 6: Create the Debezium connector
With the MSK cluster running and Lake Formation permissions in place, create the Debezium connector using the MSK Connect API. The connector reads changes from Aurora PostgreSQL and publishes them to the MSK topic.
Firehose supports only one MSK topic per delivery stream, so each source table would otherwise need its own Firehose stream and VPC connection. To avoid this, the connector uses the Debezium ByLogicalTableRouter Single Message Transform (SMT) to route changes from multiple tables into a single topic (aurora.cdc.all-tables). The Lambda function then uses the source table name in each message to direct records to the correct Iceberg table. This single-topic pattern uses one Firehose stream for multiple tables, reducing cost and operational complexity.
First, retrieve the MSK bootstrap servers from the cluster:
Note the BootstrapBrokerString value (the PLAINTEXT brokers). Then create the connector:
The <msk-security-group-id> and <msk-connect-service-role-arn> can be found in the CdcMskCluster and CdcMskConnectIam stack outputs respectively. The ByLogicalTableRouter Single Message Transform routes CDC events from the monitored tables into a single topic (aurora.cdc.all-tables).
Step 7: Verify the Debezium connector
After creating the connector, verify that it is running and has completed its initial snapshot.
The connector state should show RUNNING, as shown in the following figure.
Figure 4. Debezium connector running on Amazon MSK Connect.
Check the CloudWatch Logs to confirm the snapshot completed:
You should see messages indicating the transition to streaming mode:
Finished exporting 0 records for table 'public.orders' (1 of 2 tables)
Finished exporting 0 records for table 'public.products' (2 of 2 tables)
Snapshot completed
Starting streamingIf the tables were empty when the connector started, the export count is 0. If you had existing data, the snapshot captures the existing rows as r (read) operations, which the Lambda function maps to insert operations in the Iceberg tables.
Verify that the Firehose delivery stream is active:
The status should return ACTIVE.
Step 8: Test the pipeline
Insert test data into the Aurora PostgreSQL source tables. Each insert triggers a CDC event that flows through the pipeline: Aurora WAL to Debezium to MSK topic to Firehose to Lambda transform to S3 Tables.
This creates six records across two tables. Each record generates a Debezium CDC event with operation type c (create), which the Lambda function maps to an insert operation in the corresponding Iceberg table.
Step 9: Verify data delivery
Check the Firehose IncomingRecords metric to confirm records are flowing through the delivery stream:
You should see a Sum value of 6 or more. If the value is 0, wait another minute and retry. There can be a short delay between MSK topic delivery and Firehose metric reporting.
If records aren’t appearing, check the Firehose error output in the backup S3 bucket and the Lambda function’s CloudWatch Logs for transformation errors.
Step 10: Query data using Amazon Athena
With data delivered to S3 Tables, you can query the Iceberg tables using Amazon Athena. S3 Tables integrates with the AWS Glue Data Catalog as a sub-catalog, so you reference tables using the S3 Tables catalog format.
Tip: If records aren’t appearing in Athena, check the Firehose IncomingRecords CloudWatch metric and the Lambda function’s CloudWatch Logs for transformation errors.
Open the Athena console, select the AwsDataCatalog data source, and run the following queries:
Replace <table-bucket-name> with your S3 table bucket name. You should see the records from the initial snapshot that Debezium captured when the connector started.
The following figures show the initial state of both tables as queried through Athena. At this point, the products table contains seven records and the orders table contains seven records, captured during the Debezium initial snapshot.
Figure 5. Initial state of the products table in Amazon Athena, showing seven records captured from Aurora PostgreSQL through the CDC pipeline.
Figure 6. Initial state of the orders table in Amazon Athena, showing seven records captured from Aurora PostgreSQL through the CDC pipeline.
Now test that update and delete operations propagate correctly. Run the following statements in Aurora:
Wait for the changes to propagate through the pipeline, then query Athena again. The following figures show the results after the insert, update, and delete operations have been applied.
In the products table, the Test Widget record (product_id 100) is no longer present because it was removed by the delete operation. The Ergonomic Chair row now reflects the updated price (549.99) and stock quantity (30). Two new records, Bluetooth Speaker and Standing Desk, appear with a later created_at timestamp, confirming they were inserted after the initial snapshot.
Figure 7. Products table after CDC operations. The Ergonomic Chair, Headphones, and Desk Lamp rows reflect updated values. Bluetooth Speaker and Standing Desk are newly inserted records. The Test Widget record has been removed by the delete operation.
In the orders table, order 100 now shows a status of SHIPPED and order 201 shows DELIVERED, reflecting the update operations. Three new orders (301, 302, 303) appear with status NEW and a later timestamp, confirming they were inserted after the initial load.
Figure 8. Orders table after CDC operations. Orders 100 and 201 reflect updated status values. Orders 301, 302, and 303 are newly inserted records.
This confirms that the pipeline correctly handles the three CDC operation types: inserts, updates, and deletes are captured from the Aurora WAL by Debezium, routed through the single MSK topic, transformed by the Lambda function, and applied as row-level Iceberg operations by Firehose.
S3 Tables handles compaction and snapshot management for Iceberg tables automatically, including compaction of small data files and expiration of old snapshots. You don’t need to run manual maintenance operations.
You can also use Iceberg’s time travel capability to query the table as it existed before the updates:
This returns the original data before the update, demonstrating the time travel capability that Apache Iceberg provides through S3 Tables.
Cleaning up
To avoid ongoing charges, delete the resources in reverse dependency order.
Delete the CDK stacks:
Delete the Debezium custom plugin and worker configuration that were created through the AWS CLI in Step 2:
Clean up the Aurora PostgreSQL replication resources:
Important: The replication slot (debezium_slot) was created automatically by Debezium. If you plan to redeploy the pipeline later, you don’t need to drop the slot and publication. However, the replication slot continues to retain WAL segments while the connector isn’t running, which can increase storage usage on the Aurora cluster. The MSK cluster is the largest cost component of this solution and can’t be paused. It can only be deleted and recreated.
Conclusion
In this post, we showed you how to build a near real-time CDC pipeline from Aurora PostgreSQL to Apache Iceberg tables in Amazon S3 Tables. The key architectural decisions include:
- Single-topic routing with multi-table delivery. The Debezium
ByLogicalTableRouterSMT routes CDC events from multiple tables through one MSK topic, and the LambdaotfMetadatarouting directs each record to the correct Iceberg table. This reduces VPC connection costs by using a single Firehose stream for inserts, updates, and deletes across multiple destination tables. - Fully managed CDC pipeline. MSK Connect runs Debezium, Firehose handles delivery with automatic retries, and S3 Tables manages Iceberg compaction and snapshots. The Lambda transform preserves CDC semantics by mapping Debezium operations to Iceberg row-level operations.
- Governed lakehouse access. Lake Formation controls fine-grained access to the Iceberg tables, and data from multiple isolated Aurora clusters can be unified in a single S3 Tables namespace for cross-domain analytics.
- Infrastructure as code. Six AWS CDK stacks deploy the core pipeline, with Lake Formation permissions, MSK cluster policy, and Debezium connector configured through documented CLI steps.
To get started, clone the sample repository and follow the walkthrough steps. For more information about the services used in this solution, see the Amazon MSK Developer Guide, Amazon Data Firehose Developer Guide, and Amazon S3 Tables User Guide.
We encourage you to try this solution and adapt it to your own CDC workloads. If you have questions or feedback, leave a comment on this post.
Related posts
- Build a data lake for streaming data with Amazon S3 Tables and Amazon Data Firehose
- Stream CDC into an Amazon S3 data lake in Apache Iceberg format with AWS Glue Streaming and Amazon MSK Connect
- Introducing Amazon MSK Connect – Stream Data to and from Your Apache Kafka Clusters Using Managed Connectors
About the author
Introducing the Snowflake and AWS Custom Lens for the AWS Well-Architected Framework
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.
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.
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)
To get started:
-
- 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.
- Launch Cortex Code CLI by entering
cortexat the shell prompt. - In the Cortex Code CLI chat window, enter
invoke the joint-waf-aws-lens skillto 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.
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 skilland 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.
- AWS Well-Architected Tool
- AWS Well-Architected Framework
- Kiro Documentation
- Snowflake Cortex Code
- Snowflake WAF
- Tri-Secret Secure in Snowflake
- Snowflake Snowpipe
- Snowflake zero-copy cloning
- Snowflake Workload Identity Federation
- Snowflake sensitive data classification
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
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.
Zendure SolarFlow 800 Pro: Was It Worth It?
Post Syndicated from BeardedTinker original https://www.youtube.com/watch?v=CFAhlM_lnS4
Republicans vs. the Fourteenth Amendment | The David Frum Show
Post Syndicated from The Atlantic original https://www.youtube.com/watch?v=FjOo4aL5QDQ
[$] AI agent runs amok in Fedora and elsewhere
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
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
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
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.
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.
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.
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.
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.
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.
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
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
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
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 |
|---|---|---|
|
OS Command Injection (CWE-78) |
||
|
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.
Завръщането на американско-китайската дружба
Post Syndicated from Искрен Иванов original https://www.toest.bg/zavrushtaneto-na-amerikansko-kitayskata-druzhba/
Геополитическите нагласи на Великите сили, независимо от стратегическата им култура, винаги са били насочени към търсене на най-рационалния път за защита на националния им интерес. Ако това важи с пълна сила за САЩ, то е също толкова валидно за Китай. Разликата между Вашингтон и Пекин е, че американците представят интереса си като свой и на съюзниците си, а китайците имат навика да го представят като всеобщ.
Отношенията между двете държави никога не са били еднозначни, а Студената война е може би най-ценният урок какво може да се очаква, когато триъгълната дипломация работи в полза на нечия „дружба“, без тази дружба да представлява съюз. Дали ще станем свидетели на възстановяването на подобно приятелство между двете Велики сили и какви са основните предпоставки това да (не) се случи? Отговорът на този въпрос може да се окаже път към разплитането на сложната геополитическа ситуация, в която се намира светът, докато във Вашингтон управлява втората администрация на Тръмп, а в Китай вече говорят за политическо безсмъртие.
Стратегическите култури на САЩ и Китай
При опитите за сравнение между Америка и Китай може да паднем в капана на простия факт, че историческият подход изобщо не следва да бъде водещ в анализа на отношенията между Вашингтон и Пекин. Китай е страна с хилядолетна история, докато американското политическо житие е богато, но все още младо.
Тези отношения могат да бъдат обективно оценени чрез внимателен анализ на отделните понятийни категории, които двете държави използват, за да подсигурят изпълнението на приоритетите си. А това неизбежно ни отвежда до факта, че много експерти по Китай не владеят мандарин и обикновено използват английски преводи, които са също толкова подвеждащи, колкото и разсъжденията на авторите им. Може би единственото изключение от това правило е Хенри Кисинджър, който е толкова свързан с китайската история и култура, че е може би единственият американец, който в най-пълна степен може да се нарече истински познавач на Китай.
Американската стратегическа култура винаги е била насочена към една цел: САЩ да доминират системата на международните отношения във всичките ѝ състояния. Тази идея се корени дълбоко в американския Manifest destiny, от една страна, и в идеите на бащите основатели, от друга, които виждат в разума, а не в монарха архитекта на политическото развитие на младата държава.
От момента, в който САЩ излизат на световната карта с Испано-американската война от 1898 г., те успяват последователно да овладеят ключови сектори от глобалната политика, така че светът става „американски“. Такава е системата от началото на XX век, когато европейските колониални империи все още доминират системата във военно и културно отношение. Макар и европоцентрична, тази система на практика е икономически протекторат на САЩ, които стават основен европейски кредитор, същевременно измествайки британския флот от господстващата му роля в моретата и океаните и създавайки „меката сила“ за „империята на свободата“.
Геополитическото противопоставяне със СССР също е американоцентрично по две причини. Първо, оказва се, че съветските ядрени оръжия на практика не могат да защитят Москва, тъй като това би означавало ядрен апокалипсис – факт, който поколения съветски лидери прагматично отчитат. Второ, макар и военно двуполюсен, светът на Студената война е икономически еднополюсен, тъй като доларът бързо става основна резервна валута. Еднополюсният период на 90-те години и първото десетилетие след 11 септември 2001 г. бяха пикът на американската хегемония, след което за пръв път тя беше поставена на карта от Китай.
И за пръв път Америка нямаше отговор на въпроса какво да прави.
За разлика от стратегическата култура на САЩ, китайската е комплексна и не може да бъде изчерпана с единна цел. И все пак, ако трябва да резюмираме с една дума културното наследство на Конфуций, Лаодзъ, Менций и поколенията от философи, творили в древния период на Китай, ще видим, че това е понятието хармония.
Китайската идея за лидерство днес почива върху три основни стълба. Първият е установяването на многополюсен световен ред, който – подобно на огромна пирамида на привилегиите – функционира на базата на трибутарната дипломация. Дипломация, в която няма съюзници и врагове, а само „приятели“. Някои от тези приятелства са далечни, други – близки, а трети – „без граници“.
Предопределени за война. Но не съвсем
Продължаваме поредицата на Искрен Иванов за Китай и за отношенията на далекоизточната страна с останалите Велики сили. Този текст разглежда накратко връзките между Китай и САЩ, както и въпроса кой ще е победител в една нова Студена война.
Искрен Иванов
Тук идва и вторият стълб, който включва утвърждаването на Китай като глобален икономически център, координиращ приятелите си в рамките на йерархична структура, но тя не е колективна система за сигурност или военен съюз, а система от взаимноизгодни икономически отношения.
И накрая, не бива да забравяме ролята на социализма с китайски характеристики, който обрисува ролята на лидера (председателя) като политически стълб на китайския суверенитет, а националното единство – като необходимо условие за връщането от века на унижението към славните времена, когато Китай е бил Велика сила. Такава е и стратегическата цел на китайските управляващи от Дън Сяопин насам.
Американско-китайската дружба преди и след разпада на СССР
В геополитически план американската победа в Студената война би била далеч по-трудна, ако не беше съветско-китайската схизма и не беше постигнато стратегическо сближаване с Пекин. Първото ниво, на което следва да търсим причините за тези процеси, е създаването на Новия Китай (Китайската народна република) и формирането на идеологията му. За разлика от съветската интерпретация на марксистката икономическа теория, която просто механично добавя към идеите на Маркс труда на Ленин „Какво да се прави?“, като по този начин създава политическото учение марксизъм-ленинизъм, китайските лидери представят един далеч по-изтънчен идеологически синтез.
В маоизма този синтез създава визия за съвременния свят и за мястото на Китай в него – теорията за „трите свята“ на Мао ясно позиционира сътрудничеството между Пекин и Глобалния юг като основен инструмент в стратегическата надпревара с империалистическите държави от Първия свят (САЩ и СССР) и държавите от Втория свят в лицето на европейците и Япония.
В дънизма идеите на Маркс придобиват динамични философски измерения, които целеполагат сближаването на Китай с изконния враг – Япония, и с неговия най-близък съюзник – САЩ, като път към отварянето и към възхода на китайската икономика на глобалната сцена. Паралелно с това китайските лидери очертават политиката си за мирно съжителство с останалите държави, опитвайки се да позиционират Китай като медиатор, а не като потенциален хегемон в международната система.
Мисълта на Си Дзинпин представлява истинска революция в идеите на китайските лидери, сравнима по значимост единствено с тази на Мао Дзъдун. Сегашният лидер на Китай окончателно изчиства социализма с китайски характеристики от статичните тълкувания на марксизма, формално обвързани със старото съветско мислене, и лансира динамична система от идеи, които целят както гарантирането на китайската политическа стабилност, така и националното обединение – нещо, което нито един от предишните китайски лидери не успява да постигне.
Приятелство без граници. Как Китай очарова Русия?
Какво предопределя „приятелството“ на Русия и Китай? Вечна ли е тази дружба, или има какво да смрачи на пръв поглед безоблачното небе над отношенията между двете страни? От Искрен Иванов.
Искрен Иванов
Най-значими за Китай обаче са постиженията на Си Дзинпин на геополитическата сцена, които намират отражение в доктрината му за мирния възход на Пекин в противовес с мирното съжителство, което неговите предшественици разбират като политика на консенсуализъм с останалите Велики сили и по-конкретно със САЩ. Тук е мястото да кажем, че за разлика от останалите китайски лидери, Си има завидното качество да облича идеите си в дрехите на класическата китайска философия, което им придава още по-голяма легитимност пред останалите азиатски държави.
Така стигаме и до логичния отговор на въпроса, който си поставихме: не, старата китайска дружба със САЩ няма как да бъде възродена, или поне не във вида, в който тя съществуваше по времето на Студената война. Китай уверено се е устремил към възход, а дали той ще бъде мирен, или не, ще покаже времето, защото тези процеси зависят не от намерението на лидерите, а от обективния баланс на силите в международния пъзел.
Америка, от друга страна, няма намерение да се разделя с философията си, тъй като дори Доналд Тръмп вижда американското глобално лидерство като приоритет, макар и по един особено превратен начин – като хегемония. В същото време не бива да правим генерализации, че капанът на Тукидид не е единственият сценарий, който може да се реализира, ако в даден момент отношенията между САЩ и Китай отново се влошат.
От капана на Тукидид към конфуцианската хармония
Всъщност има един сигурен факт – на сегашния етап САЩ разбират, че не могат без Китай, и Китай разбира, че не може без САЩ. В този смисъл двете държави действително поддържат дружбата си дотолкова, доколкото тя е взаимноизгодна. Това състояние няма да позволи на капана на Тукидид да се затвори, тъй като Америка няма намерение да разполага войски в Тайван, а Китай все още не е дал зелена светлина на Северна Корея да изнудва Вашингтон с новите си ракети.
Към това се прибавя невъзможността на двете държави да водят война една срещу друга – Китай все още няма паритет със САЩ, а Америка сериозно се изтощи в резултат на операцията „Епична ярост“. За добро или за лошо, принципът на хармонията, който в продължение на хилядолетия управляваше Азия, започва да се очертава като все по-привлекателен за останалата част от света, която се чуди кой ще е следващият регион, където предстои локален конфликт.
Войната, която никой не иска, но всички вече водят
За американската дилема между Израел и глобалната икономика, за иранската ядрена амбиция и за новото разделение между Европа и САЩ. Какво ни показва блокадата на Ормузкия проток? От Искрен Иванов.
Искрен Иванов
Същевременно Вашингтон и Пекин вече се намират в състояние на нова Студена война поради непримиримостта на Русия във войната с Украйна и опитите на Иран да се сдобие с оръжия за масово унищожение. Америка не може да си позволи да изостави Израел – сигнал, който дава не само администрацията на Тръмп, но и няколко последователни президентски администрации преди него.
Китай от своя страна би бил изключително уязвим без партньор като Москва или без присъствие в Близкия изток, чрез което да проектира влияние на глобалните икономически пазари. В този смисъл стратегическото противопоставяне между САЩ и Китай е неизбежно, но конфликтът между тях не е необходимост. Добрата новина е, че на този етап и двамата лидери разбират това и се стараят надпреварата между държавите им да остане в икономическата сфера.
Тук, разбира се, е добре да посочим болезнената за двете сили реалност –
САЩ следва да отчетат, че светът няма как да продължи да бъде еднополюсен, тъй като Китай вече проектира сила сред онези режими, които не се самоопределят като либерални демокрации.
Да, китайската формула може да звучи утопично и нереално за западните политици, но за Афганистан, Бруней, Мозамбик и ЮАР тя е алтернатива. Китай, от друга страна, трябва да се примири, че многополюсният свят също е непостижим, тъй като, ако Русия успее да възвърне влиянието си от съветската ера, приятелството без граници между Москва и Пекин бързо ще се срути. Същото е валидно и за стремежа на Пекин да се превърне в глобален икономически център – макар и възможно на теория, на практика няма как трибутарната имперска дипломация да успее през XXI век.
.jpg?ref=toest.bg){kind=link}
В тези условия формирането на двуполюсен модел между Вашингтон и Пекин остава най-големият гарант за глобалния мир и стабилност. Китайската позиция по отношение на иранската ядрена програма е най-сериозното доказателство в тази посока, тъй като това ще даде възможност на Америка да довърши започнатото, а на Китай – най-сетне да реализира обединението с Тайван. В тези условия светът най-сетне ще получи възможност да се разправи с истинските заплахи, които много анализатори наричат нови, макар те да не са толкова нови: тероризмът, екстремизмът, поляризацията, фундаментализмът.
Възстановяването на новата дружба между САЩ и Китай, с други думи, реализира конфуцианската хармония, а не капана на Тукидид. Тя е възможност балансът на силите в международната система да се върне отново към времето, когато политиците преговаряха с политици, а не с терористи. Вашингтон и Пекин имат потенциала да извършат този преход.
Първата стъпка към този процес е окончателното прекратяване на иранската ядрена програма и позиционирането на Тайван отново в китайската орбита. Ако планът на САЩ и Китай сработи, това означава, че е налице нов формат на сътрудничество между тях, който може успешно да разреши и останалата част от наболелите точки в глобалния дневен ред.
Алтернативата на тези механизми остава капанът на Тукидид, или по-ясно казано, война между Вашингтон и Пекин. Последиците ще са осезаеми най-вече в две посоки: рухване на глобалната икономика и възможност за ядрена ескалация между двете държави. Бъдеще, което едва ли Доналд Тръмп и Си Дзинпин биха пожелали.
Заглавно изображение: Американският президент Доналд Тръмп и членове на делегацията му разговарят с генералния секретар на Китайската комунистическа партия и президент на Китай Си Дзинпин през юни 2019 г. в Осака на среща на Г20
Beam Pipe
Post Syndicated from xkcd.com original https://xkcd.com/3257/
Patch Tuesday – June 2026
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
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
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
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 anthropicHere 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.