# CVE-2026-27695: zae-limiter — Fixed in 0.10.1

🐍

🐍 PyPI

Not in CISA KEV

MEDIUM severity

# CVE-2026-27695 — zae-limiter

MEDIUM [Fix: zeroae/zae-limiter@481ce44](https://github.com/zeroae/zae-limiter/commit/481ce44d818d66e31d8837bc48519660ce4c267f)

CVE-2026-27695 is a medium-severity (CVSS 4.3) CWE-770 vulnerability in zae-limiter. A fix is available for zae-limiter — see the affected versions and patch details below.

zae-limiter: DynamoDB hot partition throttling enables per-entity Denial of Service

Also known as[GHSA-76rv-2r9v-c5m6](/vulnerability/GHSA-76rv-2r9v-c5m6)PYSEC-2026-3434

Published

Feb 25, 2026

Updated

Oct 28, 2026

Affected

1 pkg

Patched

1 / 1

Exploits

None indexed

Exploitation data as of Nov 6, 2026 · OSV.dev, NVD, FIRST.org (EPSS)

## Exploitation Status

### No confirmed exploitation observed yet

-   CISA’s own triage has not observed active exploitation or public proof-of-concept code for this CVE as of its last assessment.

Exploitation and automatability from CISA’s SSVC triage for CVE-2026-27695.

## EPSS Exploitation Probability

[via FIRST.org ↗](https://www.first.org/epss/)

0.3%probability of exploitation in next 30 days

Lower Risk0.00%

Lower risk than most CVEs19th percentile — riskier than 19% of all scored CVEsHighest risk

0.00%0.30%0.60%0.90%0.1%0.3%May 26Sep 26Nov 26

Probability of exploitation in the next 30 days, from [FIRST.org EPSS](https://www.first.org/epss/).

## How urgent is this, really

## Where this sits among everything scored

## Real-World Exposure

1 pkg affected

🐍`zae-limiter`

Real-time download stats are indexed for npm and PyPI packages. This vulnerability affects PyPI packages — download data is not available via public APIs for these ecosystems.

## Description

### Summary

All rate limit buckets for a single entity share the same DynamoDB partition key (`namespace/ENTITY#{id}`). A high-traffic entity can exceed DynamoDB's per-partition throughput limits (~1,000 WCU/sec), causing throttling that degrades service for that entity — and potentially co-located entities in the same partition.

### Details

Each `acquire()` call performs a `TransactWriteItems` (or `UpdateItem` in speculative mode) against items sharing the same partition key. For cascade entities, this doubles to 2-4 writes per request (child + parent). At sustained rates above ~500 req/sec for a single entity, DynamoDB's adaptive capacity may not redistribute fast enough, causing `ProvisionedThroughputExceededException`.

The library has no built-in mitigation:

-   No partition key sharding/salting
-   No write coalescing or batching
-   No client-side admission control before hitting DynamoDB
-   `RateLimiterUnavailable` is raised but the caller has already been delayed

### Impact

-   **Availability**: High-traffic entities experience elevated latency and rejected requests beyond what their rate limits specify
-   **Fairness**: Other entities sharing the same DynamoDB partition may experience collateral throttling
-   **Multi-tenant risk**: In a shared LLM proxy scenario, one tenant's burst traffic could degrade service for others

### Reproduction

1.  Create an entity with high rate limits (e.g., 100,000 rpm)
2.  Send sustained traffic at 1,000+ req/sec to a single entity
3.  Observe DynamoDB `ThrottledRequests` CloudWatch metric increasing
4.  Observe `acquire()` latency spikes and `RateLimiterUnavailable` exceptions

### Remediation Design: Pre-Shard Buckets

-   Move buckets to `PK={ns}/BUCKET#{entity}#{resource}#{shard}, SK=#STATE` — one partition per (entity, resource, shard)
-   Auto-inject `wcu:1000` reserved limit on every bucket — tracks DynamoDB partition write pressure in-band (name may change during implementation)
-   Shard doubling (1→2→4→8) triggered by client on `wcu` exhaustion or proactively by aggregator
-   Shard 0 at suffix `#0` is source of truth for `shard_count`. Aggregator propagates to other shards
-   Original limits stored on bucket, effective limits derived: `original / shard_count`. Infrastructure limits (`wcu`) not divided
-   Shard selection: random/round-robin. On application limit exhaustion, retry on another shard (max 2 retries)
-   Lazy shard creation on first access
-   Bucket discovery via GSI3 (KEYS\_ONLY) + BatchGetItem. GSI2 for resource aggregation unchanged
-   Cascade: parent unaware, protected by own `wcu`
-   Aggregator: parse new PK format, key by shard\_id, effective limits for refill, filter `wcu` from snapshots
-   Clean break migration: schema version bump, old buckets ignored, new buckets created on first access
-   **$0.625/M preserved on hot path**

## Affected Packages

1 total 1 fixed

Ecosystem

Package

Vulnerable range

Fix

🐍PyPI

`zae-limiter` 

all versions

0.10.1`pip install --upgrade 'zae-limiter==0.10.1'`

## Affected Products

1 product · 1 configurations

Application

`zae-limiter`zeroae

< 0.10.1

range

## Detection & mitigation playbook

Open-source dependency

1.  ### Detect
    
    Scan your dependency tree (package-lock.json, pnpm-lock.yaml, requirements.txt, go.sum, etc.) for zae-limiter, including transitive dependencies — a direct dependency you never call can still pull in a vulnerable version.
    
2.  ### Fix
    
    Update zae-limiter to 0.10.1 or later, then make sure no transitive (indirect) dependency still pins the vulnerable range — O3 confirms CVE-2026-27695 is resolved across your whole dependency graph.
    
3.  ### Workarounds
    
    Cap what an attacker can consume: apply request size, rate and timeout limits in front of the affected component, and run it with memory and CPU limits so exhaustion degrades one worker rather than the whole service.
    

## Frequently Asked Questions

\## Summary All rate limit buckets for a single entity share the same DynamoDB partition key (\`namespace/ENTITY#{id}\`). A high-traffic entity can exceed DynamoDB's per-partition throughput limits (~1,000 WCU/sec), causing throttling that degrades service for that entity — and potentially co-located entities in the same partition. ## Details Each \`acquire()\` call performs a \`TransactWriteItems\` (or \`UpdateItem\` in speculative mode) against items sharing the same partition key. For cascade entities, this doubles to 2-4 writes per request (child + parent). At sustained rates above ~500 req/sec

O3 Security · Impact-Aware SCA

### Is CVE-2026-27695 in your dependencies?

Find it across PyPI, including transitive dependencies.

[Scan my dependencies](/book-demo) [How O3 SCA works](/impact-aware-sca)