Infrastructure and storage modernization trends 2026

AI may be driving infrastructure investment, but storage architecture increasingly determines application performance. Our new article examines six infrastructure and storage trends shaping enterprise IT in 2026.

Enterprise storage demand keeps climbing. Infrastructure budgets aren’t. That tension defines 2026. IDC expects AI infrastructure spending to hit  $487 billion, while Flexera reports organizations estimate 29% of their cloud spend is wasted. Record investment on one side, waste on the other. Instead of replacing entire environments wholesale, IT teams now evaluate every workload on its own merits.

 

 

Figure 1. Key infrastructure and storage modernization trends shaping enterprise IT in 2026.

 

AI demand is reshaping storage and memory economics

Most AI discussions fixate on GPUs, but storage is usually the actual bottleneck. A training cluster connected to an aging NAS won’t keep expensive accelerators busy – throughput and metadata operations can’t feed them fast enough. GPU utilization drops. Doesn’t matter how powerful the compute hardware is if the storage layer can’t keep pace.

AI demand is reshaping the memory market too. IDC projects the semiconductor market to exceed $1.29 trillion in 2026, with DRAM revenue approaching $418.6 billion as hyperscalers keep investing in high-bandwidth memory (HBM). That’s expected to tighten parts of the memory supply chain and push up the cost of some server configurations, which makes extending the life of existing hardware more attractive than a traditional refresh cycle. But not every AI workload needs the same storage architecture.

Large training clusters and high-throughput inference pipelines benefit from a parallel file system like DataCore Nexus, which provides parallel access to AI and HPC datasets – but smaller deployments and inference-only environments usually don’t need that level of complexity. A well-configured NVMe array or standard NAS often delivers everything they require. Match the storage to the workload’s actual I/O pattern. Don’t over-engineer it.

Modernization is becoming selective

Organizations are getting pickier about hardware refreshes. Better server longevity and firmer component pricing mean many existing systems still deliver acceptable performance. Instead of rip-and-replace, IT teams retire what’s become expensive to operate, keep what still provides value, and pool storage resources so applications aren’t tied to individual servers.

The math only works while the platform stays supported, secure, and cheaper to run than replacing it. Premium maintenance contracts, rising operational costs, depreciation schedules, and limited staff all factor into when that calculation flips. There’s no universal answer – it depends on the specific environment.

Software-defined storage makes these decisions easier because storage services become independent of the underlying hardware. You don’t have to replace storage every time servers reach end of life. Organizations pool capacity across SAN, DAS, HCI, and JBOD environments and migrate workloads with minimal disruption. That flexibility means you can refresh compute and storage on completely different timelines.

Virtualization is going multi-vendor after the VMware changes

The VMware licensing changes introduced in 2024 and 2025 pushed many organizations to evaluate alternatives. Two years later, most enterprises are running mixed environments – VMware alongside Proxmox VE, Microsoft Hyper-V, Nutanix AHV, XCP-ng, HPE VM Essentials, and other KVM-based solutions. StarWind’s write-up on the licensing changes covers the details behind that shift.

A common mistake: treating this as nothing more than a hypervisor migration. Teams move workloads from VMware to Proxmox over a weekend, then discover the real dependency was the shared storage underneath. Different virtualization platforms rely on different virtual disk formats, filesystems, and clustering technologies. (This is also where people get burned on weekends – the storage migration, not the hypervisor swap.) Storage migration is almost always the harder part.

If you’re planning a virtualization migration, treat storage as a separate workstream. That avoids replacing more infrastructure than necessary and cuts the risk of swapping one vendor lock-in for another.

Placement is replacing cloud-first, at the core and the edge

Cloud adoption keeps growing. “Cloud-first” isn’t the default strategy anymore, though. Placement decisions now depend on utilization, latency, data volume, compliance requirements, and the long-term cost of moving data. The Flexera numbers cited above show where waste is accumulating, while 58% of their respondents already consume generative AI as a cloud service. (The survey skews toward larger cloud users – treat those numbers as directional, not universal.)

The biggest challenge is data gravity. Moving applications between environments is usually straightforward. Moving hundreds of terabytes, or petabytes, isn’t. Egress charges, transfer times, and operational complexity compound the longer large datasets stay in the wrong place. Organizations keep stable, data-intensive workloads on-premises or in private cloud, place elastic workloads in public cloud, and run latency-sensitive applications at the edge. Our article on data gravity covers how this influences infrastructure design in more depth.

At the edge, the binding constraint is staffing. A retailer with hundreds of locations can’t assign a storage engineer to every branch office. Infrastructure has to stay available even when nobody’s on site to troubleshoot it. That’s why compact systems with centralized management and built-in high availability are the preferred architecture. The 2-node StarWind HCI Appliance is designed for exactly that scenario.

Not every remote site needs a two-node cluster, though. Smaller locations may be better served by a single-node deployment combined with centralized backup or application-level failover. A two-node cluster with an external witness works well where higher availability is required, but the witness improves quorum management – it doesn’t replace a second workload node.

Kubernetes is taking on more stateful workloads

Kubernetes keeps expanding past stateless microservices. The CNCF reports 82% of organizations using containers now run Kubernetes in production, up from 66% in 2023. Among organizations hosting generative AI models, 66% also use Kubernetes for at least part of their inference workloads. Databases, analytics platforms, message queues, and AI inference services are becoming standard Kubernetes workloads alongside traditional stateless applications.

Persistent data is where things get complicated. Stateful workloads expose limitations in storage classes, volume provisioning, replication, failover, and recovery. A pod can restart automatically after a failure, but if its persistent volume can’t be attached or recovered on another node, the application stays down. In many organizations, storage management still sits outside day-to-day Kubernetes operations – and that’s where most of the operational complexity hides.

If your applications genuinely live on Kubernetes, Kubernetes-native storage can simplify operations considerably. DataCore Puls8, built on OpenEBS, runs inside the cluster and manages replication, failover, and storage provisioning through Kubernetes itself instead of relying on external storage systems. Not every workload belongs on Kubernetes, though. Plenty of organizations run stable VM environments successfully, and adopting Kubernetes doesn’t mean containerizing every existing application.

Cyber recovery is becoming a storage requirement

Storage resilience isn’t measured only by hardware failures anymore. Organizations increasingly evaluate storage platforms based on how well they recover from ransomware and other cyberattacks. Immutable snapshots, object locking, versioning, isolated backup copies, and controlled recovery workflows have become standard evaluation criteria. Regulations like DORA and NIS2 have pushed recovery controls further, requiring documented procedures, backup governance, disaster recovery planning, and regular testing – though specific requirements depend on the organization and regulatory scope. (DORA applies to financial entities in the EU; NIS2 casts a wider net across essential and important sectors.)

Here’s the failure scenario that still catches people off guard. During a ransomware attack, production systems get encrypted, and scheduled replication faithfully copies that encrypted data to the secondary storage system. Conventional backups face the same risk if attackers delete them or if retention policies don’t preserve a clean recovery point long enough.

Cyber recovery goes beyond traditional backup. It combines protected backups with immutability, isolation, controlled administrative access, and regular recovery testing to ensure a known-good copy survives an attack and can actually be restored.

Object storage has become an important part of that strategy. Beyond backup repositories and AI datasets, object storage increasingly provides the immutable recovery copy organizations depend on after a cyber incident. Compact ransomware-protected platforms like DataCore Swarm Appliance extend those capabilities to remote offices and edge locations by supporting object locking where traditional enterprise storage may not be practical.

Immutability alone won’t save you. Test your restores. A recovery plan you’ve never validated is just a hypothesis.

Conclusion

These six trends point to one buying model: choose infrastructure by workload requirements, failure domains, operational capacity, and exit cost. Before committing to a new platform, decide which data has to move, what must stay available during the change, and how the environment gets recovered if the migration fails.

Answer those questions first and technology selection gets much simpler. Software-defined storage separates storage services from underlying hardware, letting you modernize compute, storage, and virtualization independently. That independence is what makes the rest of these decisions tractable.

FAQ

Is it still worth keeping older servers in 2026?

Often, yes – as long as they’re still supported and cheaper to run than a replacement. Firmer memory pricing has made new hardware more expensive, and that shifts the math toward selective reuse. Software-defined storage lets compute and storage refresh on separate schedules, which extends the useful life of hardware that’s still pulling its weight.

What should I migrate first when leaving VMware?

Plan the storage migration before committing to a hypervisor. The dependency that complicates weekend migrations is almost always the shared storage underneath, and because platforms use different disk formats and filesystems, some VM conversion is still likely. Keeping storage portable across VMware, Hyper-V, and KVM lets you stage the move over weeks instead of forcing it into a single maintenance window.

How is cyber recovery different from a backup?

Replication may copy encrypted or corrupted data to the secondary system. Conventional backups face the same risk if attackers delete them or if retention is too short. Cyber recovery adds isolation, immutability, controlled access, and tested restoration. DORA and NIS2 have been pushing organizations toward these controls, and the requirements will only get stricter.

Do I need parallel file storage for AI?

Only at the training and high-throughput end, where a parallel file layer provides fast access to large datasets. For inference-only or smaller workloads, a well-provisioned NVMe array or NAS is usually enough. Don’t over-engineer this – match the storage tier to the workload’s actual I/O pattern.

What makes edge infrastructure hard to modernize?

Staffing. Hundreds of sites without local specialists need compact, remotely managed systems that keep running when the central site is unreachable. That could be a two-node cluster, a single node with centralized backup, or a cloud-managed appliance. The right answer depends on what’s running at each location and how much downtime the business can tolerate.

from StarWind Blog https://ift.tt/ozwy9Pe
via IFTTT

Agentic AI Needs Guardrails, Not Guesswork

What does it take to secure AI agents without slowing developers down? A recent panel explored the answer 

I recently joined Zach Lloyd, founder and CEO of Warp; Gavriel Cohen, co-founder and CEO of NanoCo and creator of NanoClaw; and moderator Moriah Hara, founder of a community of more than 3,000 CISOs and a three-time Fortune 500 CISO, for a discussion on one of the biggest challenges facing enterprise security teams today: how to safely unlock the productivity of agentic AI.

The rapid rise of agentic AI in the enterprise is putting CISOs in a tough spot. On one hand, business leaders are clamoring to run with the new technology, which promises a productivity revolution like no other. On the other, setting AI agents loose without rigorous guardrails creates severe vulnerabilities. 

Moriah put the dilemma facing CISOs like this: “The business wants AI agents everywhere, developers are already using them, sometimes without approval, oftentimes without security.
…CISOs are left in this uncomfortable middle where we’re tolerating some tools, we’re praying that nothing breaks, we’re buying some time until we can get some governance beyond policy in place to have better visibility.”

The panel explored the role of the CISO in balancing this tension between productivity and security. Here are some highlights.

Isolate, control, observe

They came at it from different angles, but the panelists agreed on one imperative: running AI agents safely requires an isolated environment with trusted control boundaries. For Zach, Warp’s Oz platform provides that isolation. It’s a cloud agent infrastructure for secure and automated deployment of coding agents that allows centralized management, access controls, and visibility into what agents are doing across the organization.

Zach said you can “literally pull up the Oz web app and see what every agent across your company is doing at all times—which is a way better situation than the world we’re in right now, where someone on your marketing team is running Cloud Code, someone on your sales team is running Codex, and you just have no idea what’s going on, what tools they’re installing.”

NanoClaw—a personal AI agent

At Docker, our answer to the challenge of running AI agents safely is to run them in disposable, isolated, local sandboxes. Docker Sandboxes give agents the freedom and autonomy they need to do their best work, safely. Call it YOLO mode with guardrails. As Moriah noted in our discussion, agentic speed should be encouraged— “it’s the ungoverned speed that is the problem.” When agents are allowed to run fast without running wild, speed and safety are no longer a tradeoff. 

Of note here: In March, we announced the integration of NanoClaw with Docker Sandboxes to deliver secure-by-design agent execution. The integration allows every NanoClaw agent to run inside a disposable, MicroVM-based Docker Sandbox that enforces strong operating system-level isolation. The stack takes advantage of NanoClaw’s minimal attack surface and fully auditable open-source codebase to meet enterprise security standards. 

Laptops as the new prod

A key focus of the discussion was where to run agents safely. With vibe coding exploding, and agents and Claws (a new class of agents) already in production, the laptop today is the most powerful node in the enterprise. It’s also the most exposed. As a colleague of mine recently put it, laptop and agent environments are the new prod, and they need to be governed like prod.

Zach stressed the need to get agents off people’s laptops and desktops and into a controlled, cloud-based environment where CISOs can see what every agent across the company is doing at all times.

Portability—from laptop to cloud

My position is that, if you run agents in a sandbox, it doesn’t matter where the box sits. It could sit on a marketing or finance person’s laptop, or on a DevOps engineer or cloud admin’s machine. As long as the trust boundary is established and you know what’s getting piped in and out of it, you’re locked and loaded for rapid prototyping, experimentation, and innovation.

By the way, this view syncs with Docker’s vision, which has always been about portability. Our vision was never everything is local. We start in the local environment, then lift off into distributed environments, Kubernetes clusters, public clouds, whatever. It’s the same with agents. Eventually they’ll lift off, be decoupled from human operators, and be able to run fully autonomously wherever needed—always in the same portable environment.

When agents build the supply chain

The supply chain today is a revolving door for opportunistic attackers like TeamPCP and ShinyHunters who exploit transient dependencies and other vulnerabilities, often needing only a short window of time to filch credentials and information.

How are CISOs to combat these risks when AI agents themselves are pulling base images, choosing dependencies, and assembling code—autonomously and without human oversight? After all, in an autonomous supply chain, traditional methods of scanning and patching after building are no longer feasible. 

Keeping humans in the loop

The panelists shared several best practices. Zach urged keeping humans in the loop for picking clean, secure dependencies, especially upstream libraries, and setting up blessed images for agents to choose from. Gavriel recommended setting a minimum release age of seven days for images and minimizing dependencies—even safe ones.

A training-wheels approach

Gavriel also suggested a training-wheels approach to experimenting with agents, starting out using unpermissioned data to build skills and avoid sensitive data issues. “Unlocking the value today is important,” he said, “but even more important is having people build the skills of working with agents, because what’s going to be coming in the coming months and years is going to totally exceed anything that we have today. So, it’s really about building the muscle memory, building the skills.”

Layer security to limit the blast radius

My take? Opportunistic attackers are simply exploiting an ecosystem that’s inherently flawed and broken and that unfortunately won’t get fixed within the next six to 12 months. Until then, developers should assume these attacks will continue and prepare for them by layering security to limit the blast radius. That means reducing privilege, reducing third-party access to their environment, and using immutable tags, digests, and SBOMs (Software Bill of Materials) to lock manifests and enable rapid detection of poisoned images. And, yes, outsourcing the risk to a trusted build environment like Docker that provides clean, hardened images so you’re starting from a clean foundation. 

MCP—the new shadow IT?

The panelists rounded out the discussion with a focus on the security implications of using MCP in developer environments. MCP (Model Context Protocol) is a standard that allows LLMs to access external data and use tools, potentially making AI more powerful and reliable.

The consensus was that centralized, secure governance is crucial for productivity and risk management. Gavriel stressed the importance of proper version control, credential management, and a “golden repository” of verified tools. Zach advocated for centralized management to avoid individual tool dependencies and ensure minimal access. 

Making it safe and easy to run MCP servers

And Docker? About a year ago, we introduced an open source MCP Gateway that serves as a chokepoint between agents and external tools. Routing every tool call through this enforcement point, where it can be authenticated, authorized, and logged before it reaches the external system, enables a wide range of agents to access trusted catalogs of MCP servers. While it’s not clear to me how long MCPs will remain useful, given the exponential speed with which AI is evolving, Docker MCP Gateway solves an important challenge today. Like Docker Sandboxes, it makes enforcement strict instead of advisory.

A once-in-a-generation opportunity—and challenge

Enabling dev environments to take advantage of agentic AI is a once-in-a-generation opportunity, and CISOs are accountable for making sure the rush to do so doesn’t devolve into the Wild West.

Moriah closed the panel with a provocative thought: “Six months from now, enterprises are all going to be running agents at scale. The one key success factor will be whether governance was present from day one or got bolted on after the first major incident.”

In the choose-your-own-adventure reality of agentic AI today, what kind of security leader will you be? 

from Docker https://ift.tt/nR7yz3m
via IFTTT

Why Modern SOCs Need Multi-Layered Detections

The cycle is over. For years, cybersecurity followed a familiar pattern: defenses improved, attackers adapted, and the back-and-forth continued. Today, AI-equipped attackers are simply outpacing defenses. Most intrusions now bypass endpoint and malware-based detection entirely.

The CrowdStrike Global Threat Report estimates around 79% of attacks are malware-free, as threat actors rely on credential theft and DLL side-load techniques to bypass host-level monitoring. Perimeter vulnerabilities compound this exposure; firewalls and VPN gateway breaches climbed 19% according to the latest Verizon Data Breach Investigations Report.

Once an adversary gains access, breakout often occurs in seconds. Claude Mythos and similar models have further escalated operational pressure. These can rapidly discover and exploit previously unknown vulnerabilities, virtually closing the window from initial discovery to full compromise.

Security practices must adapt to prioritize rapid containment and post-compromise behavior analysis, and defensive capabilities now demand real-time detection that goes beyond host-level coverage. This is where multi-layered network detections come in, extending defense beyond the endpoint-but their effectiveness depends highly on the data behind them.

Network evidence strengthens detection

Endpoint, identity, and cloud platforms each offer a valuable perspective on corporate security. Host tools track processes in memory, identity solutions monitor credentials, and cloud environments log configuration changes. While each source provides visibility, these systems operate in isolation, leaving gaps in visibility that attackers can easily exploit.

Each tool sees only its fragment of the attack chain. Threat actors can compromise a workstation, leverage blind spots between endpoint and identity systems to hide credential theft, move laterally into cloud infrastructure, and exfiltrate data before the SOC is aware. That is why unified, correlated telemetry across these domains is essential to revealing the full picture.

Network Detection and Response (NDR), validates, enriches, and connects these separate signals using network data. Because it's collected out of band, the data remains immutable even when local agents go dark or when threat actors disable endpoint tools. And because it captures traffic across the entire enterprise, NDR provides vital context, recording every conversation, transaction, and data transfer, delivering the undeniable proof defenders require to respond.

For instance, when an identity tool flags an unusual login, network data verifies whether that account initiated unauthorized database queries. When an endpoint alert flags credential access, it helps validate whether the adversary attempted lateral movement.

Multi-layered detections build confidence in decisions

Most organizations already possess some form of network visibility, such as legacy intrusion detection systems (IDS), packet capture (PCAP) appliances, or basic NetFlow logs. However, these legacy tools operate in isolation, and most fail to match the speed that analysts need to respond to modern attacks. NDR replaces these fragmented, legacy tools.

Through the consolidation of signatures, packet analysis, and flow logs into a single workflow, NDR delivers a comprehensive suite of detections and capabilities that dramatically ease analyst cognitive load. Rather than search through an overwhelming volume of separate, uncoordinated alarms, defenders use multiple integrated network detection layers to establish certain proof.

• Signature-based detection and threat intelligence: These provide rapid validation for documented exploits, catching known threats and historical malicious files with high precision, and detecting communication with established adversary infrastructure. However, to identify post-exploitation activity, modern automated toolkits require advanced behavioral and anomaly layers.
• Behavioral detection: Behavioral models identify adversary tactics, techniques, and procedures (TTPs) regardless of specific files or exploit code. For example, they can detect suspected command and control tactics without reliance on specific indicators.
• Anomaly detection: Anomaly detection flags structural variations from baseline network traffic, such as a workstation that suddenly behaves like an internal port scanner, identifies connections to a large number of previously unseen hosts, or exhibits connection patterns that indicate data collection.
• Supervised ML models: These machine learning models excel at identifying patterns that are difficult to capture using signatures or rule-based logic, thereby extending coverage to threats that evade traditional detection methods. They can see indicators of compromise in encrypted traffic, identify malicious domains, and help uncover tunneling within the network.
• AI: Rather than deliver independent alerts that force analysts to guess at severity, advanced artificial intelligence engines correlate alerts across diverse telemetry sources and layers and map attacker behavior. This integration reduces confusion, tracks the complete kill chain, and builds confidence in operational decisions. With verified, correlated intelligence, analysts shift from validating alerts to rapid triage and containment.

To achieve this degree of operational clarity, security leaders must invest in full-lifecycle protection. This posture is predicated on advanced network telemetry that can surface adversary activity quickly enough to match the operational tempo of Mythos-class threats.

AI is only as effective as the evidence behind it

As a defensive layer, AI currently excels at threat triage, workflow automation, and incident summarization. However, the core rule remains absolute: garbage in, garbage out.

The efficacy of AI-driven security automation is limited by a "knowledge ceiling" determined by source data, not model selection. Even the most advanced models cannot overcome the limitations imposed by low-quality or missing data. Invest in the data; everything else follows.

Rich network telemetry gives AI the truth it requires to reach correct conclusions, accurately mapping enterprise exposure, reconstructing attack paths, and verifying whether exploits succeeded. Without it, AI tools can generate false positives, miss critical activities, and slow incident response.

Network traffic represents undeniable evidence of the enterprise environment. When AI is grounded in this provable data, it delivers security value rather than noise.

From data silos to unified defense

This network context is not a standalone solution; it requires integration and data enrichment from multiple SOC tools to achieve maximum impact. The true strength of this approach lies in an open data architecture and deep configurability.

When a platform supports open data standards, analysts can quickly correlate network telemetry with host and identity alerts. This seamless integration allows security teams to use rich network context immediately, which resolves ambiguous events and maps attack paths from initial entry to execution. Structured, accessible data ensures that incident response teams can execute precise containment before an intrusion escalates.

Key takeaways

The emergence of powerful autonomous exploit engines like Mythos necessitates an evolution in enterprise defense. In this landscape, security teams must evolve toward a defensive architecture with network data at the center to tie together otherwise disparate security tools and data. This integration provides the evidence and context that reduce blind spots and uncertainty. As AI becomes a core component of the modern SOC, the strategic value of network evidence grows exponentially.

Unified network evidence and comprehensive visibility ensure that human analysts and AI models work from the exact same view of the environment. This shared perspective replaces guesswork with clear, structured facts. This strategy consistently delivers three critical operational outcomes:

• Improved detection quality: identify complex, multi-stage attacks that evade single-layer tools
• Faster investigations: use rich network logs to rapidly reconstruct security incidents
• Higher confidence in results: eliminate operational doubt and execute rapid threat containment

With a solid foundation of network evidence, organizations can turn their network into their most powerful defensive asset.

About Corelight

Corelight delivers network detection and response (NDR) solutions that accelerate threat investigations through AI-powered defense. By pairing comprehensive network visibility with deep behavioral analytics, the Corelight Open NDR Platform provides security teams with actionable context and evidence-backed detection. Security professionals can explore Corelight Network Defense or visit the Corelight website to learn how to defend the hybrid enterprise.

Found this article interesting? This article is a contributed piece from one of our valued partners. Follow us on Google News, Twitter and LinkedIn to read more exclusive content we post.

from The Hacker News https://ift.tt/bPJsFt9
via IFTTT

Police Dismantle Kratos Phishing Kit Built to Steal Microsoft 365 Sessions and Bypass MFA

German and US law enforcement have taken down the core infrastructure of Kratos, described by German investigators as one of the world's most widely used criminal phishing kits, and Indonesian authorities arrested the man they say developed and ran it.

In a joint announcement on Monday, the Frankfurt public prosecutor's cybercrime unit (ZIT) and Germany's Federal Criminal Police Office (BKA) said they pulled more than 200 servers offline. Investigators estimate roughly 1,800 paying customers used Kratos to run about 15,000 phishing campaigns a month.

Kratos harvested more than passwords. The kit was designed to steal the session cookie along with the login, and that cookie is enough to walk past two-factor authentication into the account as the user, the BKA said.

ANY.RUN, which reverse-engineered the kit, found operators could pick one of two modes: a plain PHP page that only harvests credentials, or a Node.js reverse proxy designed to relay the login to Microsoft in real time and capture the resulting session. That second mode is the adversary-in-the-middle technique that has made ordinary MFA a much weaker backstop than it looks.

The operation ran like a franchise, with customers the BKA called franchisees. They paid in cryptocurrency and signed up through a dedicated website and a Telegram shop to manage their accounts and organize campaigns, so even low-skill actors could point a working AiTM kit at a target.

The authorities put the number of victims since late 2024 in the hundreds of thousands, spread across more than 30 countries and concentrated in Europe and the United States. They estimate the operators earned more than 300,000 euros since 2024, and that each campaign could hit several thousand recipients.

Kratos was already being tracked. Microsoft Threat Intelligence identifies the same kit as SneakyLog, a phishing-as-a-service platform it says has run credential-and-2FA theft against Microsoft 365 since at least early 2025, and it caught one campaign in the act.

On February 10, operators sent tax-themed emails to about 100 organizations, mostly in the US, across manufacturing, retail, and healthcare, each carrying a W-2 document with a QR code personalized to the recipient that led to a fake Microsoft 365 login.

Stolen Microsoft logins are rarely the end of the line. The BKA said the stolen credentials could be used for further phishing, sold to other criminals, or turned into a foothold inside companies by spreading through their Microsoft 365 environments, the familiar path from one phished inbox to business email compromise.

Carsten Meywirth, who heads the BKA's cybercrime division, said the operation shows "that even highly professional phishing infrastructures can be effectively combated." The ZIT's Benjamin Krause framed it as proof of the office's "disruptive" approach of dismantling a criminal service outright rather than only charging the people behind it.

Microsoft is notifying users caught in the campaigns. For anyone Microsoft is notifying, the fix depends on how they were hit. Where the kit only harvested credentials, a password reset and an MFA check cover it. Where its reverse-proxy mode lifted a live session, that session survives the reset, so it has to be revoked, with high-value accounts moved to phishing-resistant sign-in.

Defenders hunting for exposure can look for the kit's tell: ANY.RUN found its login pages almost always load the paired assets barr.svg and lg.svg, then POST stolen credentials to endpoints like next.php or save.php. It rates that pairing at 90% recall with near-zero false positives.

For now, the servers are offline and, the BKA says, Kratos-powered campaigns cannot continue. What the takedown did not touch is the roughly 1,800 customers or the kit code they already hold. ANY.RUN found Kratos running on disposable domains, compromised WordPress sites, and hosting shared with other adversary-in-the-middle kits, the kind of setup that reappears under a new name once the servers go down.

from The Hacker News https://ift.tt/rsNmpTG
via IFTTT

OpenAI Says Its AI Models Escaped Sandbox, Targeted Hugging Face to Cheat Benchmark

OpenAI on Tuesday said a combination of its artificial intelligence (AI) models, including GPT-5.6 Sol and an "even more capable pre-release model," was behind the security incident that targeted Hugging Face's production infrastructure last week.

The AI company said the models were operating with "reduced cyber refusals for evaluation purposes" that might otherwise limit their ability to conduct cyber attacks, adding it expects such incidents to "become more commonplace with the proliferation of increasingly cyber-capable models."

Describing it as an "unprecedented cyber incident" and one involving state-of-the-art cyber capabilities, OpenAI said it intends to conduct a thorough investigation in partnership with Hugging Face to get to the bottom of the matter.

As part of an internal evaluation, the models are said to have identified and chained vulnerabilities across OpenAI's research environment and Hugging Face's production infrastructure to find solutions for the ExploitGym benchmark.

Evidence unearthed by OpenAI suggests the models' hyperfocus caused them to go to "extreme lengths" to achieve the goal at any cost, even managing to break out of its highly isolated sandboxed environment and obtain open internet access by discovering and exploiting a zero-day vulnerability in an unspecified vendor's product. This required spending a "substantial amount of inference compute."

"With this access, our models performed a series of privilege escalation and lateral movement actions in our research testing environment until the models reached a node with Internet access," the company explained.

Surmounting the internet access blockade, the models subsequently inferred Hugging Face as the repository that hosted models, datasets, and solutions for ExploitGym, which, in turn, caused them to look for ways to gain access to secret information that it could use to cheat the benchmark.

At one point, the models strung together several attack vectors, including using stolen credentials and zero-day vulnerabilities, to find a remote code execution path on the Hugging Face servers.

As part of incident response efforts, OpenAI said it's implementing strict controls in infrastructure configuration, responsibly disclosed the zero-day flaw in the third-party software, adding Hugging Face to its trusted access program to improve their defenses, and incorporating stronger guardrails around future training and evaluations.

"This incident points to the need to further strengthen our model's alignment, cyber protections during evaluation time, and monitoring during internal testing," OpenAI said.

The development comes as the company also revealed that long-running models, while taking on complex, open-ended problems, can open the door to taking unwanted actions, such as finding weaknesses in the operational environment, in pursuit of their objective through repeated attempts over extended periods of time.

"It also shows how a model that operates effectively over long time horizons can learn the blind spots of an approval system and work around it to achieve its goals," OpenAI said. "Long-horizon safety requires not only asking 'is this action allowed?' but also 'what outcome is this sequence of actions working toward?.'"

from The Hacker News https://ift.tt/oV8lAsG
via IFTTT

AI's Impact on Trust and Brand

SUMMARY: In this episode, Brian Gracely interviews Melissa Rosenthal from Outlever about the intersection of AI, brand, and marketing. They explore how AI impacts trust, brand consistency, and operational efficiency, offering insights for organizations navigating AI adoption.

SHOW: 1047

SHOW TRANSCRIPT: The Enterprise AI Show #1047 Transcript

SHOW VIDEO: https://youtu.be/PEqyOxE9PIw

SHOW SPONSORS:

• Nasuni - Activate your data for AI and request a demo
• ShareGate - ShareGate Protect. Microsoft 365 Governance, we got this!

RESOURCES:

Outlever

State of Brand Article

KEY TOPICS:

• AI's impact on trust and brand perception
• Operational efficiencies and AI workflows
• Challenges of AI implementation and guardrails
• Measuring ROI and costs of AI
• The importance of brand consistency in AI interactions

TAKEAWAYS

• 
  
• AI can speed up engineering and operational tasks by 100X.
• Many companies are still in pilot stages with AI, lacking governance.
• Brand consistency is at risk when AI interactions don't align with brand values.
• Experimentation with AI is costly and often lacks clear ROI.
• Organizations need to orchestrate AI workflows across teams for better outcomes.

CHAPTERS/TOPICS:

00:00 Introduction to AI's impact on enterprise and brand

00:30 Melissa Rosenthal's background and Outlever's focus

01:05 The trust issue: AI replacing human interactions

01:55 How AI speeds up workflows and system building

03:00 Risks of AI in customer-facing interactions

04:11 Brand touchpoints and AI's influence on brand perception

05:05 Training AI to reflect brand values

05:59 Responsibility and handling AI mistakes

06:53 Current state of AI governance in companies

08:12 ROI and costs of AI experimentation

08:57 The early stage of AI adoption and lessons learned

10:11 Future outlook: AI in marketing and brand orchestration

10:58 The importance of workflow orchestration across teams

12:03 Bridging the gap between technology and marketing

12:54 The chaos and chaos in AI adoption today

14:03 Risks of homogenized brand messaging with AI

15:02 Predictions for AI in marketing in the next year

16:04 Reorganizing teams around AI outcomes

17:04 The missing link: connecting technology and brand strategy

18:03 Final thoughts and key takeaways

FEEDBACK?

• Email: show @ the enterprise ai show dot come
• Bluesky: @TheEntAIShow.bsky.social
• Twitter/X: @TheEntAIShow
• Instagram: @TheEntAIShow

from The Cloudcast (.NET) https://ift.tt/3nQt2EB
via IFTTT

Critical SharePoint RCE CVE-2026-50522 Under Active Exploitation After Public PoC

A third SharePoint Server flaw patched by Microsoft as part of its Patch Tuesday update for July 2026 has come under active exploitation, per watchTowr.

The vulnerability in question is CVE-2026-50522 (CVSS score: 9.8), a critical deserialization of untrusted data in Microsoft Office SharePoint that could allow an unauthorized attacker to execute code over a network. Microsoft credited DEVCORE researcher "splitline" with discovering and reporting the flaw.

"In a network-based attack, an attacker authenticated as at least a Site Owner, could write arbitrary code to inject and execute code remotely on the SharePoint Server," Redmond said in an advisory released last week.

"The attack vector is Network (AV:N) because this vulnerability is remotely exploitable and can be exploited from the internet. The attack complexity is Low (AC:L) because an attacker does not require significant prior knowledge of the system and can achieve repeatable success with the payload against the vulnerable component."

The tech giant also tagged CVE-2026-50522 with an exploitability assessment of "Exploitation More Likely."

In a post shared on LinkedIn, watchTowr said it has detected active exploitation of the shortcoming against on-premises Microsoft SharePoint deployments following the release of a public proof-of-concept (PoC) exploit, allowing attackers to steal machine keys to maintain persistent access.

"Attackers are pulling SharePoint machine keys via a single request," the security vendor said. "Patching is not enough; defenders should rotate credentials on any assets that may have been exposed."

CVE-2026-50522 is the third vulnerability in SharePoint Server after CVE-2026-56164 (CVSS score: 5.3) and CVE-2026-58644 (CVSS score: 9.8) to witness active exploitation efforts, with the latter two weaponized as zero-days prior to them being fixed in July 2026.

The U.S. Cybersecurity and Infrastructure Security Agency (CISA) has since warned that threat actors are exploiting multiple SharePoint Server vulnerabilities, including CVE-2026-32201, CVE-2026-45659, CVE-2026-56164, and CVE-2026-58644, to gain unauthorized access to on-premises instances.

"These vulnerabilities affect all supported on-premises SharePoint Server versions (Subscription Edition, 2019, and 2016) and involve establishing remote code execution (RCE) and post-exploitation activities, such as stealing Internet Information Services (IIS) machine keys and performing deserialization techniques, to gain persistence and deploy malware," the agency said.

from The Hacker News https://ift.tt/3Qmzjx4
via IFTTT

Zimbra Patches Critical SNMP Command Injection and Four XSS Vulnerabilities

Zimbra has rolled out fixes to address multiple critical security issues, including a command injection flaw in the Simple Network Management Protocol (SNMP) monitoring component.

As many as nine security vulnerabilities have been patched in Zimbra 10.1.20. Topping the list is a command injection vulnerability in the SNMP monitoring component when SNMP notifications are enabled.

Also patched are four cross-site scripting (XSS) flaws in the Classic Web Client -

• A stored cross-site scripting (XSS) vulnerability that could allow malicious attachment filenames to execute script under specific conditions.
• An XSS vulnerability where crafted fields could execute a malicious script under specific conditions.
• An XSS vulnerability where a crafted field could execute a malicious script when rendered.
• An XSS vulnerability where crafted attachments could execute a malicious script when rendered.

Separately, fixes have been released for a mail forwarding restriction bypass (CVE-2026-50055) that could allow authenticated users to exfiltrate email despite mail forwarding restrictions being enabled. Rapid7 security researcher Jonah Burgess has been credited with discovering and reporting the flaw.

The company did not share any additional specifics, stating "in line with industry best practices, information disclosure is limited for security vulnerability fixes."

The release comes a little over a week after Zimbra patched a critical stored XSS flaw in the Classic Web Client that could result in arbitrary code execution.

Although none of the identified vulnerabilities have been flagged as actively exploited, XSS bugs in the email software have been repeatedly exploited by bad actors in the past, making it crucial that customers apply the updates to keep the environment secure.

from The Hacker News https://ift.tt/Fk7xjhX
via IFTTT

How to Upgrade Debian 12 to Debian 13 (Trixie) with Minimal Downtime

Debian 13 (Trixie) is now stable, and Debian 12 is in LTS-only support. Our new guide covers a production-focused upgrade path to Debian 13, including backups, rolling deployments, and common pitfalls to minimize service disruption.

Debian 13 “Trixie” has been the stable release since August 9, 2025, and Debian 12 “Bookworm” is now oldstable. Its full security support window closed around June 2026, leaving it on LTS-only coverage. If you’re still running Bookworm in production, upgrading is no longer optional; it’s a matter of when. This guide walks through a full 12-to-13 upgrade with a specific focus on minimizing downtime on live, service-critical servers, not just a lab box you can afford to take offline for an afternoon.

What’s New in Debian 13 Trixie (Quick Context)

Debian 13 ships Linux kernel 6.12 LTS, GCC 14.2, Python 3.13, and over 14,100 updated packages, with full support running until roughly August 2028 and LTS extending to 2030. For production servers, the practical takeaway isn’t the flashy features; it’s that the security support clock has reset, and every month spent on Bookworm’s shrinking support window is technical debt you’ll eventually have to pay down anyway.

Important Constraint: You Can Only Upgrade From Debian 12

Debian only supports upgrading between consecutive stable releases. If you’re on Debian 11 “Bullseye” or older, you must upgrade to Debian 12 first, then to Debian 13; there’s no direct 11-to-13 path.

The “No Downtime” Strategy: What This Actually Means

Be realistic about what “without downtime” means for a major OS upgrade: the goal isn’t zero risk; it’s minimizing user-facing service interruption through preparation, sequencing, and a tested rollback path. The core techniques that make this achievable:

1. Test in staging first, never run your first Trixie upgrade on a production box
2. Take a snapshot or full backup immediately before the upgrade, so rollback is a restore, not a rebuild
3. Use apt upgrade –without-new-pkgs before full-upgrade to reduce the risk of mid-upgrade service breakage
4. Drain traffic from the server first if it’s part of a load-balanced fleet, rather than upgrading it live
5. Upgrade one node at a time across a fleet, verifying each before moving to the next

How to Upgrade Debian 12 to Debian 13 (Trixie) Without Downtime

To upgrade Debian 12 to Debian 13 (Trixie) without downtime, first fully patch and reboot your Debian 12 system, back up /etc and your package selections, and disable any third-party repositories that may not yet support Trixie. Then point your APT sources from bookworm to trixie using sudo sed -i ‘s/bookworm/trixie/g’ /etc/apt/sources.list, run sudo apt update, and perform the upgrade in two stages: sudo apt upgrade –without-new-pkgs -y first to safely resolve dependencies, followed by sudo apt full-upgrade -y to complete the transition.

If the server is part of a load-balanced fleet, drain its traffic before starting and re-add it only after verifying all services are healthy post-reboot. This rolling, one-node-at-a-time approach is what actually eliminates user-facing downtime across a production environment.

Step 1: Back Up Everything Before You Touch Anything

This is non-negotiable. A dist-upgrade preserves data and configuration in the vast majority of cases, but “in the vast majority of cases” is not a guarantee; your backup is your actual rollback plan if something breaks mid-upgrade.

sudo tar -czf /backup/etc-backup-$(date +%Y%m%d).tar.gz /etc

sudo dpkg --get-selections > /backup/package-selections-$(date +%Y%m%d).txt

If you’re on a VM, take a full snapshot through your hosting provider or hypervisor; this is faster to restore from than a manual file backup and covers everything, not just /etc.

Step 2: Fully Patch Debian 12 Before Upgrading

Never jump to Trixie from a partially updated Bookworm system. Bring the current OS fully current first:

sudo apt update

sudo apt full-upgrade -y

 

 

Reboot to ensure the current kernel is fully applied and no pending changes are left hanging before you introduce the bigger upgrade.

sudo apt autoremove -y

sudo reboot

 

 

Step 3: Check for Held or Locked Packages

Held packages can silently break a major upgrade. Check for any before proceeding:

apt-mark showhold

 

 

If anything critical to the upgrade is listed, remove the hold:

sudo apt-mark unhold <package-name>

Step 4: Verify Free Disk Space

A major version upgrade downloads and temporarily stores a large number of packages. Confirm you have enough headroom, particularly on / and /boot:

df -h

 

 

You’ll typically want at least 2–3 GB free on /, and Trixie’s release notes specifically call out ensuring /boot has enough free space, since kernel packages have grown in size.

Step 5: Disable Third-Party Repositories Temporarily

Third-party repos (Docker, Node.js, PostgreSQL, etc.) are one of the most common causes of upgrade failures, since they may not yet have Trixie-compatible packages. Check what’s configured:

cat /etc/apt/sources.list

ls /etc/apt/sources.list.d/

 

 

Temporarily disable them by renaming rather than deleting, so you can restore them cleanly afterward:

sudo mv /etc/apt/sources.list.d/docker.list /etc/apt/sources.list.d/docker.list.bak

Step 6: Point Your Repositories to Trixie

The core of the upgrade is simple: swap every bookworm reference to trixie in your APT sources.

sudo sed -i 's/bookworm/trixie/g' /etc/apt/sources.list

 

 

If your system uses the newer DEB822 .sources format (common on more recent Debian 12 installs), update those too:

sudo sed -i 's/bookworm/trixie/g' /etc/apt/sources.list.d/*.sources 2>/dev/null

 

 

Trixie also officially encourages consolidating to the DEB822 format going forward, but it’s not required for the upgrade to succeed.

Step 7: Refresh Package Metadata

A handful of warnings about changed repository signatures during this step are normal for a major version transition and not a sign of a problem.

sudo apt update

 

 

Step 8: Run the Minimal Upgrade First (This Is the Downtime-Reducing Step)

This is the most important step for minimizing service disruption. Instead of jumping straight to a full upgrade, run a minimal upgrade first, one that resolves dependencies without removing or installing new packages:

sudo apt upgrade --without-new-pkgs -y

 

 

You’ll likely see “packages have been kept back” messages; this is expected and normal. This step resolves the safer, lower-risk package updates first, reducing the chance of a service getting yanked mid-transaction during the bigger step that follows.

Step 9: Run the Full Upgrade

Once the minimal upgrade completes cleanly, proceed with the full distribution upgrade:

sudo apt full-upgrade -y

 

 

This resolves the held-back packages by installing new dependencies or removing conflicting ones. This step takes the longest; don’t interrupt it, especially during kernel or GRUB package installation. If prompted about where to install GRUB, choose the disk your system currently boots from (typically /dev/sda or /dev/vda).

Step 10: Clean Up and Reboot

sudo apt clean

sudo apt autoremove -y

sudo reboot

 

 

After rebooting, let’s confirm the upgraded Debian 13.

 

 

Step 11: Verify the Upgrade

After reboot, confirm you’re actually running Trixie:

cat /etc/os-release

 

 

Or, on systemd-based installs:

hostnamectl

 

 

You should see Debian GNU/Linux 13 (Trixie) and 6.12.x kernel versions.

Minimizing Downtime Across a Fleet of Servers

If you’re managing multiple servers behind a load balancer, the real downtime-avoidance strategy happens at the infrastructure level, not just the OS level:

1. Remove the server from the load balancer pool before starting the upgrade, so it stops receiving live traffic
2. Upgrade and fully verify the drained node using the steps above
3. Re-add it to the pool only after confirming all critical services are healthy
4. Repeat one node at a time, never upgrading multiple nodes simultaneously

This turns what would otherwise be a single point of downtime into a rolling upgrade with zero visible interruption to end users.

Known Gotchas in Trixie’s Release Notes Worth Knowing

A few changes specifically called out in Debian’s official release notes have tripped up production upgrades:

• /tmp is now mounted as tmpfs by default; applications writing large temporary files may behave differently
• OpenSSH no longer supports DSA keys; audit your key types before upgrading if you rely on SSH automation
• /etc/sysctl.conf is no longer honored directly; move custom kernel parameters to /etc/sysctl.d/
• MariaDB major version upgrades only work reliably after a clean shutdown. Stop the service properly before upgrading if you’re running MariaDB
• Troubleshooting Common Issues

“Unable to locate package” errors during apt update usually mean a third-party repo is still pointing to bookworm. Disable it and retry.

Services fail to start after reboot. Check logs directly:

sudo journalctl -xe

sudo systemctl status <service-name>

 

 

Configuration file format changes between major versions are the most common cause.

Need to roll back. If your backup was a VM snapshot, restore it directly. If not, you can attempt to revert sources to bookworm, but a clean rollback via snapshot is far more reliable than trying to downgrade packages manually.

Final Thoughts

Upgrading Debian 12 to Debian 13 without downtime isn’t about finding some special zero-risk trick; it’s about disciplined preparation: full backups before you start, a fully patched source system, third-party repos handled deliberately, the minimal-upgrade-then-full-upgrade sequence, and load balancer draining if you’re managing more than one server.

Follow that order, and the upgrade itself typically takes under an hour per server, with the biggest real risk coming from custom configurations and unmaintained third-party repositories rather than Debian’s own upgrade tooling.

FAQ

Can I upgrade directly from Debian 11 to Debian 13?

No. Debian only supports upgrades between consecutive stable releases, so you must upgrade from Debian 11 “Bullseye” to Debian 12 “Bookworm” first, and only then proceed to Debian 13 “Trixie.”

Will upgrading from Debian 12 to Debian 13 delete my data or configuration?

A standard dist-upgrade preserves data and configuration in the vast majority of cases, since it upgrades packages rather than reinstalling the system. That said, a full backup or VM snapshot is still mandatory beforehand; it’s your rollback plan if anything goes wrong mid-upgrade, not an optional precaution.

Why should I run apt upgrade –without-new-pkgs before apt full-upgrade?

This two-stage approach resolves the safer, lower-risk package updates first without installing or removing anything, reducing the chance of a critical service being disrupted mid-transaction during the larger, more disruptive full upgrade that follows. It’s the key technique for minimizing downtime risk on production servers.

How long does the Debian 12 to Debian 13 upgrade actually take?

For a well-maintained server, the entire process, backup, repository switch, minimal upgrade, full upgrade, and reboot, typically takes under an hour. The biggest variable is the package download speed and how many third-party repositories need to be checked for Trixie compatibility.

What’s the safest way to upgrade multiple production servers without any visible downtime?

Upgrade one server at a time rather than all at once: remove it from your load balancer pool first, complete and verify the upgrade in isolation, then add it back only after confirming services are healthy.

from StarWind Blog https://ift.tt/Puq9xEj
via IFTTT

New Bit2Watt Attack Could Let Cloud Tenants Disrupt Power Grids Without an Exploit

A cloud tenant using nothing but ordinary GPU access can push a data center's power draw up and down fast enough to threaten the grid it runs on, with no exploit and no break-in.

That is the claim behind Bit2Watt, described by three Zhejiang University researchers in a paper accepted to CHES 2026, the IACR's hardware-security conference, and the evidence splits in two: they measured the power modulation on real GPUs and simulated the grid destabilization it could cause.

The technique inverts the usual grid-attack model: no compromised sensors, no malware on control systems, no stolen operator credentials, just a workload built to misbehave on purpose.

It works because a GPU's power draw follows whatever it is computing. Saturate the tensor cores and current spikes; drop to idle, and it collapses. Toggle between those states on a schedule and you get a controllable power oscillation at the wall socket.

The authors frame it as a blunt question: can "purely computational actions, executed as legitimate workloads, be weaponized to destabilize power infrastructure"? The rest of the paper is their answer.

Two Ways In

The first method, which they call SWMA, uploads a purpose-built CUDA kernel that flips between a high-intensity compute mode and a near-idle one. A host-side controller sets the switching schedule and toggles the mode through a single unified-memory flag allocated with cudaMallocManaged, standard tooling rather than anything exotic.

Across the tested GPUs, the synthetic workload produced power components from about 1.5 kHz up to 6 kHz, peaking on an RTX 4090, well above the handful of hertz a swinging household load like an air conditioner produces.

It held on data-center GPUs like the A100 and Tesla V100, not just gaming cards. The custom kernel and its tight polling loop are the sort of thing a provider could learn to fingerprint.

The second, LTMA, is the one that should worry operators. Rather than a synthetic kernel, it buries the modulation inside a real LLM training run, adjusting hyperparameters and inserting auxiliary operations to make the compute load rise and fall without breaking the training.

The control is looser than SWMA's, bounded by how fast the training loop iterates, and the frequencies run lower, roughly 1.2 to 3 kHz. But it reaches larger amplitude and blends into normal training noise, which is exactly what makes it the harder one to flag. Neither method needs elevated privileges, because a tenant already controls their own training scripts and job schedules.

Those are single-GPU figures, and they only bite in bulk. The paper models the bulk case at its most dangerous: a simulated 1 MW local grid, 90% powered by distributed energy resources (the rooftop solar and batteries increasingly feeding local grids), with 1,000 GPUs modulating in perfect lockstep.

In that worst-case simulation, current total harmonic distortion (THD) hit 46.8%, well above the 13% guideline the paper benchmarks it against from IEC 61000-3-12. The damping ratio fell to -0.27, a negative value that marks an unstable mode, where the grid amplifies a disturbance instead of damping it out.

The paper pushes the model further still, onto a 9,241-bus grid meant to resemble the European transmission network, where a localized disturbance worth 2% of system load cascades across 13 stages and sheds about 81% of load. That number stacks worst-case assumptions on one specific model, and it is a property of the simulation, not a forecast of anything real.

That lockstep is the load-bearing assumption, and the optimistic one for the attacker: the paper concedes that aligning power transitions across a real fleet of cloud GPUs is still an open problem. In its own 2 kHz model, timing jitter with a standard deviation of 100 microseconds cut the aggregate amplitude by about 20%, and the paper does not claim that figure reflects a typical cloud.

A real attack would need several things to line up at once: enough physically clustered GPUs, tight synchronization across them, modulation that survives the data center's power-conditioning stages, and a grid whose resonances happen to amplify the chosen frequency.

The physical experiments ran in controlled testbeds, and the grid-scale damage came from simulation, with no production systems attacked and no security flaw disclosed in any specific commercial product.

The Hacker News has reached out to the Zhejiang University researchers for comment on how far the attack scales in a real cloud environment and will update this story with any response.

What keeps it from being purely academic is that the physics is already on record. In August 2025, Microsoft, OpenAI, and NVIDIA published their own paper on stabilizing AI-training power, warning that the synchronized swings of large training jobs can, when their frequency lines up with a utility's critical frequencies, "cause physical damage to the power grid infrastructure."

Bit2Watt takes that accidental effect and asks what a tenant could do with it deliberately.

The grid has also had a scare from data centers behaving badly by accident. In July 2024, a transmission fault in a data-center-dense part of Northern Virginia caused roughly 1,500 MW of data-center load to drop off the grid at once, when the facilities' own protection systems cut them over to backup power.

NERC, which oversees North American grid reliability, said the disturbance posed no reliability risk at the time, though operators did have to correct voltage. It warned that the danger grows as these loads scale, and its technical committee set up a Large Loads Task Force later in 2024 to study them.

No one attacked anything; the data centers protected themselves. The point is not that the grid nearly failed, but that a load that size can drop in an instant, faster than operators can plan for, and the risk climbs as these fleets grow.

The loop closes with what the authors call Watt2Bit, the disturbance feeding back into the computing side. The paper's analysis shows how harmonic-driven heating and elevated current could trip thermal or overcurrent protection and shut GPU servers down, turning a power-quality problem into a denial of service.

Stranger still, the same modulation doubles as a covert channel. Encoding bits as two frequencies, 2 kHz for a 1 and 200 Hz for a 0, the team captured the electromagnetic emissions on a near-field antenna wired to a software-defined radio and recovered a 50-bit test sequence with zero errors.

It is a close cousin of PowerHammer, the air-gap data-exfiltration attack THN covered in 2018, with one distinction: PowerHammer read data conducted along the power line, tapped anywhere from the outlet to the building's electrical panel, while Bit2Watt's channel needs an antenna catching near-field EMI right at the hardware.

Neither reaches out over the internet; both need a physical foothold near the power or the machine.

No Bug to Patch

Standard telemetry barely catches it. Rack PDU counters sample once a second, NVIDIA's NVML telemetry at 450 Hz, and even the fastest common interfaces, RAPL and server BMCs, top out near 1 kHz, while the modulation runs several times higher.

A lightweight detector the researchers built on power and NVML data performed poorly; adding GPU profiling features improved it, and dedicated EMI sensing worked best. LTMA was consistently harder to spot than SWMA. Those results come from a research-grade detector, not the proprietary systems a large cloud provider might run, so they do not prove a hyperscaler would miss it.

The bigger problem is not visibility. There is no product bug to patch, because the exposure is the architecture itself: the tight coupling between volatile GPU load and an inverter-heavy grid, which no conventional monitoring watches across.

The paper offers defenses for both sides at once: batteries, supercapacitors, and harmonic filtering on the power side; anomaly detection on GPU utilization and training schedules on the compute side. It frames a single system that ties the two together as future work.

The compute side and the grid side are run by different companies, monitored by different tools, and neither is built to watch the other. That seam is where Bit2Watt lives, and right now it has no owner.

from The Hacker News https://ift.tt/D5wNrkZ
via IFTTT

WordPress wp2shell Exploitation Grows as Public Exploit Fuels Mass Scanning

Attackers have begun to exploit two critical vulnerabilities in WordPress that, when combined together, enable unauthenticated remote code execution (RCE) and complete compromise of vulnerable websites.

The two security flaws, tracked as CVE-2026-63030 and CVE-2026-60137, have been codenamed wp2shell.

"By the early hours of Saturday morning (UTC), successful exploitation was already well underway, initially using public exploit code to exfiltrate hashed credentials, with remote code execution following once additional details were made public," Jake Knott, principal security researcher at watchTowr, told The Hacker News in a statement.

"From our vantage point across a global client base, we are seeing widespread impact of this vulnerability across organizations of every size and every vertical."

Telemetry data captured by KEVIntel shows that 13 unique IP addresses from Switzerland, Germany, the U.K., Indonesia, Lithuania, the Netherlands, and Singapore have been linked to the exploitation of CVE-2026-63030.

The exploit chain, discovered by Searchlight Cyber using OpenAI GPT 5.6 Sol in over 10 hours, essentially allows unauthenticated attackers to gain remote code execution on default WordPress installations in any WordPress version released since December 2025. Technical details have been withheld in light of the severity of the issue.

"The attack has no preconditions and can be exploited by an anonymous user in a stock install of WordPress with no plugins," Searchlight Cyber said.

According to Cloudflare, CVE-2026-63030 enables unauthenticated remote code execution (RCE) only when persistent object cache is not in use. While the SQL injection vulnerability (CVE-2026-60137) is present from version 6.8 onwards, the RCE affects versions from 6.9.

"This exploit utilizes a two-part vulnerability chain to achieve unauthenticated SQL injection on a stock WordPress installation with a single HTTP request," Ben Marr, security engineer at Intruder, explained. "CVE-2026-60137 is the entry point - a route confusion bug in the REST API batch endpoint that bypasses authentication, allowing an attacker to invoke internal handlers without any permission check."

"This flaw arises from the improper sanitization of the 'author__not_in' parameter within 'WP_Query' when untrusted data is passed to it by a plugin or theme. This vulnerability allows crafted input to alter a database query, potentially leading to unauthorized access or manipulation of data."

Data from Google-owned Wiz suggests that 60% of organizations using WordPress initially had at least one vulnerable instance at the time these CVEs were published, and 25% were exposing a vulnerable server to the Internet. The figures have since dropped as organizations continue to apply the fixes.

The cloud security subsidiary has observed the following post-exploitation activities following the abuse of the two flaws -

• Uploading a malicious plugin
• Enumerating users and harvesting admin usernames and email addresses
• Performing local file inclusion (LFI) attacks to target database credentials and authentication keys for exfiltration
• Accessing the admin panel and successfully authenticating themselves
• Uploading a bare-bones PHP web shell that facilitates remote code execution

"We've also observed high-volume scanning activity without subsequent post-exploitation, suggesting opportunistic mass-scanning campaigns seeking to identify vulnerable targets alongside legitimate security scanning activity," Wiz researchers Shahar Dorfman and Gili Tikochinski said. "We have yet to identify lateral movement or data exfiltration, but we continue to monitor and investigate."

Also observed as part of the activity is a 150 KB web shell that's disguised as a legitimate WordPress security plugin called CMSmap. It acts as a "full-featured attack platform" supporting file management, database access, port scanning, batch code injection, and multiple privilege escalation modules, including MySQL UDF exploitation.

WatchTowr also said attackers have begun to spray the Internet in an indiscriminate fashion following the release of a public exploit, with its honeypots registering "tens of thousands of exploitation attempts."

More than 100 backdoor administrator accounts are said to have been created following exploitation, allowing the attackers to deploy fake WordPress plugins to gain code execution or download secondary tools to further compromise the system. In at least one case, a threat actor has been observed repeatedly attempting to install Overlord RAT, a Golang-based remote access trojan.

Defenders are recommended to inspect their WordPress instances for new administrator accounts, malicious plugins, or other suspicious files, regardless of whether they've been patched, to completely root out the threat.

from The Hacker News https://ift.tt/VtjELpk
via IFTTT