CSOonline

For more than two decades, cybersecurity has been built on a reactive model: detect intrusions, patch vulnerabilities, respond to incidents, and repeat. That model is now under sustained pressure from a threat environment that is faster, more coordinated, and increasingly automated. Two recent developments illustrate how quickly that model is breaking down. Earlier this month, the White House released its long-awaited cyber strategy that elevates proactive or offensive cybersecurity to the top of its priorities. At this year’s RSA Conference, Sandra Joyce, who leads Google’s Threat Intelligence Group, unveiled the company’s threat disruption unit, outlining plans to use legal authorities and technical capabilities to thwart cyber threat groups actively. Together, these developments reflect a shift already under way — from purely defensive models toward efforts to disrupt adversaries before attacks reach their targets. “What we’ve been doing for the past 20 years hasn’t been working,” Glenn Gerstell, former general counsel of the National Security Agency and now senior adviser at the Center for Strategic and International Studies, tells CSO. “We have been inherently playing catch-up on defense … and the gap is getting wider.” That assessment is now shaping both government strategy and private-sector operations. The United States is explicitly trying to shape adversary behavior rather than absorb attacks, while major technology providers are investing in capabilities designed to disrupt threat actors before they reach their targets. The shift is often described as “proactive cyber” or “active defense,” but the language obscures how constrained — and how operational — the change actually is. The collapse of response time The urgency behind that shift is grounded in how quickly modern attacks now unfold. The traditional sequence — initial access, lateral movement, data exfiltration — has collapsed into tightly coordinated, near-simultaneous activity across multiple actors. “The median time between initial access and the handoff to the secondary threat group has dropped from eight hours in 2022 to just 22 seconds in 2025,” Joyce emphasized during an RSA keynote. That compression reflects a broader structural change. Cyber operations are no longer linear campaigns but ecosystems, where access brokers, operators, and monetization specialists operate in parallel. Artificial intelligence is accelerating that model by automating key phases of exploitation and movement. “Agentic approaches for exploit development will allow adversaries to outpace human-driven controls,” Joyce said. John Hultquist, chief analyst at Google Threat Intelligence Group, says that once an intrusion is under way, defenders are already behind. “Active defense is looking for opportunities outside of the castle walls, before the actor shows up inside or starts hitting the castle walls.” Gerstell describes the same imbalance more bluntly. “The bad guys … have the advantage,” he says. What ‘proactive cyber’ means Despite the more aggressive language, this shift toward private-sector involvement doesn’t envision vigilante-style payback by aggrieved organizations. It instead embraces a more systematic effort to interfere with adversaries earlier in the attack chain using authorities and capabilities that already exist. “To be clear, this is not hacking back,” Joyce said. “This is the legal and ethical use of intelligence to protect our own platforms.” In practice, that approach combines civil litigation, coordinated takedowns, public exposure of tools, and product hardening. The goal is to impose cost and friction across the ecosystem rather than to stop individual intrusions. “Our goal is to shift the economics of the entire ecosystem, to make cyber threat operations so costly, so difficult, so risky, that it is no longer a viable path for any adversary,” Joyce said. Hultquist underscores that this kind of disruption has real but limited effects. “We’re looking for operations that will have a longer-lasting effect on adversaries, or we can repeat at such a tempo that we can actually maintain the effect,” he says. That dynamic is central to how proactive cyber is now being framed. Disruption is not a permanent solution; it is a way to degrade adversary capability and buy time. Gerstell offers a practical boundary for where that activity becomes more controversial. “If you’re doing something only on your own network, it sounds defensive,” he says. “If you’re doing something on somebody else’s network, it sounds offensive.” Why the private sector is central The shift toward proactive cyber is rooted in who controls the terrain. “The private sector operates the very infrastructure that adversaries abuse,” Joyce said. At the same time, the scale of cyber threats exceeds what the government can handle alone. “There’s no world in which the government can do all the things,” Cynthia Kaiser, former FBI cyber deputy director and now SVP at Halcyon, tells CSO. “When I was at the FBI, there was no world in which you could do all the things.” That has led to a push for deeper operational integration between government and industry, combining private-sector visibility and speed with public-sector authority. Adam Maruyama, former CTO and DoD and NSA analyst and counterterrorism expert, says the shift toward more proactive action is necessary but lacks clear rules. Acting earlier in the attack chain, he notes, raises questions about how those operations should be conducted across jurisdictions and how they should be coordinated with allies. “Once you start acting outside your own network, you’re immediately dealing with questions of jurisdiction and coordination,” Maruyama tells CSO. “Those aren’t fully worked out.” Without that clarity, more assertive disruption efforts risk creating friction even among partners, particularly when infrastructure sits outside US control. National Cyber Director Sean Cairncross framed the goal as correcting an imbalance. “The risk calculus on our adversary side in this space doesn’t seem to be calibrated correctly,” he said at the McCrary Institute Cyber Summit in March. But Cairncross drew a clear boundary around private-sector action. “I am not talking about private sector industry or companies engaging in a cyber offensive campaign,” he said. “That’s not what we’re talking about.” The fault lines: How far is too far Agreement on the need to act earlier does not extend to agreement on how far those actions should go. Kaiser sees a practical path in focusing on criminal actors, where legal authorities are clearer, and escalation risks are lower. “I think the least risky way in which industry can help on this front is with criminal actors,” she says, pointing to infrastructure takedowns and recovery of stolen funds. She also argues that legal frameworks may need to evolve. “The primary thing I’d like to see is re-looking at the laws as they exist now and seeing if there are ways in which industry can help more with taking down infrastructure and clawing back stolen funds,” she says. Others are more cautious. Maruyama points to the complexity of globally distributed infrastructure. “What if their infrastructure is hosted not in North Korea, but in France … or a semi-allied country like Malaysia?” he asks. Hultquist reinforces caution from an operational standpoint, but stresses the importance of effectiveness in targeting. That is one reason why Joyce said in her keynote that whatever tactic Google uses against adversaries, it intends for them to “stay burned.” He says, “We are committed to operations that have lasting effects.” Who can do this Even if those tensions are resolved, the ability to carry out proactive disruption is concentrated among a small number of actors. “This is something that Google can do [and that] Microsoft has done and can do,” Gerstell says. “A medium-sized company probably can’t.” The requirements include not just technical capability but legal authority, operational scale, and control over infrastructure. Large platform providers can act within environments they own and can absorb the risks associated with disruption. Most enterprises cannot. Even among organizations that could act, willingness varies. “Some of them could do it, but don’t want to,” Gerstell says. What should CISOs do? For enterprise security leaders, the shift toward proactive cyber does not expand their mandate to take on offensive or disruption roles. Instead, reinforcing core cybersecurity fundamentals remains the priority. “The basic blocking and tackling is still critical,” Gerstell says. Kaiser frames the enterprise role as participation rather than initiative. “What more can we all do?” she asks, particularly in supporting takedowns and recovery efforts where industry can act “more quickly and nimbly than the government can.” That participation requires operational readiness: the ability to share telemetry quickly, preserve evidence, and respond in real-time when providers or law enforcement act against adversary infrastructure. For CISOs, that means upstream disruption does not reduce the need for internal resilience. Even as governments and large cybersecurity providers increase pressure on attackers, enterprises should expect continued activity — often from the same actors operating in slightly different ways. At the same time, the legal limits remain clear. Acting outside an organization’s own environment introduces risks that most enterprises are not equipped to manage. The practical role for CISOs is not to become more aggressive, but to operate effectively in a system where others increasingly handle disruption. View the full article

I recently had the opportunity to review five popular SIEM solutions as part of a judging panel for a Security award. While each platform had its own unique flair, their core promises were remarkably consistent: 24/7/365 SOC monitoring: Round-the-clock coverage backed by global experts to validate and prioritize alerts. Proactive threat hunting: Active searches for hidden threats rather than just waiting for automated triggers. AI and machine learning integration: Leveraging everything from basic anomaly detection to “Agentic AI” to reduce noise and accelerate investigations. Active incident response and containment: Capabilities to isolate endpoints or disable compromised users to stop lateral movement. Third-party tool integrations: Ingesting telemetry from the “native stack” and third-party tools like CrowdStrike or Microsoft Defender. Continuous intelligence updates: Constant streams of new detection rules and playbooks based on global research. Service level guarantees: Financial credits or pricing adjustments for broken SLOs. These offerings are impressive, yet a glaring omission stood out: none of them discussed how they handle multi-tenancy. In a cloud-native world, it is very likely that most if not all of these providers operate on shared infrastructure. This means they are not immune to the “noisy neighbor” effect, a phenomenon where a single misbehaving tenant can degrade the security posture of everyone else on the platform. The noisy neighbor effect As security operations move toward cloud-native frameworks to handle the exponential growth of telemetry data (often reaching petabytes of logs), they rely on the elasticity of software-as-a-service (SaaS). However, the sharing of physical resources (including CPU, memory and I/O) among independent customers introduces a significant engineering risk. When one tenant’s workload consumes a disproportionate share of these resources, it creates a bottleneck. For other tenants, this translates to increased ingestion latency, delayed threat detection and violated SLAs. In security, a “delayed” alert is often as useless as no alert at all. The multi-tenant paradox The core appeal of multi-tenant SIEM solutions is efficiency: shared infrastructure leads to lower costs and unified management. Yet, without deliberate engineering, this becomes a zero-sum game. In a naive system, a high-volume tenant can saturate the ingestion pipeline, causing “starvation” for smaller tenants. This breaks the real-time detection and response (RTDR) promise that these companies market so heavily. The key distinction is that multi-tenancy does not have to be zero-sum. The fairness strategies explored in this article exist precisely to prevent that outcome, but only if vendors have invested in them. The silence in marketing materials suggests many have not. Why fairness is an engineering problem Engineering “fairness” is not merely about setting hard limits; it is about sophisticated resource orchestration. I highly recommend reading AWS’s paper on fairness in multitenant systems. A rigid cap might protect the system, but punish a client during a genuine security emergency when they need ingestion capacity most. Conversely, a completely open system is vulnerable to cascading failures. To solve this, engineers must move beyond simple rate-limiting and embrace “fair share” scheduling, intelligent queuing and dynamic resource allocation. This article explores the architectural strategies required to ensure that every tenant receives the performance they were promised, even when their neighbor’s house is on fire. The anatomy of a modern SIEM To understand where fairness fails in a multi-tenant environment, we must first dissect the anatomy of a modern SIEM. It is no longer a monolithic database, but a distributed data pipeline designed to ingest, transform and analyze petabytes of telemetry. This pipeline relies on decoupling producers from consumers using message queues, ensuring that a spike in one layer does not necessarily lead to a total system failure. The ingestion layer The Ingestion Layer is the system’s front door. It is responsible for collecting raw telemetry from diverse sources such as EDR agents, cloud APIs and firewalls. To handle the “firehose” of incoming data, which can spike unpredictably during a security incident, this layer does not process data immediately. Instead, it acts as a high-throughput buffer, writing raw events directly into a raw event queue (typically Apache Kafka). This decoupling is critical because it ensures that even if downstream processing layers are slow, the system can still accept incoming logs without data loss. The normalization layer The normalization layer consumes raw events from the initial queue. Its primary role is to bring order to chaos by parsing heterogeneous log formats (JSON, XML or Syslog) into a structured schema like the common information model (CIM). This involves CPU-intensive tasks such as regex matching, field extraction and enrichment. Once processed, these structured events are published to a second normalized event queue. This central bus becomes the single source of truth for all downstream consumers. The rule-based detection layer (real-time) The first consumer of the normalized queue is the rule-based detection layer, often powered by engines like Apache Flink in the last 2-3 years. This layer is optimized for speed, executing low-latency, rule-based logic on events as they flow through the pipe. It handles high-volume, simple detections, such as “five failed logins in one minute,” in milliseconds. By alerting on these patterns immediately, it reduces the time-to-detect for critical threats without waiting for data to be indexed. The ad-hoc search layer Parallel to the streaming engine, the ad-hoc search layer also consumes from the normalized queue. This system (often utilizing Elasticsearch or Splunk indexers) is optimized for human interaction. It indexes the data to support sub-second search and retrieval, enabling security analysts to perform investigations and threat hunting. While the streaming layer finds known threats, this layer helps analysts find the unknown ones through interactive querying. The storage layer (long-term retention) Simultaneously, a third consumer reads from the normalized queue to persist data into the storage layer. This layer is architected for durability and cost-efficiency, typically writing data to object storage (like Amazon S3) in a columnar format (such as Parquet). This “cold storage” ensures compliance with data retention policies at a fraction of the cost of the high-performance search tier, effectively decoupling retention from compute. The analytics and correlation layer (batch) Finally, the analytics and correlation layer operates by consuming data from the storage layer. Unlike the streaming engine, which looks at individual events in motion, this layer executes complex queries over vast historical datasets. It runs scheduled jobs to detect sophisticated patterns, such as “beaconing to a rare domain over thirty days,” that require analyzing long time windows. By reading from storage rather than the real-time stream, it isolates these resource-intensive jobs from the ingestion and search pipelines. Summary of SIEM layers LayerPrimary FunctionKey ChallengeIngestionCollects raw logs and buffers them into a Raw Queue.Handling massive throughput spikes without data loss.NormalizationParses raw logs into a common schema and publishes to a Normalized Queue.High CPU overhead from regex parsing and enrichment.Rule-based detectionConsumes normalized stream for fast, rule-based alerting.Managing state and windowing for millions of concurrent entities.Ad-hoc searchIndexes normalized data for fast, interactive investigation.Unpredictable resource consumption from complex analyst queries.StoragePersists normalized data for long-term retention.Optimizing file formats (Parquet or Avro) for efficient read and write.AnalyticsExecutes complex batch queries against storage.Scheduling long-running jobs without impacting other workloads. Strategies to encode fairness Without deliberate intervention, shared infrastructure will always favor the loudest voice. To build a resilient SIEM, engineers must implement strategies that enforce isolation and ensure equitable resource distribution. These strategies generally fall into three categories: admission control, tenant-aware scheduling and resource partitioning. Admission control and rate limiting The first line of defense is at the very front of the ingestion pipeline. Admission control ensures that a single tenant cannot flood the raw event queue beyond a certain threshold. However, modern SIEMs move beyond “hard” rate limits (where data is simply dropped) and instead use “soft” limits or shaping. A common approach is the token bucket algorithm. Each tenant is allocated a certain number of tokens per second, representing their licensed ingestion rate. During a spike, they can consume accumulated tokens to “burst” above their limit for a short duration. Once the bucket is empty, the system might begin “shaping” the traffic, introducing slight delays to the ingestion of that specific tenant’s logs to protect the system’s global stability without immediately discarding critical security data. In practice: A tenant contracted at 10,000 events per second might be permitted to burst to 15,000 EPS for up to 60 seconds by drawing on their accumulated token reserve. A real incident generating 20,000 EPS would exhaust the bucket and trigger shaping: their logs slow down, but nothing is dropped. Meanwhile, every other tenant on the platform continues processing at full speed. Tenant-aware fair share scheduling Inside the processing layers (such as normalization or analytics), the system must decide which tenant’s tasks to execute next. In a naive “first-in, first-out” (FIFO) model, a massive batch of logs from one tenant will block everyone else. Engineers solve this by implementing weighted fair queuing (WFQ). Instead of one giant queue for all events, the system maintains virtual queues for each tenant. The scheduler cycles through these queues, picking a small batch of events from each. This ensures that a small tenant with only ten events per second never has to wait behind a large tenant processing ten million. This “interleaving” of processing tasks guarantees that every customer makes progress, regardless of their neighbor’s activity. In practice: In a Kafka-backed SIEM, this is implemented by assigning each tenant their own partition (or partition group) within a topic. Normalization consumers are then configured to process a bounded number of records per tenant per poll cycle, cycling through partitions in round-robin order. A tenant generating a 50x spike in log volume gets their own partition filling up, but the consumer never spends more than its fair share of processing time on that partition before moving to the next tenant. Virtual resource isolation (quotas and reservations) For components like the ad-hoc search layer, where resource usage is highly unpredictable, engineers use resource partitioning. This involves setting up logical boundaries within the shared compute pool. Through resource quotas, the SIEM provider can cap the maximum CPU and memory a single tenant’s queries can consume at any given time. Some advanced architectures take this a step further with guaranteed reservations. A high-tier customer might be guaranteed a specific percentage of the cluster’s resources, ensuring that even during a global system spike, their SOC analysts can still run search queries with the same sub-second latency they expect. In practice: In Elasticsearch, this is implemented via a combination of search thread pool sizing per node and query-level circuit breakers. A tenant’s queries can be routed to a dedicated set of nodes (using shard allocation filtering), and the circuit breaker limits can be configured per tenant at the coordinating node layer. The result is that a runaway analyst query generating an expensive aggregation across 90 days of data will hit its memory ceiling and fail gracefully, rather than cascading across the entire cluster. Per-tenant buffering and decoupled processing In a highly resilient SIEM, I favor that backpressure (where a downstream failure forces the front-end to stop accepting data) should be avoided. Instead of pressuring the ingestion layer to stop, the system utilizes the queues positioned between each layer as shock absorbers. By implementing per-tenant virtual partitions within these queues, the system can ensure that a bottleneck in the storage or search layers only affects the processing speed of the responsible tenant. If one tenant’s data is being written too slowly, their specific virtual queue grows, while others continue to process at full speed. This results in delayed detection for the “noisy” tenant, but it guarantees data completeness. The system eventually catches up without ever dropping a log or impacting the real-time performance of the rest of the platform. The ultimate isolation: Physical vs. logical The strategies above address fairness within shared infrastructure. But for certain organizations, the right answer is no sharing at all. In a modern cloud environment, it is entirely feasible to provision and allocate an entire, independent SIEM stack per tenant. This “cluster-per-tenant” model eliminates the noisy neighbor problem entirely because there are no neighbors. Each customer’s ingestion pipeline, normalization workers, search nodes and storage buckets are fully dedicated to their own workload. The compliance implications alone make this worth serious consideration. Frameworks like FedRAMP, ITAR and CJIS often have explicit or implicit requirements around compute and data isolation that a shared multi-tenant cluster cannot satisfy without significant architectural gymnastics. A dedicated cluster satisfies these requirements cleanly, reduces audit surface area and simplifies the evidence chain during compliance reviews. The trade-off is cost. Dedicated clusters carry substantially higher per-tenant overhead: idle compute must be provisioned to handle peak loads, management complexity scales with cluster count and the economies of scale that make shared SaaS attractive are partially surrendered. In practice, providers who offer this model typically charge a meaningful premium (often 2-3x the multi-tenant equivalent) and reserve it for enterprise or public sector customers with specific regulatory requirements. The practical framework for security leaders evaluating this decision is straightforward. If your organization operates under a compliance framework that names compute or data isolation as a requirement, start with the dedicated cluster conversation. If your primary concern is detection performance and cost, invest time instead in understanding how deeply a vendor has engineered fairness into their shared environment, because that engineering is what determines whether the multi-tenant promise holds when it matters most. Conclusion The silence regarding multi-tenancy in major SIEM marketing is a risk that security leaders should not ignore. As telemetry volumes continue to explode, the engineering behind “fairness” becomes just as important as the AI detecting the threats. An ideal SIEM solution should offer the best of both worlds: the flexibility of a multi-tenant cluster where fairness is deeply engineered into every layer, combined with the option to deploy dedicated, physically isolated clusters for organizations with extreme performance or compliance needs. Until SIEM providers are transparent about how they manage the noisy tenants next door, the promise of 24/7/365 protection remains vulnerable to the activity of a neighbor you didn’t even know you had. This article is published as part of the Foundry Expert Contributor Network. Want to join? View the full article

DPRK-linked threat actors are preferring stealth over sophistication in targeting South Korean organizations, as researchers report the use of weaponized Windows shortcut (.LNK) files and GitHub-based command-and-control (C2) channels in a new campaign. According to new Fortinet findings, a series of attacks that began in 2024 were found using a multi-stage scripting process and GitHub C2 to evade detection, with obfuscation improving with each iteration of the campaign. “In recent months, the threat actor has altered their tactics,” Fortinet researchers said in a blog post. “They now embed decoding functions within LNK arguments and include encoded payloads directly inside the files.” The ongoing campaign seems to be targeted at expanding DPRK’s surveillance within South Korea. The researchers noted that lesser obfuscation and heavier metadata in the previous iterations of the campaign allowed them to link it to attacks spreading the XenoRAT malware. Jason Soroko, senior fellow at Sectigo, believes the strategy aligns with the recent trend of attackers relying on built-in Windows utilities and legitimate services to carry out their objectives. “Modern cyber espionage has fundamentally shifted toward a highly evasive strategy known as living off the land,” he said, noting that attackers are increasingly abusing native tools like PowerShell and scheduled tasks to blend into normal system activity. LNK files are long known for their history of exploitation, with Microsoft issuing multiple patches and advisories over the years to curb their misuse. LNK files used as stealth loaders The campaign begins its infection with a Windows shortcut file, which is typically used to launch applications or open documents, but can also embed commands to execute scripts or binaries. “A .lnk file is how Windows handles shortcuts: Whenever you click on that Outlook icon on your desktop, you’re actually clicking on a separate file that uses the Outlook image and directs the operating system to open up Microsoft Outlook,” explained Jamie Boote, senior manager, strategic security consulting at Black Duck. “You can also create shortcut links (.lnk files) to websites, programs with additional commands, executable scripts, and just about anything else you could type into Windows’s Run command window.” The LNK files in the campaign use various scripts, including earlier versions with simple character concatenation to mask GitHub C2 address and the access token, the researchers said, adding that it was easy to determine that the script was meant to run a PowerShell command fetched from GitHub. Later versions shifted to basic character decoding functions, making detection a little trickier, but still had telling metadata like name, sizes, and modification dates that allowed researchers to connect it to the specific campaign. The name column repeatedly uses “Hangul document,” a pattern consistent with state-affiliated groups like Kimsuky, APT37, and Lazarus. In its latest iteration, the campaign operators have removed the identifying metadata, now using only a decoding function within the arguments. GitHub as C2 Researchers also highlighted the campaign’s use of GitHub as a C2 layer. Rather than communicating with suspicious-looking or newly registered domains, the malware interacts with GitHub repositories and APIs to receive instructions and exfiltrate data. “The fact that this shortcut file creates a chain that ultimately reaches out to a GitHub repository, and pulls scripts over the internet, should put network defenders on alert that even productivity platforms can be attack vectors,” Boote added. After infecting a system, the PowerShell scripts perform system checks to confirm the environment isn’t under analysis, ensure the malware persists after system reboot through the Scheduled Task, and collect detailed system information. Only then is a stable connection attempted with subsequent scripts, where additional modules and instructions are fetched from the attacker’s GitHub repository. The researchers flagged a GitHub account, “motoralis”, with consistent activity dating back to 2025, and other less frequent accounts, including “God0808RAMA,” “Pigresy80,” “entire73,” “pandora0009,” and “brandonleeodd93-blip.” Additionally, the blog post shared a set of URLs and hash functions to support detection efforts. View the full article

Authentication keeps breaking where it matters most: On regulated front lines such as healthcare, government, aerospace and travel. The core issue is not a lack of innovation. Instead, it is a brittle and fragmented ecosystem of cards, readers, middleware and software that rarely work together under real-world pressure. Even today’s “passwordless” solutions can be undermined by poor implementation, downgrades and fallback paths that attackers are quick to exploit. This article examines where these failures occur, why they persist and offers a practical blueprint for CISOs to guide their organizations and vendors toward resilient, phishing-resistant and field-ready authentication. The problem: Brittle by design Authentication is supposed to be the most reliable control in your security stack. Yet in many enterprises, it is often the most fragile because there are too many moving parts: Credential types, readers (contact, contactless, dual frequency), protocols, middleware, identity platforms and device operating system nuances. Any minor mismatch — such as an unexpected identifier format, a driver quirk, a browser nuance or a rushed patch — can quickly turn a mission-critical login into a service desk crisis. This is not just a theoretical risk; it is a daily reality for operations teams who must keep care units, field agents and front of house operations running smoothly. Sector snapshots: Where it breaks (and why that matters) Healthcare. Clinicians need tap and go speed with zero tolerance for downtime. One large hospital attempted to pair advanced HID SEOS credentials, which use privacy-preserving randomized IDs, with a clinical SSO platform that expects static IDs for user recognition. This architectural mismatch forced a choice between stronger privacy and reliable workflows. The project stalled until the team reverted to technology compatible with static IDs. In healthcare, even a minor glitch can quickly escalate into a patient safety incident. State & local government. Agencies rolled out unified FIDO2 credentials to cover both door access and laptop logons. However, they soon discovered that many rugged laptops did not include the low-frequency antenna needed for physical access. Teams either split credentials, which defeated the purpose or added external readers, which increased cost and complexity. Field users ended up carrying multiple badges and dongles, which is the opposite of resilience. Aerospace and Travel. Aerospace organizations that adopted proprietary card ecosystems, such as LEGIC encountered licensing constraints that limited which readers they could purchase and how quickly they could scale globally. In the travel sector, a cruise line’s shift to wristband credentials faced challenges with FIPS 201 requirements, which were designed for cards rather than wearables. This forced the company into custom engineering solutions. In these cases, innovation moved faster than standards and operational teams had to manage the consequences. Root causes: Why the ecosystem is stuck Fragmentation across layers. Cards like SEOS, LEGIC, DESFire and FIDO2, mixed with contact, contactless and dual‑frequency readers and identity stacks such as Imprivata, Windows Hello, Okta and Ping rarely interoperate cleanly. A change in any layer can trigger unexpected failures across the system. Downgrades and fallback weaknesses. Authentication remains only as strong as its weakest backup path. Adversary‑in‑the‑middle and downgrade attacks routinely bypass phish‑resistant flows, as shown in CSO reporting on FIDO passkey downgrade exploits and ongoing MFA‑fatigue attacks. These gaps quietly reintroduce risk despite modern authentication advances. Patch fragility. Platform updates often break authentication flows, with CSO documenting cases where Windows updates disrupted smart card logons and Windows Hello for Business. These incidents, including the ones covered in Microsoft updates, knock out key enterprise functions. And Windows Hello for Business authentication issues, show how sensitive authentication stacks are to version drift. Vendor lock‑in and standards gaps. Proprietary licensing and uneven SDKs limit flexibility and slow upgrades. Progress toward interoperability profiles is emerging, but only when customers demand it. Okta’s IPSIE standard is one example, though broad adoption still depends on pressure from buyers. The path forward: 3 architectural shifts that can help Three architectural shifts can significantly improve reliability and reduce unexpected failures. These approaches are not mutually exclusive and can be combined for maximum effectiveness on a single platform. 1) Modular secure elements (SEs) embedded or in SIM form Device-bound cryptography, tamper resistance, ultra-low-power states and tighter OEM control over firmware and BIOS all raise the baseline for security and reliability. This is especially valuable in rugged or clinical environments, where device identity and offline resilience matter. Embedded secure elements help here by removing dependence on external readers and unstable drivers, though they introduce their own tradeoffs such as vendor lock‑in, added board and firmware complexity and reliance on specialized parts that can create yet another integration challenge if no common profile exists. The most effective way to adopt them is to start with a narrow, high‑value fleet like emergency carts, field supervisors or flight line tablets, pairing the secure element with a hardened, signed image and an offline‑ready authentication posture so it can serve as the root of trust for both login and data at rest. 2) Middleware standardization (make the reader/credential layer pluggable) Middleware becomes the universal bridge that smooths out card and reader quirks, giving you a stable way to integrate with identity platforms like Entra, Okta, Ping or Imprivata while normalizing identifiers, enforcing anti‑downgrade logic and capturing every strange edge case for rapid incident response. It comes with its own hurdles, including unclear ownership, upfront integration work and competing SDKs, yet once it’s in place you separate authentication behavior from device idiosyncrasies and vendor swaps, which is a major win for operations. The cleanest path is to stand up a credential abstraction layer with clear policies that block legacy fallbacks on high‑risk apps, enforce phishing‑resistant flows and log any downgrade decisions as security events sent to the SOC, while also applying session‑protection controls that blunt adversary‑in‑the‑middle attacks. 3) Unified credential ecosystem (the “USB‑C moment” for authentication) Standard behavior across readers, middleware and identity providers creates a calmer edge environment, cutting down on surprise failures and the weekend firefighting that follows patch cycles. The model isn’t free—you need industry coordination, legacy bridges and steady change management—but the direction is already set toward credential abstraction with multiprotocol support and reference integrations that vendors certify together. The cleanest way to land this is through RFP requirements that demand multiprotocol credential handling, verified reader and IdP compatibility, documented anti‑downgrade behavior and clear runbooks for regression handling after OS or IdP updates, with payments and renewals tied directly to meeting those standards. CISO action plan: 5 moves that change outcomes this quarter Kill the weakest link: Remove silent fallbacks. Identify where passwordless flows still revert to legacy prompts such as SMS, voice, OTP or simple approval pushes. On systems handling money, PHI or privileged access, disable or tightly control these paths. If a fallback is unavoidable, require identity verification and alert the SOC for review. Downgrade paths and MFA fatigue attacks often succeed because weak backups are left in place, as detailed here. Demand downgrade transparency in your tooling. Require your IdP or middleware to log every downgrade event and block scripted browser or agent spoofing that drives users into fake “unsupported browser” flows. Downgrade bypasses in passkey and FIDO flows have been demonstrated in the wild, so your stack should make these attempts easy to detect and simple to shut down. A clear example is outlined here. Harden for patch turbulence (assume authentication regressions). Create a pre‑prod integration gauntlet that exercises smart cards, passkeys, Windows Hello key trust and your clinical or field SSO flows. Hold broad deployment until the gauntlet passes and keep a one‑click rollback and a ready‑to‑send communications script. Recent Windows updates have shown how quickly authentication can break at scale, so build muscle‑memory playbooks before Patch Tuesday. Examples include Write interoperability into contracts. RFPs should call out multi‑protocol credential abstraction, certified reader and IdP pairings, FIDO2 and passkey support without insecure fallbacks and alignment with emerging interoperability profiles. Vendors are already moving in this direction and Okta’s IPSIE standard is one example worth citing. Pick the right pilot: Constrained, high‑value and visible. Start where downtime is costly and users are already trained, such as ICU stations, air‑side operations or revenue desks. Pair embedded secure‑element devices with reader‑agnostic middleware and strict anti‑downgrade policies. Track MTTR for authentication incidents, downgrade frequency and help‑desk volume, then publish the results to justify a broader rollout. The long view: Resilience over fashion Passkeys and FIDO2 move authentication in the right direction when they are deployed without porous fallbacks and with integrations that behave consistently under pressure. Their security and usability advantages are clear, yet real‑world usage has also shown how adversary‑in‑the‑middle techniques and weak backup paths can undermine those gains. These issues are not reasons to slow adoption but reminders to approach implementation with discipline. To build authentication that remains stable even as systems evolve, we need interoperability, anti‑downgrade behavior as the default and graceful failure modes. That means using modular hardware where it fits, relying on reader‑agnostic middleware with enforceable policy and pushing for a unified credential experience that vendors certify and customers insist on. Components exist today; what’s missing is the resolve to wire them together. Do not invest in another point solution until your contracts, runbooks and pilots reflect these principles. Authentication should be the calmest, most predictable part of your stack, not the source of your next incident. The building blocks for resilient, interoperable authentication already exist. What’s missing is resolve. Now is the time for security leaders to set the standard and demand better. Make authentication work for you, not against you. This article is published as part of the Foundry Expert Contributor Network. Want to join? View the full article

Attackers are starting to exploit AI systems to mount attacks in the same way they once relied on built-in enterprise tools such as PowerShell. Instead of relying on malware, cybercriminals are increasingly abusing AI tools enterprises depend on — a trend some experts describe as living off the AI land. “We’re seeing it in things like poisoned MCP servers in the supply chain, attackers using legitimate models like Claude to extract sensitive data, and even viral agents like OpenClaw accidentally causing destructive actions,” says Kaushik Shanadi, CTO at Helmet Security, a startup focused on securing agentic AI communications. “The problem is most of these systems were deployed before anyone stopped to think about governance or security.” The shift from simple prompt injection to “agent hijacking” represents a fundamental change in the AI threat landscape, other security experts told CSO. “Attackers are no longer just trying to trick a chatbot; they are living off the AI land, abusing the same legitimate automation and memory features that make AI assistants useful,” says Pascal Geenens, VP of cyber threat intelligence at cybersecurity vendor Radware. Below are some examples of how attackers are subverting AI-based services to stage attacks. MCP server impersonation In September 2025, attackers promoted a counterfeit model context protocol (MCP) server mimicking technology to integrate Postmark, a transactional email service owned by ActiveCampaign, into AI assistants. The fake MCP server package looked legitimate and functioned as a legitimate tool across 15 versions before a single-line code change was introduced that meant sensitive communications — password resets, invoices, internal memos — were silently siphoned off for days before the hack was detected. The malicious package, which attracted 1,500 downloads per week on the popular node.js package registry, exposed enterprises that relied on the tool to a form of supply chain attack. “This is the AI equivalent of name-squatting a package registry, except there’s no central MCP authority verifying server identity and no cryptographic link between an MCP server and the organization it claims to represent,” says Brad Micklea, CEO at Jozu, an AI security and MLOps platform. “This breaks the trust model before the MCP is deployed.” MCP servers — which allow AI agents and chatbots to connect to data sources, tools, and other services — have recently become the target of varied (for example against Cursor’s built-in browser) and sustained malicious attacks. Locking down these systems to minimize risks has become a priority for enterprise CISOs. “These servers expose tools, memory, and APIs to AI agents so they can perform tasks,” says Zahra Timsah, PhD, CEO of i-GENTIC AI, an agentic AI governance platform. “If an attacker inserts a poisoned tool, modified connector, or malicious retrieval source into that chain, the AI agent can unknowingly execute it.” Abusing AI platforms as covert C2 channels Cybercriminals are also abusing AI platforms as covert command-and-control (C2) channels by turning AI services into proxies that hide malicious traffic inside the flow of legitimate content. Instead of running a dedicated C2 server, malware is programmed to fetch commands and exfiltrate data through AI services, circumventing traditional security controls in the process. For example, the SesameOp backdoor hid command traffic inside the OpenAI Assistants API, camouflaging instructions to malware as normal AI development activity. This is far from an isolated example and the potential for misuse is rife. For example, Check Point Research demonstrated how Microsoft Copilot and Grok might be manipulated through their public web interfaces to fetch attacker-controlled URLs and return responses. This behavior opens the door to abuse of AI systems without requiring an API key or authenticated account. Dependency poisoning in AI workflows Rather than attacking an AI system directly some assaults have relied on poisoning downstream dependencies that an agent relies on for data processing. In one case, a compromised NPM package was injected into an agentic workflow’s dependency chain. “This mirrors classical supply chain attacks (e.g. SolarWinds), but a poisoned dependency in an agentic pipeline doesn’t just leak data — it can alter the agent’s decision-making, tool selection, or output without any visible anomaly,” says Jozu’s Micklea. Double agents Some attackers are weaponizing vulnerabilities in agents rather than abusing components of an enterprise’s legacy IT infrastructure. For example, the “EchoLeak” command injection vulnerability in Microsoft 365 Copilot (CVE-2025-32711) shows that a single email with concealed prompt-injection instructions is sufficient to force the AI assistant to exfiltrate internal files and emails to an external server without user interaction. A series of vulnerabilities (such as CVE-2026-25253) in OpenClaw, the popular open-source personal AI assistant, created a route for a malicious website to take complete control of the developer’s AI agent. “More than 21,000 such instances were detected, and the researchers further observed that 12% of the skills marketplace for the OpenClaw platform was distributing malware,” says Dr. Suleyman Ozarslan, VP of Picus Labs at Picus Security, a specialist in breach and attack simulation. Security researchers at Varonis discovered an attack against Microsoft Copilot Personal that sidestepped built-in AI safeguards simply by asking for sensitive data twice. The Reprompt vulnerability — which effectively turned Microsoft Copilot into a data exfiltration tool — was reported to Microsoft, which has responded by issuing a patch. AI-orchestrated espionage campaigns Anthropic caught threat actors abusing Claude Code to manage operational tasks in a cyber-espionage campaign in September 2025. A suspected Chinese state-sponsored group designated GTG-1002 used Claude Code to execute 80-90% of tactical operations independently, at physically impossible request rates for human operators. Attackers abused the AI agentic capabilities of Claude Code to automate the process of scripting, target research, building attack tooling, and other functions. “The attackers decomposed their operation into thousands of small, individually innocuous tasks, combined with role-play framing that convinced the model it was operating as part of a legitimate security assessment,” explains Yagub Rahimov, CEO at cybersecurity startup Polygraf AI. Creating modular black-hat AI platforms The threat landscape has shifted from abusing chatbots to building dedicated, weaponized AI stacks like Xanthorox AI. Unlike general-purpose LLMs, Xanthorox is a purpose-built offensive platform designed specifically for cybercrime. The platform features modules for functions such as malware generation and vulnerability exploits. “Hexstrike AI Model Context Protocol (MCP) integration allows Xanthorox to move beyond mere ‘assisted’ hacking into the realm of fully autonomous agent systems, moving it into the realm of ‘vibe hacking,’” says Radware’s Geenens. Hexstrike is an open-source, AI-powered offensive security framework originally designed for ethical penetration testing. Check against delivery Zbyněk Sopuch, CTO of cybersecurity vendor Safetica, says that many attackers are no longer just exploiting software vulnerabilities, preferring instead to exploit the trust organizations place in AI. “This means security teams need to treat AI assistants the same exact way they treat human privileged users: with tight control, specific monitoring, and most importantly, never assume anyone or anything to be safe,” Sopuch concludes. View the full article

Over the years, enterprise cybersecurity environments have accumulated staggering numbers of commercial tools. Industry research converges on a consistent picture of tool proliferation that drives complexity, cost, and risk. The global cybersecurity market is valued at approximately $243 billion in 2024 and projected to surpass $520 billion annually by 2026. Commercial off-the-shelf (COTS) software promises speed and maturity, while avoiding years of custom development. At first, everything works out perfectly, and the decision feels justified. However, over time, the organization might shift its goals, integrate with other systems, or even decide to move away from the software entirely. This is when real problems start to appear, and teams suddenly realize just how difficult it is to move on. Making basic changes might take ages, replacing the systems feels risky, and the organization is stuck in a conundrum. What we call the “COTS trap”. The cost of COTS dependency becomes most visible when organizations attempt to switch platforms. Migration failure statistics underscore the depth of architectural entanglement that COTS platforms create. It’s because the system around it was designed in such a way that it makes the software hard to abandon. COTS dependency in cybersecurity is structural, expensive, and accelerating. Organizations that fail to implement architectural countermeasures face compounding costs, diminished strategic flexibility, and increasing vulnerability to both cyber threats and vendor disruption. What is COTS, and why do people like it? COTS (short for commercial off-the-shelf software) refers to ready-made software usually sold online or in retail stores. They come with preconfigured functionalities right out of the box, hence they need little to no modifications. Examples include: IAM GRC IGA Threat detection platform Most enterprises like them because: They already ”work.” They deploy easily and quickly. Reduced long-term expenditure as promised by vendors. At a glance, these benefits are compelling. The challenges arise when the software becomes more than a tool and starts shaping the architecture itself. Emerging dynamics: AI and the next wave of lock-in Artificial intelligence represents both the next frontier of cybersecurity capability and the next vector of vendor dependency. McKinsey’s 2024/2025 study identifies AI as expanding the total addressable cybersecurity market to $2 trillion. AI-driven security platforms, from behavioral analytics to automated threat detection to AI-powered SIEM, create new forms of COTS dependency. AI models are trained on proprietary datasets, use vendor-specific threat intelligence feeds (62% of enterprise deployments integrate threat intelligence consuming 2.4 billion daily indicators of compromise), and require specialized compute infrastructure. The investment in AI-based detection models creates a new category of switching cost: retraining models, re-establishing behavioral baselines, and losing institutional threat intelligence. Organizations adopting AI-native security platforms face the risk that their threat detection effectiveness becomes linked to a single vendor’s model training data and algorithmic approach. How vendor lock-in forms in enterprise security architectures Vendor lock-in rarely happens overnight. Instead, it emerges gradually as technical and business decisions accumulate. How? Embedded business logic After using the software for a while, the enterprise gets comfortable, and important rules such as pricing logic and validations end up being buried within the software. With time, the enterprise gradually loses direct control over its own logic. Vendor-shaped workflows “That’s how the system works” has quickly become an excuse for most businesses to change workflows to match the software’s limits. This means a lot of processes will either be simplified, bent, or even deemed “good enough”, just because changing them feels too hard. Platform-native customization When changes are needed, teams usually add custom scripts, configurations, and extensions to ensure the software fits even better. And even though this might be practical, even necessary at that time, they are usually tailored to that particular vendor’s platform. Data entanglement Put simply, your data becomes trapped in formats and structures that only the vendor understands. Reading it becomes hard, slow, and expensive. This makes moving on difficult as the data holds the enterprise hostage. Architectural patterns that break the COTS trap Escaping the COTS trap doesn’t mean avoiding commercial software. It means designing systems so the software never becomes the point of control. Solution 1: The anti-corruption layer This simply means having a buffer between your systems and the software. Its core purpose is to ensure the two don’t communicate directly. It acts as the translator so that your systems continue speaking your business language. The vendor system remains a tool, not the architectural foundation for your business model. Solution 2: Process abstraction pattern Don’t allow the software to dictate how you’ll run your enterprise. Instead, you should define your system independent of the vendor’s software. The software should only be used to perform specific tasks. That way, it will be way easier for you to change your business model without replacing the entire software. Not just that, you can also replace the software without affecting your business model. Solution 3: Event-driven integration Point-to-point integrations usually tighten systems together. Event-driven integration prevents this by sharing simple facts about what has happened, rather than issuing direct requests. This allows systems to act independently, evolve at their own pace, and be replaced without affecting others. Solution 4: Strangler fig pattern Changing systems should always be done slowly and not all at once. Replace small pieces step by step. Allow the old and new systems to run together. Gradually move your users and data. In case something goes wrong, it will be easier to stop and retrace your steps without crashing the system. Solution 5: Data sovereignty strategy Your most crucial data should always reside within your system under your control. Vendor platforms receive copies, not ownership. This will allow you to easily move, integrate, or even replace systems without losing access to your data. Designing for replaceability: Architectural principles This is where most enterprises get it all wrong. Treating COTS software as the final solution from the get-go. Once selected, purchased, and installed, everything else around it has to adapt to it. Most processes are bent, data models stretched, and architecture redefined to fit what the software requires. The outcome? Replacing it becomes unthinkable. This kind of thinking is the real problem, not the software itself. COTS was designed to improve productivity and efficiency. It wasn’t meant to define your long-term structure. In today’s ever-changing landscape, nothing is guaranteed to remain the same. Software that fits today will not always fit tomorrow. Hence, systems should be designed with the assumption that the vendor platform can be replaced anytime the business changes its goals, market shifts, regulations evolve, or strategies get rewritten. When you approach it in this way, you become flexible by default. You remain in charge of your own systems, and you don’t surrender control to vendors. Most importantly, you do away with last-minute rewrites that occur when change is forced. The goal here isn’t to switch platforms constantly, but to ensure that you can do it when you need to. That’s what it means to design enterprise systems you can walk away from. Conclusion: Flexibility matters in architectural design The cybersecurity industry’s COTS dependency is not a failure of procurement. It is a structural characteristic of a market growing at 10–15% annually, with 3,000+ vendors competing for enterprise budgets. The $212 billion spent on cybersecurity in 2025 flows overwhelmingly through COTS channels, creating dependencies that are expensive to establish, costly to maintain, and extraordinarily difficult to exit. Purchasing the most powerful commercial off-the-shelf software doesn’t always guarantee success. Successful enterprises are those whose systems are built to adapt to any platform change. That also doesn’t mean that COTS software is bad, and that you shouldn’t use it. Rather, you should know how to use it. Most enterprises miss the mark by treating these vendor platforms as the foundation for their entire architecture, rather than what they actually are: a tool and nothing more. Given the confusion around this, most enterprises usually end up stuck in a no-win situation simply because their systems are forced to mimic what the vendor platform wants, not the other way around. To get the best out of any COTS software, clear boundaries should be set, and strong domain ownership established. Because, at the end of it all, good architecture isn’t just picking the best platform. It’s more about ensuring that the choice you make today doesn’t limit your options later. Flexibility matters a lot in the architectural design of any enterprise system. It ensures that the organization remains functional and survives any unforeseen changes. Such freedom is what allows enterprises to get the best out of these platforms. Organizations that architect for strategic independence from day one transform the COTS dependency from a trap into a tool, leveraging commercial platforms for their strengths while retaining the flexibility to adapt, migrate, and evolve at the pace of business need rather than vendor roadmap. This article is published as part of the Foundry Expert Contributor Network. Want to join? View the full article

