chore(deps): [ai] Update vulnerabilityAlerts to v24 [SECURITY]

[renovate-bot]

This PR contains the following updates:

Package	Change	Age	Confidence
pyarrow	23.0.1 → 24.0.0
starlette (changelog)	0.52.1 → 1.0.1

---

Apache Arrow: Potential use-after-free when reading IPC file with pre-buffering

CVE-2026-25087 / GHSA-rgxp-2hwp-jwgg / PYSEC-2026-113

More information

Details

Use After Free vulnerability in Apache Arrow C++.

This issue affects Apache Arrow C++ from 15.0.0 through 23.0.0. It can be triggered when reading an Arrow IPC file (but not an IPC stream) with pre-buffering enabled, if the IPC file contains data with variadic buffers (such as Binary View and String View data). Depending on the number of variadic buffers in a record batch column and on the temporal sequence of multi-threaded IO, a write to a dangling pointer could occur. The value (a std::shared_ptr<Buffer> object) that is written to the dangling pointer is not under direct control of the attacker.

Pre-buffering is disabled by default but can be enabled using a specific C++ API call (RecordBatchFileReader::PreBufferMetadata). The functionality is not exposed in language bindings (Python, Ruby, C GLib), so these bindings are not vulnerable.

The most likely consequence of this issue would be random crashes or memory corruption when reading specific kinds of IPC files. If the application allows ingesting IPC files from untrusted sources, this could plausibly be exploited for denial of service. Inducing more targeted kinds of misbehavior (such as confidential data extraction from the running process) depends on memory allocation and multi-threaded IO temporal patterns that are unlikely to be easily controlled by an attacker.

Advice for users of Arrow C++:

1. check whether you enable pre-buffering on the IPC file reader (using RecordBatchFileReader::PreBufferMetadata)

2. if so, either disable pre-buffering (which may have adverse performance consequences), or switch to Arrow 23.0.1 which is not vulnerable

Severity

• CVSS Score: 7.0 / 10 (High)
• Vector String: CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:L/I:L/A:H

References

• https://nvd.nist.gov/vuln/detail/CVE-2026-25087
• https://github.com/apache/arrow/pull/48925
• https://github.com/apache/arrow
• https://github.com/pypa/advisory-database/tree/main/vulns/pyarrow/PYSEC-2026-113.yaml
• https://lists.apache.org/thread/mpm4ld1qony30tchfpjtk5b11tcyvmwh
• http://www.openwall.com/lists/oss-security/2026/02/17/4

This data is provided by OSV and the GitHub Advisory Database (CC-BY 4.0).

---

CVE-2026-25087 / GHSA-rgxp-2hwp-jwgg / PYSEC-2026-113

More information

Details

Use After Free vulnerability in Apache Arrow C++.

This issue affects Apache Arrow C++ from 15.0.0 through 23.0.0. It can be triggered when reading an Arrow IPC file (but not an IPC stream) with pre-buffering enabled, if the IPC file contains data with variadic buffers (such as Binary View and String View data). Depending on the number of variadic buffers in a record batch column and on the temporal sequence of multi-threaded IO, a write to a dangling pointer could occur. The value (a std::shared_ptr<Buffer> object) that is written to the dangling pointer is not under direct control of the attacker.

Pre-buffering is disabled by default but can be enabled using a specific C++ API call (RecordBatchFileReader::PreBufferMetadata). The functionality is not exposed in language bindings (Python, Ruby, C GLib), so these bindings are not vulnerable.

The most likely consequence of this issue would be random crashes or memory corruption when reading specific kinds of IPC files. If the application allows ingesting IPC files from untrusted sources, this could plausibly be exploited for denial of service. Inducing more targeted kinds of misbehavior (such as confidential data extraction from the running process) depends on memory allocation and multi-threaded IO temporal patterns that are unlikely to be easily controlled by an attacker.

Advice for users of Arrow C++:

1. check whether you enable pre-buffering on the IPC file reader (using RecordBatchFileReader::PreBufferMetadata)

2. if so, either disable pre-buffering (which may have adverse performance consequences), or switch to Arrow 23.0.1 which is not vulnerable

Severity

• CVSS Score: 7.0 / 10 (High)
• Vector String: CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:L/I:L/A:H

References

• http://www.openwall.com/lists/oss-security/2026/02/17/4
• https://lists.apache.org/thread/mpm4ld1qony30tchfpjtk5b11tcyvmwh
• https://github.com/apache/arrow/pull/48925

This data is provided by OSV and the PyPI Advisory Database (CC-BY 4.0).

---

Starlette has missing Host header validation that poisons request.url.path, bypassing path-based security checks

CVE-2026-48710 / GHSA-86qp-5c8j-p5mr

More information

Details

Summary

In affected versions, the HTTP Host request header was not validated before being used to reconstruct request.url. Because the routing algorithm relies on the raw HTTP path while request.url is rebuilt from the Host header, a malformed header could make request.url.path differ from the path that was actually requested. Middleware and endpoints that apply security restrictions based on request.url (rather than the raw scope path) could therefore be bypassed.

Details

When a client requests http://example.com/foo, it sends:

GET /foo HTTP/1.1
Host: example.com

Affected versions reconstructed the URL by concatenating http://{host}{path} and re-parsing the result. The Host value is only valid as a uri-host [ ":" port ] per RFC 9112 §3.2, where uri-host follows the restricted host grammar of RFC 3986 §3.2.2. When it contains characters outside that grammar - notably /, ?, or # - those characters move the path/query/fragment boundaries during re-parsing, so the parsed request.url.path no longer matches the path the server actually received. For example:

GET /foo HTTP/1.1
Host: example.com/abc?bar=

reconstructs to http://example.com/abc?bar=/foo, whose parsed path is /abc - even though routing used the real path /foo. The router still dispatches to /foo and the endpoint executes, but any middleware or code that reads request.url.path sees /abc, so path-based authorization checks can be bypassed.

Impact

Any application running an affected version that relies on request.url (or request.url.path) for security-sensitive decisions is affected. The most common case is middleware that gates access to certain path prefixes based on request.url.path. Deployments fronted by a proxy or load balancer are mitigated only if that proxy rejects or normalizes the malformed Host header before forwarding and the application does not trust attacker-controlled host headers (e.g. X-Forwarded-Host) elsewhere.

Mitigation

Upgrade to a patched version, which validates the Host header against the grammar of RFC 9112 §3.2 / RFC 3986 §3.2.2 when constructing request.url and falls back to scope["server"] for malformed values.

Severity

• CVSS Score: 6.5 / 10 (Medium)
• Vector String: CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:L/I:L/A:N

References

• https://github.com/Kludex/starlette/security/advisories/GHSA-86qp-5c8j-p5mr
• https://nvd.nist.gov/vuln/detail/CVE-2026-48710
• https://github.com/Kludex/starlette/commit/764dab0dcfb9033d75442d7a359645c9f94648c6
• https://badhost.org
• https://github.com/pypa/advisory-database/tree/main/vulns/starlette/PYSEC-2026-161.yaml
• https://ostif.org/disclosing-the-badhost-vulnerability-in-starlette
• https://www.secwest.net/starlette
• https://www.x41-dsec.de/lab/advisories/x41-2026-002-starlette
• https://github.com/advisories/GHSA-86qp-5c8j-p5mr

This data is provided by the GitHub Advisory Database (CC-BY 4.0).

---

Starlette has missing Host header validation that poisons request.url.path, bypassing path-based security checks

CVE-2026-48710 / GHSA-86qp-5c8j-p5mr / PYSEC-2026-161 / X41-2026-002

More information

Details

Summary

In affected versions, the HTTP Host request header was not validated before being used to reconstruct request.url. Because the routing algorithm relies on the raw HTTP path while request.url is rebuilt from the Host header, a malformed header could make request.url.path differ from the path that was actually requested. Middleware and endpoints that apply security restrictions based on request.url (rather than the raw scope path) could therefore be bypassed.

Details

When a client requests http://example.com/foo, it sends:

GET /foo HTTP/1.1
Host: example.com

Affected versions reconstructed the URL by concatenating http://{host}{path} and re-parsing the result. The Host value is only valid as a uri-host [ ":" port ] per RFC 9112 §3.2, where uri-host follows the restricted host grammar of RFC 3986 §3.2.2. When it contains characters outside that grammar - notably /, ?, or # - those characters move the path/query/fragment boundaries during re-parsing, so the parsed request.url.path no longer matches the path the server actually received. For example:

GET /foo HTTP/1.1
Host: example.com/abc?bar=

reconstructs to http://example.com/abc?bar=/foo, whose parsed path is /abc - even though routing used the real path /foo. The router still dispatches to /foo and the endpoint executes, but any middleware or code that reads request.url.path sees /abc, so path-based authorization checks can be bypassed.

Impact

Any application running an affected version that relies on request.url (or request.url.path) for security-sensitive decisions is affected. The most common case is middleware that gates access to certain path prefixes based on request.url.path. Deployments fronted by a proxy or load balancer are mitigated only if that proxy rejects or normalizes the malformed Host header before forwarding and the application does not trust attacker-controlled host headers (e.g. X-Forwarded-Host) elsewhere.

Mitigation

Upgrade to a patched version, which validates the Host header against the grammar of RFC 9112 §3.2 / RFC 3986 §3.2.2 when constructing request.url and falls back to scope["server"] for malformed values.

Severity

• CVSS Score: 6.5 / 10 (Medium)
• Vector String: CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:L/I:L/A:N

References

• https://github.com/Kludex/starlette/security/advisories/GHSA-86qp-5c8j-p5mr
• https://nvd.nist.gov/vuln/detail/CVE-2026-48710
• https://github.com/Kludex/starlette/commit/764dab0dcfb9033d75442d7a359645c9f94648c6
• https://badhost.org
• https://github.com/Kludex/starlette
• https://github.com/pypa/advisory-database/tree/main/vulns/starlette/PYSEC-2026-161.yaml
• https://ostif.org/disclosing-the-badhost-vulnerability-in-starlette
• https://www.secwest.net/starlette
• https://www.x41-dsec.de/lab/advisories/x41-2026-002-starlette

This data is provided by OSV and the GitHub Advisory Database (CC-BY 4.0).

---

BadHost: Missing Host header validation poisons request.url.path, bypassing path-based security checks

CVE-2026-48710 / GHSA-86qp-5c8j-p5mr / PYSEC-2026-161 / X41-2026-002

More information

Details

Starlette reconstructs the requested URL based on the HTTP Host request header and requested path, but does not perform any validation of the Host header value. This allows attackers to inject paths into the host part, prepending the actual path. However, routing in Starlette is based on the actual request path. This inconsistent interpretation of HTTP requests may lead to issues such as authentication bypass when the authentication depends on the reconstructed URL’s path.

Severity

Unknown

References

• https://badhost.org
• https://www.secwest.net/starlette
• https://ostif.org/disclosing-the-badhost-vulnerability-in-starlette/
• https://badhost.org
• https://github.com/Kludex/starlette/security/advisories/GHSA-86qp-5c8j-p5mr
• https://github.com/Kludex/starlette/security/advisories/GHSA-86qp-5c8j-p5mr
• https://www.x41-dsec.de/lab/advisories/x41-2026-002-starlette/
• https://github.com/Kludex/starlette/commit/764dab0dcfb9033d75442d7a359645c9f94648c6

This data is provided by OSV and the PyPI Advisory Database (CC-BY 4.0).

---

Release Notes

Kludex/starlette (starlette)

v1.0.1: Version 1.0.1

Compare Source

What's Changed

• Ignore malformed Host header when constructing request.url by @​Kludex in #​3279

Full Changelog: Kludex/starlette@1.0.0...1.0.1

v1.0.0: Version 1.0.0

Compare Source

Starlette 1.0 is here! 🎉

After nearly eight years since its creation, Starlette has reached its first stable release.

A special thank you to @​lovelydinosaur, the creator of Starlette, Uvicorn, HTTPX and MkDocs, whose work helped to lay the foundation for the modern async Python ecosystem. 🙏

Thank you to @​adriangb, @​graingert, @​agronholm, @​florimondmanca, @​aminalaee, @​tiangolo, @​alex-oleshkevich, @​abersheeran, and @​uSpike for helping make Starlette what it is today. And to all my sponsors - especially @​tiangolo, @​huggingface, and @​elevenlabs - thank you for your support!

Thank you to all 290+ contributors who have shaped Starlette over the years! ❤️

Read more on the blog post.

Check out the full release notes at https://www.starlette.io/release-notes/#​100-march-22-2026

---

Full Changelog: Kludex/starlette@1.0.0rc1...1.0.0

---

Configuration

📅 Schedule: (UTC)

• Branch creation
  • At any time (no schedule defined)
• Automerge
  • At any time (no schedule defined)

🚦 Automerge: Disabled by config. Please merge this manually once you are satisfied.

♻ Rebasing: Whenever PR is behind base branch, or you tick the rebase/retry checkbox.

🔕 Ignore: Close this PR and you won't be reminded about these updates again.

---

• If you want to rebase/retry this PR, check this box

---

This PR was generated by Mend Renovate. View the repository job log.