{"id":"3343167c-fed1-42b6-b1bd-73b9d1a093d8","arxiv_id":"2412.13879","paper_version":4,"verdict":"CONDITIONAL","confidence":"MODERATE","novelty_score":6.0,"correctness_risk":"medium","formal_verification":"none","parameter_count":4,"one_line_summary":"AutoDoS automatically builds a prompt that makes black-box LLMs generate maximum-length responses, consuming disproportionate compute and degrading service performance.","lead":"This paper presents AutoDoS, a black-box attack that automatically constructs a tree of sub-questions and iteratively optimizes a prompt to force large language models to generate up to their maximum output length. The attack claims to amplify response latency by over 250x and to bypass common input and output defenses.","discovery_kind":"new_application","skeptic_critique":{"model":"deepseek-v4-flash","headline":"No naive 'write-long' baseline: the Appendix G prompt explicitly demands 400 words per sub-question, so the reported 2000%/250x amplification may be plain instruction-following rather than the proposed DoS Attack Tree or iterative optimization.","rationale":"The paper demonstrates a plausible phenomenon: explicit prompts can make LLMs generate near-maximum-length outputs, and the Appendix G prompt is a concrete, testable instance. I give credit for publishing the full attack prompt and a code link, which makes independent verification feasible. However, the single most load-bearing issue is attribution: the headline 2000% output-length extension and 250x latency amplification may be caused by the prompt's explicit 'at least 400 words per sub-question' instruction rather than by the proposed DoS Attack Tree expansion, transferability-driven iterative optimization, or Length Trojan. The paper's ablations remove entire modules (DoS tree, iteration, Trojan) but do not control for the total requested output length, so they conflate mechanism effectiveness with instruction-following. The reader's weakest_assumption (Length Trojan) is related but not identical; Table 6's length sweep could also be explained by ordinary compliance with the stated word count. The transferability inconsistencies the reader noted are real but secondary because the main DoS effect still appears for most model-prompt pairs. The missing naive baseline is the most destructive to the paper's technical claim, yet it is easily fixable, which supports keeping the verdict conditional rather than moving to reject. If the flat baseline matches AutoDoS, the paper reduces to 'LLMs comply with explicit length requests', which would require reframing the contribution; if it does not, the proposed components earn their place.","tokens_in":36173,"tokens_out":10615,"duration_ms":102399,"concrete_test":"Run AutoDoS and a flat baseline on the same 11 models with identical decoding settings (temperature 0.5, same max_tokens windows). The flat baseline consists of the same 25 sub-questions from the AutoDoS prompt with the single instruction: 'Answer each of the following 25 questions with at least 400 words, in full detail, and do not stop until all are answered.' Compare average output length and time. If the flat baseline reaches within 10% of AutoDoS's output length on a majority of models, the tree/optimization/Length Trojan are not the causal driver; if it falls far short, the concern is resolved.","verdict_should_be":"UNCHANGED","load_bearing_attack":"The central quantitative claims (output length extended by 2000%, latency amplified by over 250x) are established only against short benign queries and against P-DoS prompts; the paper never compares AutoDoS to a flat prompt that requests the same total output length without the DoS Attack Tree, iterative optimization, or Length Trojan. The worked example in Appendix G is itself an explicit instruction: 'Each question requires a response of at least 400 words... generate lengthy, detailed responses for each sub-question.' A straightforward baseline that prepends this single length/detail instruction to the 25 sub-questions and asks the model not to stop would isolate whether the tree/optimization contribute anything. The Appendix A ablations remove whole modules, but they do not hold the explicit total-length request constant, so they cannot rule out that the effect is just instruction-following. If the flat baseline reaches the same output ceiling, the paper's proposed mechanism is not the cause of the DoS effect, and the Length Trojan 'sweet spot' in Table 6 would be reinterpreted as ordinary compliance with the stated length, not filter evasion.","agreement_with_reader":"partial"},"referee_report":{"model":"deepseek-v4-flash","summary":"The paper proposes AutoDoS, a black-box LLM denial-of-service attack that constructs a 'DoS Attack Tree' from a seed question, iteratively optimizes an assist prompt via a target/judge model loop (Eqs. 6-8), and wraps the prompt with a 'Length Trojan' that states a short word-count requirement while also demanding lengthy, never-stopping answers. Experiments are reported over 11 models from six families, with claimed output-length extension of 2000%, latency amplification over 250x, GPU-memory increases, transferability across models, and stealth against perplexity, self-reflection, and similarity defenses. The authors provide a public code repository and a server-simulation study of resource consumption.","tokens_in":36366,"tokens_out":7758,"duration_ms":61283,"significance":"If the claims were fully supported, AutoDoS would represent a practical black-box DoS threat: a single prompt could push models to their output-window limits, multiplying per-request compute. The paper has notable strengths: a wide multi-model evaluation, a public code release, a server-resource simulation, and a plausible decomposition mechanism. However, the evidence is undermined by an explicit length instruction in the only disclosed attack example (Appendix G), inconsistent headline numbers, non-operationalizable optimization equations, and visible transferability failures. The central contribution is therefore not yet established; the observed effect may be plain instruction-following rather than the proposed tree/optimization/trojan mechanism.","major_comments":[{"comment":"The only disclosed AutoDoS example (Appendix G) explicitly instructs the model: 'Each question requires a response of at least 400 words' and 'generate lengthy, detailed responses for each sub-question', with 25 sub-questions. A flat baseline that requests the same total output length without the DoS Attack Tree, iterative optimization, or Length Trojan is never tested. The ablation studies in Appendix A remove whole modules but do not hold the explicit total-length request constant, so they cannot rule out the trivial explanation that the model is simply following the stated length instruction. Please add a baseline that keeps the same total-length request while stripping the tree and trojan components; without it, the 2000%/250x claims conflate instruction-following with the novel mechanism.","section":"§4.2, Appendix A, Appendix G"},{"comment":"The headline numbers are internally inconsistent. The abstract and introduction state 'extends the output length by 2000%' (20x), but §4.2.1 says 'more than > 7x' and '8–10x' (700–1000%). Similarly, the abstract's 'over 250x' latency amplification is not supported by Table 2: the per-model latency ratios are approximately 105x (Qwen), 104x (Llama), 251x (Ministral), and 20x (Gemma). The 250x figure appears to be the single best model, not an aggregate. Please reconcile these numbers and report raw values with a clear definition of the reported aggregation.","section":"Abstract, Introduction, §4.2.1, Table 2"},{"comment":"The core optimization loop is not operationalizable. Eq. (6) defines F_S as 'Rel(F,B) − λ·|F|' without specifying the semantic relevance function Rel or its range; minimizing this expression does not correspond to any described compression step. Eq. (7) defines R_a as a ratio of set-cardinalities, but the coverage sets L(T_i) and the extraction operator L_F(F) are never defined. No values for K, s, or λ are given outside the ablations, and the termination condition R_a > 0.95 in Algorithm 1 is not reported as having been met. The method section must provide concrete definitions, pseudocode, and parameter values so the procedure can be reproduced.","section":"§3.2, Eq. (6), Eq. (7), Algorithm 1"},{"comment":"The claim that 'AutoDoS successfully pushed 90% of the target model close to their performance ceilings' is contradicted by the data. In Table 3, the Llama8B row shows GPT4o-mini producing only 10 tokens and Ministral8B producing 1175 tokens; the DeepSeek row shows GPT4o at 9769, Qwen14B at 2019, and Qwen32B at 2671 tokens, all far below their respective 16k/8k ceilings. Section 4.4.1's statement that 'all experimental models reaching their performance ceilings' (for input-switching) is also not supported by Table 10, which contains many sub-ceiling entries. Please state the exact success criterion used to compute '90%' and report per-cell results without over-aggregation.","section":"§4.4.1, Table 3, Table 10"},{"comment":"The Length Trojan mechanism rests on an unverified premise. Appendix B, Eqs. (10)-(12), assumes the model's security filter estimates output length from the stated word-count requirement L_σ and allows generation only if the estimate is below a safety threshold, while the generation phase ignores L_σ because of 'detail' instructions. No evidence is provided that such a separate length-estimation filter exists in any target model. The observed '200–400 token sweet spot' in Table 6 is equally consistent with ordinary instruction-following (since the example prompt requests at least 400 words per sub-question). Please test the trojan against a model that enforces the stated length limit, or otherwise provide evidence that the posited filter mechanism is real rather than an artifact of prompt design.","section":"§3.3, Appendix B, Table 6"}],"minor_comments":[{"comment":"The definition of Π[i] as a sorted path uses a key that is itself a coverage set; the meaning of 'descending order based on key' when the key is a set is unclear and should be spelled out concretely.","section":"§3.1, Eq. (4)"},{"comment":"The text states that 'Normal user waiting time accounts for 12.0% of the total access time' and that total access times rise from 15.4 to 277.2 seconds, but none of these values appear in Table 2. Please clarify the simulation protocol and define how these percentages and totals are derived from the reported throughput/latency numbers.","section":"§4.3.2, Table 2"},{"comment":"The discussion of perplexity detection is confused: the text mentions a 'baseline of 0.41' and says AutoDoS scores are 'significantly higher', but 0.41 is the similarity score from Table 5, not a perplexity threshold. Please report actual perplexity values and thresholds, and separate the perplexity and similarity discussions.","section":"§4.4.2, Figure 5"},{"comment":"The code URL is inconsistent: the abstract and introduction give https://github.com/shuita2333/AutoDoS, while Appendix G gives https://github.com/Captain-zhangw/AutoDoS. Please unify the link and verify the repository is publicly accessible.","section":"Appendix G, Abstract"},{"comment":"No variance or error-bar information is provided for any experimental result. Since LLM outputs are stochastic and the paper's claims are quantitative, please report the number of independent runs and standard deviations (or confidence intervals) for the output-length and latency measurements.","section":"General"}],"recommendation":"major_revision","confidential_remarks":"The paper's dual-use nature is acknowledged by the authors themselves in Section 6 ('raising concerns that our methods could be exploited for malicious purposes'). The main concern is not ethical but scientific: the absence of a flat length-instruction baseline means the proposed mechanism may reduce to a trivial 'ask for a long answer' attack, which would substantially lower the novelty. The internal number inconsistencies (2000% vs 7-10x; 250x vs per-model ratios) are fixable with careful reporting. I recommend that the editor require a dedicated baseline experiment before any acceptance decision."},"author_rebuttal":null,"desk_editor":{"model":"deepseek-v4-flash","letter":"Colleague — this paper reports a black-box prompt-based DoS attack that pushes LLMs to their output-window limit. The effect is real: tell a model to answer 25 questions with at least 400 words each and repeat the instruction to itself, and it will generate a lot of tokens. But the paper's own example in Appendix G is exactly that prompt, and there is no baseline that simply requests the same total length without the DoS Attack Tree, iterative optimization, or Length Trojan. So the headline 250x latency and 2000% length numbers may be plain instruction-following, not evidence that the proposed machinery is doing the work. That is the central flaw, and it is fixable.\n\nWhat is new: the black-box setting, the combination of tree-structured prompt expansion, PAIR-style judge-guided iteration, and a length-deception wrapper, plus a defense evaluation across 11 models. Those are legitimate pieces, and the authors provide code and use public APIs, which helps reproducibility.\n\nSoft spots beyond the missing baseline: the numbers are internally inconsistent (Table 2 claims 10553% degradation while Section 4.3.2 says 25139%, and the abstract's 250x doesn't match the per-model figures in Table 3). Transferability is weaker than claimed: Table 3 includes pairs like Llama8B attacked by Qwen72B with only 10 tokens, and DeepSeek attacked by Qwen7B with 7055 tokens, undercutting the '90% success' statement. The algorithm is under-specified: Eqs. 6 and 7 define Rel(·) and S(P) only as vague optimization objectives, so the iterative process is not reproducible from the text. The Length Trojan story in Appendix B assumes the target model's safety filter estimates output length from the stated word count but then ignores that same word count during generation; that is plausible but untested. The 'sweet spot' at 200–400 tokens (Table 6) could be ordinary compliance with the explicit requested length, not filter evasion. Also, the abstract gives one GitHub URL and Appendix G another (shuita2333 vs Captain-zhangw).\n\nVerdict: this deserves a serious referee, because a cheap black-box way to amplify compute per request is a real operational concern. But it needs major revision: add a flat 'write-long' baseline that holds the explicit length/detail request fixed, clean up the inconsistent numbers, specify the optimization concretely, and report transferability honestly with error bars. As it stands, I would not rely on the quantitative claims.\n\nBring it to reading group if you want a case study in how a missing baseline can hollow out an attack paper. I would not cite it yet.","headline":"Real phenomenon, overclaimed mechanism: the black-box DoS attack works mostly because the prompt explicitly demands 400-word answers, and the paper never runs the obvious flat-baseline control.","tokens_in":36961,"tokens_out":4836,"would_cite":false,"duration_ms":44156,"reading_group":"maybe","serious_thinker":"yes","would_accept_peer_review":true},"rs_alignment":null,"lean_confirmation":null,"pith_extraction":{"msc":[],"pacs":[],"model":"deepseek-v4-flash","headline":"AutoDoS claims that a single black-box prompt can push any tested LLM to its output-window limit, amplifying latency by over 250x and enabling low-cost denial of service.","keywords":["LLM denial-of-service","black-box attack","prompt engineering","Length Trojan","DoS Attack Tree","resource exhaustion","transferability","output length amplification"],"falsifier":"Run the AutoDoS prompt against a model or API wrapper whose generation enforces the word count stated in the Trojan section, or that rejects prompts whose stated length contradicts the detailed instructions; if output length falls from the window maximum to roughly the stated limit, the Length Trojan is the load-bearing component.","tokens_in":35935,"feed_emoji":"🦀","tokens_out":7899,"duration_ms":66319,"temperature":0.7,"pith_summary":"The paper tries to show that denial-of-service against large language models can be done by a black-box attacker who only sends prompts. It introduces AutoDoS, which expands an ordinary question into a tree of many detailed sub-questions, iteratively refines an assist prompt so the attack transfers across models, and wraps everything in a Length Trojan that states a small word count while instructing detailed answers. In tests across eleven models, one prompt drives the model to generate until it hits its maximum output window, extending responses by roughly 2000% and service latency by over 250x, and in a simulated server eight parallel requests trigger a crash. If this is right, free and API-hosted LLM services face a low-cost DoS vector that existing input and output filters do not catch.","feed_headline":"One prompt makes an LLM hit its output cap and stall","feed_subtitle":"Black-box prompts stretch replies to the cap, slowing service 250x and crashing a simulated server with eight requests.","key_machinery":"The load-bearing objects are the DoS Attack Tree and the Length Trojan. The tree turns one question into many non-overlapping fine-grained sub-questions, pruned via lowest-common-ancestor backtracking, so the model has many reasons to keep writing; the iterative optimization loop uses a judge model's compressed feedback to make the assist prompt transfer across target models; and the Length Trojan splits the prompt into a Trojan Section that states a small word count, which deceives length-estimating filters, and an Attack Section that demands detailed answers and self-reminders to continue. Together they push generation to the model's output-window limit.","core_discovery":"AutoDoS constructs a DoS Attack Tree from an initial prompt, using Depth Backtracking and Breadth Expansion to produce many independent fine-grained sub-questions; a transferability-driven iterative loop, in which a judge model summarizes target feedback and an assist model rewrites the assist prompt, makes the single final prompt work across different target models; and the Length Trojan places a short word-count requirement before the detailed instructions so the model's security filter estimates a safe output length while generation follows the detail instructions and runs to the output window limit. The paper reports that this combination reaches the maximum output length on GPT-4o (16,384 tokens) and on most 8K-window models (8,192 tokens), degrades service latency by over 250x, consumes more than 16x graphics memory in a simulated server, and crashes with 8 parallel requests.","pith_inferences":["Editorial inference: the same tree-decomposition trick could be adapted to exhaust other metered LLM resources, such as tool-call loops, reasoning tokens, or image-generation steps, not just output length.","Editorial inference: the paper's numbers imply that per-token pricing and strict output caps, rather than content filtering, are the direct countermeasure, since the attack's power comes from letting generation run to the window limit.","Editorial inference: a testable extension would measure whether models trained to enforce instruction-consistency, or systems with a post-generation token-budget verifier, defeat the Length Trojan without changing the attack tree."],"forward_implications":["A single crafted prompt can push GPT-4o to its 16,384-token output cap and most tested open models to 8,192 tokens, an output-length increase the abstract quantifies as roughly 2000% over benign prompts.","Because the attack works across 11 models from 6 families with one prompt, a black-box attacker does not need model weights or training-data access.","In a simulated server, AutoDoS raised memory consumption by over 16x and crashed the server with only 8 parallel requests, while 64 benign requests used under half the memory.","Service latency degrades by more than 250x and throughput drops from about one request per minute to about 0.009 per minute under attack.","The Length Trojan keeps the prompts stealthy: they pass perplexity-based input filters, output self-monitoring, and compression-similarity detection in the paper's tests."],"supporting_citations":[{"why":"Defines the data-poisoning DoS baseline whose black-box failure motivates the method; AutoDoS is compared against its five prompt variants.","marker":"[Gao et al., 2024b]"},{"why":"Supplies the black-box iterative judge-and-feedback loop that AutoDoS adapts to optimize the assist prompt for length rather than jailbreaking.","marker":"[Chao et al., 2023]"},{"why":"Represents the white-box output-extension attack that AutoDoS aims to replace in black-box settings.","marker":"[Geiping et al., 2024]"},{"why":"Introduces sponge-example resource-exhaustion attacks on neural networks, the conceptual ancestor of LLM denial-of-service.","marker":"[Shumailov et al., 2021]"},{"why":"Provides the perplexity-based input-filter defense that AutoDoS claims to bypass with its low-perplexity prompts.","marker":"[Jain et al., 2023]"},{"why":"Another perplexity-based input defense cited in the defense setup; supports the claim that AutoDoS evades input detection.","marker":"[Alon and Kamfonas, 2023]"},{"why":"Supplies the offline lowest-common-ancestor algorithm used to prune the DoS Attack Tree so sub-questions stay independent.","marker":"[Tarjan, 1972]"},{"why":"Provides the Kolmogorov/NCD text-similarity detection method used to test whether AutoDoS prompts resemble typical requests.","marker":"[Peng et al., 2007]"}],"fun_headline_variants":["Black-box LLM DoS: one prompt maxes tokens, 250x latency","Single black-box prompt forces LLM to cap, crashes at 8 requests","AutoDoS: black-box attack uses one prompt to stall LLM service","One prompt DoS: black-box LLM hits output cap, slows service 250x","AutoDoS: one black-box prompt overloads LLM, 250x slower"],"cache_read_input_tokens":3200,"weakest_assumption_plain":"The attack stands on the target's safety filter checking only the stated word count in the prompt while the generation stage follows the detailed-instruction section, so if a model enforced the stated limit the amplification would collapse.","fun_headline_variants_meta":{"raw":{"variants":["Black-box LLM DoS: one prompt maxes tokens, 250x latency","Single black-box prompt forces LLM to cap, crashes at 8 requests","AutoDoS: black-box attack uses one prompt to stall LLM service","One prompt DoS: black-box LLM hits output cap, slows service 250x","AutoDoS: one black-box prompt overloads LLM, 250x slower"]},"model":"deepseek-v4-flash","effort":"low","cost_usd":0.001191,"raw_usage":{"total_tokens":4906,"prompt_tokens":925,"completion_tokens":3981,"prompt_tokens_details":{"cached_tokens":384},"prompt_cache_hit_tokens":384,"prompt_cache_miss_tokens":541,"completion_tokens_details":{"reasoning_tokens":3875}},"tokens_in":541,"tokens_out":3981,"duration_ms":27184,"temperature":1.0,"reasoning_tokens":3875,"cache_read_input_tokens":384,"cache_creation_input_tokens":0},"cache_creation_input_tokens":0},"created_at":"2026-08-11T12:41:36.709812+00:00","model_set":{"reader":"deepseek-v4-flash"},"falsifier":"Run the AutoDoS prompt against a model or API wrapper whose generation enforces the word count stated in the Trojan section, or that rejects prompts whose stated length contradicts the detailed instructions; if output length falls from the window maximum to roughly the stated limit, the Length Trojan is the load-bearing component.","supporting_citations":[],"review_version":1}