Cloudflare outage on February 20, 2026

Post Syndicated from David Tuber original https://blog.cloudflare.com/cloudflare-outage-february-20-2026/

On February 20, 2026, at 17:48 UTC, Cloudflare experienced a service outage when a subset of customers who use Cloudflare’s Bring Your Own IP (BYOIP) service saw their routes to the Internet withdrawn via Border Gateway Protocol (BGP).

The issue was not caused, directly or indirectly, by a cyberattack or malicious activity of any kind. This issue was caused by a change that Cloudflare made to how our network manages IP addresses onboarded through the BYOIP pipeline. This change caused Cloudflare to unintentionally withdraw customer prefixes.

For some BYOIP customers, this resulted in their services and applications being unreachable from the Internet, causing timeouts and failures to connect across their Cloudflare deployments that used BYOIP. A subset of 1.1.1.1, specifically our destination one.one.one.one, was also impacted. The total duration of the incident was 6 hours and 7 minutes with most of that time spent restoring prefix configurations to their state prior to the change.

Cloudflare engineers reverted the change and prefixes stopped being withdrawn when we began to observe failures. However, before engineers were able to revert the change, ~1,100 BYOIP prefixes were withdrawn from the Cloudflare network. Some customers were able to restore their own service by using the Cloudflare dashboard to re-advertise their IP addresses. We resolved the incident when we restored all prefix configurations.

We are sorry for the impact to our customers. We let you down today. This post is an in-depth recounting of exactly what happened and which systems and processes failed. We will also outline the steps we are taking to prevent outages like this from happening again.

How did the outage impact customers?

This graph shows the amount of prefixes advertised by Cloudflare during the incident to a BGP neighbor, which correlates to impact as prefixes that weren’t advertised were unreachable on the Internet:


Out of the total 6,500 prefixes advertised to this peer, 4,306 of those were BYOIP prefixes. These BYOIP prefixes are advertised to every peer and represent all the BYOIP prefixes we advertise globally. 

During the incident, 1,100 prefixes out of the total 6,500 were withdrawn from 17:56 to 18:46 UTC. Out of the 4,306 total BYOIP prefixes, 25% of BYOIP prefixes were unintentionally withdrawn. We were able to detect impact on one.one.one.one and revert the impacting change before more prefixes were impacted. At 19:19 UTC, we published guidance to customers that they would be able to self-remediate this incident by going to the Cloudflare dashboard and re-advertising their prefixes.

Cloudflare was able to revert many of the advertisement changes around 20:20 UTC, which caused 800 prefixes to be restored. There were still ~300 prefixes that were unable to be remediated through the dashboard because the service configurations for those prefixes were removed from the edge due to a software bug. These prefixes were manually restored by Cloudflare engineers at 23:03 UTC. 

This incident did not impact all BYOIP customers because the configuration change was applied iteratively and not instantaneously across all BYOIP customers. Once the configuration change was revealed to be causing impact, the change was reverted before all customers were affected. 

The impacted BYOIP customers first experienced a behavior called BGP Path Hunting. In this state, end user connections traverse networks trying to find a route to the destination IP. This behavior will persist until the connection that was opened times out and fails. Until the prefix is advertised somewhere, customers will continue to see this failure mode. This loop-until-failure scenario affected any product that uses BYOIP for advertisement to the Internet. One.one.one.one, which is a subset of 1.1.1.1, is a prefix onboarded as a BYOIP prefix, and was impacted in this manner. This prefix, which was Cloudflare-maintained but using our own products, allowed us to detect this issue quickly. A full breakdown of the services impacted is below.

Service/Product Impact Description
Core CDN and Security Services Traffic was not attracted to Cloudflare, and users connecting to websites advertised on those ranges would have seen failures to connect
Spectrum Spectrum apps on BYOIP failed to proxy traffic due to traffic not being attracted to Cloudflare
Dedicated Egress Customers who used Gateway Dedicated Egress leveraging BYOIP or Dedicated IPs for CDN Egress leveraging BYOIP would not have been able to send traffic out to their destinations
Magic Transit End users connecting to applications protected by Magic Transit would not have been advertised on the Internet, and would have seen connection timeouts and failures

There was also a set of customers who were unable to restore service by toggling the prefixes on the Cloudflare dashboard. As engineers began reannouncing prefixes to restore service for these customers, these customers may have seen increased latency and failures despite their IP addresses being advertised. This was because the addressing settings for some users were removed from edge servers due an issue in our own software, and the state had to be propagated back to the edge. 

We’re going to get into what exactly broke in our addressing system, but to do that we need to cover a quick primer on the Addressing API, which is the underlying source of truth for customer IP addresses at Cloudflare.

Cloudflare’s Addressing API

The Addressing API is an authoritative dataset of the addresses present on the Cloudflare network. Any change to that dataset is immediately reflected in Cloudflare’s global network. While we are in the process of improving how these systems roll out changes as a part of Code Orange: Fail Small, today customers can configure their IP addresses by interacting with public-facing APIs which configure a set of databases that trigger operational workflows propagating the changes to Cloudflare’s edge. This means that changes to the Addressing API are immediately propagated to the Cloudflare edge.

Advertising and configuring IP addresses on Cloudflare involves several steps:

  • Customers signal to Cloudflare about advertisement/withdrawal of IP addresses via the Addressing API or BGP Control

  • The Addressing API instructs the machines to change the prefix advertisements

  • BGP will be updated on the routers once enough machines have received the notification to update the prefix

  • Finally, customers can configure Cloudflare products to use BYOIP addresses via service bindings which will assign products to these ranges

The Addressing API allows us to automate most of the processes surrounding how we advertise or withdraw addresses, but some processes still require manual actions. These manual processes are risky because of their close proximity to Production. As a part of Code Orange: Fail Small, one of the goals of remediation was to remove manual actions taken in the Addressing API and replace them with safe workflows.

How did the incident occur?

The specific piece of configuration that broke was a modification attempting to automate the customer action of removing prefixes from Cloudflare’s BYOIP service, a regular customer request that is done manually today. Removing this manual process was part of our Code Orange: Fail Small work to push all change towards safe, automated, health-mediated deployment. Since the list of related objects of BYOIP prefixes can be large, this was implemented as part of a regularly running sub-task that checks for BYOIP prefixes that should be removed, and then removes them. Unfortunately, this regular cleanup sub-task queried the API with a bug.

Here is the API query from the cleanup sub-task:

 resp, err := d.doRequest(ctx, http.MethodGet, `/v1/prefixes?pending_delete`, nil)

And here is the relevant part of the API implementation:

	if v := req.URL.Query().Get("pending_delete"); v != "" {
		// ignore other behavior and fetch pending objects from the ip_prefixes_deleted table
		prefixes, err := c.RO().IPPrefixes().FetchPrefixesPendingDeletion(ctx)
		if err != nil {
			api.RenderError(ctx, w, ErrInternalError)
			return
		}

		api.Render(ctx, w, http.StatusOK, renderIPPrefixAPIResponse(prefixes, nil))
		return
	}

Because the client is passing pending_delete with no value, the result of Query().Get(“pending_delete”) here will be an empty string (“”), so the API server interprets this as a request for all BYOIP prefixes instead of just those prefixes that were supposed to be removed. The system interpreted this as all returned prefixes being queued for deletion. The new sub-task then began systematically deleting all BYOIP prefixes and all of their related dependent objects including service bindings, until the impact was noticed, and an engineer identified the sub-task and shut it down.

Why did Cloudflare not catch the bug in our staging environment or testing?

Our staging environment contains data that matches Production as closely as possible, but was not sufficient in this case and the mock data we relied on to simulate what would occur was insufficient.

In addition, while we have tests for this functionality, coverage for this scenario in our testing process and environment was incomplete. Initial testing and code review focused on the BYOIP self-service API journey and were completed successfully. While our engineers successfully tested the exact process a customer would have followed, testing did not cover a scenario where the task-runner service would independently execute changes to user data without explicit input.

Why was recovery not immediate?

Affected BYOIP prefixes were not all impacted in the same way, necessitating more intensive data recovery steps. As a part of Code Orange: Fail Small, we are building a system where operational state snapshots can be safely rolled out through health-mediated deployments. In the event something does roll out that causes unexpected behavior, it can be very quickly rolled back to a known-good state. However, that system is not in Production today.

BYOIP prefixes were in different states of impact during this incident, and each of these different states required different actions:

  • Most impacted customers only had their prefixes withdrawn. Customers in this configuration could go into the dashboard and toggle their advertisements, which would restore service. 

  • Some customers had their prefixes withdrawn and some bindings removed. These customers were in a partial state of recovery where they could toggle some prefixes but not others.

  • Some customers had their prefixes withdrawn and all service bindings removed. They could not toggle their prefixes in the dashboard because there was no service (Magic Transit, Spectrum, CDN) bound to them. These customers took the longest to mitigate, as a global configuration update had to be initiated to reapply the service bindings for all these customers to every single machine on Cloudflare’s edge.

