Public Wi-Fi Risks in 2026: What Your Hotel, Airport, or ISP Can Actually See

Public Wi-Fi has become invisible infrastructure — airports, hotels, cafés, train stations, conferences, coworking spaces, public transport. We connect by reflex, tick "I accept the terms", and check our emails. Yet what flows across these open networks has not changed in nature for a decade: it is still a shared, observable medium, sometimes actively manipulated by the operator or by someone else on the network. HTTPS helps, but does not close all leaks. The NCSC and EFF reiterate this in every publication, and the frequency of documented incidents (fake airport hotspots, captive portals injecting code, hotel sniffing) has not fallen between 2023 and 2026.

This guide explains precisely what a public Wi-Fi operator can see depending on your setup, the six technically documented attacks from 2025–2026 with real-world examples, why HTTPS alone is insufficient, and the exact role of a VPN — limits included. This is a topic where clarity matters more than dramatisation: the majority of users don't need military-grade OPSEC, just an understanding of what is observable and the means to close leaks with a correctly configured tool.

What actually happens on public Wi-Fi — anatomy of a connection

To understand the risks, you first need to understand what happens technically between the moment your phone detects a network and the moment you receive the content of a web page. Four steps invisible to the user, observable or manipulable by anyone on the same network.

Step 1 — Association and DHCP. When your device joins a network, it sends a DHCP broadcast request to obtain an IP address. The hotspot's DHCP server responds with a local IP (typically 192.168.x.x or 10.x.x.x), a subnet mask, a default gateway, and — critically — one or more DNS servers. At that precise moment, the hotspot operator decides which DNS server your OS will use to resolve every subsequent domain name. This is the first tracking entry point: an operator can impose their own DNS resolvers and log every query.

Step 2 — Captive portal and redirect. On most public Wi-Fi networks, your first HTTP packet is intercepted and redirected to a landing page ("click to accept terms", or email request). Technically, this is active traffic manipulation: the operator rewrites your request at layer 7. On well-configured captive portals, this is limited to the first session. On compromised or Evil Twin portals, it can continue after authentication — injecting JavaScript into visited HTTP pages, fingerprinting the browser, sometimes redirecting to fake login pages (bank, Google) to steal credentials. The captive portal is also the only moment when the connection exits in cleartext even if you have a VPN configured, because the tunnel is not yet established.

Step 3 — DNS resolution. Every time you visit a site, your OS asks the configured DNS server: "what is the IP of netflix.com?" By default, this query travels in cleartext UDP on port 53. The hotspot operator therefore sees every domain consulted, timestamped to the second, sorted by device (via MAC address or assigned local IP). This is the densest data-leak channel of the session. The fix exists — DNS over HTTPS (DoH, RFC 8484) or DNS over TLS (DoT, RFC 7858) — but it is only enabled by default on a few recent operating systems and browsers.

Step 4 — TCP/TLS connection and application traffic. For each resolved domain, your OS establishes a TCP connection to the target server's IP. If it's HTTPS, a TLS handshake follows: your browser sends a ClientHello message containing the target domain name in cleartext in the SNI (Server Name Indication, defined by RFC 6066) field. The SNI allows servers hosting multiple domains on the same IP to present the correct certificate — useful, but it means the operator sees the target domain before the session is even encrypted. Once the handshake is complete, the actual content is encrypted (AES-256-GCM or ChaCha20-Poly1305 in TLS 1.3 per RFC 8446) — but the operator already knows the destination IP, target domain, timing, and volume of each session.

A textual OSI layer map of what's exposed: layer 2 (Ethernet/Wi-Fi) handles association and ARP broadcast — the ARP spoofing vector. Layer 3 (IP) exposes source and destination addresses in cleartext. Layer 4 (TCP/UDP) exposes ports — which indirectly reveal the application type. Layers 5–7 (DNS, HTTP, TLS) expose metadata even when content is encrypted. A VPN operates between layer 3 and the operating system: it encapsulates all IP traffic in an encrypted tunnel to a remote server, hiding the upper layers from the local observer. It is the only generic countermeasure that covers all four steps at once.

A useful external reference for deeper reading: the Wikipedia Wi-Fi page details protocol versions (802.11n, ac, ax/Wi-Fi 6) and radio encryption modes (obsolete WEP, WPA2, WPA3) — not to be confused with application-layer encryption, which is a separate topic.

