Your RSA-2048 keys break in 2030. Find every one of them before attackers do.
🐍
🐍 PyPI
Not in CISA KEV
LOW severity

CVE-2020-1736 — ansible

LOW

CVE-2020-1736 is a low-severity (CVSS 3.3) CWE-732 vulnerability in ansible. 1 public exploit reference exists, so weaponization risk is real. No vendor fix is recorded yet; mitigation options are listed below.

Incorrect Permission Assignment for Critical Resource in Ansible

Also known asGHSA-x7jh-595q-wq82PYSEC-2020-8
Published
Updated
Affected
1 pkg
Patched
See advisory
Exploits
1 known
Exploitation data as of Oct 10, 2026 · OSV.dev, NVD, FIRST.org (EPSS)

EPSS Exploitation Probability

via FIRST.org ↗
0.4%probability of exploitation in next 30 days
Lower Risk0.00%
Lower risk than most CVEs33th percentile — riskier than 33% of all scored CVEsHighest risk
0.00%0.30%0.60%0.90%0.0%0.4%Apr 26Aug 26Oct 26

Probability of exploitation in the next 30 days, from FIRST.org EPSS.

How urgent is this, really

CVE-2020-1736 by exploitation likelihood (EPSS) against impact (CVSS). Outside the shaded patch-first corner.

Where this sits among everything scored

Of 385,738 CVEs with a current EPSS score, this one falls in the < 10% band (highlighted). Counts from FIRST.org, log-scaled.

Real-World Exposure

1 pkg affected
🐍ansible

Real-time download stats are indexed for npm and PyPI packages. This vulnerability affects PyPI packages — download data is not available via public APIs for these ecosystems.

Description

A flaw was found in Ansible Engine when a file is moved using atomic_move primitive as the file mode cannot be specified. This sets the destination files world-readable if the destination file does not exist and if the file exists, the file could be changed to have less restrictive permissions before the move. This could lead to the disclosure of sensitive data. All versions in 2.7.x, 2.8.x and 2.9.x branches are believed to be vulnerable.

Affected Packages

1 total
EcosystemPackageVulnerable rangeFix
🐍PyPIansible≥ 2.7.0No fix

Affected Products

5 products · 12 configurations
OS
fedorafedoraproject
2 versions
3132
Application
ansibleredhat
≥ 2.9.0 && ≤ 2.7.16
range
Application
ansible towerredhat
≥ 3.7.0 && ≤ 3.7.2
range
Application
cloudforms management engineredhat
1 version
5.0
Application
openstackredhat
1 version
13
Exploits & PoCs
1

Research use only. For defensive security, authorized penetration testing, and academic research only. Never execute exploit code against systems without explicit written authorization.

A flaw was found in Ansible Engine when a file is moved using atomic_mov…

github.comNVDAug 2021

Detection & mitigation playbook

Open-source dependency

  1. Detect

    Scan your dependency tree (package-lock.json, pnpm-lock.yaml, requirements.txt, go.sum, etc.) for ansible, including transitive dependencies — a direct dependency you never call can still pull in a vulnerable version.

  2. Remediation status

    No patched version of ansible has shipped for CVE-2020-1736 yet. Where your build allows, override or pin the dependency away from the vulnerable range, and apply any maintainer-recommended mitigation.

  3. Mitigate without a patch

    If you can't upgrade right away: gate or disable the affected feature, validate untrusted input at the boundary, and avoid passing attacker-controlled data into the vulnerable path. O3's runtime protection blocks exploitation in production as an interim safeguard until the upgrade lands.

Fixing This On Your OS

If you run this on a Linux distribution, patch through your package manager against the distro's own security advisory below — it tracks the exact backported fix for your release, which can ship on a different timeline (and sometimes a different severity) than the upstream project.

Red HatLow

Ansible Engine 2.8.14 and 2.9.12 as well as previous versions and all 2.7.x versions are affected. Ansible Tower 3.6.5 and 3.7.2 as well as previous versions are affected. In Red Hat OpenStack Platform, because the flaw has a lower impact, ansible is not directly customer exposed, and the fix would require a…

Workaround published by Red Hat
This issue can be mitigated by specifying the "mode" on the task. That just leaves a race condition in place where newly created files that specify a mode in the task briefly go from 666 - umask to the final mode. An alternative workaround if many new files are created and to avoid setting a specific mode for each file would be to set the "mode" to "preserve" value. That will maintain the permissions of the source file on the controller in the final file on the managed host.
Source: Red Hat security advisory for CVE-2020-1736 (CC BY 4.0)
ProductFixed inAdvisory
Red Hat Ansible Engine 2.8 for RHEL 7ansible-0:2.8.15-1.el7aeRHSA-2020:3600
Red Hat Ansible Tower 3.4 for RHEL 7ansible-tower-34/ansible-tower-memcached:1.4.15-28RHBA-2020:0547
Red Hat Ansible Tower 3.5 for RHEL 7ansible-tower-35/ansible-tower:3.5.6-1RHBA-2020:1539

Frequently Asked Questions

A flaw was found in Ansible Engine when a file is moved using atomic_move primitive as the file mode cannot be specified. This sets the destination files world-readable if the destination file does not exist and if the file exists, the file could be changed to have less restrictive permissions before the move. This could lead to the disclosure of sensitive data. All versions in 2.7.x, 2.8.x and 2.9.x branches are believed to be vulnerable.
O3 Security · Impact-Aware SCA

Is CVE-2020-1736 in your dependencies?

Find it across PyPI, including transitive dependencies.

Scan my dependencies How O3 SCA works
CVE-2020-1736: ansible (Low 3.3)