How does this incident relate to Code Orange: Fail Small?

The change we were making when this incident occurred is part of the Code Orange: Fail Small initiative, which is aimed at improving the resiliency of code and configuration at Cloudflare. As a brief primer of the Code Orange: Fail Small initiatives, the work can be divided into three buckets:

  • Require controlled rollouts for any configuration change that is propagated to the network, just like we do today for software binary releases.

  • Change our internal “break glass” procedures and remove any circular dependencies so that we, and our customers, can act fast and access all systems without issue during an incident.

  • Review, improve, and test failure modes of all systems handling network traffic to ensure they exhibit well-defined behavior under all conditions, including unexpected error states.

The change that we attempted to deploy falls under the first bucket. By moving risky, manual changes to safe, automated configuration updates that are deployed in a health-mediated manner, we aim to improve the reliability of the service.

Critical work was already ongoing to enhance the Addressing API’s configuration change support through staged test mediation and better correctness checks. This work was ongoing in parallel with the deployed change. Although preventative measures weren’t fully deployed before the outage, teams were actively working on these systems when the incident occurred. Following our Code Orange: Fail Small promise to require controlled rollouts of any change into Production, our engineering teams have been reaching deep into all layers of our stack to identify and fix all problematic findings. While this outage wasn’t itself global, the blast radius and impact were unacceptably large, further reinforcing Code Orange: Fail Small as a priority until we have re-established confidence in all changes to our network being as gradual as possible. Now let’s talk more specifically about improvements to these systems.

Remediation and follow-up steps

API schema standardization

One of the issues in this incident is that the pending_delete flag was interpreted as a string, making it difficult for both client and server to rationalize the value of the flag. We will improve the API schema to ensure better standardization, which will make it much easier for testing and systems to validate whether an API call is properly formed or not. This work is part of the third Code Orange workstream, which aims to create well-defined behavior under all conditions.

Better separation between operational and configured state

Today, customers make changes to the addressing schema that are persisted in an authoritative database, and that database is the same one used for operational actions. This makes manual rollback processes more challenging because engineers need to utilize database snapshots instead of rationalizing between desired and actual states. We will redesign the rollback mechanism and database configuration to ensure that we have an easy way to roll back changes quickly and also to introduce layers between customer configuration and Production.

We will snap shot the data that we read from the database and are applying to Production, and apply those snapshots in the same way that we deploy all our other Production changes, mediated by health metrics that can automatically stop the deployment if things are going wrong. This means that the next time we have a problem where the database gets changed into a bad state, we can near-instantly revert individual customers (or all customers) to a version that was working.

While this will temporarily block our customers from being able to make direct updates via our API in the event of an outage, it will mean that we can continue serving their traffic while we work to fix the database, instead of being down for that time. This work aligns with the first and second Code Orange workstreams, which involves fast rollback and also safe, health-mediated deployment of configuration.

Better arbitrate large withdrawal actions

We will improve our monitoring to detect when changes are happening too fast or too broadly, such as withdrawing or deleting BGP prefixes quickly, and disable the deployment of snapshots when this happens. This will form a type of circuit breaker to stop any out-of-control process that is manipulating the database from having a large blast radius, like we saw in this incident.

We also have some ongoing work to directly monitor that the services run by our customers are behaving correctly, and those signals can also be used to trip the circuit breaker and stop potentially dangerous changes from being applied until we have had time to investigate. This work aligns with the first Code Orange workstream, which involves safe deployment of changes.

Below is the timeline of events inclusive of deployment of the change and remediation steps:

Time (UTC) Status Description
2026-02-05 21:53 Code merged into system Broken sub-process merged into code base
2026-02-20 17:46 Code deployed into system Address API release with broken sub-process completes
2026-02-20 17:56 Impact Start Broken sub-process begins executing. Prefix advertisement updates begin propagating and prefixes begin to be withdrawn – IMPACT STARTS –
2026-02-20 18:13 Cloudflare engaged Cloudflare engaged for failures on one.one.one.one
2026-02-20 18:18 Internal incident declared Cloudflare engineers continue investigating impact
2026-02-20 18:21 Addressing API team paged Engineering team responsible for Addressing API engaged and debugging begins
2026-02-20 18:46 Issue identified Broken sub-process terminated by an engineer and regular execution disabled; remediation begins
2026-02-20 19:11 Mitigation begins Cloudflare Engineers begin to restore serviceability for prefixes that were withdrawn while others focused on prefixes that were removed
2026-02-20 19:19 Some prefixes mitigated Customers begin to re-advertise their prefixes via the dashboard to restore service. – IMPACT DOWNGRADE –
2026-02-20 19:44 Additional mitigation continues Engineers begin database recovery methods for removed prefixes
2026-02-20 20:30 Final mitigation process begins Engineers complete release to restore withdrawn prefixes that still have existing service bindings. Others are still working on removed prefixes – IMPACT DOWNGRADE –
2026-02-20 21:08 Configuration update deploys Engineering begins global machine configuration rollout to restore prefixes that were not self-mitigated or mitigated via previous efforts – IMPACT DOWNGRADE –
2026-02-20 23:03 Configuration update completed Global machine configuration deployment to restore remaining prefixes is completed. – IMPACT ENDS –

We deeply apologize for this incident today and how it affected the service we provide our customers, and also the Internet at large. We aim to provide a network that is resilient to change, and we did not deliver on our promise to you. We are actively making these improvements to ensure improved stability moving forward and to prevent this problem from happening again.

Metasploit Wrap-Up 02/20/2026

Post Syndicated from Diego Ledda original https://www.rapid7.com/blog/post/pt-metasploit-wrap-up-02-20-2026

Hacking Churches and Backdooring Emacs

This release packs some solid exploit module additions! Two new unauthenticated RCE modules are a major win: the StoryChief WordPress plugin exploit (CVE-2025-7441) targets a webhook validation flaw allowing arbitrary file uploads, while the ChurchCRM exploit (CVE-2025-62521) abuses the installation wizard to inject PHP code for persistent access. Both establish Meterpreter sessions. On the persistence front, there’s a creative Emacs extension module that plants malicious Lisp code for shell callbacks whenever Emacs launches; a fun take on an unconventional attack surface. Along with Emacs, a new Windows persistence using the old, gold registry; this time the UserInit one, to get Administrator shells when any user logs in. To wrap-up, now you can spread automation nightmares with the new n8n auxiliary module, allowing you to extract sessions of other logged users (even admins).

New module content (5)

n8n arbitrary file read

Authors: dor attias and msutovsky-r7

Type: Auxiliary

Pull request: #20856 contributed by msutovsky-r7

Path: gather/ni8mare_cve_2026_21858

Description: This adds an exploit module for n8n. The vulnerability, known as Ni8mare, allows arbitrary file read and session extraction of other users allowing privilege escalation on the WebApp context.

Emacs Extension Persistence

Author: h00die

Type: Exploit

Pull request: #20919 contributed by h00die

Path: linux/persistence/emacs_extension

Description: This adds a persistence module compatible with emacs for Linux, the emacs extension will trigger a session creation as the compromised user.

ChurchCRM Unauthenticated RCE 6.8.0

Author: LucasCsmt

Type: Exploit

Pull request: #20947 contributed by LucasCsmt

Path: multi/http/churchcrm_install_unauth_rce

AttackerKB reference: CVE-2025-62521

Description: This PR adds a new exploit module for CVE-2025-62521, targeting an unauthenticated Remote Code Execution (RCE) vulnerability in ChurchCRM versions 6.8.0 and earlier.

WordPress StoryChief Plugin Unauthenticated RCE

Authors: Nayera and xpl0dec

Type: Exploit

Pull request: #20976 contributed by Nayeraneru

Path: multi/http/wp_plugin_story_chef_file_upload

AttackerKB reference: CVE-2025-7441

Description: Adds a new exploit module targeting CVE-2025-7441, an unauthenticated RCE in the WordPress plugin StoryChief versions <= 1.0.45.

Windows Registry Persistence via Userinit

Authors: h00die and joel

Type: Exploit

Pull request: #20844 contributed by 6a6f656c

Path: windows/persistence/registry_userinit

Description: This adds a persistence module for Windows. Using the UserInit registry key the target machine will create a session with Admin privileges every time any user logs in.

Enhancements and features (2)

  • #20807 from webbsssss – Allow Acunetix vulnerabilities to be imported without complete web page data.
  • #20969 from sjanusz-r7 – Updates Metasploit’s logic when importing Acunetix XML files to now also include items that are less than High severity.

