Suspicious Tag Movement in AWS’s GitHub Action: What Happened and Why It Matters

On 4th August 2025, an unusual event occurred in AWS’s popular GitHub Action repository aws-actions/configure-aws-credentials: the release tag v4.3.0 was created, deleted (unpublished), and then re-created to point at a different commit later the same day.  

In other words, the tag “moved” from one commit to another. For seasoned security engineers, a moving tag is extremely rare and often a red flag. Git tags – especially version tags for semantic releases – are generally treated as immutable references. When a tag that’s already been published is changed or re-tagged to a new commit, it can signal that something went wrong, potentially even a supply chain compromise.

In this case, StepSecurity’s automated monitoring systems immediately flagged the event as suspicious.  

Was the AWS repository hacked? Had an attacker silently replaced the code behind version 4.3.0? As it turns out, the truth was more harmless: the AWS team had “unreleased” a broken update and then fixed it. But the incident provides a valuable lesson. Even a harmless release can trigger the same indicators as a malicious attack, underscoring why tag movements deserve close scrutiny.

What Happened: Tag v4.3.0 Created, Unreleased, and Recreated

The configure-aws-credentials action—a popular GitHub Action used by over 225,000 repositories—had an eventful release on August 4, 2025. Below is a timeline of the key events that led to the tag being moved (re-pointed) to a new commit:

• Initial Release (17:49 UTC): The v4.3.0 tag was first created by an automated release workflow, pointing to commit 59b44184. This marked the official release of version 4.3.0 of the action.

• Bug Discovered (18:16 UTC): Minutes later, a critical bug was reported – the new v4.3.0 release broke proxy support for the action . This meant anyone using v4.3.0 would encounter failures in proxy functionality.

• Tag “Unreleased” (≈18:34 UTC): The AWS maintainers decided to pull the faulty release. The v4.3.0 tag was deleted (in effect, making v4.2.1 the latest available version again) . This is an unusual step, essentially unpublishing a release tag due to the severity of the bug.

• Fixes and Changes (18:34–20:34 UTC): The team rushed to patch the issue. Multiple commits went into the repository to revert the problematic change and apply a proper fix for the proxy bug . These included reverting a prior PR and updating the code to properly set the proxy environment variable.

• Forced Re-release (20:34 UTC): A second release workflow was initiated to publish a corrected v4.3.0. The maintainer included a Release-As: 4.3.0 directive in the commit message, instructing the release automation (Release Please) to re-use the version number 4.3.0 rather than bumping to a new version . This was necessary because the original 4.3.0 had been “unreleased” and they wanted to reissue the same version after the fix.

‍

