Loading vulnerability…
Lucky Thirteen is a timing side-channel weakness in TLS 1.1/1.2 and DTLS 1.0/1.2 CBC cipher-suite processing, affecting OpenSSL, OpenJDK/JSSE, PolarSSL, and other implementations. During processing of records with malformed CBC padding, MAC verification can take measurably different amounts of time depending on padding and MAC-processing conditions. Statistical analysis of timing responses to crafted records can distinguish these conditions and enable recovery of protected plaintext.
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.
2 valid exploits after Mallory filtered fakes, detection scripts, and README-only repos.
Small standalone Python proof-of-concept repository for CVE-2013-0169 (Lucky13). The repository contains one executable code file, lucky13exploit.py, plus a README, license, and gitignore. The script defines a Lucky13Attacker class that creates crafted byte sequences, hex-encodes them into a Cookie header, and repeatedly issues HTTPS GET requests to a configured target URL using requests.Session with certificate verification disabled. For each target byte position, it tests all 256 possibilities, records elapsed response time and HTTP status, then chooses the fastest candidate as the inferred plaintext byte. The attack loop works backward across up to 16 bytes and prints intermediate and final recovered token values. There is no framework integration, no advanced evasion, and no customizable post-exploitation payload; this is a basic timing-attack PoC rather than a weaponized exploit. The README instructs the user to manually edit the hardcoded example URL before execution.
This repository contains a proof-of-concept Python exploit for the LUCKY13 vulnerability (CVE-2013-0169), a timing attack against CBC-mode cryptography. The repository consists of two files: a README.md explaining the attack and usage, and exploit.py, which implements the attack logic. The exploit works by sending specially crafted cookie values to a target HTTPS server and measuring response times to infer valid padding, thereby decrypting a token byte-by-byte. The code is a standalone script requiring Python 3 and the requests library. The main entry point is exploit.py, which iteratively attempts to decrypt each byte of the token. The script is a POC and requires the user to specify the actual target URL in place of the placeholder. No hardcoded credentials or real endpoints are present, but the attack vector is network-based, targeting web servers vulnerable to LUCKY13.
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.
16 sources tracked across advisories, community write-ups, and news. New activity surfaces here as Mallory finds it.
OpenSSL CBC timing side channel enabling plaintext recovery.
The Lucky Thirteen TLS CBC timing attack, referenced as the canonical example of a classic CBC padding-oracle-style issue.
Lucky 13 timing side-channel in OpenSSL CBC ciphersuite handling enabling plaintext recovery
Lucky 13 is an OpenSSL timing side-channel vulnerability in CBC ciphersuite MAC processing that can enable plaintext recovery.
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.