Bugs fixed (1)

  • #20972 from adfoster-r7 – Fixes false positives on lg simple editor check methods.

Documentation

You can find the latest Metasploit documentation on our docsite at docs.metasploit.com.

Get it

As always, you can update to the latest Metasploit Framework with msfupdate and you can get more details on the changes since the last blog post from GitHub:

If you are a git user, you can clone the Metasploit Framework repo (master branch) for the latest. To install fresh without using git, you can use the open-source-only Nightly Installers or the commercial edition Metasploit Pro

AI-augmented threat actor accesses FortiGate devices at scale

Post Syndicated from CJ Moses original https://aws.amazon.com/blogs/security/ai-augmented-threat-actor-accesses-fortigate-devices-at-scale/

Commercial AI services are enabling even unsophisticated threat actors to conduct cyberattacks at scale—a trend Amazon Threat Intelligence has been tracking closely. A recent investigation illustrates this shift: Amazon Threat Intelligence observed a Russian-speaking financially motivated threat actor leveraging multiple commercial generative AI services to compromise over 600 FortiGate devices across more than 55 countries from January 11 to February 18, 2026. No exploitation of FortiGate vulnerabilities was observed—instead, this campaign succeeded by exploiting exposed management ports and weak credentials with single-factor authentication, fundamental security gaps that AI helped an unsophisticated actor exploit at scale. This activity is distinguished by the threat actor’s use of multiple commercial GenAI services to implement and scale well-known attack techniques throughout every phase of their operations, despite their limited technical capabilities. AWS infrastructure was not observed to be involved in this campaign. Amazon Threat Intelligence is sharing these findings to help the broader security community defend against this activity.

This investigation highlights how commercial AI services can lower the technical barrier to entry for offensive cyber capabilities. The threat actor in this campaign is not known to be associated with any advanced persistent threat group with state-sponsored resources. They are likely a financially motivated individual or small group who, through AI augmentation, achieved an operational scale that would have previously required a significantly larger and more skilled team. Yet, based on our analysis of public sources, they successfully compromised multiple organizations’ Active Directory environments, extracted complete credential databases, and targeted backup infrastructure, a potential precursor to ransomware deployment. Notably, when this actor encountered hardened environments or more sophisticated defensive measures, they simply moved on to softer targets rather than persisting, underscoring that their advantage lies in AI-augmented efficiency and scale, not in deeper technical skill.

As we expect this trend to continue in 2026, organizations should anticipate that AI-augmented threat activity will continue to grow in volume from both skilled and unskilled adversaries. Strong defensive fundamentals remain the most effective countermeasure: patch management for perimeter devices, credential hygiene, network segmentation, and robust detection for post-exploitation indicators.

Campaign overview

Through routine threat intelligence operations, Amazon Threat Intelligence identified infrastructure hosting malicious tooling associated with this campaign. The threat actor had staged additional operational files on the same publicly accessible infrastructure, including AI-generated attack plans, victim configurations, and source code for custom tooling. This inadequate operational security provided comprehensive visibility into the threat actor’s methodologies and the specific ways they leverage AI throughout their operations. It’s like an AI-powered assembly line for cybercrime, helping less skilled workers produce at scale.

The threat actor compromised globally dispersed FortiGate appliances, extracting full device configurations that yielded credentials, network topology information, and device configuration information. They then used these stolen credentials to connect to victim internal networks and conduct post-exploitation activities including Active Directory compromise, credential harvesting, and attempts to access backup infrastructure, consistent with pre-ransomware operations.

Initial access: Mass credential abuse

The threat actor’s initial access vector was credential-based access to FortiGate management interfaces exposed to the internet. Analysis of the actor’s tooling supported systematic scanning for management interfaces across ports 443, 8443, 10443, and 4443, followed by authentication attempts using commonly reused credentials.

FortiGate configuration files represent high-value targets because they contain:

  • SSL-VPN user credentials with recoverable passwords
  • Administrative credentials
  • Complete network topology and routing information
  • Firewall policies revealing internal architecture
  • IPsec VPN peer configurations

The threat actor developed AI-assisted Python scripts to parse, decrypt, and organize these stolen configurations.

Geographic distribution

The campaign’s targeting appears opportunistic rather than sector-specific, consistent with automated mass scanning for vulnerable appliances. However, certain patterns suggest organizational-level compromise where multiple FortiGate devices belonging to the same entity were accessed. Amazon Threat Intelligence observed clusters where contiguous IP blocks or shared non-standard management ports indicated managed service provider deployments or large organizational networks. Concentrations of compromised devices were observed across South Asia, Latin America, the Caribbean, West Africa, Northern Europe, and Southeast Asia, among other regions.

Custom tooling: AI-generated reconnaissance framework

Following VPN access to victim networks, the threat actor deploys a custom reconnaissance tool, with different versions written in both Go and Python. Analysis of the source code reveals clear indicators of AI-assisted development: redundant comments that merely restate function names, simplistic architecture with disproportionate investment in formatting over functionality, naive JSON parsing via string matching rather than proper deserialization, and compatibility shims for language built-ins with empty documentation stubs. While functional for the threat actor’s specific use case, the tooling lacks robustness and fails under edge cases—characteristics typical of AI-generated code used without significant refinement.

The tool automates the post-VPN reconnaissance workflow:

  1. Ingesting target networks from VPN routing tables
  2. Classifying networks by size
  3. Running service discovery using gogo, an open-source port scanner
  4. Automatically identifying SMB hosts and domain controllers
  5. Integrating vulnerability scanning using Nuclei, an open-source vulnerability scanner, against discovered HTTP services to produce prioritized target lists.

Post-exploitation methodology

Once inside victim networks, the threat actor follows a standard approach leveraging well-known open-source offensive tools.

Domain compromise: The threat actor’s operational documentation details the intended use of Meterpreter, an open-source post-exploitation toolkit, with the mimikatz module to perform DCSync attacks against domain controllers. This allowed the actor to extract NTLM password hashes from Active Directory. In confirmed compromises, the attacker obtained complete domain credential databases. In at least one case, the Domain Administrator account used a plaintext password that was either extracted from the FortiGate configuration through password reuse or was independently weak.

Lateral movement: Following domain compromise, the threat actor attempts to expand access through pass-the-hash/pass-the-ticket attacks against additional infrastructure, NTLM relay attacks using standard poisoning tools, and remote command execution on Windows hosts.

Backup infrastructure targeting: The threat actor specifically targeted Veeam Backup & Replication servers, deploying multiple tools for extracting credentials, including PowerShell scripts, compiled decryption tools, and exploitation attempts leveraging known Veeam vulnerabilities. Backup servers represent high-value targets because they typically store elevated credentials for backup operations, and compromising backup infrastructure positions an attacker to destroy recovery capabilities before deploying ransomware.

Limited exploitation success: The threat actor’s operational notes reference multiple CVEs across various targets (CVE-2019-7192, CVE-2023-27532, and CVE-2024-40711, among others). However, a critical finding from this analysis is that the threat actor largely failed when attempting to exploit anything beyond the most straightforward, automated attack paths. Their own documentation records repeated failures: targeted services were patched, required ports were closed, vulnerabilities didn’t apply to the target OS versions, . Their final operational assessment for one confirmed victim acknowledged that key infrastructure targets were “well-protected” with “no vulnerable exploitation vectors.”

AI as a force multiplier

Amazon Threat Intelligence analysis revealed that the actor uses at least two distinct commercial LLM providers throughout their operations.

AI-generated attack planning: The threat actor used AI to generate comprehensive attack methodologies complete with step-by-step exploitation instructions, expected success rates, time estimates, and prioritized task trees. These plans reference academic research on offensive AI agents, suggesting the actor follows emerging literature on AI-assisted penetration testing. The AI produces technically accurate command sequences, but the actor struggles to adapt when conditions differ from the plan. They cannot compile custom exploits, debug failed exploitation attempts, or creatively pivot when standard approaches fail.

Multi-model operational workflow: Amazon Threat Intelligence identified the actor using multiple AI services in complementary roles. One serves as the primary tool developer, attack planner, and operational assistant. A second is used as a supplementary attack planner when the actor needs help pivoting within a specific compromised network. In one observed instance, the actor submitted the complete internal topology of an active victim—IP addresses, hostnames, confirmed credentials, and identified services—and requested a step-by-step plan to compromise additional systems they could not access with their existing tools.

AI-generated tooling at scale: Beyond the reconnaissance framework, the actor’s infrastructure contains numerous scripts in multiple programming languages bearing hallmarks of AI generation, including configuration parsers, credential extraction tools, VPN connection automation, mass scanning orchestration, and result aggregation dashboards. The volume and variety of custom tooling would typically indicate a well-resourced development team. Instead, a single actor or very small group generated this entire toolkit through AI-assisted development.

