CVE-2026-86123 w SQL Chat dostało CVSS v4 9.4 Critical i CWE CWE-918 SSRF — ale nazwanie tego „tylko SSRF” ukrywa najważniejszą część impactu. SQL Chat zawiera cztery unauthenticated API endpoints, które przyjmują od caller'a parametry połączenia do bazy: host, port, typ bazy, credentials — a następnie pozwalają użyć servera jako database connection proxy do zasobów osiągalnych z sieci aplikacji.
Credentials i network position to dwie osobne kontrole
Jeżeli atakujący ma credentials do wewnętrznej bazy, ale nie ma do niej network reachability, SQL Chat może usunąć tę barierę. credentials + network position to dwie niezależne kontrole bezpieczeństwa — ta luka dostarcza drugą. To klasyczny confused deputy / network pivot. A credentials bywają dostępne z wcześniejszego wycieku, developer config, secrets repo, credential stuffing czy domyślnych haseł — segmentacja miała być drugą linią obrony.
SSRF to nie zawsze HTTP
SSRF kojarzy się z GET http://169.254.169.254/, ale idea jest szersza: server wykonuje attacker-controlled outbound interaction ze swojej pozycji sieciowej. Tutaj transportem jest protokół bazy danych, a endpointy nie ograniczają się do „test connection” — mogą wykonywać SQL. Po udanym połączeniu atakujący może enumerować schema, czytać i modyfikować dane — w zakresie capabilities konkretnego DB account.
Aplikacja jako pivot point — zmiana wartości assetu
Inventory klasyfikuje SQL Chat jako aplikację, ale w attack graph po exploitacji staje się network pivot with database protocols. VM powinien uwzględnić: do jakich VLAN/DB-subnetów aplikacja ma routing, jakie egress ACL obowiązują i czy może łączyć się do produkcyjnych baz. Jeśli fix nie jest natychmiast możliwy, egress filtering ogranicza blast radius (allowlist zatwierdzonych DB endpointów) — nie usuwa braku uwierzytelnienia, ale ogranicza pivot.
Co jest „realnie exploitable” i dlaczego CVSS jest Critical
Potrzeba kilku warunków naraz: endpoint reachable + podatna wersja + target DB reachable z SQL Chat + użyteczne credentials. To nie jest zwykłe PR:L, bo credentials dotyczą kolejnego systemu, nie samego SQL Chat — to attack requirements poza granicą podatnego produktu. Mimo podwyższonej złożoności potential impact jest ogromny (subsequent system: High C/I), co CVSS v4 oddaje przez metryki subsequent-system — dobry przykład, gdzie v4 opisuje cross-system impact lepiej niż prosta triada.
Detection: patrz na outbound, nie tylko inbound
WAF zobaczy request do SQL Chat, ale prawdziwy skutek jest w drugiej połowie: SQL Chat → internal database. Detection powinno korelować inbound unauth API calls z outbound TCP do portów baz, nietypowymi target IP i nowymi protokołami DB — to dobry case integracji VM + NDR.
Wniosek
CWE mówi „SSRF”, ale realny business/technical impact to unauthenticated database pivot. W VE nie wystarczy nazwać primitive — trzeba narysować cały graph: attacker → SQL Chat → internal DB → SQL capability. Dopiero wtedy widać, że aplikacja staje się narzędziem do obejścia segmentacji sieci.
Powiązane na blogu
- WooCommerce: „SSRF” do payment bypass — CWE ukrywa realny biznesowy impact
- GHES: pre-receive hook jako SSRF-to-RCE — SSRF do uprzywilejowanej usługi wewnętrznej
Źródła
- VulnCheck — SQL Chat Unauthenticated Database-Connection Proxy (05.09.2026) — vulncheck.com
- GitHub Advisory Database — CVE-2026-86123 — github.com/advisories
- SQL Chat — repozytorium — github.com/sqlchat
Nota redakcyjna: stan informacji 6 września 2026. CVE-2026-86123 (SQL Chat, CVSS v4 9.4, CWE-918): cztery unauthenticated endpointy przyjmują attacker-controlled parametry połączenia i SQL, zamieniając aplikację w proxy do wewnętrznych baz. Artykuł nie zakłada, że atakujący ma credentials do każdej docelowej bazy — traktuje je jako osobny precondition.