databricks-sql-connector pins thrift = "~=0.24.0" (pyproject.toml#L13), which caps the resolvable thrift version below 0.25.0. Apache Thrift 0.25.0 was released 2026-09-30 and fixes 61 CVEs across language bindings (combined announcement); several affect the Python bindings this connector uses:
| CVE |
Summary |
Python-relevant |
| CVE-2026-66055 |
TJSONProtocol accepts a string/number exceeding the configured size limit |
yes (multi-language, incl. Python) |
| CVE-2026-66858 |
skip() does not apply the recursion limit in the Python accelerator (and PHP/Perl/Lua/Smalltalk/OCaml) |
yes |
| CVE-2026-85087 |
Python ≥3.12 host-name check silently becomes a no-op |
yes |
| CVE-2026-85494 |
Framed transport / binary protocol size a read buffer from a peer-declared length with no effective maximum (multi-language, incl. Python) |
yes |
| CVE-2026-94634 |
TJSONProtocol string length limit is off by default |
yes |
| CVE-2026-94636 |
TZlibTransport stops enforcing its decompressed-size limit once the limit is exactly used up |
yes |
| CVE-2026-94654 |
TNonblockingServer busy-loops after an 8192-byte-boundary frame |
yes |
Dependency scanners (Snyk confirms at least CVE-2026-66858 and CVE-2026-85494 as currently firing against thrift==0.24.0; GitHub Advisory Database has not yet mapped PyPI package ranges for the others) flag every project depending on this connector, same pattern as #964.
This is a separate upgrade from #964/#966 (oauthlib) and needs its own PR, because it is not a drop-in version bump:
Apache Thrift 0.25.0 changes TBinaryProtocol's default string_length_limit from unbounded (None) to DEFAULT_STRING_LENGTH_LIMIT (DEFAULT_MAX_FRAME_SIZE = 16,384,000 bytes ≈ 15.6 MiB) -- this is itself one of the fixes in the CVE set (unbounded allocation from a peer-declared length). thrift_backend.py constructs the protocol with no kwargs:
protocol = thrift.protocol.TBinaryProtocol.TBinaryProtocol(self._transport)
so after a bare version bump every readBinary/readString call -- including the inline Arrow result batches returned in TFetchResultsResp -- would inherit the new ~15.6 MiB cap. The connector's own result-size knob, buffer_size_bytes / DEFAULT_RESULT_BUFFER_SIZE_BYTES, defaults to 100 MiB (client.py), well above that cap, so this is a real regression, not a theoretical one. Confirmed empirically: a 20 MiB binary field that reads fine under thrift 0.24.0 raises TTransportException: Length exceeded max allowed: 16384000 under 0.25.0's default protocol construction.
Proposed fix: widen thrift to allow 0.25.x (e.g. >=0.24.0,<0.26.0) and construct TBinaryProtocol with an explicit string_length_limit sized to (or derived from) the connector's own buffer_size_bytes, so the upgrade both clears the CVEs and preserves today's large-result-set behavior. Also needs the same DBR LTS wheel-availability check #798/#840 established for 0.24.0 (0.25.0 does ship manylinux2014/macOS/musl/Windows wheels for cp310-cp314 on PyPI, so this should pass, but the DBR LTS Install CI gate is the authoritative check).
Requesting this be tracked and fixed independently of #964/#966 so the oauthlib fix isn't blocked on resolving the thrift compatibility work.
cc @jmuldoon-fa @lmarella-fa
databricks-sql-connectorpinsthrift = "~=0.24.0"(pyproject.toml#L13), which caps the resolvablethriftversion below 0.25.0. Apache Thrift 0.25.0 was released 2026-09-30 and fixes 61 CVEs across language bindings (combined announcement); several affect the Python bindings this connector uses:TJSONProtocolaccepts a string/number exceeding the configured size limitskip()does not apply the recursion limit in the Python accelerator (and PHP/Perl/Lua/Smalltalk/OCaml)TJSONProtocolstring length limit is off by defaultTZlibTransportstops enforcing its decompressed-size limit once the limit is exactly used upTNonblockingServerbusy-loops after an 8192-byte-boundary frameDependency scanners (Snyk confirms at least CVE-2026-66858 and CVE-2026-85494 as currently firing against
thrift==0.24.0; GitHub Advisory Database has not yet mapped PyPI package ranges for the others) flag every project depending on this connector, same pattern as #964.This is a separate upgrade from #964/#966 (oauthlib) and needs its own PR, because it is not a drop-in version bump:
Apache Thrift 0.25.0 changes
TBinaryProtocol's defaultstring_length_limitfrom unbounded (None) toDEFAULT_STRING_LENGTH_LIMIT(DEFAULT_MAX_FRAME_SIZE= 16,384,000 bytes ≈ 15.6 MiB) -- this is itself one of the fixes in the CVE set (unbounded allocation from a peer-declared length).thrift_backend.pyconstructs the protocol with no kwargs:so after a bare version bump every
readBinary/readStringcall -- including the inline Arrow result batches returned inTFetchResultsResp-- would inherit the new ~15.6 MiB cap. The connector's own result-size knob,buffer_size_bytes/DEFAULT_RESULT_BUFFER_SIZE_BYTES, defaults to 100 MiB (client.py), well above that cap, so this is a real regression, not a theoretical one. Confirmed empirically: a 20 MiB binary field that reads fine under thrift 0.24.0 raisesTTransportException: Length exceeded max allowed: 16384000under 0.25.0's default protocol construction.Proposed fix: widen
thriftto allow0.25.x(e.g.>=0.24.0,<0.26.0) and constructTBinaryProtocolwith an explicitstring_length_limitsized to (or derived from) the connector's ownbuffer_size_bytes, so the upgrade both clears the CVEs and preserves today's large-result-set behavior. Also needs the same DBR LTS wheel-availability check #798/#840 established for 0.24.0 (0.25.0 does shipmanylinux2014/macOS/musl/Windows wheels for cp310-cp314 on PyPI, so this should pass, but theDBR LTS InstallCI gate is the authoritative check).Requesting this be tracked and fixed independently of #964/#966 so the oauthlib fix isn't blocked on resolving the thrift compatibility work.
cc @jmuldoon-fa @lmarella-fa