CrowdStrike 的 GbVD 研究以 AI 護欄反應定位漏洞候選

1. Basic Information

• Title: When AI Guardrails Expose Vulnerabilities
• Publisher: CrowdStrike
• Published Date: 2026-10-28
• Original: CrowdStrike
• Severity: High

2. Executive Summary

CrowdStrike reported that by using guardrail reactions such as AI model refusal responses and reasoning interruptions for the same prompt as a "1-bit oracle" and performing bisection on code diffs, they correctly classified 73 out of 86 scenarios across 5 types, including safe examples without vulnerabilities.

3. Research Question

• This research examines whether differences in AI model refusal behavior for safety reasons can be used to identify vulnerable code regions from the outside.

4. Proposed Method

• The model is repeatedly given baseline source code and a defect-containing variant using the same prompt. Its refusals, reasoning interruptions, and response changes are compared as a 1-bit oracle.
• Code subsets where response differences persist are narrowed down using bisection, and the final remaining candidates are reproduced and verified by humans.

5. Inputs

• Baseline source code
• Code variants containing defects (or comparable code fragments)
• Fixed prompts
• Model and guardrail responses (such as refusals and reasoning interruptions)
• Number of repeated executions and decision thresholds

6. Outputs

• Differential signals between the baseline and variant
• Code ranges narrowed down as vulnerability candidates
• Test cases for reproduction and verification
• Independent verification results by humans

7. Workflow

1. Run fixed prompts repeatedly against the baseline code and measure guardrail reactions.
2. Measure the defect-containing variant under the same conditions.
3. Determine response differences as a 1-bit signal using thresholds such as "a refusal in at least 3 of 5 runs."
4. Repeat retesting while splitting the target code (bisection) to narrow down the range where the signal occurs.
5. Have humans perform reproduction and verification on the minimized candidate code and proceed with coordinated disclosure as needed.

8. Evaluation Design

• Total Evaluation Scenarios: 86 (44 vulnerable examples, 42 non-vulnerable examples)
• Target Vulnerability Classes: 5 types
• Reported Correct Count: 73 (True Positives TP=36, True Negatives TN=37)
• Misclassification Breakdown: False Positives FP=5, False Negatives FN=8
• Repetition Condition Example: Setting of running 5 times with a threshold of refusals in at least 3 of 5 runs (3-of-5 threshold)
• Specific Verification Examples: Out-of-bounds write in tinyhttp and verification using an SUID root binary

9. Results

The total of Table 1 as published is TP=36, FP=5, FN=8, and TN=37, and the 73/86 correct count includes correct classifications of non-vulnerable safe examples (TN=37). Therefore, it does not mean "73 vulnerabilities were discovered."

• CrowdStrike reports that correct classification results were obtained in 73 out of 86 scenarios.
• They also demonstrated the specific process of narrowing down vulnerability candidates from guardrail response differences through examples such as boundary processing defects (confusion between max and min) in tinyhttp and SUID binaries.

10. Practical Significance

• This method does not replace existing static analysis, fuzzing, or code reviews, but is positioned as an auxiliary signal to support the prioritization of investigation candidates.
• On the other hand, the fact that AI model safety mechanisms (guardrails) themselves can act as side channels that leak target code characteristics externally is an important evaluation consideration for both model providers and users.

11. Prerequisites

• A baseline must exist that allows repeated comparison under identical conditions.
• Model and guardrail versions and prompts must be fixed so that response differences are statistically stable.
• Humans must independently confirm the narrowed-down final candidates through reproduction runs in an isolated verification environment or via code review.

12. Limitations

• The exact model identities and the complete evaluation code are not public, limiting the generalization of results (though the breakdown of TP, FP, FN, and TN by classification is published).
• Response signals may change due to updates to models or guardrails, potentially leading to a loss of reproducibility.
• The figure of 73/86 represents classification results within the 86 scenarios designed in this study and does not indicate general detection accuracy for arbitrary codebases.

13. Application Guidance

• Run verifications in an isolated environment and avoid connecting unknown code to production credentials or networks.
• Save prompts, model names, versions, iteration counts, seed values, and response categories to ensure auditability and reproducibility.
• Do not perform automated remediation or automated disclosure based solely on signals; independent reproduction and verification by humans, followed by coordinated vulnerability disclosure, are required.

14. Required Evidence

• Complete code diffs between baseline and variants
• Raw responses or response classification results for each repeated run
• Minimized reproduction test cases
• Independent verification results regarding memory safety and privilege impacts
• Evaluation records for false positives (FP) and false negatives (FN)

15. Facts, Inferences, Hypotheses, and Unknowns

Facts

• CrowdStrike proposed "Guardrail-based Vulnerability Discovery (GbVD)," which observes guardrail behaviors such as refusal responses, reasoning interruptions, and response changes as a 1-bit oracle.
• The evaluation reports that correct classification results were obtained in 73 out of 86 scenarios (TP=36, TN=37) across 5 vulnerability classes (44 vulnerable examples and 42 non-vulnerable examples).
• The workflow employs giving identical prompts to a baseline and a defect-introduced version, and narrowing down code regions where behavioral differences persist using bisection.
• For tinyhttp, out-of-bounds writes caused by confusing max and min were handled, and verification examples using SUID root binaries were also shown.
• Experimental settings were described where each candidate was tested 5 times, with refusals in at least 3 runs meeting the threshold.

Inference

• Inference: Rather than discarding AI model refusal responses as mere errors, treating them as reproducible differential signals could potentially be utilized for prioritizing triage in static analysis or fuzzing.

Hypothesis

No additional hypotheses. Unconfirmed items are listed in "Unknowns and Additional Research."

Unknowns and Additional Research

• The exact model identities, source code and execution environments for all 86 scenarios, and reproducibility across other models are not fully disclosed (TP, FP, FN, and TN by classification are published in Table 1).
• Details of findings discovered against actual OSS remain partially private due to coordinated disclosure processes.

16. Implications for Defenders

When considering the adoption of this approach as a development or security audit tool, organizations must independently evaluate reproducibility, false positives/negatives (FP/FN), API costs, and safety within their own models, prompts, and codebases, rather than treating the 73/86 aggregate value as general performance.

Summary by Target Audience

• SOCs: This research is not a report on direct security incidents or attack campaigns. Treat it as knowledge regarding the verification and auditing of AI-powered vulnerability discovery methods.
• Administrators: When trialing similar methods in CI or code audit pipelines, record model versions, prompts, seed values, iteration counts, and code diffs, and make final confirmation by humans mandatory.
• Users: No immediate action is required for general end users.