Public WiFi risks 2026: real, overblown, and what to do

The standard public WiFi risks article has been roughly the same since 2014. Hackers in cafes! Sniffing your packets! Stealing your bank passwords! Buy a VPN! Most of that is no longer accurate. HTTPS deployment killed the easy attacks. The threats that remain are real and different, and the canned advice has not caught up.

This is the 2026 view of public WiFi risks. What is genuinely dangerous, what is mostly hype, where WPA3 has helped, what HTTPS does not protect, and the actual defensive layers. Less alarmism, more accuracy.

Where the old advice came from

Public WiFi attack guides from 2010-2016 assumed a few things that were true at the time:

Most websites were HTTP by default. A passive observer on the network could read login forms, cookies, and page contents.
Browser warnings about HTTPS issues were inconsistent. Users clicked through certificate errors routinely.
Network-level attacks (ARP poisoning, evil twin) were easy with off-the-shelf tools (Firesheep, the Pineapple). Anyone with a laptop and free software could mount them.

In that environment, the "use a VPN on public WiFi" advice was essentially correct. The standalone risk was high enough that even casual attackers caused real harm.

The world changed. By the late 2010s, HTTPS coverage of the open web crossed 80%. Browsers stopped letting users click through certificate warnings without explicit override. Banks, social networks, email providers all moved to HTTPS-only with HSTS. The attack surface for the easy version of public WiFi sniffing collapsed.

What HTTPS handles now

In 2026, more than 95% of the web is HTTPS. For a typical browsing session on public WiFi:

Page contents are encrypted. A network observer cannot read the page you are viewing, the form you are submitting, or the cookies you send.
Authentication tokens are encrypted. The session cookies that would have been the easy steal in the Firesheep era are inside TLS. Reading them off the wire is not feasible.
Server identity is verified. The TLS handshake authenticates the destination. A man-in-the-middle would have to either get a valid certificate for the destination (hard) or trick you into accepting an invalid one (browsers no longer let you do this casually).

The "watch your bank password get stolen" framing common in old VPN ads is mostly obsolete. Banking is HTTPS-only. The browser will refuse to connect with an invalid certificate. The attack surface for that specific scenario shrunk dramatically.

What HTTPS does not handle

The threats are different now, not gone. Specifically:

SNI is plaintext

The TLS handshake includes the destination hostname (Server Name Indication) in the clear. A network observer sees nytimes.com even though they cannot read the article. They learn which sites you visit, when, in what order, for how long.

Encrypted Client Hello (ECH) fixes this. Cloudflare, Mozilla, and Google support it. Most of the web does not yet, as of 2026. SNI is plaintext for the majority of sites you visit.

DNS is plaintext

Before your browser can connect to a site, it has to resolve the name. Plaintext DNS goes to whatever resolver the network operator configured, usually the operator's DNS server. They see every domain you resolve. Some captive portals intercept and modify DNS responses to redirect you.

DNS-over-HTTPS (DoH) and DNS-over-TLS (DoT) fix this. Firefox does DoH by default in some regions. Chrome does it for known DoH-capable resolvers. Most users on most platforms still send plaintext DNS to the network operator.

Traffic shape

Even with everything else encrypted, packet sizes and timing patterns leak information. Loading a specific YouTube video has a recognisable fingerprint of segment requests. Streaming a Netflix episode has a different one. A sophisticated observer with traffic analysis tools can identify specific sites and even specific videos from the traffic shape, especially for high-traffic destinations.

This is rare for individual users on cafe WiFi. It is real for state-level adversaries on national-scale networks.

Destination IP

Even encrypted DNS does not hide the destination IP. Routers along the path see it because they have to forward packets. For sites on dedicated infrastructure, the IP-to-domain mapping is trivially derivable.

What is actually dangerous on public WiFi in 2026

The realistic threats today, ranked by likelihood:

1. Evil twin access points

A rogue access point broadcasts a network name identical to a legitimate one ("Hotel-Guest", "Airport-Free-WiFi", "Starbucks"). Your device connects, often automatically because it remembers the SSID from a previous visit. The attacker controls the network and can intercept your traffic.

Why it still works in 2026: WPA3 mitigates some attacks but does not prevent SSID impersonation. WiFi clients still trust SSIDs. Most public networks are open or PSK-based, neither of which prevents impersonation. Modern enterprise WiFi uses certificate-based authentication that does prevent it, but consumer WiFi does not.

What an evil twin can do: see all your unencrypted traffic (mostly DNS), serve you a captive portal that injects content, attempt to MITM TLS connections (which mostly fails because of certificate validation, but works against poorly-configured clients), and log all metadata about your activity.

What it cannot do: read your HTTPS content, read your VPN tunnel content, or replace TLS certificates you trust.

2. Captive portal MITM

Hotel and airport networks use captive portals: HTTP redirects to a landing page where you accept terms or pay for access. The captive portal mechanism inherently MITMs at least one HTTP connection, because that is how the redirect works.

Some captive portals go further. They inject scripts into HTTP pages. They serve modified content. They run analytics that log every domain you connect to. They have been documented selling browsing data and reselling DNS query data.

A VPN bypasses captive portal MITM cleanly: once the tunnel is up, the captive portal sees only encrypted bytes. The challenge is that captive portals usually require a working network to authenticate to, and you need to authenticate before the VPN can establish the tunnel. Standard pattern: connect to the network, authenticate to the captive portal, then immediately bring up the VPN.

3. Network-operator data collection

Hotel networks, airport networks, and public WiFi services routinely log connection metadata: every domain resolved, every IP connected to, time, duration, byte counts. Some sell this data to data brokers. Some hand it to government surveillance programs. Some just keep it indefinitely without policy.

This is not hypothetical. Documented examples include:

Major hotel chains have been caught running deep packet inspection that profiles guest traffic.
Airport networks have been caught logging DNS and TLS SNI for marketing and surveillance partners.
Coffee shop WiFi providers (the franchise contractors, not the individual stores) have similar data practices.

A VPN moves the trust boundary from the network operator to your VPN provider. Whether that is an improvement depends on how much you trust each. For most users, a paid VPN with a real privacy policy is more trustworthy than the random hotel network operator.

4. Captive portal certificate-pinning bypass attempts

Some captive portals try to MITM HTTPS by getting you to install a certificate. This is rare on public networks (it is an obvious red flag and most users decline) but happens occasionally on managed networks (hotel chains, conference venues, employer networks). If you install the certificate, the network operator can MITM all your TLS connections. Do not install certificates from networks you do not control.

5. Compromised consumer routers

Some public WiFi runs on consumer routers that have been compromised by malware. The malware redirects DNS to ad-injection servers, redirects specific banking domains to phishing pages, or installs persistent monitoring. This is most common in hotels and rental apartments where the equipment is older and rarely updated.

A VPN bypasses this entirely once the tunnel is up.

What is mostly hype

A few items that get cited but are less of a real risk in 2026:

Packet sniffing of plaintext passwords

The classic Firesheep / aircrack-ng demo was scary in 2010 because most sites sent login data in cleartext. In 2026, the destinations that matter (banks, email, social networks, streaming services) are HTTPS-only with HSTS. The attack does not work against modern sites.

Wireshark eavesdropping

Yes, Wireshark works. It captures traffic. What it captures is mostly TLS-encrypted, with the metadata leakage already discussed (SNI, DNS, IP). The "see my email get stolen on public WiFi with Wireshark" demo no longer works against modern services. The traffic-analysis version of this is real but requires more sophistication than a casual attacker brings.

"Hackers" in the casual sense

The image of someone in a hoodie at a cafe stealing your data with a laptop is mostly outdated. The casual attacker has lost most of their attack surface. The remaining threats are:

Network-operator-level surveillance (data collection, MITM by the operator themselves).
Sophisticated attackers (evil twin, traffic analysis), which exist but are rare.
State-level adversaries, which exist for some users but are not the public-WiFi cafe scenario.

WPA3 and what changed

WPA3 deployment status as of 2026:

Enterprise WPA3 is widely deployed in modern enterprise networks (corporate, university, government). It uses certificate-based authentication and is meaningfully more secure than WPA2.
WPA3-Personal for home and small business is less universally deployed. Newer routers support it. Older clients (anything pre-2019 typically) do not, so most networks fall back to WPA2 mixed mode.
Public hotspots are largely still open or WPA2-PSK in 2026. The transition has been slow because it requires both router and client upgrades, and the consumer market upgrades slowly.

What WPA3 fixes that affects public WiFi: it adds Simultaneous Authentication of Equals (SAE), which makes offline attacks against the network password much harder. For genuinely open networks (no password), WPA3 has Opportunistic Wireless Encryption (OWE), which encrypts the WiFi link even on networks with no shared key.

