With great AI power comes the need for zero trust responsibility

The enterprise security landscape is undergoing a profound shift driven by a new dual-use AI breakthrough. With the rollout of Anthropic’s Claude Mythos Preview under the gated defense framework of Project Glasswing, the cybersecurity community has witnessed a massive leap in capability. Mythos has proven to be an extraordinary asset for defensive engineering, autonomously identifying over 10,000 critical software vulnerabilities across the world’s most systemically important infrastructure in a matter of weeks. Launch partners like Cloudflare and Mozilla reported bug-finding efficiencies scaling by more than 10 times compared to previous cycles.

However, the very properties that make Claude Mythos a defensive triumph — autonomous reasoning, multi-step exploit construction, and deep context analysis — also represent the next generation of risk if such frontier capabilities are used by unauthorized or malicious actors.

An autonomous exploit operates at machine speed:

T+0 minutes:  AI agent discovers an AWS access key in a public repository

T+5 minutes:  Validates credential, enumerates S3 buckets, identifies overly permissive IAM policies

T+12 minutes:  Pivots to EC2 metadata service, extracts broader credentials

T+18 minutes:  Locates database credentials, establishes persistence, begins exfiltration

Your security team's response time? Still awaiting human triage.

This isn't theoretical, it's the new baseline threat model. When an adversary can analyze codebases and chain zero day vulnerabilities at machine velocity, reactive security models break down.

In light of these new AI superpowers, it’s not surprising I get a lot of questions about how organizations can protect themselves with existing tools and capabilities. Hint: The answer to this question does not require inventing an entirely new cryptographic paradigm or throwing out your current security stack of “mere mortal” capabilities. What’s missing is the rigorous, automated enforcement of current security best practices. The foundational principles of zero trust, identity-based access, and continuous secret hygiene can scale to neutralize autonomous threat vectors.

Mythos’ superpowers: Scale, speed, and context

To secure an enterprise against autonomous security analysis tools, we need to map their tactical behavior. When used in an offensive or unauthorized capacity, models of this kind do not rely on some new superpower; they exploit traditional, human-engineered security oversights at an unprecedented scale.

Autonomous chain construction: Standard fuzzers identify isolated bugs. An advanced model like Mythos reasons across a broader code architecture, discovering how a minor memory corruption flaw can be chained with a local sandbox escape to engineer a functional remote code execution (RCE) pathway.

Context-driven lateral movement: Upon gaining initial access to an environment, an autonomous agent executes automated post-exploitation playbooks. It parses environment variables, local file systems, configuration files, and system memory to harvest credentials.

Compressed exploitation windows: The gap between initial breach, asset discovery, and lateral movement shrinks from days to minutes. Current telemetry indicates that active automated exploit scans now begin within 15 minutes of a vulnerability or credential disclosure online. Human-in-the-loop triage networks cannot manually patch code or rotate credentials fast enough to outpace a machine-driven loop.

The key realization for defenders is that an autonomous agent is ultimately bound by the context it can discover. If you enforce rigorous security hygiene and eliminate static targets, the agent is deprived of actionable data.

Why traditional defenses fail

Traditional security fails against AI exploits for three fundamental reasons:

Human-in-the-loop bottlenecks: Your incident response assumes human decision-making at each stage — triage, correlation, response, validation. Even world-class SOCs take hours. AI exploits complete their mission in minutes.

Static credential architecture: Long-lived credentials in environment variables, configuration files, and container secrets create persistent targets. AI agents don't crack encryption — they compromise systems with legitimate access.

Perimeter-based trust: Once inside your network, AI exploits leverage legitimate service-to-service communication and implicit trust relationships. Your firewall can't distinguish between authorized applications and autonomous agents operating with stolen credentials.

 The key realization for defenders is that an autonomous agent is ultimately bound by the context it can discover. If you enforce rigorous security hygiene and eliminate static targets, the agent is deprived of actionable data. 

The defense framework: Current best practices at machine speed

In light of these new AI capabilities, organizations frequently ask how they can protect themselves with existing tools. The answer doesn't require inventing an entirely new cryptographic paradigm or replacing your current security stack. What's missing is the rigorous, automated enforcement of security best practices. Many organizations have documented policies around least-privilege access and secure secret storage, but they're not being implemented in an automated, scalable way.

The foundational principles of zero trust, identity-based access, and continuous secret hygiene can scale to neutralize autonomous threat vectors — when properly automated.

By pairing IBM Vault Radar with IBM Vault, organizations can harden their infrastructure against AI exploits using the same sound architectural practices that security teams have been championing for years. The critical difference is actually implementing and automating these practices at the speed of autonomous threats.

The defense framework rests on three principles:

Principle 1: Eliminate static targets through continuous secret discovery and remediation

Principle 2: Assume breach, and limit blast radius via identity-based access and dynamic credentials

Principle 3: Automate at machine speed to match the velocity of autonomous exploits

Preemptive hygiene: Starving the context window with Vault Radar

An autonomous model's intelligence is directly tied to the information it consumes. If an agent gains access to internal version control histories containing historical credentials, hardcoded metadata, or clear-text architecture maps, it can map an optimized path for lateral movement. The most effective defense is keeping a pristine, unexposed codebase. Vault Radar automates this best practice at enterprise scale, continuously monitoring changes and updates across your environments to find hidden secrets or sensitive information that might have been accidentally shared.

Eliminating "zombie" secrets

Autonomous systems are highly efficient at digging through entire version control system (VCS) histories to find forgotten credentials buried in legacy commits. Vault Radar automates code hygiene by executing deep historical scans. Crucially, it avoids traditional pitfalls of false-positive alert fatigue by separating dead placeholder strings from active production keys with "activeness" checks and by supporting custom allow lists for known benign tokens. Vault Radar also performs entropy analysis to discover complex keys that can be missed by traditional pattern scanning.

To maintain strict data privacy, Vault Radar uses cryptographic hashing (Argon2id with HMAC) to track discovered secrets without storing them in plain text — ensuring your security tool doesn't become a target itself while providing exact locations for remediation.

IDE-level leak prevention

The legacy workflow of "leak first, rotate later" is entirely unviable against exploits running at machine-speed. Vault Radar implements shifting-left best practices by integrating directly into developer IDEs (such as VS Code) and gating GitHub pull requests. These built-in security capabilities also extend into the developer's IDE through IBM Concert Secure Coder , which leverages Vault Radar to detect and prioritize risks by business impact and generate automatic remediations as code is written, stopping vulnerabilities before they reach production. By blocking unmanaged tokens from ever hitting a remote repository, you eliminate the micro-windows of exposure that automated crawlers rely on.

PII and configuration scrubbing

Beyond cryptographic keys, autonomous agents leverage environmental context — such as exposed personally identifiable information (PII) or internal server names — to frame down-funnel attacks. Vault Radar's multi-layered engine flags exposed PII and configuration leaks, allowing teams to sanitize metadata.

Runtime resilience: Enforcing identity-based zero trust

While preemptive hygiene severely limits an agent's reconnaissance, a true defense-in-depth framework assumes that an application-layer vulnerability will eventually be compromised. When an autonomous exploit successfully establishes a foothold, Vault uses established zero trust practices to minimize the blast radius.

Dynamic secrets and just-in-time (JIT) credentialing

The most definitive method to neutralize an automated credential hunter is to ensure there are no static credentials on the file system to steal. Vault's dynamic secret engines generate scoped, ephemeral credentials across your entire infrastructure — AWS IAM, Azure Service Principals, GCP service accounts, databases (PostgreSQL, MongoDB, Oracle), PKI certificates, and SSH keys. No matter where an autonomous agent attempts to pivot, it encounters the same barrier: short-lived, context-aware credentials that expire before exploitation completes.

If an unauthorized agent triggers an RCE on a web server, it will find zero static database passwords in .env or YAML configurations. By the time the model processes the local file system and prepares its secondary lateral pivot, the temporary credential used by the legitimate application pool has likely expired or can be programmatically rotated.

Cryptographic identity over network trust

Autonomous agents are experts at navigating network topology, seeking out unauthenticated lateral routes between subnets or permissive internal security groups. Vault neutralizes this advantage by shifting the security boundary entirely from network topology to cryptographic identity.

Applications must authenticate to Vault using verifiable tokens (such as OIDC, JWT, AWS IAM roles, or Kubernetes service accounts). Even if an agent maps an open network route to a sensitive internal database API, it cannot extract operational secrets from Vault without presenting a valid, signed identity token. Vault administrators can also enforce strict behavioral isolation policies, locking secret access to explicit CIDR blocks or tight temporal windows, making it impossible for external agents to reuse stolen machine contexts out-of-bounds.

Automated lifecycle management

Defending at machine velocity requires automated orchestration. Vault provides the mechanism to execute response playbooks programmatically:

