fix: upgrade starlette to 1.1.0 (CVE-2026-48818)

[orbisai0security]

Summary

Upgrade starlette from 1.0.0 to 1.1.0 to fix CVE-2026-48818.

Vulnerability

Field	Value
ID	CVE-2026-48818
Severity	HIGH
Scanner	trivy
Rule	CVE-2026-48818
File	uv.lock
Assessment	Likely exploitable

Description: Starlette: SSRF and NTLM credential theft via UNC paths in StaticFiles on Windows

Evidence

Scanner confirmation: trivy rule CVE-2026-48818 flagged this pattern.

Production code: This file is in the production codebase, not test-only code.

Threat Model Context

This is a Python library - vulnerabilities affect applications that import this code.

Changes

• uv.lock

Verification

• Build passes
• Scanner re-scan confirms fix
• LLM code review passed

---

This change addresses a pattern flagged by static analysis. The code path handles user-influenced input and the fix reduces the attack surface against both manual and automated exploitation.

---

Automated security fix by OrbisAI Security

[safishamsi]

Landed on v8 (commit ec6b397). starlette is bumped to 1.3.1 (carries the fix for this CVE), and rather than only bumping the lockfile we floored starlette>=1.3.1 in the mcp (and all) extras in pyproject. That matters because graphify/serve.py imports starlette directly for the HTTP MCP transport but it was only an undeclared transitive dep via mcp — so a lock-only bump would protect dev/CI but not end users installing graphifyy[mcp], who resolve dependencies fresh. The floor protects them too. Verified: serve/MCP/HTTP tests pass on 1.3.1, full suite green. Closing as superseded by the pyproject-level fix. Thanks for the report! Note: 1.3.1 covers both CVE-2026-48818 and CVE-2026-54283, so this and #1396 are resolved by the same floor.

[orbisai0security]

Thanks for the detailed explanation and for taking the time to land a proper fix rather than just merging the lock bump! The pyproject floor is clearly the right call. I hadn't considered that end users installing graphify[mcp] resolve deps fresh, so the lockfile wouldn't have protected them.

Good catch on 1.3.1 covering CVE-2026-54283 as well. I'll make sure future PRs from our scanner target the latest patched release rather than the minimum that fixes the flagged CVE.