Large language models are increasingly used to triage decompiled functions for security vulnerabilities inside reverse-engineering assistants. We ask whether such a triage verdict is driven by the behavior of the code or by artifacts the decompiler surfaces around it: recovered symbol names, embedded string literals, and the placeholder markers (FUN_, DAT_, undefined) emitted for stripped binaries. We compile and decompile 115 Juliet C/C++ test cases and 233 real-CVE functions (PrimeVul), hold the decompiled or source body byte-identical, and vary only these carriers. For the three open-weight models deployed in local reverse-engineering assistants (Ghidra and IDA plugins run 7-13B models), the shift is real, significant, and directionally universal: alarming carriers raise the exploitability verdict and benign carriers lower it, by up to 1.5 points on a 0-10 scale (Wilcoxon p < 1e-9, surviving Holm correction) and up to +19 detection points on real CVE functions, where an "already audited, safe" comment more than halves detection. The effect is cognitive, not injection; it does not attenuate from source to decompiled code; it holds on real CVE functions compiled and decompiled in situ; and stripping does not remove it. Two frontier models (Claude Sonnet and Opus) are the honest exception: their verdict is far more robust, though benign carriers still suppress them on real code, but they refuse about 27 percent of decompiled triage prompts (77 percent for stripped code), their stability is partly benchmark memorization, and the carriers re-emerge as a refusal channel. We release the pipeline, both corpora, and all per-call logs.
No takes yet. Share an insight, caveat, or question.
Adam Melhem (2026) studied this question.
Synapse has enriched 5 closely related papers on similar clinical questions. Consider them for comparative context: