Big-AGI closes a path exposing server-side Gemini keys
Big-AGI says its AI Inspector request echo could reveal a configured server Gemini key. Version 2.1.2 closes that path; affected operators are advised to rotate the key.
Artificial Intelligence··Morning
A configured key appeared in a request echo
Big-AGI’s October 25 release notes say version 2.1.2 fixes an AI Inspector request echo that could reveal a server-configured GEMINI_API_KEY. The risk concerns deployments where an operator placed that key on the server; it is not a claim that every user’s key was exposed. The maintainer advises affected self-hosters to upgrade and rotate the key. A rotation matters because closing the display path cannot make a previously seen credential secret again. The release note describes a vulnerability and a remedy, but does not name a confirmed attacker or an observed number of compromised installations.[1]
The patch closes more than one key route
For Anthropic, Gemini and OpenAI-compatible connections, the release says a server-stored key now stays away from destinations chosen on the client side. That is a separate trust-boundary fix from the AI Inspector display problem: a client-selected destination should not receive credentials held by the server. The notes also describe stricter handling for optional HTTP Basic authentication, including passwords containing colons and UTF-8 text, with constant-time comparison. These changes matter most to people running a shared or self-hosted service, where users and administrators may have different access to stored credentials.[1]
The affected footprint remains undisclosed
The public note does not quantify how many servers used a configured Gemini key, whether an unauthorized person viewed one, or whether a client-selected host received credentials in practice. It therefore supports a specific exposure path and the maintainer’s recommended response, not a count of breaches. Big-AGI also documents a private channel for security reports. For an operator, the immediate decision is scoped: check whether the affected server-side configuration was used, apply the fixed release, and treat any key that might have appeared in an exposed request view as needing replacement. The evidence does not justify describing all Big-AGI installations as compromised.[1]
