GitHub Repo
LangChain Core 1.6.8 Strengthens IPv6 SSRF Checks, Adds Interface Scope and Embedded IPv4 Handling
LangChain released Core 1.6.8 on October 8, updating IPv6 address normalization and embedded IPv4 checks to strengthen blocking of local and cloud metadata endpoints. The fix has been merged and published on PyPI, but automated review also flagged possible changes to some default blocking behavior, so engineering teams should verify their custom network-range rules.
LangChain released langchain-core 1.6.8 on October 8, with release notes listing a fix for IPv6 server-side request forgery (SSRF) checks. In AI applications that let users or models provide URLs for the server to access, these checks determine whether tools can reach local services and cloud metadata endpoints. The package is available for download; this is not a proposal awaiting a merge. Release notes, PyPI
The code changes cover two cases: IPv6 addresses are converted to integers and then reconstructed, removing interface scope identifiers such as %eth0; and IPv4-compatible addresses in ::/96 are recognized, with their embedded IPv4 address extracted for subsequent policy checks. Special handling for :: and ::1 is retained. This makes different representations of the same destination subject to consistent checks, reducing the risk that a blocking rule recognizes only one representation. Fix diff
New tests cover IPv6 addresses with interface identifiers, loopback addresses, and several metadata addresses. They separately test cases with block_private_ips enabled and disabled. The tests require some sensitive destinations to remain blocked when private-network restrictions are relaxed, and also verify that access is allowed when local blocking is explicitly disabled. These cases provide verifiable policy boundaries, but do not establish that all network-access tools apply the same protection. Test changes
Some details remain worth tracking. Automated review in the PR noted that converting an address to IPv4 first could allow public IPv4-compatible addresses through the default policy, even though the entire range was previously blocked. It could also prevent custom IPv6 CIDRs from matching the original representation. These are concerns raised by automated review, not confirmed vulnerabilities; however, teams using additional_blocked_cidrs should add regression cases for their own rules and follow the maintainers’ response. Public information also does not establish a complete affected-version range or evidence of exploitation. PR discussion