Fastjson 1.x RCE Vulnerability Targeted in Attacks With No Patched Available

Security firms ThreatBook and Imperva say attackers are targeting a critical flaw in Fastjson, Alibaba's JSON library for Java. In affected Spring Boot applications, a malicious JSON request can execute code without authentication, with the privileges of the Java process.

Tracked as CVE-2026-16723, the vulnerability carries an Alibaba-assigned CVSS score of 9.0. The confirmed chain requires Fastjson 1.2.68 through 1.2.83, a Spring Boot executable fat-JAR, a network-reachable path that sends attacker-controlled JSON to an affected parser, and SafeMode left at its disabled default. AutoType can remain disabled, and no classpath gadget is required.

As of July 25, Alibaba had not released a fixed Fastjson 1.x version. Organizations that cannot migrate immediately should enable SafeMode with -Dfastjson.parser.safeMode=true or use com.alibaba:fastjson:1.2.83_noneautotype. Alibaba lists migration to Fastjson2 as the long-term fix.

Alibaba published its advisory on July 21 following responsible disclosure by Kirill Firsov of FearsOff Cybersecurity. The maintainers described the vulnerability as requiring "no AutoType enablement" and "no classpath gadget." They verified the chain on Spring Boot 2.x, 3.x, and 4.x with JDK 8, 11, 17, and 21.

Firsov traced the issue to Fastjson's type-resolution path. An attacker-controlled @type value can be turned into a class-resource lookup. In a compatible Spring Boot fat-JAR, a crafted nested JAR path can fetch attacker-controlled bytecode. An @JSONType annotation in that resource can then be treated as a trust signal, allowing the class to pass Fastjson's type checks and load.

His technical analysis also describes a newer-JDK path that downloads a remote JAR and references it through /proc/self/fd.

The exploit depends on the Spring Boot executable fat-JAR loader. Alibaba lists plain non-fat JARs, generic uber-JARs, and Tomcat or Jetty WAR deployments as unaffected. Reachable entry points include JSON.parse, JSON.parseObject(String), and JSON.parseObject(String, Class). Binding input to a fixed class is not sufficient when an object contains an Object or Map field where the payload can be nested.

ThreatBook said on July 22 that its platform had captured in-the-wild exploitation after adding detection support two days earlier. Its laboratory results were narrower: it reproduced full code execution in a Spring Boot fat-JAR on JDK 8, while its embedded Tomcat test produced only a remote JAR fetch or server-side request forgery.

Imperva reported activity against financial services, healthcare, computing, retail, and other organizations, primarily in the United States, with smaller volumes in Singapore and Canada. It said browser impersonators generated most requests, while Ruby and Go tools represented about 30% collectively.

Neither vendor published attack counts, raw requests, execution evidence, named victims, or confirmed compromises. Their reports establish observed exploit activity, not proof of successful code execution against a real-world target or a breach.

A July 23 CISA-ADP assessment nevertheless marked exploitation as none. The Hacker News confirmed on July 25 that the flaw was absent from CISA's current Known Exploited Vulnerabilities catalog. The available sources do not explain the mismatch.

The Hacker News also found no patched Fastjson 1.x artifact in the project's GitHub tags or Maven Central repository as of July 25. Version 1.2.83 remains the latest standard 1.x release, while 1.2.83_noneautotype remains the available restricted build.

Organizations should inventory direct and transitive Fastjson dependencies and inspect affected systems for suspicious @type values, nested JAR URLs, unexpected outbound connections, child processes, file changes, and web shells. Fastjson2 is not affected because it does not use the same resource-probing or annotation-based trust path.

The Hacker News has reached out to Alibaba for clarification on the affected versions and Fastjson 1.x patch plans, and to Imperva for details about the reported exploitation activity. We will update the story with any response.

Fastjson 1.2.83 was Alibaba's recommended upgrade for a separate AutoType bypass disclosed in 2022. That final 1.x release now sits inside the affected range for CVE-2026-16723.

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

DevMan RaaS Portal Centralizes Payload Builds, Victim Management, and Affiliate Payouts

The operators of the DevMan ransomware-as-a-service (RaaS) scheme are maintaining a dedicated web platform that offers affiliates the ability to build payloads, oversee earnings, and manage various aspects related to victims.

Swiss cybersecurity company PRODAFT is tracking the centrally administered RaaS operation under the name Funky Mantis.

"The portal combined build generation, finance, victim chat, support, victim records, teams, and payout functions," the company said in an extensive report shared with The Hacker News.

"The service integrated access brokerage or access distribution with ransomware deployment. Administrators offered country-specific 'networks,' asked whether an affiliate would use personal or program-supplied access, and imposed two-to-three-day completion windows."

Various analyses show that DevMan first emerged on the scene in April 2025 as an affiliate for Qilin, DragonForce, Apos, and RansomHub, before shifting to their own RaaS operation. The locker's DNA is "unmistakably DragonForce," Vectra AI noted back in October 2025, highlighting the ransomware's shared lineage.

In an interview with security researcher Jon DiMaggio published in October 2025, DevMan acknowledged that they worked with Conti and claimed they had developed a "specialized SCADA locker" to target an unnamed gas company that was designed to inflict progressive physical damage beyond encryption.

Per the threat actor, the malware would "push industrial control systems beyond their operating parameters, processors, memory, and thermal limits, forcing systems to ramp up and run hot until hardware failed."

"The threat actor is operating with a high-profile online presence and updating about developments, updates and general statements mainly in English and sometimes in Russian as well," the Israel National Cyber Directorate (INCD) said in a bulletin released last year. "They often 'brag' about their achievements, to the point where they post write-ups that describe the way they gained access and performed the attack."

DevMan's operations suffered a hit in June 2025 after a mysterious whistleblower calling themselves GangExposed publicly doxxed operator identities, causing a few affiliates to abandon the operation. DevMan also alleged that GangExposed attempted to extort them for 0.3 to 1 Bitcoin during their Telegram interactions.

According to statistics on Ransomware.Live, the group has claimed 184 victims to date, with no new victims reported after February 4, 2026. Nearly 50 victims are located in the U.S., with technology, healthcare, financial services, professional services, and government sectors accounting for the most targeted.

