CVE-2026-47192: 
Python vulnerability analysis and mitigation

CVE-2026-47192 is a late signature validation vulnerability in Siemens' kas (Kas Automated Setup) tool that may allow unnoticed repository manipulations in a supply-chain attack scenario. The flaw affects kas versions >= 4.8 and < 5.3 (pip package), and was introduced with commit a2480fe59b6421eb96cf3bd86527ae6e412a331e. It was published by the Siemens kas maintainer on May 27, 2026, and added to the GitHub Advisory Database on June 4, 2026. The vulnerability carries a CVSS v4.0 base score of 2.1 (Low) (GitHub Advisory, Siemens kas Advisory).

The root cause is a Time-of-Check to Time-of-Use (TOCTOU) flaw classified as CWE-347 (Improper Verification of Cryptographic Signature): kas checks out and processes repository configuration includes — including those from external repositories — before validating the cryptographic signatures of those repositories. This ordering allows an attacker who has already gained control of a referenced repository to modify the included kas configuration, substituting the signing key used to validate tag signatures with an attacker-chosen key. Exploitation requires a specific confluence of conditions: the victim's kas configuration must include a file from the compromised repository; the repository must be referenced by tag without a commit ID; the signing key must be stored as a file in the repository without a fingerprint specified; and the _source_dir key must not be set by the victim. The fix (commit 5b2114b) moves signature validation to occur before each checkout and configuration dictionary update, eliminating the TOCTOU window (GitHub Advisory, Patch Commit).

Successful exploitation allows an attacker who has compromised a referenced repository to replace the signing key used for tag signature validation with one of their own choosing, effectively forging valid signatures for malicious repository content. This undermines the integrity of the build environment managed by kas, potentially allowing injection of malicious code into Yocto/OpenEmbedded build configurations. The confidentiality, integrity, and availability impacts on the vulnerable system are all rated Low, with no impact on subsequent systems, reflecting the narrow and highly conditional nature of the attack (GitHub Advisory).

There is no public proof-of-concept exploit and no evidence of in-the-wild exploitation at this time. The EPSS score is approximately 0.021% (6th percentile), indicating a very low probability of exploitation in the near term. The CVE is not listed in the CISA Known Exploited Vulnerabilities (KEV) catalog. Exploitation requires the attacker to have already gained control of a repository referenced by the victim's kas configuration, making opportunistic exploitation unlikely (GitHub Advisory, Siemens kas Advisory).

1. Gain repository control: Compromise or take over a git repository that is referenced in a victim's kas configuration file (e.g., via credential theft, account takeover, or supply-chain compromise of the upstream project).
2. Verify preconditions: Confirm that the victim's kas configuration includes a configuration file from the compromised repository, references it by tag (not commit ID), stores the signing key as a file in the repository without a fingerprint, and does not set _source_dir.
3. Modify the included kas configuration: In the compromised repository, alter the included kas configuration file to replace the signing key reference with a path pointing to an attacker-controlled key file, also placed in the repository.
4. Push attacker-controlled key: Add the attacker's own GPG or SSH public key as a file in the compromised repository.
5. Sign malicious content: Use the attacker's private key to sign a malicious tag or commit in the compromised repository.
6. Trigger victim's kas run: Wait for or induce the victim to run kas (e.g., via a CI/CD pipeline trigger). Because kas processes configuration includes before validating signatures, it will load the attacker-modified configuration, import the attacker's key, and then validate the malicious tag as legitimate — allowing the attacker's content to be checked out and used in the build (GitHub Advisory, Patch Commit).

• File System: Unexpected or newly added key files (GPG .asc/.gpg or SSH .pub) in a referenced external repository's directory tree; modifications to included kas configuration files in external repositories that change signers or key file paths.
• Logs: kas log output showing signature validation passing for a repository whose signing key was recently changed; warnings about repositories referenced by tag without a commit ID (kas emits these by default).
• Build Artifacts: Unexpected changes in build outputs or fetched source trees that do not correspond to known-good tagged releases of referenced repositories.
• Git History: Unusual commits to referenced repositories that add or modify key files or kas configuration includes, especially shortly before a build run (GitHub Advisory).

Upgrade kas to version 5.3 or later, which includes patches in commits 5b2114b (signature validation before checkout), c443c0a (_source_dir misuse fix), and 4cb4a3d (SHA-like branch checkout prevention). As an immediate workaround without upgrading, pin the expected signing key via its fingerprint in the kas configuration rather than referencing it solely as a file in a repository. Additionally, always specify commit IDs rather than tags alone in kas configurations, set the _source_dir key explicitly when calling kas, and ensure all referenced repositories are under trusted control (Siemens kas Advisory, GitHub Advisory).