{
	"id": "4fbf6a33-63b9-4c50-a3dd-8349a1084b86",
	"created_at": "2026-04-06T00:13:23.189329Z",
	"updated_at": "2026-04-10T03:23:52.230742Z",
	"deleted_at": null,
	"sha1_hash": "b43f4219009db20e8513a8672bdab89d27fa28f2",
	"title": "Oligo",
	"llm_title": "",
	"authors": "",
	"file_creation_date": "0001-01-01T00:00:00Z",
	"file_modification_date": "0001-01-01T00:00:00Z",
	"file_size": 4550608,
	"plain_text": "Oligo\r\nArchived: 2026-04-05 17:20:26 UTC\r\nShadowRay: First Known Attack Campaign Targeting AI Workloads Actively Exploited\r\nIn The Wild\r\nCategory:\r\nResearch\r\nShadow Vulnerability\r\nAuthor:\r\nAvi Lumelsky\r\nGal Elbaz\r\nGuy Kaplan\r\nThousands of publicly exposed Ray servers compromised as a result of Shadow Vulnerability\r\nTL;DR\r\nhttps://www.oligo.security/blog/shadowray-attack-ai-workloads-actively-exploited-in-the-wild\r\nPage 1 of 17\n\nThe Oligo research team has recently discovered an active attack campaign targeting a vulnerability in Ray, a widely used\r\nopen-source AI framework. Thousands of companies and servers running AI infrastructure are exposed to the attack through\r\na critical vulnerability that is under dispute and thus has no patch. This vulnerability allows attackers to take over the\r\ncompanies' computing power and leak sensitive data. This flaw has been under active exploitation for the last 7 months,\r\naffecting sectors like education, cryptocurrency, biopharma and more. All organizations using Ray are advised to review\r\ntheir environments to ensure they are not exposed and to analyze any suspicious activity.\r\nIntro\r\nIn late 2023, five unique vulnerabilities in Ray—a widely-used open-source framework mainly used in AI workloads—were\r\ndisclosed to Anyscale, the developers and maintainers of Ray. The vulnerabilities were disclosed (some simultaneously) by\r\nBishop Fox, Sierra Haex, and Protect AI.\r\nFollowing the disclosure, Anyscale released a blog [1] to address the vulnerabilities, clarify the chain of events, and detail\r\nhow each CVE was addressed. While four of the reported vulnerabilities were fixed in Ray version 2.8.1, the fifth CVE\r\n(CVE-2023-48022) remains disputed, meaning that it was not considered a risk and was not addressed with an immediate\r\nfix.\r\nBecause CVE-2023-48022 was disputed, many development teams (and most static scanning tools) are not aware that this\r\nvulnerability should concern them. Some of them might have missed this documentation section of Ray, while some of them\r\nare unaware of this feature.\r\nResearchers at Oligo Security have observed instances of CVE-2023-48022 being actively exploited in the wild, making the\r\ndisputed CVE a “shadow vulnerability”—a CVE that doesn’t show up in static scans but can still lead to breaches and\r\nsignificant losses.\r\nIn our research, we found that thousands of publicly exposed Ray servers all over the world were already compromised as a\r\nresult of this new vulnerability, dubbed ShadowRay by Oligo’s research team. Some of the impacted machines were\r\ncompromised for at least 7 months. Many of the machines included command history, making it much easier for attackers to\r\nunderstand what resides on the current machine and possibly leaking sensitive secrets from production that were used in\r\nprevious commands.\r\nA complete list of Indications of Compromise (IoCs) is available at the end of the blog. Hundreds of companies have been\r\npublicly exposed to remote code execution (RCE) through Ray, with some remaining vulnerable to this day.\r\nOligo researchers (who have been at the forefront of uncovering shadow vulnerabilities) named this CVE ShadowRay,\r\nmarking the first known instance of AI workloads actively being exploited in the wild through vulnerabilities in modern AI\r\ninfrastructure.\r\nIn this summary of our research, we will dive into:\r\nWhy AI infrastructure is a goldmine for attackers.\r\nWhat the Ray open-source framework is, who uses it, and how it is used in AI.\r\nThe Ray clusters that have been exploited in the wild, including the wealth of data that has been compromised, the\r\ncollective value of compromised machines, how attackers are monetizing their efforts, and more.\r\nDisclaimer:\r\nThis blog will discuss recent vulnerabilities in the open-source Ray framework that were reported by Bishop Fox\r\n[2], Sierra Haex [3], and Protect AI [4]. It does not relate to Anyscale’s (the developers of Ray) SaaS offerings or\r\npaid products. The sole intention of this blog is to support users of Ray by increasing awareness of its security\r\naspects and common pitfalls.\r\nIn This Article:\r\n1. AI Infrastructure: A Goldmine for Attackers\r\n2. Meet Ray\r\n3. The Story of CVE-2023-48022: ShadowRay Explained\r\n4. Indications of Compromise (IoCs)\r\n5. Special Thanks\r\nAI Infrastructure: A Goldmine for Attackers\r\nA typical AI environment contains a wealth of sensitive information—enough to take an entire company down. Why is an AI\r\nenvironment such a lucrative environment for attackers? Let’s take a look at the components and the risks they present.\r\nAn ML-OPS environment consists of many services that communicate with each other, inside the same cluster and between\r\nclusters.\r\nhttps://www.oligo.security/blog/shadowray-attack-ai-workloads-actively-exploited-in-the-wild\r\nPage 2 of 17\n\nWhen used for training or fine-tuning, it usually has access to datasets and models, on disk or in remote storage, such as an\r\nS3 bucket. Oftentimes, models or datasets are the unique, private intellectual property that differentiates a company from its\r\ncompetitors.\r\nAdditionally, AI environments will typically have access to third-party tokens (in a readable secret or environment variable)\r\nand integrations of many kinds (HuggingFace, OpenAI, WanDB, and other SaaS providers).\r\nAI models are now connected to company databases and knowledge graphs. The AI infrastructure can be a single point of\r\nfailure for AI-driven companies—and a hidden treasure for attackers.\r\nAI models typically run on expensive, high-powered machines, which makes the computing power they use a prime target\r\nfor attackers.\r\nMeet Ray\r\nRay is a unified framework for scaling AI and Python applications for a variety of purposes.\r\nAt high level, Ray consists of:\r\n1. Core distributed runtime, known as Ray Core.\r\n2. A set of complementary AI Libraries and extensions that are built on top of it or depend on it, for accelerating and\r\ndistributing domain-specific ML workloads efficiently.\r\nWho Uses Ray and How?\r\nToday, Ray has 30K stars on GitHub [5]. According to Anyscale, some of the world’s largest organizations use Ray in\r\nproduction, including Uber, Amazon, and OpenAI. [6]\r\nSource: anyscale.com [6]\r\nMany projects rely on Ray for mainstream SaaS, Data, and AI workloads, leveraging the project for its high levels of\r\nscalability, speed, and efficiency.\r\nAnyscale maintains the Ray project, which serves as a base for numerous libraries including Ray Tune, Ray Serve, and\r\nmore.\r\nSource: ray.io\r\nRay uses boilerplate code that bootstraps product installations and deployment using Helm charts and other cloud-native\r\nmethods. Ray’s many integrations with cloud providers enable managed services use cases as well.\r\nModels like GPT-4 comprise billions of parameters, requiring massive computational power. Such large models cannot\r\npossibly fit on the memory of a single machine. Ray is the enabling technology that allows these models to run.Ray quickly\r\nhttps://www.oligo.security/blog/shadowray-attack-ai-workloads-actively-exploited-in-the-wild\r\nPage 3 of 17\n\nbecame a best practice in the industry—especially for AI practitioners, who are proficient in Python and often require\r\nmodels to run and distribute among multiple GPUs and machines.\r\nHow Ray is Used in AI\r\nRay’s capabilities match the needs of AI perfectly:\r\nRay enables distributed workloads for training, serving, and tuning AI models of all architectures and\r\nframeworks.\r\nRay requires very low proficiency in Python. It has a lean Python API with minimal configuration.\r\nRay is rock-solid and uses best practices to optimize performance, with a robust, effortless installation, few\r\ndependencies, and production-grade, battle-tested code.\r\nRay goes beyond Python, allowing you to run jobs of any kind, including bash commands.\r\nRay is the Swiss Army knife for Pythonistas and AI practitioners, allowing them to effortlessly scale their AI applications.\r\nThe story of CVE-2023-48022: ShadowRay Explained\r\nFollowing the disclosure of five vulnerabilities by Bishop Fox, Sierra Haex, and Protect AI, Anyscale handled a challenging\r\nsituation with transparency and responsiveness, demonstrating their commitment to the security and integrity of the Ray\r\necosystem. Anyscale promptly addressed four of the issues in Ray version 2.8.1 and provided a detailed blog post explaining\r\nthe vulnerabilities and their remediation [7].\r\nOne of the vulnerabilities, CVE-2023-48022, arose from Ray’s lack of authorization in the Jobs API. Unlike the other CVEs,\r\nwhich were addressed with Ray’s new release, this CVE remained disputed by Anyscale—in fact, according to them, it’s an\r\nexpected behavior and a product feature, rather than a vulnerability or bug.\r\nHowever, in many GitHub boilerplate repositories to help companies deploy Ray to their cloud environment, Ray remains\r\nvulnerable not only to the CVEs that were successfully fixed (running Ray versions between 2.6.3 - 2.8.0), but also\r\nShadowRay—because Ray’s dashboard always binds on 0.0.0.0 (all network interfaces), together with port forwarding on\r\n0.0.0.0, possibly exposing the machine to the internet by default [8].\r\nHow Can Lack of Authorization Be Abused?\r\nRay does not include any kind of authorization in its Jobs API. The result: anyone with dashboard network access (HTTP\r\nport 8265) could potentially invoke arbitrary jobs on the remote host, without authorization. \r\nAccording to Ray’s official documentation, the security best practices begin with the following:\r\n”... Security and isolation must be enforced outside of the Ray Cluster. Ray expects to run in a safe network\r\nenvironment and to act upon trusted code. Developers and platform providers must maintain the following\r\ninvariants to ensure the safe operation of Ray Clusters …” [9]\r\nRay includes code execution capabilities by design, so Anyscale believes the users should be responsible for its locality and\r\nsecurity. The dashboard should either not be internet-facing, or be accessible only to trusted parties. Ray lacks authorization\r\nbased on an assumption that it will run in a safe environment with proper routing logic: Network isolation, Kubernetes\r\nnamespaces, Firewall rules, or Security Groups.\r\nWhen we discussed these issues with industry experts, we found that they were not aware of the Jobs API in Ray’s\r\nDashboard, nor had they heard about this CVE disclosure.\r\nFor example - Ray’s official Kubernetes deployment guide [10] and Kuberay’s Kubernetes operator encourage people to\r\nexpose the dashboard on 0.0.0.0:\r\nhttps://www.oligo.security/blog/shadowray-attack-ai-workloads-actively-exploited-in-the-wild\r\nPage 4 of 17\n\nKuberay’s Kubernetes operator encourage people to expose the dashboard on 0.0.0.0\r\nAI experts are NOT security experts—leaving them potentially dangerously unaware of the very real risks posed by AI\r\nframeworks.\r\nWithout authorization for Ray’s Jobs API, the API can be exposed to remote code execution attacks when not following best\r\npractices. The CVE is tagged as “disputed” - In these cases, the CVE Program makes no determination as to which party is\r\ncorrect.\r\nA “DISPUTED” tag in a CVE Record could be for one (or more) of any number of reasons, for example,\r\nquestions of accuracy, completeness, or whether the bug in question is, in fact, a security hole at all [11]\r\nDisputed tags make this kind of attack difficult to detect, with many scanners simply ignoring a disputed CVE. Users may\r\nnot be aware of the risk, even with the most advanced solutions available in the market.\r\nAccording to Anyscale, this issue does not constitute a vulnerability, but is instead a feature essential to Ray's design,\r\nenabling the triggering of jobs and execution of dynamic code within a cluster. While an authorization feature is recognized\r\nas a technical debt that will be addressed in a future version, its implementation is complex and may introduce breaking\r\nchanges. Therefore, Anyscale decided to postpone its addition and disputed CVE-2023-48022 [6].\r\nThis approach reflects Anyscale's commitment to maintaining Ray's functionality while prioritizing security enhancements.\r\nThis decision also underscores the complexity of balancing security and usability in software development, highlighting the\r\nimportance of careful consideration in implementing changes to critical systems like Ray and other open-source components\r\nwith network access.\r\nLack of Visibility\r\nDue to the disputes surrounding whether it constituted a vulnerability, ShadowRay (CVE-2023-48022) did not appear in\r\nseveral databases. This created a blind spot: security teams around the world had no idea that they could be at risk. Let’s\r\nlook at how ShadowRay is portrayed by MITRE and OSV, for example.\r\nMITRE:\r\nWhile receiving a critical score of 9.8, it is currently tagged as “disputed” on MITRE [7] .The description explains why:\r\nAnyscale Ray 2.6.3 and 2.8.0 allows a remote attacker to execute arbitrary code via the job submission API.\r\nNOTE: the vendor's position is that this report is irrelevant because Ray, as stated in its documentation, is not\r\nintended for use outside of a strictly controlled network environment [12]\r\nA note from the disputed CVE\r\nOSV \r\nGoogle’s Open Source Vulnerability Database did not contain this vulnerability [13]. We opened an issue to understand why.\r\nBecause it was disputed, this vulnerability will likely be suppressed in SCA and SAST tools that rely on CVE for\r\nvulnerability management, which decreases the overall awareness of this CVE.\r\nhttps://www.oligo.security/blog/shadowray-attack-ai-workloads-actively-exploited-in-the-wild\r\nPage 5 of 17\n\nThis means that this disputed CVE is actually a Shadow Vulnerability [14]  - one that has already been leveraged by\r\nattackers and will be leveraged at increasing rates.\r\nCVEs tagged as “Disputed” with a high vulnerability score (9.8) are very interesting. While invisible to scanning tools, they\r\ncan pose massive risks.\r\nExploited Ray clusters in the wild: What sensitive data was compromised?\r\nWhen attackers get their hands on a Ray production cluster, it is a jackpot. Valuable company data plus remote code\r\nexecution makes it easy to monetize attacks—all while remaining in the shadows, totally undetected (and, with static\r\nsecurity tools, undetectable).\r\nA trove of sensitive information has been leaked via the compromised servers. Let’s dive into the specific information we\r\nuncovered.\r\nAI Production Workloads were compromised, meaning an attacker could affect an AI model's integrity or accuracy,\r\nsteal models, and infect models during the training phase. Impacted organizations came from many industries,\r\nincluding medical companies, video analytics companies, elite educational institutions, and many more.\r\nSensitive Environment Variables or the Ray process inside a compromised machine that was running Ray with\r\ninternet access, exposing OpenAI, Stripe, Slack, and DB credentials.\r\nhttps://www.oligo.security/blog/shadowray-attack-ai-workloads-actively-exploited-in-the-wild\r\nPage 6 of 17\n\nCluster Dashboard with Production workloads and active tasks\r\nAI model in action: handling a query submitted by a user in real time. The model could be abused by the\r\nattacker, who could potentially modify customer requests or responses.\r\nProduction DB Credentials were exposed, allowing attackers to download complete databases silently. On some\r\nmachines, attackers could modify the database or encrypt it with ransomware.\r\nProduction database credentials\r\nhttps://www.oligo.security/blog/shadowray-attack-ai-workloads-actively-exploited-in-the-wild\r\nPage 7 of 17\n\nPasswords - We saw evidence that the attackers have stolen password hashes from the machines - using a simple cat\r\n/etc/shadow, which was successfully executed multiple times in the job history.\r\nRay jobs history is visible from the dashboard: Attackers stole passwords and opened a reverse shell\r\nPrivate SSH keys - We have found several private SSH keys that can be used by attackers to connect to more\r\nmachines from the same VM image template (like AMI), reaching more compute capability for crypto-mining\r\ncampaigns or simply gaining persistence in the environment.\r\nAWS cluster machine credentials - allows connecting via SSH to all the machines in the cluster.\r\nOpenAI Tokens - We found OpenAI tokens that attackers could use to gain access to OpenAI accounts, which could\r\nbe used to drain the impacted company’s credits on the OpenAI platform. The compromised tokens we found were\r\nall disclosed to OpenAI through the official bug bounty program [15].\r\nHuggingFace Tokens - (access to private repositories) - We found HuggingFace tokens that enable adding and\r\noverriding existing models. Attackers could use the account’s repositories for supply chain attacks, potentially\r\nreaching other machines by uploading models to the platform or overriding existing ones.\r\nStripe Tokens - We found Stripe tokens that attackers could use to drain payment accounts by signing their\r\ntransactions on the live platform.\r\nAccess to the Cloud Environment (AWS, GCP, Azure, Lambda Labs) - Many of the clusters ran with high\r\nprivileges (root).\r\nAttackers had access to sensitive cloud services, potentially leaking sensitive production data: complete\r\ndatabases with customer data, codebases, artifacts, and secrets.\r\nKubernetesAPI access - Enables attackers to infect cloud workloads, steal Kubernetes secrets, and more.\r\nhttps://www.oligo.security/blog/shadowray-attack-ai-workloads-actively-exploited-in-the-wild\r\nPage 8 of 17\n\nKuberay Operator running with Administrator permissions on the Kubernetes API.\r\nSlack Tokens - We found Slack tokens that attackers could use to read an impacted organization’s Slack messages or\r\nsend arbitrary messages to certain channels on Slack.\r\nThe Financials: What Is the Collective Value of the Compromised Machines?\r\nMost of the GPU models we found compromised are currently out of stock and are hard to get. For example, the A6000\r\nGPUs from the machine above are out of stock on NVIDIA’s website:\r\nnvidia-smi output from a compromised machine\r\nhttps://www.oligo.security/blog/shadowray-attack-ai-workloads-actively-exploited-in-the-wild\r\nPage 9 of 17\n\nSource: NVIDIA Shop\r\nAs of now, Oligo has found hundreds of compromised clusters. Each cluster consists of many nodes, which are machines\r\nconnected to the cluster over the network. Most nodes have GPUs, which are leveraged by attackers for cryptocurrency\r\nmining, making this infrastructure an even bigger target for attacks.\r\nIn other words, attackers choose to compromise these machines not only because they can obtain valuable sensitive\r\ninformation, but because GPUs are very expensive and difficult to obtain, especially these days.\r\nThe on-demand price of a GPU machine depends mostly on the GPU type and memory. At the time of writing, GPU on-demand prices on AWS can reach an annual cost of $858,480 per machine.\r\nThe total amount of machines and compute power that might have been compromised can be estimated to be worth almost a\r\nbillion USD, based on the clusters we observed in the last few weeks alone. Moreover, the first evidence of an attack that we\r\nhave observed is from September 5th, which gave the attackers at least 7 months to leverage the hardware.\r\nAttackers are doing the same math.\r\nDo Targeted Clusters Have Anything in Common? (Crypto Miners)\r\nMost of the clusters Oligo Research has identified and reported were already hacked with crypto-miners or reverse-shells.\r\nWe noticed some patterns along the compromised clusters, indicating that they were targeted by the same attackers.\r\nOligo Research Team has identified crypto-mining campaigns that leverage ShadowRay to hack organizations and install\r\ncryptocurrency miners of different kinds.\r\nThe first crypto-miner we noticed was installed on Feb. 21, 2024. Using public web intelligence tools, we discovered that\r\nthe IP has been accepting connections to the target port since Sept. 5, 2023, indicating the breach might have started before\r\nthe vulnerability was disclosed. Due to the scale of the attacks and the chain of events, we believe the threat actors are\r\nprobably part of a well-established hacking group.\r\nWe uncovered crypto miners including:\r\nXMRig Miners - some of them running in a volatile manner, in-memory, without being downloaded to disk.\r\nXMRig crypto miner connected to Zephyr mining pool\r\nhttps://www.oligo.security/blog/shadowray-attack-ai-workloads-actively-exploited-in-the-wild\r\nPage 10 of 17\n\nXMRig crypto miner with the attacker's email address (username)\r\nMultiple XMRig miners, one of them is running with root user\r\nEstablished connections to mining pools\r\nHistory from a compromised machine: attackers download and run XMrig crypto miner in the background\r\nAttackers download a privilege escalation payload to gain root access without sudo on the machine\r\nNBMiner\r\nDownloading NMBiner and running it in the background\r\nJava-based Zephyr miners\r\nProprietary miner executed as Java .jar file, which is connected to miningocean.org\r\nTracing the Attackers\r\nUsually, the command line used includes the unique username AND password of the attacker. Miners must connect to a\r\ncentralized server to function. The server it communicates with is also present in the command line. In one example,\r\nzephyr[.]miningocean[.]org was used. We looked at the mining pool and managed to identify the attacker in the leaderboard:\r\nhttps://www.oligo.security/blog/shadowray-attack-ai-workloads-actively-exploited-in-the-wild\r\nPage 11 of 17\n\nThere are thousands of miners in the mining pool\r\nThe attackers already have squeezed juice from the machines, reaching 148th place out of 3216 miners in this pool, placing\r\nthem in the top 5% of miners in the mining pool.\r\nThe attacker have reached 148th place out of 3216\r\nReverse Shells (Gaining Persistency)\r\nWe found multiple reverse shells that enabled the attackers to run arbitrary code in the production environment, and gain\r\npersistence on its machines:\r\nOpening a reverse shell through a tunnel\r\nActive reverse shells\r\nPython pty spawning with dup() and dup2() syscalls\r\nAttackers open reverse shells successfully:\r\nThe image above wasthe oldest record of reverse shell we observed on a Ray cluster, executed on September\r\n5th, 2023\r\nAn attacker-controlled IP address that served the payload\r\nhttps://www.oligo.security/blog/shadowray-attack-ai-workloads-actively-exploited-in-the-wild\r\nPage 12 of 17\n\nSuccessful reverse shells found in the jobs history\r\nAttackers are leveraging the Open-Source Service Interactsh to Evade Detection\r\nThe following job was inspected on a compromised ray cluster:\r\nbase64 encoded payload\r\nThe domain oast[.]fun was hiding in the payload as base64. Here is the decoded payload that attackers successfully ran on\r\nthe Ray clusters:\r\nDecoded base64 payload\r\nThe attackers tried to evade detection by using a base64 encoded Python code. When decoded, the Python code dispatches\r\nDNS query to a subdomain under oast[.]fun.\r\nWe looked at the certificate history of this domain: https://crt.sh/?q=oast.fun and found that the first Let'sEncrypt certificate\r\nis from 2022:\r\nLet'sEncrypt certificate for the domain from 2022\r\nAfter a quick search, we understood that this domain is connected to the interactsh open source service:\r\nhttps://github.com/projectdiscovery/interactsh?tab=readme-ov-file#using-self-hosted-server\r\nThe domain oast.fun is one of the public servers the project maintains.\r\nhttps://www.oligo.security/blog/shadowray-attack-ai-workloads-actively-exploited-in-the-wild\r\nPage 13 of 17\n\nThe default page on the public server\r\nThe attackers have leveraged the free public servers to avoid detection. When the attackers successfully execute the base64\r\npayload using the Jobs API, a DNS query is invoked from the compromised machine to the attacker-controlled free\r\nsubdomain. By invoking the DNS query from the compromised machine, the attackers immediately received a notification\r\nabout the compromised machine’s IP address:\r\nAn example of interactsh usage: The attacker receives out-of-band notifications about DNS queries from\r\nclients in real time.\r\nThe same tool is known to be used by threat actors, as mentioned in the article by Palo Alto's Unit 42:\r\nEven though Interactsh can be used for legitimate purposes, it is widely used by attackers to test malicious traffic.\r\nIts testing traffic therefore could be followed by a series of exploits. [16]\r\nWe Started Investigating the Payloads of the Reverse Shells\r\nWe delved into the reverse shell payload from bit[.]ly/akuhGet.The file content made it clear: The attackers tried to escalate\r\ntheir privileges using sudo, which was not present on the attacked machine. The attackers used the service www[.]akuh[.]net\r\nusing an open source repository.\r\nThe script used by the attackers is open source: https://github.com/akuhnet/wqemu/blob/main/su.sh\r\nVirus Total did not raise any red flags:\r\nhttps://www.oligo.security/blog/shadowray-attack-ai-workloads-actively-exploited-in-the-wild\r\nPage 14 of 17\n\nVirusTotal has no detections for the payload (0/59)\r\nIndications of Compromise (IoCs)\r\nDescription Type Value\r\nDescription\r\nIP\r\nAddress\r\n23.146.184.38/\r\nReverse\r\nShell\r\nEndpoint #1\r\nIP\r\nAddress\r\n54.176.108.174/\r\nReverse\r\nShell\r\nEndpoint #2\r\nIP\r\nAddress\r\n158.247.217.90/\r\nReverse\r\nShell\r\nEndpoint #3\r\nIP\r\nAddress\r\n206.189.156.69/\r\nReverse\r\nShell\r\nEndpoint #4\r\nDomain\r\nName\r\nclo4q41v1v85ed814bogstepb5jwkbxtj.oast.fun/\r\nReverse\r\nShell\r\nEndpoint #5\r\nDomain\r\nName\r\nbore.pub/\r\nMining Pool\r\nEndpoint #1\r\nDomain\r\nName\r\nxna.2miners.com/\r\nMining Pool\r\nEndpoint #2\r\nDomain\r\nName\r\nkryptex.network/\r\nMining Pool\r\nEndpoint #3\r\nDomain\r\nName\r\nzeph.kryptex.network/\r\nMining Pool\r\nEndpoint #4\r\nDomain\r\nName\r\nzeph.kryptex.network/\r\nMining Pool\r\nEndpoint #5\r\nDomain\r\nName\r\npool.hashvault.pro/\r\nMining Pool\r\nEndpoint #6\r\nDomain\r\nName\r\nzephyr.miningocean.org/\r\nMining Pool\r\nEndpoint #7\r\nDomain\r\nName\r\nrx.unmineable.com/\r\nVirusTotal\r\nReverse\r\nShell\r\nPayload #1\r\nVirusTotal\r\nHash\r\n98f0bf732ebae8f3ba250c02e02a0787a68039caa484e688e0391343eaf0b527\r\nReverse\r\nShell\r\nPayload\r\nMD5\r\nHash\r\nf3636232ed136fed658521682f6fa9f4\r\nReverse\r\nShell\r\nPayload\r\nSHA1\r\nHash\r\n8d53ade3599ca39d9ad22d9360834514e9a6c6dc\r\nhttps://www.oligo.security/blog/shadowray-attack-ai-workloads-actively-exploited-in-the-wild\r\nPage 15 of 17\n\nDescription Type Value\r\nAttacker\r\nEmail -\r\nfound in the\r\nlogs of a\r\ncompromised\r\nmachine\r\nEmail\r\nAddress\r\nfintagixgames[at]gmail[.]com\r\nAttacker\r\nWallet\r\nAddress -\r\nfound in the\r\nlogs of a\r\ncompromised\r\nmachine\r\nZEPHYR\r\nWallet\r\nAddress\r\nZEPHYR3KfKQNQrfBwHtsEWyuLn1nzXvjAraxAVBuoKrKFHn3pgtqLqX96h3sWa5kP4Y2i48a4RZnbBQoivU6dQ\r\nIP GeoLocations:\r\nSource: maxmind.com\r\nResponsible Disclosure\r\nThe Oligo research team has actively notified numerous companies through responsible disclosure while providing further\r\ndetails and assistance with remediation.\r\nDetection and Mitigation in Runtime\r\nShadow vulnerabilities will always exist, but without CVEs that are visible in build time, these vulnerabilities are invisible\r\nto SCA and SAST approaches. Code and Static Testing alone don’t hold the complete context about what is deployed.\r\nTo detect Shadow Vulnerabilities, the runtime environment, which includes the exploit indicators, must be monitored\r\ncontinuously. The signs of an exploit vary, potentially triggered by specially-crafted input, loading data from untrusted\r\nsources, missing firewall rules, behavior of dependencies that are not taken into account, and more.\r\nMitigation Strategies\r\nFollow the best practices for securing Ray deployments [9]\r\nStart with running Ray within a secured, trusted environment.\r\nAlways add firewall rules or security groups to prevent unauthorized access.\r\nAdd authorization on top of Ray Dashboard port (8265 by default):\r\nIf you do need Ray’s dashboard to be accessible, implement a proxy that adds an authorization layer to the\r\nRay API when exposing it over the network.\r\nContinuously monitor your production environments and AI clusters for anomalies, even within Ray.\r\nRay depends on arbitrary code execution to function. Code Scanning and Misconfiguration tools will not\r\nbe able to detect such attacks, because the open-source maintainers of Ray (Anyscale) marked it as disputed\r\nhttps://www.oligo.security/blog/shadowray-attack-ai-workloads-actively-exploited-in-the-wild\r\nPage 16 of 17\n\nand confirmed it is not a bug—at the time of writing, it is a feature.\r\nDon’t bind on 0.0.0.0 to make your life easy - It is recommended to use an IP of an explicit network\r\ninterface, such as the IP that is in the subnet of your local network or a trusted private VPC/VPN.\r\nDon’t trust the default - Sometimes tools assume you read their docs. Do it.\r\nUse the right tools - The technical burden of securing open source is yours. Don't rely on the maintainers,\r\nthere are tools that can help you protect your production workloads from the risks of using open source in\r\nruntime.\r\nWe’re also hosting a threat briefing where we’ll go over the potential impacts of ShadowRay, as well as essential\r\nmitigation steps.\r\nBook a 1:1 Briefing With Our Research Team\r\nSubscribe to our updates and be the first to learn about the next cyber attacks\r\nSpecial Thanks\r\nWe want to thank Anyscale, first of all for creating Ray, which is truly an awesome open-source framework. We were also\r\nincredibly impressed by Anyscale’s security team, which responded quickly and cooperated fully with our team, clearly\r\ndemonstrating real concern for the safety of Ray users and the community. Additionally, we want to thank Bishop Fox [2],\r\nSierra Haex [3], and Protect AI[4] for their amazing prior work on findings and for disclosing vulnerabilities responsibly.\r\nOligo Research Team\r\nOligo Research Team is a group of experienced researchers who focus on new attack vectors in open source software. The\r\nteam identifies critical issues and alerts Oligo customers and the technology community about their findings. The team has\r\nalready reported dozens of vulnerabilities in popular OSS projects and libraries, including Apache Cassandra, Atlassian\r\nConfluence, and PyTorch.\r\nAvi Lumelsky\r\nAvi has a relentless curiosity about business, AI, security—and the places where all three connect. An experienced software\r\nengineer and architect, Avi’s cybersecurity skills were first honed in elite Israeli intelligence units. His work focuses on\r\nprivacy in the age of AI and big data.\r\nGuy Kaplan\r\nGuy is an experienced security researcher with a love of reverse engineering and learning new technologies. Skilled at\r\nthinking like an attacker, Guy started his career in the Israeli military, where he led a cryptographic research team.\r\nGal Elbaz\r\nGal Elbaz is the Co-Founder and CTO at Oligo Security, bringing over a decade of expertise in vulnerability research and\r\nethical hacking. Gal started his career as a security engineer in the IDF's elite intelligence unit. Later on, he joined Check\r\nPoint, where he was instrumental in building the research team and served as a senior security researcher.\r\nStop modern attacks and keep your business moving\r\nSource: https://www.oligo.security/blog/shadowray-attack-ai-workloads-actively-exploited-in-the-wild\r\nhttps://www.oligo.security/blog/shadowray-attack-ai-workloads-actively-exploited-in-the-wild\r\nPage 17 of 17",
	"extraction_quality": 1,
	"language": "EN",
	"sources": [
		"MITRE"
	],
	"references": [
		"https://www.oligo.security/blog/shadowray-attack-ai-workloads-actively-exploited-in-the-wild"
	],
	"report_names": [
		"shadowray-attack-ai-workloads-actively-exploited-in-the-wild"
	],
	"threat_actors": [
		{
			"id": "d90307b6-14a9-4d0b-9156-89e453d6eb13",
			"created_at": "2022-10-25T16:07:23.773944Z",
			"updated_at": "2026-04-10T02:00:04.746188Z",
			"deleted_at": null,
			"main_name": "Lead",
			"aliases": [
				"Casper",
				"TG-3279"
			],
			"source_name": "ETDA:Lead",
			"tools": [
				"Agentemis",
				"BleDoor",
				"Cobalt Strike",
				"CobaltStrike",
				"RbDoor",
				"RibDoor",
				"Winnti",
				"cobeacon"
			],
			"source_id": "ETDA",
			"reports": null
		}
	],
	"ts_created_at": 1775434403,
	"ts_updated_at": 1775791432,
	"ts_creation_date": 0,
	"ts_modification_date": 0,
	"files": {
		"pdf": "https://archive.orkl.eu/b43f4219009db20e8513a8672bdab89d27fa28f2.pdf",
		"text": "https://archive.orkl.eu/b43f4219009db20e8513a8672bdab89d27fa28f2.txt",
		"img": "https://archive.orkl.eu/b43f4219009db20e8513a8672bdab89d27fa28f2.jpg"
	}
}