Credential rotation: For legacy infrastructure where using true dynamic, short-lived credentials is not feasible, mitigating risk requires high-frequency rotation. Automated credential rotation in Vault Enterprise enables this process. This capability handles complex lifecycles (such as LDAP static roles) with centralized scheduling, intelligent retries with exponential backoff, and administrative pause/resume controls. By moving traditional, static accounts to automated, high-frequency rotation schedules, you drastically narrow the viability window of any intercepted credential.

Rapid global revocation: If an intrusion detection system (IDS) flags an active compromise on a workload, a single automated API call to Vault can immediately revoke every active lease tied to that workload's identity, instantly dropping the attacker’s authorization across multi-cloud environments

Secret remediation: Vault Radar provides a closed-loop approach to quickly remediate unsecure secrets when they are discovered. At discovery, teams get real-time alerts with contextual guidance and the ability to import discovered secrets directly into Vault for secure management, enabling actions like rotation and revocation to minimize risks associated with credential exposure.

Conclusion: The security bar has risen, but security best practices still apply

The emergence of frontier models like Claude Mythos marks an inflection point: Software analysis velocity has accelerated exponentially, but the defense blueprint remains unchanged. What's different is the margin for error. Quarterly rotation cycles, manual remediation, and human-in-the-loop responses are no longer viable.

The solution doesn't require new security paradigms — it requires operationalizing and automating principles security experts have championed for years. Organizations must operate in continuous discovery and response mode, reducing exploitability through elimination of static secrets, limiting blast radius via identity-based access, and integrating security into every decision.

By deploying  Vault Radar for continuous monitoring and Vault for dynamic, identity-based authorization, you create an environment devoid of the static targets autonomous exploits require. The foundational security practices you implement today ensure your architecture remains resilient, regardless of how rapidly threats evolve.

Ready to bring machine-speed security to your infrastructure?

Explore the Vault Radar Quickstart tutorial to start scanning your repositories, auditing local environments, and neutralizing "zombie" credentials before they can be exploited. to start scanning your repositories, auditing local environments, and neutralizing "zombie" credentials before they can be exploited.

To eliminate static targets at runtime, check out the Vault Documentation to learn more about setting up dynamic, just-in-time secrets engines and configuring automated credential rotations. 

from HashiCorp Blog https://ift.tt/MvItk0H
via IFTTT

Stateful vs stateless applications: differences and use cases

A development team scales its web application from one server to five to handle peak traffic. Within minutes, users report random logouts and lost shopping carts. The load balancer is routing requests across all instances, but session data exists only in the memory of the server that originally handled each user connection. 

This is a common failure mode in distributed applications. Once requests start moving between instances, anything stored locally becomes a dependency. User sessions, shopping carts, workflow progress, cached application data – all of it needs to be available regardless of which server processes the next request. 

The distinction between stateful and stateless design affects far more than session management. It shapes how applications scale, recover from failures, move between infrastructure nodes, and operate in Kubernetes environments. Where state lives and how it’s managed is a core architectural decision for any distributed service. 

Here’s how each model works, where each fits, and what the operational tradeoffs actually look like in production. 

What is a stateless application? 

A stateless application doesn’t retain client-specific information between requests. Any running instance can process any request because the required context is either included in the request itself or pulled from external services. If an instance crashes and a replacement starts, no session data is lost because nothing was stored locally. 

Figure 1: Local session memory fails under a load balancer. Externalized state does not

 

Common stateless workloads include REST APIs, static website delivery, frontend rendering containers, image and video processing workers that write results to object storage, and authentication services using self-contained JWTs (tokens that carry all the information needed to validate a request, so no server-side lookup is required). A web application that stores session data in Redis or a relational database rather than local memory is also effectively stateless at the application tier – any instance can serve any request.

Because requests are independent, adding or removing instances doesn’t require migrating user sessions or application data. You spin up another replica, point the load balancer at it, and it starts handling traffic.

One clarification. Stateless doesn’t mean data-less. A stateless API may query PostgreSQL, publish events to Kafka, and store uploaded files to S3. The application itself just doesn’t hold onto that information between requests.

What is a stateful application?

A stateful application retains information that affects future requests, transactions, or operations – persistent data, session context, replication metadata, application state on disk or in memory. Without that state, the application can’t continue operating correctly. Losing it often means losing data, transaction history, or consistency guarantees.

Databases are the obvious example. A PostgreSQL instance stores data files on disk and maintains active connection state. Starting a new instance without access to the original storage is effectively a different database. Message platforms like Kafka and RabbitMQ maintain queue state, consumer offsets, and replication metadata. Search platforms like Elasticsearch store indexes that must survive restarts and workload migrations.

Other examples include file servers, Redis deployments operating as primary data stores, multiplayer gaming platforms tracking live player sessions, and legacy enterprise applications that store session data locally.

Unlike a stateless container that can usually be replaced immediately, stateful services often need storage reattachment, integrity validation, and sometimes a recovery sequence before they can safely accept traffic.

Kubernetes formalizes this distinction through separate workload controllers. Deployments are designed for stateless workloads where pods are interchangeable. StatefulSets support applications that need persistent storage, stable network identities, and ordered startup and shutdown behavior.

How they differ

The simplest way to think about it: stateless applications treat each request independently, while stateful applications depend on information that must persist beyond the lifetime of a single request or process.

An API gateway validating a JWT can process requests on any available instance because it stores no client-specific information locally. A database, message broker, or gaming server can’t. Their operation depends on information accumulated over time and preserved across restarts, failures, and infrastructure changes.

That difference shows up in daily operations. Stateless services are easier to scale, replace, and recover because instances are interchangeable. Stateful workloads bring additional requirements around storage, replication, consistency, backup, and recovery.

Factor	Stateless applications	Stateful applications
Request handling	Each request is self-contained	Requests may depend on previously stored state
Scaling	Horizontal scaling is straightforward	Scaling requires state replication, partitioning, or coordination
Load balancing	Any instance can serve any request	May require session affinity or access to shared state
Failure recovery	Failed instances can be replaced immediately	Recovery may require state restoration, validation, or synchronization
Storage	State is stored in external services	Persistent storage is integral to the workload
Kubernetes controller	Deployment	StatefulSet
Network identity	Instances are interchangeable	Stable network identity may be required
Examples	APIs, web frontends, processing workers	Databases, message queues, cache clusters, file servers

The Twelve-Factor App methodology captures this same principle: keep application processes stateless and share-nothing wherever practical. Data that must survive application restarts belongs in backing services – databases, caches, object storage, messaging systems. 

Real-world examples 

Most production environments contain both models. 

An e-commerce platform serves product information through stateless APIs while storing shopping cart data, inventory records, and order history in stateful backend systems. The API tier scales freely, but the underlying data must stay consistent. 

Healthcare systems follow the same split. An appointment scheduling API that validates tokens and queries a calendar service can run statelessly across any number of replicas. The patient record database (Epic, Cerner, and similar EHR systems) is stateful: it needs transactional storage, consistent backups, and point-in-time recovery. A write that gets lost isn’t just a data problem – it’s a patient safety problem. 

Payment infrastructure shows the same pattern. A payment API can be exposed through stateless service endpoints, while the transaction database behind it is stateful – recording every transaction, refund, and state change as permanent history. 

Video streaming services often run metadata and recommendation APIs as stateless workloads behind load balancers. User watch history, playback position, subscription information, and billing records remain stateful and must survive infrastructure failures and regional failovers. 

Kubernetes environments combine both approaches regularly. An NGINX frontend may run as a Deployment with multiple interchangeable replicas. PostgreSQL and Kafka typically run as StatefulSets because they depend on persistent volumes, stable identities, and controlled recovery procedures. 

Scaling, recovery, and Kubernetes 

Scaling stateless services? Add instances behind a load balancer. AWS Auto Scaling Groups, Kubernetes HPA, and Azure Container Apps all work on the same assumption: no instance owns session data, so new replicas start serving requests immediately. 

Stateful services are harder to scale because the data layer becomes part of the decision. Adding a PostgreSQL read replica is routine. Expanding a Galera write cluster or rebalancing a Kafka deployment requires considerably more coordination – replication lag, quorum requirements, consistency guarantees, and storage performance all factor in. 

Failure recovery follows the same pattern. Replacing a failed stateless container often means starting a replacement and redirecting traffic. Recovering a failed database node may involve storage validation, write-ahead log (WAL) replay, cluster reformation, and consistency checks before it can safely rejoin production. 

In Kubernetes, Deployments manage stateless workloads. Pods are interchangeable: if one restarts on another node, Kubernetes launches the same image with the same configuration and resumes serving traffic. Rolling updates, rollbacks, and horizontal scaling work cleanly because pod identity doesn’t matter. 

StatefulSets manage stateful workloads. Each pod gets a stable hostname (postgres-0, postgres-1) and typically its own PersistentVolumeClaim (a request for storage that Kubernetes binds to an actual volume). If postgres-0 is rescheduled to a different node, Kubernetes reattaches the original volume and preserves its data. Startup and shutdown follow an ordered sequence, which simplifies recovery and cluster coordination for databases, message brokers, and other distributed systems. (This ordered shutdown isn’t just convention – it protects quorum in clustered systems like etcd. That’s a deep dive for another time.) 

