Is there a patch available for CVE-2026-47191?

Yes, a patch is available for CVE-2026-47191. Update the affected software to the latest version immediately.

Siemens kas CVE-2026-47191

LOW

Improper Verification of Cryptographic Signature (CWE-347)

2026-06-01 https://github.com/siemens/kas

GHSA-qjwp-hrq6-r26r

Jwt Attack Information Disclosure Siemens

Lifecycle Timeline

Source Code Evidence Fetched

Jun 01, 2026 - 14:55 vuln.today

Analysis Generated

Jun 01, 2026 - 14:55 vuln.today

DescriptionCVE.org

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.

Patches

Commit https://github.com/siemens/kas/commit/4cb4a3d01122ffaec9feaae768a5814092f6f9b5 is resolving this issue. It has been released along with kas version 5.3.

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.

AnalysisAI

Integrity bypass in Siemens kas (pip/kas < 5.3) allows an attacker who controls a referenced external git repository to substitute arbitrary commit content by creating a branch whose name matches the commit SHA recorded in a kas configuration file. Because kas passed the raw SHA string to git checkout without forcing disambiguation to a commit object, git resolves a branch of that name instead of the pinned commit, defeating the integrity guarantee users rely on. The primary impact falls on SHA-256 commit IDs; SHA-1 commits face a related but distinct risk through hash-collision substitution. No public exploit has been identified at time of analysis and the issue is not listed in CISA KEV.

Technical ContextAI

kas is a Python-based build configuration and workspace management tool for Yocto/OpenEmbedded projects, distributed as pip/kas. It manages external git repositories declared in configuration files, checking them out at specific commit SHAs to ensure reproducible builds. The vulnerability stems from CWE-347 (Improper Verification of Cryptographic Signature / integrity check): the affected code in kas/repos.py invoked git checkout -q <sha> where <sha> is the raw 40- or 64-character hex string from the config. Git's disambiguation logic allows a branch name to shadow a commit SHA when both exist in a repository; without appending the ^{commit} suffix, git resolves the ref against branch names first in some resolution paths. The patch (commit 4cb4a3d01122ffaec9feaae768a5814092f6f9b5) adds a regex check against 40- or 64-hex-char strings and appends ^{commit} to force git to treat the ref exclusively as a commit object, not a branch pointer. The affected CPE is pkg:pip/kas versions prior to 5.3.

RemediationAI

Upgrade kas to version 5.3 or later, which contains the fix in commit 4cb4a3d01122ffaec9feaae768a5814092f6f9b5 (https://github.com/siemens/kas/commit/4cb4a3d01122ffaec9feaae768a5814092f6f9b5). This is the primary and definitive remediation. For environments where immediate upgrade is not possible, the vendor recommends validating cryptographically signed git commits or tags in addition to commit SHA pinning, which provides authenticity proof that bare SHAs cannot. As a second workaround, mirror all externally referenced repositories to a controlled internal location, validate integrity there, and configure kas to reference the mirror rather than the original upstream - this prevents an attacker who controls the upstream repo from introducing malicious branches. Note that the mirror approach introduces an operational burden of keeping mirrors synchronized and does not address the underlying git disambiguation issue. Neither workaround should be considered a long-term substitute for upgrading to 5.3.