According to Google, attackers compromised infrastructure behind three country-code domain namespaces—.gh (Ghana), .sl (Sierra Leone), and .as (American Samoa)—and used it to obtain unauthorized HTTPS certificates for Google domains and other organizations. These domain endings aren’t limited to sites serving those countries, so the risk can extend to users elsewhere.

This wasn’t a break in encryption, and Google’s systems weren’t compromised. Instead, attackers manipulated the internet’s addressing infrastructure so they could pass the checks required to obtain certificates for domains they didn’t legitimately control.

The Domain Name System (DNS) helps direct internet traffic to the right destination. Control over DNS can also provide a way to demonstrate apparent control of a domain when requesting an HTTPS certificate.

An HTTPS certificate helps a browser authenticate the server it is connecting to. A trusted certificate authority issues the certificate after checking that the applicant controls the relevant domain.

By controlling DNS records, attackers can pass domain verification checks. The authority can then issue a genuine, signed certificate to someone who has hijacked the domain’s infrastructure.

Combined with the ability to redirect a victim’s traffic to an attacker-controlled server, that could enable cybercriminals to create a convincing impersonation of the real service.

Google initially blocked unauthorized certificates for its own properties in Chrome and worked with the issuing certificate authorities to revoke them. It later blocked suspicious certificates for other organizations in Chrome, too.

How to stay safe

Google points out that its actions do not offer complete protection:

“Due to the complexity of DNS hijacks, we cannot guarantee that our analysis identified every affected domain, nor do Chrome interventions reliably protect non-Chrome users.”

At the base level, this is an infrastructure problem that requires an infrastructure-level response. But these precautions can help:

• Keep your browser and operating system updated. Install available updates so you receive the latest security fixes.
• Don’t bypass certificate or secure-connection warnings. If your browser reports a certificate problem, stop rather than force the page to load.
• If a service you use has an address ending in .gh, .sl, or .as, check for security notices from the provider before logging in, making payments, or sharing sensitive information.
• Don’t treat HTTPS as an all-clear. An encrypted connection—even at the correct address—doesn’t guarantee you’re connected to the legitimate service if attackers have hijacked its DNS and obtained a valid certificate.
• Be cautious with unexpected or unusual requests, even if they appear to come from a service you trust. Before acting, verify the request through a separate, trusted channel, not through links or contact details provided in the request itself.

These precautions are not a complete defense. The lasting fix depends on domain operators restoring control, preventing further unauthorized certificates from being issued, and ensuring existing ones are revoked or blocked.

Stop threats before they can do any harm.

Malwarebytes Browser Guard blocks phishing pages and malicious sites automatically. Free, one click to install. Add it to your browser →

Criminals are hacking into public Wi-Fi devices—at hotels, conference centers, and so on—around the world and changing their DNS settings. The goal is to redirect users to fake login pages and steal their credentials.

Three WebKit mechanisms have been discovered to bypass Apple’s iCloud Private Relay. In fact, the mechanisms can bypass any browser‑level proxy configuration, including Psylo’s proxy, Tor-on-iOS proxy setups, and so on.

Private Relay is a VPN-like system for Safari on iOS which is meant to prevent websites from viewing the visitor’s IP address and location.

But because all three methods described by the researchers occur outside WebKit’s normal page loading path, Apple’s iCloud Private Relay never sees them and, as a result, means you can’t hide your IP address or Domain Name System (DNS) path in these cases.

The three features are:

• DNS prefetching
  Modern browsers try to be faster by looking up the IP addresses of links on a page before you click them, a feature known as DNS prefetching. In WebKit, these DNS lookups can bypass the configured proxy/relay and go straight through the system’s normal DNS stack, exposing which DNS servers you are using and, indirectly, where you really are. Even if the actual page load goes through Private Relay, the prefetch DNS queries can still leak metadata about your network.
• WebAuthn and passkeys
  WebAuthn (the standard behind passkeys) sometimes needs to fetch a small file from the website’s domain to verify that the credential is being used on the right site. The researchers found that, on Apple platforms, this fetch is performed outside the usual WebKit page‑loading path, which means it is not sent through the Safari proxy or Private Relay. The result is that a site using passkeys can cause your device to contact it directly, revealing your true IP address even if the rest of your browsing is supposedly hidden behind a relay.
• WebTransport and related technologies
  WebTransport is a newer API that gives websites a way to open low‑latency, bidirectional connections to a server. In the scenarios the researchers tested, these WebTransport connections were also initiated outside the proxied WebKit code path, creating another route for sites to receive traffic straight from the device. That traffic again carries the device’s real IP, not the relay or proxy IP the user expects.

From a user‑experience point of view, the problem is that all three mechanisms look like normal browser behavior and require no special tricks from a malicious site.

What’s affected

Affected are Safari on iOS and macOS when Private Relay is used, because Private Relay is implemented as a WebKit‑level proxy that only applies to Safari traffic. Additionally, any iOS/macOS browser or app that relies on WebKit’s proxy configuration to hide the IP (e.g., Psylo, Onion Browser/Tor on iOS, and other proxy browsers), since they all hit the same WebKit behavior.

And that’s not necessarily all. For most of iOS’s history, any app that browsed the web had to use Apple’s WebKit framework and JavaScript engine. This meant that Chrome, Firefox, Edge, Brave, and other browsers on iPhone were effectively different shells around the same WebKit engine Safari uses. Under pressure from the EU’s Digital Markets Act (DMA), Japan’s Smartphone Act, and similar regulatory pushes, Apple introduced a mechanism for non‑WebKit engines, but only in constrained ways.

Malwarebytes’ Senior manager for iOS software Roman Dvoinev commented:

“Basically the API has been “open” for a while, but no browser vendor has actually shipped a non-WebKit browser yet. Major players are still in prototype phase, as Apple’s bar for shipping a browser to iOS is very high.”

Malwarebytes VPN is not affected, since it tunnels the device’s entire network traffic at the system level.

The researchers have reported the problems to Apple and are expecting patches by fall.

Browse like no one’s watching. 

Malwarebytes Privacy VPN encrypts your connection and never logs what you do, so the next story you read doesn’t have to feel personal. Try it free →