⚠ Authorized testing only. Disclosed public bug-bounty data for defensive/educational research. Use payloads only against systems you are permitted to test.
LogoThe Hacktivity Field GuideReal-world web hacking, catalogued βŒ‚
πŸ”Ž
Field Guide/Vulnerabilities/Man-in-the-Middle
Vulnerabilities

Man-in-the-Middle

Specimens 12No direct PortSwigger lab
⚠ Thin coverage β€” only 12 disclosed reports for this class; illustrative, not exhaustive.

Β§Basic information

Machine-in-the-Middle (MITM) is any bug where an attacker on β€” or able to claim β€” the network path between two endpoints reads, forges, or replaces traffic the victim believed was authenticated and confidential. It is not one bug but a family: a single plaintext http:// hop, a middlebox that strips HSTS, a TLS library that reuses an unverified connection, a squattable named pipe, a rogue router advertisement, or a Wi-Fi frame-injection flaw all collapse an "encrypted" channel back to cleartext.

The core mechanism is misplaced transport trust: an endpoint treats a channel as verified when some link in the chain never actually verified it. Two halves recur. Path bugs put you (or let you route yourself) between the endpoints β€” rogue IPv6 RA, IP hijack, ARP/BT/pipe squatting. Trust bugs make the endpoint accept an attacker-controlled channel it should have rejected β€” no pinning, HSTS stripped, verify-mode skipped on connection reuse, integrity-failure not discarded. A report only needs one half plus a plausible position for the other. Most of the time you never need a live on-path position to file β€” you simulate it.

Β§Methodology

  1. Enumerate every hop of every "secure" flow. SSO/OAuth authorize, redirect_uri, intermediate redirects, update manifests, download links, in-app API calls. Any single http:// hop that carries a secret or runnable content is a finding.
  2. Grep for plaintext delivery of runnable / security-relevant content β€” installers, binaries, scripts, SWFs, and auth endpoints served over http:// when https:// exists.
  3. Simulate the on-path position. Point a hostname at an attacker IP via the hosts file (cert-block simulation) or drop an intercepting proxy with a custom CA in front of the client.
  4. Probe the trust check. Does the client still hard-block the cert error? Does it re-verify after restart? Does it pin? Does a middlebox re-add a click-through override?
  5. For libraries/protocols, audit the verify path directly — connection-reuse caches (are all TLS settings compared?), integrity-failure branches (is the whole message discarded?), signed→unsigned assignments, and scheme flags that exempt STARTTLS.
  6. For fabric bugs, check whether the L2/L3 assumption actually holds: is IPv6 hard-disabled or merely unused? Are externalIPs/pipe DACLs validated? Does reconnection re-authenticate?
# Any http:// hop to a binary, installer, script, or auth endpoint is a finding grep -RniE 'http://[^"'\'' ]+\.(exe|dmg|apk|tar\.[a-z0-9]+|zip|sh|swf)' . grep -RniE 'http://[^"'\'' ]*/(oauth|authorize|login|sso|saml)' .

Β§Technique variants

Find which class the target fits, then use the matching probe/exploit.

Plaintext hop in a "secure" flow

A single http:// hop leaks whatever crosses it. In SSO/OAuth the prize is the session-bound state/code; capture it on-path and complete the flow yourself to log the victim into an attacker-controlled session (login-CSRF β†’ ATO). For downloads, the prize is the binary itself β€” swap it for a trojanized build.

# One plaintext authorize hop leaks the state+code (#703759) GET http://www.PROVIDER/oauth/authorize?response_type=code&display=popup&client_id=...&state=<session-bound>&redirect_uri=https%3A%2F%2FTARGET%2Fredirector # Plaintext installer delivery -> swap the artifact in transit (#84797) http://download.TARGET/community/installer-stable.tar.bz2 # https:// exists -> avoidable MITM

Client transport-trust config (pinning / verify skipped)

The endpoint runs TLS but never enforces it. Mobile apps that toggle a "secure connection" but don't persist it after restart and don't pin; TLS libraries whose connection-reuse cache skips the verify/pin re-check. Prove it with an intercepting proxy + custom CA.

