zincati

Version	Released
`0.0.32` unknown	Feb 02, 2026
`0.0.31` unknown	Jan 12, 2026
`0.0.30` unknown	Mar 17, 2025
`0.0.29` unknown 1 CVE	Jul 18, 2024
`0.0.28` unknown 1 CVE	Apr 30, 2024
`0.0.27` unknown 1 CVE	Nov 08, 2023
`0.0.26` unknown 1 CVE	Oct 17, 2023
`0.0.25` unknown 1 CVE	Sep 27, 2022
`0.0.24` unknown 1 CVE	Nov 01, 2021
`0.0.23` unknown	Aug 05, 2021
`0.0.22` unknown	Jul 07, 2021
`0.0.21` unknown	May 20, 2021
`0.0.20` unknown	Apr 29, 2021
`0.0.19` unknown	Mar 23, 2021
`0.0.18` unknown	Mar 03, 2021
`0.0.17` unknown	Feb 08, 2021
`0.0.15` unknown	Jan 19, 2021
`0.0.14` unknown	Nov 02, 2020
`0.0.13` unknown	Sep 22, 2020
`0.0.12` unknown	Jun 25, 2020
`0.0.11` unknown	May 22, 2020
`0.0.10` unknown	Apr 06, 2020
`0.0.9` unknown	Mar 10, 2020
`0.0.8` unknown	Feb 11, 2020
`0.0.7` unknown	Dec 16, 2019
`0.0.6` unknown	Oct 09, 2019
`0.0.5` unknown	Sep 09, 2019
`0.0.4` unknown	Aug 02, 2019
`0.0.3` unknown	Jul 10, 2019
`0.0.2` unknown	Jun 24, 2019
`0.0.1` unknown	Jun 14, 2019

0.0.32 unknown

Feb 02, 2026

0.0.31 unknown

Jan 12, 2026

0.0.30 unknown

Mar 17, 2025

0.0.29 unknown

1 CVE

CVE-2025-27512 GHSA-w6fv-6gcc-x825 Mar 17, 2025

Zincati allows unprivileged access to rpm-ostree D-Bus `Deploy()` and `FinalizeDeployment()` methods

Low

Local Low None None

Impact

Zincati ships a polkit rule which allows the zincati system user to use the following actions:

org.projectatomic.rpmostree1.deploy: used to deploy updates to the system
org.projectatomic.rpmostree1.finalize-deployment: used to reboot the system into the deployed update

Since Zincati v0.0.24, this polkit rule contains a logic error which broadens access of those polkit actions to any unprivileged user rather than just the zincati system user.

In practice, this means that any unprivileged user with access to the system D-Bus socket is able to deploy older Fedora CoreOS versions (which may have other known vulnerabilities). Note that rpm-ostree enforces that the selected version must be from the same branch the system is currently on so this cannot directly be used to deploy an attacker-controlled update payload.

This primarily impacts users running untrusted workloads with access to the system D-Bus socket. Note that in general, untrusted workloads should not be given this access, whether containerized or not. By default, containers do not have access to the system D-Bus socket.

Patches

The logic error is fixed in Zincati v0.0.30. The fix is included in the following FCOS releases:

On the stable stream: 41.20250302.3.2
On the testing stream: 41.20250315.2.0
On the next stream: 42.20250316.1.0

Workarounds

A workaround is to add the following polkit rule:

polkit.addRule(function(action, subject) {
    if (action.id == "org.projectatomic.rpmostree1.deploy" ||
        action.id == "org.projectatomic.rpmostree1.finalize-deployment" ||
        action.id == "org.projectatomic.rpmostree1.cleanup") {
        if (subject.user != "zincati") {
                return polkit.Result.NO;
        }
    }
});

to e.g. /etc/polkit-1/rules.d/00-zincati-fix.rules (it must sort earlier than zincati.rules lexicographically).

Note that this rule will deny all non-root users other than zincati from using those actions. If you've added polkit rules to allow e.g. the core user or other users, you will need to adjust the policy (or make sure the ordering is appropriate).

References

This issue was introduced by this commit, and is fixed in v0.0.30.

Fixed in


          0.0.30

References

Updated Mar 19, 2025 · Source: OSV.dev

Jul 18, 2024

0.0.28 unknown

1 CVE

CVE-2025-27512 GHSA-w6fv-6gcc-x825 Mar 17, 2025

Zincati allows unprivileged access to rpm-ostree D-Bus `Deploy()` and `FinalizeDeployment()` methods

Low

Local Low None None

Impact

Zincati ships a polkit rule which allows the zincati system user to use the following actions:

org.projectatomic.rpmostree1.deploy: used to deploy updates to the system
org.projectatomic.rpmostree1.finalize-deployment: used to reboot the system into the deployed update

Since Zincati v0.0.24, this polkit rule contains a logic error which broadens access of those polkit actions to any unprivileged user rather than just the zincati system user.

In practice, this means that any unprivileged user with access to the system D-Bus socket is able to deploy older Fedora CoreOS versions (which may have other known vulnerabilities). Note that rpm-ostree enforces that the selected version must be from the same branch the system is currently on so this cannot directly be used to deploy an attacker-controlled update payload.

This primarily impacts users running untrusted workloads with access to the system D-Bus socket. Note that in general, untrusted workloads should not be given this access, whether containerized or not. By default, containers do not have access to the system D-Bus socket.

Patches

The logic error is fixed in Zincati v0.0.30. The fix is included in the following FCOS releases:

On the stable stream: 41.20250302.3.2
On the testing stream: 41.20250315.2.0
On the next stream: 42.20250316.1.0

Workarounds

A workaround is to add the following polkit rule:

polkit.addRule(function(action, subject) {
    if (action.id == "org.projectatomic.rpmostree1.deploy" ||
        action.id == "org.projectatomic.rpmostree1.finalize-deployment" ||
        action.id == "org.projectatomic.rpmostree1.cleanup") {
        if (subject.user != "zincati") {
                return polkit.Result.NO;
        }
    }
});

to e.g. /etc/polkit-1/rules.d/00-zincati-fix.rules (it must sort earlier than zincati.rules lexicographically).

Note that this rule will deny all non-root users other than zincati from using those actions. If you've added polkit rules to allow e.g. the core user or other users, you will need to adjust the policy (or make sure the ordering is appropriate).

References

This issue was introduced by this commit, and is fixed in v0.0.30.

Fixed in


          0.0.30

References

Updated Mar 19, 2025 · Source: OSV.dev

Apr 30, 2024

0.0.27 unknown

1 CVE

CVE-2025-27512 GHSA-w6fv-6gcc-x825 Mar 17, 2025

Zincati allows unprivileged access to rpm-ostree D-Bus `Deploy()` and `FinalizeDeployment()` methods

Low

Local Low None None

Impact

Zincati ships a polkit rule which allows the zincati system user to use the following actions:

org.projectatomic.rpmostree1.deploy: used to deploy updates to the system
org.projectatomic.rpmostree1.finalize-deployment: used to reboot the system into the deployed update

Since Zincati v0.0.24, this polkit rule contains a logic error which broadens access of those polkit actions to any unprivileged user rather than just the zincati system user.

In practice, this means that any unprivileged user with access to the system D-Bus socket is able to deploy older Fedora CoreOS versions (which may have other known vulnerabilities). Note that rpm-ostree enforces that the selected version must be from the same branch the system is currently on so this cannot directly be used to deploy an attacker-controlled update payload.

This primarily impacts users running untrusted workloads with access to the system D-Bus socket. Note that in general, untrusted workloads should not be given this access, whether containerized or not. By default, containers do not have access to the system D-Bus socket.

Patches

The logic error is fixed in Zincati v0.0.30. The fix is included in the following FCOS releases:

On the stable stream: 41.20250302.3.2
On the testing stream: 41.20250315.2.0
On the next stream: 42.20250316.1.0

Workarounds

A workaround is to add the following polkit rule:

polkit.addRule(function(action, subject) {
    if (action.id == "org.projectatomic.rpmostree1.deploy" ||
        action.id == "org.projectatomic.rpmostree1.finalize-deployment" ||
        action.id == "org.projectatomic.rpmostree1.cleanup") {
        if (subject.user != "zincati") {
                return polkit.Result.NO;
        }
    }
});

to e.g. /etc/polkit-1/rules.d/00-zincati-fix.rules (it must sort earlier than zincati.rules lexicographically).

Note that this rule will deny all non-root users other than zincati from using those actions. If you've added polkit rules to allow e.g. the core user or other users, you will need to adjust the policy (or make sure the ordering is appropriate).

References

This issue was introduced by this commit, and is fixed in v0.0.30.

Fixed in


          0.0.30

References

Updated Mar 19, 2025 · Source: OSV.dev

Nov 08, 2023

0.0.26 unknown

1 CVE

CVE-2025-27512 GHSA-w6fv-6gcc-x825 Mar 17, 2025

Zincati allows unprivileged access to rpm-ostree D-Bus `Deploy()` and `FinalizeDeployment()` methods

Low

Local Low None None

Impact

Zincati ships a polkit rule which allows the zincati system user to use the following actions:

org.projectatomic.rpmostree1.deploy: used to deploy updates to the system
org.projectatomic.rpmostree1.finalize-deployment: used to reboot the system into the deployed update

Since Zincati v0.0.24, this polkit rule contains a logic error which broadens access of those polkit actions to any unprivileged user rather than just the zincati system user.

In practice, this means that any unprivileged user with access to the system D-Bus socket is able to deploy older Fedora CoreOS versions (which may have other known vulnerabilities). Note that rpm-ostree enforces that the selected version must be from the same branch the system is currently on so this cannot directly be used to deploy an attacker-controlled update payload.

This primarily impacts users running untrusted workloads with access to the system D-Bus socket. Note that in general, untrusted workloads should not be given this access, whether containerized or not. By default, containers do not have access to the system D-Bus socket.

Patches

The logic error is fixed in Zincati v0.0.30. The fix is included in the following FCOS releases:

On the stable stream: 41.20250302.3.2
On the testing stream: 41.20250315.2.0
On the next stream: 42.20250316.1.0

Workarounds

A workaround is to add the following polkit rule:

polkit.addRule(function(action, subject) {
    if (action.id == "org.projectatomic.rpmostree1.deploy" ||
        action.id == "org.projectatomic.rpmostree1.finalize-deployment" ||
        action.id == "org.projectatomic.rpmostree1.cleanup") {
        if (subject.user != "zincati") {
                return polkit.Result.NO;
        }
    }
});

to e.g. /etc/polkit-1/rules.d/00-zincati-fix.rules (it must sort earlier than zincati.rules lexicographically).

Note that this rule will deny all non-root users other than zincati from using those actions. If you've added polkit rules to allow e.g. the core user or other users, you will need to adjust the policy (or make sure the ordering is appropriate).

References

This issue was introduced by this commit, and is fixed in v0.0.30.

Fixed in


          0.0.30

References

Updated Mar 19, 2025 · Source: OSV.dev

Oct 17, 2023

0.0.25 unknown

1 CVE

CVE-2025-27512 GHSA-w6fv-6gcc-x825 Mar 17, 2025

Zincati allows unprivileged access to rpm-ostree D-Bus `Deploy()` and `FinalizeDeployment()` methods

Low

Local Low None None

Impact

Zincati ships a polkit rule which allows the zincati system user to use the following actions:

org.projectatomic.rpmostree1.deploy: used to deploy updates to the system
org.projectatomic.rpmostree1.finalize-deployment: used to reboot the system into the deployed update

Since Zincati v0.0.24, this polkit rule contains a logic error which broadens access of those polkit actions to any unprivileged user rather than just the zincati system user.

In practice, this means that any unprivileged user with access to the system D-Bus socket is able to deploy older Fedora CoreOS versions (which may have other known vulnerabilities). Note that rpm-ostree enforces that the selected version must be from the same branch the system is currently on so this cannot directly be used to deploy an attacker-controlled update payload.

This primarily impacts users running untrusted workloads with access to the system D-Bus socket. Note that in general, untrusted workloads should not be given this access, whether containerized or not. By default, containers do not have access to the system D-Bus socket.

Patches

The logic error is fixed in Zincati v0.0.30. The fix is included in the following FCOS releases:

On the stable stream: 41.20250302.3.2
On the testing stream: 41.20250315.2.0
On the next stream: 42.20250316.1.0

Workarounds

A workaround is to add the following polkit rule:

polkit.addRule(function(action, subject) {
    if (action.id == "org.projectatomic.rpmostree1.deploy" ||
        action.id == "org.projectatomic.rpmostree1.finalize-deployment" ||
        action.id == "org.projectatomic.rpmostree1.cleanup") {
        if (subject.user != "zincati") {
                return polkit.Result.NO;
        }
    }
});

to e.g. /etc/polkit-1/rules.d/00-zincati-fix.rules (it must sort earlier than zincati.rules lexicographically).

Note that this rule will deny all non-root users other than zincati from using those actions. If you've added polkit rules to allow e.g. the core user or other users, you will need to adjust the policy (or make sure the ordering is appropriate).

References

This issue was introduced by this commit, and is fixed in v0.0.30.

Fixed in


          0.0.30

References

Updated Mar 19, 2025 · Source: OSV.dev

Sep 27, 2022

0.0.24 unknown

1 CVE

CVE-2025-27512 GHSA-w6fv-6gcc-x825 Mar 17, 2025

Zincati allows unprivileged access to rpm-ostree D-Bus `Deploy()` and `FinalizeDeployment()` methods

Low

Local Low None None

Impact

Zincati ships a polkit rule which allows the zincati system user to use the following actions:

org.projectatomic.rpmostree1.deploy: used to deploy updates to the system
org.projectatomic.rpmostree1.finalize-deployment: used to reboot the system into the deployed update

Since Zincati v0.0.24, this polkit rule contains a logic error which broadens access of those polkit actions to any unprivileged user rather than just the zincati system user.

In practice, this means that any unprivileged user with access to the system D-Bus socket is able to deploy older Fedora CoreOS versions (which may have other known vulnerabilities). Note that rpm-ostree enforces that the selected version must be from the same branch the system is currently on so this cannot directly be used to deploy an attacker-controlled update payload.

This primarily impacts users running untrusted workloads with access to the system D-Bus socket. Note that in general, untrusted workloads should not be given this access, whether containerized or not. By default, containers do not have access to the system D-Bus socket.

Patches

The logic error is fixed in Zincati v0.0.30. The fix is included in the following FCOS releases:

On the stable stream: 41.20250302.3.2
On the testing stream: 41.20250315.2.0
On the next stream: 42.20250316.1.0

Workarounds

A workaround is to add the following polkit rule:

polkit.addRule(function(action, subject) {
    if (action.id == "org.projectatomic.rpmostree1.deploy" ||
        action.id == "org.projectatomic.rpmostree1.finalize-deployment" ||
        action.id == "org.projectatomic.rpmostree1.cleanup") {
        if (subject.user != "zincati") {
                return polkit.Result.NO;
        }
    }
});

to e.g. /etc/polkit-1/rules.d/00-zincati-fix.rules (it must sort earlier than zincati.rules lexicographically).

Note that this rule will deny all non-root users other than zincati from using those actions. If you've added polkit rules to allow e.g. the core user or other users, you will need to adjust the policy (or make sure the ordering is appropriate).

References

This issue was introduced by this commit, and is fixed in v0.0.30.

Fixed in


          0.0.30

References

Updated Mar 19, 2025 · Source: OSV.dev

Nov 01, 2021

0.0.23 unknown

Aug 05, 2021

0.0.22 unknown

Jul 07, 2021

0.0.21 unknown

May 20, 2021

0.0.20 unknown

Apr 29, 2021

0.0.19 unknown

Mar 23, 2021

0.0.18 unknown

Mar 03, 2021

0.0.17 unknown

Feb 08, 2021

0.0.15 unknown

Jan 19, 2021

0.0.14 unknown

Nov 02, 2020

0.0.13 unknown

Sep 22, 2020

0.0.12 unknown

Jun 25, 2020

0.0.11 unknown

May 22, 2020

0.0.10 unknown

Apr 06, 2020

0.0.9 unknown

Mar 10, 2020

0.0.8 unknown

Feb 11, 2020

0.0.7 unknown

Dec 16, 2019

0.0.6 unknown

Oct 09, 2019

0.0.5 unknown

Sep 09, 2019

0.0.4 unknown

Aug 02, 2019

0.0.3 unknown

Jul 10, 2019

0.0.2 unknown

Jun 24, 2019

0.0.1 unknown

Jun 14, 2019

Activity

Details

Impact

Patches

Workarounds

References

Impact

Patches

Workarounds

References

Impact

Patches

Workarounds

References

Impact

Patches

Workarounds

References

Impact

Patches

Workarounds

References

Impact

Patches

Workarounds

References

Impact

Patches

Workarounds

References