The affiliate portal associated with the operation, which originally revolved around builders, finance, victim chat, and help desk functions, has since received an upgrade. The third version ("v3) of the platform released in January 2026 comes with support for structured victim records, life cycle states, team creation, invitation controls, per-victim build options, deadline tracking, revenue fields, and shared operational access.

"This progression indicates an effort to formalize affiliate workflows and manage multiple intrusions through a common platform rather than relying only on chat-based coordination," PRODAFT said.

The cybersecurity company has identified five distinct roles within the DevMan operations -

• LARVA-367 - Administrator/owner and central coordinator
• LARVA-546 - Access coordinator named as an alternative point of contact for network access
• LARVA-547 - Senior operator
• LARVA-548 - Senior operator or coordinator
• LARVA-550 - Affiliate/operator who was credited for an installation in an actor-controlled group message

"Affiliates were added to corporate chat after producing a first victim and were assigned an experienced curator," PRODAFT said. "They could be removed after one month without a new victim. Team formation and disclosure of program affiliation required curator approval, which limited independent coordination and public association with the service."

The core management also reserves the right to take over a conversation if an affiliate behaves inappropriately or fails to adhere to a commitment. The governance model reduces affiliate autonomy, while giving the administrators the power to enforce operational tempo and protect their revenue.

The illicit proceeds obtained after successful extortion follow an 80-20% split, allowing the affiliate to earn a chunk of the profits. The v3 platform rules state that the ransom funds are sent to two wallets, one for the affiliate and one linked to the RaaS program.

DevMan's stated targeting policy allows affiliates to strike entities outside the CIS countries and Serbia. It also excludes CIS consulates and CIS-linked companies, and lifts a previous restriction on Saudi Arabia. Besides explicitly encouraging attacks against critical infrastructure, it instructs affiliates to request a separate encryptor for SCADA systems, corroborating their development on a specialized SCADA locker.

However, the policy forbids affiliates from attacking child-related healthcare businesses and intentional leaks of personal data belonging to people under the age of 18.

The latest version of the portal allows affiliates to create a locker for Windows, ESXi, or Linux. An analysis of the Windows version has identified functions related to privilege checking to determine if it's running as an administrator, security-control impairment, process and service termination, recovery inhibition, event log clearing, local and network-share discovery, lateral movement, multi-threaded encryption, ransom-note creation, and optional self-deletion.

The locker encrypts files with ChaCha20-Poly1305. Files up to and including 3 MiB are fully encrypted, while those above the threshold are partially encrypted by processing a 1 MiB chunk every 51 MiB.

"Organizations should prohibit service and backup accounts from interactive VPN login unless a documented operational requirement exists," PRODAFT said. "Remote access and privileged administration should use phishing-resistant MFA. Teams should rotate credentials exposed to VPN appliances, LDAP integrations, scripts, and backup tooling, with priority given to secrets that can grant local or domain administrative access."

Huntress Faces Insider Threat Allegations

The disclosure also comes at a time when Ben Folland, a former employee of security firm Huntress, accused another analyst of passing communications from U.S. law enforcement to DevMan. The incident is said to have taken place in December 2025.

In a subsequent blog post, Huntress CEO Kyle Hanslovan said the company is aware of "questionable, long-term threat actor communications" between a threat researcher who is still employed with the security firm and a cybercriminal, calling it "poor judgement."

"In one particular exchange, our current teammate disclosed to a threat actor that law enforcement had reached out to them about the threat actor," Hanslovan said. "While this disclosure was not illegal, it reflected poor judgment."

"As a result of the investigation, my team implemented more robust policies for our researchers, coached teammates on engaging with threat actors, and took appropriate administrative actions. While we haven't found evidence of illegal conduct, insider activity, or additional disclosures, we are continuing our investigation."

Holland, however, has disagreed with the assessment, stating that the employee's actions "meet the definition of an insider threat." The ex-Huntress employee also questioned Huntress if the analyst was permitted to engage with DevMan to "support active investigations."

Per Folland, the U.S. Federal Bureau of Investigation (FBI) is said to have contacted the Huntress employee to gather intelligence on DevMan. "She immediately forwarded the exact FBI communications to the threat actor, including screenshots containing FBI agent names," Folland said. "She informed DevMan that law enforcement was actively looking into him. She also refused to cooperate because they wanted DevMan."

"This was not just 'poor judgment,'" Folland continued. "This was a Huntress employee taking sensitive knowledge about a law enforcement approach and passing it directly to the person being investigated. If someone inside a bank warns a fraudster that police are investigating them, nobody would describe that as merely 'poor judgment.' They would call it what it is - an insider."

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

Researcher Publishes GitLab RCE PoC Letting Authenticated Users Run Commands as Git

Security researcher Yuhang Wu at depthfirst has published a working proof-of-concept (PoC) exploit that executes commands as git on an unpatched self-managed GitLab 18.11.3 server.

An ordinary authenticated user triggers it by committing two crafted Jupyter notebooks and requesting their diff. The chain needs no administrator rights, continuous integration (CI) runner access, victim interaction, or access to another user's project.

The public exploit is build-specific to GitLab 18.11.3 on x86-64; the underlying Oj bugs affect broader releases. The affected ranges are GitLab Community Edition (CE) and Enterprise Edition (EE) 15.2.0 through 18.10.7, 18.11.0 through 18.11.4, and 19.0.0 through 19.0.1.

The first fixed releases are 18.10.8, 18.11.5, and 19.0.2. Oj is a high-performance JSON parser for Ruby with substantial native C code.

Published gems 3.13.0 through 3.17.1 are vulnerable; 3.17.3 is the first published release containing both fixes. The flaws affect Free, Premium, and Ultimate. Ruby itself is not affected.

Successful exploitation runs as git. Its effective reach depends on deployment isolation, but may include source code, Rails secrets, service credentials, CI/CD data, and internal services reachable from the application. GitLab.com was patched by June 10.

Dedicated customers need no action. Self-managed operators should move to a supported release containing the fix. Helm and Operator users need to check the GitLab version inside the Webservice image, not only the chart or Operator version. depthfirst said it was unaware of in-the-wild exploitation as of July 24.

Neither the depthfirst disclosure nor GitLab's June 10 release notes list CVE identifiers or CVSS scores for the two chain bugs. Neither provides a temporary workaround; both direct self-managed operators to upgrade.

The Hacker News has asked GitLab about CVE status, classification, and exploitation evidence. It also asked depthfirst about exploit portability and whether a supported temporary mitigation exists. Responses are pending. depthfirst lists nine CVEs for other Oj flaws found in the same review.

GitLab's notebook renderer passes repository-controlled .ipynb JSON to Oj::Parser.usual.parse inside a long-lived Puma worker. That sends attacker-controlled notebook data into Oj's native parser state inside GitLab's application process.

depthfirst's technical analysis shows how one bug controls a callback pointer, while the other leaks a heap address needed to narrow the address space layout randomization (ASLR) search.

Oj stores nesting state in a fixed 1,024-byte stack but never checks whether the depth exceeds it. Deeply nested arrays can therefore write 0x01 bytes into adjacent parser state. The exploit corrupts buf.head, causing Oj to pass a forged interior pointer to realloc(). A later Ruby Array allocation reclaims the same 3,584-byte jemalloc region and overwrites p->start.

Oj allocates a 65,565-byte object key, truncates its length to 29 in a signed 16-bit field, and returns 29 bytes containing the live key-allocation pointer. GitLab carries that pointer into the rendered notebook diff, giving the exploit the address leak needed to narrow the ASLR search. On the profiled two-worker GitLab 18.11.3 installation, the search usually took five to ten minutes. The researchers projected one to two hours across the widest mature-worker range.

Two lexically ordered notebook files in one diffs_stream request keep both stages inside the same Puma worker, which reuses the process-global Oj parser. The first file corrupts the callback and raises an error that GitLab catches before continuing the diff. The next parse invokes the overwritten pointer and reaches system() through a build-specific gadget sequence.

The public demonstration packages the chain in a local GitLab 18.11.3 x86-64 lab and makes the Puma worker connect back as git.

depthfirst reported the Oj bugs on May 21, and the maintainer merged the fixes on May 27. Oj 3.17.3 shipped on June 4. The researchers reported the GitLab chain on June 5; depthfirst said GitLab confirmed it on June 8.

GitLab released the fixed versions on June 10 and resolved the report on July 17, according to depthfirst. A review by The Hacker News found GitLab listed the Oj 3.17.3 bump under bug fixes rather than in the security-fix table and did not describe the notebook-diff RCE chain.

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

Strong vs eventual consistency in 2026: how to choose the right guarantee

Should every workload use strong consistency now that distributed SQL has matured? Not necessarily. Different applications tolerate different failure modes. Our new article explores where strong consistency pays off, where eventual consistency still wins, and how AI changes the equation.

Two shoppers click Buy on the last item in stock at the same instant. Does the system take both orders? Or does the second shopper immediately see the item’s gone?

That’s the difference between strong and eventual consistency. For over a decade, the industry defaulted to eventual consistency because strong consistency simply couldn’t scale. In 2026, that assumption deserves another look. Distributed SQL has made strong consistency practical at scale, and AI pipelines have turned stale reads into production bugs you’ll actually care about.

Why the tradeoff changed in 2026

Around 2010s, the rules were simple: if you wanted to scale, you accepted eventual consistency. Today that tradeoff is far less rigid.

Distributed SQL databases can now give you strongly consistent reads across regions without giving up the scalability enterprises expect – Google Spanner and CockroachDB brought this architecture into the mainstream, TigerBeetle’s joined them more recently, and the list of workloads that genuinely need eventual consistency is shrinking faster than most teams want to admit.

In modern systems, it usually belongs at the storage or caching layer, not in the service or API layer. Treating it as a default for every workload is a mistake.

AI reopened the question from the other side. Retrieval pipelines and AI agents routinely write data and read it back seconds, or even milliseconds, later. That might be a newly generated embedding or stored memory. It might be the result of a tool invocation. On an eventually consistent system, the write may not be visible yet. A one-second delay you wouldn’t notice in a social media feed (where it probably doesn’t matter) suddenly becomes an AI agent that’s making decisions on incomplete information.

Storage is moving the same way. Amazon S3 moved to strong read-after-write consistency for all objects in 2020 (after years of eventual consistency) and added conditional writes in 2024. Stronger consistency guarantees are becoming the default wherever they solve real operational problems. You shouldn’t inherit eventual consistency just because it was yesterday’s best practice.

 

Figure 1. Comparison of strong and eventual consistency models.

 

What strong and eventual promise

Strong consistency (its formal name is linearizability) means that once a write’s acknowledged, every later read from any node returns that value. There are no stale reads. The system behaves as if there’s a single copy of the data even when three copies sit on three different machines.

Eventual consistency means writes are accepted immediately and copied out in the background. Replicas can disagree for a short window, but they converge once writes settle and replication keeps running. Eventual doesn’t mean wrong forever; it means briefly stale, and the length of that window is exactly what you’re trading on. You accept that tradeoff in exchange for lower latency and higher availability.

Weak consistency is the third model. It provides no guarantee that you’ll read the latest value at all. That’s perfectly acceptable for multiplayer games or live leaderboards where responsiveness matters more than precision. Eventual consistency sits between these two extremes. It offers predictable convergence without the strict guarantees of linearizability. Amazon’s product catalog illustrates eventual consistency well. A price update or review count may take a short time to appear everywhere, and customers rarely notice. The checkout and payment systems behind that same website are built differently because they can’t tolerate stale reads. Most large-scale systems naturally split workloads this way. None of these models is universally “better.” They just optimize for different balances. If you understand that, you can pick the right guarantee.

Enough theory.

On to the CAP theorem.

Model	Reads the latest write?	Latency	Availability under failure	Typical fit
Strong	Always	Higher	Lower, may go read-only	Ledgers, inventory, locks
Eventual	After a short delay	Lower	Higher	Feeds, caches, analytics
Weak	Not guaranteed	Lowest	Highest	Games, live dashboards

 

The tradeoff you cannot escape

No distributed system can simultaneously guarantee strong consistency, high availability, and partition tolerance during a network partition. That’s the essence of the CAP theorem. When partitions occur, a strongly consistent system may reject reads or writes to preserve correctness. The exact behavior depends on its design.

An eventually consistent system can keep serving requests and reconcile replicas afterward. In practice, MongoDB and HBase generally favor consistency, while Cassandra and DynamoDB favor availability. That said, CAP is often oversimplified. Real network partitions are relatively uncommon, and the familiar “pick two” explanation hides the tradeoff you’ll notice every day: latency.

PACELC makes this explicit: if there’s a partition, you choose between availability and consistency, and else, during normal operation, you choose between latency and consistency.

That second half matters far more in day-to-day operations. Even on a perfectly healthy network, a strongly consistent read usually waits for a quorum response. Those additional milliseconds are the ongoing cost you’ll pay for stronger guarantees.

How the guarantee gets enforced

Two mechanisms do most of the work behind the scenes: quorum protocols at the database layer and replication underneath.

Strong consistency typically relies on quorums. If the read quorum plus the write quorum exceeds the total number of replicas, every read is guaranteed to overlap with the latest successful write. That overlap prevents stale reads.

Imagine three replicas. If the system requires acknowledgments from two replicas for every write and consults two replicas for every read, those groups must always share at least one node. That shared replica contains the newest committed value, so stale reads can’t happen. This overlap is the core idea behind quorum-based consistency.

Replication determines how writes reach those replicas, and two approaches dominate: synchronous and asynchronous. Synchronous replication waits until every required copy acknowledges the write before reporting success, which provides strong consistency, although write latency is limited by the slowest participating replica. Asynchronous replication acknowledges the write immediately and replicates it afterward, so your application sees lower latency, but a node failure before replication completes can still lose the most recent writes, and that’s the price you pay for speed. Consensus protocols like Paxos and Raft coordinate this process by ensuring every node agrees on the order of operations. The implementations differ, but the practical takeaway is simple: reaching agreement requires additional network round trips.

Where strong consistency is non-negotiable

Some workloads treat a stale read as a bug that costs money or breaks safety.

Financial transactions are the obvious example.

A balance that still appears positive after funds have been withdrawn is stale data escaping into production.

So is an oversold airline seat.

A customer charged twice is the same problem.

Imagine two customers buying the final copy of a book within milliseconds of each other. Without strong consistency, both purchases succeed. Your operations team’s got to issue refunds and sincere apologies.

A subtler failure mode shows up in read-modify-write workflows. Marc Brooker’s AWS example is the classic illustration: an application creates a resource and immediately reads it back. If that read reaches a lagging replica (maybe in a different availability zone), the database responds as though the resource never existed. From the application’s perspective, time’s just moved backward.

Teams often try masking this with retry loops and arbitrary sleep intervals. Those workarounds add latency. They’ll still fail if the resource’s been genuinely deleted instead of simply delayed.

That’s why banking platforms and inventory systems willingly pay the latency cost of strong consistency. It’s also why Google Spanner introduced TrueTime to provide external consistency across regions, and why AWS built Aurora DSQL around strongly consistent reads.

Where eventual consistency is the right call

Strong consistency isn’t the answer everywhere. For many workloads, eventual consistency remains the most practical choice.

Netflix serves viewing history and recommendations from eventually consistent Apache Cassandra clusters. Profile data lives there too. If the “Continue Watching” row updates a few seconds late, you won’t notice. DNS works the same way.

Record changes propagate gradually across the Internet, yet the entire ecosystem’s designed around that behavior. Content delivery networks such as Cloudflare and Akamai intentionally cache slightly stale content at the edge. Users benefit far more from fast responses than from perfectly fresh assets. Analytics and reporting platforms make similar tradeoffs. They’ll choose availability over reading the newest possible byte.

Cost’s also a factor. Amazon DynamoDB prices eventually consistent reads at roughly half the cost of strongly consistent reads. If you can tolerate a few seconds of staleness, you’ll pay significantly less.

Strong consistency pushes cost the other way. Synchronizing replicas requires extra consensus traffic and CPU time, and it’ll burn more cross-region bandwidth too. If every read uses strong consistency by default, infrastructure costs go up even when the application’s gaining little from the stronger guarantee.

That’s why most modern architectures mix both models. Use strong consistency where stale data creates correctness problems. Eventual consistency fits where responsiveness and availability matter more than reading the absolute latest value, or where cost’s the deciding factor. Amazon S3’s move to strong read-after-write consistency is a good example of this principle. The company strengthened consistency exactly where it eliminated a class of bugs developers repeatedly encountered. Other parts of the architecture stayed optimized for scale.

The storage layer already made this choice for you

Most discussions of consistency stop at the database. In practice, your consistency guarantee’s only as strong as the storage beneath it.

If the block layer loses the last acknowledged write after a node failure, the strong consistency you configured one layer above becomes a promise the infrastructure can’t keep.

The familiar read-replica race has a storage equivalent (and it’s just as painful). Asynchronous block replication acknowledges a write before the secondary copy exists, so during failover the application can suddenly see data that’s older than what it’s already committed.

This is where synchronous mirroring matters. StarWind VSAN protects acknowledged writes by mirroring every write between two storage nodes and confirming it only after both copies are safely committed. A two-node deployment using the Heartbeat failover strategy can provide high availability without a separate witness node; the footprint stays small.

For larger heterogeneous estates, DataCore SANsymphony applies the same synchronous mirroring across mixed arrays for tier-one block workloads.

In practice, the decision’s straightforward. Match the storage guarantee to the workload. There’s little value in synchronously mirroring data that’s read once every quarter, yet placing a financial ledger on an eventually consistent storage tier makes equally little sense.

What AI and agentic workloads change

AI’s changed consistency from a database setting into an infrastructure decision. Agent and retrieval workflows are fundamentally read-modify-write loops (they’re the same pattern at a different scale). They might generate an embedding, store a memory, or record a tool result. Whatever they write, they’ll often query it immediately. On an eventually consistent vector store, that write won’t be searchable yet.

The reason’s usually the index. Approximate nearest neighbor (ANN) indexes are rebuilt incrementally. A newly inserted vector can remain invisible to similarity search for seconds or even minutes, even though the underlying database already stores it and would return it through a direct lookup. For a chatbot summarizing last quarter’s reports, that delay rarely matters. An autonomous agent acting on a record it created moments earlier faces a correctness bug. These often slip through testing because quick demos rarely expose the timing window.

If you’re on the infrastructure team, this quickly becomes a placement question. Real-time inference and agent memory are increasingly deployed close to the compute layer. That might be on-premises. It might sit at the edge. Dedicated AI clusters are another common target. As a result, the consistency guarantees provided by the underlying storage directly affect application behavior.

That doesn’t mean every AI workload needs strong consistency. It means identifying the handful of operations where an agent can’t safely act on stale state. Let retrieval, analytics, and other latency-sensitive paths benefit from eventual consistency.

It isn’t always binary: tunable consistency

Consistency isn’t always an all-or-nothing switch. Apache Cassandra lets you choose a consistency level for each operation. A single-replica read minimizes latency. Quorum reads provide strong enough guarantees for many workloads. Full agreement across every replica delivers the strongest consistency, but you’ll pay with higher latency and reduced availability. That flexibility means the same application can require strong consistency during checkout while serving product pages with eventually consistent reads.

Between those two extremes sit several useful middle-ground guarantees. Read-your-writes consistency ensures you’ll see your own updates. Monotonic reads prevent a session from moving backward in time. They stop the system from returning older versions of data after newer ones have already been observed.

Causal consistency’s particularly useful for collaborative applications. It preserves the order of related operations: a reply never appears before the message it’s responding to. Messaging platforms and social networks benefit from this behavior without paying the cost of global coordination, which is why you’ll often see it in threaded comment systems and shared document editors.

In practice, very few distributed systems need one consistency model everywhere – the checkout flow and the analytics pipeline have utterly different requirements, and that’s fine. These days, databases let you pick the right guarantee per operation. Pick per operation. Don’t pick once for the whole stack.

Matching the guarantee by workload

The same tradeoffs hit differently depending on what you’re running. No surprise there. A retail warehouse and a cardiac monitor don’t share the same constraints.

Financial services and e-commerce

Checkout flows keep strong consistency on the transaction path. You can’t afford a double-charge because a replica lagged behind.

Media and healthcare

Archives hold petabytes of cold objects, and eventual consistency on an object tier is the sensible, low-cost choice. Nobody’s waiting on an MRI from 2019 to propagate instantly.

SaaS and content platforms

Run eventual on the read path and reserve strong guarantees for the few operations that guard money or identity – billing, access control, that sort of thing. Most reads don’t need the newest byte immediately.

AI platforms

Lean eventual for bulk retrieval and analytics, and keep strong consistency only where an agent acts on state it just wrote. That’s rarer than most AI marketing suggests – usually it’s limited to narrow update paths in most stacks. (Most of the time the model’s just reading stale training data and nobody cares.)

Multi-site retail

You can run a two-node, synchronously mirrored cluster at each location. Failover keeps critical local state available without forcing every transaction through a distant regional round trip. It’s slower, but the register stays up when the WAN hiccups.

How to choose

Start with one question for every operation: what happens if this read’s a few seconds stale? If the answer involves money or safety, strong consistency is usually the right choice – those are exactly the domains where a stale read turns into a real incident that’s hard to unwind. Where nobody would notice, eventual consistency will likely give you better performance at lower cost.

From there, the checklist is short. Think in terms of single operations, not whole applications, and apply strong consistency only where it delivers measurable value. Use tunable consistency levels if your database supports them. Also verify that your storage layer can actually uphold the guarantees your database claims, because a database configured for strong consistency is only as good as the replication running underneath it, and if that replication is asynchronous you’ve basically bought a label, not a guarantee. Then measure the latency. It matters. Even on a healthy network, strong consistency carries a cost, and that cost needs to be justified by the workload.

Most production systems end up somewhere in the middle. They combine strong and eventual consistency and apply each where it fits best. In 2026, more databases and storage platforms let you make that decision per operation instead of forcing one model across the entire system, which finally means you can tune by query rather than by cluster. That’s a welcome change – most teams have spent years over-provisioning clusters because vendors wouldn’t let them mix guarantees inside one deployment.

FAQ

Is eventual consistency just unreliable?

No. It’s briefly stale, then convergent. Give it a pause. Every replica ends up holding the same value, assuming the system’s healthy.

Can one system use both models?

Yes. Many engines expose tunable, per-operation consistency, so one application can run strong writes and eventual reads together. You don’t have to pick one model for the whole codebase.

How does storage replication affect my database’s consistency?

Directly. Asynchronous block replication can lose the last acknowledged writes on failover, and that quietly undercuts any strong guarantee you’ve configured above it, no matter what the database console claims. (Your database thinks it’s synchronous. The SAN underneath disagrees.)

Did distributed SQL make eventual consistency obsolete?

No. It made strong consistency cheaper at scale, but eventual still wins wherever latency and availability matter more than reading the newest byte, and that’s still most of the time.

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

Your Best Analyst Shouldn’t Be a Person. It Should Be a Capability Everyone Can Summon.

For thirty years, we have measured security operations by the tools we buy. The next decade will measure us by the outcomes we deliver. That shift is already here, and it is being driven by something quietly radical: a repository of AI “skills” that turns the deep expertise of a principal analyst or engineer into a capability any team member can invoke on demand.

I want to talk about what that actually changes for the business, not the bits and bytes underneath it.

The problem every CISO already knows by heart

You are not short on data. You are drowning in it. Endpoint telemetry, identity logs, firewall traffic, cloud control planes, email security, SaaS audit trails. Each one speaks a different language. Each one demands a specialist who knows where the bodies are buried. The talent who can fluently read all of them at once is rare, expensive, and almost certainly already burned out.

So the work stacks up. Alerts wait. Investigations get triaged by whoever is awake. The third repeat of an attack pattern goes unnoticed. The analyst who caught the first two left for a competitor. Your security posture quietly becomes a function of who happens to be on shift.

This is the real cost center in modern security operations: expert human attention, not licenses or infrastructure. There is never enough of it.

What changes when expertise becomes a skill

The ai-siem repo, located on the Sentinel One GitHub community (https://github.com/Sentinel-One/ai-siem/tree/main/plugins/s1-secops-skills), attacks that bottleneck directly. Instead of asking a human to remember how to query log sources, pivot through threat intelligence, correlate findings, and write it all up, each of those steps becomes a skill. Captured once. Available to everyone, every shift, every time.

Disclaimer: This sample script/prompt is community-contributed, open-source content provided “AS IS,” without warranty of any kind. SentinelOne does not certify or endorse it, is not responsible for its accuracy or outputs, and is not liable for any outcomes arising from its use. Test and validate in a non-production environment before use.

The senior analyst’s playbook stops living in one person’s head. It becomes a durable asset owned by the whole organization. That single change cascades into outcomes leadership actually cares about.

The data lake is the foundation nobody’s talking about

Here is the part that makes the rest of it work. It is the most underrated shift in security right now. Skills are useless if the data lives in a dozen disconnected silos. Each has its own query language, retention tier, and price per gigabyte. The reason this whole model becomes possible is the security data lake. A single place where endpoint, identity, network, cloud, email, and your own application logs land together in one queryable substrate, at a cost that doesn’t punish you for keeping data.

This is where SentinelOne’s Singularity Data Lake stops being infrastructure and starts being the differentiator. It was built for streaming AI from day one, not retrofitted onto it. That architecture is what makes an AI analyst viable. Data becomes searchable the moment it arrives. No indexing delay to wait through. Everything stays hot and searchable. All of it. There’s no cold tier to thaw, and no log you quietly dropped because retention got expensive. It scales to petabytes where legacy SIEMs buckle at terabytes. And it does this at more than ten times the query performance, for less than half the cost of the per-gigabyte SIEM model it replaces.

Translate that into outcomes, and the picture is stark. Ingestion, detection, and query that used to take minutes to hours on a legacy SIEM now happen in seconds. More than 2,000 detections run in the stream itself. Threats surface as the data lands, not minutes after it’s stored. That speed is not a nice-to-have. An AI agent is only as fast as the data underneath it. Give it a lake that answers in under a second, and it reasons across your entire estate before you’d have opened one console tab.

That is what breaks the twenty-year SIEM economics. For twenty years, the industry’s answer to “where do we put all the security data” was a SIEM. One that charged so much per gigabyte that teams were forced to drop the very logs they later wished they’d kept. The data lake inverts that math. Keep everything. Query everything. Correlate everything. Let the ingest bill stop dictating your detection strategy. The skills are the brain. The data lake is the nervous system, letting the brain feel the whole body at once, instantly. You cannot have the outcomes below without it.

This is Autonomous Cybersecurity (AI-Native Protection Across the Enterprise) in practice. Autonomous Security Intelligence, ASI, is the intelligence fabric that runs on top of that data. It is not a bolt-on skill pack. It is what turns a queryable lake into an analyst that never sleeps.

Outcome 1: Investigations that took a shift now take minutes

The gathering is the slowest part of any investigation, not the decision: pulling the alert, finding the affected asset, enriching every indicator against external intelligence, sweeping the rest of the fleet for the same fingerprint, and assembling the timeline. That is hours of skilled work that have to happen before anyone can even say “true positive” with confidence.

When those steps run as orchestrated skills, the gathering collapses into minutes. Your analysts spend their judgment on the verdict and the response, which is the part only a human should own. Mean time to detect and mean time to respond stop being aspirational metrics on a slide. They become numbers you can defend to the board.

Outcome 2: A first-year analyst operating at a principal level

This is the one that genuinely reshapes the org chart. When the hard-won method of your best investigator becomes a skill, a junior analyst inherits it directly: the answer, arrived at the right way, with evidence cited, confidence calibrated, and assumptions flagged.

The skills gap that has defined this industry for a decade narrows dramatically. You stop competing for the handful of unicorns who can do everything, because everything is now a shared capability. Tier-one talent does tier-three work. New hires become productive in days, not quarters. And the people you already have stop drowning. That’s how you keep them.

Here is what convinced me that this is real and not a demo. It was not a SOC analyst who proved it first. It was an engineer. Reviewing application logs, they surfaced a genuine fraud case. A true positive lived in business telemetry. No traditional security tool was even watching. Sit with that for a second. People who do not carry a security title, looking at data that never reaches the SIEM, caught actual fraud. That is what happens when investigative expertise stops being gated behind a job description. The capability travels to wherever the data and the curiosity are. Threats that used to hide in the gaps between teams suddenly have nowhere to live.

More impact per analyst and greater control with less fatigue.

Outcome 3: No blind spots, because nothing gets correlated in isolation

Attackers do not respect your tool boundaries. They land in email, execute on the endpoint, move through identity, and leave through the network. A threat that is invisible in one source is often obvious the moment you line it up against three others. The trouble is that lining them up has always required a specialist for each layer. All working in concert, under time pressure, at 3 am.

Cross-source correlation built into the workflow doesn’t depend on who’s in the room. The full attack story assembles itself. You see the chain, not the fragments. The single most dangerous phrase in security operations, “we had the data, we just never connected it,” starts to disappear.

Outcome 4: Every alert arrives with context already attached

A medium-severity alert on a domain controller matters more than a critical one on a throwaway sandbox. Every experienced analyst knows this. Yet most alerts land in the queue as bare indicators with no business context. Someone has to hunt down what the asset is, who owns it, and whether it matters. That manual lookup happens thousands of times a week. It’s where prioritization quietly goes wrong.

When asset enrichment runs autonomously, every log and every alert already carries the device and user context that determines its importance: what the machine is, how critical it is, and whose account is involved. The queue effectively sorts itself by business impact. Analysts stop chasing noise in disposable systems and spend their time where the real risk lies. False-positive fatigue drops, and the genuinely dangerous signal stops getting buried under the trivial. Prioritization by business impact stops being an aspiration and becomes the automatic default.

Outcome 5: Proactive defense, finally, at machine speed

Known-bad signatures catch yesterday’s threats. The adversaries that actually hurt you, the patient ones and the insiders, only ever show up as deviations from normal. A login at an impossible hour. A workstation reaching a destination it’s never touched. A service account suddenly behaving like a human.

Hunting for that kind of anomaly across the entire estate, continuously, has always been a luxury. Reserved for the most mature and best-funded teams. Make it a repeatable skill and proactive hunting stops being a quarterly project you never quite get to. It becomes the default mode of the SOC. You move from reacting to alerts to anticipating the attacker’s next move. That is the whole point of the discipline. Most teams never have the capacity to actually do it.

Outcome 6: A new threat in the headlines becomes a detection the same morning

When a new campaign breaks, the clock starts immediately. The window between “this threat is now public” and “we are protected against it” is pure exposure. Historically, that window has been measured in days or weeks. Someone has to read the intelligence, translate it into detection logic, test it, and push it live. That someone is usually already underwater.

Make detection engineering a skill, and that window collapses to a morning. The moment an emerging threat surfaces, its behavior becomes a live detection rule: validated and deployed across the estate before the first coffee gets cold. Your defenses move at the speed of the threat landscape instead of at the speed of your backlog. Just as importantly, the detection logic your team writes today gets captured and reused. Coverage doesn’t just grow. It compounds.

Outcome 7: New data sources onboarded in minutes, not quarters

Onboarding a new data source has traditionally been a small project: parse the logs, normalize the fields, build the dashboards, write the detections, and wire up the response. Weeks of specialist time have to pass before that source earns its keep. That’s exactly why the backlog of “sources we really should be ingesting” never shrinks.

That math is now broken in your favor. When those steps are packaged as skills, a new feed goes from raw and unreadable to fully operational in minutes: normalized, with detections firing and a dashboard live. Read that again, because it rewrites your roadmap. Every integration you’ve been deferring for budget or bandwidth reasons just got cheap. Cheap enough to do the same day someone asks for it. Coverage stops being a function of how many quarters you can fund. It becomes a function of how fast you can decide.

That is the compounding version of Maximize Efficiency and Effectiveness of Security Operations: coverage that gets cheaper and faster to extend every time you use it.

The economics that should end the conversation

Now brace for the part that makes the CFO lean in. Everyone assumes the AI is the expensive bit. It is the opposite. Bring-your-own-AI on top of the data lake costs peanuts relative to what it replaces and the work it does. The heavy historical spending on security operations was never on intelligence. It was on the ingestion licensing of a legacy SIEM, and the salaries of specialists doing by hand what a skill now does in seconds.

Sit the two columns next to each other. On one side: per-gigabyte SIEM pricing that grows with your business, whether or not it makes you safer. Plus the fully loaded cost of analysts spending their nights on manual gathering. On the other: a data lake built for scale, and an AI layer whose run cost rounds to a rounding error against either line item. The capability goes up and to the right while the cost line stays flat. That’s a different business model for security. It’s a rare case where the cheaper option is also the more capable one.

This is Enable Business Growth and Innovation Safely in dollar terms: the budget fight between “more coverage” and “more efficient spend” disappears, because the same architecture delivers both.

The deeper shift: the SOC stops being a cost center and starts compounding

Here is the part that should excite anyone running a security budget. Every investigation a human does is an effort spent once and largely lost. Every investigation captured as a skill is an effort spent once and reused forever. Your operation stops being a treadmill and starts being an asset that compounds. The work your team does today makes the work tomorrow faster, cheaper, and more consistent.

AI answering faster is the easy headline. The real shift: institutional security expertise stops walking out the door and starts accumulating on the balance sheet.

What I would tell a peer

We have spent a generation buying tools and hoping the outcomes follow. The teams that win the next decade will flip the order. Define the outcomes first. Then make the expertise to achieve them a capability everyone can summon, day or night, junior or senior, first alert or thousandth.

The technology to do this exists now. Our purpose is simple: to give the advantage to those who secure our future. That advantage only counts if it reaches every analyst, not just the ones already fluent in every log source. The organizations that adopt it won’t just be faster. They’ll run a fundamentally different kind of security function: one where the best analyst in the building is available to everyone, all the time, and gets sharper with every case it touches.

The bottleneck was never the data. It was access to expertise. That bottleneck just broke.

If you run a SOC, lead security for your organization, or work the queue every day: how much of your team’s best thinking is locked inside one or two people right now? That is the question worth sitting with this week.

Curious what this looks like in practice for your environment? Come talk it through in our Reddit community, r/SentinelOneXDR. Practitioners there trade real detection logic, ask the SentinelOne team direct questions, and compare notes on what’s actually working in their SOCs.

Disclaimer:  The sample scripts, code, AI prompts, and other tools referenced or included in this publication (“Community Content”) are provided for informational and educational purposes only. Community Content is contributed on an open-source basis and is made available “AS IS” and “AS AVAILABLE,” without warranties of any kind, whether express, implied, or statutory, including, without limitation, any warranties of accuracy, completeness, reliability, merchantability, fitness for a particular purpose, or non-infringement.

SentinelOne does not certify, endorse, or guarantee any Community Content, its outputs, or its suitability for any particular use, and Community Content does not constitute part of any SentinelOne product or service offering. SentinelOne has no obligation to maintain, support, or update Community Content. AI prompts in particular may produce inaccurate, incomplete, or unexpected results depending on the model, configuration, and environment in which they are used.

Any use of Community Content is at your own risk. You are solely responsible for evaluating, testing, and validating any Community Content in a non-production environment before use, and for ensuring your use complies with applicable laws, licenses, and your organization’s policies. To the maximum extent permitted by law, SentinelOne and its affiliates will not be liable for any damages, losses, or outcomes of any kind arising out of or relating to the use of, or reliance on, Community Content. Where Community Content is hosted in or links to a third-party repository (e.g., GitHub), your use is also governed by the applicable open-source license and the terms of that platform.

from SentinelOne https://ift.tt/X94Btaj
via IFTTT

Seeing AI Agents Is Not Enough. Security Teams Must Enforce What They Can Do

AI agent security is moving through a familiar maturity curve: adoption, then visibility, and finally, control. But what we've collectively discovered is that enforcing least privilege for AI agents is harder than we ever imagined. This is why there are so many approaches, from prompt filtering to identity-layer access controls. Where we've collectively landed is that understanding the intent of AI agents is essential to securing them. It's not easy, but it's the only path forward.

Organizations approach this challenge with different levels of sophistication. For many, the current goal is simply to find the AI agents already operating across the business. That is a necessary first step. AI agents are appearing in SaaS platforms, developer environments, cloud workflows, customer support systems, productivity tools, and internal applications. Some are sanctioned, and others are not.

But discovery alone isn't useful. AI agents are not passive; they reason, plan, call tools, invoke APIs, access data, and take action without a human in the loop. The risk is not that an organization has too many agents. The risk is that those agents can operate across systems without consistent identity, intent, ownership, and enforcement. There are also different types of AI agents, each requiring a different approach to securing them.

Recent guidance on the careful adoption of agentic AI services makes the point clear: agentic AI introduces privilege, authentication, accountability, design, and behavioral risks that security teams need to address before these systems become embedded in critical workflows. Visibility is the starting line, but enforcement is what matters.

The Visibility Trap

Most security programs begin with the question: "What do we have?" That made sense for cloud, SaaS, endpoints, identities, and vulnerabilities. It also makes sense for AI agents.

But the risk of stopping at visibility alone for AI agents is greater than in every other environment in the list because of the speed with which AI agents are being created, what they have access to, and how they can be shared.

An AI agent inventory that does not connect to enforcement becomes another static asset list. It may show that an agent exists, but it cannot tell you whether the agent's access is appropriate, its behavior matches its purpose, its owner remains accountable, or when its permissions should be revoked as conditions change. For AI agents, visibility without enforcement creates a dangerous kind of confidence, where it's easy to feel in control when the reality is far different.

Why AI Agents Break Static Access Models

Traditional access control assumes some level of predictability. Human Identity and Access Management has it the easiest, as each person has a job function. Non-human or machine identity management is more complex, but a service account still supports a defined workload. These assumptions are imperfect, but they gave security teams a foundation for roles, entitlements, approvals, access reviews, and periodic cleanup.

AI agents are far from static. An agent is defined less by a fixed workflow and more by a goal. It may interpret instructions, call different tools, and adapt its actions based on context. Two agents with similar permissions may have a very different risk profile, depending on what each is trying to accomplish.

Static access is not enough because AI agents are more likely to be used in ways not anticipated when access was granted. The issue is not always malicious behavior but ambiguity that poses a risk, such as a task that expands beyond its original purpose.

The question security teams need to ask is not only "what can this agent access?" The more important question is: What should this agent be allowed to do, under these conditions, for this purpose? That is an enforcement question.

Enforcement Starts With Better Understanding

Effective AI agent enforcement cannot be bolted onto a basic, non-contextual inventory. Security teams need to correlate information across owners, consumers, identities, systems, permissions, and intent before they can define meaningful controls.

That means understanding an agent across several dimensions:

• Ownership: Who owns the agent? (This can be more difficult than you may think.)
• Consumers: Who is using the agent?
• Identity: Which identities, tokens, secrets, OAuth grants, and service accounts does the agent use?
• Intent: What is the agent supposed to accomplish?
• Access: Which systems, applications, data stores, APIs, and infrastructure can it reach?
• Usage: What has the agent actually done, and how often?
• Origin: How was the agent created?
• Lifecycle: Is the agent active, dormant, or no longer tied to its original purpose?

This is where many organizations struggle because agent context is scattered. Identity data lives in one place. Cloud permissions are somewhere else. SaaS integrations have their own models. Infrastructure as code can reveal intended deployment patterns, but that context is rarely correlated with the rest. Ownership may be obvious to the person who created the agent and invisible to everyone else.

Without correlation, enforcement becomes guesswork. With correlation, security teams can begin defining rules that reflect how agents actually operate.

Many security tools equate enforcement with remediation. Something risky is found, and a playbook opens a ticket, removes access, disables an identity, or notifies an owner. That is useful, but it is not enough for agentic AI. AI agents need enforcement before, during, and after they take action.

Security teams need to move from asking, "What should be removed after risk is detected?" to "What should this agent be allowed to do in the first place?" That shift moves enforcement from cleanup to control. Organizations can then define rules such as:

• A customer support agent can read ticket history, but cannot export customer data in bulk
• A code assistant can suggest changes, but cannot push to production without an approved workflow
• A cloud operations agent can inspect configuration drift, but cannot modify privileged roles
• A finance agent can generate reports, but cannot initiate payments or change vendor details
• A security agent can triage alerts, but cannot delete logs or suppress detections

These rules cannot be managed effectively inside one AI platform at a time. Enterprises will use many agent platforms, SaaS-native agents, internal frameworks, cloud services, and developer tools. Each may have its own controls, logs, and permission models. Security teams need a consistent way to govern agents across that fragmented environment. That is why the next control plane for AI agents has to be identity-centric, context-aware, and platform-agnostic.

The Role of Intent in Enforcement

Identity answers who the agent is. Permissions answer what access exists. Intent answers why that access should be active.

The intent dimension is essential. AI agent risk cannot be understood only by looking at whether an API call is technically permitted. Security teams need to evaluate whether an action aligns with the agent's approved purpose.

Intent-based enforcement gives organizations a more precise control model. It allows security teams to move from broad, static permissions to conditional access based on purpose and context. That does not mean every action must be manually approved. It means high-risk actions should be constrained by the agent's role, owner, task, environment, and expected outcome.

The OWASP Top 10 for Agentic Applications highlights risks such as identity and privilege abuse, tool misuse, insecure inter-agent communication, cascading failures, and rogue agents. These risks all point to the same conclusion: security controls must understand the agent's reason to act.

A Singular Control Plane for Agentic AI

AI agents do not live in one platform. They exist across the enterprise. While "traditional" machine identities were created by IT, Developers, and DevSecOps teams, AI agents are created by people in every role in the organization. Some agents will operate in cloud environments, while others will run locally. Some will be embedded in business workflows that security teams do not directly manage.

Platform-by-platform controls for AI agents will not scale. Each platform may provision its own agents, but no single platform can see the full enterprise picture of identity, access, ownership, and lifecycle. Organizations need a unified control plane that can understand agents across environments and enforce consistent rules.

That control plane should do three things:

• Discover: Find agents wherever they exist
• Understand: Correlate agents with identities, owners, access, infrastructure context, usage, and intent
• Enforce: Apply rules that govern what agents can do, when they can do it, and how access should change as context changes

See how AI-first security solutions like Token Security discover, understand, and enforce what your AI agents can do across every platform.

This is the difference between managing agent sprawl and governing agentic AI. Sprawl happens when every platform, team, and business unit creates agents independently. Governance occurs when the organization can apply consistent controls across that activity without blocking innovation.

What Security Leaders Should Do Now

Security teams do not need to wait for perfect standards or fully mature tooling before acting. They can start building the operating model now.

The first step is to stop treating AI agent visibility as the finish line. Of course, agent inventories are the foundation for enforcement. Every agent should be mapped to an owner, a purpose, an identity, a set of permissions, and a lifecycle state. Unowned agents should be investigated, overprivileged agents should be right-sized, dormant agents should be retired, and high-risk actions should require stronger controls.

But ultimately, enforcement is what matters. Security leaders should align AI agent governance with identity and access management, cloud security, application security, and DevOps workflows. Agentic AI is not a separate universe. It is software with access, autonomy, and business impact. It belongs inside the enterprise security model, but that model has to evolve.

NIST's AI Agent Standards Initiative points in the same direction, with work focused on standards, protocols, authentication, identity infrastructure, and secure human-agent and multi-agent interactions. The market is moving toward the same conclusion: AI agents need to be governed as actors with authority, not treated as ordinary applications with a chatbot interface.

Visibility Is the Beginning, but Enforcement Is the Goal.

The first wave of AI agent security was about awareness. Organizations needed to understand that agents were entering the enterprise and creating new identity risk. That message landed, and every security and IAM team knows they need visibility. The next wave is enforcement.

Enterprises need to define what agents are allowed to do and apply rules consistently across platforms. They need to move from "Which agents exist?" to "Which agents can take which actions, under which conditions, and who is accountable?"

That is the control plane agentic AI requires. Not another dashboard or static inventory. AI agents are becoming active participants in enterprise operations. They will write code, manage infrastructure, move data, update systems, and execute workflows. The organizations that succeed with agentic AI will not be the ones that simply find every agent. They will be the ones who understand every agent well enough to enforce what it can do.

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

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

Golden Chickens Resurfaces With Four New Malware Families and Modular Implants

The threat actors behind the Golden Chickens malware-as-a-service (MaaS) ecosystem have resurfaced with four new malware families, indicating that the operators are showing no signs of stopping despite extensive public disclosures into their inner workings.

The malware families in question are: TinyEgg, ChonkyChicken, a modularized variant of ChonkyChicken, and a modified web browser credential theft utility codenamed ChromEggscalator. Recorded Future's Insikt Group is tracking the group under the moniker TAG-195.

TAG-195 is a financially motivated malware-as-a-service (MaaS) developer whose tooling has been previously linked to TAG-127 as an operator and customer. The threat intelligence company said it has also observed TAG-127 deploying TinyEgg via ClickFix-style social engineering campaigns that trick unsuspecting users into manually executing malicious commands.

"The four new families indicate an architectural transition and evolution in the TAG-195 MaaS ecosystem," Recorded Future said. "All four families share a common set of architectural traits: consistent command-and-control mechanisms, a shared persistence approach, string obfuscation, and execution via the same delivery model."

A brief description of each of the tools is as follows -

• TinyEgg, a lightweight initial-access backdoor providing host profiling, interactive shell access, and persistence management
• ChonkyChicken, a fully featured implant that expands on TinyEgg with browser credential theft, live browser session control using Chrome DevTools Protocol (CDP), credential-backed remote execution, network reconnaissance, and sustained surveillance
• A modularized version of ChonkyChicken that introduces a controller-and-plugin architecture that enables the controller to request and load 14 discrete capability modules on demand instead of embedding the entire functionality in the implant
• ChromEggscalator, a successor to TerraStealerV2 and a modified version of a publicly available Chrome encryption-bypass tool called ChromElevator

The shift is a sign that Golden Chickens, also called Venom Spider, is actively refining its arsenal through active development, while deliberately moving to modular, operator-driven tooling for defense evasion.

Associated with a malware family called More_eggs, the threat actor's tools have been put to use by other cybercrime groups like Cobalt Group (aka Cobalt Gang), Evilnum, and FIN6. Another threat actor associated with the Golden Chickens MaaS is TAG-127, which uses ClickFix or VenomLNK as delivery methods.

Attack chains have been found to leverage ClickFix lures to execute OCX payloads downloaded from attacker-controlled staging infrastructure, resulting in the installation of TinyEgg. The malware's functionality is limited to initial access and profiling functions, with all post-exploitation capability passed on to ChonkyChicken. TinyEgg is also designed to terminate execution if sandbox and automated analysis environments are detected.

The malware establishes connections with a C2 server using WebSockets to facilitate an interactive command shell, run operator-supplied input to the active shell session commands, send the output back to the controller, and stage OCX payloads.

The modular version of ChonkyChicken, on the other hand, supports 14 different components that are fetched from the C2 infrastructure as needed, allowing the operators to selectively deliver certain functionality on the fly that monolithic malware architectures cannot easily support without an update mechanism. The 14 modules enable the following functions -

• Process management
• Screen capture and monitor enumeration
• File manipulation
• Command execution
• Network reconnaissance
• Domain-based reconnaissance
• Clipboard capture
• Keylogging
• Audio capture
• Idle time check
• HTTP/S request via host
• Browser theft via ChromEggscalator
• Persistence management

The modular version also supports a module named "wtrack" whose purpose remains unknown. This suggests the addition of an active capability under development.

"TAG-195's transition to a modular architecture almost certainly reduces the base implant's static detection exposure, and likely also reflects commercial incentives inherent to the MaaS model, including the ability to provision capabilities selectively to operators, limit exposure if a customer is compromised, and serve a broader range of operational requirements," the cybersecurity company said.

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

Kimi K3 Agents Found Redis Zero-Days and Built RCE Exploit, Researchers Say

Redis shipped seven security releases on July 23 after researchers published authenticated RCE PoCs for stock Redis 6.2.22, 7.4.9, 8.6.4, and 8.8.0.

All four chains require RESTORE. The Streams chains also need EVAL and XGROUP; the 8.8.0 chain needs EVAL and the bundled RedisBloom module. Redis says the underlying memory flaws may lead to remote code execution.

Redis 6.2.23, 7.2.15, and 7.4.10 fix the Streams shared-NACK use-after-free; Redis 8.2.8, 8.4.5, and 8.6.5 fix both the Streams issue and the RedisBloom and TDigest out-of-bounds writes; Redis 8.8.1 fixes the RedisBloom and TDigest loaders, while the Streams guard was already present in Redis 8.8.0.

Two PoC targets, Redis 6.2.22 and 7.4.9, were the May security updates Redis told users to install, but those releases did not include the shared-NACK ownership guard.

Upgrade to the fixed release for the deployed branch. Until then, revoke RESTORE from accounts that do not strictly need it and block untrusted network access. Restricting RESTORE cuts off both disclosed paths.

Neither Redis's July 23 release notes nor the public PoC repositories reviewed reported in-the-wild exploitation as of July 24, 2026.

Two Paths Through RESTORE

The Redis Streams path is a shared-ownership bug. A corrupt RDB object can make two consumers point to the same pending-entry record, so removing both consumers frees the same object twice.

The published script is designed to turn the resulting memory corruption into arbitrary memory access and ultimately invoke system().

The RedisBloom path is an out-of-bounds write in the TDigest RDB loader. The loader allocated memory from one serialized value but trusted a separate attacker-controlled capacity field when deciding how much data to load.

The Redis 8.8.0 script is designed to turn that mismatch into read and write primitives, leak Redis and libc addresses, and call system().

The Streams Shared-NACK Chain

The first path is in Redis Streams. A corrupt RDB object can make two consumers point to the same pending-entry record, represented internally by a streamNACK. Removing the first consumer frees the object and leaves the second holding a dangling pointer. The scripts then remove the second consumer too. One chunk, two frees.

Redis 8.6.4's release notes cite PR #15081. But a source review by The Hacker News found that the tagged 8.6.4 source lacks the duplicate-ownership check added by that change. The guard appears in Redis 8.6.5, released on July 23.

The published Redis 8.6.4 script is designed to turn the double-free into arbitrary memory access, then poison a database hash function so a crafted GET invokes system(). It restores the pointer and checks whether Redis still responds.

The RedisBloom TDigest Chain

The second path sits in the RedisBloom TDigest RDB loader. It allocated its centroid arrays from a serialized compression value, then trusted a separate attacker-controlled capacity field when deciding how many nodes could be loaded. A small real allocation paired with inflated metadata produces an out-of-bounds write.

The Redis 8.8.0 script is designed to turn the write into read and write primitives, leak Redis and libc addresses, and poison a database hash function so a crafted GET calls system(). A separate proof of concept published the same root cause and an authenticated RCE chain against Redis 8.8.0.

Redis's July fix requires the loaded TDigest capacity to match the allocation derived from the compression value. It also bounds the merged and unmerged node counters before reading the arrays.

Seven Releases, No New CVE Records

The repository calls the Streams issue part of a CVE-2026-25589 "incomplete fix family," but Redis maps that CVE to RedisBloom memory corruption during RESTORE, not the Streams shared-NACK flaw. Redis's July release notes list no CVE or CVSS score for either new bug class.

As of July 24, searches by The Hacker News found no separate NVD record for the July shared-NACK or TDigest findings. NVD still listed the May records for CVE-2026-25243 and CVE-2026-25589. A search of CISA's Known Exploited Vulnerabilities catalog returned no entry for either identifier.

The disclosure follows another AI-discovered Redis RCE flaw patched in May. Bera Buddies describes itself as "AI Agent Research." Chaofan Shou said on X that Kimi K3 agents found 19 Redis zero-days in about 90 minutes, and said another run produced the Redis 8.8.0 exploit in 27 minutes.

Those counts, timings, and the claimed degree of autonomy remain self-reported. Redis's public record confirms the flaws and fixes. It does not validate the claimed zero-day count or how independently the agents worked.

Redis 6.2.22 and 7.4.9 were the May destination. By July, both needed another update. Check the exact branch version, not whether Redis was merely "recently patched."

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

Fake Notepad++ Plugin Delivers MATCHBOIL.V2 in UAC-0099 Attacks

The Computer Emergency Response Team of Ukraine (CERT-UA) has warned of a new campaign that involves the use of a malicious program that's dressed up as a Notepad++ plugin to compromise Windows systems.

The activity has been attributed by the agency to a threat cluster it tracks as UAC-0099, a Russia-aligned group that has previously observed weaponizing security flaws in WinRAR software to deliver a malware strain called LONEPAGE. Other cyber attacks mounted by the adversary have employed phishing emails as an initial access method to deploy MATCHBOIL, MATCHWOK, and DRAGSTARE. It's known to be active since at least mid-2022.

The latest set of attacks begins, observed earlier this summer, with a phishing email containing an image attachment, which, when clicked, opens a URL that's concealed using a link shortener from where the request is sent to a file-sharing service like EasySend[.]co to retrieve a ZIP archive.

The ZIP file contains a Visual Basic Script (VBScript) that masquerades as a PDF document. Attempting to launch it will cause a decoy PDF to be downloaded and displayed to the victim as a distraction mechanism, while it silently downloads a second archive named "Evernote.zip." The archive includes multiple components -

• A complete copy of the legitimate editor Notepad++ version 8.8.3
• A malicious DLL plugin ("NppExport.dll")
• A password-protected archive ("updater.rar")
• Legitimate WinRAR executable ("winrar.exe")

The primary goal of the VBScript is to extract the contents of the archive and launch Notepad++, which, in turn, loads "NppExport.dll." Codenamed LUNCHPOKE, the DLL is designed to unpack the RAR archive, which contains "RemoteLibUpdater.exe" and "InitTest.dll," to a specific directory, set up persistence by means of a scheduled task to run "RemoteLibUpdater.exe" every three minutes.

The "RemoteLibUpdater.exe" binary is BURNYBEAR, which serves as a loader for "InitTest.dll," a modified version of MATCHBOIL, a C#-based loader capable of delivering secondary payloads. The new version has been codenamed MATCHBOIL.V2.

"At the same time, if 'RemoteLibUpdater.exe' is launched incorrectly, namely without specifying arguments, BURNYBEAR instead activates logic designed to exhaust computer resources (RAM and processor)," CERT-UA said.

CERT-UA is recommending that organizations update their WinRAR, 7-Zip, and Notepad++ software to the latest versions to prevent threat actors from exploiting any known vulnerabilities to facilitate follow-on attacks.

The disclosure comes as the U.S. government highlighted a phishing campaign orchestrated by the Russia-linked threat actor called Laundry Bear (aka CL-STA-1114, TA488, UNK_PitStop, and Void Blizzard) targeting Zimbra mail servers belonging to Western government and commercial organizations since at least July 2025.

The campaign employs a novel "half-click" exploit that abuses CVE-2025-66376 to deliver malicious JavaScript dubbed ZimReaper capable of harvesting email communications and other sensitive data.

"Unlike traditional phishing campaigns that persuade a user into taking an action, such as clicking a link or opening a file, Laundry Bear's latest campaign leverages a view-based exploit that only requires a user to view a malicious email within a vulnerable version of the webmail service," the U.S. government said.

"The covert and persistent nature of this activity, along with the absence of any known financial extortion, almost certainly indicates this group's involvement in espionage activities with Russian government backing. Additionally, extensive Ukrainian targeting, prior to use against U.S. and other NATO allies, outlines an increasing trend within Russian cyber threat groups to target Ukrainian users first-both as a priority target and as a test bench for malicious cyber techniques before broader global deployment."

The disclosure also follows a report from Proofpoint about Russian threat actor's continued webmail targeting using half-click cross-site scripting (XSS) exploits to siphon valuable data as part of a campaign referred to as Operation RoundPress. The email security company is tracking the activity as TA458.

Since originally exposed by ESET in May 2025, the campaign has expanded in scope to target Kerio Webmail and SOGo Webmail, alongside Zimbra, mDaemon, and Roundcube. In March 2026, the hacking group is said to have exploited zero-day vulnerabilities in Kerio and the SOGo webmail platform (CVE-2026-8496). It was subsequently patched in version 5.12.8. In the case of Kerio, no CVE was issued as the webmail product was old and outdated.

It's worth noting that the campaign is different from Operation Roundish, which was disclosed by Hunt.io back in March and uses longstanding infrastructure that CERT-UA attributed to APT28 in 2024.

"Since at least July 2025, TA458 began removing stealing components, and swapping in interactive backdoor mechanisms to its Roundcube variant of SpyPress, to enable long-term access to the instance," Proofpoint researchers said. "SpyPress uses a second Roundcube exploit (CVE-2025-49113) that abuses Roundcube's file upload handler to trigger unsafe PHP deserialization."

The end goal is to trigger arbitrary code execution and install multiple backdoor or persistence mechanisms so as to ensure continued access in the face of disruption. TA458 has been described as likely a Russian military intelligence operation without any overlaps with APT28 (aka TA422).

"TA458 primarily targets Ukrainian government and Eastern European military and government entities across Albania, Greece, Moldova, and Türkiye, with occasional targeting of chemical, telecommunications, and technology firms," Proofpoint said. "TA458 continues to use SpyPress - an obfuscated JavaScript-based malware seen in Operation RoundPress - which the adversary modifies based on the targeted mail server."

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

Mount Here, Read There: Twin Path Traversal CVEs in Kubernetes Storage

filepath.Join was never designed to be a security boundary. We found two CSI drivers that shipped on the assumption it was, and the result was cross-tenant data access with optional node destruction, using nothing more than a valid Kubernetes manifest. The vulnerable drivers are the Kubernetes CSI Driver for NFS (csi-driver-nfs) and the Kubernetes CSI Driver for SMB (csi-driver-smb), both maintained by the upstream kubernetes-csi organization. An attacker who can create a PersistentVolume can craft a volume identifier that escapes the subdirectory boundary and reaches another tenant’s data on the shared export.

The impact varies by deployment. In the default configuration, an attacker can read, modify, and delete files belonging to other tenants sharing the same export. In production deployments where the CSI controller is configured with broader hostPath mounts (a common pattern for log collection and operational tooling), the same primitive enables arbitrary directory deletion on the Kubernetes worker node, including paths like /var/lib/kubelet, /etc/kubernetes, and /etc/cni. Remove those and the node is dead.

The Kubernetes Security Response Committee published advisories and assigned CVE-2026-3864 to the NFS driver issue and CVE-2026-3865 to the SMB driver issue.Fixes shipped in csi-driver-nfs v4.13.1 and csi-driver-smb v1.20.1. We reported both vulnerabilities in January 2026 and worked with the maintainers through coordinated disclosure.

Kubernetes Storage Concepts

First, some background on how Kubernetes does storage. This section covers the four building blocks an attacker manipulates in this attack chain.

Container Storage Interface

Kubernetes does not implement storage directly. It delegates that responsibility to the Container Storage Interface, a gRPC contract between the Kubernetes kubelet and a vendor-supplied driver.

Figure 1. The CSI specification sits between Kubernetes and the underlying storage drivers, with each layer owned by a different party.

When a workload requests storage, Kubernetes issues calls such as CreateVolume, NodePublishVolume, and DeleteVolume to the CSI driver, which in turn provisions, mounts, and tears down the actual storage on the underlying system, whether that system is an NFS export, an SMB share, an Amazon Elastic File System filesystem, a block device, or anything else.

Figure 2. The CSI driver mediates between Kubernetes pods and the underlying storage backend.

The CSI specification is intentionally minimal about what drivers must validate. It specifies the gRPC interface and the lifecycle but leaves input validation, authorization, and isolation to each driver implementation. This design decision is the underlying reason the same class of bug recurs across multiple drivers.

PersistentVolume and the volumeHandle

A PersistentVolume is a Kubernetes API object that represents a unit of storage in the cluster. When a PersistentVolume references a CSI driver, it carries a string field called volumeHandle. This field is opaque to Kubernetes: the API server stores it but does not parse, validate, or interpret it. The driver alone is responsible for understanding the format of volumeHandle and using its contents safely.

Each driver defines its own format. The NFS CSI driver parses volumeHandle as {server}#{share}#{subDir}#{uuid}#{onDelete}

The SMB CSI driver parses it as //{server}/{share}#{subDir}#{uuid}#{secretNs}#{secretName}#{pvName}

In both drivers, the subDir component is the security boundary. It’s also the one that breaks.

Subdirectory-Based Multi-Tenancy

Some clusters share a single NFS or SMB export across tenants by giving each one a dedicated subdirectory. Both drivers’ deployment guides document this pattern. It’s common wherever provisioning a separate export per tenant is expensive: on-premises NAS appliances, cloud file services that bill per share, shared storage systems that are slow to reconfigure.

In this model, the security boundary between tenants is the subdirectory path. Team A’s PersistentVolume is scoped to subDir: team-a. Team B’s is scoped to subDir: team-b. The driver mounts each tenant into their own directory, and the assumption is that neither tenant can reach the other’s data, even though both share the same underlying export.

Role-Based Access Control and PersistentVolume Authorization

Kubernetes uses RBAC to control who does what. Creating a PersistentVolume (PV) is cluster-scoped, and the documented threat model assumes only cluster admins hold this permission. In practice? It’s everywhere. CI/CD pipelines, ArgoCD, Helm automation, operator controllers. They all need persistentvolumes:create to provision storage for applications. Compromise any of those service accounts and you’re in.

That gap between the documented threat model and how clusters actually run is what makes these bugs practically exploitable.

Trusting the Wrong Function

There’s a misconception in the Go ecosystem that keeps burning people: the idea that filepath.Join prevents path traversal. It doesn’t. filepath.Join is a normalizer. It collapses ., .., and redundant separators into a canonical form. It has no concept of “base directory” or “boundary” and can’t tell whether the result landed somewhere the caller never intended.

Try it yourself: give it “/var/lib/csi/team-a” and “../../../etc/passwd“. You get /etc/passwd. Clean path, totally canonical, pointing straight at a location outside the intended base directory. The function did what it was designed to do. It just didn’t do what the caller assumed. A safe-path function would take the base directory as a parameter and refuse to return anything outside it. A safe option exists in Go, but these drivers never adopted it. The community workaround is filepath-securejoin, which does the symlink-aware join and returns an error instead of letting you escape.

Both vulnerable drivers shipped this misconception. They pulled the subdirectory string out of volumeHandle, passed it through filepath.Join, and trusted the result.

CVE-2026-3864 — Kubernetes CSI Driver for NFS

We found the bug in the controller-server implementation of csi-driver-nfs. The driver parsed the volume identifier into its parts, pulled out the subdirectory string, and built an internal mount path by joining that subdirectory to a per-volume working directory.

Figure 3 (NFS code): The NFS CSI driver extracts subDir from the volume ID and passes it to filepath.Join without validation, then calls os.RemoveAll on the result.

Three things matter here. No validation on subDir between extraction and use. filepath.Join won’t refuse a result that escapes its working directory. And the resulting path gets handed to os.RemoveAll. That last part is key: this isn’t just a read primitive. It deletes.

The exploit is a one-line modification to a PersistentVolume manifest:

Figure 4 (Exploit YAML): A malicious PersistentVolume manifest. The subDir component team-a/../../team-b escapes the legitimate tenant directory.

When a pod mounts this PersistentVolume, the path that actually gets bound is 10.0.0.50:/exports/team-b. Not team-a. The attacker’s pod now sees team B’s files, can read them, modify them, and (if the reclaim policy is set to delete) trigger their recursive removal when the PersistentVolumeClaim (PVC) is deleted.

In production deployments where the CSI controller has been granted broader hostPath mounts of the worker node (common in clusters that integrate the controller with kubelet log collection or other operational tooling), the traversal can reach beyond the export and into the host filesystem itself. A volumeHandle containing the subdirectory string ../../../../../../var/lib/kubelet provides the controller with a recursive-delete primitive against the kubelet’s own state directory, rendering the node permanently non-functional.

Two things make this harder to fix than it looks. First, NFS servers from major vendors expose hidden .snapshot directories. Point-in-time copies, invisible to ls but reachable by path. A subdirectory of team-a/../.snapshot mounts the snapshot tree and surfaces data that admins thought was gone. Second, even after the driver patch, an attacker with write access inside their own tenant directory can plant symlinks that cross the tenant boundary through the NFS data plane. The control-plane fix is necessary but not sufficient. Data-plane mitigations require mounting with nosymfollow (Linux 5.10+) or enabling subtree_check on the export.

CVE-2026-3865 — Kubernetes CSI Driver for SMB

The SMB CSI driver is maintained by the same upstream organization and follows the same architectural shape. It contained the same vulnerability:

Figure 5 (SMB code): The SMB CSI driver follows the same pattern as NFS: subDir extracted at index 1, joined without validation.

The exploit is structurally identical. The volumeHandle for SMB is //{server}/{share}#{subDir}#…, and a payload of //smb.internal/shared#dept-engineering/../../dept-finance#uuid causes the same escape into a sibling tenant’s directory.

Honestly, the recurrence is the more interesting finding than either CVE on its own. Same org, same misconception, years apart. When a standard-library function looks like a sanitizer but only normalizes, people keep reaching for it. Every codebase that did has to be audited now. Every callsite patched.

One note for other researchers on this bug class. The Kubernetes triage team initially could not reproduce the SMB report because their reproduction harness ran the proof-of-concept against an SMB-server pod inside the cluster, and SMB exports are sandboxed by the underlying storage system. The vulnerability is in the CSI controller’s internal file operations on its working-mount directory, not in protocol traffic to the SMB server. Researchers reporting CSI path traversal should lead with a host-mount reproducer and only attach protocol-level demonstrations as supplementary material. This pattern recurs because the server-side of NFS and SMB is usually well-defended by the storage vendor, while the driver-side code path between the Kubernetes API and the host filesystem is where the bug actually lives.

Multi-Tenant Storage as Attack Surface

These two CVEs are instances of something bigger. Kubernetes storage drivers sit on a trust boundary that the CSI spec doesn’t enforce. Nobody validates volumeHandle. The kubelet assumes the driver does it. The driver assumes whoever wrote the PV knew what they were doing. That was probably a CI/CD pipeline that assumed the API server would catch anything dangerous. The API server treats the field as opaque. So nobody checks. The string just flows through.

This isn’t just NFS and SMB. There are dozens of CSI drivers in production, each with its own volumeHandle format, each parsing user input with varying degrees of care, each forwarding strings into mount commands and host file operations. We haven’t audited all of them. But the pattern is there.

The bigger question is where input validation should live. The driver? Implemented inconsistently. The API server? Treats volumeHandle as opaque. An admission controller? Only works if someone remembers to deploy one. The CSI spec? Mandates none of the above. Until one of these layers owns the boundary, this bug class will keep producing CVEs.

The Full Chain — From PersistentVolume-Create to Cross-Tenant Compromise

The full attack chain:

Prerequisite: the attacker holds persistentvolumes:create (typically a CI/CD pipeline, GitOps controller, or operator service account) and identifies the cluster as using the NFS or SMB CSI driver with shared multi-tenant exports.

1. Craft a PersistentVolume whose volumeHandle contains a traversal payload in the subdirectory component.
2. Create a PersistentVolumeClaim bound to the malicious PV. The scheduler treats it as normal.
3. Schedule a pod mounting the claim. The CSI driver parses the malicious volumeHandle, joins the traversal string against its working directory, and mounts the victim tenant’s directory.
4. Read, modify, or delete the victim’s files. With onDelete=delete, deleting the PVC triggers recursive deletion.
5. (Optional) If the CSI controller has broader hostPath mounts, traverse into the host filesystem and destroy node-critical paths like /var/lib/kubelet.

The entire chain executes against the Kubernetes API server using only the persistentvolumes:create permission. No exploit code. Just YAML.

Fixes and Mitigations

The Kubernetes Security Response Committee released fixes for both vulnerabilities. The NFS driver fix shipped in csi-driver-nfs v4.13.1 and rejects subdirectory strings containing .. components outright. The SMB driver fix shipped in csi-driver-smb v1.20.1 and applies the same validation pattern.

Beyond the upstream patches, cluster operators have several additional mitigations that should be applied as defense-in-depth:

• Restrict persistentvolumes:create authorization. Audit which service accounts in the cluster currently hold this permission. CI/CD pipelines, GitOps controllers, and operator service accounts should be reviewed, and the permission should be scoped down or wrapped behind admission-controller approval for any account that is not strictly an administrative identity.

• Deploy admission-time validation. A ValidatingAdmissionPolicy (in Kubernetes 1.30 and later) or a ValidatingWebhookConfiguration (in earlier versions) can reject any PersistentVolume whose spec.csi.volumeHandle field contains .. or other suspicious patterns. This control survives any future zero-day in the same class. The next CSI driver to ship the same misconception is automatically defended.

• Address the data-plane symlink amplification. The driver patches don’t cover the symlink variant. A tenant with write access to their own directory can still plant a relative symlink that crosses into someone else’s. Mount NFS exports with the nosymfollow option (Linux 5.10 and later) where supported, enable subtree_check on the NFS server export configuration, or audit symlink targets on the storage server.

• Treat the bug class as recurring. The pattern of filepath.Join on attacker-controlled input is present in many storage drivers, container network interface plugins, operators, and webhook servers throughout the cloud-native ecosystem. Any Go code that takes an untrusted string and joins it to a path should be audited and converted to use either strict validation or the filepath-securejoin library.

Conclusion

Path traversal is one of the oldest bug classes in computing. The fact that it keeps showing up in 2026, in actively maintained infrastructure running multi-tenant production clusters, says something. The safe path-handling already exists, but these drivers kept trusting filepath.Join instead of using it.

The CSI specification doesn’t mandate input validation on volume identifiers. Individual drivers implement it inconsistently, or not at all. The protocols underneath (NFS and SMB here, but the pattern generalizes) were designed for trusted networks decades before multi-tenant container orchestration existed. Until one of these layers takes ownership of the boundary, the same misunderstanding will keep shipping.

For defenders: patch the drivers, restrict who can create PersistentVolumes, deploy admission-time validation, and treat any .. sequence in a volumeHandle as a credible alert. Validators reject. Normalizers don’t. Know which one you’re using.

Disclosure Timeline

• January 15, 2026 — Vulnerabilities identified during CSI driver code review by SentinelOne Researchers.
• January 16, 2026 — NFS and SMB reports submitted to the Kubernetes SecurityResponse Committee.
• January 19, 2026 — NFS report triaged after proof-of-concept harness was clarified.
• January 19, 2026 — SMB report triaged.
• March 9, 2026 — NFS driver fix released in csi-driver-nfs v4.13.1.
• March 17, 2026 — Public disclosure of the NFS finding; CVE-2026-3864 assigned.
• March 21, 2026 — SMB driver fix released in csi-driver-smb v1.20.1.
• April 11, 2026 — Public disclosure of the SMB finding; CVE-2026-3865 assigned.

Additional Resources

• CVE-2026-3864 — Kubernetes NFS CSI Driver path traversal (Kubernetes Security Advisory)
• CVE-2026-3865 — Kubernetes SMB CSI Driver path traversal (Kubernetes Security Advisory)
• filepath-securejoin — Secure path-joining library for Go

from SentinelOne https://ift.tt/rLhtcV2
via IFTTT