Data-Centric Algorithmic Complexity Attacks

• Data-centric algorithmic complexity attacks are techniques where adversarial data forces algorithms into their pathological worst-case behavior, causing CPU, memory, or throughput failures.
• They manifest across systems such as web servers, DNSSEC, and learned database components by exploiting inputs like regexes, hash keys, and adversarial inserts to overload processing.
• Mitigations include algorithmic hardening, load balancing, and rate limiting, yet challenges remain in balancing performance and security across diverse attack surfaces.

Data-centric algorithmic complexity attacks are attacks in which adversarially chosen data force an algorithm, protocol, or learned component to execute along a pathological worst-case path. The attack surface is not primarily memory corruption or volumetric traffic, but attacker-controlled values, structures, records, or update sequences: strings that trigger catastrophic backtracking, keys that collide, DNSSEC record sets that induce exhaustive validation, poisoned tuples that distort learned cardinality estimators, or insertion patterns that drive learned indexes into repeated splits and retraining. The common predicate is a large asymmetry between typical and worst-case cost, which can translate into low-volume CPU-based denial of service, memory amplification, or severe end-to-end slowdown in downstream execution plans (Bhuiyan et al., 2022, Heftrig et al., 2024, Li et al., 10 Jul 2025).

1. Formal definition and computational model

Algorithmic complexity vulnerabilities are security problems that allow an attacker to craft inputs that push an algorithm from its typical average-case behavior into pathological worst-case behavior. In the web-server setting, this enables low-volume, asymmetric, CPU-based denial-of-service, where a single attacker with modest bandwidth can degrade service for many users. More generally, the attacker’s objective is to maximize a resource metric under input control, whether that metric is CPU time, executed instructions, memory consumption, or induced downstream work such as optimizer cost inflation (Bhuiyan et al., 2022, Petsios et al., 2017).

A standard formalization distinguishes average-case from worst-case behavior. For input size $n$ and specific input $x$,

$$T_{avg}(n) = \mathbb{E}_{x \in \mathcal{X}_n}[T(n, x)], \qquad T_{worst}(n) = \max_{x \in \mathcal{X}_n} T(n, x).$$

In the notation used for resource-guided fuzzing,

$$T_w(n) = \max_{x \in \Sigma^n} T(x), \qquad E[T(n)] = \mathbb{E}_{x \sim D}[T(x)].$$

The exploitable regime is the one in which $T_{worst}(n) \gg T_{avg}(n)$, for example when typical behavior is linear but crafted data induce quadratic or exponential work (Bhuiyan et al., 2022, Petsios et al., 2017).

This definition extends beyond classical software libraries. In learned systems, the relevant “input” may be the training database, a poisoned subset of tuples, or an online insertion sequence. The resulting worst case is then expressed not only as direct CPU cost, but also as model error that compels a downstream system to execute a more expensive plan or maintenance path. A learned cardinality estimator trained on stale or drifted data may induce worst-case query plans; a dynamic learned index may be driven into repeated expansions, sideways splits, or retraining storms (Li et al., 10 Jul 2025, Yang et al., 2024).

2. Attack surfaces and data patterns

The data-centric view is best understood through the kinds of attacker-controlled structures that trigger worst-case behavior.

Domain	Attacker-controlled data	Pathological mechanism
Web and language runtimes	regex strings, hash keys, nested parse structures	catastrophic backtracking, collision chains, parser worst-case behavior
DNSSEC validation	colliding DNSKEYs, many RRSIGs, many DS hashes	exhaustive key-signature and key-digest cross-products
Learned database components	tuple drifts, poisoning keys, adversarial inserts	Q-error inflation, wider local search, retrain and split cascades

In application stacks, the canonical examples are ReDoS, hash-table collision attacks, parser-induced worst-case behavior, and adversarial serialization. The web-server study explicitly lists specially crafted regex inputs, adversarial keys causing hash-table collisions, and deep or nested parse structures as examples of data-centric algorithmic complexity attacks. The same synthesis notes the asymptotic signatures that make these attacks useful: expected $O(1)$ hash operations degrading to $O(n)$ per operation and even $O(n^2)$ overall, or problematic regexes with worst-case exponential backtracking such as $T_{worst}(n) \in O(2^n)$ (Bhuiyan et al., 2022).

