WitteShadovv
notes / online GitHub

notes/brave-tor-sidebar-favicon-leak.md 4 min read

Brave's Tor window fetched sidebar favicons outside Tor

Adding a page to the sidebar from a Brave Private Window with Tor sent a request to that site from the real IP address. How it worked, what caused it, and the fix in Brave 1.96.60.

Short version

In a Brave Private Window with Tor, adding a page to the sidebar could fetch that site’s favicon outside Tor. The request went straight from the real IP address to the site. The site could then link that address to the Tor visit. I reported it to Brave on HackerOne on September 24, 2026. Brave reproduced it the same day, merged a fix the next day, and shipped it in Brave 1.96.60 on September 30.

If you use Tor windows in Brave, make sure you are on 1.96.60 or later.

What happened

A Tor window in Brave sends the page’s traffic through a local Tor SOCKS proxy. Everything the page loads, including its own favicon, goes that way. The sidebar is not part of the page. It is a browser feature, and it makes its own requests.

When you add a page to the sidebar, Brave wants an icon for it. It first looks for a stored favicon. If there is none, it fetches https://<site>/favicon.ico by itself. That fetch did not go through Tor.

The steps were short:

  1. Open a Private Window with Tor and wait until it connects.
  2. Open any page, for example https://duckduckgo.com/.
  3. Add the page with the + button in the sidebar.
  4. Watch the network activity, for example with brave://net-export.

In the log, the page’s own requests went through SOCKS5 127.0.0.1 on the Tor port, as expected. About a second after the page was added to the sidebar, a second GET https://duckduckgo.com/favicon.ico resolved to DIRECT. Brave looked up the hostname with the system resolver and opened a TCP and TLS connection from the machine’s own address to the site on port 443. The request completed with 200.

The site did not need a favicon for this to happen. With https://example.com/ the same request went out DIRECT and the site answered 404. The leak is the connection, not the icon.

Who it affected

It took one ordinary action and no settings change. It only happened when Brave had no stored favicon for the site. For a site you only visit over Tor, that is the normal case. So the people most likely to hit it were the people the Tor window is for.

What leaked: a direct connection from the real IP address to the site, about a second after the same site was opened over Tor. That timing makes it easy for the site to tie the two together. The system DNS resolver also saw the hostname.

The cause

Two pieces of code, each reasonable on its own.

In brave-core, SidebarModel::FetchFaviconFromNetwork() in browser/ui/sidebar/sidebar_model.cc gets an image fetcher with ImageFetcherServiceFactory::GetForKey(profile_->GetProfileKey()). Passing the profile key reads as if the fetch belongs to that profile.

In upstream Chromium, chrome/browser/image_fetcher/image_fetcher_service_factory.cc builds that service on SystemNetworkContextManager::GetSharedURLLoaderFactory(). That is the system network context, not the profile’s. The Tor proxy is set on the Tor profile’s network context, so the system loader never uses it.

The general point for Chromium-based browsers: whether a request goes through Tor depends on the network context it uses, not on the profile it was keyed by. A service that takes a profile can still talk to the network as the system. Any feature that fetches something on its own from a Tor window is worth checking for this.

The fix

My report suggested a small change. FetchFaviconFromNetwork() returns early for off-the-record profiles, so no network fetch happens in Tor or Private windows. I also attached a browser test for the Tor case with a regular window as a control.

Brave’s fix, brave/brave-core#40214, takes the same approach. It skips the network favicon fetch for off-the-record profiles and adds a Tor browser test. It was merged on September 25 and uplifted to the 1.96.x and 1.97.x branches.

The trade-off is visible but small. Sidebar items added from a Tor or Private window show the default icon instead of the site’s favicon. I think that is the right call for a window whose whole job is to not make direct connections.

Timeline

  • 2026-09-24 · report submitted on HackerOne, with a patch and a browser test
  • 2026-09-24 · Brave reproduces it
  • 2026-09-25 · fix merged into brave-core, report closed as resolved
  • 2026-09-30 · fix released in Brave 1.96.60

A big thank you to the Brave security team. This was one of the fastest turnarounds I have seen. They confirmed the bug the same day I reported it. When their first attempt to reproduce it failed, they did not leave it waiting on me. They kept at it and had it shortly after. The fix was merged the next day and shipped to everyone six days after the report, with credit in the release notes. That is how a report should go.