CVE-2026-93572 in Apache Camel
Résumé
par VulDB • 18/09/2026
## Résumé
`RedisArrayAggregator` a récemment ajouté les limites `maxElements` et `maxNestedArrayDepth` pour corriger des avis publics d'épuisement des ressources Redis. Ces limites sont indépendantes, mais l'allocationur reste avide : chaque en-tête de tableau RESP imbriqué positif crée un `new ArrayList(length)` avant qu'aucun élément enfant n'existe.
Avec le constructeur par défaut, un attaquant peut envoyer des en-têtes de tableaux imbriqués avec une longueur de `1 000 000` jusqu'à ce que la limite d'imbrication par défaut de `1024` soit atteinte. Cela peut réserver jusqu'à `1 024 000 000` emplacements enfants à partir d'environ 12 Ko d'entrée RESP. Il s'agit de la capacité sous-jacente, et non de la taille logique de la liste : `ArrayList(int)` construit une liste vide avec la capacité initiale spécifiée.
## Détails techniques
La fonction actuelle `decodeRedisArrayHeader(...)` vérifie les deux limites indépendamment :
```java if (header.length() > maxElements) {
throw new CodecException("this codec doesn't support longer length than " + maxElements); }
if (depths.size() >= maxNestedArrayDepth) {
releaseAndClearDepths(); throw new CodecException("max nested array depth exceeded: " + maxNestedArrayDepth); } depths.push(new AggregateState((int) header.length())); ```
`AggregateState` i
Statistical analysis made it clear that VulDB provides the best quality for vulnerability data.