DNSSEC provides a protocol-level instance of the same idea. KeyTrap exploits the fact that resolvers are expected to try all candidate keys matching an RRSIG’s signer’s name, algorithm, and key tag, and to try all signatures covering an RRset until a valid one is found. By crafting many DNSKEYs that collide on the same $(\text{name}, \text{algorithm}, \text{key tag})$ triple, and many RRSIGs or DS digests referencing that triple, an attacker converts one response into a multiplicative work graph over keys, signatures, algorithms, and hashes (Heftrig et al., 2024).

In learned database systems, the data-centric surface shifts from request payloads to data distributions and update sequences. The poisoning attack on recursive model indexes exploits the fact that the model is trained on the cumulative distribution function, so one inserted poisoning key has a cascading effect on the ranks of all legitimate keys to its right. The attack on learned cardinality estimators instead modifies a small number of tuples so that estimators trained on the poisoned database later mispredict cardinalities on the clean database. Dynamic attacks on ALEX exploit gapped arrays, adaptive key-space partitioning, and catastrophic-cost heuristics by inserting duplicates or dense consecutive keys that maximize expansions, pointer-array doubling, or retraining (Kornaropoulos et al., 2020, Li et al., 10 Jul 2025, Yang et al., 2024).

3. Quantification and analytical frameworks

Because data-centric attacks are often low-volume and highly asymmetric, their evaluation commonly uses observer-centric metrics rather than packet counts alone. In the cloud web-server study, throughput is $x$0 and expected throughput is $x$1. The paper defines Attacker’s gain as

$x$2

where $x$3 interpolates expected throughput and $x$4 interpolates observed throughput. It also defines throttled time at fraction $x$5 of expected throughput as

$x$6

These metrics capture cumulative user-visible throughput shortfall and the duration of severe service degradation, rather than only instantaneous CPU utilization (Bhuiyan et al., 2022).

KeyTrap makes the multiplicative structure explicit. With $x$7 colliding keys for algorithm $x$8, $x$9 signatures for RRset $$T_{avg}(n) = \mathbb{E}_{x \in \mathcal{X}_n}[T(n, x)], \qquad T_{worst}(n) = \max_{x \in \mathcal{X}_n} T(n, x).$$0, $$T_{avg}(n) = \mathbb{E}_{x \in \mathcal{X}_n}[T(n, x)], \qquad T_{worst}(n) = \max_{x \in \mathcal{X}_n} T(n, x).$$1 DS records, average verification cost $$T_{avg}(n) = \mathbb{E}_{x \in \mathcal{X}_n}[T(n, x)], \qquad T_{worst}(n) = \max_{x \in \mathcal{X}_n} T(n, x).$$2, average digest-computation cost $$T_{avg}(n) = \mathbb{E}_{x \in \mathcal{X}_n}[T(n, x)], \qquad T_{worst}(n) = \max_{x \in \mathcal{X}_n} T(n, x).$$3, and retry/network overhead terms, total validation work can be written as

$$T_{avg}(n) = \mathbb{E}_{x \in \mathcal{X}_n}[T(n, x)], \qquad T_{worst}(n) = \max_{x \in \mathcal{X}_n} T(n, x).$$4

The critical terms are the cross-products $$T_{avg}(n) = \mathbb{E}_{x \in \mathcal{X}_n}[T(n, x)], \qquad T_{worst}(n) = \max_{x \in \mathcal{X}_n} T(n, x).$$5 and $$T_{avg}(n) = \mathbb{E}_{x \in \mathcal{X}_n}[T(n, x)], \qquad T_{worst}(n) = \max_{x \in \mathcal{X}_n} T(n, x).$$6, which are created by “try all keys” and “try all signatures” behavior (Heftrig et al., 2024).

For learned cardinality estimators, the central metric is Q-error. For query $$T_{avg}(n) = \mathbb{E}_{x \in \mathcal{X}_n}[T(n, x)], \qquad T_{worst}(n) = \max_{x \in \mathcal{X}_n} T(n, x).$$7,

$$T_{avg}(n) = \mathbb{E}_{x \in \mathcal{X}_n}[T(n, x)], \qquad T_{worst}(n) = \max_{x \in \mathcal{X}_n} T(n, x).$$8

with percentile Q-error used to summarize the tail of the error distribution. The attacker seeks to maximize a percentile such as $$T_{avg}(n) = \mathbb{E}_{x \in \mathcal{X}_n}[T(n, x)], \qquad T_{worst}(n) = \max_{x \in \mathcal{X}_n} T(n, x).$$9 under a tuple-modification budget. The paper reformulates the attack using a surrogate oracle on the poisoned training database and proves that the optimal DACA problem is NP-Hard even in the delete-only case. It then shows that the delete-only objective is supermodular, the insert-only objective is modular, and that a greedy polynomial-time algorithm obtains a $$T_w(n) = \max_{x \in \Sigma^n} T(x), \qquad E[T(n)] = \mathbb{E}_{x \sim D}[T(x)].$$0-approximation under the stated conditions (Li et al., 10 Jul 2025).