PersistentVolumes and PersistentVolumeClaims provide the storage layer many StatefulSets depend on. Without persistent storage, a database pod recreated after a node failure may start with an empty data directory, resulting in data loss or cluster reinitialization. 

ConfigMaps and Secrets hold configuration values, not transactional data. Teams that treat them as a substitute for application state usually discover the difference during an incident. I’ve seen this happen. It wasn’t pretty – the team spent two hours debugging what turned out to be a missing environment variable that had been stored in a ConfigMap they assumed was persisted, but the volume mount was misconfigured and the pod had been silently falling back to defaults for weeks. 

Can a stateful application become stateless? 

Many applications that appear stateful at the code level can be refactored to externalize their state. The compute layer behaves statelessly while all persistence moves to dedicated services. 

The most common transformations: 

• Move in-process session storage from application memory to a shared Redis cluster 

• Replace sticky sessions with token-based authentication so any instance can validate any request 

• Move uploaded files from container-local disk to object storage 

• Write job progress to a database instead of holding it in process memory 

 

AWS documents this pattern in its guidance on converting stateful architectures to stateless designs: moving session management to DynamoDB or ElastiCache, and user files to S3, removes the dependencies that make horizontal scaling complex and failover painful. 

The compute tier gets the scaling and recovery properties of a stateless service. The stateful systems still exist – they’re just no longer inside the application process. Those data services now need dedicated storage planning, replication, backup schedules, and tested failover. 

Storage and infrastructure requirements 

Stateless compute services need reliable networking and a stable path to their backing services. Storage requirements are minimal: a container image, possibly a small ephemeral volume for temporary processing, and connection strings to external services. 

Stateful services have a different set of requirements. They need persistent storage that survives pod restarts and node failures. Performance matched to the workload (NVMe or low-latency flash for transactional databases, high-capacity storage for archives and cold data). Replication so a single drive or node failure doesn’t cause data loss. Snapshots and backups for point-in-time recovery. HA clustering so a node failure doesn’t take the service offline. 

For virtualized databases, file services, and application clusters, shared storage is often the foundation of availability. Software-defined storage handles this by mirroring local drives between cluster nodes and presenting a shared fault-tolerant volume to the hypervisor, removing the external SAN from the HA path. VMware vSAN takes this approach on vSphere clusters. StarWind Virtual SAN covers the same pattern for both Hyper-V and VMware environments and is common in two-node configurations where adding a physical witness server would increase hardware cost without proportional benefit. 

Disaster recovery also differs between the two models. Restoring a stateless service is often as simple as redeploying its configuration and application image. Restoring a stateful service requires verified backups, tested recovery procedures, and in many cases replicated data at a secondary location to meet recovery objectives. 

How to choose between stateful and stateless 

A few questions usually determine the answer: 

• Can any instance process any request without prior context? 

• Does the application need to retain session information between requests? 

• What happens if an instance restarts? 

• Where is persistent data stored? 

• Does the workload require a stable identity? 

• Does startup order matter?

These questions are useful, but they’re abstract. Walking through a concrete example makes the decision clearer. 

Consider a notification delivery service. It reads messages from a queue and sends emails, SMS, or push notifications to users. On the surface, it’s stateless: any instance can pick up any message and deliver it. 

But what about retries? If delivery fails, the service needs to know it failed, schedule a retry, and track how many attempts have been made. That’s state. What about rate limiting? If you’re sending to a carrier that throttles at 100 messages per second per sender, the service needs to track the current send rate. More state. What about delivery receipts? If downstream providers send webhook confirmations that a message was delivered, those receipts need to be matched to the original message. State again. 

You can solve each of these two ways. Keep the retry counters, rate limits, and delivery receipts in the application process (stateful) or externalize them to Redis, a database, or a message queue with visibility timeouts (stateless compute backed by stateful services). The first approach is simpler to build. The second is simpler to operate at scale, because you can add more compute instances without worrying about which instance owns which piece of state. 

In most architectures, the preferred approach is to keep the application tier stateless and move persistence into dedicated services designed for storage, replication, backup, and recovery. 

Common mistakes 

Storing sessions only in local process memory is the most common early mistake. When the process restarts or a load balancer routes to a different instance, the session is gone. Store session state in a shared service like Redis, Memcached, or a database that all application instances can reach. 

Writing uploaded files to container-local disk causes a similar class of failure. Container restarts and pod rescheduling destroy ephemeral storage. User-generated content needs to go to object storage on the first request, not after the first incident. 

Running databases in Kubernetes without persistent volumes is specific to container environments but remains common. If persistent storage is missing or incorrectly configured, a recreated database pod may start with an empty data directory or fail to recover correctly. Test pod failure and PVC reattachment before you go to production. Don’t skip it. 

Sticky sessions are a short-term workaround that teams often mistake for a scaling strategy. They work until the instance holding those sessions fails, at which point every affected user loses their state simultaneously. Externalizing session state removes that dependency. 

Skipping backup and restore testing for stateful services creates a false sense of security. Backups that haven’t been tested as restores are an unknown quantity. The gap shows up during an actual incident, when you discover the backup was corrupted three weeks ago and nobody noticed. 

Treating cache as the source of truth is a design error with a predictable failure mode. In-memory caches like Redis are fast but volatile in default configurations. Any data that can’t be lost needs a durable store behind it, with the cache serving as acceleration, not storage. 

Confusing stateless applications with stateless systems is another common mistake. A stateless API may still depend on databases, message brokers, caches, and object storage that hold critical application state. Making the application tier stateless simplifies operations, but the underlying state still needs protection, replication, backup, and recovery planning. 

Conclusion 

Stateless application tiers scale and recover easily because no instance owns data – replace a pod, and nothing is lost. Stateful services are unavoidable wherever data, sessions, ordering, or persistence matter, and they require dedicated storage, replication, backup, and tested failover. 

Most production systems combine both. Stateless tiers handle user requests and business logic. Stateful services manage databases, message queues, caches, and persistent storage. If you’re designing a new service, default to stateless compute with externalized state and invest your operational complexity budget in the data layer where it belongs. 

FAQ 

What is the difference between stateful and stateless applications? 

A stateless application processes each request independently and does not retain client-specific state between requests. A stateful application depends on stored data, session context, or persistent identity to function correctly across requests or restarts. 

Is REST stateless? 

The REST architectural style defines statelessness as a constraint: each request must carry all the information needed to process it, and the server stores no session state between requests. Many APIs described as REST do use server-side sessions, which technically violates this constraint. 

Is a database stateful or stateless? 

Databases are stateful. They accumulate and persist data, maintain transaction and connection state, and require persistent storage to function. This is the fundamental reason databases need different operational treatment than application containers. 

What is the difference between Deployment and StatefulSet? 

A Deployment manages interchangeable pods that can be replaced and rescheduled freely. A StatefulSet assigns each pod a stable identity and its own persistent storage, and enforces ordered startup and shutdown sequences. 

Can a stateful app be converted to stateless? 

The application tier of many stateful applications can be made stateless by moving session data, file storage, and persistence to external services. The overall system remains stateful because the data still exists; it is simply managed outside the application process. 

Is Redis stateful or stateless? 

Redis is generally considered stateful because it stores data that applications depend on. When used for caching, data loss may be acceptable. When used for sessions, queues, or as a primary data store, Redis becomes a critical stateful component that requires persistence, replication, and backup planning. 

Which is better: stateful or stateless? 

Neither is universally better. Stateless application tiers are easier to scale, replace, and operate. Stateful data services are unavoidable for any application that needs to retain information. The best architectures use stateless compute and treat their stateful data services as the critical infrastructure they are. 

 

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

Centralized computing in a hybrid world

For years, the infrastructure conversation has been framed as a binary choice: centralized vs. distributed, with the pendulum swinging back and forth like clockwork. But that framing no longer reflects how work actually happens or how modern platforms are being built.

Today’s reality is more nuanced. Enterprises are operating in a world of hybrid infrastructure, distributed users, and increasingly low‑cost, nearly disposable endpoints. The question is not where computing happens. It’s how work is secured, governed, and delivered across any environment.

This is where centralized infrastructure evolves from an architectural design into something more powerful: a platform to secure the work.

Centralization isn’t about location anymore

Centralized used to imply a single data center and a monolithic stack. That definition is outdated. Modern centralized infrastructure is defined by central control, not geography:

• Workloads may run on‑prem, in public cloud, or across multiple clouds.
• Users may connect from corporate laptops, thin clients, personal devices, or mobile workstations.
• Data may span SaaS, legacy apps, and cloud‑native services.

What’s centralized is the policy, security, identity, experience, and increasingly, a secure enterprise browser—not the hardware.

This shift matters because complexity has moved to the edge. Devices are more diverse, networks more variable, and security threats more persistent. As more work shifts to SaaS and web-based applications, the browser has become the new operating system for work. Without a secure, centrally managed enterprise browser, organizations are effectively pushing their most sensitive workflows and their data back out to unmanaged endpoints. Trying to manage all of that at scale via multiple apps like MDM/UDM, EDR, DLP, and SSE is no longer sustainable.

