Affected: flytohub flyto-core

Flyto2 Core is an execution kernel for automation and AI-agent workflows. Prior to 2.26.6, llm.chat reads provider keys such as OPENAI_API_KEY and ANTHROPIC_API_KEY from the environment and sends them in the Authorization: Bearer header to caller-controlled base_url, allowing an attacker to receive the operator's key on a public host that passes the SSRF guard. This issue is fixed in version 2.26.6.

Affected: PyPI: flyto-core

## Summary

`llm.chat` reads the operator's provider key from the environment (`OPENAI_API_KEY`, `ANTHROPIC_API_KEY`, ...) and sends it in the `Authorization: Bearer` header to `base_url`, a parameter the caller controls. `base_url` is only checked against the SSRF guard, and the guard allows any public host, so pointing `base_url` at an attacker's server hands them the operator's key. flyto-core's own bounty scale rates "environment access exposing secrets (e.g. `ANTHROPIC_API_KEY`)" as High.

## Affected code

`src/core/modules/atomic/llm/chat.py` (`_call_openai`):

```python base_url = params.get('base_url') # caller-controlled if base_url: validate_url_with_env_config(base_url) # SSRF check only; a public attacker host passes if not api_key: api_key = os.getenv('OPENAI_API_KEY') # operator's key ... url = (base_url or "https://api.openai.com/v1").rstrip('/') + "/chat/completions" headers = {"Authorization": f"Bearer {api_key}"} await client.post(url, headers=headers, json=payload) # sent to base_url ```

The same wiring (env key plus caller endpoint) exists in `ai.model` (which does not even SSRF-check `base_url`), `llm.agent`, and `vector.connector` (`QDRANT_API_KEY` with a caller `url`). The SSRF guard is the wrong control here: it stops private targets but does nothing about the key being sent to an attacker's public host.

## Reproduction

Save as `keyexfil_poc.py`, run with `PYTHONPATH=src/src python keyexfil_poc.py`. It sets an operator…