# Mobile: install custom CA, set device proxy -> mitmproxy/Burp, then KILL and relaunch the app. # TELL: readable traffic after restart = "secure" toggle not enforced AND no pinning (#64731) # curl STARTTLS connection reuse skips pinning/verify (#3718195, CVE-2022-27782 sibling) # Both transfers MUST run in ONE curl process (--next) so they share the connection cache; # two separate curl invocations each get their own pool and would NOT reuse the conn. curl --ssl-reqd --insecure imap://TARGET/ \ --next \ --ssl-reqd --pinnedpubkey KEY imap://TARGET/ # handle B reuses A's unverified conn -> pin check NEVER runs

TLS-terminating middlebox strips HSTS

AV / "web protection" / corporate proxies that break up HTTPS to scan it take over certificate validation β€” and downgrade it. Where a browser hard-blocks a cert error on an HSTS/preloaded site, the middlebox re-adds a clickable override, turning HSTS-immune high-value sites back into MITM targets. Simulate with a hosts-file redirect.

# %WINDIR%\system32\drivers\etc\hosts -- redirect an HSTS-preloaded host to a wrong IP 93.184.216.34 www.google.com # Load with the TLS-scanning AV installed. A bare browser HARD-blocks (HSTS). # TELL: an "I understand the risks" override reappears -> middlebox stripped HSTS enforcement (#461780)

Integrity / crypto wrapper failure

On a cryptographically protected channel (GSSAPI/krb5), the verify-failure branch must discard the whole message. A "log-and-continue" path that overwrites only a prefix leaves the rest of the attacker bytes intact as forged responses β€” and error sentinels (-1) flowing into unsigned size fields underflow and leak memory.

// GSS-unwrap failure masks only 5 bytes; rest of attacker data survives as forged FTP responses (#1590071) maj = gss_unwrap(&min, *context, &enc, &dec, NULL, NULL); if (maj != GSS_S_COMPLETE) { if (len >= 4) strcpy(buf, "599 "); // only overwrites 5 bytes -- attacker's remaining bytes survive return -1; // becomes size_t buf->size -> underflow -> heap leak }

Local IPC as a network (named-pipe squat)

On Windows, named pipes without an explicit restrictive DACL are squattable: multiple instances of the same name coexist, so a local attacker races to own an instance a client binds to, then relays to the real server β€” MITMing a cleartext local protocol.

# Attacker creates an extra instance of the target's named pipe and waits for a client (#1019891) # On client connect: open the REAL pipe as a client, relay both ways -> read/alter cleartext SQL. # Audit CreateNamedPipe() calls for missing/weak security descriptors.

L2/L3 network fabric

Claim or reconfigure the path itself.