Distributed devices, centralized control

One of the most important platform shifts happening across enterprises is the move toward simpler, lower‑cost endpoints. Because the value is no longer in the device, it’s in the work session.

By centralizing applications, desktops, and access policies, organizations can:

• Treat endpoints as replaceable access points, not security liabilities
• Reduce the cost and lifecycle burden of premium devices
• Support BYOD, contractors, and frontline workers without expanding risk
• Isolate corporate work from personal environments

In this model, activity happens at the edge, but trust does not.

The endpoint becomes a window, not a container, for corporate work. Whether work is delivered through virtual desktops, SaaS applications, or a secure enterprise browser, the principle remains the same: work is centralized, even when execution is not.

Hybrid infrastructure is the new default

Most enterprises are not “moving to the cloud.” They are operating across clouds and keeping critical systems where they make the most sense.

A modern centralized platform embraces this reality:

• Sensitive workloads remain on‑prem for regulatory or latency reasons.
• Elastic capacity bursts to public cloud when needed.
• Management, monitoring, and access remain consistent everywhere.
• SaaS and web apps are delivered through secure enterprise browsers with centralized policy and session isolation.

This hybrid model delivers the agility of distributed infrastructure without the operational sprawl that may come with it. The result is a unified access model where apps, desktops, and browser‑based work are governed through the same platform lens—regardless of where they run.

Device choice without losing control

Centralized compute doesn’t require forcing every user into the same device. Most work can be delivered securely to low‑cost, easily replaceable endpoints—reducing spend, risk, and operational overhead. But modern platforms also recognize that some roles still benefit from high‑performance local devices. The difference is where control and security live.

In a modern centralized platform, identity, access, and policy are centralized, even when execution varies. Power users can run work locally when it makes sense, while still connecting securely to centralized applications, data, and services. For many users, especially task workers, secure enterprise browsers provide the fastest, lowest‑friction path to controlled access without the overhead of full desktop delivery or device lockdown.

Centralized infrastructure isn’t about eliminating choice. It’s about ensuring that every choice—low‑cost or high‑powered—operates within a consistent, secure framework for work.

Security follows the work, not the device

Traditional security models assumed trust based on location and ownership. That assumption is no longer useful. In a centralized, platform‑based model:

• Data stays protected regardless of where users connect.
• Policies are enforced centrally, not replicated across endpoints.
• Access is contextual, based on identity, posture, and risk.
• Work sessions are isolated, monitored, and auditable.

This is what makes centralized infrastructure such a natural foundation for zero trust as an operational reality. Security becomes inherent to the platform, not layered on top of every device.

The real shift from infrastructure to secure work

One mistake organizations make is treating centralized infrastructure as just a cost‑optimization tactic. It’s much more.

It’s a platform decision—one that determines how quickly you can onboard users, integrate acquisitions, respond to disruption, and scale securely.

When centralized infrastructure is done right, it enables:

• Faster M&A integration by onboarding users without re‑imaging devices
• Business continuity that doesn’t depend on a physical office
• Consistent user experience regardless of device or location
• Lower operational friction across IT, security, and compliance teams

It becomes the operating system to secure the work.

Life or death example

In healthcare, where seconds matter, centralized infrastructure enables both security and speed without forcing clinicians into rigid device models. Many hospitals pair Citrix with Imprivata to give clinicians fast, simple, and secure badge‑based access to their applications and desktops with a single tap while keeping patient data centralized and protected. Clinicians can move between shared workstations and instantly resume their sessions to stay clinically aware, while IT maintains centralized identity, access, and audit controls across the environment. The result is simpler access for caregivers, stronger compliance, and fewer device‑level exceptions that slow care delivery.

The Citrix platform

Citrix has long been associated with centralized delivery of apps and desktops. But the larger idea has always been about something more enduring: Decoupling work from devices, securely, at scale.

In today’s environment, that idea extends naturally into a broader platform vision:

• Centralized control
• Hybrid infrastructure
• Secure enterprise browsers for SaaS and web access
• Distributed, low‑cost devices
• Safe, consistent work experiences

Not centralized instead of distributed but centralized because the world is distributed.

The bottom line for IT leaders

The future of enterprise IT isn’t about choosing sides in an old architectural debate. It’s about building a platform that:

• Simplifies complexity
• Reduces risk
• Lowers cost
• Lets the business move faster than the infrastructure beneath it

Centralized infrastructure—modernized, hybrid, and device‑agnostic—is no longer a legacy concept. It’s the foundation to secure the work in a distributed world.

To learn more, check out our eBook: Centralized desktops vs. managed PCs: A smarter model for control and cost.

from Citrix Blogs https://ift.tt/GFrmUZu
via IFTTT

Chrome V8 Zero-Day CVE-2026-11645 Exploited in the Wild - Patch Now

Google has released security updates to address 74 vulnerabilities, including one that has come under active exploitation in the wild.

The high-severity vulnerability, tracked as CVE-2026-11645 (CVSS score: 8.8), has been described as an out-of-bounds memory access in V8, Chrome's JavaScript and WebAssembly engine.

"Out-of-bounds read and write in V8 in Google Chrome prior to 149.0.7827.103 allowed a remote attacker to execute arbitrary code inside a sandbox via a crafted HTML page," reads a description of the flaw in the NIST's National Vulnerability Database (NVD).

A security researcher named "303f06e3" has been credited with discovering and reporting the flaw on April 27, 2026. The researcher has been awarded a bug bounty of $55,000 for responsible disclosure.

As is customary in these cases, Google acknowledged that an "exploit for CVE-2026-11645 exists in the wild," but stopped short of sharing additional specifics to ensure that a majority of the users are updated with a fix and to prevent further exploitation.

With the latest development, Google has addressed a total of five actively exploited Chrome zero-days since the start of the year. This includes CVE-2026-2441, CVE-2026-3909, CVE-2026-3910, and CVE-2026-5281.

For optimal protection, users are advised to update their Chrome browser to versions 149.0.7827.102/.103 for Windows and Apple macOS, and 149.0.7827.102 for Linux. To make sure the latest updates are installed, users can navigate to More > Help > About Google Chrome and select Relaunch.

Users of other Chromium-based browsers, such as Microsoft Edge, Brave, Opera, and Vivaldi, are also advised to apply the fixes as and when they become available.

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

The Hidden Security Risk in Modern Networks: The Work Between Tools

Organizations have more visibility than ever. Growing tech stacks provide greater coverage, and network security teams are increasingly adopting AI and automation to help with routine tasks and reduce manual effort.

But the same challenges persist. Outages still last hours, causing significant financial losses, operational disruption, and reputational impact. Threat response and mean time to remediate (MTTR) remain slow. Misconfigurations and human error still create major incidents. And, despite the promises of AI, teams remain overwhelmed and burnt out.

Detection isn't the issue. Neither is tooling. Today, the real problem is execution - that is, the work that happens between tools.

The hidden operational layer most organizations overlook

Every time an alert fires, network security teams must:

• Gather context across systems
• Validate ownership and severity
• Route tickets to the appropriate people
• Request approvals
• Implement changes manually
• Log evidence

This operational work spans multiple systems and environments, requiring analysts to context-switch between:

• SIEM
• Firewalls
• Identity and access management (IAM) systems
• ITSM
• Monitoring platforms
• Cloud, on-prem, and hybrid environments
• Messaging and collaboration apps

This isn't just time- and labor-intensive. Manual processes also increase opportunities for human error - including inconsistencies, missed steps, and compliance gaps - introducing risks that can quickly compound.

Recent industry shifts have only made the problem worse. Distributed infrastructure, API sprawl, and increasingly interconnected tooling have expanded the number and complexity of systems teams must coordinate across. Attack velocity is increasing, and threats are becoming more sophisticated. At the same time, AI is accelerating operations and raising expectations of scale and speed, putting teams under increased pressure to deliver with limited capacity.

The key takeaway? Although today's environments may be more connected technically, the underlying operational workflows remain fragmented - creating bottlenecks, slowing response times, and limiting security's business impact.

When teams manually coordinate work between systems, people, and tools, operations can quickly break down. Here are three critical workflows where disconnected processes put your organization at risk.

1. Alert triage and incident response

Detection may be automated, but investigation and coordination usually aren't. Teams must manually gather context across systems to enrich alerts and dismiss false positives, increasing investigation time and using valuable resources that could be better spent on more complex problems.

These slow, manual processes lead to:

• Delays in identifying, escalating, containing, and remediating issues
• Missed threats that become real security incidents
• Alert fatigue that leads to poor analysis quality, missed true positives, and team burnout

2. Access and change management

Security-sensitive processes still rely heavily on humans as the integration layer. Access requests and network changes require manual approvals, which can lead to inconsistent validations and gaps in policy enforcement. Security and IT often work in separate systems, leading to duplicate work, delayed provisioning, and poor visibility into changes.

At scale, this can cause:

