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.
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:
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.
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.
Two notable incidents from March 2025 illustrate how malicious tag tampering can compromise thousands of 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.
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.
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.
StepSecurity’s Artifact Monitor has also detected similar tag movement events in other popular GitHub Actions.
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.
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:
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:
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.
此内容由惯性聚合(RSS阅读器)自动聚合整理，仅供阅读参考。 原文来自 — 版权归原作者所有。