What WPA3 does not fix: SSID impersonation (evil twin attacks), captive portal MITM, network-operator data collection. WPA3 secures the radio link to the access point. It does not secure you against the operator of that access point.

The defensive layers that matter

In rough order of importance for public WiFi in 2026:

1. HTTPS-Everywhere by default

Modern browsers (Firefox, Chrome, Safari, Edge) default to HTTPS. Some have a mode that refuses HTTP entirely. Enable it. Firefox has "HTTPS-Only Mode". Chrome has "Always Use Secure Connections". Safari has it built in.

This handles 95% of the easy public WiFi attack surface for free.

2. DNS-over-HTTPS

Encrypts your DNS queries so the network operator cannot read or redirect them. Firefox does this by default in some regions. Chrome does it when your configured resolver supports DoH. Configure your OS DNS to a DoH-capable resolver (Cloudflare 1.1.1.1, Google 8.8.8.8, NextDNS, Quad9) for system-wide protection.

This handles the DNS leak vector and the DNS-redirect attacks.

3. A VPN

The remaining vectors (SNI plaintext, IP-level traffic logging, evil twin attacks, network-operator surveillance, traffic shape analysis) are best mitigated by a VPN tunnel. Once the tunnel is up, the network operator sees only encrypted bytes flowing to the VPN server.

A VPN is the single most effective defensive layer for public WiFi in 2026 because it covers everything HTTPS does not. We have a piece on VPN for hotel and airplane WiFi that goes into the specific use case.

The kill switch matters here. If the VPN drops, your traffic should not leak. We have a deeper piece on kill switches explained.

4. Common sense about networks

Do not connect to networks you do not recognise. Do not autotrust a network just because the SSID matches a place you have been before (evil twin attacks rely on this). Verify the network name with the venue if it matters. Do not install certificates from networks you do not control.

Specific scenarios

Hotel WiFi

Worst category. Hotel networks have a long, documented history of: surveillance, data sales, captive portal injection, deep packet inspection, and weak network isolation between guests. Use a VPN. We have a deeper piece on hotel WiFi specifically.

Airport and airplane WiFi

Airport: similar issues to hotel. Use a VPN. Airplane: same plus the constraint that satellite connections can be slow and the captive portal often blocks anything other than HTTP and HTTPS on standard ports. WireGuard on UDP often works. OpenVPN on TCP 443 is the fallback. VLESS Reality on TCP 443 also works and is the most reliable on aggressive captive portals.

Cafe WiFi

Lower risk than hotel because the network operator (the cafe's franchisee) is usually less professional about data collection. Still: SNI is visible, DNS may be intercepted, and evil twin attacks are possible in busy areas. A VPN is reasonable. HTTPS plus DoH is the minimum.

Conference WiFi

Often well-managed (real enterprise WiFi with WPA3-Enterprise) or terribly managed (whoever ran ethernet to a consumer access point). Hard to tell from outside. Default to a VPN.

Library and university WiFi

Often runs intrusion detection that may flag VPN connections. The VPN still works in most cases. If your library or university has a VPN-blocking policy and enforces it, that is its own problem to navigate.

Practical setup

For most users, a reasonable public WiFi defensive setup looks like:

HTTPS-only browser mode enabled.
DNS-over-HTTPS configured at the OS level (or in Firefox if you only browse).
A VPN with a kill switch, configured to auto-connect on untrusted networks.
WPA3 client support enabled (the OS handles this; modern devices already do it).
Network selection turned off for public SSIDs you do not actively use (so your device does not auto-connect to evil twins of "Starbucks" while you walk down a street).

This stack handles essentially all realistic public WiFi threats in 2026. None of it is exotic.

Practical takeaways

The easy public WiFi attacks of 2014 are mostly dead. HTTPS killed them.
The threats that remain are real but different: evil twin APs, captive portal MITM, network-operator surveillance, traffic analysis.
WPA3 helps but does not change the public WiFi threat picture much, because most public networks are still WPA2 or open.
HTTPS, DoH, and a VPN are the three layers that handle 2026's actual threats.
A kill switch matters because tunnels drop, and a leak window during a drop defeats the VPN.

If you are picking a VPN specifically for public WiFi use, our do I actually need a VPN piece treats this as the strongest standalone case. The 7-day free trial gives you time to see if it works on the networks you actually use.