kas is a setup tool for bitbake based projects. Starting in version 4.8 and prior to version 5.3, kas checks out and processes repositories regarding configuration includes prior to validating signatures of those repositories. This may allow to replace on original repository with one under the control of an attacker under very specific conditions. First of all, the attacker must have gained control of a repository that a kas file of the victim is referencing. Furthermore, the following conditions must be fulfilled: the victim's kas configuration must include a configuration file from the attacked repository; the repository state is referenced by tag, and no commit ID is specified (this is triggering a warning, though); the key used for validating the tag or commit signature is stored as file in a repository; no fingerprint for the key is specified; and the `_source_dir` key must not be set by the victim when calling kas (e.g. by avoiding a local `.config.yaml`). Given these conditions, the attacker could modify the included kas configuration in way that the key used to validate the tag signature of the attacker's repository could be replaced by an attacker-chosen key. No other exploit possibilities have been identified so far, but this does not rule out that those may exist. All patches have been released along with kas version 5.3. As a workaround, pin the expected signature key via its fingerprint, also when storing it as file in a repository.

There are packages installed that are affected by a vulnerability referenced in the following CVE:

  - kas is a setup tool for bitbake based projects. Starting in version 4.8 and prior to version 5.3, kas
    checks out and processes repositories regarding configuration includes prior to validating signatures of
    those repositories. This may allow to replace on original repository with one under the control of an
    attacker under very specific conditions. First of all, the attacker must have gained control of a
    repository that a kas file of the victim is referencing. Furthermore, the following conditions must be
    fulfilled: the victim's kas configuration must include a configuration file from the attacked repository;
    the repository state is referenced by tag, and no commit ID is specified (this is triggering a warning,
    though); the key used for validating the tag or commit signature is stored as file in a repository; no
    fingerprint for the key is specified; and the `_source_dir` key must not be set by the victim when calling
    kas (e.g. by avoiding a local `.config.yaml`). Given these conditions, the attacker could modify the
    included kas configuration in way that the key used to validate the tag signature of the attacker's
    repository could be replaced by an attacker-chosen key. No other exploit possibilities have been
    identified so far, but this does not rule out that those may exist. All patches have been released along
    with kas version 5.3. As a workaround, pin the expected signature key via its fingerprint, also when
    storing it as file in a repository. (CVE-2026-47192)

The Linux/Unix host has one or more packages installed that are impacted by a vulnerability without a vendor supplied patch available.

  - kas is a setup tool for bitbake based projects. Starting in version 4.8 and prior to version 5.3, kas     checks out and processes repositories regarding configuration includes prior to validating signatures of     those repositories. This may allow to replace on original repository with one under the control of an     attacker under very specific conditions. First of all, the attacker must have gained control of a     repository that a kas file of the victim is referencing. Furthermore, the following conditions must be     fulfilled: the victim's kas configuration must include a configuration file from the attacked repository;
    the repository state is referenced by tag, and no commit ID is specified (this is triggering a warning,     though); the key used for validating the tag or commit signature is stored as file in a repository; no     fingerprint for the key is specified; and the `_source_dir` key must not be set by the victim when calling     kas (e.g. by avoiding a local `.config.yaml`). Given these conditions, the attacker could modify the     included kas configuration in way that the key used to validate the tag signature of the attacker's     repository could be replaced by an attacker-chosen key. No other exploit possibilities have been     identified so far, but this does not rule out that those may exist. All patches have been released along     with kas version 5.3. As a workaround, pin the expected signature key via its fingerprint, also when     storing it as file in a repository. (CVE-2026-47192)

Note that Nessus relies on the presence of the package as reported by the vendor.

ID	Name	Product	Family	Type	Severity
442623	SCA: security update for kas (GHSA-4vqc-wpwg-vh7j)	Tenable Cloud Security	SCA Checks	Local	low
442623	SCA: security update for kas (GHSA-4vqc-wpwg-vh7j)	Tenable Self-Hosted Container Security	SCA Checks	Local	low
318345	Linux Distros Unpatched Vulnerability : CVE-2026-47192	Nessus	Misc.	Local	low

Detections

Analytics

CVE-2026-47192

low

Tenable Plugins

low

low

low