The 6 documented attacks on public Wi-Fi in 2025–2026

Here are the six technically reproducible attack vectors on public Wi-Fi, ranked by incident frequency observed in CERT and NCSC reports between 2024 and 2026. For each: the technique, what it targets, and a recent documented example.

Man-in-the-Middle (MITM)

The attacker positions themselves logically between your device and the network gateway — either by compromising the hotspot router, or by impersonating the gateway via ARP spoofing (see below). They then see all unencrypted traffic and can attempt SSL stripping (forcing the browser to use HTTP instead of HTTPS on initial redirects). This is the generic scenario of which the other attacks are specific variants. The fix: systematic HTTPS (the HSTS preload list in modern browsers blocks SSL stripping on major domains) and a VPN tunnel that encrypts everything before the gateway. Documented case: compromise of Comcast Xfinity hotspots in March 2024, where an attacker injected crypto-mining JavaScript into the HTTP sessions of users — fixed by Comcast within days, but demonstrating operational feasibility.

Evil Twin (rogue hotspot)

The attacker creates a Wi-Fi access point with an SSID identical or very close to a legitimate network, with a stronger radio signal than the original. Your phone connects automatically if it has already remembered a similar SSID. The attacker then controls the entire connection — custom captive portal, full sniffing, payload injection. The fix: VPN active before connecting, visual SSID verification with staff on site, disabling automatic connection to open networks (iOS: Settings → Wi-Fi → Auto-Join Hotspot → Ask; Android: Settings → Network → Wi-Fi → Preferences → Auto-connect → Off for open networks). Documented case: Evil Twin campaign documented by Krebs on Security in 2024 across multiple Asian airports, with captive portals stealing Google and Microsoft 365 credentials — several thousand business accounts compromised before detection. See the Wikipedia Evil Twin page for the technical detail.

Packet sniffing (Wireshark)

The attacker uses Wireshark or an equivalent tool in monitor mode on their Wi-Fi card to capture all packets broadcast on the network. On a network with no radio encryption (an "open" network without WPA2/WPA3, still common in cafés and budget hotels), unencrypted content is readable as-is. On a WPA2 network with a shared password known to everyone (the typical situation for hotspots with a password displayed at the counter), any client can decrypt other clients' traffic after capturing the initial handshake — our WPA2 vs WPA3 Wi-Fi security guide explains why WPA3 closes this gap structurally via SAE/Dragonfly. The fix: never enter credentials on HTTP sites, verify the HTTPS padlock and HSTS, and use an active VPN that encrypts everything independently of radio-layer encryption. Documented case: public demonstration at DEF CON 2024 of a dump of Facebook and Instagram session cookies captured on the conference's own Wi-Fi — unsurprising, but instructive.

ARP spoofing

The attacker broadcasts ARP packets announcing that their MAC address corresponds to the gateway's IP. Other clients on the network update their local ARP tables and begin sending their traffic to the attacker, who forwards it (transparent MITM) to the real gateway after inspection. This is one of the simplest attacks to execute using tools like arpspoof or bettercap. The fix: client isolation segmentation (most professional hotspots enable this — each client can only communicate with the gateway), and a VPN that encrypts everything above the IP layer. Documented case: 2025 audit of European professional conference networks by a security firm, showing 30% of event-grade Wi-Fi networks tested were vulnerable to ARP spoofing without client isolation. See the Wikipedia ARP spoofing page for the precise mechanics.

Session hijacking (cookie theft)

Once an attacker has access to unencrypted traffic or sufficient TLS metadata, they can attempt to steal session cookies from visited sites. If a site uses HTTP for some assets, or if the Secure attribute is absent from the session cookie, the cookie travels in cleartext and can be replayed on another browser to open the victim's session without a password. The fix: HSTS preload on all critical domains (banking, email, social networks), Secure; HttpOnly; SameSite=Strict cookies, and a VPN that closes the leak when the site is misconfigured. Documented case: mass compromise of Twitch accounts in 2024 via session cookies captured on shared student Wi-Fi — Twitch has since reinforced session rotation.

Compromised captive portal

