Post Syndicated from The Atlantic original https://www.youtube.com/shorts/wEQcxRWbvAM
Japan’s First Naval Defeat of WWII
Post Syndicated from The History Guy: History Deserves to Be Remembered original https://www.youtube.com/shorts/w3SSx44tqmk
Apples
Post Syndicated from xkcd.com original https://xkcd.com/3180/

Exploring the new AWS European Sovereign Cloud: Sovereign Reference Framework
Post Syndicated from Andreas Terwellen original https://aws.amazon.com/blogs/security/exploring-the-new-aws-european-sovereign-cloud-sovereign-reference-framework/
At Amazon Web Services, we’re committed to deeply understanding the evolving needs of both our customers and regulators, and rapidly adapting and innovating to meet them. The upcoming AWS European Sovereign Cloud will be a new independent cloud for Europe, designed to give public sector organizations and customers in highly regulated industries further choice to meet their unique sovereignty requirements. The AWS European Sovereign Cloud expands on the same strong foundation of security, privacy, and compliance controls that apply to other AWS Regions around the globe with additional governance, technical, and operational measures to address stringent European customer and regulatory expectations. Sovereignty is the defining feature of the AWS European Sovereign Cloud and we’re using an independently validated framework to meet our customers’ requirements for sovereignty, while delivering the scalability and functionality you expect from the AWS Cloud.
Today, we’re pleased to share further details about the AWS European Sovereign Cloud: Sovereign Reference Framework (ESC-SRF). This reference framework aligns sovereignty criteria across multiple domains such as governance independence, operational control, data residency and technical isolation. Working backwards from our customers’ sovereign use cases, we aligned controls to each of the criteria and the AWS European Sovereign Cloud is undergoing an independent third-party audit to verify the design and operations of these controls conform to AWS sovereignty commitments. Customers and partners can also leverage the ESC-SRF as a foundation upon which they can build their own complementary sovereignty criteria and controls when using the AWS European Sovereign Cloud.
To clearly explain how the AWS European Sovereign Cloud meets sovereignty expectations, we’re publishing the ESC-SRF in AWS Artifact including the criteria and control mapping. In AWS Artifact, our self-service audit artifact retrieval portal, you have on-demand access to AWS security and compliance documents and AWS agreements. You can now use the ESC-SRF to define best practices for your own use case, map these to controls, and illustrate how you meet and even exceed sovereign needs of your customers.
A transparent and validated sovereignty model
The ESC-SRF has been built from customer feedback, regulatory requirements across the European Union (EU), industry frameworks, AWS contractual commitments, and partner input. ESC-SRF is industry and sector agnostic, as it’s written to address fundamental sovereignty needs and expectations at the foundational layer of our cloud offerings with additional sovereignty-specific requirements and controls that apply exclusively to the AWS European Sovereign Cloud. Each criterion is implemented through sovereign controls that will be independently validated by a third-party auditor.
The framework builds on core AWS security capabilities, including encryption, key management, access governance, AWS Nitro System-based isolation, and internationally recognized compliance certifications. The framework adds sovereign-specific governance, technical, and operational measures such as independent EU corporate structures, dedicated EU trust and certificate services, operations by AWS EU-resident personnel, strict residency for customer data and customer created metadata, separation from all other AWS Regions, and incident response operated within the EU.
These controls are the basis of a dedicated AWS European Sovereign Cloud System and Organization Controls (SOC) 2 attestation. The ESC-SRF establishes a solid foundation for sovereignty of the cloud, so that customers can focus on defining sovereignty measures in the cloud that are tailored to their goals, regulatory needs, and risk posture.
How you can use the ESC-SRF
The ESC-SRF describes how AWS implements and validates sovereignty controls in the AWS European Sovereign Cloud. AWS treats each criterion as binding and its implementation will be validated by an independent third-party auditor in 2026. While most customers don’t operate at the size and scale of AWS, you can use the ESC-SRF as both an assurance model and a reference framework you can adapt to your specific use cases.
From an assurance perspective, it provides end-to-end visibility for each sovereignty criterion through to its technical implementation. We will also provide third-party validation in the AWS European Sovereign Cloud SOC 2 report. Customers can use this report with internal auditors, external assessors, supervisory authorities, and regulators. This can reduce the need for ad-hoc evidence requests and supports customers by providing them with evidence to demonstrate clear and enforceable sovereignty assurances.
From a design perspective, you can refer to the framework when shaping your own sovereignty architecture, selecting configurations, and defining internal controls to meet regulatory, contractual, and mission-specific requirements. Because the ESC-SRF is industry and sector agnostic, you can apply criteria from the framework to suit your own unique needs. Depending on your sovereign use case, not all criteria may apply to your use case sovereign needs. The ESC-SRF can also be used in conjunction with AWS Well-Architected which can help you learn, measure, and build using architectural best practices. Where appropriate you can create your version of the ESC-SRF, map to controls, and have them tested by a third party. To download the ESC-SRF, visit AWS Artifact (login required).
A strong, clear foundation
The publication of the ESC-SRF is part of our ongoing commitment to delivering on the AWS Digital Sovereignty Pledge through transparency and assurances to help customers meet their evolving sovereignty needs with assurances designed, implemented, and validated entirely within the EU. Within the framework, customers can build solutions in the AWS European Sovereign Cloud with confidence and a strong understanding of how they are able to meet their sovereignty goals using AWS.
For more information about the AWS European Sovereign Cloud, visit aws.eu.
If you have feedback about this post, submit comments in the Comments section below.
Pop!_OS 24.04 LTS released
Post Syndicated from jzb original https://lwn.net/Articles/1050129/
Version 24.04 LTS of the Ubuntu-based Pop!_OS distribution has
been released with the COSMIC Desktop Environment:
Today is special not only in that it’s the culmination of over
three years of work, but even more so in that System76 has built a
complete desktop environment for the open source community. We’re
proud of this contribution to the open source ecosystem. COSMIC is
built on the ethos that the best open source projects enable people to
not only use them, but to build with them. COSMIC is modular and
composable. It’s the flagship experience for Pop!_OS in its own way,
and can be adapted by anyone that wants to build their own unique user
experience for Linux.
In addition to the COSMIC desktop environment, Pop!_OS is now
available for Arm computers with the 24.04 LTS release, and the
distribution has added hybrid graphics support for better battery
life. LWN covered an
alpha version of COSMIC in August 2024.
Rust 1.92.0 released
Post Syndicated from jzb original https://lwn.net/Articles/1050125/
Version
1.92.0 of Rust has been released. This release includes a number
of stabilized APIs, emits unwind tables by default on Linux, validates
input to #[macro_export], and much more. See the separate
release notes for Rust,
Cargo,
and Clippy.
[$] Toward a policy for machine-learning tools in kernel development
Post Syndicated from corbet original https://lwn.net/Articles/1049830/
The first topic of discussion at the 2025 Maintainers Summit has been in
the air for a while: what role — if any — should machine-learning-based
tools have in the kernel development process? While there has been a fair
amount of controversy around these tools, and concerns remain, it seems
that the kernel community, or at least its high-level maintainership, is
comfortable with these tools becoming a significant part of the development
process.
AIs Exploiting Smart Contracts
Post Syndicated from Bruce Schneier original https://www.schneier.com/blog/archives/2025/12/ais-exploiting-smart-contracts.html
I have long maintained that smart contracts are a dumb idea: that a human process is actually a security feature.
Here’s some interesting research on training AIs to automatically exploit smart contracts:
AI models are increasingly good at cyber tasks, as we’ve written about before. But what is the economic impact of these capabilities? In a recent MATS and Anthropic Fellows project, our scholars investigated this question by evaluating AI agents’ ability to exploit smart contracts on Smart CONtracts Exploitation benchmark (SCONE-bench)a new benchmark they built comprising 405 contracts that were actually exploited between 2020 and 2025. On contracts exploited after the latest knowledge cutoffs (June 2025 for Opus 4.5 and March 2025 for other models), Claude Opus 4.5, Claude Sonnet 4.5, and GPT-5 developed exploits collectively worth $4.6 million, establishing a concrete lower bound for the economic harm these capabilities could enable. Going beyond retrospective analysis, we evaluated both Sonnet 4.5 and GPT-5 in simulation against 2,849 recently deployed contracts without any known vulnerabilities. Both agents uncovered two novel zero-day vulnerabilities and produced exploits worth $3,694, with GPT-5 doing so at an API cost of $3,476. This demonstrates as a proof-of-concept that profitable, real-world autonomous exploitation is technically feasible, a finding that underscores the need for proactive adoption of AI for defense.
Is TP-Link Spying on You? The REAL Story Behind the US Ban Investigation
Post Syndicated from Crosstalk Solutions original https://www.youtube.com/watch?v=b9q2p4v1q94
React2Shell and related RSC vulnerabilities threat brief: early exploitation activity and threat actor techniques
Post Syndicated from Cloudforce One original https://blog.cloudflare.com/react2shell-rsc-vulnerabilities-exploitation-threat-brief/
On December 3, 2025, immediately following the public disclosure of the critical, maximum-severity React2Shell vulnerability (CVE-2025-55182), the Cloudforce One Threat Intelligence team began monitoring for early signs of exploitation. Within hours, we observed scanning and active exploitation attempts, including traffic originating from infrastructure associated with Asian-nexus threat groups.
Early activity indicates that threat actors quickly integrated this vulnerability into their scanning and reconnaissance routines. We observed systematic probing of exposed systems, testing for the flaw at scale, and incorporating it into broader sweeps of Internet‑facing assets. The identified behavior reveals the actors relied on a combination of tools, such as standard vulnerability scanners and publicly accessible Internet asset discovery platforms, to find potentially vulnerable React Server Components (RSC) deployments exposed to the Internet.
Patterns in observed threat activity also suggest that the actors focused on identifying specific application metadata — such as icon hashes, SSL certificate details, or geographic region identifiers — to refine their candidate target lists before attempting exploitation.
In addition to React2Shell, two additional vulnerabilities affecting specific RSC implementations were disclosed: CVE-2025-55183 and CVE-2025-55184. Both vulnerabilities, while distinct from React2Shell, also relate to RSC payload handling and Server Function semantics, and are described in more detail below.
On December 3, 2025, the React Team disclosed a Remote Code Execution (RCE) vulnerability affecting servers using the React Server Components (RSC) Flight protocol. The vulnerability, CVE-2025-55182, received a CVSS score of 10.0 and has been informally referred to as React2Shell.
The underlying cause of the vulnerability is an unsafe deserialization flaw in the RSC Flight data-handling logic. When a server processes attacker-controlled payloads without proper validation, it becomes possible to influence server-side execution flow. In this case, crafted input allows an attacker to inject logic that the server interprets in a privileged context.
Exploitation is straightforward. A single, specially crafted HTTP request is sufficient; there is no authentication requirement, user interaction, or elevated permissions involved. Once successful, the attacker can execute arbitrary, privileged JavaScript on the affected server.
This combination of authenticated access, trivial exploitation, and full code execution is what places CVE-2025-55182 at the highest severity level and makes it significant for organizations relying on vulnerable versions of React Server Components.
In response, Cloudflare has deployed new rules across its network, with the default action set to Block. These new protections are included in both the Cloudflare Free Managed Ruleset (available to all Free customers) and the standard Cloudflare Managed Ruleset (available to all paying customers), as detailed below. More information about the different rulesets can be found in our documentation.
|
CVE |
Description |
Cloudflare WAF Rule ID |
|---|---|---|
|
CVE-2025-55182 React – RCE |
Rules to mitigate React2Shell Exploit |
Paid: 33aa8a8a948b48b28d40450c5fb92fba Free: 2b5d06e34a814a889bee9a0699702280 |
|
CVE-2025-55182 – 2 React – RCE Bypass |
Additional rules to mitigate exploit bypass |
Paid: bc1aee59731c488ca8b5314615fce168 Free: cbdd3f48396e4b7389d6efd174746aff |
|
CVE-2025-55182 Scanner Detection |
Additional paid WAF rule to catch React2Shell scanning attempts |
Paid: 1d54691cb822465183cb49e2f562cf5c |
In addition to React2Shell, two additional vulnerabilities affecting specific RSC implementations were disclosed. The two vulnerabilities, while distinct from React2Shell, also relate to RSC payload handling and Server Function semantics, with corresponding Cloudflare protections noted below:
|
CVE |
Description |
Cloudflare WAF Rule ID |
|---|---|---|
|
CVE-2025-55183 Leaking Server Functions |
In deployments where Server Function identifiers are insufficiently validated, an attacker may force the server into returning the source body of a referenced function |
Paid: 17c5123f1ac049818765ebf2fefb4e9b Free: 3114709a3c3b4e3685052c7b251e86aa |
|
CVE-2025-55184 React Function DoS |
A crafted RSC Flight Payload containing cyclical Promise references can trigger unbounded recursion or event-loop lockups under certain server configurations, resulting in denial-of-service conditions |
Paid: 2694f1610c0b471393b21aef102ec699 |
The following analysis details the initial wave of activity observed by Cloudforce One, focusing on threat actor attempts to scan for and exploit the React2Shell vulnerability. While these findings represent activity immediately following the vulnerability’s release, and were focused on known threat actors, it is critical to note that the volume and scope of related threat activity have expanded dramatically since these first observations.
Unsurprisingly, the threat actors were relying heavily on publicly available, commercial, and a variety of other tools to identify vulnerable servers:
-
Vulnerability intelligence: The actors leveraged vulnerability intelligence databases that aggregated CVEs, advisories, and exploits for tracking and prioritization.
-
Vulnerability reconnaissance: The actors conducted searches using large-scale reconnaissance services, indicating they are relying on Internet-wide scanning and asset discovery platforms to find exposed systems running React App or RSC components. They also made use of tools that identify the software stack and technologies used by websites.
-
Vulnerability scanning: Activity included use of Nuclei (User-Agent: Nuclei – CVE-2025-55182), a popular rapid scanning tool used to deploy YAML-based templates to check for vulnerabilities. The actors were also observed using a highly likely React2Shell scanner associated with the User-Agent “Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/60.0.3112.113 Safari/537.36 React2ShellScanner/1.0.0“.
-
Vulnerability exploitation: The actors made use of Burp Suite, a web application security testing platform for identifying and exploiting vulnerabilities in HTTP/S traffic.
Recon via Internet-wide scanning and asset discovery platform
To enumerate potential React2Shell targets, the actors leveraged an Internet-wide scanning and asset-discovery platform commonly used to fingerprint web technologies at scale. Their queries demonstrated a targeted effort to isolate React and Next.js applications — two frameworks directly relevant to the vulnerability — by searching for React-specific icon hashes, framework-associated metadata, and page titles containing React-related keywords. This approach likely allowed them to rapidly build an inventory of exploitable hosts before initiating more direct probing.
Targeting enumeration and filtering
During their reconnaissance phase, the operators applied additional filtering logic to refine their target set and minimize noise. Notably, they excluded Chinese IP space from their searches, indicating that their enumeration workflow intentionally avoided collecting data on possibly domestic infrastructure. They also constrained scanning to specific geographic regions and national networks to identify likely high-value hosts. Beyond basic fingerprinting, the actors leveraged SSL certificate attributes — including issuer details, subject fields, and top-level domains — to surface entities of interest, such as government or critical-infrastructure systems using .gov or other restricted TLDs. This combination of geographic filtering and certificate-based pivoting enabled a more precise enumeration process that prioritized strategically relevant and potentially vulnerable high-value targets.
Preliminary target analysis
Observed activity reflected a clear focus on strategically significant organizations across multiple regions. Their highest-density probing occurred against networks in Taiwan, Xinjiang Uygur, Vietnam, Japan, and New Zealand — regions frequently associated with geopolitical intelligence collection priorities. Other selective targeting was also observed against entities across the globe, including government (.gov) websites, academic research institutions, and critical‑infrastructure operators. These infrastructure operators specifically included a national authority responsible for the import and export of uranium, rare metals, and nuclear fuel.
The actors also prioritized high‑sensitivity technology targets such as enterprise password managers and secure‑vault services, likely due to their potential to provide downstream access to broader organizational credentials and secrets.
Additionally, the campaign targeted edge‑facing SSL VPN appliances whose administrative interfaces may incorporate React-based components, suggesting the actor sought to exploit React2Shell against both traditional web applications and embedded web management frameworks in order to maximize access opportunities.
Early threat actor observations
Cloudforce One analysis confirms that early scanning and exploitation attempts originated from IP addresses previously associated with multiple Asia-affiliated threat actor clusters. While not all observed IP addresses belong to a single operator, the simultaneous activity suggests shared tooling, infrastructure, or experimentation in parallel among groups with a common purpose and shared targeting objectives. Observed targeting enumeration and filtering (e.g. a focus on Taiwan and Xinjiang Uygur, but exclusion of China), as well as heavy use of certain scanning and asset discovery platforms, suggest general attribution to Asia-linked threat actors.
Cloudflare’s Managed Rulesets for React2Shell began detecting significant activity within hours of the vulnerability’s disclosure. The graph below shows the daily hit count across the two exploit-related React2Shell WAF rules.

