SSRF Bypass In Validate_safe_url When LANGCHAIN_ENV=Local_test

The function validate_safe_url contains an explicit special-case conditional that returns the URL without validation if LANGCHAIN_ENV == 'local_test' and the hostname starts with 'test' and contains 'server'. This condition is far too broad and permits attacker-controlled hostnames such as test.attacker.server.com. The related helper _effective_allowed_hosts uses env.startswith('local'), which treats any environment value starting with 'local' as if it were one of the intended local development modes.

1. Install langchain-core latest. 2. Set environment variable LANGCHAIN_ENV=local_test. 3. Import validate_safe_url from langchain_core._security._ssrf_protection. 4. Call validate_safe_url('http://test.attacker.server.com/exfil'). 5. Observe that the function returns the URL instead of raising ValueError.

Removing the special-case may break local testing setups that rely on hostnames like test.some.server.com being automatically allowed. Such hosts must now be added to the explicit allowlist via configuration. Changing the environment check to exact equality may revoke localhost allowances for users who were using environment values such as 'local_staging' unintentionally. In multi-threaded applications, environment variables are process-wide; changing LANGCHAIN_ENV at runtime affects all threads. Rollback recommendation: restore the previous function definitions if needed, but understand that doing so reintroduces the SSRF vulnerability. Upgrading langchain-core does not automatically fix already-deployed code; you must actually install the patched version and ensure no other code path recreates the bypass.