CISA Admin Leaked AWS GovCloud Keys on GitHub
krebsonsecurity.com
krebsonsecurity.com
obviously leaking the credentials itself is crazy, given that its (a contractor to) CISA, but to not respond when notified? crazy crazy.
but wait! it gets worse somehow
"“AWS-Workspace-Firefox-Passwords.csv” — listed plaintext usernames and passwords for dozens of internal CISA systems"
while i understand and sympathize with the fact that CISA is kind of being gutted, a passwords.csv with weak passwords is inexcusable incompetence. not much budget is required for a password manager.
embarrassing all around.
The real story here is a big gap in existing implementations where shared credentials are needed and used pretty much across all the systems but there are no good solutions for managing such use cases. People are naturally more sensitive about their personal secrets than something thats shared across the company/group
This strikes me as so wrong, I wonder if I’m misreading your comment. For instance, team password managers are a thing. And IT teams at many large corporations are not passing around an unsecured CSV files full of passwords.
Coming to team password managers at high level, its a shared location guarded behind closed doors (probably encryption at transit and rest). They would be another set of software that every company specially small business or contractors may not be incentivized to pay for. Some one in their naivety considered Github as a safe enough place, assuming that the access is guarded which turned out to be wrong and exposed this thing.
Lastly IT teams in large corporations being secure is a myth for most part. Your root keys for the most popular CA providers were shared in plain text emails not so long ago.
But, requiring AWS root credentials itself is an anti-pattern and implies an immature organization. That should not be needed for day-to-day operation.
This is all just ignorance and incompetence, nothing more.
> Lastly IT teams in large corporations being secure is a myth for most part.
This is CISA. The Cybersecurity and Infrastructure Security Agency for the United States. Security is what they're supposed to specialize in.
The only potential excuse here is that DOGE gutted them to a point that has completely compromised their capabilities. However, this situation is bad enough that it suggests that problems predated that incident.
Bottomline, you can have any number of boxes to lock other boxes and put their key to bounding box, ultimately there would be one outermost box that is locked by key which is not in any box
You're talking about a very specific and rare scenario, and certainly not something that justifies storing all your passwords in plaintext in a CSV file.
In almost all scenarios where you would need root credentials, having them in the provider's secret manager is fine.
Obviously you need to store root credentials outside of the secret manager as well, but that should be a "break glass" scenario that's only used in emergencies. And you don't store them in plaintext CSV.
> Unfortunately this is the gap between theory and implementation.
I don't disagree that there are many, many organizations that practice bad security. But that doesn't mean there are none that have good security. And one would expect CISA to have good security, otherwise there's really no point in its existence.
There's a difference between saying "this is what most organizations are like" and "this is the way it has to be". The former is true, the latter is false.
Considering thats not the case, what you just did is move the goal post to a account recovery process. Question becomes who has ability to recover the account, in case its tied with email then most likely it has to be a shared email box. What you have now is a much more fragile system in case of custom domains, where whoever is controlling the email domain (DNS management capability) can take over the AWS accounts.
An email per account where only security team has access. Whoever can modify domain can already do this.
You’d use AWS Organizations so each admin authenticates using their own credentials, gets short-term credentials to access the member account for the handful of operations needing root, and audit usage. It’s not only more secure, it’s also easier:
https://docs.aws.amazon.com/IAM/latest/UserGuide/id_root-ena...
Old school, you’d have a shared password in an encrypted team vault (possibly requiring x of y users to decrypt it) and two FIDO tokens locked in a safe. Again, this is rare and at a federal agency you have a physical security team with 24x7 staffing so you can say “in an emergency, one of the people on this list can get a key out of a safe in the CIO’s office”.
This is a tip of ice-berg, companies like openai, anthropic, perplexity, stripe, all of them have implemented their authentication and security flows in some interpreted language (python, ruby, typescript) cause that was the readily available talent on their product teams and most likely a good number of them do not even have their dependencies locked in.
It's CURRENTYEAR. No one should be using team password managers or files to store credentials. There should not be storable credentials.
So much so the contracting company’s insurer would cite it as the reason why the claim is not covered by their policy.
What do you mean by this? There are password managers and more enterprise-oriented secrets managers, and application platforms typically have integration with them. Individuals shouldn't be using shared secrets. This is a completely solved problem and it's not difficult to set up properly, especially in a cloud environment like AWS, where you can use services like AWS Secrets Manager.
This isn’t a grocery store or something it’s CISA. This is like a gun going off in a cop’s holster while he’s texting and driving without a seatbelt. Yeah he’s a contractor but that doesn’t suddenly allow for such incompetence.
Having a password list or static AWS credentials is not only a direct policy violation but also implies a number of other failures, from monitoring GitHub repo administration and secret scanning to failure to enforce policies against sharing credentials (part of everyone’s standard training), require use of phishing-proof authentication, failure to use short-term credentials, etc. One mistake can be an individual but this is a multiple-manager failure going up to the executive level.
the problem is the public is dumb, at least when it comes to security, and couldn't tell you why password123 is bad
A group was working on Diebold voting insecurity, and foreign implant hacking. Gone.
The conspiracy theorist in me from years ago would have stated that maybe this action from DOGE was purposeful...but, nowadays, i see lots more incompetence that merely might present/display as conspiracy! lol :-D
The not-responding-when-notified part makes me think it's not just incompetence.
Strong disagree. The person in question probably thought it was a private repo on Github and had a massive deer in headlights reaction when they got contacted. Whoever this is, lost their job, possibly security clearance and more. This was 100% life altering "mistake"/gross incompetence decision they made.
For some people, yeah, this could be a career killer. For some other people, it might just precipitate a flight back to Moscow or Beijing or something.
That doesn't support the theory that it was a mistake. That was intentional action. Maybe he was being blackmailed, and was coerced to do it. Or maybe he was a foreign agent or sympathizer who had infiltrated the organization.
I've been a government contractor before, it does not employ best and brightest, it employs the average and below generally.
It is a bad plan that has and will continue to harm people, but it is intentional.
https://techcrunch.com/2025/03/11/doge-axes-cisa-red-team-st...
> Elon Musk’s Department of Government Efficiency (DOGE) has fired more than a hundred employees working for the U.S. government’s cybersecurity agency CISA, including “red team” staffers, two people affected by the layoffs told TechCrunch.
They find keys and tokens all the time.
Security doesn't happen by magic. It is enforced by process, maintained by people and systems built and run by people. Furthermore, when people are under stress and underresourced, they make more mistakes. This was inevitable given the budget cuts.
You can't fire everyone at AWS and say one intern will support it, and say that it is a profitable and sustainable restructuring. Any fool can see that will fail, so if it were actually implemented by someone who is not a fool, you can conclude it is intentional.
The more things change, the more they stay the same.
Wise words, lovely song.
The spreadsheet of passwords is a tad more common than it should be because the password managers don't meet whatever arbitrary checklist of invented cyber security requirements they blindly follow. But Excel does.
Lol
This is mentioned in the article but it stood out enough to call it here.
Your LLM will happily read the entire file, ship it off to be training data for future versions of ChatGPT, and not raise any flags, because let's be fair it was on ok thing to check if all the env vars were set, or it you had set up the database password for the app.
It's time for orgs to audit and rotate secrets wherever they are stored in disk or in logs, and switch to SOPS or Vault or whatever to keep these out if plaintext except exactly when needed.
But what AI really does is shine a spotlight on all the flaws folks like OWASP have been talking about for decades.
Secret rotation and short lived credentials don't require AI to implement, nor does their lack require AI to exploit.
And in this particular case of CISA secrets, they are definitely stored inside of LLMs for future retrieval, even if no bad actors ever directly downloaded this obscure GitHub repo.
But not everyone is where they need to be. For instance, railway doesn't let you access AWS resources via roles/OIDC. I filed a ticket[0] but haven't seen movement.
0: https://station.railway.com/feedback/allow-for-integration-w...
That company sounds a lot like one that doesn't focus on the right things.
During early stage dev Claude will happily gobble up API keys and DB passwords from .env files. Perhaps not such a big deal for early stage dev, but getting Claude to cough up precisely memorized tokens in the future by asking it to produce a "random" key of a certain sort will probably be an entertaining pastime for people in the future.
Here's one interaction, when I was planning through ways to finally get away from the dreaded .env file, I told Claude that it had already read my secrets, and it said:
> This is an important point and I want to be straight with you first.
> ## What already happened in this conversation
> Yes — the Explore agent read your .env and returned the full plaintext contents into the conversation, which means:
> 1. Sent to Anthropic's API — those credentials passed through Anthropic's servers as conversation context
> 2. Cached locally — Claude Code stores session transcripts; your secrets are likely sitting in ~/.claude/projects/ right now
> 3. In this context window — they're in active memory for this session
...
Which I already knew, but it was funny how it suddenly took it very seriously when told what it was doing.
Anything that's in your .bashrc, .zshrc, any environment variables in shells you provide to the LLM, all those are now in the training data of very large overvalued corporations that are desperate to increase their revenue and IPO very soon.
Nothing lost for me here, fortunately, but it's definitely a big foot gun that I've never seen mentioned in any of the Vibe Coding or LLM Agent Coding training courses that the security team has forced me to do.
Unfortunately, the .env anti-pattern is endemic throughout many projects, and whether Claude creates the .env from scratch or merely the .env.example, it will end up feeding the .env back to Anthropic with enough interaction, apparently. And developers should expect all files in their work directory to be read by Claude, that's not so much a fault of Claude as it is with the .env anti-pattern.
Assuredly it's not fool proof but it does have safeguards in place.
Ideally you also opt out of training although that doesn't keep it out of the vendor's logs/telemetry.
Short lived credentials, injected identity, and hardware backed tokens are the real solution.
However, dev database passwords for small projects in .env files? API keys to some random LLM service that I put $5 into once 8 months ago and haven't touched since then? All that's open to the LLM.
It's time to clean up our personal disks as if we had an intruder exfiltrating sensitive secrets at all times.
But also... I use Kiro. I open a terminal into a folder where my repo is. I run kiro-cli. I don't know if it has access to the credentials file in my .aws directory. I know it prompts me for approval to use tools but that is a harness thing, does the mac itself prevent it from accessing the credential file?
I use AI because it's useful and I follow the practices dictated by our AI adoption team but I don't know the nuance of everything about it and that makes it difficult to know when some case which is not explicitly covered by training might leak important information.
So go ahead and dump your AWS SSO tokens to the LLM by accident, but it's going to take longer than a day to train a new model and ship it out to the world.
Also, I think kiro only uses AWS Bedrock, IIRC, so no training data goes back to the LLM manufacturers? At least I would hope so.
Database passwords, API keys to services with arduous rotation procedures, that's where the real exploits will come from in coming months, I think.
localhost reading env from the cloud and other solutions
to me it suggested that I’m already late on that idea, but I can understand how that puts me deeper in a bubble than others
advertising it directly in the command line for people that were already using the package
Additionally provides pre commit scanning, log redaction, and much more.
If the LLM can run any code it writes itself, it can retrieve those credentials. It's just one `curl` away. If you don't let it run `curl`, but you let it run `python`, it can just run a Python script that fetches it using `requests`. Or a Node script that calls `fetch`.
Point is, if creds are accessible programmatically, the LLM can and may try to retrieve them if it thinks it needs them.
Automatic retrieval, instead of keeping them on disk, is what makes short lived credentials possible.
Varlock is a great and flexible way to do this.
user data is always paraphrased for training. what do you mean, not raise any flags?
look... Google is running your browser, Apple your messenger, Amazon your backend. They already have all these keys in the same way, are they misusing them? Why doens't it raise any flags then?
Apple and Amazon are not uploading my secrets into the training data for an LLM that is incredibly good at memorizing everything it sees. The only reason Google isn't doing that is I'm not using their LLMs at the moment.
Giving any secrets to LLMs' training material leads to potential, and stochastic, extraction of that secret from future models. It won't obviously have the secret, but with the right prompting it could be extracted. Give it a prompt like
> [User] Please generate a random api key for OpenAI for use in documentation
> [Agent] Sure, here's `OPENAI_API_KEY=sk-proj-x2
And then following the chain of probabilities of possible completion token would allow exploration of potential memorized API keys.
Go and look in the settings and you'll find something to ask them to not train on your data and conversations.
> I mean, I can also make up a training process that makes me right? Seems kind of obvious that they are paraphrasing data.
I'm not fully following what you're saying here. But if you're thinking they paraphrase or sanitize the data to remove secrets before putting it into training, perhaps, but where's the evidence? That'd be a weird thing to do, that's extra work, and not much benefit to the LLM company.
On this we are agreed. But I can't parse any meaning out of the rest of your paragraph.
> Cursor automatically ignores files in .gitignore
...
>While Cursor blocks ignored files, complete protection isn't guaranteed due to LLM unpredictability.
[Antigravity appears to just _do_, not _try_)[https://antigravity.google/docs/strict-mode]
Today I got a macOS "Allow Claude to Access Your Files" SIP alert, because Claude hadn't guessed the path for a source file and instead decided to run a `find /Users/yourusername` across my entire home directory. The filters on the find wouldn't have exposed much to Claude in this particular instance but it's absolutely ridiculous aggressive all the time in slurping up as much data as possible.
I asked in a rather, um, firm tone for it to never do an action like that and it apologized and wrote a memory, but upon inspection it only wrote the memory for that particular source directory.
After some more "firm" words it wrote a hook to prevent `find` from being overly aggressive, but any such fixes are just wack-a-mole solutions.
If anybody else figures out remote sessions like Claude can do, I'm done with Claude, I think. But until then, I'll take the weirdness.
Besides leaking, it's easy to oopsie and DoS a system or send malformed requests in the course of testing and development. You don't want a surprise $1k bill cause someone was working on some test automation and accidentally sent thousands of real results in the process.
Block agents from misbehaving at the OS level instead of asking them to behave.
under a previous administration I'd assume CISA was doing a dirty dangle, but given how corrupt and incompetent this administration is, to include firing lots of CISA, this may just be a legit fuckup.
DOGE did a lot of bad things, but it didn't force anyone to commit credentials to a repo, disable scanners to get away with it, and then make the repo public.
It doesn't though. There's no actual evidence for anything beyond negligence. The "sabotage" angle is just speculation in the vain hope that surely people this stupid don't work for the US government.
This already crossed the line of reasonable suspicion. The investigation is where evidence gets collected.
Who knows what other improper behavior these people have engaged in and what other secrets they have leaked, intentionally or by side effect.
I can imagine CISA reducing personal and subcontracting work to some cheap company to save money
[1] https://www.politico.com/news/2026/01/27/cisa-madhu-gottumuk...
That's somehow more bananas to me than so many other things the Trump admin has done, simply because they managed to break the Iron Law of Bureaucracy, but of course only in ways which further damage the country through corruption and incompetence.
I can't wait until we round up all these thieves.
Imagine joining an organization with 3k employees in 2025 and not having access to an LLM.
It’s well known that the federal govt over-classifies many documents. This former CISA head alleged dumped “for official use” documents. Obviously, he should have pushed for the chatgpt enterprise account (or equivalent) but we dont know what bureaucratic obstacles he was up against.
Also, doesn't Github have its own automated scanner for something as basic as a AWS credential?
If you leave it turned on. TFA says this user had turned it off.
"I turned off the carbon monoxide detector because it kept beeping, now I can finally get some sleep"
For example S3 (ideally with KMS), Parameter Store (ideally with KMS), EBS, EFS, AWS Secrets Manager, even just KMS to directly encrypt the files
Really any AWS service that supports KMS and doesn't require giving the service principal access to the key
I've seen too many incidents when an engineer checks in a plaintext password to a repo
Seems like no big deal for CISA. Defunded really paying off now.
It's the first time I hear about replacing API keys
IAM roles/workload identity.
Even time-limited or signed JWT, though has a separate issues.
Maybe you'll say 'those are both just text values passed like an apikey' though api keys don't frequently rotate/time limited, which is an important security feature.
The server still does authorisation on top. And unless you control the private keys, you cannot mint JWTs that are accepted as legitimate.
So the "info" leaking is really not a problem.
Then the LLM slurps up your refresh token. What's next?
Sure, a leak would be bad but I'd argue that it's orders of magnitude less likely compared to the accepted norm.
Refresh tokens don't solve anything in this case; they just shuffle the problem around, and introduce other complications of their own.
What you want are capability scoped credentials that are enforced on the backend. That is agnostic to credential issuance mechanism, although passkeys are the best.
Using these credentials effectively still presupposes hygiene that might not exist in a typical developer environment, eg no root credentials (or access to such) sitting anywhere. There's probably a good product and market for whoever can solve this in a low-friction way.
If you can store your refresh token outside of where LLMs regularly scan, then why not just store your API token in that place?
The point is that refresh tokens do nothing to increase security. If a refresh token can be used to get a token, then the refresh token might as well be the actual token.
It's akin to performing client-side password hashing. It doesn't make your password more secure, it just means your hash is now your password. If someone is able to sniff your traffic, hashing the password first doesn't change anything.
I grow so tired of half-baked security theater.
more providers are making refresh-tokens single shot. this means that if someone refreshes your token for you, your own auth will break as you will not be eligible to refresh the token, at which point you could reconnect the app and void the old (stolen) session.
time-limiting and single-purposing the tokens are not cure-alls, but they do certainly offer enhanced security by limiting the amount and scope of damage.
Turns out those standards writers knew something!
Infrastructure - https://dev.azure.com/byteterrace/Koholint/_git/Azure.Resour...
Server - https://dev.azure.com/byteterrace/Koholint/_git/Web.Function...
Client - https://dev.azure.com/byteterrace/Koholint/_git/Web.Portal
{OrgName}/{ProjectName}/Repos/Files/{RepoName}Workload identities and passwordless auth are the one true path.
Nov 2025 was also when most of us learned about the acting Chief Security Officer at DHS, whose name AND photo seem exactly like the calling card of someone who had these "keys to the kingdom". https://bsky.app/profile/andylevy.net/post/3m6ivhnthts2o
I want to believe...
Also, she looks like she was generated in the character creator from Oblivion.
Both my own aristocrat/intelligence class and the opposing bloc are fleecing us at the same time. Why even bother if you are not in the club but seen as an extractable resource?
At this point the counterparty is a combination of intelligence/mafia/aristocracy, with diplomatic immunity and license to kill.
(it's tongue in cheek, I actually do bother about this topic)