Skip to content

Close SSRF gaps in all api_url configs and block metadata IP encodings#5

Merged
ethanj merged 1 commit into
mainfrom
sync/python-f19180d
Jun 16, 2026
Merged

Close SSRF gaps in all api_url configs and block metadata IP encodings#5
ethanj merged 1 commit into
mainfrom
sync/python-f19180d

Conversation

@ethanj

@ethanj ethanj commented Jun 16, 2026

Copy link
Copy Markdown
Contributor

Summary

Consolidate api_url SSRF validation into a single shared helper and apply it to all six SDK configs that accept an api_url field — previously only the storage and client configs validated the URL while the three provider configs and EntitiesClientConfig accepted any string.

Changes

  • Add atomicmemory/core/url.py with a single validate_api_url helper that centralizes scheme/host checks and SSRF defense.
  • Wire the shared validator into all six configs: AtomicMemoryClientConfig, StorageClientConfig, EntitiesClientConfig, AtomicMemoryProviderConfig, HindsightProviderConfig, and Mem0ProviderConfig.
  • Switch to posture B (match Node SDK): loopback/private/reserved IP literals are allowed by default (the SDK routinely connects to local and self-hosted cores); link-local and cloud-metadata addresses (169.254.169.254, fe80::/10) are always blocked.
  • Canonicalize IPv4-mapped IPv6 addresses (::ffff:169.254.169.254169.254.169.254) so the metadata block is deterministic across Python 3.10/3.11.
  • Canonicalize legacy IPv4 encodings (decimal 2852039166, hex 0xA9FEA9FE, dotted-octal 0251.0376.0251.0376) via socket.inet_aton so they cannot bypass the link-local block.
  • Add allowPrivateNetworks field (default True) on every config; setting it to False also rejects loopback/private/reserved literals.
  • Add tests/core/test_url.py — 12 parametrized cases covering allowed, always-blocked, strict-mode, IPv4-mapped IPv6, whitespace stripping, and encoded-address bypass scenarios.
  • Add tests/providers/test_config_ssrf.py — integration coverage for each config surface plus a reflective enumeration test (test_every_api_url_config_blocks_imds) that auto-discovers every BaseModel subclass with an api_url field and fails if any future config omits the guard.
  • Bump package version to 1.1.2.

Why

The three provider configs and EntitiesClientConfig had no URL validation at all, so a crafted apiUrl could reach the AWS IMDS endpoint (169.254.169.254) or its non-canonical encodings (decimal, hex, octal, IPv4-mapped IPv6). The validator was also applied per-surface with duplicated logic, so adding a new config would silently inherit no protection. The shared helper closes both gaps at one chokepoint.

Validation

  • uv run pytest tests/core/test_url.py tests/providers/test_config_ssrf.py — all new tests pass.
  • The reflective enumeration test asserts ≥ 6 configs are discovered and each rejects the IMDS literal; it will fail automatically if a future config with an api_url field omits the validator.
  • uv run mypy atomicmemory --strict and uv run ruff check . both pass clean.

```json
{
  "title": "Close SSRF gaps in all api_url configs and block metadata IP encodings",
  "body": "## Summary\n\nConsolidate `api_url` SSRF validation into a single shared helper and apply it to all six SDK configs that accept an `api_url` field — previously only the storage and client configs validated the URL while the three provider configs and `EntitiesClientConfig` accepted any string.\n\n## Changes\n\n- Add `atomicmemory/core/url.py` with a single `validate_api_url` helper that centralizes scheme/host checks and SSRF defense.\n- Wire the shared validator into all six configs: `AtomicMemoryClientConfig`, `StorageClientConfig`, `EntitiesClientConfig`, `AtomicMemoryProviderConfig`, `HindsightProviderConfig`, and `Mem0ProviderConfig`.\n- Switch to posture B (match Node SDK): loopback/private/reserved IP literals are **allowed by default** (the SDK routinely connects to local and self-hosted cores); link-local and cloud-metadata addresses (`169.254.169.254`, `fe80::/10`) are always blocked.\n- Canonicalize IPv4-mapped IPv6 addresses (`::ffff:169.254.169.254` → `169.254.169.254`) so the metadata block is deterministic across Python 3.10/3.11.\n- Canonicalize legacy IPv4 encodings (decimal `2852039166`, hex `0xA9FEA9FE`, dotted-octal `0251.0376.0251.0376`) via `socket.inet_aton` so they cannot bypass the link-local block.\n- Add `allowPrivateNetworks` field (default `True`) on every config; setting it to `False` also rejects loopback/private/reserved literals.\n- Add `tests/core/test_url.py` — 12 parametrized cases covering allowed, always-blocked, strict-mode, IPv4-mapped IPv6, whitespace stripping, and encoded-address bypass scenarios.\n- Add `tests/providers/test_config_ssrf.py` — integration coverage for each config surface plus a **reflective enumeration test** (`test_every_api_url_config_blocks_imds`) that auto-discovers every `BaseModel` subclass with an `api_url` field and fails if any future config omits the guard.\n- Bump package version to 1.1.2.\n\n## Why\n\nThe three provider configs and `EntitiesClientConfig` had no URL validation at all, so a crafted `apiUrl` could reach the AWS IMDS endpoint (`169.254.169.254`) or its non-canonical encodings (decimal, hex, octal, IPv4-mapped IPv6). The validator was also applied per-surface with duplicated logic, so adding a new config would silently inherit no protection. The shared helper closes both gaps at one chokepoint.\n\n## Validation\n\n- `uv run pytest tests/core/test_url.py tests/providers/test_config_ssrf.py` — all new tests pass.\n- The reflective enumeration test asserts ≥ 6 configs are discovered and each rejects the IMDS literal; it will fail automatically if a future config with an `api_url` field omits the validator.\n- `uv run mypy atomicmemory --strict` and `uv run ruff check .` both pass clean."
}
```
@ethanj ethanj changed the title Fix PR Metadata: SSRF Guard Across All api_url Configs Close SSRF gaps in all api_url configs and block metadata IP encodings Jun 16, 2026
@ethanj ethanj merged commit f0160c3 into main Jun 16, 2026
4 checks passed
@ethanj ethanj deleted the sync/python-f19180d branch June 18, 2026 08:16
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant