Artifactory integration is leaking CR credentials!

[b1czu]

• I have tried with the latest version of Docker Desktop
• I have tried disabling enabled experimental features
• I have uploaded Diagnostics
• Diagnostics ID:

Actual behavior

When Access experimental features option is enabled in Docker Desktop (v4.17.1) settings then credentials to private container registry (which uses TLS) are leaked by periodically sending plain HTTP GET requests to example.container.registry:5050/artifactory/api/system/ping endpoint. These requests contains Authorization: Basic XYZ headers so user's credentials are sent as a plaintext through the network.

Screnshot of request:

Screenshot of pcap in wireshark:

I'm using self-hosted Gitlab with Container Registry enabled on port 5050 with active TLS (https). I haven't tested it (yet) on another platforms.

Expected behavior

User credentials should not be leaked!

Information

• Windows Version: Windows 10 22H2 19045.2728
• Docker Desktop Version: v4.17.1
• WSL2 or Hyper-V backend? WSL2
• Are you running inside a virtualized Windows e.g. on a cloud server or a VM: I've tested it on physical workstation and on ESXi virtualized Windows 10 also.

Steps to reproduce the behavior

1. Install Docker Desktop v4.17.1 on Windows 10 with WSL2 enabled.
2. Login to any private Container Registry using docker login <example.registry.com:5050>.
3. Make sure that Access experimental features option is enabled.
4. Pull any image from private repository using docker pull <example.registry.com:5050:test-image:latest>.
5. Start an network sniffer. Could be Wireshark installed locally or any network sniffing solution on the path between Docker Desktop and Container Registry.
6. Restart Docker Desktop several times. Click several times on Containers and Images option in application menu. When I was testing the request was mostly sent when Images section was opened after a while of not looking at it.

[nicks]

thank you for the report! we're investigating a fix.

[fblampe]

The release notes of version 4.18 say that this was fixed, so I suppose this issue can be closed?

Also, this issue should probably contain a hint that this is CVE-2023-1802, which links back here.