{"id":6141,"date":"2025-12-10T02:11:28","date_gmt":"2025-12-10T02:11:28","guid":{"rendered":"https:\/\/cybersecurityinfocus.com\/?p=6141"},"modified":"2025-12-10T02:11:28","modified_gmt":"2025-12-10T02:11:28","slug":"github-action-secrets-arent-secret-anymore-exposed-pats-now-a-direct-path-into-cloud-environments","status":"publish","type":"post","link":"https:\/\/cybersecurityinfocus.com\/?p=6141","title":{"rendered":"GitHub Action Secrets aren\u2019t secret anymore: exposed PATs now a direct path into cloud environments"},"content":{"rendered":"
\n
\n
\n
\n
<\/div>\n

Many enterprises use GitHub Action Secrets to store and protect sensitive information such as credentials, API keys, and tokens used in CI\/CD workflows. These private repositories are widely assumed to be safe and locked down.<\/p>\n

But attackers are now exploiting that blind trust, according to new research<\/a> from the Wiz Customer Incident Response Team. They found that threat actors are using exposed GitHub Personal Access Tokens (PATs) to access GitHub Action Secrets and sneak into cloud environments, then run amok.<\/p>\n

\u201cThe root cause issue is the presence of these secrets in repos,\u201d said David Shipley<\/a> of Beauceron Security. \u201cCloud service provider access keys are gold, they can be extraordinarily long lived, and that\u2019s what [attackers are] sniffing around for.\u201d<\/p>\n

GitHub Action Secrets aren\u2019t secrets anymore<\/h2>\n

Wiz estimates that 73% of organizations using private GitHub Action Secrets repositories store cloud service provider (CSP) credentials within them. When PATs, which allow developers and automation bots to interact with GitHub repositories and workflows, are exploited, attackers can easily move laterally to CSP control planes.<\/p>\n

PATs can become a \u201cpowerful springboard\u201d that allows attackers to impersonate developers and carry out a range of activities, explained Erik Avakian<\/a>, technical counselor at Info-Tech Research Group. It\u2019s like having a backstage pass into a company\u2019s cloud environments, he said.<\/p>\n

\u201cOnce they\u2019re holding that valid PAT, they can do all sorts of things in GitHub that lead directly back into a company\u2019s AWS, Azure, GCP, or other types of cloud services, because GitHub treats that PAT like the real developer,\u201d he said.<\/p>\n

With that access, threat actors can \u201cpoke around\u201d various repositories and workflows and look for anything that hints at cloud access, configuration items, scripts, and hidden secrets, he noted. If they get access to real cloud credentials, they \u201chave the keys to the company\u2019s AWS bucket, Azure subscriptions, and other workflows.\u201d<\/p>\n

They can then spin up cloud resources, access databases, steal source code, install malicious files such as crypto miners, sneak in malicious workflows, or even pivot to other cloud services, while setting up persistence mechanisms so they can return whenever they want.<\/p>\n

\u201cAt that point, basically anything you can do in the cloud, so can they,\u201d said Avakian.<\/p>\n

Easily evading detection<\/h2>\n

Wiz found that a threat actor with basic read permissions via a PAT can use GitHub\u2019s API code search to discover secret names embedded directly in a workflow\u2019s yaml code, accessed via \u201c${{ secrets.SECRET_NAME }}<\/em>.\u201d<\/p>\n

The danger is that this secret discovery method is difficult to monitor because search API calls are not logged. Further, GitHub-hosted Actions run from GitHub-managed resources that use legitimate, shared IP addresses not flagged as malicious. Attackers can abuse secrets, impersonate workflow origins to exploit trust, and potentially access other resources if code is misconfigured or reused elsewhere in the workflows. They can also persistently access the system.<\/p>\n

In addition, if the exploited PAT has write permissions, attackers can execute malicious code and remove workflow logs and runs, pull requests, and \u2018created branches\u2019 (isolated copies of codebases for dev experimentation). Because workflow logs are rarely streamed into security incident and event management (SIEM) platforms, attackers can easily evade detection.<\/p>\n

Also, notably, a developer\u2019s PAT with access to a GitHub organization makes private repositories vulnerable; Wiz research found that 45% of organizations have plain-text cloud keys stored privately, while only 8% are in public repositories.<\/p>\n

Shipley noted: \u201cIn some developers\u2019 minds, a private repo equals safe, but it\u2019s clearly not safe.\u201d<\/p>\n

How enterprise leaders can respond<\/h2>\n

To protect themselves against these threats, enterprises should treat PATs as they would any other privileged credentials, Avakian noted. Cloud infrastructure and cloud development environments should be properly locked down, essentially \u201czero trustifying\u201d them through micro segmentation and privileged user management to contain them and prevent lateral pivoting.<\/p>\n

\u201cLike any other credentials, tokens are best secured when they have reasonable expiration dates,\u201d said Avakian. \u201cMaking tokens expire, rotating them, and using short-lived credentials will help thwart these types of risks.\u201d<\/p>\n

Least privilege everything and give accounts only the rights they need, rather than an \u2018admin everything\u2019 approach, Avakian advised. More importantly, move cloud secrets out of GitHub workflows and ensure that the proper amount of monitoring and log review processes are in place to flag surprise or unexpected workflow or cloud creation events.<\/p>\n

Beauceron\u2019s Shipley agreed, saying that enterprises need a multi-pronged strategy, good monitoring, instant response plans, and developer training processes that are reinforced with \u201cmeaningful consequences\u201d for non-compliance. Developers must be motivated to follow secure coding best practices; building a strong security culture in developer teams is huge. \u201cYou can\u2019t buy a blinky box for that part of the problem,\u201d he said.<\/p>\n

\u201cCriminals have stepped up their game,\u201d said Shipley. \u201cOrganizations don\u2019t have a choice. They have to invest in these areas, or they will pay.\u201d<\/p>\n

Also, stop blindly trusting GitHub repos, he added. \u201cThe nature of repos is that they live forever. If you don\u2019t know if you have cloud secrets inside your repos, you need to go and find them. If they\u2019re there, you need to change them yesterday, and you need to stop adding new ones.\u201d<\/p>\n

If there is an upside, he noted, it\u2019s that enterprises are \u201cvictims of their own success\u201d as they\u2019ve raised the bar with multi-factor authentication (MFA). Gains in general security awareness makes it more difficult for criminals to obtain access and identities and compromise systems.<\/p>\n

\u201cIn some ways, this is a good sign,\u201d said Shipley. \u201cIn a hilarious kind of way, it means [the criminals] are now moving into deeper levels requiring more effort.\u201d<\/p>\n

This article originally appeared on InfoWorld<\/a>.<\/em><\/p>\n\n<\/div>\n<\/div>\n<\/div>\n<\/div>","protected":false},"excerpt":{"rendered":"

Many enterprises use GitHub Action Secrets to store and protect sensitive information such as credentials, API keys, and tokens used in CI\/CD workflows. These private repositories are widely assumed to be safe and locked down. But attackers are now exploiting that blind trust, according to new research from the Wiz Customer Incident Response Team. They […]<\/p>\n","protected":false},"author":0,"featured_media":6142,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[3],"tags":[],"class_list":["post-6141","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-education"],"_links":{"self":[{"href":"https:\/\/cybersecurityinfocus.com\/index.php?rest_route=\/wp\/v2\/posts\/6141"}],"collection":[{"href":"https:\/\/cybersecurityinfocus.com\/index.php?rest_route=\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/cybersecurityinfocus.com\/index.php?rest_route=\/wp\/v2\/types\/post"}],"replies":[{"embeddable":true,"href":"https:\/\/cybersecurityinfocus.com\/index.php?rest_route=%2Fwp%2Fv2%2Fcomments&post=6141"}],"version-history":[{"count":0,"href":"https:\/\/cybersecurityinfocus.com\/index.php?rest_route=\/wp\/v2\/posts\/6141\/revisions"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/cybersecurityinfocus.com\/index.php?rest_route=\/wp\/v2\/media\/6142"}],"wp:attachment":[{"href":"https:\/\/cybersecurityinfocus.com\/index.php?rest_route=%2Fwp%2Fv2%2Fmedia&parent=6141"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/cybersecurityinfocus.com\/index.php?rest_route=%2Fwp%2Fv2%2Fcategories&post=6141"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/cybersecurityinfocus.com\/index.php?rest_route=%2Fwp%2Fv2%2Ftags&post=6141"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}