Threat actor assessment

Based on comprehensive analysis, Amazon Threat Intelligence assesses this threat actor as follows:

  • Motivation: Suspected financially motivated, based on widespread, indiscriminate targeting and low sophistication
  • Language: Russian-speaking, based on extensive Russian-language operational documentation
  • Skill level: Low-to-medium baseline technical capability, significantly augmented by AI. The actor can run standard offensive tools and automate routine tasks but struggles with exploit compilation, custom development, and creative problem-solving during live operations
  • AI dependency: Extensive reliance across all operational phases. AI is used for tool development, attack planning, command generation, and operational reporting across multiple commercial LLM providers
  • Operational scale: Broad. Compromised devices across dozens of countries, with evidence of sustained operations over an extended period
  • Post-exploitation depth: Shallow. Repeated failures against hardened or non-standard targets, with a pattern of moving on rather than persisting when automated approaches fail
  • Operational security: Inadequate. Detailed operational plans, credentials, and victim data stored without encryption alongside tooling

Amazon’s response

Amazon Threat Intelligence remains committed to helping protect customers and the broader internet ecosystem by actively investigating and disrupting threat actors.

Upon discovering this campaign, Amazon Threat Intelligence took the following actions:

  • Shared actionable intelligence, including indicators of compromise, with relevant partners
  • Collaborated with industry partners to broaden visibility into the campaign and support coordinated defense efforts

Through these efforts, Amazon helped reduce the threat actor’s operational effectiveness and enabled organizations across multiple countries to take steps to disrupt the efficacy of the campaign.

Defending your organization

This campaign succeeded through a combination of exposed management interfaces, weak credentials, and single-factor authentication—all fundamental security gaps that AI helped an unsophisticated actor exploit at scale. This underscores that strong security fundamentals are powerful defenses against AI-augmented threats. Organizations should review and implement the following.

1. FortiGate appliance audit

Organizations running FortiGate appliances should take immediate action:

  • Ensure management interfaces are not exposed to the internet. If remote administration is required, restrict access to known IP ranges and use a bastion host or out-of-band management network
  • Change all default and common credentials on FortiGate appliances, including administrative and VPN user accounts
  • Rotate all SSL-VPN user credentials, particularly for any appliance whose management interface was or may have been internet-accessible
  • Implement multi-factor authentication for all administrative and VPN access
  • Review FortiGate configurations for unauthorized administrative accounts or policy changes
  • Audit VPN connection logs for connections from unexpected geographic locations

2. Credential hygiene

Given the extraction of credentials from FortiGate configurations:

  • Audit for password reuse between FortiGate VPN credentials and Active Directory domain accounts
  • Implement multi-factor authentication for all VPN access
  • Enforce unique, complex passwords for all accounts, particularly Domain Administrator accounts
  • Review and rotate service account credentials, especially those used in backup infrastructure

3. Post-exploitation detection

Organizations that may have been affected should monitor for:

  • Unexpected DCSync operations (Event ID 4662 with replication-related GUIDs)
  • New scheduled tasks named to mimic legitimate Windows services
  • Unusual remote management connections from VPN address pools
  • LLMNR/NBT-NS poisoning artifacts in network traffic
  • Unauthorized access to backup credential stores
  • New accounts with names designed to blend with legitimate service accounts

4. Backup infrastructure hardening

The threat actor’s focus on backup infrastructure highlights the importance of:

  • Isolating backup servers from general network access
  • Patching backup software against known credential extraction vulnerabilities
  • Monitoring for unauthorized PowerShell module loading on backup servers
  • Implementing immutable backup copies that cannot be modified even with administrative access

AWS-specific recommendations

For organizations using AWS:

  • Enable Amazon GuardDuty for threat detection, including monitoring for unusual API calls and credential usage patterns
  • Use Amazon Inspector to automatically scan for software vulnerabilities and unintended network exposure
  • Use AWS Security Hub to maintain continuous visibility into your security posture
  • Use AWS Systems Manager Patch Manager to maintain patching compliance across EC2 instances running network appliances
  • Review IAM access patterns for signs of credential replay following any suspected network device compromise

Indicators of compromise (IOCs)

This campaign’s reliance on legitimate open-source tools—including Impacket, gogo, Nuclei, and others—means that traditional IOC-based detection has limited effectiveness. These tools are widely used by penetration testers and security professionals, and their presence alone is not indicative of compromise. Organizations should investigate context around matches, prioritizing behavioral detection (anomalous VPN authentication patterns, unexpected Active Directory replication, lateral movement from VPN address pools) over signature-based approaches.

IOC Value

IOC Type

First Seen

Last Seen

Annotation

212[.]11.64.250

IPv4

1/11/2026

2/18/2026

Threat actor infrastructure used for scanning and exploitation operations

185[.]196.11.225

IPv4

1/11/2026

2/18/2026

Threat actor infrastructure used for threat operations


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

CJ Moses

CJ Moses

CJ Moses is the CISO of Amazon Integrated Security. In his role, CJ leads security engineering and operations across Amazon. His mission is to enable Amazon businesses by making the benefits of security the path of least resistance. CJ joined Amazon in December 2007, holding various roles including Consumer CISO, and most recently AWS CISO, before becoming CISO of Amazon Integrated Security September of 2023.

Prior to joining Amazon, CJ led the technical analysis of computer and network intrusion efforts at the Federal Bureau of Investigation’s Cyber Division. CJ also served as a Special Agent with the Air Force Office of Special Investigations (AFOSI). CJ led several computer intrusion investigations seen as foundational to the security industry today.

CJ holds degrees in Computer Science and Criminal Justice, and is an active SRO GT America GT2 race car driver.

Избори за Народно събрание 2026 – какво знаем и какво не за гласуването в чужбина

Post Syndicated from Боян Юруков original https://yurukov.net/blog/2026/izbori-2026-dati/

На 19-ти април 2026 ще се проведат избори за Народно събрание. Ето най-важното към този момент.

Все още не е публикуван електронният формуляр за заявление за гласуване. Очакваме го в следващите дни, когато ще изпратя мейл с нужната информация на всички абонирали се в Glasvuam.org. Разбираме от хронограмата на ЦИК, че срокът на подаване е 24-ти март. В последните 10 години времето за подаване на заявления варира от 17 дни на изборите през 2023-та до 28 дни през октомври 2024 и април 2021-ва. Това значи, че може да очакваме да пуснат формуляра между 24 февруари и 7-ми март. Както и на предишни избори, събирането на заявления ще се следи в реално време на карта на Glasuvam.org.

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

До 27-ми февруари ще бъдат обявени и местата в чужбина, където в последните пет години е имало поне 100 гласували. Това ще включва 6-те вота между юли 2021-ва до сега. От това дали сегашния парламент ще потвърди отново промените в Избирателния кодекс зависи на кои от тях ще има секции. Отделно някои държави като Германия трябва изрично да дадат съгласие за досегашните места. Тук подаването на заявления отново ще е от значние, защото от една страна ще даде сведение на МВнР за местата, където има интерес, а от друга – ще бъде повод да се отварят повече секции на едно и също място предвид повишения интерес.

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

Повече информация ще намерите на сайта на ЦИК и МВнР. Условията и редът за създаване на секции, провеждане на изборния ден и незабавните задачи пред посолствата и МВнР ще намерите в решението на ЦИК от 19-ти февруари.

Ако желаете да получавате такава полезна информация за изборите в чужбина, може да се абонирате на Glasuvam.org.

Hacktivism and the Winter Olympics 2026: What We’re Seeing and What it Signals

Post Syndicated from Emma Burdett original https://www.rapid7.com/blog/post/it-hacktivism-winter-olympics-2026

The 2026 Winter Olympics have been live for several weeks, and the cyber activity many predicted is already unfolding.

Threat intelligence reporting from Intel471 highlights a surge in hacktivist chatter and mobilization tied to protests and geopolitical tensions surrounding the Games. At the same time, Google’s Threat Intelligence Group has warned that hacktivists, state actors, and cybercriminal groups are actively targeting the global defense industry, including organizations that overlap with Olympic infrastructure and supply chains. This is not a coincidence. Major global events concentrate visibility, political symbolism, and digital dependency. That combination attracts actors who want attention as much as disruption.

What is hacktivism in 2026?

Hacktivism today is ideologically motivated cyber activity designed to influence perception, apply pressure, or advance political narratives, often through disruption, data leaks, or public messaging. Recent reporting shows that hacktivist groups are not operating in isolation. In some cases, their campaigns run alongside state-aligned or criminal activity. The targeting of defense contractors, aerospace suppliers, and industrial entities reflects this convergence.

