OpenAgents SSRF: rekord podatności i live issue nie mówią tego samego — jak Vulnerability Engineer ustala source precedence

CVE-2026-86237 dotyczy OpenAgents HTTP Transport. Endpoint POST /api/admin/default-model/test przyjmuje provider, api_key i kontrolowane przez caller base_url; dla providerów custom/openai-compatible adres trafia do klienta OpenAI-compatible i powoduje request z serwera do wskazanego hosta — klasyczny SSRF. Ciekawsze jest to, co dzieje się z metadanymi podatności.

CVE-2026-86237: brak wymaganego admin authorization check na endpoincie → attacker-controlled base_url → server-initiated request (metadata service, localhost, internal API).

Konflikt danych: GHSA „unreviewed”, brak patched version, narracja o zamknięciu jako inapplicable — a live issue #566 jest Open z PoC i rekomendacją _require_admin().

Attack path

unauthenticated HTTP request → /api/admin/default-model/test → attacker controls base_url → create_model_provider() → SimpleGenericProvider → AsyncOpenAI(base_url=attacker_url) → server-initiated HTTP request

Brak authentication sprawia, że endpoint może zamienić host OpenAgents w network pivot — problem nie polega tylko na „dowolnym URL”.

Czy mamy potwierdzony fix? Nie zgaduj

Publiczny GHSA nie wskazuje patched version; live issue też nie daje jednoznacznego released fix. Poprawny stan VM to nie patch_available = yes, lecz:

vulnerability_record_exists = yes public_technical_report = yes public_poc = yes fixed_version = unknown/not published

Dlaczego stan issue ma znaczenie i jak ustalać precedence

Issue tracker nie jest idealną security-bazą — bywa zmieniany i zamykany z powodów organizacyjnych. Ale gdy rekord wtórny twierdzi „maintainer closed as inapplicable”, a źródło pierwotne pokazuje Open, pipeline powinien oznaczyć konflikt, nie nadpisywać. Praktyczna kolejność źródeł: (1) vendor/maintainer advisory, (2) live source/fixed commit/release, (3) official issue/PR, (4) CNA/CVE, (5) NVD enrichment, (6) agregatory. Każda rozbieżność musi mieć provenance: claim + source + timestamp + confidence.

CVSS też nie jest jednolity

Publiczny issue proponował CVSS 3.1 7.5 (wysoki C impact), GHSA pokazuje 4.0 5.5 Moderate (VC:L). To niekoniecznie błąd — różne modele i różne założenia o tym, co SSRF realnie odczyta. Ważniejsze pytanie: czy z tego deploymentu base_url może osiągnąć metadata service, control-plane API, localhost lub wewnętrzne usługi z implicit trust? Jeśli tak, lokalny impact bywa większy niż ogólne VC:L.

Bez patcha: affectedness i controls

Ustal: czy transport jest uruchomiony i osiągalny, czy endpoint istnieje w używanej wersji, czy wymaga auth, czy egress pozwala na RFC1918/localhost/metadata, czy workload ma cloud identity. Możliwe controls: blokada endpointu na reverse proxy, auth przed endpointem, egress allowlist, blokada metadata IP, workload identity hardening, izolacja network namespace. Uwaga: sama blokada 169.254.169.254 nie usuwa SSRF do localhost i innych internal API.

Wniosek

CVE-2026-86237 jest ciekawy nie dlatego, że SSRF jest egzotyczne, lecz dlatego, że live issue, unreviewed GHSA, CVSS i brak fixed version tworzą stan, w którym automat nie powinien udawać pewności. Prawdziwa praca VE zaczyna się tutaj: zachować provenance, nazwać konflikt, sprawdzić kod i deployment.

Powiązane na blogu

SQL Chat: unauthenticated pivot do baz — SSRF jako network pivot
GHES: GHSA „Unknown” — konflikt i niekompletność danych

Źródła

OpenAgents — issue #566 (utw. 21.07.2026, Open) — github.com/openagents-org
GitHub Advisory Database — GHSA-969x-2pm2-x3hx / CVE-2026-86237 (07.09.2026) — github.com/advisories

Nota redakcyjna: stan informacji 7 września 2026. CVE-2026-86237 (OpenAgents HTTP Transport, SSRF przez unauth /api/admin/default-model/test): rekordy niespójne (unreviewed GHSA bez fixed version vs live issue #566 Open; CVSS 7.5 vs 5.5). Artykuł koncentruje się na source precedence i zachowaniu provenance przy konflikcie danych.