An apparent security lapse has allowed researchers to peer into the work of a threat group currently exploiting unpatched servers open to the four-month-old React2Shell vulnerability to steal login credentials, keys, and tokens at scale. Researchers from Cisco Systems’ Talos threat intelligence team who made the discovery said Thursday that the data harvested by an unattributed group they call UAT-10608 went to a password protected database behind a web application. However, that application was at one point exposed, allowing the researchers to see data that had been harvested from compromised systems. Credentials, as well as Auth tokens and more, that have been stolen so far come from instances of AWS, Microsoft Azure, OpenAI, Anthropic, Nvidia NIM, OpenRouter, Tavily, payment processor Stripe, and GitHub. The web application allows a user to browse all of the compromised hosts. A given host can then be selected, bringing up a menu with all of the exfiltrated data corresponding to each phase of the harvesting script – a bonus to the researchers. The discovery is a prime reason for IT pros with React servers in their environment who haven’t yet addressed this vulnerability to act quickly, before corporate credentials are stolen. To help blunt the attack, victims, and service providers with exposed and at-risk credentials, including AWS and GitHub, are being notified. One notable statistic: The automated exploitation and harvesting framework was able to successfully compromise 766 hosts within a 24 hour period. At risk are Next.js applications vulnerable to CVE-2025-55182, a pre-authentication remote code execution vulnerability known as React2Shell. A fix was issued four months ago. Multi-phase attack Once a host is compromised, the campaign deploys a multi-phase credential harvesting tool that collects usernames, passwords, SSH keys, cloud tokens, and environment secrets, at scale. “The breadth of the victim set and the indiscriminate targeting pattern is consistent with automated scanning,” says Cisco Talos, “likely based on host profile data from services like Shodan, Censys, or custom scanners to enumerate publicly reachable Next.js deployments and probe them for the described React configuration vulnerabilities.” The attacker crafts a malicious serialized payload designed to abuse the deserialization routine, a technique commonly used to trigger arbitrary object instantiation or method invocation on a server. The payload is sent via an HTTP request directly to a Server Function endpoint; no authentication is required. The server deserializes the malicious payload, resulting in arbitrary code execution in the server-side Node.js process. The initial React exploit delivers a small dropper that fetches and runs a multi-phase harvesting script. Upon execution, the harvesting script goes through several phases to collect various data from the compromised system, which is then uploaded to a command and control server where it is loaded into a database. Industrial scale “This is all about neglect and efficiency,” Gene Moody, field CTO at patch management provider Action1, told CSO . “React2Shell quickly met all the criteria attackers look for: public disclosure, reliable exploitation, and internet-facing exposure. That combination effectively guaranteed widespread abuse. Since then, multiple campaigns have automated the full [attack] lifecycle [of], scanning, exploitation, and credential harvesting, with little to no human intervention.” Attackers operate at industrial scale, he added. Platforms like Shodan and Censys already index much of the internet, making vulnerable systems trivial to find. With the finite IP space, comprehensive scanning can be completed in well under an hour on even the most modest of modern computers/internet connections. “There is no meaningful obscurity left for exposed systems,” he added. “To be honest, there never really was.” ‘Attack started when you failed to patch’ The result is predictable, Moody said: Unpatched systems are not ‘at risk’, they are in a queue. Discovery is fast, exploitation is fast, and compromise is often automated end-to-end. “React2Shell is a perfect example of how quickly attackers can turn a known issue into a sustained revenue stream, and have it persist for extended periods of time based on admin complacency,” he said. “Even more concerning is what happens after initial access,” he added. “Credential harvesting extends the lifespan of the attack far beyond the original vulnerability. Even if systems are patched later, stolen credentials can enable persistence, lateral movement, and, as a result, means the attack started when you failed to patch. One mistake can turn into every mistake in an instant, with information like this in the wrong hands. The damage could be absolute, with no recovery possible. Businesses have failed for less. When it ends will certainly not be when the patch is applied, unless you got it before being compromised. “Treat your patching like a toothache,” he advised. “At first sign, address it as fast as possible, or only misery follows.” View the full article

An apparent security lapse has allowed researchers to peer into the work of a threat group currently exploiting unpatched servers open to the four-month-old React2Shell vulnerability to steal login credentials, keys, and tokens at scale. Researchers from Cisco Systems’ Talos threat intelligence team who made the discovery said Thursday that the data harvested by an unattributed group they call UAT-10608 went to a password protected database behind a web application. However, that application was at one point exposed, allowing the researchers to see data that had been harvested from compromised systems. Credentials, as well as Auth tokens and more, that have been stolen so far come from instances of AWS, Microsoft Azure, OpenAI, Anthropic, Nvidia NIM, OpenRouter, Tavily, payment processor Stripe, and GitHub. The web application allows a user to browse all of the compromised hosts. A given host can then be selected, bringing up a menu with all of the exfiltrated data corresponding to each phase of the harvesting script – a bonus to the researchers. The discovery is a prime reason for IT pros with React servers in their environment who haven’t yet addressed this vulnerability to act quickly, before corporate credentials are stolen. To help blunt the attack, victims, and service providers with exposed and at-risk credentials, including AWS and GitHub, are being notified. One notable statistic: The automated exploitation and harvesting framework was able to successfully compromise 766 hosts within a 24 hour period. At risk are Next.js applications vulnerable to CVE-2025-55182, a pre-authentication remote code execution vulnerability known as React2Shell. A fix was issued four months ago. Multi-phase attack Once a host is compromised, the campaign deploys a multi-phase credential harvesting tool that collects usernames, passwords, SSH keys, cloud tokens, and environment secrets, at scale. “The breadth of the victim set and the indiscriminate targeting pattern is consistent with automated scanning,” says Cisco Talos, “likely based on host profile data from services like Shodan, Censys, or custom scanners to enumerate publicly reachable Next.js deployments and probe them for the described React configuration vulnerabilities.” The attacker crafts a malicious serialized payload designed to abuse the deserialization routine, a technique commonly used to trigger arbitrary object instantiation or method invocation on a server. The payload is sent via an HTTP request directly to a Server Function endpoint; no authentication is required. The server deserializes the malicious payload, resulting in arbitrary code execution in the server-side Node.js process. The initial React exploit delivers a small dropper that fetches and runs a multi-phase harvesting script. Upon execution, the harvesting script goes through several phases to collect various data from the compromised system, which is then uploaded to a command and control server where it is loaded into a database. Industrial scale “This is all about neglect and efficiency,” Gene Moody, field CTO at patch management provider Action1, told CSO . “React2Shell quickly met all the criteria attackers look for: public disclosure, reliable exploitation, and internet-facing exposure. That combination effectively guaranteed widespread abuse. Since then, multiple campaigns have automated the full [attack] lifecycle [of], scanning, exploitation, and credential harvesting, with little to no human intervention.” Attackers operate at industrial scale, he added. Platforms like Shodan and Censys already index much of the internet, making vulnerable systems trivial to find. With the finite IP space, comprehensive scanning can be completed in well under an hour on even the most modest of modern computers/internet connections. “There is no meaningful obscurity left for exposed systems,” he added. “To be honest, there never really was.” ‘Attack started when you failed to patch’ The result is predictable, Moody said: Unpatched systems are not ‘at risk’, they are in a queue. Discovery is fast, exploitation is fast, and compromise is often automated end-to-end. “React2Shell is a perfect example of how quickly attackers can turn a known issue into a sustained revenue stream, and have it persist for extended periods of time based on admin complacency,” he said. “Even more concerning is what happens after initial access,” he added. “Credential harvesting extends the lifespan of the attack far beyond the original vulnerability. Even if systems are patched later, stolen credentials can enable persistence, lateral movement, and, as a result, means the attack started when you failed to patch. One mistake can turn into every mistake in an instant, with information like this in the wrong hands. The damage could be absolute, with no recovery possible. Businesses have failed for less. When it ends will certainly not be when the patch is applied, unless you got it before being compromised. “Treat your patching like a toothache,” he advised. “At first sign, address it as fast as possible, or only misery follows.” View the full article

When Daniel Rhyne pleaded guilty on April 1 to having launched an insider extortion attack against his then-employer, authorities enumerated the techniques he used, including unauthorized remote desktop sessions, deletion of network administrator accounts, changing of passwords, and scheduling unauthorized tasks on the domain controller. After he shut down key systems and accounts, he sent a note to employees in which he claimed to have deleted all backups, and threatened to continue shutting down servers unless he was given bitcoin worth roughly $750,000. But what consultants and analysts found most concerning is how commonplace and routine were the techniques he used. In other words, standard security procedures should have blocked almost all of them. Preventive actions missing Enterprise insider threats are hardly new, but consultants and analysts said that many enterprises don’t take every preventive move that they can, and should, because the IT staff resists, seeing the efforts as excessive monitoring of their activities, and something that also slows down their work. Cybersecurity consultant Brian Levine, executive director of FormerGov, said, “what makes the case interesting was how boringly predictable the attack path was.” Levine noted that backups need to always be immutable. “Nobody in the company should be able to delete or modify or encrypt the backup for a set period of time,” he said. He also stressed that the principle of least privilege needs to be applied to workers whose jobs change for any reason. Critically, he argued that the use of various tools should be instantly flagged as concerning. “Instrument Task Scheduler, PsExec, PsPasswd, and net user are high‑risk signals. These are the insider’s equivalent of lockpicks,” he said. “They should generate behavioral alerts when used at scale, off‑hours, or from unusual hosts.” Levine also suggested extensive system monitoring. “If someone is RDP’ing into a domain controller at 7:48 a.m. and creating 16 scheduled tasks, you should have a video‑like audit trail.” Paul Furtado, a distinguished VP analyst at Gartner, said he encourages clients to make sure that no single admin can cause this kind of damage. “Create a tiered administration model with fragmented authority. This rotates ownership of crown jewel processes, even among senior engineers and administrators,” Furtado advised. IT should also include “a break-glass admin credential stored in hardware security modules or digital vaults [that are] only to be used via testing drills and in case of emergency.” Added Flavio Villanustre, CISO for the LexisNexis Risk Solutions Group, “the same accounts used to administer their networks [in the Rhyne case] seemed to be able to irreversibly destroy their backups too, which is an indication that strong segregation of duties was not in place.” Rhyne now faces considerable jail time. US Justice Department filings said, “the extortion charge to which Rhyne pleaded guilty carries a maximum penalty of five years in prison, and the intentional damage to a protected computer violation to which Rhyne pleaded guilty carries a maximum penalty of 10 years in prison.” View the full article

Google has patched another zero-day vulnerability in Chrome, its fourth this year. In patching the vulnerability, tracked as CVE-2026-5281, the company acknowledged that an exploit for it already exists in the wild. According to the report in NIST’s National Vulnerability Database, the vulnerability in Dawn, the implementation of WebGPU used by Chrome, allowed a remote attacker who had compromised the renderer process to execute arbitrary code via a crafted HTML page. It advised users to update to Chrome 146.0.7680.178 or newer. The three previous vulnerabilities patched in Chrome this year were in different areas of the code. The first, tracked as CVE-2026-2441 and patched in February, was a fault in the way memory was managed in the processing of cascading style sheets (CSS). The other two were patched in March. One was a bug in the Skia graphics library (CVE-2026-3909) that allowed write access to memory addresses outside the boundaries of a predefined buffer. The second one (CVE-2026-3910) was found in the V8 JavaScript engine, and was described by Google as an “inappropriate implementation.” It will concern Google that, barely a quarter way through the year, it has already had to deliver fixes for four exploits in the wild. Last year, it introduced Code Mender, a security tool to help fix security vulnerabilities in open source projects, and will be looking to introduce more AI help to fix these issues. View the full article

Researchers who identify and report bugs in open-source software will no longer be rewarded by the Internet Bug Bounty team. HackerOne, which administers the program, has said that it is “pausing submissions” while it contemplates ways in which open source security can be handled more effectively. The Internet Bug Bounty program, funded by a number of leading software companies, has been run since 2012 and has awarded more than $1.5m to researchers who have reported bugs. Up to now, 80% of its payouts have been for discoveries of new flaws, and 20% to support remediation efforts. But as artificial intelligence makes it easier to find bugs, that balance needs to change, HackerOne said in a statement. “AI-assisted research is expanding vulnerability discovery across the ecosystem, increasing both coverage and speed. The balance between findings and remediation capacity in open source has substantively shifted,” said HackerOne. Among the first programs to be affected is the Node.js project, a server-side JavaScript platform for web applications known for its extensive ecosystem. While the project team will continue to accept and triage bug reports through HackerOne, without funding from the Internet Bug Bounty program it will no longer pay out rewards, according to an announcement on its website. The Internet Bug Bounty Program is not the only bug-hunting project that has struggled with the onset of AI in vulnerability hunting. In January, the Curl program said that it was not taking any more submissions. And just last month, Google also put a halt to AI-generated submissions provided to its Open Source Software Vulnerability Reward Program. This article first appeared on InfoWorld. View the full article

The leak of Claude Code’s source is already having consequences for the tool’s security. Researchers have spotted a vulnerability documented in the code. The vulnerability, revealed by AI security company Adversa, is that if Claude Code is presented with a command composed of more than 50 subcommands, then for subcommands after the 50th it will override compute-intensive security analysis that might otherwise have blocked some of them, and instead simply ask the user whether they want to go ahead. The user, assuming that the block rules are still in effect, may unthinkingly authorize the action. Incredibly, the vulnerability is documented in the code, and Anthropic has already developed a fix for it, the tree-sitter parser, which is also in the code but not enabled in public builds that customers use, said Adversa. Adversa outlined how attackers might exploit the vulnerability by distributing a legitimate-looking code repository containing a poisoned CLAUDE.md file. This would contain instructions for Claude Code to build the project, with a sequence of 50 or more legitimate-looking commands, followed by a command to, for example, exfiltrate the victim’s credentials. Armed with those credentials, the attackers could threaten a whole software supply chain. This article first appeared on Infoworld. View the full article

The European Union’s Computer Emergency Response Team, CERT-EU, has traced last week’s theft of data from the Europa.eu platform to the recent supply chain attack on Aqua Security’s Trivy open-source vulnerability scanner. The attack on the AWS cloud infrastructure hosting the Europa.eu web hub on March 24 resulted in the theft of 350 GB of data (91.7 GB compressed), including personal names, email addresses, and messages, according to CERT-EU’s analysis. The compromise of Trivy allowed attackers to access an AWS API key, gaining access to a range of European Commission web data, including data related to “42 internal clients of the European Commission, and at least 29 other Union entities using the service,” it said. “The threat actor used the compromised AWS secret to create and attach a new access key to an existing user, aiming to evade detection. They then carried out reconnaissance activities,” said CERT-EU. The organization had found no evidence that the attackers had moved laterally to other AWS accounts belonging to the Commission. Given the timing and involvement of AWS credentials, “the European Commission and CERT-EU have assessed with high confidence that the initial access vector was the Trivy supply-chain compromise, publicly attributed to TeamPCP by Aqua Security,” it said. In the event, the stolen data became public after the group blamed for the attack, TeamPCP, leaked it to the ShinyHunters extortion group, which published it on the dark web on March 28. Back door credentials The Trivy compromise dates to February, when TeamPCP exploited a misconfiguration in Trivy’s GitHub Actions environment, now identified as CVE-2026-33634, to establish a foothold via a privileged access token, according to Aqua Security. Discovering this, Aqua Security rotated credentials but, because some credentials remain valid during this process, the attackers were able to steal the newly rotated credentials. By manipulating trusted Trivy version tags, TeamPCP forced CI/CD pipelines using the tool to automatically pull down credential-stealing malware it had implanted. This allowed TeamPCP to target a variety of valuable information including AWS, GCP, Azure cloud credentials, Kubernetes tokens, Docker registry credentials, database passwords, TLS private keys, SSH keys, and cryptocurrency wallet files, according to security researchers at Palo Alto Networks. In effect, the attackers had turned a tool used to find cloud vulnerabilities and misconfigurations into a yawning vulnerability of its own. CERT-EU advised organizations affected by the Trivy compromise to immediately update to a known safe version, rotate all AWS and other credentials, audit Trivy versions in CI/CD pipelines, and most importantly ensure GitHub Actions are tied to immutable SHA-1 hashes rather than mutable tags. It also recommended looking for indicators of compromise (IoCs) such as unusual Cloudflare tunnelling activity or traffic spikes that might indicate data exfiltration. Extortion boost The origins and deeper motives of TeamPCP, which emerged in late 2025, remain unclear. The leaking of stolen data suggests it might be styling itself as a sort of initial access broker which sells data and network access on to the highest bidder. However, the fact that stolen data was handed to a major ransomware group suggests that affected organizations are likely to face a wave of extortion demands in the coming weeks. If so, this would be a huge step backwards at a time when ransomware has been under pressure as the proportion of victims willing to pay ransoms has declined. The compromise of Trivy, estimated to have affected at least 1,000 SaaS environments, is rapidly turning into the one of the most consequential supply-chain incidents of recent times. The number of victims is likely to grow in the coming weeks. Others caught up in the incident include Cisco, which reportedly lost source code, security testing company Checkmarx, and AI gateway company LiteLLM. View the full article

The 2026 RSA circus is over. The tents are packed and the elephants have been loaded onto the train. Nevertheless, it was an eventful week. There were fleets of vehicles — Escalades, Rivians, trucks but curiously, no Teslas — strewn with vendor names and tag lines, and you couldn’t walk anywhere near Howard Street in San Franciso without seeing, “AI-[insert word here like enabled, enhanced, native, powered, etc., etc., etc.]” I spent the week speaking with CISOs, cybersecurity professionals, technology vendors, and service providers. Here are a few of my takeaways. The CISO AI hierarchy is real While every vendor communicated AI opportunity gaga, cybersecurity professionals’ mood was one of trepidation. In fact, I came away with a profile of three distinct CISO archetypes: The proactive CISO (approximately 20%): These security leaders were well aware of the AI-driven business and technology changes afoot and came armed with a list of questions tailored to their specific enterprise requirements. Many of these executives brought along security engineers and architects — an action-oriented team. These CISOs had a decent understanding about their organization’s AI business initiatives, as well as their own security needs. The goal? Develop a shopping list that aligns with their organization’s strategy and supports their governance models, policy enforcement controls, and security technology stacks. The curious and confused CISO (approximately 40%): These executives know something is happening with AI in their organization, but they aren’t sure what, where, or how much is going on. Their goal was education — what risks they face, what risk mitigation steps they should take, and what’s available from the industry to help them stop the bleeding. CISOs in this category are somewhat desperate for help. The blissfully ignorant CISO (approximately 40%): Okay, this one is a bit unfair to CISOs as it’s more about their organizations. There’s likely AI development and usage the CISO and probably some executives are unaware of. They approached RSA believing time was on their side, so they probably skimmed through the AI rhetoric, shmoozed with vendors, and looked for the best cocktail parties. In my humble opinion, CISOs will cycle through this hierarchy quickly over the next year. Blissfully ignorant CISOs will get wind of AI projects at their organization and move on to curiosity and confusion. This won’t take long. Proceeding from curious and confused to proactive will be the more difficult transition. These CISOs must assess business objectives, active projects, and user activities, then work with executives to develop a governance framework, create policies, implement guardrails, monitor activities, and manage a flexible model that keeps up with current and future business and technical requirements. A common analogy heard at RSA is that companies must be able to fix the plane while it’s in flight. Legacy security vendors have the inside track on AI — for now As far as AI technology consumption for cybersecurity, most CISOs I spoke with were open-minded while leaning toward their existing vendors — at least in the short term. This may buy legacy security vendors a bit, but not much time. Remember what happened in the cloud as we progressed from a lack of cloud trust, to “lift and shift,” to cloud-native? The same thing is happening with AI, only even faster than the cloud. Bolting AI to existing tools won’t work for long, a year at most. You’ve got to get the AI foundations right I was encouraged to hear vendors describe how they started their AI transition by building an infrastructural foundation — data foundation/context engine, intelligent control plane, execution layer, services, guardrails, etc. — and then adding functional agents on top of this foundation. Cisco/Splunk impressed me with its development approach and roadmap, while AI-based startups such as Abstract, Crogl, and Sidekick are betting the farm on this methodology. AI code is making an impact Vendors are also all-in on using AI-development tools and seeing strong results. I heard about project acceleration along with staff reduction. Building connectors is a good example. Axonius and Tenable, both known for broad technology integration, are using AI to offload a lot of this tedious but necessary work, freeing developers to work on functionality rather than plumbing. AI pricing remains a mess While AI capabilities appear to be baked into many tools, I found that no one knows how to price their AI services. Some are doing so by the token, some by the number of users, and some are charging by the agent. The market will flush this out over the rest of the year. Application security is getting its AI makeover We all know the impact of AI on software development. It’s clear to me after RSA that the same thing is happening to application security. Anthropic’s Claude Code Security is one example, but I also got a view of the AWS Security Agent, which provides software testing capabilities across the software development lifecycle — from design, to development, to runtime, to red teaming. Likewise, I met with a company named XBow that focuses on autonomous offensive security based on AI agents. Based on these developments, we will see a very different application security market at RSA 2027. Few may be prepared for what comes next from cyber-adversaries There’s active debate in the industry about the impact of AI within the threat landscape: Are existing cybersecurity defenses adequate or will AI tilt the battlefield toward adversaries? After RSA, I believe both premises are true. Sophisticated firms with strong governance, risk management, asset visibility, modern training, and sound hygiene and posture management should be okay. Alarmingly, this is a small percentage of organizations. Most others lack advanced security skills and adequate resources. Adversaries armed with AI tools and automated workflows will have a field day here. Managed providers are advancing the AI SOC Managed security service providers (MSSPs) and managed detection and response (MDR) vendors are pushing the envelope on the AI-enabled security operations center (SOC). Arctic Wolf unveiled its Aurora Superintelligence Platform and the Aurora Agentic SOC, which includes agents for triage, alerting, investigations, and more. I also met with Ontinue, an MSSP that provides services on top of Microsoft security tools such as Defender for Endpoint, Defender for Azure, and MS Sentinel. It is using AI to establish what it calls “hyper-contextualization” to understand all it can about its customers’ business processes and technology infrastructure so it can improve decision-making. Microsoft cements its position Speaking of Microsoft, it’s hard to point to any other vendor that can match its cybersecurity coverage. Unlike others, Microsoft came to RSA armed with AI metrics and proof points. For example, Microsoft provided specific metrics from several customers that turned on its Defender agents and saved hundreds of hours of work while improving accuracy and productivity. I’m sure Microsoft has many examples to share. Beware the cyber category killers We’ve always viewed cybersecurity through the lens of security product categories — EDR, firewalls, SIEM, CSPM, etc. But multi-agent AI products could take on many of these tasks simultaneously, breaking down traditional product buckets and acting as category killers. CISOs must anticipate this and be open to organizational, process, and budgetary changes. Also, will multi-agent cybersecurity products mean the death of the Gartner Magic Quadrant and all other me-too vendor mapping products? Awareness training gradually transforms Training is in transition. I’m pleased with this development. Awareness training is being replaced by behavior monitoring and change. Human risk management (HRM) tools from Fable Security, KnowBe4, and Mimecast, among others, watch over users and provide a nudge when they go astray. Beyond synthetic phishing, some tools even provide synthetic deepfake training. HRM sales are limited today to progressive organizations, but I believe they will become a de facto standard as regulators and cyber-insurance companies see the light and support this training renaissance. Security claims ownership of identities Well, partial ownership, but this is a step in the right direction. I’m seeing interesting advancements in areas such as passwordless authentication (I can’t believe it’s 2026 and we’re still using passwords), browser security, non-human identity (NHI) security, and privileged account management. RSA also pushed discussions about AI-agent access and action control — detection, monitoring, control of shadow agents, zero-standing privilege, etc. AI will be a big player, helping to ease the painful identity modernization process. As a cryptographer might say, with this article, I’ve tried to hash the entire RSA event into a single key. I really enjoyed RSA 2026 (my 20th) and look forward to next year. See you at the Moscone Center from April 5 through April 8, 2027. View the full article

ArtemisDiana | shutterstock.com Manuelles, siloartiges Management ist in der modernen IT-Welt unangebracht. Erst recht im Bereich der IT-Sicherheit: Der Umfang von modernem Enterprise Computing und State-of-the-Art-Application-Stack-Architekturen erfordern Sicherheits-Tools, die: Einblicke in den Sicherheitsstatus von IT-Komponenten ermöglichen, Bedrohungen in Echtzeit erkennen, und Aspekte der Bedrohungsabwehr automatisieren. Diese Anforderungen haben zum Aufkommen von Extended-Detection-and-Response- (XDR) Lösungen geführt. Diese Sicherheits-Tools kombinieren die stärksten Elemente von Security Incident and Event Management (SIEM), Endpoint Detection and Response (EDR) und Security Orchestration and Response (SOAR) – und bauen darauf auf. XDR-Tools evaluieren Der Preis wird immer ein Schlüsselfaktor bei Enterprise-Sicherheitssystemen sein, die skalierbar sein müssen – da bilden auch XDR-Systeme keine Ausnahme. Die Lösungen im Bereich Extended Detection and Response sind fast ausschließlich abonnementbasiert, verursachen also laufende Kosten. Wie bei vielen Sicherheits-Tools stellen diese Kosten angesichts der finanziellen Risiken eines Datenverlusts oder den geschäftlichen Auswirkungen einer Kompromittierung einen guten Kompromiss dar. Gleiches gilt mit Blick auf den Personalaufwand, der nötig wäre, um mit bestehenden Systemen und manueller Korrelation von Ereignisdaten dasselbe Schutzniveau zu erreichen. Zu den wichtigsten XDR-Funktionen zählen: Die Möglichkeit zur Integration mit vorhandener Hardware, Software und Cloud-Investitionen. Das kann sich sowohl auf die Effektivität der gewählten Plattform sowie auf die Kosten und den Aufwand für die anfängliche Implementierung der Lösung auswirken. Richtlinien und Regeln managen zu können, ist ebenfalls von entscheidender Bedeutung. Nur so können Sie die XDR-Funktionen auf Ihre geschäftlichen Anforderungen abstimmen und Ihre IT-Sicherheitsteams in die Lage versetzen, effektiv auf Bedrohungen zu reagieren. Benutzerfreundlichkeit und Schulungsoptionen (entweder durch den Anbieter oder die Community) sind schließlich ebenfalls wichtig, damit sich Ihre Investition in eine XDR-Plattform langfristig bezahlt macht. Die besten XDR-Lösungen Nachfolgend haben wir einige der wichtigsten XDR-Tools in alphabetischer Reihenfolge für Sie zusammengestellt. Bitdefender GravityZone Business Security Enterprise CrowdStrike Falcon Insight XDR Cybereason XDR Cynet 360 AutoXDR Elastic Security for XDR Microsoft SecOps Palo Alto Networks Cortex XDR SentinelOne Singularity XDR Trellix XDR Platform Trend Micro Vision One (fm) View the full article

ArtemisDiana | shutterstock.com Manuelles, siloartiges Management ist in der modernen IT-Welt unangebracht. Erst recht im Bereich der IT-Sicherheit: Der Umfang von modernem Enterprise Computing und State-of-the-Art-Application-Stack-Architekturen erfordern Sicherheits-Tools, die: Einblicke in den Sicherheitsstatus von IT-Komponenten ermöglichen, Bedrohungen in Echtzeit erkennen, und Aspekte der Bedrohungsabwehr automatisieren. Diese Anforderungen haben zum Aufkommen von Extended-Detection-and-Response- (XDR) Lösungen geführt. Diese Sicherheits-Tools kombinieren die stärksten Elemente von Security Incident and Event Management (SIEM), Endpoint Detection and Response (EDR) und Security Orchestration and Response (SOAR) – und bauen darauf auf. XDR-Tools evaluieren Der Preis wird immer ein Schlüsselfaktor bei Enterprise-Sicherheitssystemen sein, die skalierbar sein müssen – da bilden auch XDR-Systeme keine Ausnahme. Die Lösungen im Bereich Extended Detection and Response sind fast ausschließlich abonnementbasiert, verursachen also laufende Kosten. Wie bei vielen Sicherheits-Tools stellen diese Kosten angesichts der finanziellen Risiken eines Datenverlusts oder den geschäftlichen Auswirkungen einer Kompromittierung einen guten Kompromiss dar. Gleiches gilt mit Blick auf den Personalaufwand, der nötig wäre, um mit bestehenden Systemen und manueller Korrelation von Ereignisdaten dasselbe Schutzniveau zu erreichen. Zu den wichtigsten XDR-Funktionen zählen: Die Möglichkeit zur Integration mit vorhandener Hardware, Software und Cloud-Investitionen. Das kann sich sowohl auf die Effektivität der gewählten Plattform sowie auf die Kosten und den Aufwand für die anfängliche Implementierung der Lösung auswirken. Richtlinien und Regeln managen zu können, ist ebenfalls von entscheidender Bedeutung. Nur so können Sie die XDR-Funktionen auf Ihre geschäftlichen Anforderungen abstimmen und Ihre IT-Sicherheitsteams in die Lage versetzen, effektiv auf Bedrohungen zu reagieren. Benutzerfreundlichkeit und Schulungsoptionen (entweder durch den Anbieter oder die Community) sind schließlich ebenfalls wichtig, damit sich Ihre Investition in eine XDR-Plattform langfristig bezahlt macht. Die besten XDR-Lösungen Nachfolgend haben wir einige der wichtigsten XDR-Tools in alphabetischer Reihenfolge für Sie zusammengestellt. Bitdefender GravityZone Business Security Enterprise CrowdStrike Falcon Insight XDR Cybereason XDR Cynet 360 AutoXDR Elastic Security for XDR Microsoft SecOps Palo Alto Networks Cortex XDR SentinelOne Singularity XDR Trellix XDR Platform Trend Micro Vision One (fm) View the full article