Aggregate rule hit volume over time
The React2Shell disclosure triggered a surge of opportunistic scanning and exploit behavior. In total, from 2025-12-03 00:00 UTC to 2025-12-11 17:00UTC, we received 582.10M hits. That equates to an average of 3.49M hits per hour, with a maximum number of hits in a single hour reaching 12.72M. The average unique IP count per hour was 3,598, with the maximum number of IPs in an hour being 16,585.

Hourly count of unique IPs sending React2Shell-related probes
Our data also shows distinct peaks above 6,387 User-Agents per hour, indicating a heterogeneous mix of tools and frameworks in use, with the average number of unique User-Agents per hour being 2,255. The below graph shows exploit attempts based on WAF rules (Free and Managed) triggering on matching payloads:

Unique User-Agent strings used in React2Shell-related requests
To better understand the types of automated tools probing for React2Shell exposure, Cloudflare analyzed the User-Agent strings associated with React2Shell-related requests since December 3, 2025. The data shows a wide variety of scanning tools suggesting broad Internet-wide reconnaissance:
|
Top 10 User Agent strings by exploit attempts |
|---|
|
Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/60.0.3112.113 Safari/537.36 Assetnote/1.0.0 |
|
Block Security Team/Assetnote-HjJacErLyq2xFe01qaCM1yyzs |
|
Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/60.0.3112.113 Safari/537.36 (GIS – AppSec Team – Project Vision) |
|
Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 |
|
python-requests/2.32.5 |
|
Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/60.0.3112.113 Safari/537.36 Assetnote/1.0.0 (ExposureScan) |
|
Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/91.0.4472.124 Safari/537.36 |
|
Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/142.0.0.0 Safari/537.36 |
|
Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/60.0.3112.113 Safari/537.36 |
|
Mozilla/5.0 (Macintosh; Intel Mac OS X 10_15_7) AppleWebKit/605.1.15 (KHTML, like Gecko) Version/18.1 Safari/605.1.1 |
Cloudflare analyzed the payload sizes associated with requests triggering React2Shell-related detection rules. The long-tailed distribution — dominated by sub-kilobyte probes, but punctured by extremely large outliers — suggest actors are testing a wide range of payload sizes:
|
Metric |
Value |
|---|---|
|
Maximum payload size |
375 MB |
|
Average payload size |
3.2 KB |
|
p25 (25th Percentile) |
703 B |
|
p75 (75th Percentile) |
818 B |
|
p90 (90th Percentile) |
2.7 KB |
|
p99 (99th Percentile) |
66.5 KB |
|
Standard deviation |
330 KB |
In parallel with our ongoing analysis of the React2Shell vulnerability, two additional vulnerabilities affecting React Server Components (RSC) implementations have been identified:
The vulnerability CVE-2025-55184 was recently disclosed, revealing that React Server Component frameworks can be forced into a Node.js state where the runtime unwraps an infinite recursion of nested Promises.
This behavior:
-
Freezes the server indefinitely
-
Prevents yielding back to the event loop
-
Effectively takes the server offline
-
Does not require any specific Server Action usage — merely the presence of a server capable of processing an RSC Server Action payload
The trigger condition is a cyclic promise reference inside the RSC payload.
Another vulnerability, CVE-2025-55183, was also recently disclosed, revealing that certain React Server Component frameworks can leak server-only source code under specific conditions.
If an attacker gains access to a Server Function that:
-
Accepts an argument that undergoes string coercion, and
-
Does not validate that the argument is of an expected primitive type
then the attacker can coerce that argument into a reference to a different Server Function. The coerced value’s toString() output causes the server to return the source code of the referenced Server Function.
Cloudflare’s protection strategy is multi-layered, relying on both the inherent security model of its platform and immediate, proactive updates to its Web Application Firewall (WAF).
-
Cloudflare Workers: React-based applications and frameworks deployed on Cloudflare Workers are inherently immune. The Workers security model prevents exploits from succeeding at the runtime layer, regardless of the malicious payload.
-
Proactive WAF deployment: Cloudflare urgently deployed WAF rules to detect and block traffic proxied through its network related to React2Shell and the recently disclosed RSC vulnerabilities.
The Cloudflare security team continues to monitor for additional attack variations and will update protections as necessary to maintain continuous security for all proxied traffic.
While Cloudflare’s emergency actions — the WAF limit increase and immediate rule deployment — have successfully mitigated the current wave of exploitation attempts, this vulnerability represents a persistent and evolving threat. The immediate weaponization of CVE-2025-55182 by sophisticated threat actors underscores the need for continuous defense.
Cloudflare remains committed to continuous surveillance for emerging exploit variants and refinement of WAF rules to detect evasive techniques. However, network-level protection is not a substitute for remediation at the source. Organizations must prioritize immediate patching of all affected React and Next.js assets. This combination of platform-level WAF defense and immediate application patching remains the only reliable strategy against this critical threat.
|
Tool/Scanner |
User Agent String |
Observation/Purpose |
|---|---|---|
|
Nuclei |
Nuclei – CVE-2025-55182 |
User-Agent for rapid, template-based scanning for React2Shell vulnerability |
|
React2ShellScanner |
Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/60.0.3112.113 Safari/537.36 React2ShellScanner/1.0.0 |
User-Agent for a likely custom React2Shell vulnerability scanner |
Architecting conversational observability for cloud applications
Post Syndicated from Anton Aleksandrov original https://aws.amazon.com/blogs/architecture/architecting-conversational-observability-for-cloud-applications/
Modern cloud applications are commonly built as a collection of loosely coupled microservices running on services like Amazon Elastic Kubernetes Service (Amazon EKS), Amazon Elastic Container Service (Amazon ECS), or AWS Lambda. This architecture gives engineering teams flexibility and scalability, but its inherently distributed nature also makes troubleshooting more difficult. When something breaks, engineers often find themselves digging through logs, events, and metrics scattered across different observability layers. With Kubernetes, for example, without a deep understanding of the service, troubleshooting can turn into a time-consuming effort to manually correlate information from different sources.
In this post, we walk through building a generative AI–powered troubleshooting assistant for Kubernetes. The goal is to give engineers a faster, self-service way to diagnose and resolve cluster issues, cut down Mean Time to Recovery (MTTR), and reduce the cycles experts spend finding the root cause of issues in complex distributed systems.
Overview
One of the challenges of architecting a modern cloud application is keeping observability intact across many moving pieces. Anyone who has ever tailed logs in one terminal while running kubectl describe and curl commands in another, knows how tedious this can get. Distributed systems are powerful, but they’re also complex. Kubernetes, for example, offers strong orchestration capabilities, yet troubleshooting inside a cluster often means navigating multiple layers of abstractions such as pods, nodes, networking, logs, and events. On top of that, the system generates a large volume of telemetry, including kubelet logs, application logs, cluster events, and metrics. Making sense of these layers requires both expertise on the system and application knowledge.
This skill gap shows up in the numbers. According to the 2024 Observability Pulse Report, 48% of organizations say that lack of team knowledge is their biggest challenge to observability in cloud-native environments. MTTR has also been going up for three years straight, with most teams (82%) saying it can take more than an hour to resolve production issues.
When something goes wrong and your applications start to fail for an unknown reason, engineers often must start stitching together signals from multiple sources to find the root cause. That can be tedious for specialists, and it gets worse when the issue is intermittent or spans across services. Often, multiple teams need to get involved – application engineers may not know Kubernetes well, while platform teams may not have deep insight into the applications. This can result in longer troubleshooting cycles, potentially degraded user experience, and pulling engineers away from planned work that drives business goals.
Figure 1. A multitude of telemetry sources in Kubernetes clusters
This is where generative artificial intelligence (AI) can help. Users can build an AI assistant that combines large language model (LLM)-driven analysis and guidance with existing telemetry data. This assistant enables engineers to troubleshoot issues faster, in a self-service way, without requiring every team to become Kubernetes experts. In the following sections, we show how to build such an assistant for Amazon EKS, however, keep in mind that a similar approach can be extended to other compute services like Amazon ECS or AWS Lambda.
Solution architecture
Architecting this AI-powered troubleshooting assistant consists of three primary parts:
- Deployment approach selection: The solution supports two architectures – a traditional Retrieval-Augmented Generation (RAG)-based chatbot and a modern Strands-based agentic system that uses the Strands Agents SDK with EKS MCP Server integration for direct EKS API access.
- Telemetry collection and storage: Collecting telemetry from various sources and storing it as vector embeddings in Amazon OpenSearch (RAG approach) or as 1024-dimensional embeddings in Amazon S3 Vectors (Strands approach).
- Interactive troubleshooting interface: Building either a web-based chatbot that retrieves relevant telemetry and injects it into LLM prompts, or a Slack integrated multi-agent system that uses MCP tools for real-time Kubernetes diagnostics.
For this architecture walkthrough, we focus on the RAG-based approach. The first step is setting up a pipeline that can reliably collect, process, and store telemetry data. This pipeline aggregates telemetry from the relevant data sources, such as application logs, kubelet logs, and Kubernetes events. In Kubernetes environments, this can be done with a telemetry processor and forwarder, such as Fluent Bit, which streams telemetry into Amazon Kinesis Data Streams. On the receiving end, we use a Lambda function to normalize collected data, Amazon Bedrock to generate vector embeddings, and OpenSearch Serverless to store this embedded representation for efficient retrieval. Because these services are serverless, we can avoid the overhead of managing infrastructure and can focus on the troubleshooting workflow itself.
Figure 2. Collecting telemetry from sources, generating embeddings, and saving in OpenSearch
Pro tip: for better performance and cost-efficiency, your Lambda functions should use batching when ingesting data from Kinesis, generating embeddings, and storing them in OpenSearch.
Once telemetry is collected, converted to embeddings, and stored in OpenSearch, the next step is building a chatbot that uses RAG. Using RAG means that when a user asks a question, the chatbot looks up semantically similar telemetry in OpenSearch, adds it to the prompt, and sends it to the LLM. Instead of generic answers, the model now has relevant telemetry and cluster-specific details it can use to generate useful next steps, such as precise kubectl commands for the troubleshooting assistant, as illustrated in the following diagram.
Figure 3. Chatbot is using user queries augmented with telemetry context to send kubectl commands to the troubleshooting assistant.
One powerful aspect of this design is its iterative nature. The chatbot hands instructions to a troubleshooting assistant running in the cluster, which executes a set of allowlisted, read-only kubectl commands. The output comes back to the LLM, which can decide whether it needs to investigate further (by asking the troubleshooting assistant to run more kubectl commands), or present a clear resolution path to the engineer. This cycle gradually builds a richer picture of the issue by combining historical telemetry with real-time cluster state to speed up root cause analysis.
Figure 4. Iterative troubleshooting process.
Here’s the end-to-end troubleshooting flow illustrated in the preceding diagram:
- An engineer enters a query into the chatbot interface, for example “My pod is stuck in pending state. Investigate.”
- The chatbot sends the query to Bedrock, which converts it into vector embeddings.
- Using those embeddings, the chatbot retrieves semantically matching telemetry that was previously stored in OpenSearch.
- The chatbot generates an augmented prompt, which contains both the original query and semantically relevant telemetry, and passes it to the LLM. The LLM responds with a list of kubectl commands to run for further diagnostics.
- The chatbot forwards those commands to the troubleshooting assistant running in the EKS cluster. The agent executes them with a service account that has read-only permissions, following the principle of least privilege, and sends the output back.
- Based on the output, the chatbot asks LLM to decide whether to continue investigation (by asking the agent to run more commands), or whether it has enough context to produce an answer.
- Once enough information has been gathered (investigation concluded), the chatbot composes a final prompt, including the query, telemetry, and investigation results, and asks the LLM for a final resolution, which it then returns to the engineer.
Example implementation
Use the example repo to deploy the solution in your AWS account. Follow the instructions in README.md for provisioning and testing the sample project using Terraform. Resources provisioned by the example project incur costs in your AWS account. Make sure to clean up the project as described in the README.md to avoid unexpected costs.
The repository provides two deployment architectures controlled by the deployment_type Terraform variable:
- RAG-based deployment (default): See the
./terraform/modulesdirectory for the “ingestion-pipeline” module that creates a Kinesis Data Stream and Lambda function to generate embeddings using"amazon.titan-embed-test-v2:0"and store them in OpenSearch. The “agentic-chatbot” module handles the Gradio web interface and kubectl command execution. - Strands agentic deployment: this approach uses the Strands Agents SDK to create a multi-agent system with three specialized agents:
- Agent Orchestrator: Coordinates troubleshooting workflows
- Memory Agent: Manages conversation context and historical insights
- K8s Specialist: Handles Kubernetes diagnostics
The agentic system stores knowledge as 1024-dimensional embeddings in Amazon S3 Vectors, providing cost-optimized vector storage for AI agents. EKS MCP Server integration enabled direct EKS API access through standardized MCP tools located in ./apps/agentic-troubleshooting/src/tools/. Engineers interact via Slack bot integration, where the Strands agents can execute kubectl commands through the MCP protocol while maintaining Pod Identity security for AWS service access.
The following screenshot shows an example chatbot response to a query about a pod being stuck in pending state. The assistant generated and ran multiple kubectl commands to build the output and came up with recommendations for issue remediation.
Figure 5. EKS cluster troubleshooting, example output
See AWS re:Invent 2025 – Streamline Amazon EKS operations with Agentic AI and KubeCon – From Logs To Insights: Real-time Conversational Troubleshooting for Kubernetes with GenAI sessions for a deeper dive into solution implementation.
Security considerations
When implementing AI agents for Kubernetes environments, security must be a primary consideration throughout the architecture. The solution requires secure communication channels between the chatbot and EKS clusters, with interactions authenticated through AWS Identity and Access Management (AWS IAM) roles.
Permissions-wise, command execution security is critical. Implementing strict allowlists that only allow read-only kubectl operations to help prevent unauthorized cluster modifications while maintaining diagnostic capabilities. The troubleshooting assistant should also operate with minimal Kubernetes RBAC permissions, limited to viewing pods, services, events, and logs within specific namespaces.
Data protection measures must include sanitizing application logs before embedding generation to help prevent sensitive information exposure, encrypting the telemetry data in transit through Kinesis and at rest in OpenSearch using AWS Key Management Service (AWS KMS).
Follow the AWS Well-Architected Framework Security Pillar principles, deploy components within Amazon Virtual Private Cloud (Amazon VPC) using private subnets and VPC endpoints to minimize network exposure, implement comprehensive logging of troubleshooting activities for audit purposes, and validate user inputs to protect against prompt injection attacks that could manipulate the AI assistant’s behavior.
Conclusion
In this post, we walked through how to architect a generative AI-powered troubleshooting assistant that gives engineers a way to solve Kubernetes issues in a self-service way, without always needing service experts to step in. By combining telemetry analysis with AI-driven context, engineers can get to the root causes faster and keep MTTR low. Assistant’s ability to pull from multiple telemetry sources, run safe diagnostic commands, and provide actionable recommendations helps to make the troubleshooting process more efficient and less disruptive to ongoing work.
As distributed systems continue to grow in scale and complexity, solutions like the one described in this post become essential. Putting AI on top of your observability data helps to practically handle these challenges today, while also setting you up for more autonomous, resilient operations in the future.
Мила родино, ти си ергенски рай
Post Syndicated from Светла Енчева original https://www.toest.bg/mila-rodino-ti-si-ergenski-ray/