During the Olympics, those same sectors intersect with event logistics, telecommunications, aviation, energy, and security technology.

What has happened since the Winter Games began?

According to Intel471, online communities aligned with hacktivist causes have escalated messaging and operational coordination in the lead-up to and during the Winter Games. Threat actors have referenced Olympic-related targets in forums and social channels, including infrastructure tied to transportation and sponsors.

SecurityWeek and OODA Loop, citing Google’s intelligence, note continued targeting of defense industry entities through phishing and exploitation of exposed services. While not every campaign is explicitly labeled “Olympics-related,” the overlap in sectors matters.

Defense contractors often provide technology, logistics, surveillance, or communications capabilities that support major international events. Attacks against them, even if framed around geopolitical grievances, can have ripple effects.

The pattern is consistent: high-visibility events amplify the impact of even limited cyber incidents.

Why global events amplify hacktivist activity

The Olympics function as a global amplifier. Billions are watching, media cycles move faster, and political narratives are intensified. In that environment, even relatively low-complexity attacks can produce outsized consequences. A distributed denial-of-service campaign against a broadcaster can interrupt coverage at a critical moment. A data leak involving a sponsor can dominate headlines for days. A website defacement tied to a political cause can circulate globally within minutes. In many cases, the objective is not technical devastation but psychological and reputational impact. Undermining confidence in organizers or projecting instability can advance the strategic goals of ideologically aligned groups without requiring sophisticated or destructive techniques.

What security teams should focus on, now and in the future

With the Games underway, the priority is not speculation. It is monitoring and preparedness. Security leaders supporting global events should:

  • Review third-party dependencies that connect to core event operations

  • Increase monitoring of public-facing systems during peak broadcast windows

  • Track hacktivist messaging that references sponsors, infrastructure, or host nations

  • Ensure executive and communications teams are aligned on rapid response planning

The risk is not confined to stadium control systems. It spans broadcasters, payment providers, logistics partners, and digital platforms. High-visibility events attract ideologically motivated actors, but they also create opportunities for financially driven cybercrime. As we’ve previously examined in our research on carding-as-a-service and stolen credit card fraud, periods of high transaction volume often coincide with increased fraud activity and exploitation of payment infrastructure.

Security leaders should prepare for both disruption and monetization. While hacktivist activity may generate headlines, financial exploitation often causes quieter but longer-lasting operational damage.

Hacktivism in 2026: A warning for high-visibility events

The Winter Olympics provide a live case study in how hacktivism operates within today’s geopolitical environment. Threat actors understand timing. They understand symbolism. They understand that a small disruption during a global event carries disproportionate weight.

The activity seen so far reinforces a broader shift. Hacktivism has matured into a persistent and visible component of the threat landscape. It intersects with state and criminal ecosystems and targets sectors that carry political and economic symbolism.

For organizations tied to high-visibility events, the lesson is clear. Cyber risk during global moments is not only technical – it is reputational, geopolitical, and amplified by attention and preparation must account for all three.

[$] Open-source Discord alternatives

Post Syndicated from daroc original https://lwn.net/Articles/1058319/

The closed-source chat platform Discord

announced
on February 9 that it would soon require some users to verify their
ages in order to access some content — although the company quickly

added
that
the “vast majority” of users would not have to. That reassurance has to
contend with the fact that the UK and other countries are implementing
increasingly strict age requirements for social media. Discord’s age
verification would be done with an AI age-judging
model or with a government photo ID. A surprising number of open-source
projects use Discord for support or project communications, and some of those
projects are now looking for open-source alternatives. Mastodon, for example,

has moved discussion to Zulip
. There are some alternatives out there, all
with their own pros and cons, that communities may want to consider if they want
to switch away from Discord.

Security updates for Friday

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

Security updates have been issued by AlmaLinux (grafana), Debian (gegl, inetutils, libvpx, nova, and python-django), Fedora (azure-cli, chromium, microcode_ctl, python-azure-core, python3.14, and roundcubemail), Red Hat (grafana and osbuild-composer), SUSE (apptainer, dnsdist, istioctl, libsoup, openCryptoki, python-nltk, python311, python313, rclone, and thunderbird), and Ubuntu (libvpx, linux-azure, linux-azure-5.4, linux-azure-fips, and linux-intel-iotg).

Code Mode: give agents an entire API in 1,000 tokens

Post Syndicated from Matt Carey original https://blog.cloudflare.com/code-mode-mcp/

Model Context Protocol (MCP) has become the standard way for AI agents to use external tools. But there is a tension at its core: agents need many tools to do useful work, yet every tool added fills the model’s context window, leaving less room for the actual task.

Code Mode is a technique we first introduced for reducing context window usage during agent tool use. Instead of describing every operation as a separate tool, let the model write code against a typed SDK and execute the code safely in a Dynamic Worker Loader. The code acts as a compact plan. The model can explore tool operations, compose multiple calls, and return just the data it needs. Anthropic independently explored the same pattern in their Code Execution with MCP post.

Today we are introducing a new MCP server for the entire Cloudflare API — from DNS and Zero Trust to Workers and R2 — that uses Code Mode. With just two tools, search() and execute(), the server is able to provide access to the entire Cloudflare API over MCP, while consuming only around 1,000 tokens. The footprint stays fixed, no matter how many API endpoints exist.

For a large API like the Cloudflare API, Code Mode reduces the number of input tokens used by 99.9%. An equivalent MCP server without Code Mode would consume 1.17 million tokens — more than the entire context window of the most advanced foundation models.


Code mode savings vs native MCP, measured with tiktoken

You can start using this new Cloudflare MCP server today. And we are also open-sourcing a new Code Mode SDK in the Cloudflare Agents SDK, so you can use the same approach in your own MCP servers and AI Agents.

Server‑side Code Mode


This new MCP server applies Code Mode server-side. Instead of thousands of tools, the server exports just two: search() and execute(). Both are powered by Code Mode. Here is the full tool surface area that gets loaded into the model context:

[
  {
    "name": "search",
    "description": "Search the Cloudflare OpenAPI spec. All $refs are pre-resolved inline.",
    "inputSchema": {
      "type": "object",
      "properties": {
        "code": {
          "type": "string",
          "description": "JavaScript async arrow function to search the OpenAPI spec"
        }
      },
      "required": ["code"]
    }
  },
  {
    "name": "execute",
    "description": "Execute JavaScript code against the Cloudflare API.",
    "inputSchema": {
      "type": "object",
      "properties": {
        "code": {
          "type": "string",
          "description": "JavaScript async arrow function to execute"
        }
      },
      "required": ["code"]
    }
  }
]

To discover what it can do, the agent calls search(). It writes JavaScript against a typed representation of the OpenAPI spec. The agent can filter endpoints by product, path, tags, or any other metadata and narrow thousands of endpoints to the handful it needs. The full OpenAPI spec never enters the model context. The agent only interacts with it through code.

When the agent is ready to act, it calls execute(). The agent writes code that can make Cloudflare API requests, handle pagination, check responses, and chain operations together in a single execution. 

Both tools run the generated code inside a Dynamic Worker isolate — a lightweight V8 sandbox with no file system, no environment variables to leak through prompt injection and external fetches disabled by default. Outbound requests can be explicitly controlled with outbound fetch handlers when needed.

Example: Protecting an origin from DDoS attacks

Suppose a user tells their agent: “protect my origin from DDoS attacks.” The agent’s first step is to consult documentation. It might call the Cloudflare Docs MCP Server, use a Cloudflare Skill, or search the web directly. From the docs it learns: put Cloudflare WAF and DDoS protection rules in front of the origin.

Step 1: Search for the right endpoints
The search tool gives the model a spec object: the full Cloudflare OpenAPI spec with all $refs pre-resolved. The model writes JavaScript against it. Here the agent looks for WAF and ruleset endpoints on a zone:

async () => {
  const results = [];
  for (const [path, methods] of Object.entries(spec.paths)) {
    if (path.includes('/zones/') &&
        (path.includes('firewall/waf') || path.includes('rulesets'))) {
      for (const [method, op] of Object.entries(methods)) {
        results.push({ method: method.toUpperCase(), path, summary: op.summary });
      }
    }
  }
  return results;
}

The server runs this code in a Workers isolate and returns:

[
  { "method": "GET",    "path": "/zones/{zone_id}/firewall/waf/packages",              "summary": "List WAF packages" },
  { "method": "PATCH",  "path": "/zones/{zone_id}/firewall/waf/packages/{package_id}", "summary": "Update a WAF package" },
  { "method": "GET",    "path": "/zones/{zone_id}/firewall/waf/packages/{package_id}/rules", "summary": "List WAF rules" },
  { "method": "PATCH",  "path": "/zones/{zone_id}/firewall/waf/packages/{package_id}/rules/{rule_id}", "summary": "Update a WAF rule" },
  { "method": "GET",    "path": "/zones/{zone_id}/rulesets",                           "summary": "List zone rulesets" },
  { "method": "POST",   "path": "/zones/{zone_id}/rulesets",                           "summary": "Create a zone ruleset" },
  { "method": "GET",    "path": "/zones/{zone_id}/rulesets/phases/{ruleset_phase}/entrypoint", "summary": "Get a zone entry point ruleset" },
  { "method": "PUT",    "path": "/zones/{zone_id}/rulesets/phases/{ruleset_phase}/entrypoint", "summary": "Update a zone entry point ruleset" },
  { "method": "POST",   "path": "/zones/{zone_id}/rulesets/{ruleset_id}/rules",        "summary": "Create a zone ruleset rule" },
  { "method": "PATCH",  "path": "/zones/{zone_id}/rulesets/{ruleset_id}/rules/{rule_id}", "summary": "Update a zone ruleset rule" }
]

The full Cloudflare API spec has over 2,500 endpoints. The model narrowed that to the WAF and ruleset endpoints it needs, without any of the spec entering the context window. 

The model can also drill into a specific endpoint’s schema before calling it. Here it inspects what phases are available on zone rulesets:

async () => {
  const op = spec.paths['/zones/{zone_id}/rulesets']?.get;
  const items = op?.responses?.['200']?.content?.['application/json']?.schema;
  // Walk the schema to find the phase enum
  const props = items?.allOf?.[1]?.properties?.result?.items?.allOf?.[1]?.properties;
  return { phases: props?.phase?.enum };
}

{
  "phases": [
    "ddos_l4", "ddos_l7",
    "http_request_firewall_custom", "http_request_firewall_managed",
    "http_response_firewall_managed", "http_ratelimit",
    "http_request_redirect", "http_request_transform",
    "magic_transit", "magic_transit_managed"
  ]
}

The agent now knows the exact phases it needs: ddos_l7 for DDoS protection and http_request_firewall_managed for WAF.

Step 2: Act on the API
The agent switches to using execute. The sandbox gets a cloudflare.request() client that can make authenticated calls to the Cloudflare API. First the agent checks what rulesets already exist on the zone:

async () => {
  const response = await cloudflare.request({
    method: "GET",
    path: `/zones/${zoneId}/rulesets`
  });
  return response.result.map(rs => ({
    name: rs.name, phase: rs.phase, kind: rs.kind
  }));
}

[
  { "name": "DDoS L7",          "phase": "ddos_l7",                        "kind": "managed" },
  { "name": "Cloudflare Managed","phase": "http_request_firewall_managed", "kind": "managed" },
  { "name": "Custom rules",     "phase": "http_request_firewall_custom",   "kind": "zone" }
]

The agent sees that managed DDoS and WAF rulesets already exist. It can now chain calls to inspect their rules and update sensitivity levels in a single execution:

async () => {
  // Get the current DDoS L7 entrypoint ruleset
  const ddos = await cloudflare.request({
    method: "GET",
    path: `/zones/${zoneId}/rulesets/phases/ddos_l7/entrypoint`
  });

  // Get the WAF managed ruleset
  const waf = await cloudflare.request({
    method: "GET",
    path: `/zones/${zoneId}/rulesets/phases/http_request_firewall_managed/entrypoint`
  });
}

This entire operation, from searching the spec and inspecting a schema to listing rulesets and fetching DDoS and WAF configurations, took four tool calls.

The Cloudflare MCP server

We started with MCP servers for individual products. Want an agent that manages DNS? Add the DNS MCP server. Want Workers logs? Add the Workers Observability MCP server. Each server exported a fixed set of tools that mapped to API operations. This worked when the tool set was small, but the Cloudflare API has over 2,500 endpoints. No collection of hand-maintained servers could keep up.

The Cloudflare MCP server simplifies this. Two tools, roughly 1,000 tokens, and coverage of every endpoint in the API. When we add new products, the same search() and execute() code paths discover and call them — no new tool definitions, no new MCP servers. It even has support for the GraphQL Analytics API.

Our MCP server is built on the latest MCP specifications. It is OAuth 2.1 compliant, using Workers OAuth Provider to downscope the token to selected permissions approved by the user when connecting. The agent  only gets the capabilities the user explicitly granted. 

For developers, this means you can use a simple agent loop and still give your agent access to the full Cloudflare API with built-in progressive capability discovery.


Comparing approaches to context reduction

Several approaches have emerged to reduce how many tokens MCP tools consume:

Client-side Code Mode was our first experiment. The model writes TypeScript against typed SDKs and runs it in a Dynamic Worker Loader on the client. The tradeoff is that it requires the agent to ship with secure sandbox access. Code Mode is implemented in Goose and Anthropics Claude SDK as Programmatic Tool Calling.

Command-line interfaces are another path. CLIs are self-documenting and reveal capabilities as the agent explores. Tools like OpenClaw and Moltworker convert MCP servers into CLIs using MCPorter to give agents progressive disclosure. The limitation is obvious: the agent needs a shell, which not every environment provides and which introduces a much broader attack surface than a sandboxed isolate.

Dynamic tool search, as used by Anthropic in Claude Code, surfaces a smaller set of tools hopefully relevant to the current task. It shrinks context use but now requires a search function that must be maintained and evaluated, and each matched tool still uses tokens.


Each approach solves a real problem. But for MCP servers specifically, server-side Code Mode combines their strengths: fixed token cost regardless of API size, no modifications needed on the agent side, progressive discovery built in, and safe execution inside a sandboxed isolate. The agent just calls two tools with code. Everything else happens on the server.

Get started today

The Cloudflare MCP server is available now. Point your MCP client at the server URL and you’ll be redirected to Cloudflare to authorize and select the permissions to grant to your agent. Add this config to your MCP client: 

{
  "mcpServers": {
    "cloudflare-api": {
      "url": "https://mcp.cloudflare.com/mcp"
    }
  }
}

For CI/CD, automation, or if you prefer managing tokens yourself, create a Cloudflare API token with the permissions you need. Both user tokens and account tokens are supported and can be passed as bearer tokens in the Authorization header.

More information on different MCP setup configurations can be found at the Cloudflare MCP repository.

Looking forward

Code Mode solves context costs for a single API. But agents rarely talk to one service. A developer’s agent might need the Cloudflare API alongside GitHub, a database, and an internal docs server. Each additional MCP server brings the same context window pressure we started with.

Cloudflare MCP Server Portals let you compose multiple MCP servers behind a single gateway with unified auth and access control. We are building a first-class Code Mode integration for all your MCP servers, and exposing them to agents with built-in progressive discovery and the same fixed-token footprint, regardless of how many services sit behind the gateway.

Боят настана

Post Syndicated from Емилия Милчева original https://www.toest.bg/boyat-nastana/

Боят настана

Тринайсетото служебно правителство, което е с премиер Андрей Гюров, изглежда толкова добре, че мнозина се размечтаха да е редовно. Скроено по изпитаната сватбена традиция – нещо старо, нещо ново, нещо назаем и нещо синьо, засега е трудно да се прецени кое е в повече – старото, новото или синьото. 

В разцвета на „мечтите“ на втория ден последва оставката на вицепремиера Стоил Цицелков, назначен като гарант за честни избори.

Още в деня на клетвата на кабинета „Гюров“ в парламента Цицелков беше компрометиран с информация, огласена от доскорошни във властта. „Има такъв народ“ съобщиха, под формата на въпрос, че Цицелков е бил задържан три пъти: заради шофиране в нетрезво състояние и притежание на марихуана. Като по поръчка последва справка от МВР, публикувана в близък до Пеевски сайт. Данните показват, че към днешна дата той е реабилитиран за шофиране с 1,5 промила алкохол в кръвта. Присъдата на Софийския районен съд е от 23 септември 2014 г. по НОХД №15691/11 г. Наказанието е било пробация.

Провиненията му за марихуана са свързани с проверки заради пушене, когато в него били открити съответно 15 грама и 55 грама. 

В удара срещу Цицелков, чиято биография е тясно свързана с НПО сектора, се включи и лидерът на ГЕРБ Бойко Борисов. 

Ако е вярно, че „министърът за честни избори“ Стоил Цицелков има забрана от Европейската комисия да припарва като наблюдател на избори в чужбина, никой няма да приеме изборите за честни! Цялата отговорност за това назначение е на Гюров и на Йотова.

Тук се визира случай от 2020 г. Твърди се, че като наблюдател на изборите в Гана Цицелков предизвикал „инцидент с жена в хотелска стая“, заради което Европейската комисия му наложила 5-годишна забрана да участва в мисии на ЕС.

