TL;DR: CVE-2023-48022 has moved from ShadowRay-style exploitation into commoditized botnet tradecraft, with established families reusing a missing-authentication flaw in the Ray Jobs API to run arbitrary code, harvest secrets and drive cryptomining, DDoS and exfiltration, according to TXOne Networks research. The practical lesson is that exposed AI infrastructure needs identity, network and runtime controls before attackers turn it into a reusable launchpad.
At a glance
What this is: TXOne Networks says CVE-2023-48022 has been adopted by multiple botnet families, turning exposed Ray Jobs API instances into launch points for code execution, secret theft and secondary payloads.
Why it matters: This matters because AI infrastructure now behaves like any other internet-facing attack surface: identity controls, egress limits and secret handling determine whether a foothold becomes a cluster-wide compromise.
By the numbers:
- Our telemetry shows Q4 2025 total activity reached 803, with 45 in October, 386 in November and 372 in December.
Context
AI infrastructure becomes a security problem when a management API is reachable from the internet and can drive distributed jobs, data access or code execution. In that setting, authentication, network exposure and runtime permissions matter as much as the model workload itself. AI infrastructure workload identity is the right lens for treating clusters, jobs and orchestration systems as governed identities rather than disposable compute.
The article is really about what happens when AI platforms inherit old internet-facing assumptions: unauthenticated control planes get reused as mass-compromise infrastructure, and attackers move quickly from probing to automation. That is typical of exposed AI tooling, not an edge case.
Key questions
Q: What breaks when AI endpoints are exposed without authentication?
A: Unauthenticated AI endpoints become discoverable services that attackers can validate, abuse for inference, and resell as access. The failure is not only unauthorized usage. It is the conversion of a machine service into a tradable identity surface with cost, data, and internal access implications.
Q: Why do exposed AI clusters make secret harvesting so easy?
A: Because workloads often inherit secrets through environment variables, mounted files and orchestration metadata. Once an attacker gains code execution, those artefacts are immediately available for discovery and reuse. The risk is highest when the cluster’s runtime context is treated as temporary and therefore left with broader credential exposure than a user-facing system would permit.
Q: How can security teams tell when AI infrastructure is being used for botnet activity?
A: Look for shell-cascade execution, unexpected script downloads, background daemons, cron creation and unusual CPU or GPU consumption. Those signals matter because botnet operators want persistence and scale, not a one-off exploit. If the cluster begins fetching scripts and staying busy outside normal job windows, assume malicious repurposing until proven otherwise.
A: Control-plane authentication comes first because it closes the easiest path to arbitrary execution. Egress filtering still matters, but it works best after the management surface is no longer publicly reachable. The most resilient programme treats both as paired controls, with authentication reducing initial compromise and outbound limits reducing post-exploitation utility.
Technical breakdown
How missing authentication in a jobs API becomes remote code execution
A jobs API is an orchestration surface, not just a data endpoint. When it lacks authentication, an attacker can submit commands or payloads as if they were a legitimate operator, then use the cluster’s own execution machinery to run code on distributed nodes. The risk is amplified when the API is exposed publicly, because the control plane becomes the entry point for arbitrary execution rather than a protected admin plane. In AI infrastructure, that can translate into notebook abuse, job hijacking or full cluster takeover. The core failure is trust without identity binding. See the NHI Authentication Guide.
Practical implication: Treat job submission interfaces as privileged control planes and require strong authentication before any workload execution path is exposed.
Why reconnaissance payloads target secrets, identity and privilege context
The article’s reconnaissance examples are not incidental. Reading /etc/passwd, dumping environment variables and running whoami or id are classic steps for mapping the local security context, identifying service accounts and finding secrets or tokens embedded in runtime state. In AI infrastructure, those artifacts often sit in job environments, container variables, mounted files or orchestration metadata. Once the attacker understands the execution context, they can choose between privilege escalation, lateral movement or direct exfiltration. The mechanism is simple: discover what the process can see, then repurpose that visibility into access.
Practical implication: Assume every exposed runtime variable or mounted credential can become an attacker’s next pivot point and remove secrets from job environments.
How download-and-execute botnet tradecraft turns AI clusters into persistence platforms
The payloads described here use a familiar pattern: fetch a script, pipe it into a shell, and then either stage persistence or run a binary in the background. That works because AI compute environments often have enough outbound connectivity, CPU and GPU headroom to hide malicious activity inside legitimate workload noise. The threat is not just execution, but repeatable execution at scale, which lets botnet operators automate cryptomining, DDoS recruitment and follow-on payload delivery. In other words, the cluster is being repurposed as infrastructure for the attacker’s lifecycle, not simply compromised once.
Practical implication: Monitor for shell-cascade patterns and unexpected persistence artefacts in AI workloads, not just for model-specific anomalies.
Threat narrative
Attacker objective: The attacker wants durable control of AI infrastructure that can be reused for monetisation, botnet recruitment and data theft.
- Entry occurs through CVE-2023-48022 in the Ray Jobs API, which allows unauthenticated attackers to reach an exposed AI control plane.
- Credential harvesting and context discovery follow as payloads read system accounts, dump environment variables and identify the current execution context.
- Escalation and persistence occur when attackers fetch shell scripts or binaries, execute them in-memory or in the background, and convert the cluster into botnet infrastructure.
- Impact includes cryptomining, DDoS recruitment and data exfiltration from high-performance AI environments.
Breaches seen in the wild
- ShadowRay 2024: Attackers took over internet-exposed Ray AI clusters via the disputed CVE-2023-48022, exposing cloud keys, AI API tokens and GPU compute.
- LiteLLM MCP auth bypass 2026: An exploited LiteLLM MCP auth bypass and default sk-1234 master keys let attackers steal AI gateway master and provider API keys.
Read and download The State of NHI & AI Agent Breach Report 2026, covering 200+ breaches impacting Non-Human Identities including AI Agents.
NHI Mgmt Group analysis
AI infrastructure exposure is now an identity problem as much as a vulnerability problem. The article shows that unauthenticated jobs APIs are not merely exploitable services, they are control planes that can be repurposed for code execution, secret harvesting and botnet staging. That makes workload identity and control-plane authentication part of core security design, not optional hardening. The governance failure is treating AI orchestration as ephemeral compute instead of managed identity surface.
Secrets living in AI runtime environments create a standing compromise path. Environment variables, mounted tokens and orchestration metadata are repeatedly used as the quickest route from foothold to meaningful access. That pattern aligns with non-human authentication concerns because the attacker is often not breaking the model, but abusing the credentials wrapped around the workload. Practitioners need inventory, rotation and scoping discipline around every machine credential that can reach AI infrastructure.
ShadowRay 2.0 shows how exploit commoditisation changes the risk model. Once multiple botnet families fold a vulnerability into automated kits, the question shifts from whether an exposed service will be found to how quickly it will be weaponised. That is a category-level signal for AI platforms with internet exposure. The right response is to reduce exposure paths, enforce managed identity at the control plane and assume automated abuse will follow.
AI workloads are becoming part of the criminal compute economy. The combination of GPU capacity, cloud-native orchestration and weak perimeter assumptions makes exposed AI infrastructure attractive for cryptomining and DDoS as well as data theft. This is not a niche research problem but a governance issue for any team running distributed AI services. The practical conclusion is that AI security must cover identity, network egress and runtime telemetry together, not as separate workstreams.
From our research library:
- AI-related credential leaks surged 81.5% year-over-year in 2025, with the surrounding AI infrastructure leaking 5x faster than core LLM providers, according to the State of Secrets Sprawl 2026.
- Read next: AI Infrastructure Workload Identity Guide
What this signals
AI infrastructure sprawl creates a credential exposure window: as AI platforms accumulate orchestration APIs, job runners and distributed compute, every exposed management surface becomes a candidate for automated abuse. The article shows that the decisive risk is not the model itself but the runtime and control plane around it, which is why workload identity has to be designed into AI infrastructure from the start.
The attacker’s fastest path is usually not novel exploitation but reuse of ordinary operational trust, from environment variables to script execution and outbound fetches. That is why identity governance for AI workloads increasingly needs to join network controls, secret hygiene and runtime monitoring in one operating model, especially as AI-related credential leaks surged 81.5% year-over-year in 2025, with the surrounding AI infrastructure leaking 5x faster than core LLM providers, according to the State of Secrets Sprawl 2026.
Exposed AI platforms are becoming part of the same commoditised attack economy as any other internet-facing service. Once botnets can reliably weaponise a control plane, the programme question changes from whether a vulnerability exists to how quickly identity, segmentation and telemetry can contain it before the cluster is repurposed.
For practitioners
- Enforce authenticated access to AI control planes Require OIDC or mTLS for Ray-style dashboards and job APIs, and remove any internet exposure that is not strictly necessary for operations.
- Strip secrets from job environments Move credentials out of environment variables and job payloads, then rotate anything that may already have been exposed through a recon payload.
- Hunt for download-and-execute patterns Alert on wget to sh, curl to bash, direct shell piping and similar process chains in AI job submissions and runtime logs.
- Tighten outbound controls on AI clusters Block unauthorized egress, restrict TCP/8265 to trusted management networks and treat unexpected HTTP fetches as a compromise indicator.
- Watch for persistence and resource abuse Investigate unexpected cron jobs, systemd units, background daemons and abnormal CPU or GPU consumption on AI workloads.
Key takeaways
- The article describes a shift from a one-off AI vulnerability to a repeatable abuse pattern that attackers can automate across exposed clusters.
- Telemetry shows the threat expanded sharply in late 2025, with 803 observed activity events in Q4 and multiple botnet families participating.
- The control gap is not just patching CVE-2023-48022, but enforcing authentication, restricting exposure and removing secrets from AI runtime environments.
Related NHI Mgmt Group resources: AI Infrastructure Workload Identity Guide · NHI Authentication Guide · Vulnerability Management Guide · Threat Modelling AI Agents
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP Non-Human Identity Top 10 and MITRE ATT&CK address the attack and risk surface, while NIST SP 800-53 Rev 5 and NIST CSF 2.0 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Non-Human Identity Top 10 | NHI-04 — Insecure Authentication | The article centres on missing authentication in the Ray Jobs API, which enabled unauthenticated code execution. |
| NHI-02 — Secret Leakage | Payloads dumped environment variables and harvested credentials from runtime state. | |
| Recommendation — Require strong authentication on AI job APIs before exposing any control plane to remote users. Remove secrets from AI runtime environments and rotate any credential exposed through job execution. | ||
| NIST SP 800-53 Rev 5 | IA-9 — Identification and Authentication (Service and Machine Identities) | AI workloads and orchestration services authenticate as non-human identities in this attack path. |
| AC-6 — Least Privilege | The attacker relied on broad runtime access after compromising the jobs API. | |
| Recommendation — Bind workload and service authentication to IA-9 so AI control planes are not reachable without verified machine identity. Limit AI job and service privileges so a compromised workload cannot pivot beyond its intended scope. | ||
| NIST CSF 2.0 | PR.AA-05 — Access Permissions, Entitlements and Authorizations | The exposed jobs API and runtime access controls failed to constrain unauthorised execution. |
| Recommendation — Review AI cluster entitlements and remove any access path that is not explicitly authorised for operations. | ||
| MITRE ATT&CK | TA0006;TA0008 — Credential Access; Lateral Movement | Reconnaissance payloads harvested secrets and set up follow-on movement across the environment. |
| Recommendation — Map AI cluster telemetry to TA0006 and TA0008 to detect credential harvesting and follow-on movement quickly. | ||
Key terms
- Atlas Control Plane: The Atlas control plane is the administrative layer for managing MongoDB Atlas resources such as database users, IP access lists, and cluster settings. When exposed to AI agents, it expands risk beyond data access into infrastructure and identity changes. That makes prompt injection and overbroad permissions much more dangerous.
- Jobs API: A jobs API is the interface used to submit, manage and monitor workload execution. In AI infrastructure, it can trigger compute on distributed systems, so missing authentication or weak authorization turns it into an execution primitive for attackers. Governance has to treat it like privileged infrastructure, not a convenience feature.
- Runtime Secret Retrieval: Runtime secret retrieval is the practice of fetching credentials from a vault or controlled service only when they are needed. It reduces secret exposure in repositories and configs, but it only works when the retrieval path is scoped, logged, and tied to a specific workload or agent.
- Botnet Commoditisation: Botnet commoditisation is the point at which multiple criminal crews package the same exploit into reusable tooling and scale it across campaigns. The risk shifts from isolated exploitation to repeatable abuse, where exposed services are targeted automatically and repurposed for cryptomining, DDoS or data theft.
Deepen your knowledge
The NHI Foundation Level course, the industry's only accredited NHI security programme, covers NHI governance, machine identity security and secrets management. It helps practitioners connect identity controls to the systems that actually run modern workloads.
Published by the NHIMG editorial team on October 22, 2026.
NHI Mgmt Group, the independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org