Summary
kas checks out SHA-like git branches as valid commits
Workarounds
Avoid relying solely on the commit ID for integrity validation of a repository that might become under control of a malicious 3rd party. If available, additional validate cryptographically signed commits or tags. Alternatively, mirror the repository to a save place, validate its integrity, and use this instead of the original one.
Credits
That such issues exist was already reported 3 years ago by Aditya Sirish A Yelgundhalli. At this point, no strong integrity checks for external repositories were in place in kas, and Siemens stated in the kas documentation that such attacks are considered out of scope. This hasn't changed for SHA-1 commits as explained above. If a repo provides SHA-256 commits, though, those may be considered strong enough (even if not providing authenticity proof) and can be affected by this issue.
Impact
When relying solely on a git commit ID (SHA-1 or SHA-256) to qualify if a checkout of a repository is equivalent to the state validated while adding its commit ID to a kas configuration, users may be tricked to check out a branch of the same name from this repository. This implies that the referenced repository has been taken over by an attacker and modified to carry such a branch. SHA-1 commits may also be replaced by creating hash collisions, so the primary impact of this issue is on SHA-256 commit IDs.
Affected versions
Security releases
Kodem intelligence
Severity tells you how bad this could be in the worst case. It does not tell you whether you are exposed. Exploitability and impact are functions of runtime truth: whether the vulnerable code is present, reachable, and actually executes in your application. A vulnerable package can sit in your dependency tree and never run.
Kodem, an Intelligent Application Security platform, uses runtime intelligence to reveal which vulnerabilities actually execute in production, so teams prioritize the ones that genuinely matter. Kodem's runtime-powered SCA identifies whether this CVE is reachable in your applications.
Already deployed Kodem?
See it in your environmentNew to Kodem? Get a demo →Remediation advice
Commit https://github.com/siemens/kas/commit/4cb4a3d01122ffaec9feaae768a5814092f6f9b5 is resolving this issue. It has been released along with kas version 5.3.
Frequently Asked Questions
- What is CVE-2026-47191? CVE-2026-47191 is a low-severity security vulnerability in kas (pip), affecting versions < 5.3. It is fixed in 5.3.
- Which versions of kas are affected by CVE-2026-47191? kas (pip) versions < 5.3 is affected.
- Is there a fix for CVE-2026-47191? Yes. CVE-2026-47191 is fixed in 5.3. Upgrade to this version or later.
- Is CVE-2026-47191 exploitable, and should I be worried? Whether CVE-2026-47191 is exploitable in your environment depends on whether the vulnerable code is present and reachable. A CVSS score is a worst-case rating; it does not account for your specific deployment, configuration, or usage patterns. Kodem, an Intelligent Application Security platform, uses runtime intelligence to show which vulnerabilities actually execute in production, so you can focus on the ones that represent real risk. Get a demo
- What actually determines whether CVE-2026-47191 is exploitable, and how bad it is? Exploitability and impact are not fixed properties of a CVE. They depend on runtime truth: whether the vulnerable code is present, reachable, and actually executes in your application. A high CVSS score on a dependency that never runs is not the same as real risk. Kodem, an Intelligent Application Security platform, uses runtime intelligence to reveal which vulnerabilities actually execute in production, so teams prioritize the ones that genuinely matter.
- How do I fix CVE-2026-47191? Upgrade
kasto 5.3 or later.