For learned indexes, the analytical objects are different but analogous. The poisoning attack on CDF-trained linear regressors uses the closed-form least-squares solution

$$T_w(n) = \max_{x \in \Sigma^n} T(x), \qquad E[T(n)] = \mathbb{E}_{x \sim D}[T(x)].$$1

and observes that poisoning reshapes the training labels because ranks are induced by global sort order. The dynamic ALEX attack uses a Multiple-Choice Knapsack formulation to allocate a bounded number of adversarial insertions across data nodes so as to maximize post-expansion free space. Duplicate-key attacks on internal nodes induce exponential pointer-array growth, with memory after $$T_w(n) = \max_{x \in \Sigma^n} T(x), \qquad E[T(n)] = \mathbb{E}_{x \sim D}[T(x)].$$2 doubling events given by $$T_w(n) = \max_{x \in \Sigma^n} T(x), \qquad E[T(n)] = \mathbb{E}_{x \sim D}[T(x)].$$3 (Kornaropoulos et al., 2020, Yang et al., 2024).

4. Empirical manifestations across systems

In cloud web services, the observed effect is not uniform across architectures. Under a local setup with attack tuple $$T_w(n) = \max_{x \in \Sigma^n} T(x), \qquad E[T(n)] = \mathbb{E}_{x \sim D}[T(x)].$$4, Attacker’s gain was reported as 9 for Tomcat, 0 for Apache, 1,276 for Django, 61 for Go, and 2,603 for Node.js. Throttled time at $$T_w(n) = \max_{x \in \Sigma^n} T(x), \qquad E[T(n)] = \mathbb{E}_{x \sim D}[T(x)].$$5 was 26 s for Node.js and 10 s for Django, while Tomcat, Apache, and Go remained at 0 s. Median latency for Node.js rose from about 1.7 ms to about 16.1 s as payloads increased to 1 s, and the study concludes that sub-second slowdowns such as 50–100 ms can be weaponized in cloud PaaS settings; a “$$T_w(n) = \max_{x \in \Sigma^n} T(x), \qquad E[T(n)] = \mathbb{E}_{x \sim D}[T(x)].$$6 s” slowdown criterion is too high. The same study also stresses that event-based systems are not uniformly worse: they tend to recover faster in some scenarios but also suffer the worst performance degradation overall, and Apache may perform worse than event-based systems in certain setups (Bhuiyan et al., 2022).

In DNSSEC, KeyTrap is a single-packet realization of the same principle. A response carrying 582 colliding DNSKEYs and 340 RRSIGs for ECDSA P-384 caused a spike from roughly 811,500 CPU instructions for a benign signed lookup to roughly $$T_w(n) = \max_{x \in \Sigma^n} T(x), \qquad E[T(n)] = \mathbb{E}_{x \sim D}[T(x)].$$7 instructions for one KeyTrap resolution in Unbound, approximately a $$T_w(n) = \max_{x \in \Sigma^n} T(x), \qquad E[T(n)] = \mathbb{E}_{x \sim D}[T(x)].$$8 increase. Reported stalls for one packet included about 1,014 s for Unbound, about 58,632 s for Bind9, about 186 s for Akamai CacheServe, about 170 s for PowerDNS Recursor, about 184 s for Stubby, and about 51 s for Knot Resolver. The paper also reports a HashTrap variant with up to 1,357 DS records and 1,357 DNSKEYs, yielding 1,841,449 digest computations per request (Heftrig et al., 2024).

Learned database systems exhibit a different but equally severe failure mode. For learned cardinality estimators, modifying only about 0.8% of training tuples on IMDB-JOB and 1.2% on STATS-CEB raises 90th-percentile Q-error by three orders of magnitude and inflates end-to-end execution time by up to $$T_w(n) = \max_{x \in \Sigma^n} T(x), \qquad E[T(n)] = \mathbb{E}_{x \sim D}[T(x)].$$9. The attack applies across query-driven, data-driven, and hybrid estimators, including LWNN, MSCN, NeuroCard, FactorJoin, ALECE, and RobustMSCN. The paper links these estimation failures to concrete algorithmic complexity inflation in query planning: for IMDB-JOB Q60, a clean plan uses hash joins with time complexity $T_{worst}(n) \gg T_{avg}(n)$0, whereas the attacked estimator pushes the optimizer to index nested-loop joins, degrading complexity to $T_{worst}(n) \gg T_{avg}(n)$1 and increasing execution time by $T_{worst}(n) \gg T_{avg}(n)$2 seconds (Li et al., 10 Jul 2025).

