YOLO Mode: Agent Autonomy Without the Guardrails

AI agents have come a long way in both capability and everyday use since generative AI went mainstream in late 2022. In Stack Overflow’s 2025 Developer Survey, 84% of developers said they use or plan to use AI tools in their workflow, up from 76% a year earlier. As those tools shift from suggesting code to writing files and running commands on their own, one practical question follows. How much should an agent be allowed to do without stopping to ask? Turn that dial all the way up and you reach what developers call YOLO mode.

It’s worth understanding YOLO mode before you enable it, because its main risk is easy to misread. The risk comes down to where an agent runs.  On your own machine, one mistaken command can delete  files, expose your credentials, and make network requests you may not want. Inside a proper boundary, however, developers can use agents in YOLO mode to unlock a new level of productivity, without jeopardizing security.

Key takeaways

• YOLO mode is when an AI agent auto-approves every action, with no confirmation prompts.
• It’s popular because it’s fast, and risky for the same reason. The danger isn’t the autonomy, it’s where the autonomy runs.
• On your host, a bad command or prompt injection reaches real files and credentials. Inside an isolated sandbox, the blast radius is contained.
• Run YOLO mode where it can’t do real damage, in an isolated, disposable environment with scoped access and no real secrets.

What is YOLO mode?

YOLO mode is the community nickname for running an AI agent with every action auto-approved. When turned on, agents can read files, write code, run shell commands, and call tools without stopping for user approval. While in Claude Code it’s the –dangerously-skip-permissions flag, other common agents each have their own version of the same switch.

• Codex CLI has `–full-auto`, plus `–dangerously-bypass-approvals-and-sandbox` when you drop the sandbox too.
• Gemini CLI uses `–yolo`, or the Ctrl+Y toggle mid-session.
• GitHub Copilot CLI has `–allow-all`, also aliased as `–yolo`.
• Cursor exposes it as auto-run in settings rather than a flag.

The names differ, but the behavior is the same: remove the prompts and let the agent go. 

YOLO mode showed up in Cursor first, then Claude Code, and by 2026 it’s a standard toggle in most coding agents. But when people ask what YOLO mode is, they’re usually asking whether they should use it, and the answer is that it depends entirely on where the agent is running.

Why developers turn it on

On a regular task, a careful agent asks for permission constantly. “Can I edit this file, run this test, install this package, call this tool?” 

Dozens of prompts for one feature. While these constant permission requests can help prevent agents from going rogue, each approval forces you to context switch and breaks the flow that made the agent worth using. A few reasons why developers are leveraging YOLO mode include:

• Context switching: Every approval pulls a developer out of their flow, taxing mental focus and overall productivity. 
• Prompt fatigue: Excessive querying, refinement, and approvals force creative coding to take a back seat to tedious prompt wrangling and debugging.  
• Low-risk, routine work: Agents can often handle repetitive tasks that would otherwise take developers away from creative coding and innovation. 
• Momentum: An agent is most useful when it has the freedom to keep moving, but a steady stream of prompts breaks that.

If you turn approvals off, these friction points disappear for the most part, and the agent can deliver the speed it promised. But what’s the cost of giving agents the autonomy of YOLO mode?

Why is YOLO mode risky?

When you remove the prompts, you remove the last human check before an action runs, which amplifies the security risks agents already carry. If the agent is working directly on your host, that action has the full run of your machine, including your files, environment variables, credentials, and network. A confused or compromised agent can do a significant amount of damage when nothing stands between an agent’s decision and your system.

On an unprotected host, YOLO mode introduces risks such as:

• Destructive commands: A vague or mistaken instruction runs something like rm -rf against the wrong directory, and nothing pauses to catch it.
• Secret and credential exposure: The agent can read environment variables, .ssh keys, tokens, and .env files, then use or leak them.
• Prompt injection: The agent acts on whatever it reads, so a hidden instruction in a web page, an issue, a code comment, or a document can redirect it, and the attacker never needs access to your machine.
• Data exfiltration: A mistaken or hijacked agent sends sensitive data out over the network.
• Unintended broad changes: Edits and config changes reach past the task at hand into your other projects.
• Network and lateral reach: The agent can hit internal endpoints and outside services, or act with your credentials to push code and call APIs.

And unfortunately, keeping manual approvals on doesn’t remove all risk. Once permission fatigue kicks in, it can be all too easy to accidentally approve the wrong request. So the safeguard belongs in the environment the agent runs in, where a bad command or a tired click has a greatly reduced scope of impact.

The fix isn’t fewer permissions, it’s a boundary

If prompts aren’t the answer, what is? A boundary the agent can’t cross. Guardrails only work when something outside the agent enforces them. The agent needs a bounding box, with constraints set before it runs and clear limits on what it can touch. Inside that box, it should be free to move as fast as it wants. The goal is to shape the environment so that a mistake can’t damage your systems or leak your secrets.

In practice, that means running the agent in an isolated, ephemeral environment instead of on your host. Done well, the agent gets a real place to work. It can install packages, run services, and edit files, but it can’t see your credentials, reach your other projects, or touch the host.

Unlike a container that shares the host kernel, a microVM puts a hardware-level boundary around the agent, so the isolation holds even if the agent tries to break out, and it does that without the speed penalty people expect. If a run goes sideways, you destroy the environment and start clean. This is the core idea behind sandbox security and why agents need isolation in the first place.

What does YOLO mode look like at scale?

For one developer on a sandboxed laptop, YOLO mode is a personal choice. Across a team, it becomes a policy question. A hundred developers each deciding on their own when to skip permissions is the ungoverned-autonomy problem that keeps security leaders up at night. The picture that works at scale is one where the safe path is the default. Every agent runs inside an isolated, disposable environment, configured once at the organization level so it holds for everyone.

This is the problem AI Governance is built to solve. You define the rules once across the surfaces that matter, network access, the filesystem, and the tools an agent can reach, then enforce them automatically at every developer’s machine. Governance turns a per-developer judgment call into a consistent, repeatable capability. Clear boundaries are what let an organization extend autonomy to its agents while keeping the risk contained. Once the boundary is standard, YOLO mode is fast and safe for everyone.

What it unlocks for developers

Once the boundary is in place, the developer can stop supervising every step, and the payoff kicks in:

• Deep focus: Give direction, step away, and come back to a cloned repo, passing tests, and an open pull request. No interruptions pulling you off your own work.
• Long, autonomous runs: The agent edits, runs the tests, reads the failures, and retries until the task is done, the kind of run a wall of prompts would stall.
• Agents in parallel: Point several at different tasks, each in its own disposable environment, and let them run at once.
• You review the outcome: Your job moves up to the pull request, the tests, and the diff, where your judgment matters most.

That’s the real appeal, and the sandbox is what makes it safe to lean on.

Unlock agent autonomy, safely

YOLO mode is really a question in disguise. How much autonomy can you give an agent before the risk outweighs the speed? Framed that way, the answer stops being about the agent and starts being about its environment. Give an agent the run of your laptop and even a small mistake is expensive. But give it a boundary it can’t cross and you get the speed with almost none of the exposure.

That’s exactly what Docker Sandboxes is built for. Each agent runs in its own disposable microVM with control over networking, filesystem access, and resource limits, so you can run agents in YOLO mode safely from day one. For teams that want those boundaries applied consistently rather than agent by agent, Docker AI Governance sets and enforces the rules everywhere developers work. Define the box. Then let the agent go as fast as it likes.

Get started with Docker Sandboxes → 

Explore Docker AI Governance →

Frequently asked questions

Is YOLO mode safe?

It depends entirely on where the agent runs. On your host machine, YOLO mode is risky, because a mistake or a prompt injection can reach your files and credentials. Inside an isolated, disposable environment with scoped access and no real secrets, the blast radius is contained and YOLO mode is reasonable to use.

What does –dangerously-skip-permissions do in Claude Code?

It turns off the confirmation prompts, so Claude Code reads, writes, runs commands, and calls tools without asking for approval at each step. It trades the safety of human review for speed. It’s the most common way people run Claude Code in YOLO mode.

How do I use YOLO mode safely?

Run the agent inside an isolated sandbox rather than on your main machine, give it scoped network access and throwaway credentials instead of your real ones, work against a cloned or disposable copy of your project, and keep a way to inspect what it did. The goal is a boundary the agent can’t cross, not a more careful set of prompts.

