CVE-2026-44544
gittuf: Policy can be rolled back to prior valid version
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.
Attack profile
How easy it is to exploit
- Attack vector
- Network
- Complexity
- High
- Privileges needed
- Low
- User interaction
- None
What an attacker can affect
- Confidentiality
- None
- Integrity
- None
- Availability
- None
Exploit likelihood
What each source reports
CVE List Score used
gittuf: Policy can be rolled back to prior valid version
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.
- Record
CVE-2026-44544- CVSS 4.0
- 4.9 Medium
CVSS:4.0/AV:N/AC:H/AT:P/PR:L/UI:N/VC:N/VI:N/VA:N/SC:N/SI:H/SA:N - Weakness
- CWE-639
- Updated
- 2026-11-02
EUVDEUVD-2026-30348
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.
- Record
EUVD-2026-30348- CVSS 4.0
- 4.9 Medium
CVSS:4.0/AV:N/AC:H/AT:P/PR:L/UI:N/VC:N/VI:N/VA:N/SC:N/SI:H/SA:N - Updated
- 2026-11-02
GitHub AdvisoriesGHSA-vxvc-cg7j-rwqj
gittuf's policy can be rolled back to prior valid versions
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 the repository, and all other contributions must be done via pull request), then only those users with push access can perform the attack, or the forge itself.
Fix
gittuf version v0.14.0 introduces a monotonically increasing number to all policy metadata (not to be confused with the metadata version, which dictates the features supported by the metadata). This number is incremented whenever a gittuf client of version v0.14.0 or greater updates the metadata or invokes a patch command to add this field.
During policy verification, gittuf compares the monotonically increasing number of the new policy it encounters in the RSL to the current policy. If any file in the policy (e.g. root of trust, primary policy file, or delegated policy file) has this number, gittuf will check that it increases by one any time the respective file is changed.
Resolution
Upgrade gittuf and Apply Metadata Patch
gittuf strongly recommends users upgrade to the latest version to remediate this vulnerability. Specifically, gittuf version v0.14.0 (and above) are patched with respect to this vulnerability. All users who use gittuf to verify the repository or update its policy metadata must upgrade to prevent this attack.
After a consuming application applies the upgrade, a root of trust user or policy administrator must run:
gittuf trust increment-version
or:
gittuf policy increment-version
to add the monotonically increasing number field to the metadata (see Fix above).
Check for Rollback Attack Attempts
Because this attack requires the attacker to add an entry to the RSL, and because gittuf stores the RSL inside the repository, this attack cannot be performed without leaving evidence behind (in this case, the malicious RSL entry). To check for whether this attack was performed on your repository, run:
gittuf rsl log --ref refs/gittuf/policy
All RSL entries that record new policy states for gittuf should be displayed. There should be one RSL entry every time a legitimate, new policy was applied. Should users find an RSL entry which points to an older policy state, their repository has been compromised.
Credits
gittuf thanks Andrew Nesbitt (@andrew) for finding and responsibly disclosing this vulnerability.
- Record
GHSA-vxvc-cg7j-rwqj- CVSS 4.0
- 6.0 Medium
CVSS:4.0/AV:N/AC:H/AT:P/PR:L/UI:N/VC:N/VI:H/VA:N/SC:N/SI:N/SA:N - Weakness
- CWE-639
- Updated
- 2026-11-02
NVD
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.
- Record
CVE-2026-44544- CVSS 4.0
- 4.9 Medium
CVSS:4.0/AV:N/AC:H/AT:P/PR:L/UI:N/VC:N/VI:N/VA:N/SC:N/SI:H/SA:N/E:X/CR:X/IR:X/AR:X/MAV:X/MAC:X/MAT:X/MPR:X/MUI:X/MVC:X/MVI:X/MVA:X/MSC:X/MSI:X/MSA:X/S:X/AU:X/R:X/V:X/RE:X/U:X - Weakness
- CWE-639
- Updated
- 2026-11-02
OSV
gittuf: Policy can be rolled back to prior valid version
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.
- Record
CVE-2026-44544- CVSS 4.0
- 4.9 Medium
CVSS:4.0/AV:N/AC:H/AT:P/PR:L/UI:N/VC:N/VI:N/VA:N/SC:N/SI:H/SA:N - Weakness
- CWE-639
- Updated
- 2026-11-02
OSVDEBIAN-CVE-2026-44544
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.
- Record
DEBIAN-CVE-2026-44544- CVSS 4.0
- 4.9 Medium
CVSS:4.0/AV:N/AC:H/AT:P/PR:L/UI:N/VC:N/VI:N/VA:N/SC:N/SI:H/SA:N/E:X/CR:X/IR:X/AR:X/MAV:X/MAC:X/MAT:X/MPR:X/MUI:X/MVC:X/MVI:X/MVA:X/MSC:X/MSI:X/MSA:X/S:X/AU:X/R:X/V:X/RE:X/U:X - Updated
- 2026-11-02
Show 4 moreShow less
OSVGHSA-vxvc-cg7j-rwqj
gittuf's policy can be rolled back to prior valid versions
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 the repository, and all other contributions must be done via pull request), then only those users with push access can perform the attack, or the forge itself.
Fix
gittuf version v0.14.0 introduces a monotonically increasing number to all policy metadata (not to be confused with the metadata version, which dictates the features supported by the metadata). This number is incremented whenever a gittuf client of version v0.14.0 or greater updates the metadata or invokes a patch command to add this field.
During policy verification, gittuf compares the monotonically increasing number of the new policy it encounters in the RSL to the current policy. If any file in the policy (e.g. root of trust, primary policy file, or delegated policy file) has this number, gittuf will check that it increases by one any time the respective file is changed.
Resolution
Upgrade gittuf and Apply Metadata Patch
gittuf strongly recommends users upgrade to the latest version to remediate this vulnerability. Specifically, gittuf version v0.14.0 (and above) are patched with respect to this vulnerability. All users who use gittuf to verify the repository or update its policy metadata must upgrade to prevent this attack.
After a consuming application applies the upgrade, a root of trust user or policy administrator must run:
gittuf trust increment-version
or:
gittuf policy increment-version
to add the monotonically increasing number field to the metadata (see Fix above).
Check for Rollback Attack Attempts
Because this attack requires the attacker to add an entry to the RSL, and because gittuf stores the RSL inside the repository, this attack cannot be performed without leaving evidence behind (in this case, the malicious RSL entry). To check for whether this attack was performed on your repository, run:
gittuf rsl log --ref refs/gittuf/policy
All RSL entries that record new policy states for gittuf should be displayed. There should be one RSL entry every time a legitimate, new policy was applied. Should users find an RSL entry which points to an older policy state, their repository has been compromised.
Credits
gittuf thanks Andrew Nesbitt (@andrew) for finding and responsibly disclosing this vulnerability.
- Record
GHSA-vxvc-cg7j-rwqj- CVSS 4.0
- 6.0 Medium
CVSS:4.0/AV:N/AC:H/AT:P/PR:L/UI:N/VC:N/VI:H/VA:N/SC:N/SI:N/SA:N - Weakness
- CWE-639
- Updated
- 2026-11-02
OSVUBUNTU-CVE-2026-44544
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.
- Record
UBUNTU-CVE-2026-44544- CVSS 4.0
- 4.9 Medium
CVSS:4.0/AV:N/AC:H/AT:P/PR:L/UI:N/VC:N/VI:N/VA:N/SC:N/SI:H/SA:N - Updated
- 2026-11-02
OSVGO-2026-5683 No score
gittuf's policy can be rolled back to prior valid versions in github.com/gittuf/gittuf
gittuf's policy can be rolled back to prior valid versions in github.com/gittuf/gittuf
- Record
GO-2026-5683- Updated
- 2026-11-02
OSVopenSUSE-SU-2026:21483-1 No score
Security update for govulncheck-vulndb
This update for govulncheck-vulndb fixes the following issues:
- Update to version 0.0.20260723T184607 2026-07-23T18:46:07Z (jsc#PED-11136).
Go CVE Numbering Authority IDs added or updated with aliases:
- GO-2026-4730 CVE-2026-33022 GHSA-cv4x-93xx-wgfj
- GO-2026-4761 CVE-2026-33211 GHSA-j5q5-j9gm-2w5c
- GO-2026-5102 CVE-2026-45021 GHSA-3vcp-chfh-f6r2
- GO-2026-5272 CVE-2026-40938 GHSA-94jr-7pqp-xhcq
- GO-2026-5486 CVE-2026-40924 GHSA-m2cx-gpqf-qf74
- GO-2026-5542 CVE-2026-40090 GHSA-pj97-4p9w-gx3q
- GO-2026-5630 CVE-2026-25542 GHSA-rmx9-2pp3-xhcr
- GO-2026-5643 CVE-2026-40923 GHSA-rx35-6rhx-7858
- GO-2026-5675 CVE-2026-41492 GHSA-vvf7-6rmr-m29q
- GO-2026-5711 CVE-2026-40161 GHSA-wjxp-xrpv-xpff
- GO-2026-5746 CVE-2026-41567 GHSA-x86f-5xw2-fm2r
- GO-2026-5749 CVE-2026-41328 GHSA-x92x-px7w-4gx4
- GO-2026-5837 CVE-2026-44840 GHSA-q2m9-6jp9-c6mc
- GO-2026-5929 CVE-2026-44342 GHSA-26v7-h57m-gh9m
- GO-2026-5930 CVE-2026-33655 GHSA-6qcr-qxgr-m7fv
- GO-2026-5933 GHSA-3g4q-2f67-2gvh
- GO-2026-5934 GHSA-59qp-cfj3-rp64
- GO-2026-5935 GHSA-7856-g3gv-9wq8
- GO-2026-5936 CVE-2026-53552 GHSA-26rh-24rg-j3vv
- GO-2026-5937 CVE-2026-53508 GHSA-2jcc-mxv7-p3f9
- GO-2026-5938 CVE-2026-53553 GHSA-4g5x-hcwm-82jw
- GO-2026-5939 CVE-2026-10517 GHSA-698x-9w2p-7vvp
- GO-2026-5940 CVE-2026-53572 GHSA-6w3m-4hhp-775q
- GO-2026-5941 CVE-2026-53487 GHSA-gvhc-wv3v-7pf8
- GO-2026-5942 CVE-2026-46600
- GO-2026-5944 CVE-2026-50197 GHSA-659f-rgp5-w4wf
- GO-2026-5945 CVE-2026-6815 GHSA-rmxx-v9rj-vpvg
- GO-2026-5946 CVE-2026-52831 GHSA-v5px-423j-pf7p
- GO-2026-5947 CVE-2026-53649 GHSA-xqhv-chqm-fhcc
- GO-2026-5948 CVE-2026-50554 GHSA-588f-fvcv-xhvf
- GO-2026-5949 CVE-2026-50553 GHSA-rqrh-8wpv-x7hh
- GO-2026-5950 CVE-2026-53602 GHSA-339v-266x-79xr
- GO-2026-5951 CVE-2026-10219 GHSA-6jm8-4fhr-5w64
- GO-2026-5952 CVE-2026-49834 GHSA-9vcr-p3rj-q5q6
- GO-2026-5953 CVE-2026-9094 GHSA-c9w5-qp6m-m395
- GO-2026-5956 CVE-2026-55252 GHSA-h5g6-xmh4-hc37
- GO-2026-5957 CVE-2026-54158 GHSA-5xfx-xj4h-5p7r
- GO-2026-5958 CVE-2026-54068 GHSA-gcm7-57gf-953c
- GO-2026-5959 CVE-2026-54072 GHSA-h29v-hj44-q8cv
- GO-2026-5961 CVE-2026-54069 GHSA-hvr9-72v2-fff3
- GO-2026-5962 CVE-2026-54088 GHSA-m93h-4hw7-5qcm
- GO-2026-5963 CVE-2026-54067 GHSA-mvjr-vv3c-w4qv
- GO-2026-5964 CVE-2026-54066 GHSA-p4m3-mgmm-c664
- GO-2026-5965 CVE-2026-54070 GHSA-w7cg-whh7-xp28
- GO-2026-5966 CVE-2026-54089 GHSA-xqp3-jq6g-x3qm
- GO-2026-5967 CVE-2026-50551 GHSA-56mp-4f3v-fgj2
- GO-2026-5968 CVE-2026-54174 GHSA-fpg8-7664-jc5q
- GO-2026-5969 GHSA-g936-7jqj-mwv8
- GO-2026-5970 CVE-2026-56852
- GO-2026-5973 CVE-2026-54250 GHSA-jxr7-mqhw-9p98
- GO-2026-5974 CVE-2026-44300 GHSA-wmj8-9953-vff5
- GO-2026-5975 CVE-2026-50018 GHSA-42j2-w334-qxw7
- GO-2026-5976 CVE-2026-50141 GHSA-g7mm-9vx7-jm7h
- GO-2026-5977 CVE-2026-50013 GHSA-qrh4-p6v4-mrfg
- GO-2026-5978 CVE-2026-50125 GHSA-qw5r-ppcg-f8rj
- GO-2026-5979 CVE-2026-50006 GHSA-xrcf-6jh3-ggvx
- GO-2026-5980 CVE-2026-50158 GHSA-2c7f-fxww-6w6c
- GO-2026-5981 GHSA-mqxv-9rm6-w8qc
- GO-2026-5982 GHSA-pqg7-v6wh-3pfp
- GO-2026-5984 CVE-2026-53604 GHSA-2p2f-px33-4vv5
- GO-2026-5985 GHSA-7rx3-5wx3-5v76
- GO-2026-5986 CVE-2026-61699 GHSA-cm26-5974-52h8
- GO-2026-5987 CVE-2026-55513 GHSA-g4x6-jcvr-9m3g
- GO-2026-5988 CVE-2026-54628 GHSA-hwrq-8wxh-q4xv
- GO-2026-5989 CVE-2026-55512 GHSA-m3cx-mwpg-32jg
- GO-2026-5990 CVE-2026-54629 GHSA-mf78-3rpf-r784
- GO-2026-5991 CVE-2026-53603 GHSA-q4vm-pq3q-8wgq
- GO-2026-5992 CVE-2026-61549 GHSA-qf34-295c-26v8
- GO-2026-5996 CVE-2026-54450 GHSA-pph6-vfjv-vpjw
- GO-2026-5997 CVE-2026-54452 GHSA-xgch-x3mx-cm3c
- GO-2026-5998 CVE-2026-54495 GHSA-398h-7f66-3h4p
- GO-2026-5999 CVE-2026-10814 GHSA-jh6h-v6mp-h22v
- GO-2026-6002 CVE-2026-58196 GHSA-pr64-jmmf-jp54
- GO-2026-6003 CVE-2026-53714 GHSA-22xc-xg2r-9j7v
- GO-2026-6004 CVE-2026-52833 GHSA-3v79-m2cg-89ww
- GO-2026-6005 CVE-2026-53715 GHSA-8fv2-88gg-hm7q
- GO-2026-6006 CVE-2026-53716 GHSA-cxpq-8v7q-cg56 *…
- Record
openSUSE-SU-2026:21483-1- Updated
- 2026-11-02
Affected products
Affected packages
| Package | Affected | Fixed |
|---|---|---|
github.com/gittuf/gittufGo |
through 0.13.1 | 0.14.0 |
gittufDebian:13 |
All versions, plus listed versions 0.12.0-10.12.0-20.13.1-10.13.1-1~exp00.13.1-1~exp10.14.1-10.15.0-10.9.0-5 |
None known |
gittufDebian:14 |
before 0.14.1-1, plus listed versions 0.12.0-10.12.0-20.13.1-10.13.1-1~exp00.13.1-1~exp10.9.0-5 |
0.14.1-1 |
github.com/gittuf/gittufGo |
before 0.14.0 | 0.14.0 |
gittufUbuntu:25.10 |
All versions, plus listed versions 0.9.0-10.9.0-5 |
None known |
gittufUbuntu:26.10 |
All versions, plus listed versions 0.12.0-10.14.1-10.15.0-1 |
None known |
gittufUbuntu:Pro:26.04:LTS |
All versions, plus listed versions 0.9.0-50.12.0-10.12.0-1ubuntu0.26.04.1~esm1 |
None known |
govulncheck-vulndbopenSUSE:Leap 16.0 From an advisory covering 1734 CVEs |
before 0.0.20260723T184607-160000.1.1 | 0.0.20260723T184607-160000.1.1 |
History
| Recorded | Changed | Sources |
|---|---|---|
| affected, facts | ||
| first indexed | CVE List, EUVD, GitHub Advisories, NVD, OSV |
Dates are when Every CVE recorded each change. Upstream dates may differ.
In short
CVE-2026-44544 is a medium vulnerability (CVSS 4.9) in Gittuf, published May 7, 2026. No source lists public exploit code. EPSS puts the chance of exploitation in the next 30 days at 0.20%, the 9th percentile. Fixed in github.com/gittuf/gittuf 0.14.0.
References
github.com/gittuf/gittuf/security/advisories/GHSA-vxvc-cg7j-rwqj
nvd.nist.gov/vuln/detail/CVE-2026-44544
security-tracker.debian.org/tracker/CVE-2026-44544
Show 194 moreShow less
ubuntu.com/security/CVE-2026-44544
cve.org/CVERecord?id=CVE-2026-44544
suse.com/security/cve/CVE-2016-11063
Left out here: 1,543 references and the rest of 1 source description. The JSON record has them.