[GH-ISSUE #2909] DNS lookup occurs before blacklist regex check #18182

New Issue

GiteaMirror · 2026-04-25T20:23:53-05:00

GiteaMirror commented

2026-04-25 20:23:53 -05:00

Originally created by @viglianesed on GitHub (Nov 10, 2022).
Original GitHub issue: https://github.com/dani-garcia/vaultwarden/issues/2909

Originally assigned to: @BlackDex on GitHub.

Subject of the issue

Vaultwarden server does a DNS lookup before checking the icon blacklist regex. https://github.com/dani-garcia/vaultwarden/blob/main/src/api/icons.rs#L264

This could cause deanonymization of the server owner/users.

Deployment environment

vaultwarden version: 1.26.0

Install method: Docker
Clients used: n/a
Reverse proxy and version: n/a
MySQL/MariaDB or PostgreSQL version: n/a
Other relevant details: n/a

Steps to reproduce

A network DNS filtering solution like Pi-hole is recomended or any solution that logs DNS traffic.

Configure config.json with "icon_blacklist_regex": "'^(.*\\.onion/.*)$'", or in the admin page, set Icon blacklist Regex to '^(.*\.onion/.*)$'
Create a new password with some .onion url like -> http://1234567890.testing.dns.blacklist.onion/

Expected behaviour

For privacy reasons, the lookup_host((domain, 0)).await should happen after the regex check.

Actual behaviour

The regex part works and it doesn't contact the actual server:

[2022-11-10 21:26:19.449][vaultwarden::api::icons][WARN] Unable to download icon: Domain is blacklisted. 1234567890.testing.dns.blacklist.onion

The issue is that some user's may not filter .onion DNS requests, so the DNS requests will be sent to the upstream DNS server where they will be most likely logged and identify the user as a Tor user.

Troubleshooting data

Screenshot of a blocked DNS query:

Screenshot of the DNS regex blacklist rule:

Originally created by @viglianesed on GitHub (Nov 10, 2022). Original GitHub issue: https://github.com/dani-garcia/vaultwarden/issues/2909 Originally assigned to: @BlackDex on GitHub.   ### Subject of the issue  Vaultwarden server does a DNS lookup before checking the icon blacklist regex. https://github.com/dani-garcia/vaultwarden/blob/main/src/api/icons.rs#L264 This could cause deanonymization of the server owner/users. ### Deployment environment     * vaultwarden version: 1.26.0  * Install method: Docker * Clients used:  n/a * Reverse proxy and version:  n/a * MySQL/MariaDB or PostgreSQL version:  n/a * Other relevant details: n/a ### Steps to reproduce  A network DNS filtering solution like Pi-hole is recomended or any solution that logs DNS traffic. 1. Configure config.json with `"icon_blacklist_regex": "'^(.*\\.onion/.*)$'",` or in the admin page, set `Icon blacklist Regex` to `'^(.*\.onion/.*)$'` 2. Create a new password with some `.onion` url like -> `http://1234567890.testing.dns.blacklist.onion/` ### Expected behaviour  For privacy reasons, the `lookup_host((domain, 0)).await` should happen after the regex check. ### Actual behaviour  The regex part works and it doesn't contact the actual server: ``` [2022-11-10 21:26:19.449][vaultwarden::api::icons][WARN] Unable to download icon: Domain is blacklisted. 1234567890.testing.dns.blacklist.onion ``` The issue is that some user's may not filter `.onion` DNS requests, so the DNS requests will be sent to the upstream DNS server where they will be most likely logged and identify the user as a Tor user. ### Troubleshooting data  Screenshot of a blocked DNS query: ![2022-11-10_22h39_10](https://user-images.githubusercontent.com/62939309/201221085-6c1cdd53-f6a0-412c-8aca-ec79a3a5b233.png) Screenshot of the DNS regex blacklist rule: ![2022-11-10_22h35_13](https://user-images.githubusercontent.com/62939309/201220477-ba80f5f0-f28a-4975-a9a9-7683b96c7f01.png)

GiteaMirror added the enhancement label 2026-04-25 20:23:53 -05:00

GiteaMirror closed this issue

2026-04-25 20:23:54 -05:00

GiteaMirror commented

2026-04-25 20:23:55 -05:00

@BlackDex commented on GitHub (Nov 10, 2022):

Thanks for your report.
I understand the issue, and i also think it is easy to resolve.

@BlackDex commented on GitHub (Nov 10, 2022): Thanks for your report. I understand the issue, and i also think it is easy to resolve.

Sign in to join this conversation.

1 Participants

Notifications

Due Date

No due date set.

Dependencies

No dependencies set.

Reference: github-starred/vaultwarden#18182