Is auto mode the same as YOLO mode?

Not exactly. Full YOLO mode approves everything. Some tools now offer a classifier-gated auto mode that runs safe actions automatically while still blocking or flagging dangerous ones. That’s a useful middle ground, but it’s a filter on top of the agent, not a boundary around it. Isolation still matters.

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

The common security controls behind India's regulatory wave

India’s security and privacy rulebook has changed quickly. But beneath the new layers of requirements, a common control set is emerging: encryption, tokenization and masking, least-privilege access, audit logging and retention, and controls for keeping regulated data inside India. 

Over the last decade, India has strengthened several major security and privacy requirements, including the Digital Personal Data Protection (DPDP) Rules, the Securities and Exchange Board of India’s (SEBI) Cybersecurity and Cyber Resilience Framework (CSCRF), the Indian Computer Emergency Response Team’s (CERT-In) cybersecurity directions, and the Reserve Bank of India’s (RBI) payment data localization mandate. For organizations operating in India, especially in banking, financial services, payments, or the securities markets, these obligations now stack across regulators, deadlines, and enforcement regimes.  

It’s tempting to treat each one as a separate compliance project, staffed and solved on its own track. But line the technical requirements up, and a recognizable pattern emerges. Collectively, the mandate is clear: The sensitive data, and the credentials that protect it, should be looked after from creation to deletion, reachable only by those who genuinely need them, with a provable record of who touched what. 

This post focuses exclusively on the security control aspects of the frameworks discussed and should not be considered as compliance assessment. The content is provided solely for informational purposes and should not be construed as legal advice and/or regulatory advisory. Organizations should conduct their own legal and compliance assessments before relying on or taking any action based on the information contained herein. This highlights areas where HashiCorp Vault, with support from HashiCorp Boundary and Hashicorp Consul, may be considered when addressing common controls for secrets, encryption, access, auditability, and service-to service protection. Consent, notice, data-principal rights, and other legal obligations are out of scope. 

Four frameworks, one direction

DPDP Rules: Security safeguards

The DPDP Rules were notified in November 2025, with phased commencement dates. Any organization that determines why and how the digital personal data of people in India is processed may be impacted, regardless of industry. The fines are serious. Failing to put reasonable security safeguards in place can draw a penalty of up to ₹250 crore. For most boards, a number that size is what escalates data security from an IT task into an enterprise-risk concern.  

Companies need to be focused on several key areas that any security architect would recognize, including but not limited to:  

• Protecting personal data using measures such as encryption, obfuscation, masking, or virtual tokens mapped to that personal data 

• Controlling access to the systems that hold personal data 

• Keeping visibility on access through logs, monitoring, and review 

• Maintaining backups for continued processing 

• Retaining logs and personal data for one year 

SEBI CSCRF: Cybersecurity for regulated entities

Issued by SEBI in August 2024, the Cybersecurity and Cyber Resilience Framework created one standard built around five resilience goals: anticipate, withstand, contain, recover, and evolve. It reaches across the securities market — stock exchanges, clearing corporations, depositories, mutual funds, portfolio managers, alternative investment funds, stockbrokers, and KYC registration agencies — with requirements scaled to each entity’s size and risk.  

CERT-In directions: Stringent reporting requirement

Effective June 2022, CERT-In’s directions come down to two core requirements: better observability and faster incident reporting. And they apply to a very wide net: service providers, intermediaries, data centers, body corporates, and government organizations. Notably, covered entities must report specified cyber incidents in accordance with the timelines stipulated under CERT-In. A single incident can also trigger reporting requirements for both CERT-In and DPDP.

RBI: Data localization and IT security directions 

In 2018, the RBI-mandated payment data must be stored only in India. And where any processing happens abroad, the data must be brought back within 24 hours. It applies to payment system operators and the providers in their chain. This was a turning point, and the rules have only expanded since.  

Table 1. The frameworks at a glance 

Framework	Applies to	Deadline	Technical mandates
DPDP Rules 2025	Any data fiduciary handling digital personal data of people in India	Rule 6 safeguards enforceable May 13, 2027	Encryption; masking or virtual tokens; access control; logging with one-year retention; backups
SEBI CSCRF	Securities market- regulated entities — exchanges, depositories, mutual funds, brokers, and others	Most REs August 31, 2025; HSM for qualified REs June 30, 2025 (SEBI cloud-services framework)	Encryption at rest and in transit; data in India; SOC and SIEM with 24/7 monitoring; VAPT; HSM
CERT-In directions 2022	Service providers, intermediaries, data centers, body corporates, government organizations	In force since June 27, 2022	Report incidents within six hours; 180-day ICT logs stored in India; NTP time-sync
RBI directions	Payment system operators, banks, and NBFCs	Payment data localization since 2018; IT-governance direction April 1, 2024	Payment data stored only in India; strong cryptography, access controls, audit trails; MFA; WAF and DDoS protection

<p></p>

Different regulators, different deadlines, different penalties. Underneath, the same handful of technical controls. The below image shows how HashiCorp can help:   

The common control emergence

Across many of the key rules and requirements, the same five controls come up: 

• Encryption of data at rest and in transit, so intercepted or stolen data is unreadable 

• Tokenization or masking of sensitive fields, so the data flowing through your systems isn’t the real thing in the first place 

• Least-privilege access, so people, applications, and partners reach only what they need, only for as long as they need it 

• Audit logging with monitoring and retention, so every access is visible and reviewable after the fact 

• Data residency, so regulated data and logs stay inside India 

Build each well, and companies answer many of their compliance challenges at once.  

Vault in the context of control set

Vault is an identity-based secrets and encryption platform, a single audited place to store credentials and keys, encrypt and tokenize data, and control who can do what. It is not a compliance product, and it is not a database that holds all your personal data. It protects the secrets, keys, and sensitive fields routed through it and records every interaction. Vault can help organizations implement several of these controls through:

Encryption: Sensitive data encrypted at rest and in transit, using strong, current algorithms

Vault’s Transit engine offers encryption as a service. An application sends Vault a piece of plaintext and gets back ciphertext. The encryption keys themselves never leave Vault and are never exposed to the application. That means developers don’t have to implement cryptography themselves or manage raw keys in their code — a common source of mistakes — and the organization can rotate keys and re-encrypt centrally.

Tokenization and masking: Sensitive values swapped for tokens that mean nothing on their own

Vault’s Transform engine — a Vault Enterprise and HCP feature — does tokenization, format-preserving encryption, and data masking. Tokenization swaps a real value, such as an account or identity number, for a token that systems can store and pass around freely, while the real value stays locked away in Vault. Format-preserving encryption keeps the shape of the data — a 12-digit number stays a 12-digit number, for example — so it still fits existing databases and screens.  

Least-privilege access: Access to sensitive systems and data restricted to authorized identities, on a need-to-know basis 

Vault is deny-by-default. Policies grant a named identity access to exactly the paths it needs and nothing more. Vault can also issue dynamic secrets. Instead of a long-lived database password shared across an application fleet, Vault generates a unique, short-lived credential on request and automatically revokes it when its lease ends. A credential that exists for an hour and is tied to one identity is a much smaller risk than a static password that lives for years.  

Audit logging and retention: A visible, reviewable record of who accessed sensitive data and when, retained for a defined period

Vault’s audit devices records authenticated requests, including which identity accessed which path, whether the request succeeded, and where it came from. To support regulatory retention and investigation requirements, organizations should stream those events to a SIEM or log platform configured for the required retention period, access controls, and tamper-resistant storage.  

Hardware-backed keys: Dedicated hardware security module and strong cryptographic standards 

Vault Enterprise integrates with hardware security modules and supports architectures that need to remain compliant with the Federal Information Processing Standards (FIPS). An HSM can guard Vault’s own root of trust — the key that unseals Vault — so even someone with the storage disks cannot read what Vault protects.  

A closer look: API key security and the secrets lifecycle

Controls rarely arrive alone. Instead, a single, ordinary process usually pulls several of them together at once. The clearest example is an industry-specific use case: the API keys a bank gives to its partners.  