Tag Recreated (20:47 UTC): Once the fixes were merged (specifically, the merge commit d0834ad from PR #1419), the release automation re-created the v4.3.0 tag – this time pointing to the new fixed commit instead of the original buggy one . In the build logs, Release Please noted it was “Creating 1 release for pull #1419,” indicating the tag was tagged to the new code.

Essentially, the tag moved from commit 59b44184 to commit d0834ad within a few hours.

This sequence of events explains how the tag ended up “moving.” It was first created on one commit, then later deleted and reassigned to a different commit once the issue was resolved.  

First tag location: 59b44184 (created at 17:49:16Z, original release commit)

Final tag location: d0834ad (created at 20:47:54Z, after fixes – the tag was moved to this commit)  

Such tag churn is highly atypical in normal release practice. Let’s explore why this drew attention from a security standpoint.

Why Tag Movements Are Rare Red Flags and When They’re Malicious

In typical development workflows, once a semantic release tag is pushed, especially one already distributed to users, it is expected to remain fixed. Moving a tag to a new commit, or deleting and reusing it, is rare because it can confuse downstream users and automation. From a security perspective, this is even more alarming because it can indicate that an attacker has modified a release after the fact, pointing the version to malicious code. Tag tampering is a known tactic in software supply chain attacks, and even when the cause is legitimate, the pattern is indistinguishable from a potential compromise until it is investigated.

That is why, in security practice, a moved tag is treated as “guilty until proven innocent.” History shows this caution is justified because the ecosystem has already seen real examples where tag movements were not harmless accidents but deliberate attacks.

Lessons from tj-actions and reviewdog

Two notable incidents from March 2025 illustrate how malicious tag tampering can compromise thousands of projects:

• tj-actions/changed-files Compromise (Mar 2025): Attackers gained write access to the repository of a widely used GitHub Action (tj-actions/changed-files). They then updated multiple version tags to reference a malicious commit. In effect, all existing tagged versions (for example, v34, v35, etc.) were silently repointed to malware. The malicious commit ran a Python script that dumped CI/CD secrets from the runner and exposed them in build logs . StepSecurity Harden Runner detected the tag tampering within three hours of the compromise, triggering an investigation before the attack could spread further. Despite this, the manipulation still impacted some repositories that trusted the Action, leading to secrets being leaked from many CI pipelines. GitHub later removed the action and all malicious tags, and a CVE was assigned to the incident.
  

• reviewdog/action-setup Compromise (Mar 2025): In a related attack, the v1 tag of the reviewdog/action-setup action was briefly pointed to a malicious commit containing a base64-encoded payload designed to steal secrets. The reviewdog actions are used as dependencies in many other composite actions, so this one tag change potentially compromised multiple actions in the reviewdog ecosystem. During the window when the v1 tag was hijacked (around 18:42–20:31 UTC on March 11, 2025), any workflow pulling reviewdog/action-setup@v1 would actually run the exploit code. This stealthy tag move was later uncovered by security researchers and confirmed by the maintainers. It demonstrated how an attacker’s subtle retagging of an existing semantic tag can have cascading effects on many projects.

These incidents prove that a moving tag is more than a curiosity — it is a known attack vector. While the AWS v4.3.0 case was harmless, it followed the exact same pattern as these malicious compromises, which is why it triggered an immediate investigation.

Automatic Detection by StepSecurity’s Artifact Monitor

This tag change was caught automatically by StepSecurity’s Artifact Monitor. StepSecurity’s Artifact Monitor continuously watches software releases (tags, packages, etc.) for signs of tampering or abnormal behavior. In this scenario, the monitor flagged the “aws-actions/configure-aws-credentials@v4.3.0” release because the tag’s history deviated from the norm.

How did StepSecurity Artifact Monitor Detect it?  

We monitor for new tags/ updates to existing tags for over 3,000 popular GitHub Actions every few minutes. If an existing semantic tag has changed to point to a new commit, StepSecurity Artifact Monitor triggers a detection alert.  

By catching the tag movement within minutes, StepSecurity’s Artifact Monitor enabled an investigation to start right away. In a malicious scenario, such early detection can be the difference between a contained incident and a widespread compromise. In this AWS case, the monitor’s alert led to verifying the details of the change, which fortunately aligned with the maintainers’ public explanation of a release gone wrong.

Additional detections by Artifact Monitor

StepSecurity’s Artifact Monitor has also detected similar tag movement events in other popular GitHub Actions.

Cache Extension

‍

Firebase Action

In both cases, the tag changes were not malicious, but they could have been.

If such changes had been confirmed as malicious, StepSecurity would have flagged the Action as a Compromised Action.

Compromised Actions Policy

When StepSecurity identifies a compromised Action, it is added to our internal Compromised Actions List. Customers who have the Compromised Actions Workflow Policy enabled in their organization are automatically protected against using the compromised Action in their workflows.

You can learn more about the Compromised Actions Workflow Run Policy  

Explore this interactive demo to see how Compromised Actions Policy works:

Conclusion: Monitor Your Releases and Stay Ahead of Threats

The AWS v4.3.0 tag incident turned out to be a harmless release process mistake, but it served as a valuable fire drill for supply chain security. It showed that our tools and processes – in this case, StepSecurity’s Artifact Monitor – worked as intended by catching an anomaly in real time. Had this been a malicious retagging, that early detection could have saved countless downstream users from exposure.

For security engineers, the takeaways are clear:

• Treat unexpected tag changes as urgent incidents: They might be rare events like hot-fix tag recreations, but they could also be the first sign of a breach. It’s always safer to investigate quickly.
  

• Invest in automated release monitoring: Just as we monitor code changes and deployments, we should monitor our artifact releases and version tags. In a complex CI/CD ecosystem, manual oversight isn’t enough. A tool like StepSecurity Artifact Monitor can automatically compare each new release against your expected build pipeline and alert on anomalies (like a tag that wasn’t created by your normal process, or a tag that moves).
  

• Learn from past attacks: The tag tampering in the tj-actions and reviewdog cases was caught only after secrets had been stolen. Those incidents have led many in the community to tighten controls (for example, pinning actions to immutable commit SHA hashes rather than floating version tags). Proactively monitoring tags and releases adds another layer of defense to catch similar issues sooner.

In the end, the goal is to make sure that when the next “weird tag movement” happens — and sooner or later, it will — your team isn’t caught off guard. Whether it’s an honest mistake or an attack in progress, you’ll be ready to respond rapidly and protect your software supply chain.

StepSecurity’s Artifact Monitor, available in our Enterprise Tier, provides continuous, automated surveillance of critical GitHub Actions and other release artifacts — detecting suspicious tag changes within minutes and blocking compromised Actions before they run in your environment.

The next attack will not wait!!

Start your Enterprise Tier trial now and ensure you have the visibility and protection to stop it before it spreads.

‍