[GH-ISSUE #274] Security Concern: Silent Auto-Detection of OpenAI API Key During Desktop Installation #176

New issue

Open

opened 2026-10-18 14:06:44 +00:00 by bsakaguchi · 0 comments

bsakaguchi commented

2026-10-18 14:06:44 +00:00

Owner

Originally created by @lepptin on GitHub (Sep 21, 2026).
Original GitHub issue: https://github.com/open-webui/desktop/issues/274

Summary

During the installation and first run of Open WebUI Desktop v0.0.20 on
Windows 11, the application silently detected and imported an existingOpenAI API key from my system without any user notification, explicit consent,
or warning. The API key was automatically populated in
Settings → Connections → OpenAI API, with the main toggle enabled by
default.

This behavior raises serious privacy and security concerns, as credentials
appear to be read from system-level storage locations (e.g., Windows
Credential Manager, environment variables) without user awareness.

Environment Details

Component	Version / Info
Open WebUI Desktop	v0.0.20
Open WebUI Core	v0.11.3
Open WebUI Terminal	v0.13.0
Installation Method	`open-webui-x64-setup.exe`
Platform	win32 (x64)
Operating System	Windows 11 Pro, 25H2
OS Build	26200.9168

Steps to Reproduce

Install Open WebUI Desktop (open-webui-x64-setup.exe) on a Windows
machine that already has an OpenAI API key stored somewhere in the
system (e.g., Windows Credential Manager, environment variables, or any
other persistent storage location).
Launch Open WebUI Desktop for the first time.
Open a new chat and observe the model selection dropdown.
Notice that numerous OpenAI GPT models (including recent flagship models
such as GPT-4o, o1, o1-mini, astra etc.) are listed and selectable — despite
no manual API key configuration.
Navigate to Settings → Connections.
Observe that the OpenAI API section already contains:
- The endpoint URL: https://api.openai.com/v1
- A pre-filled API key matching the user's personal OpenAI API key
  (e.g., sk-proj-Ab...XYZ)
- The main toggle switch is enabled by default

Discovery Process

I assumed Open WebUI was providing a free testing/demo service for OpenAI
models through its own infrastructure, similar to what some other AI
frontends offer.
Upon seeing recent flagship models (e.g., GPT-4o, astra) available without
any manual configuration, I became suspicious.
I checked Settings → Connections → OpenAI API and found an API key
already populated in the configuration field.
I reviewed my Open WebUI account profile settings and confirmed that
Open WebUI does not issue or provide its own API keys.
I logged into the OpenAI API Platform at https://platform.openai.com
and located API keys I had created approximately one year ago.
I compared the key displayed in Open WebUI's settings with the one in
my OpenAI Platform account — they matched exactly.
I confirmed that I had never manually entered this key into Open
WebUI at any point.

Security & Privacy Implications

Lack of user consent: The API key was imported silently, without
notification, prompt, or explicit user action.
No transparency: There was no documentation, onboarding message, or
warning informing the user about this credential-detection behavior.
Default-enabled state: The toggle was switched on by default with a
valid, billable credential attached — any model selection could have
resulted in API calls and billing.
System credential scanning: The application appears to access persistent system-level storage (likely Windows Credential Manager, possibly
environment variables) to extract credentials without disclosure.
Privacy-by-design violation: This contradicts the principle of minimal
permission scope, where applications should request the least amount of
access necessary and inform users about credential usage.
Trust erosion: Users who discover this behavior post-hoc may lose
confidence in the application's handling of sensitive data.

Mitigation Steps Taken

I have taken the following actions to secure my environment:

Revoked the affected API key on the OpenAI Platform.
Cleared the API key from Open WebUI's connection settings.
Verified the billing dashboard — no unexpected charges detected, as I
did not actively use the application with the auto-configured key.
Set up a hard usage limit on the OpenAI account to prevent future
unauthorized billing.
Inspected Windows Credential Manager and identified likely storage
locations for the key (now cleaned up).

Suggested Improvements

I respectfully propose the following changes to improve security and user
trust:

Explicit user consent: Before importing or reading any credentials
from system storage, the application should request explicit permission
with a clear explanation of what will be accessed, from where, and why.
Transparent notification: If credentials are detected, the user
should be informed immediately with full details — including the source
location if known.
Opt-in by default: Even if detection occurs, the connection toggle
should remain off until the user manually enables it.
Empty state default: The API key field should be empty by default;
credentials should never be silently pre-filled.
Documentation: This behavior must be clearly documented in the
installation guide, release notes, FAQ, and privacy policy.
Audit trail: Provide users with a visible log of when credentials
were accessed and which actions were taken automatically.
No silent credential store access: The application should not read
from system credential managers (Windows Credential Manager, macOS
Keychain, Linux Secret Service) without explicit, granted permission.
Telemetry disclosure: If this detection mechanism is part of an
"ease-of-use" feature, it must be disclosed in the privacy policy and
be opt-in, not opt-out.

Additional Notes

I am not certain exactly how or when my OpenAI API key was stored on
my Windows system. It may have been via Windows Credential Manager,
environment variables, a third-party CLI tool, or another mechanism. I am
investigating further.
The detection behavior may be related to an Electron-based packaging
artifact, an environment variable scan, or an integration with a system
credential API — but this is speculation and should be investigated by
the development team.
I have not observed unauthorized billing, but I cannot rule out
background network calls or telemetry that may have included the key.
I am reporting this in good faith to improve the security, privacy,
and transparency of Open WebUI for the entire community.

Request to the Open WebUI Team

Please investigate the technical mechanism by which the API key was
detected and imported into the desktop application.
Please consider implementing the suggested improvements above.
Please disclose this behavior transparently in the privacy policy,
documentation, and release notes.
Please provide guidance to other users who may have been affected
without their knowledge.
Please consider adding a security advisory if this behavior is
confirmed as unintentional.

Thank you for your work on Open WebUI. I hope this report contributes to
making the platform safer and more trustworthy for all users.

Originally created by @lepptin on GitHub (Sep 21, 2026). Original GitHub issue: https://github.com/open-webui/desktop/issues/274 ### Summary During the installation and first run of **Open WebUI Desktop v0.0.20** on Windows 11, the application silently detected and imported an existingOpenAI API key from my system without any user notification, explicit consent, or warning. The API key was automatically populated in **Settings → Connections → OpenAI API**, with the main toggle enabled by default. This behavior raises serious privacy and security concerns, as credentials appear to be read from system-level storage locations (e.g., Windows Credential Manager, environment variables) without user awareness. --- ### Environment Details | Component | Version / Info | |-----------|----------------| | **Open WebUI Desktop** | v0.0.20 | | **Open WebUI Core** | v0.11.3 | | **Open WebUI Terminal** | v0.13.0 | | **Installation Method** | `open-webui-x64-setup.exe` | | **Platform** | win32 (x64) | | **Operating System** | Windows 11 Pro, 25H2 | | **OS Build** | 26200.9168 | --- ### Steps to Reproduce 1. Install Open WebUI Desktop (`open-webui-x64-setup.exe`) on a Windows machine that already has an OpenAI API key stored somewhere in the system (e.g., Windows Credential Manager, environment variables, or any other persistent storage location). 2. Launch Open WebUI Desktop for the first time. 3. Open a new chat and observe the model selection dropdown. 4. Notice that numerous OpenAI GPT models (including recent flagship models such as GPT-4o, o1, o1-mini, astra etc.) are listed and selectable — despite no manual API key configuration. 5. Navigate to **Settings → Connections**. 6. Observe that the **OpenAI API** section already contains: - The endpoint URL: `https://api.openai.com/v1` - A **pre-filled API key** matching the user's personal OpenAI API key (e.g., `sk-proj-Ab...XYZ`) - The main toggle switch is **enabled by default** --- ### Discovery Process 1. I assumed Open WebUI was providing a free testing/demo service for OpenAI models through its own infrastructure, similar to what some other AI frontends offer. 2. Upon seeing recent flagship models (e.g., GPT-4o, astra) available without any manual configuration, I became suspicious. 3. I checked **Settings → Connections → OpenAI API** and found an API key already populated in the configuration field. 4. I reviewed my **Open WebUI account profile** settings and confirmed that Open WebUI does **not** issue or provide its own API keys. 5. I logged into the **OpenAI API Platform** at `https://platform.openai.com` and located API keys I had created approximately one year ago. 6. I compared the key displayed in Open WebUI's settings with the one in my OpenAI Platform account — **they matched exactly**. 7. I confirmed that I had **never** manually entered this key into Open WebUI at any point. --- ### Security & Privacy Implications - **Lack of user consent:** The API key was imported silently, without notification, prompt, or explicit user action. - **No transparency:** There was no documentation, onboarding message, or warning informing the user about this credential-detection behavior. - **Default-enabled state:** The toggle was switched **on** by default with a valid, billable credential attached — any model selection could have resulted in API calls and billing. - **System credential scanning:** The application appears to access persistent system-level storage (likely Windows Credential Manager, possibly environment variables) to extract credentials without disclosure. - **Privacy-by-design violation:** This contradicts the principle of minimal permission scope, where applications should request the least amount of access necessary and inform users about credential usage. - **Trust erosion:** Users who discover this behavior post-hoc may lose confidence in the application's handling of sensitive data. --- ### Mitigation Steps Taken I have taken the following actions to secure my environment: 1. **Revoked** the affected API key on the OpenAI Platform. 2. **Cleared** the API key from Open WebUI's connection settings. 3. Verified the **billing dashboard** — no unexpected charges detected, as I did not actively use the application with the auto-configured key. 4. Set up a **hard usage limit** on the OpenAI account to prevent future unauthorized billing. 5. Inspected **Windows Credential Manager** and identified likely storage locations for the key (now cleaned up). --- ### Suggested Improvements I respectfully propose the following changes to improve security and user trust: 1. **Explicit user consent:** Before importing or reading any credentials from system storage, the application should request explicit permission with a clear explanation of what will be accessed, from where, and why. 2. **Transparent notification:** If credentials are detected, the user should be informed immediately with full details — including the source location if known. 3. **Opt-in by default:** Even if detection occurs, the connection toggle should remain **off** until the user manually enables it. 4. **Empty state default:** The API key field should be empty by default; credentials should never be silently pre-filled. 5. **Documentation:** This behavior must be clearly documented in the installation guide, release notes, FAQ, and privacy policy. 6. **Audit trail:** Provide users with a visible log of when credentials were accessed and which actions were taken automatically. 7. **No silent credential store access:** The application should not read from system credential managers (Windows Credential Manager, macOS Keychain, Linux Secret Service) without explicit, granted permission. 8. **Telemetry disclosure:** If this detection mechanism is part of an "ease-of-use" feature, it must be disclosed in the privacy policy and be opt-in, not opt-out. --- ### Additional Notes - I am **not** certain exactly how or when my OpenAI API key was stored on my Windows system. It may have been via Windows Credential Manager, environment variables, a third-party CLI tool, or another mechanism. I am investigating further. - The detection behavior may be related to an Electron-based packaging artifact, an environment variable scan, or an integration with a system credential API — but this is speculation and should be investigated by the development team. - I have **not** observed unauthorized billing, but I cannot rule out background network calls or telemetry that may have included the key. - I am reporting this in **good faith** to improve the security, privacy, and transparency of Open WebUI for the entire community. --- ### Request to the Open WebUI Team - Please **investigate** the technical mechanism by which the API key was detected and imported into the desktop application. - Please consider implementing the suggested improvements above. - Please **disclose** this behavior transparently in the privacy policy, documentation, and release notes. - Please provide **guidance** to other users who may have been affected without their knowledge. - Please consider adding a **security advisory** if this behavior is confirmed as unintentional. --- **Thank you for your work on Open WebUI. I hope this report contributes to making the platform safer and more trustworthy for all users.**

No labels

help wanted

pull-request

No milestone

No project

No assignees

1 participant

Notifications

Due date

The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set.

Reference

open-webui/desktop#176

No description provided.

Rows
Columns