Първият сезон на „Ергенът: Любов в рая“ вече е минало. Човек може да гледа риалити шоута по различни причини. Например за да изпитва морално или естетическо превъзходство, да се подиграва, да се възмущава, да се вживява в екранни драми, да си намира повод да влиза в пререкания или просто да си убива времето. Може да гледа обаче и за да разбере – какви ценности и послания се внушават, как се „управляват“ постъпките на участниците и зрителските реакции, какво ни казва шоуто за обществото, в което живеем.
Що се отнася до авторката на настоящата статия – оправдавах своето guilty pleasure (гузно удоволствие) да си причинявам риалитито с обещание, което лекомислено дадох на редакцията на „Тоест“: че след първата си статия по темата съм съгласна да напиша и втора, когато сезонът свърши. Но колкото повече гледах, толкова повече „Ергенът: Любов в рая“ ми заприличваше на държавата, в която живеем.
Задкулисие, което вече не се крие
В България отдавна се говори за задкулисие – реална власт извън формалното управление, която „дърпа конците“ на държавата. През 2009 г. репликата на Ахмед Доган „Аз разпределям порциите на властта“ от изтекъл запис с негово участие на събитие на ДПС звучеше скандално. Днес #кой дърпа конците, отдавна не е тайна.
Задкулисието в ергенския рай е Продукцията – с главна буква, защото е самостоятелен герой със собствена роля. По принцип се очаква една продукция да е по-скоро невидима, освен в специални моменти, като церемонии, за да изглежда, че отношенията между участниците следват естествен ход. Нашата Продукция обаче се намесва, когато и както реши.
Под формата на глас зад кадър например Продукцията внушава на ергенка чувство за вина, защото върши нормалното за участниците в подобно риалити – колебае се в чувствата си към ерген, с когото се е запознала наскоро, и казва ту че не го харесва, ту че го харесва. В резултат ергенката цяла седмица плаче, тръшка се, че е виновна, и напомня „вината“ си дори в самия край на шоуто.
По аналогичен начин в България хора биват пречупвани и принудени да подпишат самопризнания под натиск, като бившия заместник на Коцев – Диан Иванов.
Властта на задкуслисието води до произволно прилагане на правилата.
Основно правило в ергенския рай е, че който не получи роза, си тръгва, освен ако водещата не му даде една от общо трите за цялото предаване спасителни златни рози. Един ерген обаче се колебае между две ергенки. Дава роза на едната, другата си тръгва и той се разкайва за избора си. Но не щеш ли, кахърният мъж кани на среща отхвърлената участничка, моли я да се върне и тя се съгласява. Как става тази работа, след като ергенката вече е напуснала предаването, без дългата ръка на Продукцията?
Но какво ли се учудваме – колко институции в България са оглавявани от хора, чийто мандат вече е изтекъл? Членове на регулатори, на Висшия съдебен съвет, директорът на БНТ… Най-очеизбождащият пример е с главния прокурор. Въпреки че съдът „не даде роза“ на Борислав Сарафов, постановявайки, че той е нелегитимен главен прокурор, засега нищо не може да го мръдне от поста.
Като стана дума за мандати, първоначалното впечатление за джендърната „мандатност“ в шоуто беше, че на една церемония жените дават рози на мъжете, а на следващата е обратното. В един период обаче имаше три поредни церемонии, в които мъжете даваха рози на жените. Защо? Ергенките все бяха повече. Кой обаче решава в „рая“ да влизат повече жени, отколкото мъже, ако не Продукцията?
В някои случаи произволните решения на Продукцията са обясними с гоненето на рейтинг. Например тя отне правото на избор на ергенка, която показваше колебание между двама ергени, като прати и тримата директно на финал – за да има интрига до самия край. По този начин удължи с няколко дни терзанията им, както и тормоза върху участничката. Но и това едва ли ни учудва – колко често в България законодателни решения се приемат след формални или предварително нагласени „обществени обсъждания“, без да се чуе гласът на хората, които те засягат?
С напредването на риалитито Продукцията все повече ставаше тема на разговор между ергените. Един от членовете на пратения на финал любовен триъгълник дори конкретно я визира, обосновавайки решението си да остане, вместо да си тръгне:
Просто напук и на инат, защото всички ме дразните. И искам и на вас да ви е гадно с мене. И на Продукцията.
Милиони, закони, кокошки, прошки и Ново начало
Понякога действията на Продукцията трудно могат да се оправдаят с рейтинга и сценария, а зад тях прозира неравно третиране на участниците.
В една игра ергените мъже трябва да се състезават по двойки в дърпане на въже. Няма предварително зададени правила как точно да се удържи въжето. Единият от двамата финалисти не разчита само на грубата си мъжка сила, а прилага тактика, с която побеждава. Това поражда възмущение сред участниците (макар той да не е единственият участник в играта, приложил подобна тактика). Продукцията предлага на ергенките да гласуват кой е победил, и те избират загубилия битката.
Ако отново потърсим паралели с обществения живот в България, няма да ни е трудно да открием такива. Ето, Конституционният съд и Върховният касационен съд сътвориха тълкувания на понятията за пол и традиции в Конституцията, каквито в Основния закон няма, само и само служебно да декласират групата на ЛГБТ хората.
Отвръщайки на канонадата от упреци, че не е спазил правилата (каквито е нямало), спечелилият с тактика и впоследствие служебно загубил ерген обръща внимание върху едно доста по-сериозно неспазване на правила. А именно, че
ергени са излезли да се почерпят извън района, в който се снима предаването.
Напускането на „рая“ е забранено и тъй като всичко се снима с камери, то не би могло да се осъществи без благословията на Продукцията.
„Бегълците“, които са сред най-яростните обвинители на декласирания ерген, не показват никакво притеснение, когато става ясно, че са нарушили едно от най-важните правила. Напротив, хвалят се колко хубаво са си изкарали и как са пили „шотчета“. На въпроса дали има привилегии, един от тях отговори:
Имам, да! В песента се пее: „За кокошка няма прошка, за милиони няма закони“! Кое не ти е ясно?
Със споменаването на известната поговорка ергенът нямаше предвид обичайния ѝ смисъл – изтъкване на социална несправедливост. Напротив, изразяваше гордост, тъй като самият той твърди, че е милионер. Един вид, полага му се да е над законите.
Над правилата е и ергенката, която беше кандидат-депутатка от ДПС – Ново начало на изборите на 27 октомври 2025 г.
В качеството си на половинка в „рая“ на ергена с милионите и тя е от пилите „шотчета“ извън района на снимките. Но това май не е единствената ѝ привилегия.
Едно от основните правила за участниците е, че те нямат право да използват телефоните си. Мобилните им устройства се вземат преди началото на снимките и им се връщат след финала. На кадър от предаването (на 25-тата секунда от това видео) обаче се вижда как ергенката от „Ново начало“ държи нещо, което има формата на телефон и свети като телефон. Ако следваме принципа, че най-простото обяснение често е вярното, това най-вероятно е мобилен телефон.
(Не)толерантност към насилието
Случаите на вербално насилие в „рая“, на тормоз, подигравки, обиди заради външния вид (т.нар. бодишейминг), унижаване и пр. са толкова много, че и няколко статии няма да стигнат за споменаването им. Физическото насилие обаче е забранено, научаваме от разговори на Продукцията с участници. Това правило беше моментално приложено за едва-що влязъл в шоуто ерген, който събори ергенка от стола ѝ. Сцената не беше излъчена изцяло в предаването, а само загатната, както е и редно, защото показването на насилието на екран го мултиплицира.
Аналогична би следвало да е реакцията и ако ергенка бутне друга в басейна. Но не е. Бутането в басейна е задача, която Продукцията дава в рамките на игра, която уж би трябвало да е забавна за всички. Задачата е възложена на ергенка, изпитваща ревност към друга, в момент, в който почти всички участници тормозят другата. Ревнивата ергенка блъска съперницата си с всички сили. След кратък полет момичето пада във водата. Кадърът с блъскането и полета се повтаря няколко пъти (няма да сложа линк, защото е унизително). Ергените се смеят. „Дано може да плува“, чува се развеселен глас. Момичето излиза от водата и сяда мокро до останалите, защото е длъжно да продължи участието си в играта.
За да направим връзка с обществения живот в България – има групи хора, насилието върху които остава без последствия и дори се толерира. Бежанци се задържат, ограбват и бият на границата; „ловци на бежанци“ се обявяват за герои; събарят се единствените жилища на роми и пр. – държавата внушава, че представителите на някои групи си го „заслужават“.
За ергенки и ергени, които налитат на бой, няма никакви последствия – щом не се е стигнало до реално нанасяне на удари, за Продукцията, изглежда, няма проблем. И някои „дребни“ форми на физическо насилие не се броят. Ерген постепенно засилва агресията си към друг – от вербален тормоз минава към блъскане на краката му с чекмедже. Продукцията го изгонва чак след като изплюва храна върху набелязаната жертва. За разлика от първия изгонен ерген, който ни се чу, ни се видя, този гордо дефилира по bTV, защитавайки гледната си точка.
Тук стигаме до темата за домашното насилие,
понеже вторият изгонен ерген си имаше половинка в „рая“. Забраняваше на избраницата си да говори с другите мъже в шоуто, както и на тях да общуват с нея. Изобщо, смяташе, че е най-добре тя да мълчи, а той да говори вместо нея. И тя преобладаващо си мълчеше, говореше основно в негово отсъствие, почти няма и синхрони с нея (реплики в разговор с Продукцията).
Когато Продукцията реши да изгони ергена, тя му даде възможност преди напускането си да говори и с участника, върху когото беше изплюл храна (уж да му се извини, но на практика не стана точно така), и с избраницата си. Нея той постави пред избор – да си тръгне с него или да остане. На практика обаче изборът не беше точно такъв – споменавайки как ще ѝ обясни причините за изгонването си в хотела, той вече беше предпоставил, че тя ще го последва.
Впоследствие стана ясно, че двамата продължават да са заедно и извън „рая“. Може би ергенката щеше да последва изгонения и ако имаше възможност да вземе решение самостоятелно, далеч от присъствието му. Няма как да знаем това. Продукцията обаче не ѝ помогна, а bTV допълнително легитимира тази основана на контрол и ограничения връзка.
Друг ерген пък забрани на половинката си да разговаря с ергенка, която я е обидила – с претенцията, че така всъщност я защитава. И дори ѝ постави условие: ако си позволи да общува с нея, той си тръгва.
Но какво ли се учудваме – борбата с домашното насилие не е приоритет и на държавата. Важното е да се борим с „джендъра“ и да не допускаме хората в еднополови връзки до и без това не особено ефективно работещата система на защита.
В „рая“ не липсваше и сексуално насилие.
Някои ергени толкова искаха от половинките си да им „пуснат“, че понякога си позволяваха да ги понатиснат в леглото. Те се цупеха, че не постигат своето, и обвиняваха ергенките в липса на взаимност. Не вдяваха, че „не“-то, дори изречено през смях, си е „не“. Един участник беше особено настоятелен не само в леглото. Опита се да бръкне между краката на изгората си дори в двора. Не успя само защото тя е бивша спортистка и има здрави мускули.
На повечето ергенски мераци Продукцията не реагира, но след последния от описаните случаи попита ергенката дали да се намеси. Не го направи, защото участничката каза, че няма нужда. Така както институциите си измиват с ръцете с това, че много от пострадалите не си търсят правата.
Привидност и реалност
Както в политиката, така и в „рая“ не трябва да приемаме всичко за чиста монета. Не само защото нещата, които виждаме, са „за пред хората“ и поведението на участниците поне отчасти се дължи на факта, че играят роли, а и защото биваме сугестирани кое как да възприемаме.
Един от начините да се влияе на преценката ни е да се манипулира усещането ни за време. ГЕРБ, които са на власт с кратки прекъсвания от 2009 г., стоварват отговорността за всички беди върху периода между 2021 и 2024 г., когато не са участвали в правителството (макар че правителството на Николай Денков беше и тяхно).
В „рая“ времето е разтегливо дори повече, отколкото в главата на Бойко Борисов.
В началото на шоуто церемониите с розите се излъчваха веднъж седмично – в петък. Един период между две церемонии обаче се проточи цели три седмици. Така се създаде впечатлението, че участниците са прекарали много повече време заедно, отколкото реално са, и че някои драми са се разразявали в продължение на близо месец, а не по-малко от седмица.
Случваше се едно и също събитие да се излъчва в няколко поредни епизода, особено ако включва скандал. Други случки бяха показани мимоходом, а много така и не са стигнали до зрителите, понеже няма как да се излъчи всичко. Не по-маловажна обаче е
привидността в ергенските отношения,
въпреки че в някои случаи е трудно да се сложи рязка граница между привидност и реалност. Ергени и ергенки може да смятат, че обиждат, тормозят и унижават, за да става шоу, но обидите, тормозът и униженията са си истински. С любовта нещата стоят по-скоро по обратния начин. От екрана се леят огромни количества от нея, но такива са правилата на играта.
До финала стигнаха седем двойки и една тройка, като ергените (в случая с тройката – избраният от дамата ерген) трябваше да дадат на избраниците си или роза (еквивалент на „една студена вода“), или годежен пръстен. Рози получиха само две участнички, а пръстени – пет. Така че шоуто завърши с четири годежа и един полугодеж (тъй като пръстенът беше сложен на дясната ръка на ергенката от тройката със заръка да го премести на лявата, когато се почувства готова).
Годежът е обещание за съвместно бъдеще, но колко от двойките, дали си драматични любовни обещания, са заедно след края на предаването? Има данни само за една – двамата от бившата тройка, завършили с полугодеж. Именно техните отношения бяха поставяни под въпрос от другите участници по време на почти цялото шоу. Защо тя е избрала него, а не друг; защо не си намери по-подходящ и по-мъжествен; защо е „лека жена“, „волна пеперуда“, скача „от цвят на цвят“ и не може да избере? Защо той не е достатъчно „мъжествен“; гей ли е; защо ѝ дава свобода?
Злите езици говорят, че далеч от камерите се е оформила истинска тройка, а не за шоуто, точно между най-големите морализатори, упрекващи оцелялата двойка, но засега не разполагам с достатъчно данни, за да потвърдя това.
В заключение, ако човек има желание и нерви да си причинява риалити формати, те могат да ни промиват мозъците (което и основно правят), но пък и ние можем да ги използваме, за да се упражняваме да не вярваме на очите си и да развиваме критичното си мислене. Да се замисляме какво ни внушават да мразим и от кое да се разчувстваме, да имаме едно наум кой дава празни обещания и кой е превърнат в изкупителна жертва. За да не стане така, че отново да се доверим на поредните популисти.
Security updates for Thursday
Post Syndicated from jzb original https://lwn.net/Articles/1050117/
Security updates have been issued by Debian (ffmpeg, firefox-esr, libsndfile, and rear), Fedora (httpd, perl-CGI-Simple, and tinyproxy), Oracle (firefox, kernel, libsoup, mysql8.4, tigervnc, tomcat, tomcat9, and uek-kernel), SUSE (alloy, curl, dovecot24, fontforge, glib2, himmelblau, java-17-openjdk, java-21-openjdk, kernel, krb5, lasso, libvirt, mozjs128, mysql-connector-java, nvidia-open-driver-G07-signed-check, openssh, poppler, postgresql17, postgresql18, python-cbor2, python-Django, python310, python311-Django, runc, strongswan, tomcat11, and xwayland), and Ubuntu (binutils, libpng1.6, linux, linux-aws, linux-aws-5.4, linux-gcp, linux-gcp-5.4, linux-hwe-5.4,
linux-ibm, linux-ibm-5.4, linux-kvm, linux-oracle, linux-xilinx-zynqmp, linux, linux-aws, linux-aws-6.14, linux-gcp, linux-hwe-6.14, linux-raspi, linux, linux-aws, linux-gcp, linux-realtime, and qtbase-opensource-src).
Xsight Labs X2 Switch Powering SpaceX Starlink V3 in a Milestone Win
Post Syndicated from Rohit Kumar original https://www.servethehome.com/xsight-labs-x2-switch-powering-spacex-starlink-v3-in-a-milestone-win/
SpaceX is using the Xsight Labs X2 12.8T programmable switch chip in its next-generation Starlink V3 satellites
The post Xsight Labs X2 Switch Powering SpaceX Starlink V3 in a Milestone Win appeared first on ServeTheHome.
This Made Editing in Lightroom… Weirdly Satisfying
Post Syndicated from Matt Granger original https://www.youtube.com/watch?v=J2aIQzhiMms
He’s Undocumented. She’s Not.
Post Syndicated from The Atlantic original https://www.youtube.com/watch?v=QbOY9SklFrY
New Research: Multifunction Printer (MFP) Security Concerns within the Enterprise Business Environment
Post Syndicated from Deral Heiland original https://www.rapid7.com/blog/post/new-research-multifunction-printer-mfp-security-concerns-within-the-enterprise-business-environment
Multifunction printers (MFPs) do far more than print. They scan, email, fax, store, and authenticate. That convenience comes with risk. Our latest report, Understanding Multifunction Printer (MFP) Security within the Enterprise Business Environment, from Rapid7’s Deral Heiland, Principal Security Researcher (IoT), and Sam Moses, Security Consultant, takes a clear look at where MFPs expand your attack surface and how to reduce that risk.
Why this research matters
MFPs are everywhere, often overlooked, and frequently underprotected. Many organizations deploy them without password changes, patch cycles, or network segmentation. Attackers notice. Because MFPs are attached to networks and can carry sensitive data, compromise can enable credential theft, data leakage, and lateral movement within the network.
The report tracks how long-standing and emerging weaknesses continue to affect MFP security. It highlights common risk areas such as weak authentication and limited patching practices, among others, that leave devices open to misuse or compromise. As these printers have grown more connected and feature-rich, the potential impact of a single vulnerable device has increased, especially when linked to core business systems or identity services.
The study also examines broader exposure trends across the enterprise landscape. Thousands of MFPs remain directly accessible from the internet, and vulnerability data shows that many models have faced serious flaws in recent years. Beyond technical issues, organizational processes like inconsistent patch management and poor decommissioning practices often allow sensitive data and credentials to linger on devices long after their use.
Penetration testing data collected by Rapid7 and Raxis confirms that these risks are not theoretical. Many organizations still deploy MFPs with default settings, leaving them open to credential theft and data access that can help attackers move deeper into the network.
The report introduces Praeda-II, a community tool designed for pentesters, auditors, and IT teams who need fast visibility into vulnerable printers, to identify risks in MFPs across modern models.
See the research
If your organization relies on networked printers, this research offers the insights you need. Read Understanding Multifunction Printer (MFP) Security within the Enterprise Business Environment to learn about key risks and practical steps to strengthen your printer security program.
Geopolitics and Cyber Risk: How Global Tensions Shape the Attack Surface
Post Syndicated from Jeremy Makowski original https://www.rapid7.com/blog/post/geopolitics-and-cyber-risk-how-global-tensions-shape-the-attack-surface
Geopolitics has become a significant risk factor for today’s organizations, transforming cybersecurity into a technical and strategic challenge heavily influenced by state behavior. International tensions and the strategic calculations of major cyber powers, including Russia, China, Iran, and North Korea, significantly shape the current threat landscape. Businesses can no longer operate as isolated entities; they now function as interconnected global ecosystems where employees, suppliers, cloud workloads, supply chains, and data flows intersect across multiple jurisdictions, each with its own unique set of political risks.
A region considered low-risk last month could become a high-risk zone overnight if a diplomatic dispute escalates. An overseas development team could suddenly become vulnerable if that region experiences sanctions, stricter regulations, or state pressure on the workforce.
Many organizations still underestimate this dynamic reality, relying on static risk models that assume relatively stable attack patterns. However, geopolitical decisions and internal vulnerabilities are often the drivers of the most sudden and consequential changes in exposure. For example, the announcement of sanctions can trigger retaliatory cyberattacks, a military buildup can unleash destructive campaigns, and a trade or intellectual property dispute can lead to large-scale espionage.
Cybersecurity leaders must therefore integrate geopolitical intelligence directly into their operational decision-making and risk assessment processes, recognizing that political forces, rather than technical errors, are often the primary trigger for increased vulnerability.
Geopolitics as a core driver of cyber risk
Geopolitics plays a decisive role in shaping the scale, direction, and sophistication of cybercriminal and state-sponsored activity, fundamentally altering the threat landscape for organizations worldwide. Geopolitical tensions and sanctions often create conditions in which state-aligned hackers operate with greater freedom, using cyber operations as tools for espionage, economic survival, political retaliation, or strategic influence. Isolated or sanctioned states often turn to cybercrime as an alternative source of revenue.
North Korea, for instance, intensifies financially motivated campaigns, including cryptocurrency theft and extortion, when economic pressure mounts. Iran, facing recurring sanctions and political isolation, tends to respond with retaliatory or disruptive cyber operations targeting sectors and institutions associated with adversarial nations.
China’s cyber activity often peaks during moments of heightened competition over technology and strategic resources, driving expansive espionage campaigns aimed at industries like aerospace, telecommunications, AI, and energy. Russia, meanwhile, escalates disruptive or destructive cyber actions during geopolitical confrontations or military conflicts, leveraging malware, industrial system interference, and coordinated information operations.
These patterns demonstrate how cyber risk extends far beyond technical vulnerabilities: organizations become targets because of their nationality, sector, technology assets, or global partnerships.
How geopolitical tensions influence threat actor behavior
Geopolitical tensions influence the behavior of threat actors by altering their objectives, aggression levels, and operational trade-offs in ways that directly impact global organizations. Russian groups, for example, will shift from covert intelligence collection to overt disruption, employing destructive malware, DDoS attacks, and infrastructure sabotage to exert pressure. Chinese actors are known to intensify long-term espionage and supply-chain infiltration, targeting IP, cloud providers, security firms, and development environments.
Iran responds to sanctions or regional tensions with opportunistic retaliation through data wiping, defacements, and financially motivated attacks. And when facing economic strain, North Korea expands cybercrime, including cryptocurrency theft, extortion, software supply-chain poisoning, and high-level financial fraud.
For organizations, these shifts manifest internally as newly observed attack patterns, such as targeted phishing aimed at political or strategic sectors, the exploitation of vulnerabilities relevant to conflicts, or supply-chain attacks aligned with espionage objectives. The unifying pattern is that geopolitical tensions cause attackers to reprioritize, whereby espionage becomes a means of destruction, revenue generation becomes a national strategy, and symbolic retaliation becomes an operational necessity. Security teams that do not account for these geopolitical triggers risk misjudging the scale, intent, and urgency of incoming threat campaigns.
Indicators that cyber escalation is coming
A cyber escalation is rarely an isolated phenomenon; it is usually accompanied by political and technical warning signs that can herald a wave of attacks. On the political front, organizations should monitor events such as sanctions announcements, diplomatic expulsions, military mobilizations, sudden breakdowns in negotiations, strategic military strikes, or public accusations of espionage. For example, tensions with Russia are often followed by cyber influence campaigns. Retaliatory cyberattacks are also common following the imposition of sanctions on the Islamic Republic of Iran. Increased cyber espionage campaigns coincide with periods of strategic competition with China, and financially motivated attacks intensify after economic pressure is exerted on North Korea.
On a technical level, the first warning signs manifest in one or more of the following ways:
- An increase in sector-specific phishing attacks linked to political events
- The reactivation of known command and control infrastructures
- The formation of new politically-motivated hacktivist collectives
- Access intermediaries launching campaigns to sell access points in sectors linked to ongoing conflicts
Internally, organizations may sometimes observe unusual activity from cybersecurity teams, such as unexpected code updates from maintenance managers located in politically sensitive regions, vendor outages correlated with geopolitical developments, or authentication anomalies linked to regions near ongoing crises. The most important pattern to recognize is convergence: when political escalation, external surveillance, and internal anomalies appear within the same time frame, organizations must assume that threat conditions have shifted from background noise to active risk and immediately adopt a strengthened defensive posture.
Adjusting defensive posture during geopolitical instability
Harden identity infrastructure against state-grade threats.
Identity has become a frontline asset in geopolitical conflict. In today’s environment, the boundaries between hacktivism, cybercrime, and state-sponsored activities are increasingly blurred, with governments at times guiding or amplifying these operations. Credential compromise is often the entry point that enables these broader campaigns. To mitigate this risk, organizations should enforce universal, phishing-resistant MFA, regularly review and tightly govern privileged roles, particularly in sensitive geographies, and adopt just-in-time access to minimize standing privileges. These measures materially reduce exposure and strengthen resilience against sophisticated, geopolitically motivated threat actors.
Conduct targeted threat hunts
- Russia — Russian threat actors place a strong emphasis on disruption and destruction, particularly during periods of geopolitical conflict. They commonly deploy wiper malware that deletes or corrupts files and often pretend it’s ransomware. Threat hunters should watch for sudden mass file changes, system reboots, or the use of admin-level command-line tools immediately preceding damage. Russia also has advanced capabilities for ICS/OT manipulation, meaning unusual access to industrial controllers or configuration changes can be a strong indicator of potential compromise. Additionally, their operations often support information warfare, so defenders should look for compromised media or government accounts, unauthorized website changes, and targeted spear-phishing attacks tied to political events.
- China — China focuses on long-term, stealthy access rather than quick disruption. They are known for supply-chain compromises, so unusual activity from vendor accounts or anomalies in software updates should be investigated. They frequently abuse cloud identity platforms, making it essential to monitor for impossible travel logins, token theft, MFA fatigue, or suspicious OAuth applications. Chinese groups also invest heavily in credential harvesting, often trying to quietly collect usernames, passwords, and tokens over long periods. Threat hunters should look for password spraying, attempts to dump credentials, or lateral movement linked to service or personal accounts that generally don’t access sensitive systems.
- Iran — Iranian threat actors tend to be opportunistic and politically reactive, relying heavily on broad phishing campaigns. Organizations should monitor for spikes in failed logins, newly created email forwarding rules, and look-alike phishing domains. Iran also frequently conducts website defacements, so signs such as unexpected CMS admin logins, unauthorized web content changes, or DNS tampering are essential to hunt for. While generally less sophisticated than Russia or China, they can still deploy destructive malware, meaning defenders should watch for scripts or tools that mass-delete or encrypt files, suspicious scheduled tasks, and activity involving commodity RATs or .NET tools.
- North Korea — North Korea’s cyber operations are primarily financially motivated, with a strong focus on cryptocurrency theft. Threat hunters should monitor for unauthorized access to wallet systems, unusual outbound connections to cryptocurrency platforms, or abnormal API calls associated with blockchain activity. They also excel at social engineering, especially targeting finance, HR, and engineering staff by posing as recruiters or job candidates. Indicators include suspicious attachments, communication from personal email accounts, or new “contractor” accounts accessing code or financial systems. Once inside a network, their activity is typically driven by exfiltration, so large or stealthy data transfers, especially to cloud storage or foreign VPNs, are significant warning signs.
Reprioritize assets exposed to geopolitical pressure.
Identify systems and identities that become high-value targets during periods of geopolitical tension, especially those associated with sensitive regions or government-linked operations. Immediately harden them with faster patching, tighter segmentation, stricter east–west controls, and increased telemetry to concentrate defenses where state-aligned actors are most likely to strike.
Reduce external exposure on high-value frontiers.
Reduce the attack surface by removing access paths favored by advanced adversaries. Disable legacy VPNs, retire unmonitored jump servers, tighten SSO/IdP trust paths, and eliminate unnecessary remote-admin or broad cloud access routes. Reducing weak entry points raises the cost of initial access for foreign intelligence units.
Harden response capabilities
Incident response teams must prepare for an increased likelihood of destructive or politically motivated attacks. Organizations should test their data destruction and destructive attack plans, validate their disaster recovery timelines, and ensure the restoration of offline or immutable backups. Management must be kept informed of evolving geopolitical risks, and cross-functional teams, including cybersecurity, legal, communications, and operations, must conduct crisis simulation exercises. Rapid response structures, such as crisis management teams, should be ready to be activated to facilitate fast decision-making under pressure. These measures are intended to help ensure that the organization can respond effectively even in the face of significant stress or disruption.
Building a geopolitical cyber attack surface map
Building a geopolitical map of the attack surface enables organizations to anticipate how political conditions may impact cyber risk. This involves understanding how people, technology, and third-party relationships are geographically distributed, and how those distributions intersect with jurisdictions that may impose legal, operational, or conflict-related risks. A robust map also integrates geopolitical assessments with business impact and criticality, enabling organizations to see where instability or state control could affect privileged access, essential services, or sensitive data.
The following steps describe how to perform an attack surface mapping based on geopolitical events. These steps are not derived from any single framework or source; they are a practical blend of best practices for mapping infrastructure, assessing geopolitical exposure, identifying weak points, and prioritizing remediation.
- Map Internal Workforce: Create an authoritative inventory of the physical locations of all employees with technical or elevated privileges. Include full-time staff, contractors, and outsourced teams. Use HR, IAM, and staffing records to ensure accuracy and maintain updates as personnel relocate or roles change.
-
Map Infrastructure: Create a comprehensive list of regions that host your cloud services, data centers, disaster recovery sites, and replication routes. Document which workloads reside where, how traffic moves between regions, and what operational responsibilities each location carries. Capture both primary and failover arrangements.
- Map Vendor & Subcontractor: This step requires suppliers to disclose the actual countries where engineering, customer support, managed services, and subcontracted tasks are performed. Validate this information through audits, questionnaires, or contractual obligations. Record each operational footprint, not just corporate registration locations.
- Geopolitical Risk Scores: Apply a standardized scoring model to each region (e.g., Matteo Iacoviello Geopolitical Risk (GPR) index, BlackRock Geopolitical Risk Indicator (BGRI), or Bloomberg’s geopolitical risk scores). Inputs may include government stability indicators, international sanctions status, regulatory pressures, history of state intervention, and exposure to espionage or cyber operations. Use a consistent scoring range.
- Overlay Business Criticality: Cross-reference each region’s risk score with the operational value of what that region supports. Identify where highly sensitive systems, privileged roles, or essential processes are located in areas with higher risk. Highlight areas where disruption would impact business continuity or security posture.
- Identify Regional Strategic Points: Look for dependencies where a single region hosts an excessive number of critical people, systems, or vendors. This includes cloud regions serving multiple core workloads, a subcontractor with a heavily centralized team, or a country where several key staff reside. Flag these for targeted risk discussions.
- Prioritize Remediation Measures: Develop a ranked set of actions based on the combined geopolitical and business impact. Potential responses include redistributing workloads across safer regions, shifting privileged roles, tightening access controls, enhancing monitoring for at-risk locations, or preparing contingency plans for rapid relocation or provider transition.
Conclusion
Geopolitics is now a key driver of cyber risk, redefining attacker profiles, motivations, and the organizations targeted and/or affected by collateral damage. Many vulnerabilities in modern businesses stem not from technical misconfigurations, but from the geopolitical interconnectedness of global supply chains, cloud architectures, distributed teams, and open-source ecosystems.
Traditional cybersecurity controls remain essential, but are insufficient on their own as they fail to account for laws, political incentives, national strategies, and human vulnerabilities influenced by the world’s most active cyber powers. To manage this reality, organizations must integrate geopolitical analysis into every layer of their security decision-making process, consider geography as a key security variable, and develop the agility to proactively adapt their posture to the evolving global context.
Celebrating the community: Irioluwa, Michelle, Jedidiah and Inioluwa
Post Syndicated from Sarah Lygoe original https://www.raspberrypi.org/blog/celebrating-the-community-irioluwa-michelle-jedidiah-and-inioluwa/
We love hearing from members of the community and sharing the stories of amazing young people, volunteers, and educators who are using their passion for technology to create positive change in the world around them.
In our latest story, we’re meeting a group of inspiring young innovators from Belfast — Michelle, 15, Inilouwa, 18, Jedidiah, 14 — and Irioluwa, 11, who are using their creativity and technical skills to tackle an issue that impacts millions of young women across the UK: period poverty.