# Kubernetes externalIPs / LoadBalancer-status IP hijack (#764986, CVE-2020-8554) # Anyone able to create Services can claim ANY IP -- kube-proxy routes it to the attacker pod. apiVersion: v1 kind: Service metadata: {name: mitm-external-eip, namespace: kubeproxy-mitm} spec: ports: [{name: https, port: 443, targetPort: 8443}] selector: {app: echoserver} type: ClusterIP externalIPs: ["VICTIM_IP"] # claim 1.1.1.1, a ClusterIP, a pod IP...
# LoadBalancer variant patches status -- only THIS path can claim 127.0.0.1 (#764986) curl -XPATCH -H 'Content-Type: application/merge-patch+json' \ '.../services/mitm-external-lb/status' \ -d '{"status":{"loadBalancer":{"ingress":[{"ip":"VICTIM_IP"}]}}}'
# Rogue IPv6 Router Advertisements MITM an "IPv4-only" cluster (#819717) # From a root container (CAP_NET_RAW is enough): broadcast crafted ICMPv6 RAs on the veth/host link. # Host (accept_ra=1) autoconfigures a default route pointing at you. Run a USERSPACE TCP/IP stack # (POC: smoltcp) since CAP_NET_ADMIN/iptables are unavailable. Dual-stack A+AAAA DNS + happy-eyeballs # means clients try IPv6 FIRST -> you MITM even hosts that "used no IPv6". sysctl net.ipv6.conf.<iface>.accept_ra # 1 = spoofable; fix: 0 (or ipv6.disable=1)
# Bluetooth SSP reconnection impersonation -- no pairing mode, no user action (#2642615) echo 'PRETTY_HOSTNAME=Example Laptop' >> /etc/machine-info # match victim's paired-peer name ./chgbtaddr -addr 00:11:22:33:44:55 # clone the paired-peer BT address sudo systemctl restart bluetooth.service bluetoothctl discoverable on # Wait for the target to power-cycle/idle-off, short-press power (avoids pairing mode) -> it # auto-connects to you. Impersonate BOTH peers -> full BT MitM.
● NOTE
Wi-Fi FragAttacks (#1238470) is the fabric-injection variant: the A-MSDU flag in the plaintext 802.11 header is unauthenticated, and receivers reassemble fragments across keys / from stale caches β€” so plaintext (fragmented) frames are accepted even in protected networks. Run fragattacks against both clients and APs; injected frames enable DNS hijack and internal-network pivots.

Parallel-channel config write

A sensitive settings store served over HTTPS is still MITM-able if a parallel http:// path can write the same state. Check whether security-relevant settings/cookies can be set over an unauthenticated channel.

# Flash settings-manager: SWF served over HTTPS but the same settings store is writable over HTTP (#54094) # Serve a modified settings SWF at the manager path via mitmproxy over the victim's HTTP traffic # -> persist webcam/mic grants, CORS exemptions, or disable auto-update for the attacker's domain.

Β§Bypasses

Filter / controlBypassSeen in
HSTS enforcementTLS-scanning AV outsources cert decisions, re-adds a click-through override on preloaded sites#461780
Pinning / verifypeerSTARTTLS schemes lack PROTOPT_SSL, so the conn-reuse config-match is never called; handle B reuses handle A's unverified session#3718195
Integrity checkGSS-unwrap failure overwrites only a 5-byte 599 prefix; rest of attacker bytes survive as forged FTP responses (-1β†’size_t underflow leaks heap)#1590071
"IPv4-only" networkIPv6 merely unused (accept_ra=1), not ipv6.disable=1; CAP_NET_RAW + a userspace stack MITMs without CAP_NET_ADMIN#819717
Loopback guard127.0.0.1 blocked for externalIPs but claimable via the LoadBalancer-status path#764986
WPA/WPA2 protectionunauthenticated A-MSDU flag + mixed-key / stale-cache fragment reassembly injects plaintext frames into protected networks#1238470
Reconnection authSSP re-authentication not run on reconnect; matching address+name is trusted, no pairing mode needed#2642615
HTTPS-only settings storethe same Flash settings SWF/cookie is writable over a parallel http:// path#54094
Named-pipe ACLWindows multi-instance pipes with weak/absent DACL let a hostile instance win the client bind#1019891
β–² WARNING
A "missing pinning" or "http:// link" finding is only real with a plausible position. Simulating the on-path role (hosts file, proxy + custom CA, local user for a pipe squat) is enough to demonstrate it β€” but a report that just observes plaintext with no secret/runnable content crossing it, and no demonstrated interception, closes as informative. Show what you capture or swap, not merely that the channel is plaintext.

Β§Escalation & impact

MITM is a position primitive; the impact is whatever you inject once you hold it.

Β§Prevention

Β§Tools

✦Specimens β€” real-world examples

The techniques above are the general method. Below, each disclosed HackerOne report is a catalogued example β€” concrete payload, outcome, and matching practice lab. 12 in this class.

Real-world example

Bluetooth reconnection auth bypass by impersonating a paired device (SSP non-compliance)

β—† High
Specimen #2642615 Β· sony Β· none Β· 71 votes Β· resolved
Program sonySurface otherChain impersonate laptop -> connect to headphones; impersonate

Root cause

On reconnection the device does not follow Secure Simple Pairing's re-authentication; an attacker who clones a previously-paired peer's BT address and adapter name connects with no user interaction and even when the device is not in pairing mode.

Method

  1. Pair victim device with its legitimate master in advance.
  2. Spoof the Raspberry Pi's BT address (script) and adapter name to match the victim's master, set Discoverable.
  3. Wait for the target to power-cycle/idle-off; power it on (short-press to avoid pairing mode) -> it auto-connects to the attacker with no prior pairing.
# change BT name echo 'PRETTY_HOSTNAME=Example Laptop' >> /etc/machine-info # change BT address (Go helper from report) go build main.go -o chgbtaddr ./chgbtaddr -addr 00:11:22:33:44:55 sudo systemctl restart bluetooth.service bluetoothctl discoverable on

Insight β€” For BT/BLE devices, test whether reconnection re-runs authentication or just trusts a matching address+name. Spoof the paired peer identity while the device is out of pairing mode; success = impersonation primitive that, combined with power-save/idle-off session drops, yields a full MitM.

Real-world example

Windows named-pipe squatting/MITM via weak security descriptor

β—† High
Specimen #1019891 Β· mariadb Β· none Β· 9 votes Β· resolved
Program mariadbSurface desktopChain pipe instance squatting -> MITM cleartext protocol ->

Root cause

MariaDB's named-pipe server is created without a restrictive security descriptor, so any local user can create additional instances of the same pipe; an attacker races to own an instance a client connects to, then proxies to the real server, MITMing cleartext SQL traffic.

Method

  1. Attacker creates an instance of the MariaDB named pipe and waits for a client to connect to it
  2. On client connect, attacker opens the real pipe server instance as a client
  3. Attacker relays messages both ways, reading/altering the cleartext SQL and running commands as the connected user

Insight β€” On Windows, named pipes without an explicit restrictive DACL are squattable: multiple instances of the same name coexist and clients may bind to a hostile one. Audit CreateNamedPipe calls for missing/weak security descriptors; the same pattern enables local privilege escalation and credential theft in many services.

Real-world example

TLS-intercepting security software strips HSTS enforcement

β—† Medium
Specimen #461780 Β· kaspersky Β· none Β· 41 votes Β· resolved
Program kasperskySurface desktopTag account-takeover

Root cause

AV/'web protection' products that break up HTTPS to scan it take over certificate validation but do not honor HSTS (preload list or Strict-Transport-Security header). Where a browser would hard-block a cert error on an HSTS site, the AV re-adds a clickable 'I understand the risks' override, re-enabling MITM against sites that should be immune.

Method

  1. Confirm target host is HSTS-preloaded / sends Strict-Transport-Security.
  2. Simulate MITM by pointing the hostname at an attacker IP (edit hosts file to a wrong IP for www.google.com).
  3. Load the site with the TLS-scanning AV installed; observe an override option ('I understand the risks') appears despite HSTS.
  4. User (or social-engineered victim) clicks through -> attacker-served content is accepted.
# %WINDIR%\system32\drivers\etc\hosts 93.184.216.34 www.google.com # example.com IP, simulates MITM of an HSTS-preloaded host

Insight β€” Any middlebox that MITMs TLS (AV, corporate proxy, parental filter) is a downgrade of the browser's own defenses: test whether it re-enables cert-warning bypass on HSTS/preloaded sites. AV presence is fingerprintable, so an attacker only fires when the weakened client is present.

Real-world example

Flash settings-manager MITM: local SWF loadable over HTTP sets sandbox perms

β—† Medium
Specimen #54094 Β· ibb Β· awarded Β· 12 votes Β· resolved
Program ibbSurface desktopChain network MITM -> write persistent Flash sandbox settings (Tag cors

Root cause

The Flash Player settings manager is served over HTTPS, but the local settings SWF/cookie can also be placed/edited by serving the corresponding path over plain HTTP, so a network MITM can write persistent sandbox settings.

Method

  1. MITM the victim's HTTP traffic (e.g. mitmproxy) and serve an altered settings SWF on the matching path
  2. Write local settings granting webcam/mic access, CORS exemptions, or disabling auto-update
  3. Settings persist, widening the attack surface for the attacker's domain
# serve modified settings SWF over HTTP at the settings-manager path via mitmproxy; embed remote SWF or inject into victim HTTP traffic

Insight β€” A sensitive config surface delivered over HTTPS is still MITM-able if a parallel HTTP path can write the same state. Check whether security-relevant settings/cookies can be set over an unauthenticated/HTTP channel.

Real-world example

IPv6 rogue router advertisements MITM on IPv4-only clusters

β—† Medium
Specimen #819717 Β· kubernetes Β· awarded Β· 10 votes Β· resolved
Program kubernetesSurface cloudChain Rogue IPv6 RA -> host IPv6 MITM -> chain apt CVE-2019-Tag cloud-gcp

Root cause

IPv4-only Kubernetes nodes usually leave IPv6 not fully disabled, with accept_ra=1 and forwarding=0. A process running as root in a container (default CAP_NET_RAW, veth to host) can broadcast rogue IPv6 Router Advertisements that reconfigure the host's IPv6 stack, redirecting the host's IPv6 traffic to the attacker container. Dual-stack DNS (A+AAAA) means clients try IPv6 first, giving the attacker a window even where no IPv6 was in use.

Method

  1. From a root container, use CAP_NET_RAW to send crafted ICMPv6 Router Advertisements onto the veth/host link.
  2. Host accepts RA (accept_ra=1) and autoconfigures IPv6 default route/prefix pointing at the attacker.
  3. Run a userspace TCP/IP stack (POC uses smoltcp) since CAP_NET_ADMIN/iptables are unavailable; listen on IPv6 addresses.
  4. Victim host resolves A+AAAA, connects over IPv6 first -> reaches attacker = MITM; optionally chain a host-side RCE (apt CVE-2019-3462) to escalate to the node.
# root-in-container POC (smoltcp): broadcast rogue IPv6 RA + serve dummy HTTP on any v6 addr # fix: set net.ipv6.conf.<iface>.accept_ra=0 on all CNI/K8s-managed interfaces

Insight β€” IPv6 SLAAC/RA spoofing MITMs 'IPv4-only' networks whenever IPv6 is merely unused rather than hard-disabled (ipv6.disable=1). CAP_NET_RAW alone (no CAP_NET_ADMIN) suffices by implementing the stack in userspace. Always check accept_ra and whether IPv6 is truly off, not just unconfigured.

Real-world example

Kubernetes Service externalIPs/LoadBalancer status hijacks arbitrary IPs (CVE-2020-8554)

β—† Medium
Specimen #764986 Β· kubernetes Β· awarded Β· 2 votes Β· resolved
Program kubernetesSurface cloudChain Service create/patch -> kube-proxy routes victim IP to atTag cloud-gcp

Root cause

Any principal able to create/patch Services can set spec.externalIPs to an arbitrary IP, or (with status patch rights) set a LoadBalancer ingress IP, with no validation that the IP belongs to the cluster's allocation. kube-proxy programs iptables/IPVS to route that IP to the attacker's pod, intercepting traffic destined for external IPs (e.g. 1.1.1.1), ClusterIPs, pod IPs, or 127.0.0.1.

Method

  1. As a user who can create Services, deploy an attacker echo/mitm pod + Service.
  2. ExternalIPs path: create a ClusterIP Service with spec.externalIPs=[victimIP].
  3. LoadBalancer path: create a LoadBalancer Service then patch status.loadBalancer.ingress[].ip=victimIP via the API.
  4. kube-proxy now routes victimIP to the attacker pod; test node->IP and pod->IP curls to confirm interception (external IP, ClusterIP, pod IP; 127.0.0.1 works only via LB path).
apiVersion: v1 kind: Service metadata: {name: mitm-external-eip, namespace: kubeproxy-mitm} spec: ports: [{name: https, port: 443, targetPort: 8443}] selector: {app: echoserver} type: ClusterIP externalIPs: ["1.1.1.1"] --- # LoadBalancer variant: patch status curl -XPATCH -H 'Content-Type: application/merge-patch+json' \ '.../services/mitm-external-lb/status' \ -d '{"status":{"loadBalancer":{"ingress":[{"ip":"1.1.1.1"}]}}}'

Insight β€” In multi-tenant Kubernetes, the ability to create Services is an IP-hijacking / MITM primitive: externalIPs and LB status IPs are trusted by kube-proxy without ownership checks. Mitigate with an admission controller (later shipped as the externalIP webhook) restricting externalIPs/LoadBalancer IP ranges. When testing clusters, try claiming a ClusterIP, pod IP, or 127.0.0.1 to intercept internal service traffic.

Real-world example

OAuth/SSO authorize redirect over http enables MITM takeover

β—† Low
Specimen #703759 Β· bumble Β· 150 Β· 14 votes Β· resolved
Program bumbleSurface webChain http authorize hop -> MITM intercept state/code -> accTag oauthTag account-takeover

Root cause

The SSO flow redirects the user to the identity provider's plaintext http authorize URL; a network attacker can serve a fake login page (credential theft) or capture the http-borne state/code and replay it to authenticate as/into the victim.

Method

  1. Start SSO login and capture the redirect to the IdP authorize endpoint
  2. Confirm the authorize URL uses http:// (not https)
  3. From a MITM position, either phish credentials on a fake IdP page or intercept the state/code and complete the flow
http://www.PROVIDER/oauth/authorize?response_type=code&display=popup&client_id=...&scope=...&state=<session-bound>&redirect_uri=https%3A%2F%2FTARGET%2Fredirector

Insight β€” Inspect every hop of SSO/OAuth flows for http:// URLs (authorize endpoint, redirect_uri, intermediate redirects); a single plaintext hop leaks the state/code and enables credential-phishing or login-CSRF for a MITM attacker.

Real-world example

FTP-KRB response injection via mishandled gss_unwrap error (CVE-2022-32208)

β—† Low
Specimen #1590071 Β· curl Β· none Β· 11 votes Β· resolved
Program curlSurface otherChain integrity-check bypass -> control-channel response inject

Root cause

On a GSSAPI-protected FTP control channel, when gss_unwrap returns an error curl only prefixes the buffer with '599 ' and returns -1, but read_data assigns that -1 into a size_t buf->size and does not discard the raw attacker bytes, so unverified server data is treated as legitimate FTP responses and an underflowed size later leaks heap memory.

Method

  1. MITM (or malicious server) sends data that fails GSS verification on a krb5 FTP control channel
  2. curl writes only a 5-byte '599 ' junk prefix but keeps the rest of the attacker bytes as response lines
  3. Attacker picks a protocol position where 599 is non-fatal, then forges subsequent (predicted) control responses; -1 -> size_t underflow additionally leaks heap
maj = gss_unwrap(&min, *context, &enc, &dec, NULL, NULL); if(maj != GSS_S_COMPLETE) { if(len >= 4) strcpy(buf, "599 "); // only masks 5 bytes, rest of attacker data survives return -1; // becomes size_t buf->size -> underflow }

Insight β€” When an integrity check fails, the failure path must DISCARD the whole message, not partially overwrite it, and error sentinels (-1) must never flow into unsigned size fields. Audit crypto/verify wrappers for 'log-and-continue' handling and signed->unsigned assignments.

Real-world example

Executable/software download delivered over plaintext HTTP (MITM binary tampering)

β—† Low
Specimen #84797 Β· owncloud Β· none Β· 2 votes Β· resolved
Program owncloudSurface webChain MITM position -> replace HTTP-delivered installer -> cTag supply-chain

Root cause

A download link for an installable artifact (tar.bz2) pointed at http:// even though https:// was available, letting a network attacker transparently replace the binary with a malware-bound version.

Method

  1. Find download/update links for installers, binaries, or archives in pages/emails
  2. Check the scheme - if http://, a MITM attacker can intercept and swap the file for a trojanized build
  3. Confirm the same host also serves https:// (proving the http link is an avoidable exposure)
http://download.owncloud.org/community/owncloud-daily-stable8.1.tar.bz2 (should be https://download.owncloud.org/...)

Insight β€” Grep target pages, emails and update manifests for http:// links to executables/archives/scripts. Plaintext delivery of runnable content is a real supply-chain/MITM finding even without a stored bug - the fix is forcing HTTPS (and ideally signature verification).

Real-world example

STARTTLS connection reused without TLS-config match (curl)

β—† Low
Specimen #3718195 Β· curl Β· none Β· 2 votes Β· resolved
Program curlSurface otherChain connection-reuse pooling flaw -> pinning/verifypeer bypas

Root cause

curl's connection-reuse ssl-config comparison (Curl_ssl_conn_config_match) is gated on the scheme flag PROTOPT_SSL; STARTTLS protocols (imap/pop3/smtp/ftp/ldap with CURLOPT_USE_SSL) run TLS but lack that flag, so a second handle silently reuses an existing TLS session without re-checking verifypeer/pinning.

Method

  1. Handle A connects imap://host with USE_SSL=ALL and VERIFYPEER=0; an on-path attacker MITMs the STARTTLS upgrade.
  2. Handle B connects the same imap://host with USE_SSL=ALL, VERIFYPEER=1 and a pinned key.
  3. Because the plain imap:// scheme lacks PROTOPT_SSL, url_match_ssl_config returns TRUE without calling the ssl-config comparison.
  4. B reuses A's unverified/attacker-controlled TLS session; B's verifypeer and pinning never run.
# Same bug class as CVE-2022-27782; STARTTLS protocols missed the fix. # A: curl --ssl-reqd --insecure imap://host/ (attacker MITMs STARTTLS) # B: curl --ssl-reqd --pinnedpubkey <key> imap://host/ (reuses A's conn, checks skipped)

Insight β€” When auditing any connection-pool/keep-alive cache, verify that ALL security-relevant settings (TLS verify mode, pinned key, client cert, SNI) are compared before a reuse, and that protocol-upgrade (STARTTLS) connections are not exempted by a scheme flag. A partial gate that only covers 'implicit TLS' schemes leaves the upgrade path unchecked.

Real-world example

Mobile app 'secure connection' not enforced + no certificate pinning

β—† Low
Specimen #64731 Β· vkcom Β· awarded Β· 4 votes Β· resolved
Program vkcomSurface mobile-ios

Root cause

The app's HTTPS/secure-connection setting is not persistently enforced and no certificate pinning is applied, so a proxy/attacker on the network can transparently intercept and read the app's traffic.

Method

  1. Log in and enable the app's 'secure connection (HTTPS)' setting
  2. Kill and relaunch the app behind an intercepting proxy
  3. Observe traffic is downgraded/unpinned and fully interceptable

Insight β€” Test mobile apps for (1) HTTPS actually enforced after restart, not just toggled, and (2) absence of certificate pinning -- both let a network MITM read sensitive traffic. Use an intercepting proxy + custom CA; if it works, pinning is missing.

Real-world example

FragAttacks: Wi-Fi fragmentation/aggregation packet injection

β—† Info
Specimen #1238470 Β· ibb Β· awarded Β· 14 votes Β· resolved
Program ibbSurface networkChain packet injection -> malicious DNS / SSL strip / NAT hole-

Root cause

Design and implementation flaws in 802.11: the A-MSDU flag in the plaintext header is unauthenticated, plaintext (fragmented) frames are accepted in protected networks, and receivers reassemble fragments across keys or from stale caches - enabling arbitrary packet injection and data exfiltration.

Method

  1. Use the fragattacks test tool to probe a client/AP
  2. Inject plaintext or plaintext-fragmented frames accepted despite protection
  3. Abuse the unauthenticated A-MSDU flag to inject packets (with minor social engineering)
  4. Pivot: force a malicious DNS server, or punch NAT holes to attack internal devices
# github.com/vanhoefm/fragattacks test tool (CVE-2020-24586/24587/24588 + impl CVEs)

Insight β€” Protocol-level trust of unauthenticated header fields (the A-MSDU flag) and lax fragment reassembly are a general injection class. For Wi-Fi engagements, run fragattacks against both clients and APs; injected packets enable DNS hijack and internal-network pivots.

Β§References & practice

  1. No dedicated PortSwigger lab for this class; use the methodology above and the cited reports.
  2. All 12 disclosed reports for this class are catalogued as specimens above.
  3. See also: exploit chains Β· payload libraries Β· methodology.