CVE-2020-14343 is an arbitrary code execution vulnerability in PyYAML before version 5.4. The flaw affects applications that deserialize untrusted YAML using the full_load method or the FullLoader loader. By crafting malicious YAML that abuses the python/object/new constructor, an attacker can trigger unsafe object construction during deserialization and execute arbitrary code in the context of the consuming application. The issue was caused by an incomplete fix for CVE-2020-1747, leaving FullLoader-based parsing paths exploitable despite prior hardening efforts.
Mallory correlates every CVE against your assets, your vendors, and active adversary campaigns. Know which vulnerabilities matter for you, not just which ones are loud.
What it means. What to do now. Patch path, mitigations, and the assume-compromise checklist.
What an attacker gets, and what they’ve been doing with it.
If you can’t patch tonight, do this now.
Patch, then assume compromise.
6 valid exploits after Mallory filtered fakes, detection scripts, and README-only repos (1 hidden).
This 11-file Docker lab demonstrates CVE-2020-14343 against a deliberately vulnerable Flask application. The main reproduction script, exploit/reproduce.py, POSTs a Python-tagged YAML document to /parse. The vulnerable application at vulnerable/app.py uses PyYAML 5.3.1 and yaml.load with yaml.FullLoader, allowing the payload's eval-based construction path to execute a benign print marker in the server process. This is a controlled proof of code execution rather than an interactive shell or persistence payload. Docker Compose publishes the vulnerable container on localhost:5000 and a patched comparison container on localhost:5001. The patched app uses PyYAML 5.4 and yaml.safe_load, which rejects the Python-specific tags. detection/detect.py is a separate version-based Docker inspection utility; it checks the installed PyYAML version in cve-vulnerable by default and is not itself an exploit. The repository contains Python application, exploit, and detection code, Dockerfiles for both environments, dependency manifests, Compose configuration, and extensive lab documentation.
This repository is a small, intentionally vulnerable demonstration app rather than a stealth exploit kit. Its core exploit logic is in app.py, a Flask application that accepts user input from the name parameter on the root route and passes it directly to yaml.load() without a safe loader. With PyYAML==5.1, this exposes CVE-2020-14343, allowing attacker-controlled YAML tags such as !!python/object/apply and !!python/name:eval to trigger arbitrary Python execution. Repository structure: app.py contains the vulnerable web app and the exploit-trigger handling; requirements.txt pins the vulnerable dependency PyYAML==5.1 and Flask; README.md documents the vulnerability, exploit payload, and remediation workflow; .github/workflows/build-and-run.yml starts the vulnerable app and exposes it via ngrok; .github/workflows/seal-security.yml applies Seal remediation and reruns the app; Jenkinsfile shows equivalent CI integration for Seal in Jenkins. Exploit capability: remote web-based RCE through unsafe deserialization. The supplied payload executes Python code that imports subprocess and runs the id command. The app then schedules os._exit(1) after returning a success page, intentionally crashing the server to visibly prove compromise. Both GET /?name=... and POST / with form field name are viable delivery paths. Notable endpoints and observables include the vulnerable route /, the exploit parameter name, a hardcoded public ngrok hostname overcovetous-cementless-annette.ngrok-free.dev, the fully URL-encoded exploit request embedded in workflow logs, localhost:5000 for local testing, and external infrastructure for Bootstrap CDN, ngrok download, and Seal services. The workflows also contain a hardcoded ngrok authtoken, which is a sensitive observable. Overall purpose: this is an operational proof-of-concept repository designed to demonstrate exploitation of CVE-2020-14343 before remediation and blocking of the same payload after dependency replacement by Seal Security. It is a real exploit demo, not merely a detector, because it includes a working malicious payload path and observable post-exploitation behavior.
Repository is a PoC + helper scanner for CVE-2026-24009 (docling-core unsafe YAML deserialization) that becomes exploitable when combined with PyYAML < 5.4 behavior (referenced as CVE-2020-14343). Structure: - README.MD: explains vulnerable version ranges (docling-core >=2.21.0,<2.48.4; PyYAML <5.4), root cause (unsafe loader usage), reproduction steps, and mitigations (upgrade docling-core >=2.48.4 or PyYAML >=5.4). - malicious.yaml: payload YAML using !!python/object/new and !!python/name:eval to execute an OS command during deserialization. - repro_docling_load.py: PoC runner that calls DoclingDocument.load_from_yaml('malicious.yaml'), then checks for /tmp/docling_cve_poc_marker to confirm execution occurred during parsing (even though validation later fails). - check_loader.py: introspection utility that prints PyYAML version and the source of DoclingDocument.load_from_yaml to confirm whether yaml.FullLoader vs yaml.SafeLoader is used. - scanner/scan_cve_2026_24009.py (+ scanner/README.md): a simple local scanner that (1) queries installed docling-core and PyYAML versions by spawning a specified Python interpreter, and (2) optionally scans a project directory for direct sink usage patterns (DoclingDocument.load_from_yaml(...) or load_from_yaml(...) with import hints). It outputs classifications like NOT_VULNERABLE, VULNERABLE_DEPENDENCIES_ONLY, or POTENTIALLY_EXPLOITABLE. Overall purpose: demonstrate and validate RCE via unsafe YAML loading in docling-core under specific dependency conditions, and provide a lightweight tool to identify vulnerable environments and direct sink usage.
Repository contains a minimal Python proof-of-concept for CVE-2020-14343 (PyYAML unsafe deserialization). Structure: (1) `01.py` is the only executable code and demonstrates the vulnerability by defining a malicious YAML document using the `!!python/object/apply:os.system` tag and then calling `yaml.load(malicious_yaml, Loader=yaml.UnsafeLoader)`, which results in OS command execution (`whoami`). It then shows the safe pattern using `yaml.safe_load()` inside a try/except, printing the exception to demonstrate mitigation. (2) `01-uast.json` is an AST/analysis artifact of `01.py` (not required to run). (3) `README.md` only names the repo. No network communication, C2, or external endpoints are present; the only observable action is local command execution via `os.system` when unsafe loading is used.
This repository provides a working proof-of-concept exploit for CVE-2020-14343, a remote code execution vulnerability in PyYAML versions prior to 5.4. The exploit consists of a single Python script (cve-2020-14343-poc.py) and a README.md with detailed usage instructions and background information. The exploit works by uploading a maliciously crafted YAML file to a vulnerable web application's /upload endpoint. The payload leverages PyYAML's unsafe deserialization to execute arbitrary Python code, which in this case launches a bash reverse shell to the attacker's machine. The script also includes a built-in TCP listener to catch the reverse shell. The attack requires the target application to expose /upload and /login endpoints and to process uploaded YAML files with yaml.load(). The code is operational and demonstrates a full attack chain, from payload delivery to shell access.
This repository contains a single Python script (poc.py) that serves as a proof-of-concept exploit for CVE-2020-14343, a deserialization vulnerability in PyYAML. The script constructs a malicious YAML file that, when deserialized by a vulnerable server, executes a bash reverse shell command to the attacker's machine. The exploit works in two stages: first, it uploads the malicious YAML file to the target's /upload endpoint; second, it triggers the vulnerability by sending a login request to the /login endpoint. The script also includes a simple TCP listener to catch the reverse shell. The code is operational and demonstrates remote code execution via a network attack vector, targeting Python web applications using vulnerable PyYAML deserialization. The endpoints /upload and /login are fingerprintable, and the exploit requires the attacker to specify their own IP and port for the reverse shell connection.
Products and vendors Mallory has correlated with this vulnerability. Open in Mallory to drill down to specific CPE configurations and version ranges.
Vendor-confirmed product mapping. Mallory continuously reconciles this list against your asset inventory.
6 sources tracked across advisories, community write-ups, and news. New activity surfaces here as Mallory finds it.
A vulnerability affecting the python3-pyyaml package on SUSE Linux 12, addressed by advisory SUSE-SU-2026:4402-1. The listed CVSS vectors indicate network exploitation without authentication or user interaction, with high confidentiality, integrity, and availability impacts. The content does not describe the underlying flaw.
A PyYAML FullLoader deserialization/code execution vulnerability discussed as one of the flaws that affected PyYAML before fixes in version 5.4.
Unknown
Query your assets running an affected version, and investigate the blast radius.
Every observed campaign linking this CVE to a named adversary.
Malware families riding this exploit, with evidence and IOCs.
YARA, Sigma, Snort, and vendor rules, auto-deployed to your SIEM.
Cross-references every affected SKU, including bundled OEM variants.
Community discussion across Reddit, Mastodon, and other social sources.