The power of community
The group first connected through Diverse Youth, a community space that gave them the chance to collaborate, learn, and grow.
At the youth centre, the girls were introduced to Code Club through mentor, and Jedidiah’s mum, Tiwa. When Tiwa offered them the opportunity to travel to Coolest Projects UK and showcase projects they had been working on, they knew they wanted to make something special…

Tackling taboo topics
The idea for Flow Body began when Inilouwa was inspired by her sister’s experience at school.
“So, for me, it was my sister actually, that really inspired this project because she would tell me, her school at the time, they run out of period products very frequently, so not a lot of girls could access it.”
Wanting to make a difference, the team created Flow Body, a website connecting young women to period charities in the UK and providing reliable information about periods, puberty, and related health issues.
Playing to their strengths
The technical side of the project was led by Inilouwa, with the rest of her teammates supporting her with research and content creation.
“So, alongside Michelle, I researched the diseases and what can come from period poverty and how different people get by with the lack of period products around,” Jedidiah said.
Their research highlighted just how widespread period-related health issues are.
The team discovered that one of the biggest challenges is access to accurate information, given the stigma around discussing menstruation, and using technology to solve this issue seemed like the perfect fit to them.
Inilouwa explained, “Having that access to information that’s tailored to young women, to young parents, to everyone all across the board would be really helpful, you know, in order to make periods less of a strange topic to discuss.”

Celebrating teamwork
After taking home judges’ favourite in the web category, the girls could not recommend the experience enough. When asked what advice they would give to other young people thinking of taking the leap and entering Coolest Projects, the answer was simple…
“Do it. Don’t be afraid. Even if tech is not your thing, it’s not a lot of people’s things. But like you learn so much, you grow so much and it’s very fun. It is. It really is,” said Inilouwa.
If you are interested in getting involved in Coolest Projects, keep an eye on the website for exciting announcements for 2026 plans.
Want support on your coding journey? Find a Code Club near you to learn alongside a likeminded community.
The post Celebrating the community: Irioluwa, Michelle, Jedidiah and Inioluwa appeared first on Raspberry Pi Foundation.
Theodore Roosevelt’s Nobel Peace Prize
Post Syndicated from The History Guy: History Deserves to Be Remembered original https://www.youtube.com/shorts/Ton44l2XBQA