[dependabot]

Bumps multidict from 6.8.0 to 6.9.1.

Release notes

Sourced from multidict's releases.

6.9.1

Bug fixes

• Fixed the C extension reading freed memory on free-threaded builds when a list handed to :py:meth:~multidict.MultiDict.update, :py:meth:~multidict.MultiDict.extend, :py:meth:~multidict.MultiDict.merge or the :py:class:~multidict.MultiDict and :py:class:~multidict.CIMultiDict constructors, a [key, value] item inside any iterable handed to them, or a list tested with in against :py:meth:~multidict.MultiDict.items, is changed by another thread; a call that catches the list shrinking under it now raises :py:exc:RuntimeError -- by :user:rodrigobnogueira.

  Related issues and pull requests on GitHub: #1437.

• Fixed a data race on the free-threaded build where a retired hash table's reader count used relaxed atomics, letting a lock-free get()/getone()/ __getitem__() read race a concurrent free of that table. The reader-exit decrement and the drain's free check now use release/acquire ordering instead -- by :user:asvetlov.

  Related issues and pull requests on GitHub: #1481.

• Fixed a free-threaded build bug where two threads calling update(), merge(), or __setitem__() on the same key at the same time could lose the key entirely instead of just racing on which value wins. A decref of the replaced value could transiently suspend the writer's critical section, letting a second writer for the same key observe the first writer's in-progress entry as absent and, once both settled, mistake it for a stale duplicate and delete it. Every such decref is now deferred until the writer has released its critical section, so the window can no longer open. setdefault() had an unrelated instance of the same blind spot (it could insert a duplicate rather than recognizing an in-flight key), fixed alongside it -- by :user:asvetlov.

  Related issues and pull requests on GitHub: #1483.

• Fixed a free-threaded build bug where getall() and the items()/ keys()/values() equality path could raise KeyError or report a present, never-deleted key as missing. A concurrent update()/extend()/ __setitem__() call can have its critical section transiently suspended (a decref triggering a blocking allocator call) while an entry is marked as part of its own bookkeeping; a reader landing in that window used to treat the mark as "not found" instead of "still there, in flight" -- by :user:asvetlov.

  Related issues and pull requests on GitHub:

... (truncated)

Changelog

Sourced from multidict's changelog.

6.9.1

(2026-09-21)

Bug fixes

• Fixed the C extension reading freed memory on free-threaded builds when a list handed to :py:meth:~multidict.MultiDict.update, :py:meth:~multidict.MultiDict.extend, :py:meth:~multidict.MultiDict.merge or the :py:class:~multidict.MultiDict and :py:class:~multidict.CIMultiDict constructors, a [key, value] item inside any iterable handed to them, or a list tested with in against :py:meth:~multidict.MultiDict.items, is changed by another thread; a call that catches the list shrinking under it now raises :py:exc:RuntimeError -- by :user:rodrigobnogueira.

  Related issues and pull requests on GitHub: :issue:1437.

• Fixed a data race on the free-threaded build where a retired hash table's reader count used relaxed atomics, letting a lock-free get()/getone()/ __getitem__() read race a concurrent free of that table. The reader-exit decrement and the drain's free check now use release/acquire ordering instead -- by :user:asvetlov.

  Related issues and pull requests on GitHub: :issue:1481.

• Fixed a free-threaded build bug where two threads calling update(), merge(), or __setitem__() on the same key at the same time could lose the key entirely instead of just racing on which value wins. A decref of the replaced value could transiently suspend the writer's critical section, letting a second writer for the same key observe the first writer's in-progress entry as absent and, once both settled, mistake it for a stale duplicate and delete it. Every such decref is now deferred until the writer has released its critical section, so the window can no longer open. setdefault() had an unrelated instance of the same blind spot (it could insert a duplicate rather than recognizing an in-flight key), fixed alongside it -- by :user:asvetlov.

  Related issues and pull requests on GitHub: :issue:1483.

• Fixed a free-threaded build bug where getall() and the items()/ keys()/values() equality path could raise KeyError or report a present, never-deleted key as missing. A concurrent update()/extend()/ __setitem__() call can have its critical section transiently suspended (a decref triggering a blocking allocator call) while an entry is marked as

