An automated security scan flagged a critical RCE vulnerability due to a significant response delay. The payload included a command to pause execution, which incorrectly indicated command injection. This delay was observed to be inconsistent across repeated tests, highlighting its unreliability as proof of vulnerability.The issue stemmed from the Web Application Firewall (WAF) taking longer to process requests containing suspicious characters. This is a known failure mode where delays are misinterpreted as command execution when they are actually caused by other factors like WAF inspection or application load. Many automated tools and even experienced security professionals can fall into this trap by solely relying on time-based responses.The text emphasizes a better approach: instead of just looking for delays, one should confirm if the server evaluated input in a way that produces a unique, unforgeable value. This involves sending a benign control request to establish a baseline. Then, asking the server to compute something novel, like the sum of random numbers, and verifying if that specific sum appears in the response.If there's no direct output, varying the delay time can help differentiate between true vulnerabilities and external factors. DNS callbacks by themselves are insufficient evidence of RCE, as they can be triggered by link previews or other benign functions.False positives are common, especially when scanners use shell metacharacters in environments that don't execute them. The author advocates for repeatable, verifiable results rather than relying on single, inconsistent observations. The ultimate goal is to confirm if a value could only exist due to server-side execution of input, not just a delayed response.