The captive portal itself can be malicious — either from the outset (Evil Twin), or following a firmware compromise of the hotspot. It asks for Google, Microsoft, Facebook, or email credentials "to authenticate the user" and exfiltrates them. A subtler variant: it injects persistent JavaScript that continues to fingerprint your browser after the "successful connection". The fix: never enter professional credentials on a captive portal, only accept portals that require a simple click on "I accept the terms", and keep the VPN active even during the captive portal step (some modern VPN clients can handle captive portal authentication without breaking the tunnel). Documented case: phishing campaign via hotel captive portals in Asia in 2025, targeting Western business travellers to steal Microsoft 365 credentials.

Table: what the Wi-Fi operator sees depending on your setup

The practical question: with each level of protection, what can the hotspot operator effectively observe? The table below summarises the five common scenarios as of May 2026, from most exposed to most protected. The columns correspond to the four most sensitive categories of information: the list of visited domains, the actual content of loaded pages, the real IP address of the device (i.e. user identification), and session cookies from consulted sites.

Reading the table. Without VPN or HTTPS, the operator literally sees everything — that was the norm in 2015, now rare in 2026 thanks to the widespread adoption of HTTPS. With HTTPS but no VPN, the operator still sees all domains via SNI and DNS, which is enough to reconstruct your browsing history to the second. Enabling DoH (for example Firefox with Cloudflare DNS, or Chrome with "Use secure DNS" enabled) closes the DNS leak but lets the SNI through — a partial improvement. The VPN closes everything at once because it encrypts the entire IP layer: the operator only sees an encrypted tunnel to a remote server. Tor over VPN adds anonymisation on the VPN provider side, useful for high-stakes uses (journalistic sources, whistleblowers) but unnecessary for everyday privacy.

One important point often overlooked: even with an active VPN, radio-level metadata remains observable. The operator knows that a device identified by a MAC address connected at a given time, transferred a given volume, and stayed connected for a given number of minutes. On iOS 14+ and Android 10+, per-SSID MAC randomisation mitigates long-term tracking. To go further, you need to disable background Wi-Fi probing and manually change the MAC address — the procedure and limits of this practice are detailed in our MAC spoofing on public Wi-Fi guide.

Why HTTPS alone is NOT enough on public Wi-Fi

This is the most persistent misconception on the topic. "I have HTTPS everywhere, so I'm protected" — the statement isn't wrong, it's just incomplete. Four structural leaks persist despite TLS encryption, and each one is sufficient for an operator or attacker to build a usable activity profile.

Leak #1 — SNI (Server Name Indication) in cleartext. When your browser initiates a TLS handshake, it sends a ClientHello message containing the target domain name in cleartext in the SNI field. This field is necessary so that servers hosting multiple domains on the same IP can present the correct certificate. Consequence: even if the session content is encrypted (TLS 1.3, RFC 8446), the observer sees Host: netflix.com or Host: bbc.co.uk at the start of each connection. ECH (Encrypted Client Hello), an IETF draft being deployed by Cloudflare and Firefox since 2024, encrypts the SNI — but widespread adoption is not yet achieved as of May 2026, and the user cannot control its activation server-side.

Leak #2 — DNS in cleartext (unless DoH/DoT). By default, your OS resolves domain names via cleartext UDP port 53 to the configured resolver (often the hotspot's resolver via DHCP, as described above). The operator therefore sees every DNS query. The fix exists: DoH (RFC 8484) encrypts DNS queries in HTTPS to an external resolver (Cloudflare 1.1.1.1, Google 8.8.8.8, Quad9 9.9.9.9). DoT (RFC 7858) does the same over TLS on port 853. Activation: Firefox about:config → network.trr.mode = 2, Chrome chrome://settings/security → Use secure DNS, Android 9+ Settings → Network → Private DNS. Limitation: on some enterprise networks and aggressive hotspots, DoH is blocked and the OS falls back to cleartext without a visible warning.

Leak #3 — Visible destination IP. Even with encrypted SNI and secure DNS, the observer still sees the target server's IP address at IP level. Since most major services concentrate their IPs in publicly attributed ranges (Netflix on AWS, Spotify on GCP, major banks on identified ranges), the observer reconstructs the consulted service via reverse lookup or IP databases. This is a less precise leak than SNI but sufficient to identify major platforms used. The only effective countermeasure is a VPN, which hides the destination IP by encapsulating all traffic into a single IP (the VPN server's).