Dynamic learned indexes display both memory and time ACAs. One study on ALEX reports three attacks: a knapsack-optimized space ACA on data nodes, a duplicate-key-triggered space ACA on internal nodes, and a time ACA based on pathological insertions. It reports out-of-memory conditions on all tested RAM sizes from 64 GB to 384 GB with only about 423–692 duplicate insertions, and throughput degradation of 31×–1,641× for a modified ALEX under white-box or gray-box attacks. By contrast, a later unified evaluation finds that static poisoning under bulk-loaded ALEX yields only 0.855×–1.029× lookup slowdown, whereas dynamic ACA produces peak lookup slowdowns of about 2.7×–2.8× and sustained degradation over insertion rounds. This suggests that static poisoning and dynamic ACA are distinct threat models, and that attack magnitude is highly dependent on the interaction among dataset distribution, locality of structural damage, and the metric being reported (Yang et al., 2024, Jue, 27 Apr 2026).

The earlier poisoning study on learned indexes provides a complementary build-time attack surface. On a two-stage recursive model index, poisoning increased average error by up to about 150× on uniform keys and about 300× on log-normal keys, while individual second-stage models reached about 1,000× and about 3,000× error increases respectively. On real data, such as Miami-Dade salaries and OpenStreetMap latitudes, reported RMI ratio-loss increases ranged from 4× to 24× (Kornaropoulos et al., 2020).

5. Discovery, reproduction, and experimental methodology

The discovery of data-centric algorithmic complexity attacks has increasingly been systematized. SlowFuzz formulates vulnerability discovery as an optimization problem over inputs, using a resource-usage-guided evolutionary search to maximize a proxy for executed instructions. It instruments targets with SanitizerCoverage edge counters, treats higher resource usage as fitness, and uses $T_{worst}(n) \gg T_{avg}(n)$3-greedy prioritization over mutation operators and byte offsets. Across domains, it produced representative worst-case inputs: 6,201 valid slow regexes for PCRE, including 765 super-linear and 78 exponential-time regexes within 10-character patterns; 20 collisions against PHP’s DJBX33A hash table after roughly 40 hours on one CPU; and about $T_{worst}(n) \gg T_{avg}(n)$4 slowdown on crafted bzip2 files (Petsios et al., 2017).

HotFuzz moves the same idea into object-rich Java code. It performs guided micro-fuzzing one method at a time, evolving arbitrary Java objects with a genetic algorithm and measuring runtime with a modified HotSpot VM called the Eye. The framework uses Small Recursive Instantiation to derive seed inputs, then synthesizes standalone witness programs and validates them on an unmodified JVM, requiring wall-clock time at least $T_{worst}(n) \gg T_{avg}(n)$5 s and CPU-bound execution. In its evaluation, HotFuzz discovered 158 previously unknown AC vulnerabilities in real-world software, confirmed 5 intended AC vulnerabilities in the DARPA STAC corpus, and reported that SRI outperformed identity-value seeds in witness detection across the JRE, Maven libraries, and STAC artifacts (Blair et al., 2020).

Experimental methodology in deployment studies has also become more data-centric. The web-server study does not directly exploit real ReDoS or parser vulnerabilities in its cloud-scale experiments; instead, it uses modular exponentiation as an ACV surrogate and calibrates the exponent so that each request consumes a target CPU time $T_{worst}(n) \gg T_{avg}(n)$6 milliseconds on each server-platform pair. This calibration permits controlled comparison across AWS Elastic Beanstalk, Azure Web Apps, Heroku, and DigitalOcean App Platform, using observer-side throughput, latency, Attacker’s gain, and throttled time as the main outputs (Bhuiyan et al., 2022).

Database-oriented attacks require their own measurement pipelines. The learned-cardinality-estimator attack computes per-tuple joint weights $T_{worst}(n) \gg T_{avg}(n)$7 from materialized query results using GROUP BY, then performs greedy selection of tuple insertions, deletions, or duplicates under budget $T_{worst}(n) \gg T_{avg}(n)$8. The stated time complexity is $T_{worst}(n) \gg T_{avg}(n)$9, combining the GROUP BY phase over result materializations with $O(1)$0 greedy selections across $O(1)$1 tuples and $O(1)$2 test queries. Learned-index poisoning likewise relies on efficient updates over candidate poisoning points or per-node scenarios rather than exhaustive retraining from scratch (Li et al., 10 Jul 2025, Kornaropoulos et al., 2020).

