An employee at Elon Musk’s artificial intelligence company xAI leaked a private key on GitHub that for the past two months could have allowed anyone to query private xAI large language models (LLMs) which appear to have been custom made for working with internal data from Musk’s companies, including SpaceX, Tesla and Twitter/X, KrebsOnSecurity has learned.
Image: Shutterstock, @sdx15.
Philippe Caturegli, “chief hacking officer” at the security consultancy Seralys, was the first to publicize the leak of credentials for an x.ai application programming interface (API) exposed in the GitHub code repository of a technical staff member at xAI.
Caturegli’s post on LinkedIn caught the attention of researchers at GitGuardian, a company that specializes in detecting and remediating exposed secrets in public and proprietary environments. GitGuardian’s systems constantly scan GitHub and other code repositories for exposed API keys, and fire off automated alerts to affected users.
GitGuardian’s Eric Fourrier told KrebsOnSecurity the exposed API key had access to several unreleased models of Grok, the AI chatbot developed by xAI. In total, GitGuardian found the key had access to at least 60 fine-tuned and private LLMs.
“The credentials can be used to access the X.ai API with the identity of the user,” GitGuardian wrote in an email explaining their findings to xAI. “The associated account not only has access to public Grok models (grok-2-1212, etc) but also to what appears to be unreleased (grok-2.5V), development (research-grok-2p5v-1018), and private models (tweet-rejector, grok-spacex-2024-11-04).”
Fourrier found GitGuardian had alerted the xAI employee about the exposed API key nearly two months ago — on March 2. But as of April 30, when GitGuardian directly alerted xAI’s security team to the exposure, the key was still valid and usable. xAI told GitGuardian to report the matter through its bug bounty program at HackerOne, but just a few hours later the repository containing the API key was removed from GitHub.
“It looks like some of these internal LLMs were fine-tuned on SpaceX data, and some were fine-tuned with Tesla data,” Fourrier said. “I definitely don’t think a Grok model that’s fine-tuned on SpaceX data is intended to be exposed publicly.”
xAI did not respond to a request for comment. Nor did the 28-year-old xAI technical staff member whose key was exposed.
Carole Winqwist, chief marketing officer at GitGuardian, said giving potentially hostile users free access to private LLMs is a recipe for disaster.
“If you’re an attacker and you have direct access to the model and the back end interface for things like Grok, it’s definitely something you can use for further attacking,” she said. “An attacker could it use for prompt injection, to tweak the (LLM) model to serve their purposes, or try to implant code into the supply chain.”
The inadvertent exposure of internal LLMs for xAI comes as Musk’s so-called Department of Government Efficiency (DOGE) has been feeding sensitive government records into artificial intelligence tools. In February, The Washington Post reported DOGE officials were feeding data from across the Education Department into AI tools to probe the agency’s programs and spending.
The Post said DOGE plans to replicate this process across many departments and agencies, accessing the back-end software at different parts of the government and then using AI technology to extract and sift through information about spending on employees and programs.
“Feeding sensitive data into AI software puts it into the possession of a system’s operator, increasing the chances it will be leaked or swept up in cyberattacks,” Post reporters wrote.
Wired reported in March that DOGE has deployed a proprietary chatbot called GSAi to 1,500 federal workers at the General Services Administration, part of an effort to automate tasks previously done by humans as DOGE continues its purge of the federal workforce.
A Reuters report last month said Trump administration officials told some U.S. government employees that DOGE is using AI to surveil at least one federal agency’s communications for hostility to President Trump and his agenda. Reuters wrote that the DOGE team has heavily deployed Musk’s Grok AI chatbot as part of their work slashing the federal government, although Reuters said it could not establish exactly how Grok was being used.
Caturegli said while there is no indication that federal government or user data could be accessed through the exposed x.ai API key, these private models are likely trained on proprietary data and may unintentionally expose details related to internal development efforts at xAI, Twitter, or SpaceX.
“The fact that this key was publicly exposed for two months and granted access to internal models is concerning,” Caturegli said. “This kind of long-lived credential exposure highlights weak key management and insufficient internal monitoring, raising questions about safeguards around developer access and broader operational security.”
Could someone explain to me how something like this would occur? What was the possible cause for someone on the team to publish a private API key? In this case is an API key needed to push to GitHub, I’m wondering how would that end up in the files apart from on purpose? I don’t know much about these subjects so maybe someone with more insight could offer an explanation. Thanks for any help.
Typically this has occurred through an error on the users behalf where an API key file is copied into a repository while writing scripts or code that makes calls to the api. This was very likely not deliberate but speaks to either a lack of experience or knowledge around how to handle sensitive information. In other words a rookie mistake
It is very easy to do this inadvertently. Rushed projects are another reason for that mistake. It speaks of on-the-fly developmentalso.
This is very common. Developers write tests inside the repos and run the git add command without checking anything. They neither add anything to the ignore file, so many keys are constantly being pushed to GitHub and all other Source Controls. Supposedly, GitHub has key detection to prevent this from happening, but it mainly detects AWS keys, GCP keys, etc. Your key may pass the evaluation process if it has a high entropy. In our company, we ask the developers to run a SAST tool to find secrets in the commits before they get pushed to the repos. There are plenty of Google Dorks examples to look for those keys around, and you will be surprised how many are out there. Too many.
I’m not a developer, but I wonder why developers are publishing this regardless to a public repository instead of a private one. Especially since SpaceX is a government contractor. Maybe a simple case of Musk not wishing to pay for something as ‘inefficient’ as an internal repo license and infrastructure?
Oh no. But that would be akin to government waste. We couldn’t possibly deny C-Suite and our investors of their hard earned bonuses.
The developer made some sort of program that uses the API key, and the API key was stored in a settings file (.env).
When publishing the program, the dev accidentally pushed the settings (with the api key inside) to a public repository.
A good practice is to never publish these environment variables / settings to github, even not into private repos.
But it’s a very common mistake, hence entire companies focusing on detecting these mistakes as their core business.
So comforting to know that Musk’s DOGE dwarves are right now writing a master API for all government databases.
When I do development, I set it up so any type of credential is generated during installation and is not part of the source at all. Those credentials are also stored in locations separate from any source controlled directories, so there is nothing that can accidentally be uploaded to source control.
Given that code parameters require deliberate efforts to use an indirect reference to secrets, millions of keys are uploaded to GitHub. They charge for the feature that can detect and prevent it, and it’s also imperfect in what patterns it detects, so even catching poor practices already in play requires a 4th layer for high confidence that oversights are mitigated (peer review + scan when code is committed + regular scans + 3rd party scan). GitHub supports the first 3 for Enterprise licenses. The 4th can run on the Dev workspace, in the build pipeline, out of band – and a 5th can also be scanning the live application.
What makes this worse is that AI coding is trained on examples that follow poor practices, so it encourages devs to fall for it.
https://www.techmonitor.ai/technology/cybersecurity/10-million-exposed-credentials-open-source-code-repositories?cf-view
This is why lazy vibe coding is so dangerous. Once the secret sprawl sets in, you’re compromised forever.
#LLM
What’s the big deal here? This is freedom of speech, in general. 🙂
But thanks to Comrade Krasnow, freedom of speech has long since been abolished in the USA…
Microsoft own Github and they also create chatbots and LLMs. I’d be surprised if they didn’t know what was in their own back yard…
We’ll all end up writing anything important in cursive on yellow-lined paper
“DOGE is using AI to surveil at least one federal agency’s communications for hostility to President Trump and his agenda.”
1984 is here! (Only Trump would not realise the significance of that comment)
The idea that the Muskrats are digging through communications “for hostility” not just to a man but also his agenda (which seems to include breaching the Constitution) is Maoist. Chatting or even off-message comments on company email is always unwise, but who is to say that Musk and his Muskrats are not also scanning X-Twitter for disloyalty and speech crimes?
Does “supporting his agenda (which seems to include breaching the Constitution)” smell a bit of disloyalty to the US and its Constitution?
Seems to me we’ve gone way past 1984 and this is the biggest breach of the Constitution ever before. I just hope there is some way that this can be repaired before there’s no turning back. And if I’m not mistaken I’ve read that any and all hostilities toward the administration is being rooted out.
That’s the life of a programmer. Does anyone have any idea how it got leaked? Did he commit the key to a public repo?
Do jaké míry by mělo být možné přizpůsobovat LLM modely pomocí dat z firem jako Tesla nebo SpaceX, a jak chránit tyto modely před zneužitím?
LLM programy jsou užitečné jen do té míry, do jaké jsou užitečná data, na kterých se trénují. Pokud jsou tato data „proprietární“, „citlivá“, „obchodní tajemství“ atd., v současné době, pokud vím, neexistuje žádný spolehlivý způsob, jak je zabezpečit, pokud k nim má veřejnost povolen přístup. Tyto údaje jsou určeny pouze pro interní použití. Někdo se zeptal, proč umisťovat citlivé interní věci do veřejného cloudu místo do soukromého, a neexistuje žádná dobrá odpověď. Totéž platí pro otázku, proč umisťovat soukromé podpisové klíče a pevně zakódované přihlašovací údaje a tak dále do gitu/cloudu/čehokoli jiného, neexistuje žádná dobrá odpověď.
To what extent should it be possible to customize LLM models using data from companies like Tesla or SpaceX, and how can these models be protected from misuse? and what is the responsibility of developers when managing sensitive data (such as API keys) in code repositories
Considering there’s been legal action over the relationship between Tesla and xAI, Tesla investors should be asking themselves why Telsa’s proprietary data (which a massive portion of the companies valuation is based upon) was given to xAI for free for any such model trained on tesla data…
The number of Elon and Tesla “fan boys” is down to just those people purely wiling to turn a blind eye to his character, his lack of ingenuity, and his carelessness. I am guessing that Tesla owner data was accessible via the API? I have to think there is a huge amount of data collection done on those who still own one.