CVE-2026-47191: 
Python vulnerability analysis and mitigation

CVE-2026-47191 is a supply-chain integrity vulnerability in Siemens' kas (Yocto/OpenEmbedded build tool) where SHA-like git branch names are incorrectly checked out as valid commits. When kas resolves a commit ID from a kas configuration file, it fails to distinguish between an actual commit object and a branch whose name matches the commit's SHA hash, allowing an attacker who has taken over the referenced repository to substitute malicious code. The vulnerability affects all kas versions prior to 5.3 (pip package). It was originally reported by Aditya Sirish A Yelgundhalli, published on May 27, 2026, and has a CVSS v4 base score of 2.1 (Low) (GitHub Advisory, kas Advisory).

The root cause is classified as CWE-347 (Improper Verification of Cryptographic Signature) — kas relies solely on a git commit ID (SHA-1 or SHA-256 hex string) to validate repository state, but git does not warn when a SHA-like branch name (40 or 64 hex characters) is checked out instead of the actual commit object. The fix in commit 4cb4a3d adds a regex check in kas/repos.py: if the desired ref matches a SHA-like pattern (^[0-9a-f]{40}|[0-9a-f]{64}$), kas appends ^{commit} to the ref, forcing git to resolve it as a commit object rather than a branch or tag, causing the checkout to fail if a branch of that name exists instead (kas Commit). SHA-1 commit IDs carry an additional risk of hash collision attacks, though major git forges (GitHub, GitLab) do not permit pushing SHA-like branch names, partially mitigating the branch-spoofing vector on those platforms (GitHub Advisory).

Successful exploitation allows an attacker who has gained control of a referenced git repository to cause kas users to silently check out malicious code instead of the intended, validated commit — a classic supply-chain substitution attack. The impact spans confidentiality (exposure of build environment data), integrity (introduction of malicious code into Yocto/OpenEmbedded builds), and availability (potential disruption of build pipelines). Downstream systems built using the compromised kas configuration could incorporate attacker-controlled code, with no indication to the user that the expected commit was not checked out (GitHub Advisory, kas Advisory).

There is no public proof-of-concept exploit and no evidence of in-the-wild exploitation as of the time of disclosure (GitHub Advisory). Exploitation requires the attacker to first gain control of a git repository referenced in a kas configuration (high attack complexity), and a kas user must subsequently trigger a build that checks out that repository (passive user interaction required). The vulnerability is not listed in the CISA KEV catalog, and no threat actor attribution has been reported. The EPSS score is not yet published for this CVE.

1. Repository Takeover: Gain write access to a git repository that is referenced by a kas configuration file (e.g., via credential theft, dependency confusion, or account compromise on a self-hosted git server that permits SHA-like branch names).
2. Create SHA-like Branch: Create a branch in the compromised repository whose name exactly matches the SHA-1 (40 hex chars) or SHA-256 (64 hex chars) commit ID specified in the target's kas configuration file, and populate it with malicious code.
3. Wait for kas Checkout: When a victim runs kas with the affected configuration, kas executes git checkout -q <commit-id> without the ^{commit} disambiguator, causing git to silently check out the attacker-controlled branch instead of the intended commit object.
4. Code Execution in Build: The malicious code from the attacker-controlled branch is incorporated into the Yocto/OpenEmbedded build process, potentially executing arbitrary commands during the build or embedding backdoors into the resulting firmware/image (kas Commit, GitHub Advisory).

• File System: Unexpected or modified source files in kas-managed repository checkout directories that do not match the expected commit hash; presence of a branch named with 40 or 64 hex characters in a cloned repository (git branch -a | grep -E '^[0-9a-f]{40}$|^[0-9a-f]{64}$').
• Logs: kas build logs showing a successful checkout of a SHA-like ref without the ^{commit} suffix in the git command; git output lacking the expected detached HEAD message referencing the correct commit object.
• Process: git checkout invocations in build logs where the checked-out ref resolves to a branch tip rather than the commit object specified in the kas configuration (verifiable by comparing git rev-parse HEAD against the configured commit ID post-checkout).

Upgrade kas to version 5.3 or later, which includes the fix in commit 4cb4a3d that appends ^{commit} to SHA-like refs during checkout, preventing branch substitution (kas Commit, GitHub Advisory). If upgrading immediately is not possible, apply these workarounds: (1) additionally validate cryptographically signed commits or tags for any externally referenced repository; (2) mirror referenced repositories to a trusted, controlled location, validate their integrity, and configure kas to use the mirror instead of the original. Note that SHA-1 commit IDs remain susceptible to hash collision attacks even after patching, so using SHA-256 commits with signed tags is the strongest integrity posture.

The vulnerability was originally flagged three years prior to disclosure by researcher Aditya Sirish A Yelgundhalli, but Siemens had previously documented such supply-chain attacks as out of scope for kas. The advisory notes that Siemens revised this position for SHA-256 commits following the patch, while SHA-1 commits remain acknowledged as a residual risk (kas Advisory). No significant broader media coverage or social media discussion has been identified for this low-severity vulnerability.