• Overprivileged access that violates least-privilege and Zero Trust principles
• Misconfigurations that create security vulnerabilities and outages
• Audit and compliance gaps that expose your organization to regulatory risk

3. Hybrid and multi-environment operations

Working across fragmented technology and hybrid environments adds complexity and operational overhead, as analysts must switch between different tooling and ownership models. Inconsistent processes and visibility gaps between teams make it difficult to maintain accountability, enforce standards, and execute reliably across systems.

This fragmentation can result in:

• Configuration drift that creates network instability and compliance risks
• Delayed responses to threats and incidents
• Security gaps due to inconsistent policy enforcement across environments

What forward-thinking organizations are doing differently

The solution isn't replacing tools. It's orchestrating how work moves across them.

To do this, organizations are adopting intelligent workflows. Intelligent workflows are the operational layer that connects systems, teams, approvals, automation, and decision-making across all environments. They combine three essential types of workflow:

• Deterministic automation to handle highly predictable, reliable, and controlled tasks
• AI to assess context, make decisions, and execute tasks autonomously
• Humans to handle high-impact, high-stakes tasks that require judgment and creativity

Unlike automation alone, which only handles discrete, isolated tasks, intelligent workflows enable network security teams to orchestrate entire processes from beginning to end, while still providing the flexibility, control, and oversight needed to apply the right approach to the right task.

What does an intelligent workflow look like in practice?

Consider the alert triage and incident response process above. Using intelligent workflows:

• A monitoring tool detects unusual activity and creates an alert
• AI pulls context from multiple systems to triage, enrich, and prioritize the alert based on severity and risk
• If the alert meets specific predefined conditions, the workflow automatically triggers actions, like containment or remediation processes
• If human judgment is required, the workflow routes the issue to the appropriate analyst for deeper investigation or approval
• All actions, decisions, and evidence are automatically logged to support auditing and compliance requirements

Before, the work between tools led to delays, missed threats, and alert fatigue. Now, intelligent workflows handle the end-to-end process, enabling teams to move from detection to execution faster, reduce MTTR, and relieve the strain on analysts.

How intelligent workflows enhance network security

For network security teams in particular, intelligent workflows unlock a number of benefits:

• Standardization reduces inconsistencies, missed steps, and errors, ensuring responses follow defined protocols and guidance across the entire organization
• Automatic evidence logging eliminates manual effort and improves auditability
• Shared workflows provide cross-functional visibility, alignment, and accountability
• Reduced operational burden relieves analyst fatigue and wins back time for high-impact security work, like complex investigations or strategy
• Consistent execution strengthens security posture and reduces risk
• Faster coordination reduces response times and improves operational resilience

All of this allows network security teams to operate at scale, extending their capacity without needing to add headcount.

Closing the gap between detection and execution

The biggest operational risk in modern networks isn't tooling or visibility - it's the gap between detection and execution.

The organizations that improve security and operational resilience don't just add more technology. Instead, they improve how work moves across their environment, using intelligent workflows to orchestrate the work between tools.

As network and security environments become more complex, this operational coordination will become just as crucial as visibility itself, enabling teams to operate securely, consistently, and at scale.

Learn more in Tines' ultimate guide to network operations management.

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/ZKFE4ue
via IFTTT

Hades PyPI Attack: 19 Packages Poisoned to Auto-Run Bun Credential Stealer

The Miasma supply chain campaign has sparked a fresh attack wave called Hades, this time involving 37 malicious wheel artifacts across 19 packages in the Python Package Index (PyPI) registry, as the Mini Shai-Hulud-style attacks continue to be refined and splintered to target specific ecosystems.

"The compromised releases shipped a *-setup.pth file that attempts to execute automatically during Python startup, download the Bun JavaScript runtime, and run an obfuscated JavaScript payload named _index.js," Socket said in a new analysis.

The list of identified packages is below -

• bramin 0.0.2, 0.0.3, 0.0.4
• cmd2func 0.2.2, 0.2.3
• coolbox 0.4.1, 0.4.2
• dynamo-release 1.5.4
• executor-engine 0.3.4, 0.3.5
• executor-http 0.1.3, 0.1.4
• funcdesc 0.2.2, 0.2.3
• magique 0.6.8, 0.6.9
• magique-ai 0.4.4, 0.4.5
• mrbios 0.1.1, 0.1.2
• napari-ufish 0.0.2, 0.0.3
• nucbox 0.1.2, 0.1.3
• okite 0.0.7, 0.0.8
• pantheon-agents 0.6.1, 0.6.2
• pantheon-toolsets 0.5.5, 0.5.6
• spateo-release 1.1.2
• synago 0.1.1, 0.1.2
• ufish 0.1.2, 0.1.3
• uprobe 0.1.3, 0.1.4

Like in the previous Shai-Hulud and Miasma campaigns, the malicious payload downloads and installs the Bun JavaScript runtime, which is then used to launch a heavily obfuscated JavaScript stealer that can harvest a wide range of data from developer systems.

This includes secrets associated with GitHub, npm, PyPI, RubyGems, JFrog, CircleCI, Anthropic, AWS, GCP, Azure, and Kubernetes, along with Docker configurations, Vault tokens, SSH keys, shell histories, .env files, .npmrc files, .pypirc files, Claude/MCP configurations, and other local or runner-accessible credentials.

What's changed this time around is the campaign marker. While previous iterations exported the harvested data to a public GitHub repository with the description "Miasma: The Spreading Blight," "Miasma: The Spreading Blight," and "Miasma - The Spreading Blight," the latest wave includes the repository descriptions -

• Hades - The End for the Damned
• Hades * The End for the Damned

"That makes Hades best understood as a PyPI branch of the same Mini Shai-Hulud / Miasma lineage, not a standalone Python malware incident," the application security company said. "The core playbook remains the same: abuse trusted package channels, execute before normal package use, stage a Bun-powered JavaScript payload, steal developer and CI/CD credentials, and use GitHub-centric exfiltration and propagation logic."

What has changed this time around is the use of a *-setup.pth file that's processed by Python's "site" module during interpreter startup, resulting in the execution of the malicious payload after installation without requiring the victim to import the poisoned package. The payload, in turn, downloads and runs Bun from GitHub and runs the stealer, but not before checking if the system corresponds to the Russian locale.

"This is the Python equivalent of the npm install-hook problem that Shai-Hulud and Miasma repeatedly exploit," Socket explained. "The syntax is different, but the security consequence is the same: dependency installation creates an execution edge before application code is reviewed or invoked."

Hades Cluster Attempts to Mislead AI Security Scanners

Also compromised as part of the Hades campaign are a number of packages related to the computational biology, bioinformatics, and genotype-phenotype analysis ecosystem -

• embiggen 0.11.97
• ensmallen 0.8.101
• gpsea 0.9.14
• mflux-streamlit 0.0.3, 0.0.4
• nhmpy 2.4.7
• ppkt2synergy 0.1.1
• pyphetools 0.9.120

Interestingly, this cluster employs a different approach in that the entry point is embedded inside the package's "__init__.py" file as an obfuscated single-line import hook, resulting in the same outcome: Downloading and running the Bun runtime, followed by the execution of the JavaScript payload.

"The use of the Bun runtime remains a consistent theme," StepSecurity said. "Downloading Bun as a standalone ZIP file allows the malware to run complex JavaScript tasks in environments that lack a Node.js installation, bypassing traditional package manager controls and network proxy logs."

In what has been characterized as a novel artificial intelligence (AI) defense evasion technique, the malware also incorporates a plain-text prompt injection that attempts to deceive Large Language Model (LLM)-based package analysis tools to instruct the model to classify the package as safe.

On top of that, the malware queries GitHub commits for the keyword "TheBeautifulSnadsOfTime" to extract a Base64-encoded string containing a JavaScript payload. It also polls GitHub for commits matching the keyword "firedalazer" so as to fetch a Python-based dropper and execute it.

Some of the important features built into the Hades malware are listed below -

• Replicate and spread laterally across developer networks via SSH or SCP, push trojanized versions of PyPI packages from compromised systems by exploiting the developers' OpenID Connect (OIDC) trust configurations.
• Target GitHub repositories to extract organization secrets using GitHub Actions runners if the harvested GitHub token has appropriate write permissions.
• Backdoor local workspace folders to trigger code execution when analyzed by AI assistants or opened in IDEs. Targets include Anthropic Claude, OpenAI Codex, Google Gemini, Microsoft Copilot, Cline, Aider, Tabby, Amazon Q, Cody, Bolt, and Continue.
• Install a background service named "gh-token-monitor" that acts as a wiper by removing all data ("rm -rf ~/; rm -rf ~/Documents") if the stolen GitHub token is revoked by the developer.

"A key capability of the Miasma actor is reading the process memory of the GitHub Actions runner (the Runner.Worker process) to extract secrets," security researcher Rohan Prabhu said. "In earlier campaigns, this was limited to Linux systems using /proc/{pid}/mem. The Hades Campaign introduces tailored macOS and Windows memory scrapers."