... (truncated)

Commits

• 0a1770c Release 6.9.1 (#1504)
• d220522 Upload release assets one at a time to avoid the secondary rate limit (#1503)
• 30cd596 Stop a GIL-releasing del from segfaulting the standard C extension build ...
• d1c331a Recheck the reader gate after taking the retired list (#1502)
• b37f07c Allocate deferred decrefs in fixed-size blocks (#1501)
• 563f667 Run CodSpeed benchmarks on Python 3.14 and loop the smallest ones (#1498)
• 157c87c Cancel superseded CI runs on pull requests (#1500)
• d43adfe Drop -I from the ASan test command so PYTHONMALLOC takes effect (#1499)
• 2a68472 Stop items() iteration from reading a freed entry in CIMultiDict (#1496)
• cd528d6 Rename GHSA-54p9-h82j-f925 changelog fragment to the merged commit (#1495)
• Additional commits viewable in compare view

Dependabot will resolve any conflicts with this PR as long as you don't alter it yourself. You can also trigger a rebase manually by commenting @dependabot rebase.

---

Dependabot commands and options

You can trigger Dependabot actions by commenting on this PR:

• @dependabot rebase will rebase this PR
• @dependabot recreate will recreate this PR, overwriting any edits that have been made to it
• @dependabot show <dependency name> ignore conditions will show all of the ignore conditions of the specified dependency
• @dependabot ignore this major version will close this PR and stop Dependabot creating any more for this major version (unless you reopen the PR or upgrade to it yourself)
• @dependabot ignore this minor version will close this PR and stop Dependabot creating any more for this minor version (unless you reopen the PR or upgrade to it yourself)
• @dependabot ignore this dependency will close this PR and stop Dependabot creating any more for this dependency (unless you reopen the PR or upgrade to it yourself)
  You can disable automated security fix PRs for this repo from the Security Alerts page.

[dependabot]

Labels

The following labels could not be found: dependencies. Please create it before Dependabot can add it to a pull request.

Please fix the above issues or remove invalid values from dependabot.yml.

[github-actions]

Dependency Security Audit

Scanned: pyproject.toml dependencies + dev group, resolved at Python 3.10 (the current resolution, and the lowest versions the published specs permit under each pydantic major)

❌ 2 fixable HIGH/CRITICAL advisories -- blocking this build.

Severity	Count
🔴 HIGH	2
🔶 MEDIUM	2
⚪ LOW	1
❔ UNKNOWN	4

Severity	Package	Installed	Fixed in	Advisory
🔴 HIGH	aiohttp	3.14.3	3.14.4	CVE-2026-111064
🔴 HIGH	aiohttp	3.14.3	3.14.4	GHSA-2g87-pp6c-29x5
🔶 MEDIUM	uv	0.12.17	0.12.18	CVE-2026-104843
🔶 MEDIUM	werkzeug	3.1.8	3.1.9	CVE-2026-102598
⚪ LOW	aiohttp	3.14.3	3.14.4	CVE-2026-111063
❔ UNKNOWN	aiohttp	3.14.3	3.14.4	CVE-2026-111063 (GHSA-494j-54xm-rwp3)
❔ UNKNOWN	aiohttp	3.14.3	3.14.4	CVE-2026-111064 (GHSA-5wr8-gcqf-gqf3)
❔ UNKNOWN	uv	0.12.17	0.12.18	PYSEC-2026-4305 (CVE-2026-104843, GHSA-2cv4-cqwr-gwf7)
❔ UNKNOWN	werkzeug	3.1.8	3.1.9	PYSEC-2026-4312 (CVE-2026-102598, GHSA-g6x2-hccm-hh4m)

Advisory details

HIGH -- CVE-2026-111064 (aiohttp 3.14.3)

Found by: trivy:runtime-floor, trivy:runtime-floor-pydantic-v2

aiohttp: aiohttp: Denial of Service via missing initial request timeout

HIGH -- GHSA-2g87-pp6c-29x5 (aiohttp 3.14.3)

Found by: pip-audit:runtime-floor, pip-audit:runtime-floor-pydantic-v2, trivy:runtime-floor, trivy:runtime-floor-pydantic-v2

aiohttp: Multiple instances of excessive or unbounded memory/CPU use

MEDIUM -- CVE-2026-104843 (uv 0.12.17)

Found by: trivy:dev-ceiling

uv: uv: Arbitrary code execution via malicious package extraction on Windows

MEDIUM -- CVE-2026-102598 (werkzeug 3.1.8)

Found by: trivy:dev-ceiling

werkzeug: werkzeug: Denial of Service via safe_join() Windows special device paths

LOW -- CVE-2026-111063 (aiohttp 3.14.3)

Found by: trivy:runtime-floor, trivy:runtime-floor-pydantic-v2

aiohttp: aiohttp: Information disclosure via unenforced Secure attribute on shared cookies

UNKNOWN -- CVE-2026-111063 (GHSA-494j-54xm-rwp3) (aiohttp 3.14.3)

Found by: pip-audit:runtime-floor, pip-audit:runtime-floor-pydantic-v2

### Summary The Secure attribute was not being enforced for the shared cookie. ### Impact It may be possible to send a shared cookie marked Secure through an unencrypted request.

UNKNOWN -- CVE-2026-111064 (GHSA-5wr8-gcqf-gqf3) (aiohttp 3.14.3)

Found by: pip-audit:runtime-floor, pip-audit:runtime-floor-pydantic-v2

### Summary The keepalive timeout was not used during the initial portion of a request. ### Impact An attacker could keep an idle connection open indefinitely before sending any data. ### Workaround Use a reverse proxy (as recommended for all production deployments) with sensible keepalive limits.

UNKNOWN -- PYSEC-2026-4305 (CVE-2026-104843, GHSA-2cv4-cqwr-gwf7) (uv 0.12.17)

Found by: pip-audit:dev-ceiling

### Impact In versions of uv from 0.12.7 to 0.12.18 on Windows, uv could be induced into writing a file outside of the installation prefix during wheel installation. A malicious wheel could use this to place an executable outside of the intended environment, including in a directory already present on the user's PATH. This vulnerability only affects Windows hosts; no other platforms are affected. ### Patches uv 0.12.18 and newer address this vulnerability. Users are encouraged to upgrade to 0.12.18. ### Workarounds There is no workaround other than upgrading to uv 0.12.18.

UNKNOWN -- PYSEC-2026-4312 (CVE-2026-102598, GHSA-g6x2-hccm-hh4m) (werkzeug 3.1.8)

Found by: pip-audit:dev-ceiling

Werkzeug's `safe_join` function allows Windows device names as filenames when they have an empty ADS marker on NTFS. This was previously reported as https://github.com/pallets/werkzeug/security/advisories/GHSA-hgf8-39gv-g3f2, but the added filtering failed to account for the fact Windows allows special device names with an empty ADS marker, such as `NUL:`. `send_from_directory` uses `safe_join` to safely serve files at user-specified paths under a directory. If the application is running on Windows and NTFS, and the requested path ends with a special device name, the file will be opened successfully, but reading will hang indefinitely.

How to fix

Raise the affected lower bound in pyproject.toml ([project].dependencies, or the pin in the dev dependency group) to at least the Fixed in version above, then run uv lock. Because this package publishes open >= ranges, the floor is what consumers can actually install -- bumping only the resolved version does not close the hole.

This audit resolves without the 7-day publish-age cooldown (exclude-newer) in [tool.uv], but uv lock applies it. If uv lock says the fixed version was filtered by exclude-newer, add exclude-newer-package = { <package> = false } under [tool.uv] in pyproject.toml, run uv lock and commit both files. Once the release is 7 days old, remove the entry and run uv lock again.

An advisory with no fix available does not block the build -- it is reported here so it can be tracked, but no version bump can resolve it. Suppression files are deliberately not honoured: the scan runs with --ignorefile /dev/null so nothing can disappear from this report silently.