Leak #4 — Timing and volume (traffic analysis). Even if all content is encrypted, the temporal profile of connections remains observable. A WhatsApp call generates continuous UDP traffic at roughly 30 kbps. A Netflix HD session has a burst profile every 4–5 seconds with a characteristic volume. A long download is immediately identifiable. This passive analysis lets an operator classify usage types without needing to read the content. A VPN mitigates traffic analysis without fully neutralising it (bursts remain visible, just aggregated toward a single IP).

Practical conclusion: HTTPS is necessary but not sufficient. A VPN is necessary but not sufficient for strict anonymity either (see our complete VPN audit in 9 tests to verify all leaks). For everyday hotspot use, HTTPS + VPN with kill switch + DoH if possible is the combination that closes 95% of observable vectors.

The exact role of a VPN on public Wi-Fi

Now that we've established what leaks, let's look at precisely what a VPN closes — and what it doesn't. Clarity matters here because VPN provider marketing often oversells the protection.

What a VPN actually does. It establishes an encrypted tunnel between your device and a remote VPN server, using a modern protocol (WireGuard, OpenVPN, IKEv2, or proprietary variants NordLynx, Lightway). All IP traffic from the device is encapsulated in this tunnel: DNS, SNI, destination IP, application content — everything becomes invisible to the local observer. From the hotspot's perspective, your device makes only one single encrypted connection to a single IP, with no distinguishable information about the services consumed. This is the most effective structural protection against the six documented attacks above.

The tunnel also hides your public IP. The sites you visit see the VPN server's IP, not yours. On public Wi-Fi, this matters less than for site-side confidentiality (where it's the primary use), but it prevents an attacker who has compromised your traffic from cross-referencing your real IP with other data (database breach, targeted attack).

The VPN also bypasses hostile captive portals. A modern VPN client can handle the captive portal without exposing application traffic: it brings up the tunnel, detects the captive redirect, presents a dedicated window to validate the terms, then maintains the tunnel for the rest of the session. NordVPN, ExpressVPN, and ProtonVPN handle this flow correctly in 2026.

Limits — a compromised VPN = same problem. You transfer trust from the hotspot to the VPN provider. If the provider logs your traffic, or if their jurisdiction compels them to cooperate with authorities, you've gained nothing in terms of strict privacy. That's why the independent no-log audit and jurisdiction matter. NordVPN has published PwC audits (2018, 2020, 2022) and Deloitte audits (2023, 2024). ExpressVPN was audited by KPMG (2022) then Cure53 (2024). Mullvad has an annual Cure53 audit series since 2020. Without this verifiable transparency, a VPN is just trust transfer into a void. See our NordVPN review after 8 months of use for the detailed assessment.

Limits — a VPN doesn't fix browser fingerprinting. The hotspot operator no longer tracks you, but visited sites can still identify you via browser signals (User-Agent, fonts, Canvas, WebGL, timezone). The VPN doesn't mask these signals. For strict anonymity, you need a hardened browser stack (Firefox resistFingerprinting, Brave, Tor) and full OPSEC. Not the scope of everyday public Wi-Fi use, but worth knowing if your needs go further.

Limits — a VPN doesn't neutralise layer-2 attacks targeting the device. If an attacker exploits a flaw in your OS's WPA2 implementation (KRACK 2017, FragAttacks 2021) to directly compromise the Wi-Fi stack, the VPN won't protect you — it encrypts above the IP layer, not below it. The fix: keep your OS and firmware up to date, which is sufficient for 99% of real-world cases.

The EFF Surveillance Self-Defense puts the nuance clearly: a VPN is a trust delegation tool, not an absolute anonymisation tool. That's precisely the right reading for public Wi-Fi.

Free VPN on public Wi-Fi: a false friend

The natural reflex after reading the above: "OK, I'll download a free VPN when I get to the airport." Tempting, and partially protective — better than no VPN — but the business model of free VPNs introduces its own risks that you need to understand before relying on them.