Cloudflare on Wednesday rolled out EmDash, which it described as “the spiritual successor to WordPress.” The security vendor positioned EmDash as a far more secure site building tool that avoids the extensive cybersecurity problems with WordPress plugins. But the Cloudflare claims go far beyond cybersecurity issues. The vendor is arguing that the very nature of websites in 2026 is sharply different to the kind of website that WordPress was designed to handle. “WordPress powers over 40% of the internet. It is a massive success that has enabled anyone to be a publisher, and created a global community of WordPress developers. But the WordPress open source project will be 24 years old this year,” the Cloudflare announcement said. “Hosting a website has changed dramatically during that time. When WordPress was born, AWS EC2 didn’t exist. In the intervening years, that task has gone from renting virtual private servers, to uploading a JavaScript bundle to a globally distributed network at virtually no cost. It’s time to upgrade the most popular CMS on the internet to take advantage of this change.” More flexible licensing Cloudflare’s statement also suggested that it is delivering open source in a way that is potentially more open and flexible than the WordPress approach. “EmDash is fully open source, MIT licensed, and available on GitHub. While EmDash aims to be compatible with WordPress functionality, no WordPress code was used to create EmDash. That allows us to license the open source project under the more permissive MIT license. We hope that allows more developers to adapt, extend, and participate in EmDash’s development,” the company said. “EmDash is committed to building on what WordPress created: an open source publishing stack that anyone can install and use at little cost, while fixing the core problems that WordPress cannot solve.” The next wave of web development In an interview with Computerworld, Cloudflare senior product manager Matt Taylor said his team sees the project as the next wave of web development platforms. “There is a whole new generation of developers, and WordPress is old news to them. If you are starting today, there is no way you are picking WordPress,” Taylor said, adding that AI agents are also not going to opt for WordPress platforms when creating new sites. Even when adding Cloudflare in front of a WordPress site to enhance security, he noted, “you have to hack the system to work with the modern internet.” WordPress was unable to provide its feedback on the announcement by deadline. WordPress not for new users Melody Brue, principal analyst for Moor Insights & Strategy, said she has not seen many developers who are not already experienced with WordPress choosing it to build sites, and that she is also seeing that AI agents never opt for WordPress unless they were given explicit instructions to do so. Given how rampant autonomous AI agents are today, the ability to be more hospitable to agentic systems may prove a massive advantage. “For somebody new, you have this opportunity to skip all of these legacy CMS assumptions and have true least privilege by design, a first class experience for agents. At least, that is what [Cloudflare] is trying to deliver,” Brue said. “They are baking in agent skills.” Enterprise concerns When it comes to enterprise web development strategies, however, things get a little more complex, Brue said. Given how deeply they are already invested in WordPress code and plugins and the support environment, existing WordPress enterprise users are not likely to easily move. But the extensive legal outbursts from last year involving Automattic CEO Matt Mullenweg, and the lawsuit with WP Engine, made some enterprise IT executives nervous, once they realized how much control one person had over WordPress platforms. Brue said, “I can understand the concerns,” but added that the WordPress squabbles seem to have become more subdued lately: “There is now less of the tantrum throwing happening.” Thomas Randall, a research director at Info-Tech Research Group, agreed with Brue that enterprise environments are unlikely to abandon WordPress any time soon. “Is EmDash the spiritual successor to WordPress? Not from what Cloudflare has shown so far. The problem Cloudflare highlights, security vulnerabilities in WordPress plugins, is real. But the rest of the announcement deserves skepticism,” Randall said. “For instance, enterprise IT teams with complex WordPress environments will encounter nontrivial barriers for migration. EmDash uses Portable Text rather than WordPress’s HTML content model, which would significantly complicate automated migration. Existing PHP themes and plugins would not carry over directly and would likely require substantial redevelopment.” But that would still open the door to newcomers who have not already invested in the WordPress environment. Competing in a different layer Noah Kenney, principal consultant for Digital 520, said the future is likely to look much more inviting for an EmDash-like approach than for legacy WordPress. “Cloudflare’s EmDash is less about replacing WordPress outright and more about setting a new security baseline, which is that CMS platforms should have isolated execution environments, least-privilege access, and verifiable permission models,” Kenney said. “That has implications for both content management and how enterprises evaluate third-party extensibility risk more broadly.” However, he noted, “viability is an ecosystem question just as much as it is a technical one. EmDash, even if superior from an architectural perspective, is effectively starting from zero. Enterprise adoption will depend heavily on migration tooling, developer adoption, and whether Cloudflare can build a credible plugin and integration ecosystem.” Kenney added that he sees EmDash as “very likely to influence the next phase of CMS architecture, particularly in security-sensitive and enterprise environments where plugin risk is already a prevalent issue.” Sanchit Vir Gogia, chief analyst at Greyhound Research, saw the EmDash move in a much broader context, potentially signaling the near-term future of website strategies. “EmDash is competing in a different layer altogether,” Gogia said. “It sits closer to composable and headless CMS platforms like Contentful and Strapi, and even closer to developer frameworks like Astro. It is collapsing what used to be separate concerns; content management, execution runtime, and security enforcement are being fused into one programmable environment.” This, he observed, “is where the real friction emerges. Traditional CMS buyers are not necessarily developers first. They prioritize usability, ecosystem depth, and speed of execution for business teams. EmDash is clearly optimized for developers and architects. So the competition is not just product versus product. It is operating model versus operating model. And in that contest, incumbents have inertia on their side, while EmDash has architectural purity. History shows those two rarely move at the same speed.” This article originally appeared on Computerworld. View the full article

Cisco has released patches for a critical vulnerability in its out-of-band management solution, present in many of its servers and appliances. The flaw allows unauthenticated remote attackers to gain admin access to the Cisco Integrated Management Controller (IMC), which gives administrators remote control over servers even when the main OS is shut down. The vulnerability, tracked as CVE-2026-20093, stems from incorrect handling of password changes and can be exploited by sending specially crafted HTTP requests. This means servers with their IMC interfaces exposed directly to the local network — or worse, to the internet — are at immediate risk. The Cisco IMC is a baseboard management controller (BMC), a dedicated controller embedded into server motherboards with its own RAM and network interface that gives administrators monitoring and management capabilities as if they were physically connected to the server with a keyboard, monitor, and mouse (KVM). Because BMCs run their own firmware independently of the OS, they can be used to perform operations even when the OS is shut down, including reinstalling it. The IMC provides an HTML5 web interface, an SSH-based command line interface, and an XML API. It also supports Redfish, a standardized RESTful API for BMCs and virtual KVM. “A successful exploit could allow the attacker to bypass authentication, alter the passwords of any user on the system, including an Admin user, and gain access to the system as that user,” Cisco said in its advisory. The IMC is present in 5000 Series Enterprise Network Compute Systems, Catalyst 8300 Series Edge uCPE, UCS C-Series M5 and M6 Rack Servers in standalone mode, UCS E-Series Servers M3, and UCS E-Series Servers M6. However, a long list of Cisco products and appliances that are based on the Cisco Unified Computing System (UCS) C-Series platform are also affected if they have their IMC interface exposed. While Cisco is not currently aware of any malicious attacks exploiting this vulnerability, BMC flaws in servers from other manufacturers have been exploited in the past. In 2022, security researchers found a malicious implant dubbed iLOBleed that was likely developed by an APT group and was being deployed through vulnerabilities in HPE iLO (HPE’s Integrated Lights-Out) BMC. In 2018, a ransomware group called JungleSec used default credentials for IPMI interfaces to compromise Linux servers. The risk of attacks against such management interfaces is serious enough that the US Cybersecurity and Infrastructure Security Agency (CISA) and the National Security Agency (NSA) issued guidance on hardening BMC back in 2023. More recently researchers also warned about vulnerabilities in cheap KVM-over-IP devices that some organizations or admins use as alternatives for managing systems that don’t have dedicated BMC controllers. View the full article

Cisco has released patches for a critical vulnerability in its out-of-band management solution, present in many of its servers and appliances. The flaw allows unauthenticated remote attackers to gain admin access to the Cisco Integrated Management Controller (IMC), which gives administrators remote control over servers even when the main OS is shut down. The vulnerability, tracked as CVE-2026-20093, stems from incorrect handling of password changes and can be exploited by sending specially crafted HTTP requests. This means servers with their IMC interfaces exposed directly to the local network — or worse, to the internet — are at immediate risk. [ Related: More Cisco news and insights ] The Cisco IMC is a baseboard management controller (BMC), a dedicated controller embedded into server motherboards with its own RAM and network interface that gives administrators monitoring and management capabilities as if they were physically connected to the server with a keyboard, monitor, and mouse (KVM). Because BMCs run their own firmware independently of the OS, they can be used to perform operations even when the OS is shut down, including reinstalling it. The IMC provides an HTML5 web interface, an SSH-based command line interface, and an XML API. It also supports Redfish, a standardized RESTful API for BMCs and virtual KVM. “A successful exploit could allow the attacker to bypass authentication, alter the passwords of any user on the system, including an Admin user, and gain access to the system as that user,” Cisco said in its advisory. The IMC is present in 5000 Series Enterprise Network Compute Systems, Catalyst 8300 Series Edge uCPE, UCS C-Series M5 and M6 Rack Servers in standalone mode, UCS E-Series Servers M3, and UCS E-Series Servers M6. However, a long list of Cisco products and appliances that are based on the Cisco Unified Computing System (UCS) C-Series platform are also affected if they have their IMC interface exposed. While Cisco is not currently aware of any malicious attacks exploiting this vulnerability, BMC flaws in servers from other manufacturers have been exploited in the past. In 2022, security researchers found a malicious implant dubbed iLOBleed that was likely developed by an APT group and was being deployed through vulnerabilities in HPE iLO (HPE’s Integrated Lights-Out) BMC. In 2018, a ransomware group called JungleSec used default credentials for IPMI interfaces to compromise Linux servers. The risk of attacks against such management interfaces is serious enough that the US Cybersecurity and Infrastructure Security Agency (CISA) and the National Security Agency (NSA) issued guidance on hardening BMC back in 2023. More recently researchers also warned about vulnerabilities in cheap KVM-over-IP devices that some organizations or admins use as alternatives for managing systems that don’t have dedicated BMC controllers. More Cisco news: Chained vulnerabilities in Cisco Catalyst switches could induce denial-of-service Cisco goes all in on agentic AI security Cisco Talos 2025 year in review and lessons learned How Cisco’s platform mindset is meeting the AI era Cisco extends AgenticOps across networking, security, observability products Cisco amps up Silicon One line, delivers new systems and optics for AI networking Takeaways from Cisco’s AI Summit Cisco: Infrastructure, trust, model development are key AI challenges AI, security tailwinds signal promising 2026 for Cisco Cisco adds intelligent policy enforcement to mesh firewall family Actively exploited Cisco UC bug requires immediate, version‑specific patching Cisco’s 2026 agenda prioritizes AI-ready infrastructure, connectivity Cisco finally patches seven-week-old zero-day flaw in Secure Email Gateway products Cisco routers knocked out due to Cloudflare DNS change View the full article

A new phishing-as-a-service (PhaaS) campaign is abusing Microsoft’s device code authentication flow to gain unauthorized access to user accounts. Sekoia researchers first spotted the toolkit “EvilTokens” that lets attackers capture authentication tokens by tricking users into completing a legitimate login process in Microsoft’s own environment. The activity, observed since at least mid-February, relies on social engineering lures that prompt victims to enter a device code on a real Microsoft login page, Sekoia researchers noted in a blog post. “To compromise Microsoft 365 accounts, EvilTokens pages rely on device code phishing, a technique that differs from the common AitM tactic of replicating Microsoft authentication pages,” the researchers said. The PhaaS toolkit is offering a host of features to its affiliates, including modules for access weaponization, email harvesting, reconnaissance capabilities, and a built-in webmail interface, all powered through Ai automation, the researchers added. EvilTokens was found operating through bots on Telegram, with a dedicated channel for kit upgrades. The campaign has so far mostly affected countries, including the US, Australia, Canada, France, India, Switzerland, and the UAE. Device code authentication as an access broker The campaign centers around the abuse of Microsoft’s device authorization grant flow, a feature designed to simplify logins for devices like smart TVs or command-line tools. EvilTokens repurposes this workflow by generating a legitimate device code and then tricking victims into entering it themselves on the official login page. Once the victim completes authentication, the attacker receives access tokens tied to the session. These tokens can then be used to access Microsoft 365 services, including email and cloud resources, without triggering typical credential-based alerts. Sekoia researchers noted that this technique sidesteps many conventional phishing detections. Because the authentication happens on a legitimate Microsoft domain, there is no credential interception in transit, and multi-factor authentication is completed as happens in a normal login flow. The attack results in a form of account takeover coming from a seemingly expected user behavior. A phishing package with post-compromise focus Beyond the initial access vector, EvilTokens is structured as a full-service phishing platform. The kit provides affiliates with ready-to-use lures, infrastructure, and automation tools designed to carry out both the phishing phase and post-compromise activity. The lures used in the campaign include fake SharePoint document notifications, DocuSign requests, and account alerts, all meant to urge users toward entering device codes. Once access is obtained, the platform enables inbox analysis, allowing attackers to identify high-value targets such as financial conversations or invoice threads. “By leveraging the short-lived access token, the attacker can exfiltrate targeted user data for up to 60 minutes following the device code phishing attack,” they said. “Depending on the targeted service, the attacker can access emails via Exchange Online, documents from Microsoft SharePoint Online and OneDrive, or conversation history in Microsoft Teams.” The received tokens with 60 minutes expiry can also be redeemed for generating new access tokens, with a rolling 90-day validity, allowing attackers to maintain persistence on the compromised account. Distributed through Telegram channels, the PhaaS service includes bot-driven workflows to manage campaigns and token collection. Researchers also observed ongoing development efforts, with indications that support for additional platforms beyond Microsoft may be introduced. Sekoia shared a set of attack infrastructure details to support tracking. These include phishing domain and URL patterns, self-hosted affiliate domains, EvilTokens admin domains, and the YARA rule for detecting the phishing page. View the full article

AI is rapidly changing how software is written, deployed, and used. Trends point to a future where AIs can write custom software quickly and easily: “instant software.” Taken to an extreme, it might become easier for a user to have an AI write an application on demand — a spreadsheet, for example — and delete it when you’re done using it than to buy one commercially. Future systems could include a mix: both traditional long-term software and ephemeral instant software that is constantly being written, deployed, modified, and deleted. AI is changing cybersecurity as well. In particular, AI systems are getting better at finding and patching vulnerabilities in code. This has implications for both attackers and defenders, depending on the ways this and related technologies improve. In this essay, I want to take an optimistic view of AI’s progress, and to speculate what AI-dominated cybersecurity in an age of instant software might look like. There are a number of unknowns that will factor into how the arms race between attacker and defender might play out. How flaw discovery might work On the attacker side, the ability of AIs to automatically find and exploit vulnerabilities has increased dramatically over the past few months. We are already seeing both government and criminal hackers using AI to attack systems. The exploitation part is critical here, because it gives an unsophisticated attacker capabilities far beyond their understanding. As AIs get better, expect more attackers to automate their attacks using AI. And as individuals and organizations can increasingly run powerful AI models locally, AI companies monitoring and disrupting malicious AI use will become increasingly irrelevant. Expect open-source software, including open-source libraries incorporated in proprietary software, to be the most targeted, because vulnerabilities are easier to find in source code. Unknown No. 1 is how well AI vulnerability discovery tools will work against closed-source commercial software packages. I believe they will soon be good enough to find vulnerabilities just by analyzing a copy of a shipped product, without access to the source code. If that’s true, commercial software will be vulnerable as well. Particularly vulnerable will be software in IoT devices: things like internet-connected cars, refrigerators, and security cameras. Also industrial IoT software in our internet-connected power grid, oil refineries and pipelines, chemical plants, and so on. IoT software tends to be of much lower quality, and industrial IoT software tends to be legacy. Instant software is differently vulnerable. It’s not mass market. It’s created for a particular person, organization, or network. The attacker generally won’t have access to any code to analyze, which makes it less likely to be exploited by external attackers. If it’s ephemeral, any vulnerabilities will have a short lifetime. But lots of instant software will live on networks for a long time. And if it gets uploaded to shared tool libraries, attackers will be able to download and analyze that code. All of this points to a future where AIs will become powerful tools of cyberattack, able to automatically find and exploit vulnerabilities in systems worldwide. Automating patch creation But that’s just half of the arms race. Defenders get to use AI, too. These same AI vulnerability-finding technologies are even more valuable for defense. When the defensive side finds an exploitable vulnerability, it can patch the code and deny it to attackers forever. How this works in practice depends on another related capability: the ability of AIs to patch vulnerable software, which is closely related to their ability to write secure code in the first place. AIs are not very good at this today; the instant software that AIs create is generally filled with vulnerabilities, both because AIs write insecure code and because the people vibe coding don’t understand security. OpenClaw is a good example of this. Unknown No. 2 is how much better AIs will get at writing secure code. The fact that they’re trained on massive corpuses of poorly written and insecure code is a handicap, but they are getting better. If they can reliably write vulnerability-free code, it would be an enormous advantage for the defender. And AI-based vulnerability-finding makes it easier for an AI to train on writing secure code. We can envision a future where AI tools that find and patch vulnerabilities are part of the typical software development process. We can’t say that the code would be vulnerability-free — that’s an impossible goal — but it could be without any easily findable vulnerabilities. If the technology got really good, the code could become essentially vulnerability-free. Patching lags and legacy software For new software — both commercial and instant — this future favors the defender. For commercial and conventional open-source software, it’s not that simple. Right now, the world is filled with legacy software. Much of it — like IoT device software — has no dedicated security team to update it. Sometimes it is incapable of being patched. Just as it’s harder for AIs to find vulnerabilities when they don’t have access to the source code, it’s harder for AIs to patch software when they are not embedded in the development process. I’m not as confident that AI systems will be able to patch vulnerabilities as easily as they can find them, because patching often requires more holistic testing and understanding. That’s Unknown No. 3: how quickly AIs will be able to create reliable software updates for the vulnerabilities they find, and how quickly customers can update their systems. Today, there is a time lag between when a vendor issues a patch and customers install that update. That time lag is even longer for large organizational software; the risk of an update breaking the underlying software system is just too great for organizations to roll out updates without testing them first. But if AI can help speed up that process, by writing patches faster and more reliably, and by testing them in some AI-generated twin environment, the advantage goes to the defender. If not, the attacker will still have a window to attack systems until a vulnerability is patched. Toward self-healing In a truly optimistic future, we can imagine a self-healing network. AI agents continuously scan the ever-evolving corpus of commercial and custom AI-generated software for vulnerabilities, and automatically patch them on discovery. For that to work, software license agreements will need to change. Right now, software vendors control the cadence of security patches. Giving software purchasers this ability has implications about compatibility, the right to repair, and liability. Any solutions here are the realm of policy, not tech. If the defense can find, but can’t reliably patch, flaws in legacy software, that’s where attackers will focus their efforts. If that’s the case, we can imagine a continuously evolving AI-powered intrusion detection, continuously scanning inputs and blocking malicious attacks before they get to vulnerable software. Not as transformative as automatically patching vulnerabilities in running code, but nevertheless valuable. The power of these defensive AI systems increases if they are able to coordinate with each other, and share vulnerabilities and updates. A discovery by one AI can quickly spread to everyone using the affected software. Again: Advantage defender. There are other variables to consider. The relative success of attackers and defenders also depends on how plentiful vulnerabilities are, how easy they are to find, whether AIs will be able to find the more subtle and obscure vulnerabilities, and how much coordination there is among different attackers. All this comprises Unknown No. 4. Vulnerability economics Presumably, AIs will clean up the obvious stuff first, which means that any remaining vulnerabilities will be subtle. Finding them will take AI computing resources. In the optimistic scenario, defenders pool resources through information sharing, effectively amortizing the cost of defense. If information sharing doesn’t work for some reason, defense becomes much more expensive, as individual defenders will need to do their own research. But instant software means much more diversity in code: an advantage to the defender. This needs to be balanced with the relative cost of attackers finding vulnerabilities. Attackers already have an inherent way to amortize the costs of finding a new vulnerability and create a new exploit. They can vulnerability hunt cross-platform, cross-vendor, and cross-system, and can use what they find to attack multiple targets simultaneously. Fixing a common vulnerability often requires cooperation among all the relevant platforms, vendors, and systems. Again, instant software is an advantage to the defender. But those hard-to-find vulnerabilities become more valuable. Attackers will attempt to do what the major intelligence agencies do today: find “nobody but us” zero-day exploits. They will either use them slowly and sparingly to minimize detection or quickly and broadly to maximize profit before they’re patched. Meanwhile, defenders will be both vulnerability hunting and intrusion detecting, with the goal of patching vulnerabilities before the attackers find them. We can even imagine a market for vulnerability sharing, where the defender who finds a vulnerability and creates a patch is compensated by everyone else in the information-sharing/repair network. This might be a stretch, but maybe. Up the stack Even in the most optimistic future, attackers aren’t going to just give up. They will attack the non-software parts of the system, such as the users. Or they’re going to look for loopholes in the system: things that the system technically allows but were unintended and unanticipated by the designers — whether human or AI — and can be used by attackers to their advantage. What’s left in this world are attacks that don’t depend on finding and exploiting software vulnerabilities, like social engineering and credential stealing attacks. And we have already seen how AI-generated deepfakes make social engineering easier. But here, too, we can imagine defensive AI agents that monitor users’ behaviors, watching for signs of attack. This is another AI use case, and one that I’m not even sure how to think about in terms of the attacker/defender arms race. But at least we’re pushing attacks up the stack. Also, attackers will attempt to infiltrate and influence defensive AIs and the networks they use to communicate, poisoning their output and degrading their capabilities. AI systems are vulnerable to all sorts of manipulations, such as prompt injection, and it’s unclear whether we will ever be able to solve that. This is Unknown No. 5, and it’s a biggie. There might always be a “trusting trust problem.” No future is guaranteed. We truly don’t know whether these technologies will continue to improve and when they will plateau. But given the pace at which AI software development has improved in just the past few months, we need to start thinking about how cybersecurity works in this instant software world. View the full article

Gorodenkoff | shutterstock.com Model Context Protocol (MCP) verbindet KI-Agenten mit Datenquellen und erfreut sich im Unternehmensumfeld wachsender Beliebtheit. Allerdings ist auch MCP nicht frei von Sicherheitslücken, wie entsprechende Entdeckungen, etwa beim SaaS-Anbieter Asana oder dem IT-Riesen Atlassian gezeigt haben. Inzwischen hat sich jedoch einiges in Sachen MCP-Sicherheit getan. Einerseits wurden mit Blick auf das Kernprotokoll etliche Fortschritte erzielt. Beispielsweise in Form von Support für OAuth sowie für Authentifizierungs-Server von Drittanbietern und Identity-Management-Systeme. Darüber hinaus wurde inzwischen auch eine offizielle MCP Registry geschaffen, die einen Überblick über sichere, öffentlich verfügbare MCP-Server bietet. Dennoch bestehen weiterhin Sicherheitslücken, die sich für diverse Cyberschandtaten ausnutzen lassen – Prompt Injection, Tool Poisoning, Token-Diebstahl, Server-übergreifende Attacken oder manipulierte Messages sind nur einige von vielen Beispielen. Mit anderen Worten: Unternehmen, die sich beim Aufbau von Agentic-AI-Systemen einen Wettbewerbsvorteil verschaffen wollen, müssen erhebliche Anstrengungen unternehmen, um zu gewährleisten, dass sensible Daten nicht nach außen dringen. Glücklicherweise gibt es diverse Tools, die dabei Unterstützung versprechen. In diesem Artikel lesen Sie: was Security-Tools für MCP leisten sollten, und welche Angebote in diesem Bereich interessant sind. Das sollten MCP-Sicherheitslösungen können Die Gefahr von Datenlecks, Prompt Injections und weiteren Sicherheitsbedrohungen besteht unabhängig davon, ob Unternehmen: ihre eigenen KI-Agenten mit MCP-Servern von Drittanbietern, ihre eigenen MCP-Server mit Drittanbieter-Agenten, oder ihre eigenen Server mit den eigenen Agenten verbinden. Soll heißen: Unternehmen müssen in jedem Fall Autorisierungen und Berechtigungen überprüfen, detaillierte Zugriffskontrollen implementieren und alles protokollieren. Daraus ergeben sich auch die Anforderungen für MCP-Sicherheitslösungen. Diese sollten bieten: MCP-Servererkennung. Für Mitarbeiter eines Unternehmens ist es einfach, MCP-Server herunterzuladen und zu nutzen. Mit Scan-Services für MCP-Server können Unternehmen sämtliche Instanzen von Schatten-MCP-Servern in ihrer Umgebung finden. Laufzeitschutz. KI-Agenten kommunizieren mit MCP-Servern in natürlicher Sprache. MCP-Sicherheits-Tools sollten deshalb in der Lage sein, diese Kommunikation auf Sicherheitsprobleme wie Prompt Injections hin zu überwachen. Authentifizierungs- und Zugriffskontrollen. Das MCP-Protokoll unterstützt inzwischen OAuth, aber das ist nur ein erster Schritt. Für zusätzliche Sicherheit empfehlen sich Tools mit integrierten Kontroll-Frameworks für Zero Trust und Least Privilege. Logging und Observability. Tools und Plattformen sollten zudem die Möglichkeit bieten, MCP-Protokolle zu sammeln, Sicherheitsteams über Richtlinienverstöße zu informieren, Compliance-Daten zu erfassen oder Protokolle in die bestehende Sicherheitsinfrastruktur einzuspeisen. MCP-Security-Angebote Im Folgenden haben wir die Anbieter von MCP-Security-Tools in drei Kategorien aufgeteilt. Diese Aufstellung erhebt keinen Anspruch auf Vollständigkeit. Hyperscaler Für Unternehmen, die sich vollständig auf eine bestimmte Cloud-Plattform verlassen, bieten die MCP-Tools des jeweiligen Hyperscalers einen einfachen Einstieg. Amazon Web Services (AWS) hat Mitte 2025 seine eigene agentenbasierte KI-Plattform eingeführt. Amazon Bedrock AgentCore umfasst ein Gateway, das mehrere Protokolle unterstützt (darunter auch MCP), ein Identity-Management-System sowie Observability. Microsoft bietet einen grundlegenden Azure-MCP-Server an, inklusive Support für Azure Key Vault. Darüber hinaus unterstützen auch Azure AI Foundry Agent Service und Azure API Management das Model Context Protocol. Zudem bietet Microsoft mit dem Agent Framework auch ein Open-Source-Entwicklungskit, das sowohl MCP als auch Agent2Agent unterstützt und beispielsweise Schutz vor Prompt Injections verspricht. Google Cloud kündigte Anfang 2025 seine MCP Toolbox für Datenbanken an – inklusive integrierter Authentifizierung und Observability. Außerdem hat der Hyperscaler auch eine Referenzarchitektur veröffentlicht, um MCP-Server auf seiner Cloud-Plattform abzusichern. Große Plattformanbieter Der IT-Dienstleister Cloudflare hat mit MCP Server Portals ein Tool veröffentlicht, mit dem Unternehmen MCP-Verbindungen zentralisiert absichern und überwachen können. Die Funktion ist Bestandteil der Cloudflare-One-Plattform. Palo Alto Networks hat mit Blick auf MCP-Sicherheit mehrere Eisen im Feuer. Mit Prisma AIRS hat das Unternehmen einen eigenen, intermediären MCP-Server veröffentlicht. Dieser sitzt zwischen den KI-Agenten und dem eigentlichen MCP-Server und erkennt schadhafte Inhalte und Daten. Das Tool MCP Security ist hingegen Bestandteil von Cortex Cloud WAAS und überprüft die MCP-Kommunikation an der Netzwerkgrenze auf bösartige Aktivitäten. SentinelOne gewährt mit seiner Singularity Platform ebenfalls Einblick in die MCP-Interaktionskette und bietet zum Beispiel Warnmeldungen und automatisierte Incident Response für MCP-Server auf lokaler oder Remote-Ebene. Daneben hat auch Broadcom MCP-Sicherheitsfunktionen für VMware Cloud Foundation angekündigt, die künftig mehr Sicherheit für agentenbasierte Workflows gewährleisten sollen. Startups Die Plattform von Acuvity (seit Februar 2026 Teil von Proofpoint) verspricht, MCP-Server umfassend abzusichern. Dafür sorgt laut dem Anbieter eine Kombination aus Least-Privilege-Execution, unveränderlichen Laufzeiten, kontinuierlichen Schwachstellenscans, Authentifizierung und Bedrohungserkennung. Das API-Security-Startup Akto hat eine MCP-Security-Plattform im Angebot. Sie umfasst ein Discovery Tool, um MCP-Server in Unternehmensumgebungen zu identifizieren, Security-Testing-Werkzeuge sowie Monitoring- und Threat-Detection-Funktionen. Invariant Labs bietet mit MCP-Scan ein quelloffenes Tool, das die statische Analyse und Echtzeitüberwachung von MCP-Servern ermöglicht. Mit Guardrails hat das Startup auch ein kommerzielles Produkt im Angebot. Dabei handelt es sich um einen Proxy. Der zwischen KI-Agenten und MCP-Servern sitzt und vor Security-Risiken schützen soll. Das Tool befähigt Anwender außerdem dazu, Richtlinien aufzusetzen. Highflame (vormals Javelin) addressiert ebenfalls das Thema MCP-Sicherheit. Etwa mit Funktionen wie MCP-Server auf Risiken zu scannen oder Datenanfragen zu überprüfen. Lasso Security stellt ein Open-Source-MCP-Gateway zur Verfügung, das die Konfiguration und das Lebenszyklusmanagement von MCP-Servern ermöglicht und Messages um sensible Informationen bereinigt. (fm) View the full article