When a bank exposes APIs to partners, they authenticate with API keys — long-lived, high-value credentials that, if leaked, can be used to impersonate a trusted partner. India’s rules treat such credentials the way they treat any sensitive secret. The RBI’s IT governance direction expects strong cryptographic controls, restricted access, and audit trails around credentials and the systems that use them. It’s digital payment security direction adds web application firewall and DDoS protection in front of internet-exposed services.  

Exploring the role of Vault

Vault implements that lifecycle as a platform capability, so a single deployment can answer the same control across multiple mandates: 

• Secure storage. Keys and secrets are encrypted at rest inside Vault and never sit in application code or config files, meeting the “stored securely” expectation directly. 

• Rotation. Vault can rotate keys automatically on a set schedule, keeping the old key valid until the new one is fully in use, so you can rotate often without breaking partner traffic. 

• Least-privilege access. Fine-grained policies set exactly which identity can read which secret, so each one reaches only what it needs — the need-to-know rule these frameworks expect. 

• Gateway-fronted, not partner-facing. Partners never touch Vault directly. The API gateway sits in front of it, and one Vault identity serves the whole partner tier, so Vault stays behind the gateway and firewall the rules ask for, and you manage one Vault client instead of one per partner. 

• Tamper-evident audit. Every access and rotation is recorded in Vault’s audit log, giving the “who did what, when” evidence auditors ask for; you can tag each entry with the partner it relates to, without creating a separate identity for each partner. 

Agentic AI security: Extending the controls to non-human identities

AI agents create a familiar security problem in a new form: They are non-human identities that may need credentials, access to sensitive systems, and an auditable record of what they did. 

As regulated organizations begin using agents to retrieve data, call APIs, trigger workflows, or act on a user’s behalf, the same controls already required for people, applications, and API keys need to extend to agents as well. If an agent touches personal data, moves money, or participates in a regulated workflow, organizations need to know which identity was acting, what it was allowed to do, which credentials it used, and how its actions can be traced back to the right user, system, or approval. 

That makes the control questions practical:  

• Who or what is the agent?  

• What is it allowed to access right now?  

• Which credential or secret did it use? 

• What action did it take, and on whose behalf?  

• How can one agent be revoked, contained, or investigated without disrupting the rest of the environment?  

Vault and IBM Verify in the context of agent controls

To help answer the questions, HashiCorp and IBM put together a runtime security pattern organized around four pillars:  

• Identity. Every agent gets its own verifiable identity instead of sharing a service account. Vault hands out short-lived credentials unique to each agent. No standing secrets, and no sharing API keys. 

• Least and runtime containment. Each action is checked when it happens, not waved through in advance. A policy as code check like Sentinel, for example, reviews each action. High-impact ones trigger a step-up approval to the delegating human through Verify before the call is made, and the resulting credential is tied to that one action for that one user. A misbehaving agent can be shut off on its own through Vault without impacting other agents. 

• Traceability. Using standard delegation flows, Verify links every action an agent takes back to the human who asked for it. Nothing the agent does is left untraceable. 

• Observability. With a tamper-evident trail — Vault’s audit log plus Verify’s event log, fed to the SIEM — there’s one place to know which user, which agent, what tool, what intent, and what outcome. 

Organizations don’t need a separate “AI security” program. They need their existing identity, secrets lifecycle, policy, and audit controls — the ones DPDP, CSCRF, and the RBI already require — extended to agents as first-class non-human identities. Same controls, new identity type. 

Beyond Vault: Boundary and Consul

Access and encryption in transit are handled by two other HashiCorp products:  

Boundary provides identity-based access. Where Vault secures the secrets, Boundary secures the path a human or machine takes to reach infrastructure. Access is brokered by identity, credentials can be injected from Vault rather than handed to the user, and sessions are auditable. In plain terms, an operator can connect to a production database without ever seeing the password and without a standing network route to it.  

Consul handles service-to-service networking. A service mesh enforces mutual transport layer security (TLS) between services, encrypting the traffic that moves between your applications and tying each connection to a verified service identity. That covers the part of “encryption in transit” that lives inside systems, not just at the edge, and adds an access control layer at the network level. 

If the goal is to navigate India’s frameworks with a coherent toolset rather than a patchwork, the winning alignment is Vault for secrets and encryption, Boundary for access, and Consul for service networking. 

Next steps

The work of building encryption, tokenization, least-privilege access, audit logging, and residency only needs to be done once. Designed against the common control set, strong secrets and identity strategy can help address multiple regulatory requirements through one coherent operating model.  

If you’d like help applying this to your environment, talk to the team at HashiCorp. 

Related resources 

• HashiCorp Vault 

• Vault transit secrets engine (encryption as a service) 

• Vault transform secrets engine (tokenization and masking — Enterprise/HCP) 

• Vault policies and access control 

• Support regulatory compliance with Vault 

• HCP Vault Dedicated logs and metrics 

• HashiCorp trust and compliance center 

• Agentic runtime security: Solving agentic AI identity and access gaps 

• Announcing native AI agent support in HashiCorp Vault 

• SPIFFE: Securing the identity of agentic AI and non-human actors 

• HashiCorp Boundary 

• HashiCorp Consul 

 

Disclaimer: Clients are solely responsible for assessing and meeting their own legal, regulatory, and compliance obligations. IBM does not provide legal advice, and no IBM product, service, or statement should be construed as guaranteeing compliance with any law, regulation, or regulatory requirement.  

No product or system is completely secure; IBM does not warrant immunity from malicious or illegal conduct.  

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

US Becomes Top Target in RMM Phishing Campaign Spanning 46 Countries

An RMM phishing campaign initially associated with Canadian targeting due to its use of Canada Revenue Agency (CRA) tax forms as lures has turned out to be part of a broader campaign spanning 46 countries.

Around 45% of observed activity was associated with the United States, making it the campaign's top geographic target. ANY.RUN research connected 601 cases to the wider operation, which uses fake documents to trick victims into installing legitimate remote monitoring and management (RMM) software.

The attackers adapt their lures to different targets, using shipping and UPS communications, Adobe PDFs, tax notices, US Social Security Administration themes, invoices, and other documents. Rapidly rotated, disposable Vercel infrastructure makes the campaign harder to track and detect.

US-First Threat with Daily Infrastructure Rotation

Threat overview by ANY.RUN

The campaign’s infrastructure changes significantly faster than its attack pattern. ANY.RUN researchers identified 425 kit URLs across 240 hosts, 94% of which were observed for only a single day.

The operation has used Vercel, GitHub Pages, Netlify, compromised websites, and other infrastructure for delivery. Payloads have also been staged through services including Amazon S3, Cloudflare R2, GitHub, DigitalOcean Spaces, Dropbox, and GoFile.

