[Security] AgentOS component config resolution returns backend DB credentials (db_url w/ password) to components:read callers

[bogdancherniy11-sudo]

Summary

_resolve_db_in_config() expands a component's db id-reference into the fully-resolved
resolved_db.to_dict(), which for PostgresDb/SqliteDb includes db_url — and a Postgres URL
embeds the password. That expanded block is persisted and returned verbatim by
GET /components/{id}/configs/current | /configs/{version} | /configs, gated only by
components:read/components:write (NOT admin/config:read). A low-privilege Studio/components
principal thus recovers the backend DB master credentials.

Affected code (main @ 07fe6b23)

• os/routers/components/components.py _resolve_db_in_config: config["db"] = {**resolved_db.to_dict(), **table_overrides}.
• db/postgres/postgres.py:170-179 to_dict() → includes "db_url": self.db_url (password in URL).
• db/sqlite/sqlite.py:158-163 to_dict() → includes db_url/db_file.
• GET /components/*/configs* returns ComponentConfigResponse.config verbatim under components:read.

Root cause

The DB to_dict() used for the stored/returned config carries the secret db_url; the resolve step
bakes it into the component config; components:read is not an admin scope. Secrets round-trip to
non-admin callers.

Preconditions / attacker model

• A principal with components:read (Studio surface). Confirmed 403 on /config (genuinely low-priv).
  Unauthenticated in default no-OS_SECURITY_KEY deployment. Pre-existing Studio configs already carry
  resolved creds, so even read-only suffices.

Impact — HIGH

DB master password disclosure → full data-plane compromise (sessions, memories, the auth_tokens
table, all tenants) and lateral movement to the DB host.

Reproduction (mechanism)

POST /components referencing a db by id ({"db":{"id":"prod-postgres"}}), then
GET /components/{id}/configs/current with a components:read token → response config.db.db_url
contains postgresql+psycopg://<user>:<password>@host:5432/db. Local PoC:
/mnt/ntfs-p2/agno-hunt-2026-07-02/poc/agentG/poc-1.py (fake creds). Captured:

GET /components/my-studio-agent/configs/current -> 200
config.db.db_url = postgresql+psycopg://agno_admin:SuperSecretDbPassw0rd@prod-db.internal:5432/agno_prod
db_url leaked to components:read token = True

Expected vs actual

• Actual: resolved component config contains connection secrets (db_url w/ password), returned to
  components:read.
• Expected: component config responses never contain connection secrets; the db stays a non-secret
  id reference (or secrets are redacted).

Suggested fix

Do not embed the secret-bearing db_url in the stored/returned component config. Options:

1. Keep db as {"id": ..., <table overrides>} in persisted/returned config; resolve the live db
   (with its db_url) only in-memory at load time — never persist/return the expansion.
2. Add to_dict(redact_secrets=True) (drops db_url/password) and use it for the resolve/response path.
3. At minimum, strip db_url/credentials from ComponentConfigResponse.config before returning.

Duplicate / publicness (GitHub API, this session)

No issue/PR/GHSA reports component-config credential disclosure (db_url searches: 0). #8477 covers
NON-secret model connection params only (Model.to_dict), not db_url. Related to #8702 (same
function, injection vector); distinct impact.

Environment tested

• agno 2.6.20, main @ 07fe6b2, Python 3.12. Local-only reproduction; fake creds.

[kausmeows]

hi @bogdancherniy11-sudo we appreciate these but we noticed these look like AI sweeps from your codex/claude, and its difficult for maintainers to address all such 20-25 issues getting opened every second day, so can you pls make sure you've manually tested and verified that the issue exists before opening any more issues? we appreciate it

[bogdancherniy11-sudo]

Hi @kausmeows, thanks for the honest feedback, and sorry about the volume. You're right, that's on me.

To be upfront: yes, these come from an AI setup, but it's my own. I build the tooling and fine-tune it on my own datasets and tests. It's a security research project I'm developing, and I pointed it at agno because it's a project I genuinely respect. Even so, 20 to 25 issues at once is unreasonable to triage no matter how they're produced, and that wasn't fair to you. I did reproduce each one I opened locally (they include PoCs), but the volume was the real problem.

Going forward I'll stop the bulk issue opening, only open something after I've manually verified it with a minimal repro, and space them out. I'm also glad to close anything you see as out of scope or noise, just point me to it.

Honestly I'd rather help than add load. For any confirmed issue I can send a PR with the fix and a regression test, so there's no extra work on your side. And if it's ever useful, I'd be happy to help review or triage incoming security reports or PRs as a contributor, on your terms and with no pressure.

No rush on a reply. I just wanted to flag things responsibly, not pile up a backlog. Thanks for building agno, and sorry again for the noise.

[kausmeows]

thanks a lot for understanding and appreciate all the help and using Agno!