Gorodenkoff | shutterstock.com Model Context Protocol (MCP) verbindet KI-Agenten mit Datenquellen und erfreut sich im Unternehmensumfeld wachsender Beliebtheit. Allerdings ist auch MCP nicht frei von Sicherheitslücken, wie entsprechende Entdeckungen, etwa beim SaaS-Anbieter Asana oder dem IT-Riesen Atlassian gezeigt haben. Inzwischen hat sich jedoch einiges in Sachen MCP-Sicherheit getan. Einerseits wurden mit Blick auf das Kernprotokoll etliche Fortschritte erzielt. Beispielsweise in Form von Support für OAuth sowie für Authentifizierungs-Server von Drittanbietern und Identity-Management-Systeme. Darüber hinaus wurde inzwischen auch eine offizielle MCP Registry geschaffen, die einen Überblick über sichere, öffentlich verfügbare MCP-Server bietet. Dennoch bestehen weiterhin Sicherheitslücken, die sich für diverse Cyberschandtaten ausnutzen lassen – Prompt Injection, Tool Poisoning, Token-Diebstahl, Server-übergreifende Attacken oder manipulierte Messages sind nur einige von vielen Beispielen. Mit anderen Worten: Unternehmen, die sich beim Aufbau von Agentic-AI-Systemen einen Wettbewerbsvorteil verschaffen wollen, müssen erhebliche Anstrengungen unternehmen, um zu gewährleisten, dass sensible Daten nicht nach außen dringen. Glücklicherweise gibt es diverse Tools, die dabei Unterstützung versprechen. In diesem Artikel lesen Sie: was Security-Tools für MCP leisten sollten, und welche Angebote in diesem Bereich interessant sind. Das sollten MCP-Sicherheitslösungen können Die Gefahr von Datenlecks, Prompt Injections und weiteren Sicherheitsbedrohungen besteht unabhängig davon, ob Unternehmen: ihre eigenen KI-Agenten mit MCP-Servern von Drittanbietern, ihre eigenen MCP-Server mit Drittanbieter-Agenten, oder ihre eigenen Server mit den eigenen Agenten verbinden. Soll heißen: Unternehmen müssen in jedem Fall Autorisierungen und Berechtigungen überprüfen, detaillierte Zugriffskontrollen implementieren und alles protokollieren. Daraus ergeben sich auch die Anforderungen für MCP-Sicherheitslösungen. Diese sollten bieten: MCP-Servererkennung. Für Mitarbeiter eines Unternehmens ist es einfach, MCP-Server herunterzuladen und zu nutzen. Mit Scan-Services für MCP-Server können Unternehmen sämtliche Instanzen von Schatten-MCP-Servern in ihrer Umgebung finden. Laufzeitschutz. KI-Agenten kommunizieren mit MCP-Servern in natürlicher Sprache. MCP-Sicherheits-Tools sollten deshalb in der Lage sein, diese Kommunikation auf Sicherheitsprobleme wie Prompt Injections hin zu überwachen. Authentifizierungs- und Zugriffskontrollen. Das MCP-Protokoll unterstützt inzwischen OAuth, aber das ist nur ein erster Schritt. Für zusätzliche Sicherheit empfehlen sich Tools mit integrierten Kontroll-Frameworks für Zero Trust und Least Privilege. Logging und Observability. Tools und Plattformen sollten zudem die Möglichkeit bieten, MCP-Protokolle zu sammeln, Sicherheitsteams über Richtlinienverstöße zu informieren, Compliance-Daten zu erfassen oder Protokolle in die bestehende Sicherheitsinfrastruktur einzuspeisen. MCP-Security-Angebote Im Folgenden haben wir die Anbieter von MCP-Security-Tools in drei Kategorien aufgeteilt. Diese Aufstellung erhebt keinen Anspruch auf Vollständigkeit. Hyperscaler Für Unternehmen, die sich vollständig auf eine bestimmte Cloud-Plattform verlassen, bieten die MCP-Tools des jeweiligen Hyperscalers einen einfachen Einstieg. Amazon Web Services (AWS) hat Mitte 2025 seine eigene agentenbasierte KI-Plattform eingeführt. Amazon Bedrock AgentCore umfasst ein Gateway, das mehrere Protokolle unterstützt (darunter auch MCP), ein Identity-Management-System sowie Observability. Microsoft bietet einen grundlegenden Azure-MCP-Server an, inklusive Support für Azure Key Vault. Darüber hinaus unterstützen auch Azure AI Foundry Agent Service und Azure API Management das Model Context Protocol. Zudem bietet Microsoft mit dem Agent Framework auch ein Open-Source-Entwicklungskit, das sowohl MCP als auch Agent2Agent unterstützt und beispielsweise Schutz vor Prompt Injections verspricht. Google Cloud kündigte Anfang 2025 seine MCP Toolbox für Datenbanken an – inklusive integrierter Authentifizierung und Observability. Außerdem hat der Hyperscaler auch eine Referenzarchitektur veröffentlicht, um MCP-Server auf seiner Cloud-Plattform abzusichern. Große Plattformanbieter Der IT-Dienstleister Cloudflare hat mit MCP Server Portals ein Tool veröffentlicht, mit dem Unternehmen MCP-Verbindungen zentralisiert absichern und überwachen können. Die Funktion ist Bestandteil der Cloudflare-One-Plattform. Palo Alto Networks hat mit Blick auf MCP-Sicherheit mehrere Eisen im Feuer. Mit Prisma AIRS hat das Unternehmen einen eigenen, intermediären MCP-Server veröffentlicht. Dieser sitzt zwischen den KI-Agenten und dem eigentlichen MCP-Server und erkennt schadhafte Inhalte und Daten. Das Tool MCP Security ist hingegen Bestandteil von Cortex Cloud WAAS und überprüft die MCP-Kommunikation an der Netzwerkgrenze auf bösartige Aktivitäten. SentinelOne gewährt mit seiner Singularity Platform ebenfalls Einblick in die MCP-Interaktionskette und bietet zum Beispiel Warnmeldungen und automatisierte Incident Response für MCP-Server auf lokaler oder Remote-Ebene. Daneben hat auch Broadcom MCP-Sicherheitsfunktionen für VMware Cloud Foundation angekündigt, die künftig mehr Sicherheit für agentenbasierte Workflows gewährleisten sollen. Startups Die Plattform von Acuvity (seit Februar 2026 Teil von Proofpoint) verspricht, MCP-Server umfassend abzusichern. Dafür sorgt laut dem Anbieter eine Kombination aus Least-Privilege-Execution, unveränderlichen Laufzeiten, kontinuierlichen Schwachstellenscans, Authentifizierung und Bedrohungserkennung. Das API-Security-Startup Akto hat eine MCP-Security-Plattform im Angebot. Sie umfasst ein Discovery Tool, um MCP-Server in Unternehmensumgebungen zu identifizieren, Security-Testing-Werkzeuge sowie Monitoring- und Threat-Detection-Funktionen. Invariant Labs bietet mit MCP-Scan ein quelloffenes Tool, das die statische Analyse und Echtzeitüberwachung von MCP-Servern ermöglicht. Mit Guardrails hat das Startup auch ein kommerzielles Produkt im Angebot. Dabei handelt es sich um einen Proxy. Der zwischen KI-Agenten und MCP-Servern sitzt und vor Security-Risiken schützen soll. Das Tool befähigt Anwender außerdem dazu, Richtlinien aufzusetzen. Highflame (vormals Javelin) addressiert ebenfalls das Thema MCP-Sicherheit. Etwa mit Funktionen wie MCP-Server auf Risiken zu scannen oder Datenanfragen zu überprüfen. Lasso Security stellt ein Open-Source-MCP-Gateway zur Verfügung, das die Konfiguration und das Lebenszyklusmanagement von MCP-Servern ermöglicht und Messages um sensible Informationen bereinigt. (fm) View the full article

When your network goes down, your business stops. That’s a stark truth we see confirmed daily in incident response—and N-able’s 2026 State of the SOC Report only underscores it. Backup isn’t just an IT routine anymore; it’s the backbone of your business resilience strategy. Yet, too many teams leave gaps that threat actors are ready to exploit. Let’s get proactive. Here are seven common backup priorities and what we recommend to ensure your organization can recover from anything the modern threat landscape throws at you. 1. Prioritize your most critical data You can’t protect everything at the same level, and you shouldn’t try. Businesses focusing on mission-critical systems for backup and rapid recovery have significantly shorter downtime post-incident. The Fix: Identify revenue-driving applications, regulated data, and anything core to daily operations—then align backup policies with these priorities. If you treat your archive data with the same urgency as your production data, you’re wasting resources that could save your business during a crisis. 2. Ensure off-site backup copies Local backups are fast, but they are also vulnerable to the same physical disasters and ransomware attacks that hit your primary servers. If your production environment and your backups are on the same network segment without air-gapping, a single compromise becomes a total extinction event. The Fix: Adopt a 3-2-1 strategy (3 total copies of data, 2 different media types, 1 offsite copy) but modernize it. Ensure at least one copy is off-site and immutable. Our cloud-first backup solution shows how reducing the attack surface mitigates risk. 3. Implement backup immutability Ransomware attacks increasingly target repositories to force payment. If an attacker can delete your backups, you have no leverage. The Fix: Immutable backups—backups that can’t be changed or deleted, even by admins—are non-negotiable. In N-able’s cloud, automated immutable storage and air-gapped backups consistently prevented data loss, even when primary systems were compromised. N-able’s Cove Data Protection is ransomware ready with cyber-resilient architecture, immutable copies, and ransomware recovery to keep you in control and able to restore data successfully. 4. Automating RPO and RTO Recovery Point Objective (RPO) and Recovery Time Objective (RTO) are your real commitments to stakeholders. Not enforcing or automating RPO and RTO means an organization lacks defined, measurable targets for data loss and downtime, leading to high-risk, manual, and often chaotic recovery processes. Without automation, organizations rely on manual, human-driven procedures, which increase the likelihood of data loss, extended outages, and failure to meet compliance requirements (e.g., HIPAA, PCI DSS) The Fix: Establish RTO and RPO for each application based on criticality. Implement automation and regularly test recovery processes to ensure they meet targets. Don’t rely on manual checks; let the system tell you if you are drifting from your resilience goals. Why RPO and RTO metrics matter for cyber resilience and how they are different. 5. Real-world backup testing The worst time to test a backup is when you’re restoring it under pressure. In our experience, corrupted backups surface as a leading cause of failed recoveries. A screenshot of a “success” message isn’t enough proof that a server will boot. The Fix: Make automated recovery testing a daily habit and not a quarterly dread. We advocate solutions that boot VMs from backups, run service checks, and supply verifiable evidence after every run. 6. Integrate backup with security ops Too often, backup and security exist in silos. The most resilient organizations are integrating backup failures directly into their SOC dashboards. The Fix: Treat backup failures as security incidents. Any surprise failure or agent tampering gets immediate incident review and threat hunting. Bonus: Scan backup images for malware before restoring to avoid reintroducing threats during your most vulnerable moment. 7. Implement scalable recovery playbooks Recovering one file is easy; recovering your business under attack is chaos without a plan. This was painfully clear in cases where teams restored non-essential servers, leaving core business processes offline. The Fix: Build recovery runbooks. Know what to bring back first (typically identity, DNS, DB servers), document dependencies, and rehearse recovery from “zero” infrastructure. Proving resilience, not just activity Executives and clients want to know: “Are we protected if disaster strikes?” Reporting on backup success means showing more than last night’s log. Demonstrate that your tests meet RPO/RTO, that DR rehearsals succeed, and that automated processes kick in as designed. We recognize backup is about more than files—it’s about business continuity and trust. With the number of alerts every minute hitting SOCs today, automated orchestration helps you respond to the velocity of modern attacks so you can recover fast and stay compliant, operational, and secure. Data threats are evolving, and your backup needs to evolve with them. See how N-able’s Cove Data Protection beats legacy backups. View the full article

How many times has your SOC hit crisis mode at 2:00 AM, with the dashboard blaring red and analysts scrambling to separate real threats from useless noise? We’ve all been there, and if you’re still measuring success by the number of alerts closed, chances are you’re feeling the strain. The truth is, responding to everything is neither sustainable nor effective—and it puts resilience at risk. In this article, we’ll show you the five most important steps you can take to move from alert fatigue to business resilience, supported by hard data from the 2026 N-able State of the SOC Report. These are the practical habits security-driven IT leaders are adopting to future-proof their operations and protect what matters most. 1. Recognize the cost of noise: When “more alerts” means more risk Many SOCs still believe that more data equals better protection. But our 2026 State of the SOC report found that traditional alert volumes have hit a breaking point— our SOC team had to process an average of 2 alerts per minute last year. When everything is urgent, nothing is. Analysts get burned out, and critical threats can slip by undetected, leading to increased dwell times and real business impact. Key N-able SOC stat: 18% of threats in 2025 were only caught by network and perimeter layers—outside endpoint visibility. It’s clear: If you’re over-relying on endpoint or cloud signals, you’re missing threats and putting uptime and client trust at risk. 2. Prioritize outcomes over ticket volume Stop focusing on how many alerts are cleared. This may be a metric for a better understanding of where automation or headcount are necessary but prioritize outcomes. Instead, the right questions are: How quickly did you contain a threat? Did we disrupt business operations or keep recovery swift and effective? A practical, outcome-driven SOC measures: Dwell time: How long before a threat was neutralized? Mean Time to Contain: How quickly were you able to halt an attack? Business downtime avoided: How resilient were you when tested? Tie these metrics back to resilience. When you can tell the CEO or client you prevented X hours of downtime or stopped ransomware in minutes, you position yourself as more than a cost center—you’re a driver of business continuity. Hear how customers use N-able to boost efficiency, gain peace of mind, and ensure business resiliency. 3. Put AI and automation to work—or get left behind According to our SOC report, 90% of all investigations in 2026 could be automated by AI. In fact, only organizations that shifted to AI-centric security models kept up with the onslaught. Those stuck with purely manual playbooks fell behind. Here’s what works: AI-driven correlation to unify context across endpoints, networks, identities, and more. Automation to handle tasks like remediation, account disables, password resets, and notifications—repetitive work that machines do faster and with less error. Last year, our SOAR actions surged 500%, making up almost a quarter of all responses. That’s what resilience in the face of “volume crisis” looks like. Explore the benefits of integrating AI into your strategy and how it impacts your security team across crucial threat and detection stages. 4. Build defense-in-depth (and don’t rely on magic bullets) The “magic bullet” mindset, where a single security layer or tool is supposed to protect everything, doesn’t cut it. The 2026 N-able State of the SOC report underscores that business resilience depends on a defense-in-depth strategy: In 2025, half of all attacks bypassed endpoint controls entirely. 137,187 network and perimeter threats were invisible to endpoint-only deployments. The lesson: Layered security isn’t just “nice to have”—it’s the difference between stopping attacks and suffering a breach. Even with the right foundational layers in place, the real power only emerges when they operate as a unified system. Multi-layer correlation connects the signals coming from identity, endpoint, cloud, network, and perimeter controls, transforming isolated alerts into a clear, actionable picture of an unfolding attack. 5. Design playbooks that focus on business resilience Your playbooks shouldn’t just stop at technical containment—think bigger. The best teams design for resilience, from automated isolation and communication to verified recovery. For ransomware: Confirm the scope rapidly (AI correlates affected assets). Automate isolation of the subnet or systems involved. Communicate with stakeholders per your IR plan. Initiate backup restoration, leveraging recent, immutable recovery points. In our 2026 SOC report, organizations with unified, automated playbooks contained perimeter-initiated attacks in under 10 minutes—even during off-hours. That’s the bar you need to hit. The bottom line Volume and complexity aren’t going away, but SOC fatigue doesn’t have to be your story. By shifting to outcome-driven defense, embracing automation, layering controls, and focusing on measurable resilience, you move from reactive to proactive—protecting your clients, your brand, and your peace of mind. Are you ready to take the next step? Take a tour of Adlumin’s AI-powered XDR platform and expert-led MDR service. View the full article