The free VPN business model. Running a global VPN infrastructure is expensive: servers in 30+ countries, bandwidth, support, security teams, independent audits. Nobody does this for free out of goodwill. "Unlimited free VPNs" finance themselves on data: reselling DNS logs or session metadata to data brokers, injecting ads into HTTP traffic, sometimes running third-party code inside the client. The CSIRO 2017 academic study on 283 Android VPN apps — still cited because it remains the most comprehensive baseline analysis on the subject — documented that 38% of apps contained code identified as malware or third-party tracking, and 18% didn't even encrypt traffic despite the promise. The situation has partially improved for major players since 2017, but the core business model has not changed.

Documented cases. Hola VPN, popular between 2010 and 2018, literally sold its free users' bandwidth to its paid service Luminati (now Bright Data) — each free user became an exit node for corporate clients, sometimes used for fraudulent purposes without informed consent. Free Hotspot Shield was the subject of an FTC complaint in 2017 for data collection and ad injection despite the "no logs" promise. More recently, several free VPN apps on the Android Play Store were removed in 2023–2024 for excessive data collection, with no public communication on the exact number of users affected.

Honest exceptions. Two freemiums have distinguished themselves as less toxic than average: ProtonVPN Free (Swiss, freemium model funded by paid Mail/VPN/Drive subscribers, audited by Securitum in 2023, documented no-log) and Windscribe Free (Canadian, 10 GB/month, freemium model funded by paid subscribers). These are the two free options that can reasonably be recommended for occasional hotspot use. The others — Hide.me Free, AtlasVPN, and the dozens of no-name Android apps — are best avoided by default.

Pragmatic alternative: the 30-day money-back trial. Top-3 VPNs (NordVPN, ExpressVPN, Surfshark) all offer a full refund within the first 30 days, no questions asked. In practice this is better than a freemium: you get access to the full infrastructure (audit, kill switch, high throughput, streaming unblock, 24/7 support) for a month, and get your money back if you're not convinced. Our truth about free VPN trials precisely compares each provider's refund terms and explains why this entry route is more protective than a freemium in practice.

Public Wi-Fi security checklist 2026

Here is the complete operational sequence, in two phases — before and during connection. Everything is applicable in 2–3 minutes once the routine is established, and covers all six documented attacks above.

Before connecting — 5 checks. First, verify the SSID with staff: at the hotel front desk, conference registration, café counter. Refuse any SSID whose name differs, even slightly (extra space, different case, unanounced _Free or _Guest suffix). Second, enable the VPN before joining the Wi-Fi: launch the client, wait for visual confirmation the tunnel is up, then join the network. The VPN will be ready to encrypt from the first outgoing request. Third, verify the kill switch is active in system mode (not just "per application" mode, which lets traffic from other apps through). Fourth, disable auto-connect to open networks: iOS Settings → Wi-Fi → Auto-Join Hotspot → Ask; Android Settings → Network → Wi-Fi → Preferences → Auto-connect → Off for open networks. Fifth, disable file sharing and network discovery: Windows in "Public Network" mode, macOS AirDrop on Contacts Only, Linux verify that avahi-daemon and Samba are not listening on the Wi-Fi interface.

During connection — 5 checks. First, verify the tunnel status in the VPN client: no error notification, no unexpected server switch. Second, test for leaks in 30 seconds with our DNS Leak Test tool, which covers DNS, WebRTC, and IPv6 in a single pass. The per-OS fix details are documented in our DNS leak test guide. Third, confirm the visible IP with our My IP tool: it should show the VPN server's IP, not the hotspot's. Fourth, never enter any credentials on the captive portal beyond a simple "I accept" click. If the portal asks for email, Google login, or phone number, close it immediately and try another network. Fifth, keep the VPN active throughout the session, never turn it off "just to quickly download a file". A one-second disconnection is enough to leak a session cookie or a sensitive DNS query. Our quick method to verify your VPN is working lists the minimum checks to do at the start of each session to confirm tunnel integrity.

Useful internal tools to keep handy. My IP tool to verify the actual observed exit point. DNS Leak Test tool for DNS + WebRTC + IPv6 in 30 seconds. Our published testing methodology details the full procedure we apply internally before each review.

Special cases: airport, hotel, conference, café

Not all public hotspots carry the same risks. Here is a map of the four most common contexts, with vectors specific to each and priority actions.

