TL;DR

Six attacks are still documented on public WiFi in 2026: Man-in-the-Middle (MITM), Evil Twin (fake hotspot), packet sniffing, ARP spoofing, session hijacking, and compromised captive portals. HTTPS protects content but not the SNI (the destination domain remains visible in plain text) — meaning the WiFi operator still sees which domains you visit. The only effective countermeasure is a VPN active before connecting to the network. Free VPNs are explicitly counter-productive on public WiFi: they monetize your data more thoroughly than the WiFi operator would.

---

What actually happens on a public WiFi connection

When you connect to a public WiFi network, several invisible steps happen between your device and the internet — and each one is a potential point of observation.

Step 1 — DHCP. Your device requests an IP address from the access point, which assigns one along with the local gateway and DNS servers (typically the operator's). This means the operator decides which DNS resolver you'll use.

Step 2 — ARP. Your device announces "I'm IP X with MAC Y". On a public network, this is broadcast to everyone — including potential attackers running tools like arpspoof who can pretend to be the gateway.

Step 3 — DNS resolution. Each website you visit triggers a DNS query. If those queries go through the WiFi operator's resolver (without DoH or VPN), the operator gets a complete log of every domain you visit.

Step 4 — TLS handshake. For HTTPS sites, TLS 1.3 (RFC 8446) encrypts the connection. But the SNI (Server Name Indication) field remains in plain text during the handshake — meaning anyone watching the packets knows you visited mybank.com, even if they can't see what you did there.

Step 5 — Encrypted traffic. Application data is encrypted. But the metadata isn't: packet sizes, timing patterns, destination IPs. A determined observer can derive a lot from this.

---

The 6 documented attacks on public WiFi in 2025-2026

Man-in-the-Middle (MITM)

Classic attack vector. The attacker positions themselves between you and the access point, relaying traffic while reading or modifying it. Tools like Bettercap or mitmproxy make this trivial for someone with basic networking knowledge. Mitigation: HTTPS with HSTS prevents most MITM attacks on the application layer, but DNS-level MITM still works if you don't use DoH.

Evil Twin (fake access point)

Attacker creates an AP with the same SSID as the legitimate one (e.g. Starbucks_WiFi_Free), sometimes with better signal strength. Your device might auto-connect. Once connected, the attacker sees all your traffic. Mitigation: never auto-connect to open networks, verify the official SSID with staff if uncertain.

Packet sniffing

On open networks (no WPA2/WPA3), all traffic is broadcast in clear. Anyone with Wireshark can read it. WPA2/WPA3 networks encrypt per-device, but not all "public" networks actually use encryption — many captive-portal networks remain fully open.

ARP spoofing

Attacker sends crafted ARP packets to convince the network that they are the gateway. All your traffic is then routed through them. Mitigation: static ARP tables (impractical for mobile), or simply a VPN that encrypts everything.

Session hijacking

Cookies set without the Secure flag travel in clear. Attacker captures the session cookie and impersonates you. Modern frameworks set Secure and HttpOnly by default, but legacy sites still exist.

Compromised captive portal

Even legitimate captive portals can be compromised (XSS, host header injection). Attacker injects malicious JS that runs before you've connected your VPN. Mitigation: connect VPN first when possible, dismiss the captive portal in a sandboxed browser session.

---

What the WiFi operator sees, by setup

The verdict is uncomfortable: with HTTPS alone, the operator still knows every domain you visit. Only DoH or VPN provides actual domain-level privacy.

---

Why HTTPS isn't enough on public WiFi

HTTPS protects:

• Content of requests and responses
• Headers (including cookies)
• Form submissions

HTTPS does NOT protect:

• The SNI field (server name during TLS handshake) — visible in plain text
• DNS queries (unless DoH/DoT is used)
• The destination IP (visible by definition)
• Timing patterns and packet sizes

RFC 8446 (TLS 1.3) addressed many issues but SNI plaintext remains a known leak. RFC 9116 (Encrypted Client Hello, ECH) proposes a fix but rollout is fragmented in 2026.

---

The actual role of a VPN on public WiFi

A VPN does three concrete things on public WiFi:

1. Encrypts end-to-end between your device and the VPN server. The WiFi operator sees only encrypted traffic going to a single IP (the VPN server's).
2. Masks the visible IP. Sites you visit see the VPN server's IP, not your real one.
3. Bypasses hostile captive portals. Some captive portals inject ads or redirect to malicious pages — a VPN tunnel ignores them once active.

What a VPN doesn't do:

• Protect against malware already installed on your device
• Protect against phishing pages
• Protect against attacks at the application layer (XSS, etc.)

For our complete VPN security audit covering 9 different test vectors, see AnonymFlow's complete VPN security audit.

---

Free VPN on public WiFi: a false friend

Free VPNs make money by selling user data — that's their business model. Several documented cases:

• Hola VPN (2015) sold users' bandwidth as a botnet
• Hotspot Shield (2017) was found to inject ads and tracking
• FreeVPN (2020) leaked user logs

A free VPN on public WiFi often monetizes your data more aggressively than the WiFi operator would. You traded one observer for another, possibly worse one.

For the truth about free VPN trials and their hidden conditions, see The truth about VPN free trials.

---

Public WiFi security checklist 2026

Before connecting:

1. Verify the SSID with venue staff (avoid Evil Twins)
2. Turn off file sharing and AirDrop discoverability
3. Activate your VPN before connecting to WiFi (so the tunnel is up the moment you're online)
4. Disable auto-connect to open networks in OS settings
5. Have a fallback (mobile hotspot) if the WiFi is suspicious

During connection:

1. Re-verify VPN is active (status indicator should show connection)
2. Check your IP via a public IP checker — should be the VPN's, not your real one
3. Avoid sensitive operations (banking, password changes) for casual browsing only
4. If captive portal injects unexpected JS, disconnect and use mobile data
5. Disconnect from the WiFi when done — many devices keep credentials and auto-reconnect later

---

Special cases: hotel, airport, conference, café

Hotel WiFi — Often uses Cisco Meraki or similar, which can perform deep inspection and inject ads. Use VPN + your own DNS. See our hotel WiFi VPN guide.

Airport WiFi — Captive portal sometimes HTTPS-only, which blocks VPN handshake until you accept the portal. Workaround: connect via mobile hotspot to accept the portal, then switch to airport WiFi with VPN.

Conference/event WiFi — High Evil Twin risk during tech events (people demonstrate the attack). Always verify SSID, prefer the conference's specifically dedicated network.

Café WiFi — The classic packet-sniffing scenario. Open networks are still common, even in 2026. VPN mandatory.

---

Companion tools

We maintain open-source detection tools that pair with this guide:

• dns-leak-detector-cli — Python CLI to verify DNS isn't leaking on your VPN
• webrtc-leak-detector — Single HTML file to check WebRTC isn't leaking your real IP
• vpn-speed-tester — Python CLI to measure VPN overhead

All MIT licensed, zero-dependency, auditable.

---

Originally published on AnonymFlow — independent VPN/privacy tooling and research. Read our full methodology and the 95-session VPN streaming study.