След оставката на вицепремиера Борисов натърти още веднъж, че „това е огромен пропуск и Йотова няма как да се оправдае“.

Самият Цицелков нито потвърди, нито отрече информацията. Той заяви, че това е атака срещу кабинета.

Политиката трябва да е поле на идеи и действия, а не лов на хора, незаконно използване на архиви. Моето свидетелство за съдимост е чисто, както и моята съвест. Честните избори са по-важни от всеки един човек. Това е една кауза, за която се боря повече от 20 години.

Срещу никое служебно правителство не е водена такава ожесточена кампания не просто от първия му ден, а отпреди това с насочване на „Петрохангейт“ като гранатомет към ПП–ДБ. Ясен знак, че кампанията за предстоящите на 19 април парламентарни избори ще бъде яростна и особено кална. 

Целта е прозрачна – спад на избирателната активност и поредна доза омерзение, че „всички са едни и същи маскари“. 

Кръв, порно, политика
Това, което дават по новините, е белег за нещо отдавна случващо се под носа ни: умишления отказ на институциите да си вършат работата. Коментар на Емилия Милчева.
Боят настана

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

А правителството на Гюров е точно такова, каквото поискаха излезлите по улиците на България хора – срещу Борисов/Пеевски. Това дава надежди за презареждане на протестната енергия, спаднала и/или преляла се в сочения за победител Румен Радев заради ескалацията на трагедията с шестте трупа на Петрохан–Околчица.

Андрей Гюров беше съвсем ясен в парламента: 

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

Чие е правителството – на ПП–ДБ, повече на ДБ, отколкото на ПП, – вече няма значение. И неуспехите, и успехите ще са коалиционно споделени. Амбициите са свързани, освен с основната задача за честни избори, и с подготвяне на нов удължителен бюджет, справедливо разпределение на средствата за общините, опит за избор на нов и.ф. главен прокурор, нови областни управители и шефове на дирекции на МВР. 

Фигурите в кабинета обаче бяха изтълкувани като опит за бъдеща следизборна коалиция между формацията на Румен Радев, ПП–ДБ, отломки от ДПС и новия гражданско-политически съюз между „Единение“ (чийто лидер Иван Христанов бе избран за земеделски министър), „Зелено движение“, „Средна европейска класа“ и „Ние идваме“.

Въпреки че самият Радев критикува в социалните мрежи:

Сглобката отстрани президентската институция от съставянето на служебно правителство. Резултата го виждаме днес: един служебен кабинет с ярко изразени партийни и политически ангажирани лица.

Военен министър назаем

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

Само преди две седмици Съветът на ЕС даде зелена светлина за финансирането за отбрана по линия на SAFE за осем държави членки на ЕС, сред които и България. Това решение означава 3,2 млрд. евро за българската армия, като преди това страната представи национален план за отбрана до 2030 г. Първите траншове се очакват още тази година. 

Сред най-важните проекти в българската инвестиционна програма са закупуване на модерни 3D радари, системи за противовъздушна и противоракетна отбрана, 155-милиметрови артилерийски системи и боеприпаси, технологии за противодействие на дронове, ракетни системи и способности за залпов огън, както и нова транспортна и логистична военна техника. Включени са също проекти за безпилотни летателни апарати, които да разширят разузнавателните и оперативните способности на армията. 

Започнаха и доставки на бронирани машини Stryker от САЩ – близо 200, които ще бъдат сглобявани и частично адаптирани в държавния завод „ТЕРЕМ–Ивайло“ във Велико Търново. Това ще засили мобилността на сухопътните войски и ще модернизира механизираните формирования.

Служебният кабинет трябва да управлява процесите по модернизирането на българската армия в условията на растящо напрежение в Близкия изток, и по-специално в Иран. Затова е и запазен Запрянов, въпреки известната му гравитация около ГЕРБ. Бойко Борисов хвърли светлина по темата, като съобщи, че Гюров официално се е обърнал към ГЕРБ заради Запрянов.

Считам, че беше държавническо, тъй като и министър Запрянов винаги е бил експерт при нас. Той винаги е бил в отбраната като експерт на ГЕРБ и като такъв се е държал. Затова мисля, че ГЕРБ може да поеме отговорност за министър Запрянов в този кабинет. Поискано е официално, официално сме се съгласили.

МВР и правосъдие, или как зам.-министрите стават министри

Нищо не подсказва по-добре принадлежността на кабинета от това кой държи ключовите МВР и Министерството на правосъдието – наказателният съдия Емил Дечев и бившият прокурор Андрей Янкулов. Двамата са били заместник-министри на правосъдието, номинации на „Да, България“ (част от „Демократична България“). 

Промяна в кабинета на главния прокурор и честни избори са и част от исканията на многохилядните протести от края на миналата година. Задачите на Дечев и Янкулов надхвърлят обичайните задължения на служебни министри, защото действията им ще са от значение и за предизборната кампания.

Янкулов вече действа – той свика заседание на Висшия съдебен съвет с искане за определяне на временно и.ф. главен прокурор на мястото на Борислав Сарафов.

Дали ще успее, предвид факта, че през седмицата прокурорската колегия на ВСС единодушно подкрепи за главен прокурор на София Емилия Русинова, която досега беше временно изпълняваща тази функция? Нейното име беше замесено в аферата „Осемте джуджета“ – схема за търговия с влияние в съдебната система. Сега Янкулов иска от същата прокурорска колегия да отстрани наставника на Русинова?

Доган, или мост към българските турци?

Нямаше как да останат незабелязани министрите на социалната политика и на транспорта заради връзката им с ДПС и Ахмед Доган. За първи път от злополучния кабинет на Пламен Орешарски (ДПС–БСП) през 2013–2014 г. ДПС е представено официално и нескрито в правителство – ясен сигнал за турските избиратели, прелели се към силната ръка в ДПС на Делян Пеевски.

Д-р Хасан Адемов, ветеран в политиката, дълги години депутат от ДПС, но известен със своята почтеност, става министър на социалната политика. Сфера, в която има безспорна експертност. Рискът от социално напрежение в предизборния период расте и задачата на Адемов е да осигури спокойствие.

Корман Исмаилов, бившият лидер на младежкото ДПС, напуска Движението през 2011 г. заедно със заместника на Доган Касим Дал. По-късно двамата създават Народна партия „Свобода и достойнство“. Днес Исмаилов оглавява Министерството на транспорта и съобщенията. 

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

Кметове в изпълнителната власт

Ключовият пост на министър на финансите е поверен на Георги Клисурски, доскоро заместник-кмет по финансите в Столичната община. Любопитното е, че през юни 2025 г. той подаде оставка от „Продължаваме промяната“ с пост във Facebook: 

Напускам ПП. Разочарован и омерзен.

Причината беше арестът на заместник-кмета Никола Барбутов, обвинен в корупционни престъпления, и последвалата оставка на съпредседателя на ПП Кирил Петков.

Клисурски беше зам.-министър на финансите в кабинета на Николай Денков (ПП–ДБ) и съветник на вицепремиера по европейските фондове и министър на финансите Асен Василев в правителството на Кирил Петков. 

Той зае поста в Столичната община, след като предишният заместник-кмет Иван Василев напуска в края на юли 2025 г., за да се присъедини към Румен Радев.

Министър на енергетиката е Трайчо Трайков, доскоро кмет на столичния район „Средец“. Трайков заемаше този пост в първото правителство на Бойко Борисов, но беше освободен и на негово място дойде Делян Добрев. 

Формално той беше „сготвен“ с „плажа в Катар“ – случай от март 2011 г., при който беше обвинен, че се е пекъл на плаж, докато е трябвало да бъде на форум с бизнесмени от емирството. Тогава лидерът на ГЕРБ и премиер отрече Трайков да е бил отстранен заради острата си позиция срещу АЕЦ „Белене“.

Но причината за освобождаването му през 2011 г. беше именно АЕЦ „Белене“ и подписаното от шефа на НЕК Красимир Първанов допълнение №12 за АЕЦ „Белене“, макар да не е имал разрешение да го прави. Резултатът е, че на българската държава ѝ се наложи да плати над 600 млн. евро за двата реактора на „Белене“, чието строителство така и не започна. 

Тогава Трайков заяви, че 

руският натиск понякога е по-силен от способността на някои хора, призвани да защитават националния интерес, да му се противопоставят.

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

Тодор Тодоров: „Проектът за АЕЦ „Белене“ няма за цел да се построи централата, а да се източва бюджетът“
Темата за АЕЦ „Белене“ периодично се връща във фокуса на общественото внимание. В началото на седмицата стана известно, че според ЕК такава тема няма, доколкото България въобще не е започнала нужната…
Боят настана