The development comes as StepSecurity revealed that an unknown attacker compromised the GitHub account ("LeonOstrez") linked to "Pythagora-io/gpt-pilot," a popular open-source AI developer tool, and force-pushed a variant of the Shai-Hulud credential-stealing worm to the main branch. The malware is designed to activate silently when an unsuspecting developer runs the project, while avoiding systems with a Russian locale.

"The malware, a variant of the Shai-Hulud worm, was stopped by an unlikely defender: ruff, a Python code formatter," Ashish Kurmi, co-founder and CTO of StepSecurity, said. "The attacker tried twice to get the malicious code past CI and failed both times because their injected Python file did not match the project's formatting and linting rules."

Software supply chain security company Snyk has described these attacks as part of the Shai-Hulud / Miasma lineage, with each wave leveraging a Bun-runtime obfuscated stealer and combining it with "new persistence, new exfiltration routes, and new ways to fire code automatically at install or build time."

"The Miasma campaign proves that having signed keys and authenticated maintainer accounts are no longer an absolute guarantee of safety," Cloudsmith said. "When upstream registries and repos are compromised, public code becomes one of the easiest, and most direct, ways of getting pwned."

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

Meta Blocks NSO Group's New WhatsApp Phishing Attack, Files Contempt Order

Meta on Monday said it detected and blocked spear-phishing attempts linked to Israeli spyware vendor NSO Group.

In addition, the tech giant said it's filing a federal court contempt order against the company for violating a permanent injunction that barred it from targeting WhatsApp and its users.

"They tried to trick people into clicking on malicious links to drive them to external websites outside of WhatsApp, similar to previously reported 1-click phishing campaigns linked to NSO," Meta said.

The social media company also said it caught NSO Group creating test accounts and groups on WhatsApp. They have since been taken down by Meta. The list of malicious domains linked to the activity is listed below -

• fr24cast[.]com
• ghazacast[.]com
• ikhwancast[.]com

The development comes a year after NSO Group was fined approximately $168 million in monetary damages, after a U.S. court found the company to have violated U.S. laws by exploiting WhatsApp servers to deploy Pegasus spyware targeting over 1,400 individuals globally.

In 2021, the company was also added to a U.S. Commerce Department blocklist for engaging in activities that are "contrary to the national security or foreign policy interests of the United States."

"As always, WhatsApp users' personal messages and calls remain protected with default end-to-end encryption," Meta said. "We encourage people to keep their apps and devices up to date and report suspicious activity so we can quickly investigate and take action."

Users who believe they may be at elevated risk of sophisticated cyber attacks because of who they are and what they do are recommended to enable strict account settings to harden their accounts. The feature reduces the attack surface by locking the account to more private settings, such as follows -

• Two-step verification is turned on.
• Link previews are turned off.
• Last seen and online, profile photo, About details, and profile links are locked to contacts only or to a pre-established list of people.
• Only known contacts or a pre-established list of people can be added to groups.

"Strict account settings are an advanced security feature that turns on privacy and security controls to help protect accounts from sophisticated cyber attacks," Meta notes in its help document. "Strict account settings are an optional, lockdown-style security feature that, when enabled, reduces your vulnerability to cyber attack by limiting functionality."

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

Critical Check Point VPN Flaw Exploited to Bypass Passwords in IKEv1 Setups

Check Point has warned of active exploitation of a critical vulnerability impacting Remote Access VPN and Mobile Access deployments that are configured to use the deprecated IKEv1 key exchange protocol.

The vulnerability, tracked as CVE-2026-50751 (CVSS score: 9.3), is a case of a logic flow weakness in certificate validation that allows an unauthenticated remote attacker to bypass user authentication and establish a remote access VPN connection without a valid user password.

"By exploiting a logic flaw in certificate validation, an attacker can establish a VPN session without possession of a valid password, effectively bypassing authentication requirements," Check Point said. "Additional post-authentication activity is required to access internal resources or escalate privileges."

The shortcoming impacts the following products and versions -

• Security Gateways R82.10 Jumbo Hotfix Take 19 or below, R82 Jumbo Hotfix Take 103 or below, R81.20 Jumbo Hotfix Take 141 or below, R81.10 (EOS), R81 (EOS), and R80.40 (EOS)
• Spark Firewalls: R80.20.X (EOS), R81.10.X, and R82.00.X

Successful exploitation requires the following conditions to be met -

• VPN Remote Access or Mobile Access is enabled
• IKEv1 is enabled for remote access
• Gateways accept legacy Remote Access clients
• Gateways do not demand a machine certificate for connections

The Israeli cybersecurity company said it first observed indications of suspicious activity on June 4, 2026, with the earliest observed exploitation dating back to May 7, 2026. Exploitation efforts are said to have ramped up starting this month.

The exploitation activity, Check Point added, has been limited to a "few dozen targeted organizations globally." In one case, the post-exploitation phase has been associated with a Qilin ransomware affiliate.

"We believe that this threat actor infrastructure is exploiting other VPN related vulnerabilities such as the ones published by Palo Alto [Networks], Fortinet, and F5," it noted. "We identified indicators suggesting the actor may use the Tox protocol for communication, a pattern commonly associated with financially motivated ransomware actors."

A key aspect is the use of a virtual private server (VPS) infrastructure to conduct the attacks. Specifically, this involves relying on VPS servers geolocated to a particular country to target organizations within its borders. Once access was established, the attackers were found attempting to download malicious ELF files from actor-controlled infrastructure.

Some aspects of these efforts overlap with a report from Ctrl-Alt-Intel last month, which highlighted the ransomware crew's abuse of corporate VPN appliances for initial access.

Further review of the affected VPN components has uncovered a second vulnerability, CVE-2026-50752 (CVSS score: 7.40), which may allow an adversary-in-the-middle (AitM) attack on VPN site-to-site connections. There is no evidence the flaw has been exploited in real-world attacks.

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

⚡ Weekly Recap: Instagram Account Hacks, Android Zero-Day, GitHub Worm and More

Monday again. The weekend was meant to be quiet. It wasn't. Last week had poisoned packages, a broken AI helper, and a worm tearing through repos. The ugly part: basic tricks still worked.

A chatbot got fooled. A bot token got leaked inside the malware. The same old mistakes showed up again. And while everyone chased the loud stuff, quieter attackers sat in inboxes for months, reading mail and stealing it bit by bit.

Lots to cover. Grab coffee. Read up.

⚡ Threat of the Week

Miasma Worm Hits 73 Microsoft GitHub Repositories in Supply Chain Attack - Microsoft's GitHub repositories became the latest to fall victim to the ongoing Miasma self-replicating supply chain attack campaign. The incident impacted 73 Microsoft repositories across four of its GitHub organizations, including Azure, Azure-Samples, Microsoft, and MicrosoftDocs. The development prompted GitHub to disable access to those repositories. Miasma is assessed to be a variant of the Mini Shai-Hulud worm that TeamPCP publicly released in mid-May 2026.

🔔 Top News

• Google Fixes Android Framework Flaw Under Exploitation - Google released patches for 124 security vulnerabilities impacting its Android operating system for the month of June 2026, including one high-severity flaw in the Framework component that has come under active exploitation. Tracked as CVE-2025-48595 (CVSS score: 8.4), the security flaw has been described as a case of privilege escalation without requiring any user interaction. The vulnerability impacts devices running Android versions 14, 15, 16, and 16 QPR2 (Quarterly Platform Release 2). Google has acknowledged there are indications that CVE-2025-48595 may be under "limited, targeted exploitation." As is typically the case, the tech giant did not reveal any specifics about who may have been behind the activity, the targets affected, and the scale of such efforts.
• U.S. Action Disrupts Investment Fraud Schemes - The U.S. Department of Justice announced the results of a sweeping action undertaken by government authorities and private sector companies to combat cyber-enabled and cryptocurrency fraud targeting Americans. The "Disruption Week" operation led to the takedown of millions of social media, email, and internet access accounts used by transnational cybercrime groups in Southeast Asia to defraud victims. Private sector entities voluntarily froze over $3.8 million in cryptocurrency involved in the laundering of funds stolen from Americans. The efforts are part of an ongoing U.S. government initiative called Scam Center Strike Force, which aims to dismantle transnational criminal organizations running cyber-enabled fraud and "pig butchering" (aka romance baiting) scams from compounds in Southeast Asia, along with the human trafficking and money laundering operations that fuel the illicit enterprise.
• China-Linked TA4922 Broadens Focus to Europe, Africa - A new Chinese-speaking cybercrime group has expanded its reach from East Asia into Europe and Africa, while rapidly overhauling the malware it employs to hack into corporate networks. The actor, tracked as TA4922, is financially motivated and focused on gaining remote access to victim systems for data theft, fraud, and the resale of access. Some elements of the threat actor's tactics overlap with Silver Fox and Void Arachne. Its operations are unusually varied, leveraging malware delivery, credential phishing, and credit card theft across different campaigns. While historical attacks targeted Japan, the actor has also targeted organizations in Taiwan, Korea, Singapore, and India, the U.K., Germany, Italy, and South Africa. The lures are localized, impersonating tax authorities, finance departments and human resources teams in the target's own language to distribute Atlas RAT, RomulusLoader, and SilentRunLoader through DLL side-loading techniques.
• OP-512 Targets Microsoft IIS Servers with Custom Web Shell Framework - A previously unreported threat cluster dubbed OP-512 has been observed targeting Microsoft Internet Information Services (IIS) servers to deploy a bespoke web shell framework. The espionage-focused activity has been assessed as originating from China. "OP-512 was highly likely conducting espionage through a compromised Internet Information Services (IIS) web server on an organization whose sector and geography align with China-linked intelligence priorities," ReliaQuest said. The web shell framework facilitates file management and authenticated command execution.
• Hackers Spied on a Stock Exchange Executive's Outlook Mailbox for 5 Months - Unknown threat actors managed to spy on a senior member of an unnamed global stock exchange for at least five months. There are still several unanswered questions, like who was behind it and how they obtained initial access. However, what's evident is that the attacker spent several months inside the Outlook mailbox and likely accessed sensitive information. The goal of the operation was most likely cyber espionage, but details are scant on which stock exchange was targeted. The earliest sign of malicious activity was observed on October 10, 2025. The attack led to the deployment of a mailbox stealer that ran in 2-4 week intervals to hoover up email data. The captured information was exfiltrated via Dropbox and Microsoft OneDrive Personal, transferring only small batches at a time to avoid raising any red flags. The data exfiltration runs lasted through March 2026.

