gittuf is a platform-agnostic Git security system. Prior to 0.14.0, an attacker with push access to gittuf's Reference State Log (RSL) can roll back the current policy to any previous policy trusted by the current set of root keys. gittuf determines the policy to load by inspecting the RSL. Except for the very first policy (which is automatically trusted given gittuf's TOFU model, or verified against manually specified keys), whenever an RSL entry that points to a new policy is encountered, gittuf validates that this policy is trusted. This is done by checking that the new policy’s root metadata is signed by the required threshold of the current policy's root keys. Because of this, an attacker with push access to the RSL may create a new entry that references an old policy (that is trusted by the most recent policy's set of root keys), thereby rolling back gittuf's policy to the attacker's chosen state. This vulnerability is fixed in 0.14.0.

Affected: Go: github.com/gittuf/gittuf

## Summary

An attacker with push access to gittuf's Reference State Log (RSL) can roll back the current policy to any previous policy trusted by the current set of root keys.

## Impact

gittuf determines the policy to load by inspecting the RSL. Except for the very first policy (which is automatically trusted given gittuf's TOFU model, or verified against manually specified keys), whenever an RSL entry that points to a new policy is encountered, gittuf validates that this policy is trusted. This is done by checking that the new policy’s root metadata is signed by the required threshold of the current policy's root keys.

Because of this, an attacker with push access to the RSL may create a new entry that references an old policy (that is trusted by the most recent policy's set of root keys), thereby rolling back gittuf's policy to the attacker's chosen state.

Note that the attacker cannot roll back the policy to one that would no longer be trusted by the most recent policy's root keys. As an example, say that Policy A's root keys were for Alice and Bob with a threshold of two, and then Policy B replaced Bob with Carol, with a threshold of two required. An attacker would not be able to roll back the policy to policy A, because it was signed by Alice and Bob, not Alice and Carol.

If you host your repository on a forge such as GitHub, GitLab, Bitbucket, etc., and only certain people are allowed to push to the RSL (e.g. only maintainers of your project have push access to th…

Affected: Ubuntu:25.10: gittuf, Ubuntu:26.10: gittuf, Ubuntu:Pro:26.04:LTS: gittuf

gittuf is a platform-agnostic Git security system. Prior to 0.14.0, an attacker with push access to gittuf's Reference State Log (RSL) can roll back the current policy to any previous policy trusted by the current set of root keys. gittuf determines the policy to load by inspecting the RSL. Except for the very first policy (which is automatically trusted given gittuf's TOFU model, or verified against manually specified keys), whenever an RSL entry that points to a new policy is encountered, gittuf validates that this policy is trusted. This is done by checking that the new policy’s root metadata is signed by the required threshold of the current policy's root keys. Because of this, an attacker with push access to the RSL may create a new entry that references an old policy (that is trusted by the most recent policy's set of root keys), thereby rolling back gittuf's policy to the attacker's chosen state. This vulnerability is fixed in 0.14.0.