Надежда за Външно

Четвърт век след като оглавяваше дипломацията, когато България получи покана за членство в ЕС, Надежда Нейнски се завръща в Министерството на външните работи. Ще ѝ помагат изпитани дипломати от кариерата – Марин Райков, който е бил и служебен премиер, и Ради Найденов.

България е постигнала големите си цели, но в последните години имаше особено слаби първи дипломати. Тази година трябва най-сетне да приключи процедурата за членство в Организацията за икономическо сътрудничество и развитие (ОИСР), към която България се стреми от почти 20 години.

Нови, но не съвсем

Повечето министри в кабинета на Андрей Гюров имат административен опит. Професор Сергей Игнатов беше образователен министър в първия кабинет на ГЕРБ. Министърът на културата Найден Тодоров също има опит от служебни кабинети, а Михаил Околийски – на здравеопазването, е бил заместник-министър от ПП. Също опит, но като началник-кабинет на екоминистри в две служебни правителства, има Мария Недина. Тя е вицепремиер по европейските фондове и нейната висока позиция буди недоумение предвид скромния опит, освен ако не броят поста ѝ на съветник на бившия вицепремиер Атанас Пеканов. 

Безспорно попадение за министър на регионалното развитие и благоустройството е Ангелина Бонева, възпитаничка на „Оксфорд“. Цялата ѝ кариера е свързана с политиките, финансирани със средства от ЕС.

След трагедията на Петрохан протестната енергия и общественото доверие някак се сринаха. Но сякаш получиха своя шанс при обявяването на служебния кабинет. И последва ударът с компрометирането на вицепремиера за честни избори. От това ще спечели новият кандидат-спасител.

На второ четене: „Нощта на професор Андершен“

Post Syndicated from original https://www.toest.bg/na-vtoro-chetene-noshtta-na-profesor-andershen/

„Нощта на професор Андершен“ от Даг Сулста

На второ четене: „Нощта на професор Андершен“

превод от норвежки Стефка Кожухарова, София: изд. „Аквариус“, 2023

Когато в малките часове преди Коледа професор Андершен става свидетел на убийство в апартамент срещу своя, пред него има две възможности: веднага да се обади в полицията или… да не го направи. Още на първите страници, в спокойната Бъдни вечер на един самотен и застаряващ преподавател по литература, Даг Сулста внася тази достойна за роман на Достоевски дилема. Дилема, която обаче, вместо да се разгърне остро и драматично и да изведе към някакво решение, постепенно спихва и потъва в плаващите пясъци на интелектуалното отнасяне, моралното шикалкавене, свръхаргументацията, убегливите разсъждения и снобското вторачване в какви ли не странични, но възприемани като изключително важни към момента „проблеми“.

Неволното свидетелство на убийство е утвърден сюжет – нека да споменем само класика като „Страничен прозорец“ на Хичкок. „Нощта на професор Андершен“ обаче не може да се чете като трилър, нито пък нещо в нея носи noir атмосфера. Напротив, в типичен за автора стил, познат ни и от романа му „Т. Сингер“, Сулста подхожда с фина ирония, наративен минимализъм и умишлено дразнещи повторения и отклонения, за да създаде неусетно (докато ние наивно чакаме да разберем кой и дали в действителност е убиецът, какви са мотивите му и какво ще стане с жертвата) една безмилостна дисекция на интелектуалната и морална парализа. И така

бездействието, мекушавостта, уклончивостта и безкрайните рационализации се превръщат в действителното „престъпление“.

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

Нещо повече: в процеса на възбудено „обмисляне“ и „следене“ на ситуацията професор Андершен не само ще рационализира еднократното убийство, ами дори ще се сближи с убиеца (без да ни се дава отговор дали той наистина е такъв – но това е тема за отделен анализ). Вътрешното му съпротивление да го издаде ще се окаже не само страх или малодушие, а и форма на вече почти импотентна съпротива срещу „обществото като огромна движеща сила“ в нас и в действията ни. Или на „състрадание отвъд всякакви граници“ и емпатия дори към един престъпник, с когото героят се споява в бинарна двойка:

Убиецът е жив и трябва да продължи да живее. Както и аз […] Защо не искам да изчезне от живота ми? Защо се опасявам, че ще изчезне от живота ми?

В крайна сметка професор Андершен ще реши, че „не може да подаде сигнал за непоправимото“.

В романа си Сулста, един от големите норвежки писатели от следвоенния период, ни пренася в края на ХХ век, в интелектуалните среди (приятелите и колегите на героя), съзрели през 60-те и 70-те години, израснали с революционните (предимно леви) идеи, с политическия радикализъм и всички негови жалони и съответно с модерното авангардно изкуство. Личности, които са се възприемали като „различни“ от мнозинството – и парадоксално тъкмо заради това са били възприети като изразяващи духа на поколението си (а в този смисъл – за типични). В гостуванията си при тях след убийството професор Андершен ще се окаже неспособен да сподели случилото се – първоначалният му порив ще бъде заглушен в един снобски тинитус. В крайна сметка ще видим как всички те са се превърнали в отрицанието си – в хора, заемащи престижни културно-интелектуални позиции, и в доволни потребители на презираната някога консуматорска култура. В конформисти, които надълго и нашироко могат да спорят за подходящото съчетание на определени храни, за произхода на виното или за друга някаква „насъщна“ незначителност в уютното им благоденствие.

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

На второ четене: „Нощта на професор Андершен“

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

Ще си позволя тук да оставя един малко по-дълъг цитат преди края:

Отношението ни към миналото е белязано от дълбоко безразличие, макар да твърдим друго и макар да сме сериозни, когато казваме, че в миналото се съдържат непреходни ценности. […] Нервите ни надават писъци на ужас при мисълта, че вече нямаме историческо съзнание, тъй като това означава, че нашето време ще изчезне заедно с нас, а когато поставяме Ибсен в Националния театър, нервите ни се успокояват, защото си мислим, че щом можем да поставим пиеса от миналия век в една от най-изящните сгради в страната, пред широката публика и често пред пълен салон, то е възможно идните поколения да имат същото отношение и към нас. Но ние не поставяме пиесите на Ибсен, а славата на Ибсен. Към самата пиеса малко или много проявяваме безразличие, да, така е, и то сега, едва стотина години след написването ѝ. […] Защото коремът ми се свива при мисълта, че никоя слава не е толкова голяма, че да трае сто години. Иска ни се да оставим безсмъртни произведения, но има ли такива за нас? Най-добрите пиеси на Ибсен са едва на сто години, казваме, че са вечни, но наистина ли са такива? […] Понякога, след като съм прочел и разучил например „Призраци“, се случва да си помисля: Аха, това ли беше всичко? Няма ли още нещо? Това ли е най-върховото постижение на осемдесетте години на миналия век, това ли е най-върховото интелектуално постижение в Европа през деветнайсети век? Със сигурност е добро, но все пак това ли е най-забележителното произведение, създадено досега? Оказва се, че е това, но въпросът ми си остава: Това ли беше всичко? Няма ли още нещо?

И тези размисли, и съзнанието за безполезността и непреподаваемостта на натрупания опит в крайна сметка преливат в усещането на професор Андершен за „бавната заключителна драма, която се разиграва в почти пълен застой“ току на прага на житейския край. И може би накрая – иронично и парадоксално – ще трябва май да се опровергаем: изглежда, метафизичното все пак изяде дребнотемието и тривиалното. Защото какво е просто някакво си убийство на фона на всичко това?


Никой от нас не чете единствено най-новите книги. Тогава защо само за тях се пише? „На второ четене“ е рубрика, в която отваряме списъците с книги, публикувани преди поне година, четем ги и препоръчваме любимите си от тях. За нея медията „Тоест“ е отличена с Националната награда „Христо Г. Данов“ (2025) за принос в представянето на българската книга.

Рубриката е част от партньорската програма Читателски клуб „Тоест“, благодарение на която активните дарители на „Тоест“ получават 20% отстъпка от коричната цена на всички книги на включените издателства. Изборът на заглавия обаче е единствено на авторите Стефан Иванов, Севда Семер и Антония Апостолова, които биха ви препоръчали тези книги и ако имаше как да се разходите с тях в книжарницата. 

Т.Е. от Е.Т. – епизод 41

Post Syndicated from Тоест original https://www.toest.bg/t-e-ot-e-t-epizod-41/

Т.Е. от Е.Т. – епизод 41

Топприоритет на служебното правителство ще са честните избори, а пък БНТ щяло да има нов директор. Всичко звучи като от „Приключенията на Лукчо“.


Следете видеорубриката на Елена Телбис за „Тоест“ и във Facebook, Instagram и TikTok.

The collective thoughts of the interwebz