Despite this rapid rotation, the phishing kit leaves more persistent fingerprints. Shared assets such as font1.woff2, recurring image resources, and the secure.html → project/*.zip delivery structure helped researchers connect otherwise separate infrastructure to the same campaign.

Education, technology, and government are among the top targeted industries. Banking, finance, and manufacturing are also prominently present.

Attack chain overview by ANY.RUN

Individual domains and RMM products are disposable, while the underlying delivery chain is more stable. This shows why detection cannot depend solely on malware verdicts, reputation, or individual IOCs.

To detect these patterns and distinguish legitimate RMM use from abuse, SOC teams need access to the full behavioral context behind suspicious activity.

Respond faster and reduce risk in your company with deeper visibility and intel from 16K+ organizations. Power your SOC with ANY.RUN

Key Detection Takeaways for SOC Teams

• Build a product-agnostic defense: legitimate software can be abused and switched between vendors, leading to visibility gaps. Maintain focus on delivery chain and unauthorized remote-access activity.
• Detect around campaign patters: Instead of relying only on domains, which in this campaign get rotated daily, prioritize more stable kit indicators, including the fmtt / font1.woff2, icons8-microsoft-word-94.png asset, and the secure.html → project/*.zip chain.
• Establish mail-layer controls and raise user awareness: SOC teams should account for password-protected archive delivery.
• Give analysts behavioral and threat context: ANY.RUN's Interactive Sandbox exposed the campaign's browser activity, scripts, processes, downloads, and network behavior, while Threat Intelligence Lookup connected persistent indicators to related infrastructure and cases.

One of the lures, an Adobe phishing page, analyzed within ANY.RUN Interactive Sandbox

As attackers increasingly combine legitimate software, trusted services, and disposable infrastructure, security teams need to access and operationalize in-depth threat context.

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/3VjaEyX
via IFTTT

Attackers Expose Ongoing AI Tool Use Targeting Organizations in Latin America

Executive Summary

We have analyzed two ongoing, multi-stage network intrusion and data-exfiltration campaigns targeting organizations in Latin America. Corroborating recent findings from the broader threat intelligence community, we observed attackers leveraging artificial intelligence (AI) to enhance their capabilities.

Our investigation categorizes this activity as follows:

• Mexican transportation campaign: This campaign impacted a transportation organization, alongside federal government ministries and municipal water utilities in Mexico and Ecuador. Operators relied on living-off-the-land (LotL) techniques. They executed iterative batch scripts to manipulate and exfiltrate sensitive data, and self-hosted NextChat instances on operational infrastructure. We track the activity in this cluster as CL-CRI-1131.
• Brazilian financial campaign: Attackers targeted the Brazilian financial sector. We observed an expansion of previously reported targeting of vulnerable web servers in a job-themed phishing campaign. The attackers employed custom remote access Trojans (RATs) and tunneling tools, including a Go-based SOCKS5 proxy with iterative filenames that suggest AI-enablement. We track the activity in this cluster as CL-CRI-1163.

We track them as two separate activity clusters with distinct geographic focuses. However, the technical and behavioral overlaps between CL-CRI-1131 and CL-CRI-1163 highlight shifting trends in Latin American targeting and threat actor tooling.

Both clusters have overlapping SOCKS5 relay infrastructure and they both rely on AI to orchestrate operations via commercial large language models (LLMs). This signals a broader evolution in the regional threat landscape. Rather than isolated incidents, these clusters demonstrate how diverse threat groups in Latin America are independently adopting advanced proxy networks and AI integration to streamline their execution.

Palo Alto Networks customers are better protected from the threats discussed here through the following products and services:

• Advanced WildFire
• Advanced URL Filtering and Advanced DNS Security
• Cortex XDR and XSIAM

If you think you might have been compromised or have an urgent matter, contact the Unit 42 Incident Response team.

Related Unit 42 Topics

AI, LLM, Phishing, RATs

CL-CRI-1131: Mexican Transportation Campaign

During an April 2026 compromise, the attacker’s host-based operations reflected the trial and error of LLM usage. Infrastructure associated with the campaign persisted into June 2026 and exposed targeting profiles of the attacker.

Initial Host-Based Footprint: Execution Challenges

During an intrusion as part of CL-CRI-1131 activity in April 2026, we observed the attacker struggling to gather sensitive data. After repeated attempts to dump the Security Account Manager (SAM) registry hive and the domain controller NTDS.dit file, the attacker created shadow copies across multiple drives before copying files, as shown in Figure 1.

Figure 1. Volume shadow copy manipulation.

This occurred while the attacker used a series of numbered batch scripts to collect sensitive data from the compromised host, as shown in Figure 2.

Figure 2. Commands used for a series of batch scripts to collect sensitive data.

The attackers inserted a permissions check to ensure successful file writing to the collection directory. These trial-and-error actions and successive script fixes are consistent with LLM usage.

After struggling to collect these files, we observed attackers troubleshooting connectivity with infrastructure at 62.171.185[.]97.

Infrastructure Analysis: Tracing Exfiltration Commands to Exposed Certificates

Pivoting on 62.171.185[.]97, the IP address used in CL-CRI-1131 activity for data exfiltration, we discovered an active Let's Encrypt TLS certificate using the domain m-doxa-apodo.duckdns[.]org and following a unique dynamic DNS naming standard.

Shared Infrastructure: What the SSL Certificates Revealed

Searching for the m-doxa prefix revealed that attackers established the infrastructure for the campaign in February 2026 using a single, consolidated multi-Subject Alternative Name (SAN) certificate. This single certificate reveals five active subdomains. These subdomain names indicate their operational functions and intended Mexican federal government targets, as Table 1 shows.

Subdomain	Interpretation
m-doxa-apodo.duckdns[.]org	apodo = alias/nickname (Spanish)
m-doxa-geo.duckdns[.]org	geo for geolocation
m-doxa-intel.duckdns[.]org	intel for intelligence
m-doxa-vacunas.duckdns[.]org	vacunas = vaccines (Spanish)

Table 1. Subdomains and their likely operational capabilities and targets.

In February 2026, following the initial window of activity reported by CloudSEK, attackers deployed a single-SAN certificate during this campaign. The certificate was configured to secure only one specific domain: m-doxa-apodo. However, as the operation evolved, so did the infrastructure.

By April 2026, and again in June 2026, attackers rotated their infrastructure and generated new multi-SAN certificates.

Table 2 shows, by date, the certificates and hosts used for CL-CRI-1131 activity, demonstrating a timeline for the associated infrastructure.

Date	Certificate SHA-256 Hash	SANs	Host
Feb. 27, 2026	7d766942ef34542cee39c852286599958c4c2e23187010c4d38dbf88fcb40bf8	1	165.22.184[.]26
April 20, 2026	4e218e70afdbb116209ec0ebe8fc556e296e69648aa4e0425b83c0e863a8fee5	5	178.128.87[.]160
June 19, 2026	46ac289ce0c13666de616446f5d5a68da8bd150f4f065c3bec02f63776d3899c	5	178.128.87[.]160

Table 2. Certificate procurement timeline.

AI Integration: Discovering the Backend Troubleshooting Interface

In a previous report by Gambit, The AI-Assisted Breach of Mexico’s Government Infrastructure [PDF], the February 2026 activity was notable for using multiple LLMs. The report by CloudSEK linked above detailing activity from June 2026 tracks the activity we call CL-CRI-1131 as Operation Escaneo.

These reports describe attackers using multiple LLMs, including Claude and GPT-4.1 to troubleshoot issues faced by the attackers across their campaigns. We discuss the attackers using NextChat as part of their broader LLM process.

The IP address 178.128.87[.]160 was used in CL-CRI-1131 activity during the associated April and June 2026 compromises. This address hosted an instance of the open-source tool NextChat on TCP port 3000. Figure 3 shows an example of the associated NextChat user interface, as it would look from a web browser window.

Figure 3. Example of a locally hosted NextChat window.

NextChat is an open-source web interface where users can load and interact with multiple models. NextChat allows operators to compare across models and ensure prompts are hosted on attacker-controlled infrastructure.

Beyond revealing new targets, tracking this infrastructure provided a critical window into the activity cluster's backend operations. Given the initial failures to extract data from the host combined with the NextChat interface on this backend, we assess that the attackers relied on LLMs to generate the required workaround scripts.

Integrating AI into the operational infrastructure is not unique to this incident. We observe an identical technical setup when pivoting to a secondary campaign targeting the Brazilian financial sector.

CL-CRI-1163: Brazilian Financial Service Campaign

Unlike the Mexican transportation campaign, the Brazilian financial campaign we track as CL-CRI-1163 involved homebrewed malware. We observed that the attackers behind CL-CRI-1163 likely gained initial access through a job-themed phishing compromise.

Despite trading built-in Windows utilities for custom-built implants, the underlying operational shift remains consistent in both campaigns. Exposed staging infrastructure revealed operational scripts with filenames that suggest an LLM dynamically generated them rather than a human developer.

The apparent presence of this AI setup, deployed alongside advanced proxy networks, reinforces the conclusion of a broader regional trend. Even for attackers capable of deploying custom malware, an AI-driven backend serves as a force multiplier to populate directories with exploit scripts, streamline execution and lower the barrier to entry for managing complex post-exploitation workflows.

Initial Access and Execution: Phishing and Automated Actions on Objectives

In February 2026, we observed that attackers associated with CL-CRI-1163 achieved initial access through a resume-themed phishing email attachment.

After attackers dropped multiple RATs, we observed a similar iterative naming structure, likely due to the attackers' failure to install their tool set. We observed attempts to install versions 1–8 of a Go-based reverse SOCKS5 tunneling tool named SockTz from a compromised WordPress site.

Figure 4 shows the attempt to execute version 8, named socktz_v8.exe.

Figure 4. Attempt to retrieve SockTz version 8 from a compromised WordPress site.

Likely due to failure to install the SockTz malware and open a successful proxy connection, attackers behind CL-CRI-1163 pivoted to attacker-controlled infrastructure to retrieve version 9, named socktz_v9, as Figure 5 shows.

Figure 5. Pivot to attacker-controlled infrastructure to retrieve SockTz version.

Infrastructure Inspection: Analyzing AI-Generated Naming Conventions in the Open Directory

Researchers previously identified this SockTz proxy tool and 167.148.195[.]53 tied to persistent targeting of vulnerable JBoss servers. Where previous reports identified different versions of this tool across campaigns, we observed installation attempts of versions 1–9 in a two-hour window.

SockTz installers were hosted along with hundreds of campaign scripts on an open directory at 167.148.195[.]53. Similar to the SockTz version numbers and the CL-CRI-1131 operations, the open directory associated with this CL-CRI-1163 activity exposed iterative scripts with appended identifier _output, indicating the attackers employed LLMs throughout the campaign. A partial list of the files is shown in Figure 6.

Figure 6. Partial list of the campaign scripts hosted on an open directory at 167.148.195[.]53.

In addition to exposing scripts across multiple phases of the attack chain, attackers appended exploit filenames with descriptive adjectives. This suggests that the attackers employed iterative, language model-driven development:

exploit_creative.py, exploit_careful.py

and

rce_focused.py

.

The threat actors behind the CL-CRI-1131 and CL-CRI-1163 campaigns have enhanced their technical capabilities by incorporating commercial LLMs into their workflows. This integration enables them to author advanced proxy configurations and dynamically address complex execution failures. However, the infrastructure they deployed to leverage this AI became their Achilles' heel.

Exposing an open NextChat directory to the public internet reveals a fundamental lack of operational maturity. The AI provided the necessary tactical workaround to extract the Active Directory database, but the human operators failed to secure the staging server. This left their entire playbook, prompt history and staging scripts visible to threat researchers.

This highlights a critical vulnerability for defenders to exploit. As less skilled and experienced actors adopt AI to accelerate their attacks, their foundational operational security (OpSec) failures remain the most reliable way to track and dismantle their operations.

Conclusion

The CL-CRI-1131 and CL-CRI-1163 operations orchestrated in the Mexican transportation and Brazilian financial sector campaigns highlight a notable evolution in the regional threat landscape. Through these campaigns, we observe attackers leveraging AI to enhance their capabilities.

Whether manipulating built-in Windows utilities or deploying custom-built proxy networks, these operators rely on commercial LLMs to overcome tactical hurdles and streamline their execution. However, this rapid technical acceleration is offset by fundamental operational security failures. Exposed staging directories, unsecured NextChat interfaces and structured multi-SAN certificates provide defenders with a clear roadmap of the attacker's infrastructure.

By pivoting on these OpSec oversights, defenders can proactively track the activity and disrupt the attackers' campaigns.

Palo Alto Networks customers are better protected from the threats discussed above through the following products:

• The Advanced WildFire machine-learning models and analysis techniques have been reviewed and updated in light of the indicators shared in this research
• Advanced URL Filtering and Advanced DNS Security identify known domains and URLs associated with this activity as malicious.
• Cortex XDR and XSIAM are designed to help prevent the threats described in this article, by employing the Malware Prevention Engine. This approach combines several layers of protection, including Advanced WildFire, Behavioral Threat Protection and the Local Analysis module, intended to prevent both known and unknown malware from causing harm to endpoints.

If you think you may have been compromised or have an urgent matter, get in touch with the Unit 42 Incident Response team or call:

• North America: Toll Free: +1 (866) 486-4842 (866.4.UNIT42)
• UK: +44.20.3743.3660
• Europe and Middle East: +31.20.299.3130
• Asia: +65.6983.8730
• Japan: +81.50.1790.0200
• Australia: +61.2.4062.7950
• India: 000 800 050 45107
• South Korea: +82.080.467.8774

Palo Alto Networks has shared these findings with our fellow Cyber Threat Alliance (CTA) members. CTA members use this intelligence to rapidly deploy protections to their customers and to systematically disrupt malicious cyber actors. Learn more about the Cyber Threat Alliance.

Indicators of Compromise

Mexican Transportation Campaign

Domains:

• m-doxa-apodo.duckdns[.]org
• m-doxa-geo.duckdns[.]org
• m-doxa-intel.duckdns[.]org
• m-doxa-repuve.duckdns[.]org
• m-doxa-sre.duckdns[.]org
• m-doxa-vacunas.duckdns[.]org

Certificate SHA-256 Hashes for Fingerprints and Corresponding Hosts:

• 46ac289ce0c13666de616446f5d5a68da8bd150f4f065c3bec02f63776d3899c
  • 178.128.87[.]160
• 4e218e70afdbb116209ec0ebe8fc556e296e69648aa4e0425b83c0e863a8fee5
  • 178.128.87[.]160
• 7d766942ef34542cee39c852286599958c4c2e23187010c4d38dbf88fcb40bf8
  • 165.22.184[.]26

Brazilian Financial Campaign

SHA-256 hashes:

• a38b2cf8beff32a276eed8783723ecf8cc53d7dc88669e1b998dddc4db6fe996
• 87bf8bc8b4a2cf34f0af1afe161f123a3d200e77f6c6f41b81bf6ae66ee172ec

URL:

• hxxp[:]//167.148.195[.]53:8888/socktz_v9.exe

Additional Resources

• Operation Escaneo — CloudSEK
• Vibe Hacking: Two AI-Augmented Campaigns Target Government and Financial Sectors in Latin America — Trend Micro

from Unit 42 https://ift.tt/xdnTbAo
via IFTTT

Shai-Hulud's Reach Just Grew to 469 Credential Locations. Here's What That Means

In early August, GitGuardian researchers found that a recent Shai-Hulud infostealer worm variant had evolved to scan for credentials across 469 locations across developer environments, Continuous Integration/Continuous Deployment (CI/CD) tooling, cloud configurations, and even AI tool configs.

Earlier variants of the infostealer worm only checked 189 paths. The jump says a lot. Attackers have stopped trying to break trust relationships and started using the credentials that already make those relationships work.

Software supply chains have always depended on trust.

Developers trust package registries. Organizations trust maintainers. CI/CD systems trust the credentials and identities they're given. Applications trust the dependencies they pull down during a build.

Attackers realized they don't need to break any of that. They just needed to find where the credentials and standing privileges already sit.

This is what is driving the current focus on software supply chain defense across multiple ecosystems. Protecting package registries and dependencies still matters, but the core of the problem, the actual required element for infostealer worms to succeed, sits underneath those systems.

Attackers are hunting for reusable authority. Preventing the next Shai-Hulud starts with addressing and securing the credential layer.

Shai-Hulud turns stolen credentials into an ongoing supply chain attack

Shai-Hulud belongs to a growing class of supply chain attacks that search compromised environments for credentials they can use to continue the attack.

A token found on a developer workstation might open access to source code. That same code likely contains cloud credentials, which would grant access to the infrastructure. A GitHub token might allow write access to additional repositories. A package publishing credential can let an attacker publish software through a channel developers already trust. Credentials become the connective tissue between one compromised environment and the next.

The broader ecosystem has already seen how direct that path can be. A quick scan of any security industry news site or info feed will surface a never-ending supply of stories about new infections across multiple languages, package managers, and operating systems.

Credential harvesting gives attackers somewhere to go next

Modern developer environments contain far more authentication material than the source repository alone. Credentials show up in expected places, like .env files, shell history, and package-manager configuration. But there are also secrets in CLI caches, CI/CD configurations, and IDE settings. Increasingly, teams are finding access keys in the configuration used by AI development tools.

This is why credential-harvesting malware creators keep broadening the search radius. The attacker doesn't necessarily know which credential matters most before collection begins. It can gather what's available and sort out what each credential unlocks afterward.

Defenders should work the problem in the opposite direction. Security teams must identify which credentials matter most and address their exposure before an attacker gets the chance to use them.

The power to publish creates a path to propagation

Package publishing credentials deserve special attention because they turn credential theft into software distribution, forward propagating the attack.

Tokens that developers use to publish carry authority over a trusted package that other developers, build systems, and organizations will automatically consume. That trust is what attackers abuse. This creates an obvious first priority for defenders: to reduce the number of standing publishing credentials available to steal.

Organizations need to cut their dependence on long-lived publishing tokens. We should encourage all software makers to adopt short-lived, verified authentication via OpenID Connect (OIDC) or similarly scoped mechanisms. Docker and GitHub Actions' recent updates have pushed the ecosystem further in this direction, including stronger authentication and greater use of trusted publishing.

Any long-lived publishing credential that remains should be treated as highly sensitive infrastructure.

Credentials connect systems security teams manage separately

Security teams traditionally think about their orgs in terms of security types: source control security, CI/CD security, cloud security, endpoint security, and application security. Credentials span all of these divisions and separation-of-duties requirements. A single developer can authenticate to GitHub, npm, AWS, Kubernetes, internal APIs, and build infrastructure in one normal day, and CI/CD pipelines often carry an equally diverse set.

A credential left in a developer environment can represent authority somewhere completely different. The file might sit on a laptop while the credential controls a cloud resource or might grant package publication rights.

Where a secret is discovered only tells part of the story. Organizations working towards secrets management maturity also need to know whether the credential is valid, what identity it belongs to, what system accepts it, what privileges it carries, which environment it reaches, and who owns its remediation.

That turns secrets detection into credential risk management.

Not every exposed secret creates the same risk

A list containing 100,000 secret findings does not represent 100,000 equally urgent incidents.

Some credentials are already invalid. Others reach disposable development environments. A smaller number provide access to production databases, cloud infrastructure, deployment systems, or package publication. Treating those findings identically builds queues instead of reducing risk.

A useful remediation strategy starts by asking what an attacker would choose first. The answer provides a practical order of operations.

Priority one: remove package publishing keys from cleartext

This is the key action a developer and team need to pursue to stop Shai-Hulud variants and other infostealer worms. Organizations maintaining packages should identify where publishing tokens exist and determine whether standing credentials are still necessary. That search needs to extend beyond repositories.

Find publishing credentials wherever developers and pipelines leave them

Too often, package authors write authentication keys to local configuration files as part of normal workflows. But a secret doesn't need to have been committed to Git to be available to malware running on the developer machine. It's also why recent supply chain attacks increasingly target the working developer environment itself.

Security and development teams need visibility into where package publishing credentials actually accumulate, followed by a plan to remove them.

Replace standing publishing credentials where possible

The hardest publishing credential for an attacker to steal is one that does not exist. But if they must exist, the shorter the window access can be granted, the better.

The goal is always to eliminate reusable publishing authority sitting in cleartext. Organizations should move package publishing toward short-lived, identity-backed mechanisms wherever supported. OIDC-based trusted publishing is one example. Most cloud platforms are moving towards federated security token services like AWS STS, allowing for workload verification across platforms where you would be pushing artifacts. This area is always evolving in each package tooling ecosystem as well.

Static credentials that can't yet be replaced need tighter controls. They should be discoverable, validated, owned, monitored, and rotated when exposure occurs.

This effort sits naturally between development and security. Developers understand how packages get built and released while security teams set policy and identify credential exposure across those workflows.

Neither side can solve it alone.

Priority two: remove exposed production credentials

Stopping the propagation path halts the spread of the infection but does not stop the bleeding. After publishing credentials, organizations should focus on credentials that provide access to critical production systems. This is where credential remediation becomes risk management.

An exposed credential tied to an isolated development environment might create limited damage. A valid credential with write access to production infrastructure is a different incident entirely.

Each organization should have its own hierarchical view of what constitutes mission critical, but a good short list might be:

• Production cloud accounts
• Databases containing customer information
• Signing infrastructure
• Kubernetes clusters
• Deployment tooling
• Administrative interfaces

The question to ask is "what happens if an attacker does something malicious with stolen access?" Validity is a very useful filter here. Determining the true blast radius will help you prioritize which systems to address to eliminate long-lived secrets, or at least which to rotate secrets for.

Shared credentials create hidden paths between environments

Environment boundaries also blur when credentials get reused. A credential discovered in staging may still authenticate against production. A token copied into a developer's local environment may retain privileges meant for automation. The same credential may show up across multiple systems long after its original purpose has been forgotten.

Finding the secret is only the first step. The alerts are just noise if they do not map it back to the identity, privileges, resources, environments, and owners behind it. Multiple teams, including DevOps, platform, Identity and Access Management (IAM), and security, each hold a piece of that picture, and remediation needs to bring those pieces together.

Priority three: rank every remaining exposed secret by risk

Once package publishing and obvious production access are handled, organizations can work systematically through the remaining credential inventory. The goal isn't to rotate everything at random. It's to build an action plan that continuously removes the most useful credentials from an attacker's path.

Validity is a good place to start, but not the whole story

A valid credential deserves more immediate attention than one that's already expired or revoked. At scale, that distinction matters enormously: GitGuardian's State of Secrets Sprawl research found 28.65 million new hardcoded secrets added to public GitHub commits in 2025 alone, a 34% year-over-year increase.

Volumes at that scale make manual triage unrealistic. Organizations need to determine which findings still represent usable authentication and move those toward the front of the queue.

Validity alone still doesn't tell the whole story. A valid credential for a shared development service deserves attention. A valid credential with administrator access to a production cloud account deserves considerably more.

Useful prioritization adds context:

• Is the credential still valid?
• Does it reach production, staging, or development?
• What identity does it represent?
• What privileges does that identity have?
• Which resources can it access?
• Where else is the credential being used?
• Who owns the credential and can rotate or revoke it?

Working to make sure you have answers that can be audited turns an overwhelming list of leaked secrets into an actual remediation plan.

Credential risk reduction requires a repeatable program

This newest wave of Shai-Hulud attacks, or any variants of it, should do more than trigger a one-time credential cleanup exercise.

Credentials will likely continue to accumulate as developers keep building software, services integrate with one another, pipelines evolve, and new tools enter the environment. The response needs to become a repeatable cycle.

Organizations first need broad visibility into what they have. A single inventory of all credentials. That includes source code and Git history, but modern attacks make the case for looking further, into the CI/CD systems and developer environments where authentication material accumulates.

Detection should answer a simple question: where does reusable authority currently exist? This needs to be auditable, and not simply reflect the 'known" secrets already vaulted. The percentage of secrets that exist outside the vault is a very important metric when addressing secrets security at scale. Remediation plans without a way to account for those orphaned, plaintext secrets are doomed to fail.

The next step is prioritization. As we have laid out in this post, any publishing credentials and valid production credentials belong at the top of your list. Remaining secrets need to be ranked using validity, environment, identity, privilege, ownership, and other available context. Remediation then moves through a manageable queue instead of an undifferentiated backlog.

Prevent standing credentials from rebuilding the attack path

Finally, organizations need to stop the same credential layer from rebuilding itself. That means blocking new hardcoded secrets, moving workflows toward short-lived credentials where possible, protecting credentials in developer environments, and catching new exposure before it becomes another large remediation project.

"Detection, remediation, and prevention" need to be seen as an ongoing cycle, not an emergency response triggered after an attack.

The next Shai-Hulud wave should find fewer credentials to steal

The next Shai-Hulud variant will almost certainly look somewhere new, expanding past that 469 number we started with. Attackers will keep adding paths and developer tools to their search because they have learned that modern software environments are full of reusable authority.

We are not going to win that race by memorizing every place the next infostealer might look. We win by removing standing privilege and eliminating exposed credentials everywhere they exist.

That is why the credential layer deserves to be treated as its own security problem. Detect where reusable authority exists. Remediate the credentials that create the most risk. Prevent that exposure from accumulating again.

Our goal should be to ensure that every time a new worm arrives, there are fewer findable keys to abuse.

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

Apache CloudStack 4.23 – Release Overview

Apache CloudStack 4.23 is a regular feature release. It contains 11 new features, around 22 improvements and more than bug fixes since 4.22.1.0, from 169 merged pull requests and 223 resolved items in the 4.23.0 milestone. It advances the platform in four areas: making networking extensible and self-service, strengthening security and identity at the volume and platform level, broadening enterprise storage support for KVM, and maturing data protection for organisations moving away from VMware. It builds on 4.22 and continues to harden day-to-day operations for administrators.

Networking gains a DNS Framework with pluggable providers, network orchestration extensions that can drive external systems, firewall rules on VPC public IPs, and more efficient public IP usage through VPC conserve mode. Security and identity add KMS-backed volume encryption, a restructured API key pair model with per-key permissions and validity, per-domain OAuth providers, and wider vTPM coverage. On the storage side, a modernised CLVM stack and a new NetApp ONTAP plugin bring enterprise block storage to open-source KVM. Data protection gains a native backup provider that writes to secondary storage, and incremental backups for NAS-based backup and recovery. The sections below cover each feature.

Storage

Modernised CLVM Support for KVM Block Storage

Apache CloudStack 4.23 reworks CLVM-based primary storage for KVM, making it a more reliable and production-ready block storage option for environments using iSCSI, Fibre Channel, or similar shared storage. The updated implementation improves cluster-safe operations through proper locking, and introduces a new generation CLVM stack (CLVM_NG) designed to align with modern Linux LVM capabilities. Where CLVM places RAW images on LVM, CLVM_NG places QCOW2 on LVM.

The volume lifecycle is more consistent and predictable across create, attach, detach, and delete operations. CLVM_NG adds live migration, hypervisor-level volume encryption, and support for full volume snapshots.

Two scope limitations are worth noting for planning. Incremental snapshots were removed from the scope of this release, and VM (instance) snapshots on CLVM_NG are not yet supported, being targeted for a future release. Deployments that depend on instance snapshots should continue to use the existing CLVM stack.

Taken together, these changes reduce operational edge cases and improve stability across multi-host clusters, which matters most for workloads that rely on shared block storage during a move from legacy or VMware-based environments to open-source infrastructure.

NetApp ONTAP Storage Plugin

A new primary storage plugin integrates NetApp ONTAP directly, rather than presenting ONTAP capacity through a generic protocol and losing visibility of the array. CloudStack manages ONTAP-backed primary storage itself, and storage operations initiated in CloudStack are carried out through the array’s own interfaces.

The integration covers the full storage pool lifecycle (create, delete, enable, disable, and entering or cancelling maintenance mode) as well as volume operations on ONTAP-backed pools, so volumes are provisioned and managed as part of normal instance workflows. Because the plugin sits behind the standard CloudStack primary storage abstraction, ONTAP pools appear alongside other primary storage types and are consumed through the same APIs and UI screens operators already use.

For organisations standardised on NetApp, this removes an obstacle to running CloudStack on existing storage investments, particularly where a VMware migration is underway and ONTAP is already the storage platform of record.

Configurable Template Replica Counts on Secondary Storage

New configuration keys control how many secondary storage replicas are created for public and private templates. In zones with several secondary storage stores, templates were replicated according to fixed internal behaviour, with no way to express that a heavily used public template deserves broad replication while a rarely used private template does not.

Replica counts can now be set separately for public and private templates, so replication policy follows actual usage. Widely consumed public templates can be placed on more stores to spread deployment load and improve resilience, while private templates belonging to individual accounts can be kept to fewer copies to conserve capacity.

Operators therefore get a direct lever over the trade-off between secondary storage consumption, deployment performance, and redundancy, which previously could only be influenced indirectly. In large multi-zone or multi-store environments, where template data can account for a substantial share of secondary storage, both the capacity saved and the change in deployment behaviour are measurable.

Data Protection

KVM Backup on Secondary Storage (KBOSS)

KBOSS (KVM Backup on Secondary Storage) is a native backup provider that stores virtual machine backups directly on CloudStack secondary storage. Protecting KVM workloads has generally meant integrating a third-party backup and recovery product, with the licensing, infrastructure, and operational overhead that comes with it. For smaller environments, and for operators who wanted backup without adopting an external appliance, that was often the reason there was no backup strategy at all.

KBOSS uses the secondary storage a CloudStack zone already has. It supports both full and incremental backups, so repeated backups of the same instance do not require repeated full copies, and it also supports compression and integrity validation of backup data. It plugs into the existing backup and recovery abstraction in CloudStack, covering backup offerings, schedules, and restore workflows, so it is configured and consumed the same way as any other provider through the API and UI.

This release also introduces a configurable allowed-provider list, giving operators explicit control over which backup plugins, third-party ones included, may be enabled.

Native data protection is therefore available to any KVM deployment with nothing additional to procure or maintain. Service providers get a backup capability they can offer without a partner dependency, and backup data stays within infrastructure the operator already controls.

Incremental Backups for NAS Backup and Recovery

The NAS backup and recovery provider for KVM now supports incremental backups. Every NAS backup was previously a full copy of the instance’s disks, so backup storage consumption and backup windows grew with retention, which made frequent schedules impractical outside small environments.

The provider now maintains backup chains: an initial full backup followed by incremental backups capturing only the changes since the previous point in time. Less data is written to the NAS target and each job takes less time, so recovery point objectives can be tightened without a proportional increase in storage. Restores continue to run through the standard CloudStack backup and recovery workflows, with the provider resolving the chain internally.

NAS-based data protection is therefore viable at a scale where it previously was not, while still using ordinary NFS or CIFS storage that operators already have. Together with KBOSS, KVM deployments now have two native paths to data protection, chosen on whether backups should live on secondary storage or on a dedicated NAS target.

Networking

DNS Framework

Apache CloudStack 4.23 brings DNS management into the platform. Users can manage DNS zones and records directly from CloudStack while integrating with external providers, starting with PowerDNS. The framework uses a plugin-based approach, so additional DNS backends can be integrated later through the same interface.

DNS servers, zones, and records become first-class resources, exposed through both the API and the UI. Users can register DNS providers, create domains associated with accounts or projects, and create, list, and remove records. Associating a DNS zone with a network lets CloudStack create, update, and remove records automatically in response to VM lifecycle events and IP assignments, which removes the manual DNS steps that usually sit alongside instance provisioning.

For service providers, DNS management inside the same portal, scoped to the tenant’s own account, is a self-service capability that previously meant sending customers elsewhere.

Network Extensions

The XaaS Extensions Framework now covers network lifecycle orchestration. CloudStack can integrate with external networking systems and delegate work during lifecycle events such as network creation, preparation, and teardown, which takes networking beyond the built-in providers.

A network extension registers against a Physical Network, a broader scope than the cluster-level registration used previously, and operates across all network types: Isolated Networks, VPCs, L2, and Shared Networks. By hooking into lifecycle stages, extensions let CloudStack coordinate with external systems such as Linux-based networking or SDN controllers while remaining the orchestration layer.

This makes it possible to support custom networking implementations without modifying CloudStack core, and without carrying a fork. Networking now follows the same extensible model already available for compute and workloads.

VPC Conserve Mode

Conserve mode now applies to VPC environments, allowing more efficient use of public IP addresses across tiers and services. Previously a public IP was limited to a single VPC tier, and the Source NAT IP could not be reused for services such as load balancing or port forwarding. With conserve mode enabled on the VPC offering, and on the network offering used by the VPC tier, the same public IP including the Source NAT IP can be reused across multiple services and tiers.

This simplifies network design and reduces the number of public IPs needed to expose applications. It also lowers the entry barrier for adopting VPCs, particularly where IP address availability is limited or billed. In aligning VPC behaviour more closely with isolated networks, CloudStack offers a more consistent networking model across network types.

Firewall Support for Public IPs in VPC

Firewall rules can now be applied directly to public IP addresses within a VPC, closing a long-standing gap between VPCs and isolated networks. Traffic filtering in a VPC previously had to be expressed through network ACLs applied at the tier level, which made it awkward to control access to a specific public IP or to protect services exposed through port forwarding and load balancing. Ingress and egress rules can now be defined against a VPC public IP using the same model administrators and users already know from isolated networks.

The feature applies to public IPs associated with a VPC, including those used for port forwarding and load balancing, and is exposed through both the API and the UI. Rules are managed per IP address, so access to a given service can be restricted without reshaping the ACLs of the entire tier. This matters more now that conserve mode allows one public IP, Source NAT included, to serve several services and tiers: the firewall rule is the natural place to express access control for a shared address.

Security configuration is therefore consistent across network types, which reduces the amount of VPC-specific knowledge needed to secure an environment. Teams migrating from isolated networks to VPCs carry their existing firewall practice over unchanged, and service providers get a clearer per-IP boundary for exposing multi-tier applications.

Security and Identity

KMS Support for Encrypted Volumes

Volume encryption keys no longer have to live on the Management Server. Apache CloudStack 4.23 introduces Key Management Service (KMS) support for volume encryption, with integration to external key management systems including HSM-backed solutions, and a built-in database-backed option for simpler deployments. Operators can separate key custody from infrastructure control without changing existing provisioning workflows.

The implementation follows an envelope encryption model. Data Encryption Keys (DEKs) are generated per volume and wrapped using centrally managed KMS keys (KEKs). Only the wrapped keys are stored in CloudStack, and operations such as wrapping and unwrapping can be delegated to external systems. Key lifecycle management is part of the feature, covering versioning and rotation as well as migration of existing passphrase-encrypted volumes to KMS, so encryption keys can be updated over time without disrupting running workloads.

This addresses environments where strict control over encryption keys is required. It supports deployment models ranging from the built-in provider to external HSMs, and existing encryption mechanisms continue to work as before.

API Key Pair Restructure

API keys are now a first-class resource. Instead of a single key pair per user, users can hold several at the same time, each with its own set of permissions and its own validity interval. Distinct credentials can be issued for distinct purposes, such as automation pipelines, monitoring systems, and third-party tooling, and each one can be reasoned about independently.

Because each key pair carries its own permissions, a credential used by a monitoring integration can be limited to read operations while an orchestration pipeline receives only the API commands it actually calls. Key pairs can also be given a start and end date, so credentials expire automatically rather than living indefinitely until someone remembers to rotate them. Creating, listing, and removing key pairs is available through the API and, as of this release, through a dedicated management interface in the UI.

The effect on credential hygiene is direct. Revoking access for one integration no longer invalidates every other automation a user owns, and least-privilege access becomes practical to implement. For organisations with compliance requirements around credential rotation and scope, this brings the API authentication model in line with what is expected of a cloud platform.

Per-Domain OAuth Providers

OAuth provider configuration moves from global to per-domain. Configuration previously applied to the whole installation, which made single sign-on difficult to adopt in multi-tenant deployments: every domain shared the same identity provider and the same application registration, regardless of who owned the users in that domain.

Each domain can now carry its own OAuth provider configuration for Google and GitHub, so tenants authenticate against the identity provider they already use without affecting other domains on the same installation. This release also adds Keycloak as an OAuth provider, which extends single sign-on to environments running their own identity broker rather than a public provider.

For service providers this turns OAuth into a genuinely multi-tenant capability: each customer domain can be onboarded with its own identity configuration, and delegating authentication no longer costs tenant isolation. For enterprises, Keycloak means single sign-on can be built entirely on self-hosted identity infrastructure.

Keycloak as an OAuth Provider

Apache CloudStack 4.23 adds Keycloak as an OAuth2 and OIDC provider. Single sign-on previously meant Google or GitHub, which suited organisations already using those accounts but ruled out anyone required to keep authentication inside their own perimeter. Keycloak is the identity broker most commonly deployed for exactly that reason, and it can now be used to sign in to CloudStack directly.

Supporting Keycloak required making the provider endpoints configurable, because unlike a public provider there is no fixed URL to hard-code. The OAuth provider model gains two fields, an authorize URL and a token URL, carried through the database, the API, and the UI. Both can be set when registering a provider and changed afterwards, using the register, update, and list OAuth provider APIs, and both are editable in the UI. Registration validates that a Keycloak provider has both URLs before it is accepted. Once registered, Keycloak appears as a sign-in option on the login page.

For enterprises and public sector deployments where identity cannot leave the organisation, this closes the gap that kept single sign-on off the table. Together with per-domain OAuth configuration, each tenant domain can be pointed at its own Keycloak realm, so a service provider can offer single sign-on without every customer sharing one identity provider.

Support for vTPM on XenServer and XCP-ng 8.3/8.4

Virtual Trusted Platform Module (vTPM) support now extends to XenServer and XCP-ng 8.3 and 8.4, matching what is already available on KVM and VMware. Virtual machine instances on these hypervisors can use vTPM devices for secure key storage and platform integrity features inside the guest operating system.

The implementation uses the native capabilities of XenServer and XCP-ng. vTPM devices can be attached during virtual machine deployment, typically together with UEFI boot mode, allowing guest operating systems to use the TPM for disk encryption, secure boot, and attestation with no change to existing provisioning workflows in CloudStack.

With vTPM now available across all major hypervisors, security capability no longer depends on which hypervisor a workload lands on. That helps in heterogeneous environments and for administrators maintaining uniform configurations across hypervisor platforms.

Compute, Kubernetes and Operations

Multiple CD-ROM Devices per VM

A virtual machine can now have more than one CD-ROM device attached, addressing a long-standing limitation where only a single ISO could be mounted at a time. This matters most on KVM, where workflows such as Windows installation need simultaneous access to the OS installer and to additional driver media such as VirtIO drivers.

Users previously had to swap ISOs manually or prepare templates with external tools such as Proxmox or virt-manager, which added complexity and moved part of the workflow outside CloudStack. Multiple ISOs can now be attached either at deployment time or after the instance has been created, each in its own CD-ROM slot.

Template creation and day-to-day instance management are simpler as a result, with fewer steps in common scenarios and less dependency on external tooling. Initial support focuses on KVM, and the design allows for extension to other hypervisors depending on their capabilities and limits.

CKS: Affinity Group Selection at Cluster Creation

Affinity groups can now be selected when a CloudStack Kubernetes Service cluster is created. Placement of control plane and worker nodes was previously left entirely to the allocator, so a cluster intended to be highly available could end up with several of its nodes on the same host.

Affinity groups can now be specified as part of cluster creation, so anti-affinity rules can spread nodes across hosts, or affinity rules can be used where colocation is wanted. The selection is exposed through both the API and the UI as part of the normal cluster creation workflow and applies to the nodes CloudStack provisions on the user’s behalf.

Fault-tolerant clusters can therefore be built without post-provisioning intervention, and Kubernetes cluster placement now uses the same placement controls already available for individual instances.

Scheduled Autoscaling

Autoscaling groups can now schedule their minimum and maximum member counts. Groups have so far reacted to observed conditions such as load, which works for unpredictable demand but is inefficient when demand is known in advance: the group only begins to grow after the load has arrived, and the delay is visible to users.

Capacity boundaries can now change according to a defined timetable rather than only in response to metrics. An operator can raise the minimum size ahead of a known daily peak and lower it again overnight, while metric-based behaviour continues to operate within those boundaries. The underlying VM Schedule framework was refactored to be generic, making it reusable for scheduling beyond individual virtual machines.

Predictable load patterns such as business-hours traffic, batch windows, and seasonal campaigns can therefore be handled before the load arrives rather than after. For service providers, scaling behaviour also becomes explicit and reviewable, which makes autoscaling easier to offer as a managed capability.

Clone and Update Existing Offerings

Offerings can now be cloned and used as the basis for new ones, with broader support for updating offerings after creation. Compute, disk, network, and VPC offerings have historically been largely immutable, so introducing a small variation meant recreating the definition from scratch and re-entering every parameter. With cloning, an existing offering becomes a starting point: administrators duplicate it, adjust what needs to change, and save it as a new offering.

The feature covers the offering types administrators work with day to day and is available through both the API and the UI. This release also widens the set of fields that can be modified on an existing offering, which reduces the number of cases where an offering must be replaced, and existing resources migrated onto a new definition, because one attribute was set incorrectly or needs to change.

For operators managing large offering catalogues, this removes a good deal of repetitive and error-prone work. Variations on an established offering can be produced consistently, without a mistyped parameter quietly changing the behaviour of a service tier.

Availability and Next Steps

4.23 will matter most to teams running KVM at production scale, and particularly to those leaving VMware, where storage, backup, and key custody are usually what decide whether a migration goes ahead. The features above are configured through the standard APIs and UI, so adopting any one of them does not require rebuilding an existing deployment. Upgrade paths, database changes, and the full list of fixes are in the 4.23.0 release notes, and per-feature configuration detail is in the documentation.

The post Apache CloudStack 4.23 – Release Overview appeared first on ShapeBlue.

from CloudStack Consultancy & CloudStack... https://ift.tt/eWdTGf4
via IFTTT