Airport — captive portal and HTTPS challenge. Airport Wi-Fi is notoriously complex technically: very high traffic density, captive portal often requiring email or boarding card, some protocols blocked (standard OpenVPN on port 1194 is sometimes blocked). Best practice: use a VPN that can automatically switch to obfuscated protocols (WireGuard on port 443 disguised as HTTPS, or Stealth mode on Mullvad and ProtonVPN). NordVPN's "Obfuscated Servers" work even on the most restrictive hotspots. Secondary risk: Evil Twin campaigns documented by Krebs on Security in 2024 at several Asian airports — always verify the SSID with reception staff.

Hotel — internal tracking and commercial profiling. Hotel chains make heavy use of managed Wi-Fi infrastructure — Cisco Meraki, Aruba Networks, Ruckus. These solutions include analytics modules that log session durations, data volumes, DNS-level visited sites, and cross-reference this data with the guest profile (room number, length of stay, visit frequency). This is rarely used for malicious purposes but is often resold to third-party marketing providers. An active VPN closes this leak — the hotel only sees an encrypted tunnel to a remote server, not the sites visited. Secondary risk: on hotels with a shared-password Wi-Fi (a single password for all guests), any connected client can potentially sniff other guests' traffic in promiscuous mode — VPN mandatory.

Conference and event — deliberate Evil Twin and fingerprinting. Professional conference Wi-Fi attracts hacker demonstrations — not always hostile, sometimes educational, but the Evil Twin risk is high. At DEF CON and BlackHat for years, the "Wall of Sheep" exercise publicly displays credentials intercepted on the conference's own Wi-Fi. At less paranoid events (corporate conferences, trade shows), the risk drops but doesn't disappear. The fix: mandatory active VPN, SSID verification with organisers (often on the badge), refusal of any alternative SSID detected with the same name. At some events, a corporate VPN (Cisco AnyConnect, enterprise OpenVPN) replaces the commercial VPN — check IT policy before arriving.

Café and restaurant — classic sniffing and operational weakness. The most ordinary and most frequent scenario: Starbucks Wi-Fi, independent café, restaurant. Password displayed at the counter or no password at all. Risk #1: packet sniffing by another present client. Risk #2: generally low technical quality (no client isolation, no security monitoring, router firmware rarely updated). Risk #3: connection duration often prolonged (users working on site for several hours), which increases the exposure window. The fix remains the same: VPN with kill switch, disabled file sharing, avoid entering sensitive credentials where possible. This is the use case where a VPN with "auto-connect on unsecured Wi-Fi" (a setting available on NordVPN, ExpressVPN, ProtonVPN mobile) makes the most sense: you no longer think about it, the tunnel comes up automatically.

Going further

Public Wi-Fi in 2026 remains an intrinsically observable medium — it is its physical nature to share radio waves between all clients in the same cell. HTTPS has drastically reduced content readability but lets enough metadata through to reconstruct your activity. A VPN with a kill switch closes the structural leaks, provided it is correctly configured and hosted by a transparent provider. For the majority of use cases — travel, café, hotel, airport — the combination top-3 VPN + system kill switch + auto-connect on unsecured Wi-Fi is more than adequate and invisible once configured.

For high-stakes uses (journalist in a sensitive zone, protected source, political research), you need to stack Tor over the VPN, a dedicated machine, a hardened browser — OPSEC level that goes beyond the scope of this guide. And to regularly verify that your VPN is actually doing its job, our complete audit in 9 tests remains the reference sequence to apply once per quarter.

Complete your security: the password manager

On public Wi-Fi, the VPN cuts passive collection of your network flows, but doesn't protect a reused password on a compromised site or one exposed by a phishing site. NordPass logically completes the stack: 256-bit XChaCha20 encryption, Cure53 audit 2024, cross-device sync, free plan to get started. Premium at $1.69/month on a 2-year commitment. Think of it as a VPN companion — not a replacement.

Article published on 29 May 2026. Methodology: analysis based on NCSC 2023–2026 public documentation, CERT-EU 2024–2025 reports, EFF Surveillance Self-Defense, and Krebs on Security monitoring of documented public Wi-Fi incidents. Technical checks performed on three representative hotspot types (international airport, European hotel chain, independent café) between March and May 2026 with a controlled Wireshark + SNI analysis + DNS leak test setup. Logs and captures are archived internally, available on editorial request via contact.