6. Mitigation, trade-offs, and unresolved issues

Mitigation strategies are necessarily domain-specific, but they share a common theme: restrict the attacker’s ability to enlarge the work graph induced by data. In cloud services, the web-server study finds that increasing instance capabilities and adding parallel instances behind a load balancer reduce Attacker’s gain. For event-driven servers, increasing preforked workers via the Node.js Cluster API or Gunicorn workers significantly reduces Attacker’s gain; on AWS, Node.js with 20 workers reduced Attacker’s gain by 2,222 versus default. The cost is higher monthly expenditure and increased latency in benign conditions, with reported non-attack latency increases of about 30% in Azure and about 59% in DigitalOcean for maximum tested worker counts. The same study emphasizes aggressive rate limiting, since small payloads at higher bandwidth produced large degradation and some platforms enforced no rate limits (Bhuiyan et al., 2022).

Algorithmic hardening remains the most direct defense where the vulnerable primitive is known. The surveyed recommendations include linear-time regex constructs, avoidance of nested quantifiers, selective memoization or non-backtracking engines, randomized hashing, parser hardening against nested structures, depth limits, and avoiding unsafe or overly flexible deserialization. These measures do not eliminate the broader class, but they reduce the worst-case gap that makes the attack profitable (Bhuiyan et al., 2022, Petsios et al., 2017, Blair et al., 2020).

In DNSSEC, mitigations had to address a protocol-level tension between availability and worst-case validation work. Reported vendor patches include caps on failed validations, caps on key-tag collisions such as “$O(1)$3 colliding keys per tag,” and caps on validations for ANY requests such as “$O(1)$4 validations per ANY request.” Architectural recommendations include de-prioritizing heavy requests, separate threads for OS-buffer draining and cache serving, load-aware scheduling, fail-fast strategies prioritizing supported algorithms, and per-response or per-resolution quotas on keys, signatures, and DS records. The paper explicitly identifies “try all keys” and “try all signatures” guidance as a root cause, making KeyTrap a standards-level as well as an implementation-level problem (Heftrig et al., 2024).

For learned estimators, the identified countermeasures are ensembling of heterogeneous estimators and calibrated Gaussian noise injection at inference. Ensembling trains an auxiliary MLP over LWNN, MSCN, NeuroCard, FactorJoin, ALECE, and RobustMSCN outputs; it improves robustness in many settings but does not universally dominate constituent models. Noise injection uses

$O(1)$5

and can reduce tail Q-errors by up to three orders of magnitude in some settings, though excessive noise with $O(1)$6 collapses accuracy. Continuous drift monitoring, tail-focused validation on current data, auditing of unusual tuple-level changes, and guardrails on worst-case Q-error thresholds are presented as deployment necessities rather than optional refinements (Li et al., 10 Jul 2025).

Learned indexes expose a further misconception: poisoning before bulk load and dynamic ACA during operation are not interchangeable. Static poisoning was found to have minimal effect on lookup performance in one bulk-loaded ALEX evaluation, while dynamic ACA that sculpts insertion locality produced sustained 2–2.8× lookup slowdowns. Earlier work, however, showed far larger degradation and even out-of-memory conditions under different settings. A plausible implication is that robustness claims for learned indexes cannot be stated independently of the threat model, data distribution, and measurement protocol; localized structural damage may or may not propagate into large global throughput changes, depending on how broadly adversarial inserts cover the clean-rank domain (Jue, 27 Apr 2026, Yang et al., 2024).

Open problems remain broad. Reported future directions include integrating dynamic resource control into event-driven servers, evaluating provider load balancers and Apache MPM configurations under ACVs, extending database studies to autoscaling and cost-performance optimization under adversarial load, incorporating real ACVs such as ReDoS and hash collisions into cloud-scale experiments, broadening learned-index studies beyond ALEX, and developing principled frameworks for tuning defenses such as ensemble weights, noise intensity, or insert-path guardrails. Across all of these threads, the persistent lesson is that average-case optimization without explicit worst-case budgeting leaves a system open to attacks in which the data itself determines the shape and size of the computation (Bhuiyan et al., 2022, Li et al., 10 Jul 2025, Jue, 27 Apr 2026).