‎️🔥 Trending CVEs

Bugs drop weekly, and the gap between a patch and an exploit is shrinking fast. These are the heavy hitters for the week: high-severity, widely used, or already being poked at in the wild.

Check the list, patch what you have, and hit the ones marked urgent first - CVE-2026-28318 (SolarWinds Serv-U), from CVE-2026-39210 through CVE-2026-39217 (FFmpeg), CVE-2026-20245 (Cisco Catalyst SD-WAN Manager), CVE-2026-20230 (Cisco Unified Communications Manager), CVE-2026-3300 (Everest Forms Pro plugin), CVE-2025-48595 (Google Android) CVE-2026-8501 (PCTCore64.sys), CVE-2026-10629 (Verizon IMS network), CVE-2026-7299 (Appsmith), CVE-2026-10621, CVE-2026-10622 (Collibra Agent), CVE-2026-0826 (HP Poly Voice), CVE-2026-8206 (Themeum Kirki - Freeform Page Builder, Website Builder & Customizer plugin), CVE-2026-23479, CVE-2026-23631 aka DarkReplica, CVE-2026-25243, CVE-2026-25588, CVE-2026-25589 (Redis), CVE-2026-49200, CVE-2026-49201 (Acer Wave 7 routers), CVE-2026-8874, CVE-2026-8876, CVE-2026-8878, CVE-2026-8879, CVE-2026-8881, CVE-2026-8888, CVE-2026-8889 (Securly), CVE-2026-10881, CVE-2026-10882, CVE-2026-10883 (Google Chrome), CVE-2026-41722, CVE-2026-41723, CVE-2026-41724 (Broadcom VMware Cloud Foundation Operations), CVE-2026-34908, CVE-2026-34909 (UniFi OS Server), CVE-2026-4372 (Hugging Face), CVE-2026-45495 (Microsoft Edge), CVE-2026-42253 (Apache ActiveMQ), CVE-2026-9614 (Ivanti ISTM), CVE-2026-48019 (laravel/framework), CVE-2026-5386 (KMW CCTV security cameras), CVE-2026-5509 (TP-Link Archer BE450 v1 and Archer BE7200 v1), CVE-2026-4387 (StrongDM), CVE-2026-8633 (IBM WebSphere), and CVE-2026-9739 (MCP Toolbox).

🎥 Cybersecurity Webinars

• Learn How to Validate What Your SIEM, EDR, and SOC Catch → Automated pentesting finds flaws. It doesn't prove your defenses caught them. Join Picus experts to learn where testing falls short, why "clean" reports can mislead, and how validation shows what your SIEM, EDR, and SOC actually detect.
• Stop AI-Powered Attacks Before They Spread → AI is making cyberattacks faster, harder to spot, and easier to scale. This webinar shows why old defenses fail against threats like Mythos-and how Zero Trust helps block movement, limit damage, and stop attacks before they grow.
• Learn How to Detect and Stop Risky AI Use in Real Time → AI tools are spreading through the workplace faster than security teams can control. Every pasted file, prompt, or piece of code can expose sensitive data to systems that the business never approved. This webinar shows how to detect risky AI use, stop leaks in real time, and keep company data out of uncontrolled AI tools.

📰 Around the Cyber World

