<?xml version="1.0" encoding="UTF-8" ?>
<rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom">
  <channel>
    <title>Grayhaven exploit watch: platform incidents</title>
    <link>https://www.grayhavenindustries.com/watch</link>
    <description>Flaws CISA confirms are exploited, and the platform incidents Grayhaven is following.</description>
    <language>en-us</language>
    <atom:link href="https://www.grayhavenindustries.com/watch/feed.xml?only=incidents" rel="self" type="application/rss+xml" />
    <item>
      <title>Luanti says attacker broke into ContentDB servers</title>
      <link>https://www.grayhavenindustries.com/watch#luanti-2026-10</link>
      <description>Luanti said an attacker broke into ContentDB by exploiting two vulnerabilities, one of them in a third-party component that it reported to the maintainer. Luanti said the attacker had access to ContentDB&apos;s internal configuration from 22nd October 13:00 UTC and used it to sign into a staff account. Luanti said it confirmed that from 26th October 00:15 the attacker could run commands on its server inside a docker container, with full access to the database. Luanti said the attacker had full access to secrets, the database, redis and uploads, including usernames, emails, bcrypt hashed passwords, and download IP addresses from the two weeks before 26th October. Luanti said it checked every upload against backups and found no changes, but it has not ruled out that the attacker caused ContentDB to serve malicious uploads.</description>
      <pubDate>Tue, 27 Oct 2026 00:00:00 GMT</pubDate>
      <guid isPermaLink="false">https://www.grayhavenindustries.com/watch#luanti-2026-10@2026-10-27</guid>
    </item>
    <item>
      <title>FirstVDS says attackers copied client server data via VMmanager</title>
      <link>https://www.grayhavenindustries.com/watch#firstvds-2026-10</link>
      <description>FirstVDS said that on 17 October 2026 it found a compromise of the VMmanager 6 virtualization management platform, made by ISPsystem, and that the attacker gained administrative access to the panel. FirstVDS said the attacker used the panel&apos;s standard functions to run a data collector on virtualization nodes, and that it mounted client virtual machine disks in read only mode and copied selected files, including passwords, keys, tokens and configurations. FirstVDS said collector archives were found on 457 virtualization nodes, and that this is a count of physical servers, not of clients or virtual machines. FirstVDS said the archives are encrypted with the attacker&apos;s key, that it does not have the key, and that it cannot check from the archives which exact files were copied from each virtual machine. FirstVDS said it began sending personal notices to affected clients on 18 October, and that clients who received one should treat the data on the listed servers as compromised.</description>
      <pubDate>Tue, 27 Oct 2026 00:00:00 GMT</pubDate>
      <guid isPermaLink="false">https://www.grayhavenindustries.com/watch#firstvds-2026-10@2026-10-27</guid>
    </item>
    <item>
      <title>OVHcloud CLI releases replaced with secret stealing binaries</title>
      <link>https://www.grayhavenindustries.com/watch#ovhcloud-2026-10</link>
      <description>OVHcloud said a compromised OVHcloud GitHub developer account was used to replace several existing release assets of ovhcloud-cli with malicious binaries on 19 October 2026 between 14h47 (UTC+2) and 16h21 (UTC+2). OVHcloud said the affected releases were v0.11.0 to v0.15.0, and that only users who installed the CLI in that window were affected. OVHcloud said the source code and build chain were not affected and no other repository projects were affected. OVHcloud said the malicious binaries were designed to steal secrets and files, including cloud credentials, SSH keys, Kubernetes and Docker configuration, and AI coding tool data. OVHcloud said the main cause was that the GitHub repository was not configured for release immutability, and that this was corrected and applied to every repository.</description>
      <pubDate>Fri, 23 Oct 2026 00:00:00 GMT</pubDate>
      <guid isPermaLink="false">https://www.grayhavenindustries.com/watch#ovhcloud-2026-10@2026-10-23</guid>
    </item>
    <item>
      <title>Railway customers told to rotate every stored secret</title>
      <link>https://www.grayhavenindustries.com/watch#railway-environment-variables</link>
      <description>Railway said an unauthorized third party may have reached the encrypted environment variables it keeps for customers and decrypted some of them. It asked every customer to rotate every variable, API key and registry credential stored with it. Railway invalidated all Railway API tokens, reset storage bucket credentials and the GitHub tokens it held, and published guides for checking unexpected use of AI service keys. It believes the breach is part of a series aimed at AI service providers. It had not published a cause as of 22 October.</description>
      <pubDate>Thu, 22 Oct 2026 00:00:00 GMT</pubDate>
      <guid isPermaLink="false">https://www.grayhavenindustries.com/watch#railway-environment-variables@2026-10-22</guid>
    </item>
    <item>
      <title>LiteLLM release v1.107.0 pushed with credential stealing malware</title>
      <link>https://www.grayhavenindustries.com/watch#litellm-2026-10</link>
      <description>LiteLLM said its release pipeline was compromised in the early morning of October 21 and pushed v1.107.0 to the docker registry and PyPi. LiteLLM said v1.107.0 contained compiled malware which steals credentials and loads remote-code execution tools. LiteLLM said the malicious PyPI package was live from 11:39 UTC to 13:23 UTC, and the compromised Docker images were live from 11:46 UTC to 14:20 UTC. LiteLLM said all previous versions are safe, the impacted releases have been pulled, and enterprise customers on the private enterprise release were not impacted. LiteLLM said it believes it has identified the attack chain, and that it has not yet confirmed how the attacker gained access to its internal deployment but currently suspects a recently patched vulnerability. LiteLLM said the incident was contained and the investigation was still in progress as of its October 21, 2026 20:30 UTC update.</description>
      <pubDate>Thu, 22 Oct 2026 00:00:00 GMT</pubDate>
      <guid isPermaLink="false">https://www.grayhavenindustries.com/watch#litellm-2026-10@2026-10-22</guid>
    </item>
    <item>
      <title>GMO Internet reports third-party intrusion into Onamae.com Desktop Cloud servers</title>
      <link>https://www.grayhavenindustries.com/watch#gmointernet-2026-10</link>
      <description>GMO Internet said 26,739 servers were potentially affected and that information stored on the servers may have been viewed. GMO Internet said it began shutting down customer servers in sequence from 4:00 on October 21, 2026, and had not yet set a date for resumption. In its second report, GMO Internet said it had received customer reports of unauthorized operations on trading accounts linked to trading tools used on the servers. GMO Internet said trading tool passwords and trading account credentials used on the servers may have been viewed by a third party, and that it was investigating with an external cybersecurity firm and had consulted the police on October 22.</description>
      <pubDate>Thu, 22 Oct 2026 00:00:00 GMT</pubDate>
      <guid isPermaLink="false">https://www.grayhavenindustries.com/watch#gmointernet-2026-10@2026-10-22</guid>
    </item>
    <item>
      <title>OpenCode console keys may have been exposed</title>
      <link>https://www.grayhavenindustries.com/watch#opencode-console-keys</link>
      <description>OpenCode said a breach it called related to a large-scale distillation attack affected 1.4% of its console users, those who had linked outside AI providers, and that it emailed each of them. The Hacker News reports that the keys saved in the hosted console may have been exposed, and that OpenCode&apos;s co-founder said keys used by its local apps never reach OpenCode. OpenCode said it was working with Anthropic, OpenAI and Google, and had not said any key was copied or used.</description>
      <pubDate>Thu, 22 Oct 2026 00:00:00 GMT</pubDate>
      <guid isPermaLink="false">https://www.grayhavenindustries.com/watch#opencode-console-keys@2026-10-22</guid>
    </item>
    <item>
      <title>Zeabur platform database read by an attacker</title>
      <link>https://www.grayhavenindustries.com/watch#zeabur-platform-database</link>
      <description>Zeabur reported that on 14 and 15 October an attacker used leaked internal credentials to work through its systems and read 3,218,965 environment variable records and 321,810 accounts from its platform database. Zeabur gives the cause: long-lived admin credentials stored in plaintext that could be used from the public internet, unchanged since January 2024. More than 16 hours of attack activity raised no alert. Zeabur judges from the attacker&apos;s commands that it was mainly after API keys, especially for AI services.</description>
      <pubDate>Thu, 22 Oct 2026 00:00:00 GMT</pubDate>
      <guid isPermaLink="false">https://www.grayhavenindustries.com/watch#zeabur-platform-database@2026-10-22</guid>
    </item>
    <item>
      <title>PingCAP says stolen credentials let an attacker copy data and source code</title>
      <link>https://www.grayhavenindustries.com/watch#pingcap-2026-09</link>
      <description>PingCAP said that between September 9 and October 7, 2026, an unauthorized party used stolen service account credentials to access certain internal systems, copy data, and obtain source code. PingCAP said exported records included user names, email addresses, organization and project associations, SQL editor text and errors, customer contacts, contract terms, orders, pricing, and billing configuration. PingCAP said an exported table contained encrypted TiDB Cloud API-key values, and that whether other usable credentials were exposed remains to be determined. PingCAP said there is no evidence that data stored in TiDB was impacted, and that an external firm found no evidence the attacker ran commands or kept persistent access in the production systems it reviewed. PingCAP said it became aware of the incident on October 7, and that as of October 14 all identified compromised credentials were invalidated and the identified unauthorized access paths were blocked. PingCAP said it is still determining which customers and data types were affected, and that it will notify affected customers directly once customer-specific impact is established.</description>
      <pubDate>Thu, 22 Oct 2026 00:00:00 GMT</pubDate>
      <guid isPermaLink="false">https://www.grayhavenindustries.com/watch#pingcap-2026-09@2026-10-22</guid>
    </item>
    <item>
      <title>Vercel breach that began at an employee&apos;s AI tool</title>
      <link>https://www.grayhavenindustries.com/watch#vercel-context-ai</link>
      <description>Vercel said its April breach began with Context.ai, a third-party AI tool one employee used, whose Google Workspace connection was compromised. The attacker took over the employee&apos;s accounts, moved into a Vercel environment and decrypted non-sensitive environment variables for a limited set of customers. Vercel closed the incident on 16 October 2026.</description>
      <pubDate>Thu, 22 Oct 2026 00:00:00 GMT</pubDate>
      <guid isPermaLink="false">https://www.grayhavenindustries.com/watch#vercel-context-ai@2026-10-22</guid>
    </item>
  </channel>
</rss>
