Pensar - auto fix for Sensitive API Key Exposure via Settings Endpoint #862
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Security vulnerability fixed:
The original code defined
LLMConfigOutputDTO
andVectorDBConfigOutputDTO
by inheriting directly from their config models, which included sensitiveapi_key
fields. Theget_settings
endpoint returned these objects directly, causing inadvertent exposure of plaintext service credentials to any authenticated user.How it was fixed:
LLMConfigOutputDTO
andVectorDBConfigOutputDTO
were redefined to explicitly exclude theapi_key
field. Only non-sensitive fields (provider
,model
, andurl
) are included.get_settings()
handler, objects are now manually constructed for output, ensuring only the safe fields are included in the response./
responses, eliminating the credential leakage risk.More Details
SettingsDTO
response model inherits fromLLMConfig
andVectorDBConfig
, both of which include theapi_key
field. CallingGET /
returns these objects verbatim, leaking plaintext API keys (e.g., OpenAI, Vector-DB) to the client side. Anyone with any valid account can now view and misuse these credentials, leading to potential account takeover, quota exhaustion, or data tampering.