• Five Eyes Warns of China Exploiting LinkedIn to Target Security Personnel - Chinese military intelligence services are using LinkedIn and other professional networking sites like Indeed and Upwork to recruit people with access to government, military, foreign policy, or sensitive economic information, the U.S. and its Five Eyes intelligence partners said in an advisory. The aim is to acquire privileged military, political and economic intelligence that can provide China with a strategic and tactical advantage over the Five Eyes, per the advisory. "These actors use an aggressive online recruitment strategy whereby intelligence officers or their affiliates pose as employees of private consultancies, think tanks, or human resources firms, and place online job advertisements for foreign policy and defense analysts," the agencies said. Bloomberg reported that China has been targeting Five Eyes nationals with security clearance, particularly those working in foreign affairs, security, and intelligence, and military personnel, including people stationed in the Asia-Pacific region, as well as journalists, academics, and think-tank employees with knowledge of unclassified information. Targets are offered payments in exchange for increasingly privileged information. Payments may arrive through a number of online platforms, including reputable services like PayPal, Zelle, and Wise, or via Western Union and cryptocurrency.
• Over 20K Accounts Likely Impacted in Instagram Attack Campaign - Meta has revealed that 20,225 Instagram accounts may have been impacted in a recent attack abusing an AI-powered support tool. The attacks involved compromising the accounts simply by asking Meta's chatbot to link their own email address to the targeted account. This enabled unauthorized third parties to reset the account password and take control of it. Many of the high-profile accounts were then sold on the dark web. The exploitation of the High Touch Support (HTS) tool was discovered on May 31, 2026. It's currently what personal information, if any, the threat actors may have accessed. The use of the tool has since been disabled. The development comes as a vulnerability was disclosed in Instagram's web-based password reset flow that exposed unredacted email addresses and phone numbers associated with user accounts when providing a user name as input.
• Hola Browser for Windows Compromised to Deliver Cryptocurrency Miner - Sophos discovered an XMRig cryptocurrency miner binary bundled within a certified version of the Hola Browser installer for Windows. Hola attributed the anomaly to a supply chain compromise affecting its "update distribution pipeline," which allowed the unauthorized payload to evade detection. "This was a supply chain compromise, and critically, no user data was accessed, exfiltrated, or compromised at any point during this incident affecting 0.1% of users," Hola said. "We have since completely rebuilt our distribution pipeline, implemented advanced code-signing verification, and introduced tighter access controls and continuous monitoring across our infrastructure."
• Malicious npm Packages Target Trusted Brands - A threat actor has been deploying dozens of malicious packages to npm targeting AI companies, luxury brands, and venture capital firms. These packages drop a new malware strain that impersonates an AI coding tool. The malicious code is launched by means of a post-install hook. "When the binary payloads are run, a terminal window pops up and prompts the user for user information and OpenAI or Anthropic API keys," OpenSourceMalware said. "Meanwhile, in the background, the malware is already harvesting ~/.local/share/stardrop/auth.json and other files for credentials."
• 2 npm Packages Deliver Epsilon Stealer - Two malicious npm packages, turbo-axios and faster-axios, targeted developers searching for the popular axios HTTP client. "Both are trojanized copies of the real axios source with a single addition: a postinstall hook that fetches and eval()s remote JavaScript," SafeDep said. "The chain terminates in Epsilon Stealer, a malware-as-a-service (MaaS) Electron infostealer that harvests browser credentials, crypto wallets, and messaging sessions, then opens a persistent WebSocket channel for arbitrary command execution."
• Malicious npm Package Leaks Own Telegram Bot Token - In a related development, OX Security flagged a malicious npm package named cms-store-ren that exfiltrates data to Telegram, while leaking its own bot API token in the process. "cms-store-ren is a malicious npm package that collects data from developers' machines and then sends them to a Telegram channel," OX Security said. "It also downloads a potentially malicious JavaScript file from a remote server and tries to execute it, although this behavior wasn't yet weaponized. The package acts as a downloader/loader whose primary purpose is to fetch and execute a second-stage payload while reporting successful infections back to the malicious actor."
• Fake Document Factory Taken Down in Spain - French and Spanish authorities, with support from Europol, dismantled an online marketplace selling fake identity documents to migrant smuggling rings operating in Europe to evade border controls, fraudulently obtain residence rights, and facilitate secondary movements within the region. The counterfeit document production facility, located in Alicante, Spain, led to one arrest and the seizure of approximately 800 forged European documents, document-production equipment, digital devices, a vehicle, and €1,580 in cash. "The search of the apartment, rented under a false name, uncovered a fully operational counterfeit document workshop, highlighting the industrial-scale production methods increasingly used by organised crime groups involved in document fraud," Europol said.
• Former IBM Executive Accuses Company of Covering Up Hacks - A former IBM cybersecurity executive accused the company of getting hacked three times in the previous decade by foreign governments and then covering up the breaches. William Barlow, who was IBM's vice president of threat intelligence until August 2019, said IBM concluded Chinese hackers breached its core network between 2013 and 2016, but that the software company went on to conceal the incidents and never publicly disclosed them. Breaches at two other IBM subsidiaries were also covered up in a similar manner, a lawsuit unsealed last week revealed.
• Gafgyt Botnet Variant Targets DD-WRT Router - A new variant of the Gafgyt botnet called C0XMO is now targeting DD-WRT router firmware by exploiting a stack buffer overflow vulnerability (CVE-2021-27137). "Unlike earlier versions, this malware separates its lateral movement into a standalone Python script," Fortinet FortiGuard Labs said. "This approach helps the attacker target various system architectures and device types more efficiently." The activity was discovered in March 2026 in connection with an attack targeting a Japanese technology firm. Once C0XMO is delivered and executed on the victim host, it sets up persistence, terminates competing processes and red teaming utilities, and then establishes a connection with a remote server to accept DDoS attack commands against specific targets. It also comes with a scanner to facilitate lateral movement via SSH, Telnet, Android Debug Bridge (ADB), and other HTTP-based exploits (e.g., CVE-2025-34054, CVE-2016-15047, CVE-2015-2051, CVE-2022-35914, and CVE-2021-27137).
• Malicious PyPI Package Drops Backdoor - Parsimonius, a malicious typosquat of the parsimonious Python package, "incorporated the legitimate parsimonious parsing functionality to avoid suspicion while simultaneously deploying a Telegram-based backdoor," Zscaler said. "Once installed, the backdoor provided attackers with remote access capabilities and facilitated the theft of sensitive data, including .env files and bot authentication tokens." The package racked up 2,474 downloads, prior to it being removed.
• VECT Ransomware Suffers From New Flaws - A new analysis of the Windows version of VECT ransomware has uncovered additional vulnerabilities that "can leave files renamed, partially encrypted, inconsistently modified, or damaged in ways the attacker's own decryptor cannot reliably reverse," Morphisec revealed. "These bugs change the recovery picture. A VECT incident does not necessarily produce one clean class of encrypted files. The same .vect suffix can represent several outcomes: a file that was only renamed, a file encrypted in a single pass, a large file with only selected regions modified, or a file left inconsistent by failed writes or shared-state races."
• Handala Brand Used for Physical and Influence Operations - Recorded Future has revealed that Iran's Ministry of Intelligence (MOIS) has likely expanded the use of its Handala persona to include external physical and influence operations targeting U.S. and Israeli interests, bringing cyber, physical, and influence personas under a single umbrella. The threat intelligence company said it observed significant overlaps in the online activities of Handala Hack Team, a new Handala-branded persona named "Handala Popular Resistance Front," and three influence operations networks dubbed VIPEmployment, MOISIRAN, and Brave Israel. "Notably, the HPRF and the three influence operations networks all almost certainly share a modus operandi: their administrators solicit individuals to conduct physical attacks and espionage targeting U.S. and Israeli entities, on behalf of Iranian intelligence agencies, for a financial reward," Recorded Future said. "By encompassing these groups under the Handala brand, MOIS likely seeks to take advantage of Handala's global recognition to amplify its solicitation efforts."
• New Android Trojan OverlayPhantom Spotted - A new Android banking trojan referred to as OverlayPhantom has been observed targeting more than 180 apps across 10 countries via malicious URLs, aiming to steal credentials via fake overlays and real-time screen sharing. "The malware employs a two-stage infection chain, using a dropper application that impersonates trusted platforms, including the official Austrian government identity application, ID Austria, and the widely used consumer platform TikTok, to deceive victims into installing it," Cyble said. "Once deployed, OverlayPhantom masquerades as 'Google Play Services' and abuses Android's accessibility service to gain persistent, elevated control of the infected device." The malware is equipped to run over 30 remote commands to enable automated gestures, clipboard manipulation, credential theft, and data exfiltration. Targets of the malware include financial and cryptocurrency apps serving users in the U.S., Australia, Germany, France, Belgium, Finland, the Netherlands, Italy, Spain, and the U.K.
• Fake Copyright Infringement Notice Emails Lead to Credential Theft - Threat actors are using official-looking copyright removal requests to target Chrome extension developers, warning them of imminent removal and urging them to appeal by clicking on a link ("dmca-chrome-extensions[.]click") within 48 hours. "After you enter your extension's ID to 'verify' it, the page pulls in your extension's real name and icon," Malwarebytes said. "But it's all part of a phishing attack designed to steal your Google username and password." Other campaigns have been found to use pirated PC games and modified installers for franchises like Far Cry, Need for Speed, FIFA, and Assassin's Creed to distribute a Windows password-stealing malware; fake payment invoices that trick recipients into calling a bogus customer support agent as part of refund scams; counterfeit websites impersonating BlueWallet and OpenAI ChatGPT to deliver a macOS stealer and clipper. For Windows systems, the website mimicking ChatGPT is used to deliver a credential-stealing malware loader, while Mac users get Odyssey Stealer, a fork of Atomic Stealer (AMOS).
• Bypassing Malicious Skill Scanners - Trail of Bit said it was able to bypass ClawHub's malicious skill detector, Cisco's agent skill scanner, and scanners integrated into skills.sh to push rogue skills to public skill marketplaces and steal sensitive data from developer systems. One of the malicious skills used prompt injection to "convince the guard model that the malicious payload is nothing to worry about," the company said. "The skill tells the agent to configure its package managers (npm and yarn) to use an attacker-controlled registry, but dresses the subterfuge up in the language of corporate environment configurations and virtual private network access to convince the LLM analyzer the change is innocuous." The takeaway here is that trust can never be outsourced to a third-party scanner and that they cannot reliably detect malicious content in agent skills. To counter the risks, organizations are recommended to curate skill marketplaces for their employees and agents using trustworthy open-source collections.
• Phishing Campaigns Drop Remcos RAT - Payment slip-themed phishing emails are being used to distribute a link pointing an external file-hosting service like MediaFire, which triggers the download of a screen saver (.SCR) file, which kicks off a multi-stage chain that ends in the deployment of Remcos RAT by means of an AutoIt script after performing anti-analysis checks. The activity has been attributed by JUMPSEC to a threat group called BlackToad, which is likely an affiliate of the broader Nigerian e-crime ecosystem that's tracked as SilverTerrier with its own set of targeting lures and tradecraft. It also exhibits some infrastructure overlap with a cluster documented by Agoda Engineering as BoredFluff, which targeted hotel staff in 2024 through fake guest enquiries to deliver Remcos RAT through a malware loader named GuLoader.
• Pink, a New Com-Affiliated Actor - A new cybercrime brand called Pink (aka CL-CRI-1147), is leveraging vishing for initial access with the primary objective of data theft and extortion. It's assessed to be part of the broader Com ecosystem, embracing techniques similar to those of ShinyHunters and CL-CRI-1116 (Blackfile/Redact). The group's data leak site went live on May 31, 2026. "The threat actor leverages vishing for initial access, impersonating internal IT personnel to convince a user to input credentials into a phishing site, allowing the actor to gain access to the victim's account and MFA," Palo Alto Networks Unit 42 said. "After gaining access to the victim's account, the actor rapidly identifies and exfiltrates data from platforms like SharePoint and OneDrive, similar to other Com-affiliated groups." The threat actor has also been found to make use of compromised victim accounts to send their initial extortion email as well as internal Teams messages. According to Google, the activity maps to a threat group it calls UNC6671.

• CAI → It is an open-source framework for building AI agents that help with cybersecurity work, from security testing and vulnerability discovery to defense automation. It supports 300+ AI models and includes built-in tools for tasks like reconnaissance, exploitation, privilege escalation, and security assessment.
• PMG → It is a free, open-source tool that blocks malicious open-source packages before they install. It sits in front of package managers like npm, pip, and Poetry, checks packages with SafeDep threat intelligence, and helps protect developers and AI coding agents from supply-chain attacks.

Disclaimer: This is strictly for research and learning. It hasn't been through a formal security audit, so don't just blindly drop it into production. Read the code, break it in a sandbox first, and make sure whatever you're doing stays on the right side of the law.

Conclusion

That's the week. Nothing here is new. Same tricks. Same shortcuts. Same open inboxes. That's what makes it worse. Patch what matters first. Warn the people who click everything. Back up the important stuff.

Then log off for a bit. It'll be messy again by next Monday.

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