dlt: credential leak and SSRF via pagination next URL

No upstream patch is available yet. Teams that run rest_api sources or RESTClient against APIs they do not fully trust should apply one of these mitigations until an official fix is released.

1. Set an explicit paginator on every resource instead of relying on auto-detection. Where the API supports it, prefer offset, page-number or cursor pagination, which keep requests on the configured base URL.
2. If you must use JSONLinkPaginator or HeaderLinkPaginator, subclass it and override update_request to stop pagination when the resolved next URL's scheme or host differs from the original request.
3. If modifying the library, patch BaseNextUrlPaginator.update_request in dlt/sources/helpers/rest_client/paginators.py to keep next-page URLs on the same origin unless the user opts in, and only attach auth for the configured host.
4. Run pipelines with network egress limited to the APIs they need, and block link-local metadata addresses (such as 169.254.169.254) from pipeline hosts or require IMDSv2.
5. Use short-lived, narrowly scoped API credentials for ingestion, and rotate any credential used against an API that may have returned unexpected next-page links.

Any dlt pipeline that pages through a REST API with RESTClient or the rest_api source and a configured authenticator (BearerTokenAuth, APIKeyAuth, HttpBasicAuth and similar) is exposed when the upstream API, or a party able to alter its responses, is hostile. Secrets in the default request headers travel with every page as well.

Two outcomes follow. First, credential theft: the pipeline's secret is sent to a host chosen by whoever controls the response. dlt already masks these same secrets in its logs, but not on the wire. Second, server-side request forgery: the pipeline can be made to request internal or link-local services and load the response body into the destination dataset. This is not an HTTP redirect, so the requests library's own rule that strips Authorization on cross-host redirects never runs. A working exploit is withheld.

JSONLinkPaginator and HeaderLinkPaginator read the next-page reference directly from the response. BaseNextUrlPaginator.update_request then only resolves relative URLs and assigns the result to request.url, with no scheme or host check. The same request object keeps its auth, so RESTClient._send_request re-runs the authenticator against the new URL when it prepares the request:

• Next URL assigned with no host check: dlt/sources/helpers/rest_client/paginators.py#L651-L662
• Next reference taken from the Link header: dlt/sources/helpers/rest_client/paginators.py#L709-L711
• Next reference taken from the JSON body: dlt/sources/helpers/rest_client/paginators.py#L764-L767
• Pagination loop reuses the request and its auth: dlt/sources/helpers/rest_client/client.py#L271-L284
• Request prepared again with the authenticator: dlt/sources/helpers/rest_client/client.py#L141-L142
• Next-link paginators are the first auto-detectors: dlt/sources/helpers/rest_client/detector.py#L151-L172 and detector.py#L213-L220

1. 2026-07-14Vulnerability reported privately via GitHub Security Advisory (GHSA-67vw-hpjr-f78q).
2. 2026-08-18First follow-up comment posted on the advisory (35 days in triage).
3. 2026-09-17Second follow-up comment posted on the advisory (65 days in triage).
4. 2026-10-20Coordinated-disclosure notice posted on the advisory after the 90-day window passed, setting a deadline of 2026-11-03.
5. 2026-11-03Coordinated-disclosure deadline expired with no response from the maintainer; sink verified still present at HEAD 75ea7f3 and in release 1.32.0.
6. 2026-11-03Public advisory published; CVE requested via MITRE CNA-LR.

• Affected repository: dlt-hub/dlt
• GitHub Security Advisory: GHSA-67vw-hpjr-f78q (private; in triage)