Database/AI/ML frameworks & serving
SitemapLoader: nested sitemap entries skip restrict_to_same_domain, giving readable SSRF
Impact
An ingestion pipeline built on SitemapLoader can be made to fetch arbitrary internal URLs even when the deployer set restrict_to_same_domain=True to prevent exactly that. The domain check is applied to leaf url entries but not to nested sitemap entries, which go straight to an aiohttp GET with no private, loopback or link-local filtering. Because the response body is parsed into the returned Documents, this is disclosure and not a blind request: cloud instance-metadata credentials for the GPU node, an internal model registry, a cluster API endpoint or an unauthenticated inference admin port all come back to whoever called the loader. Ingestion workers commonly run inside the same cluster as the serving fleet with a service account and node identity, which is what makes the readable variant expensive.
Who can reach it
Anyone who controls or can influence a sitemap that the pipeline ingests - the operator of a crawled site, or any user who can submit a sitemap URL. No authentication to the application is required (CVSS PR:N); the request originates from the ingestion worker, so it inherits that pod's network position.
What to do
The record cites the upstream issue and the VulnCheck advisory and names no fixed langchain-community release, so there is no version to pin to yet. In the meantime, apply the domain check yourself before ingestion by resolving and allowlisting nested sitemap hosts, and cut the ingestion pod's egress: block link-local metadata addresses and RFC1918 ranges it does not need. Rolling out either the eventual package update or a wrapper is a dependency bump and a restart of the ingestion workers - no node drain.
References
This entry is curated: imported from vendor advisories with machine assistance, not yet individually verified. Confirm against your vendor's advisory before acting, and report anything wrong.