Intruder's security research team discovered a SQL injection vulnerability in the Creative Mail plugin for WordPress using an automated pipeline that combines traditional code scanning with AI analysis. This vulnerability allowed unauthenticated attackers to extract data from the database. It was a real zero-day found by machines, not humans.
What Happened
The Creative Mail plugin, installed on thousands of WordPress sites, contained a SQL injection flaw that went undetected by standard scanning tools. Intruder's automated system identified the vulnerability by feeding program slices, focused chunks of code showing data flow, to an AI model trained to recognize injection patterns.
Here's how it worked: Joern, a code analysis framework, scanned the plugin's codebase and generated program slices for potential taint flows. These slices isolated the path from user input to database query. The AI model analyzed these slices and flagged the SQL injection. The entire process ran without human intervention until the exploitation phase.
Timeline
Initial scan: Joern processed the Creative Mail plugin codebase and identified potential data flow paths where user input reached database operations.
Slice generation: The system extracted program slices showing how user-controlled data moved through the code. These slices provided the focused context AI models need, not the entire 50,000-line codebase, but the specific 200 lines that mattered.
AI analysis: The model examined each slice for vulnerability patterns, flagging the SQL injection based on the lack of input sanitization before the database query.
Validation: The team confirmed the finding and disclosed it to the WordPress plugin security team.
Which Controls Failed
Code review failed to catch the vulnerability. Someone wrote the code, someone else likely reviewed it, and both missed the injection point. This maps directly to OWASP ASVS v4.0.3 Requirement 5.3.4: "Verify that data selection or database queries use parameterized queries, ORMs, entity frameworks, or are otherwise protected from database injection attacks."
Static analysis tools didn't flag it. Traditional SAST tools scan for patterns but struggle with complex data flows across multiple functions. They generate too many false positives, so teams tune them down and miss real issues. PCI DSS v4.0.1 Requirement 6.3.2 requires that "an inventory of bespoke and custom software, and third-party software components incorporated into bespoke and custom software is maintained to facilitate vulnerability and patch management." Running SAST is essential, but it's not enough.
Input validation was missing or incomplete. The code accepted user input and passed it to a database query without proper sanitization. ISO 27001 Control 8.3 requires secure coding practices, which includes input validation at trust boundaries.
Dependency risk management was reactive, not proactive. The plugin maintainers waited for someone to report the vulnerability rather than actively hunting for it in their own code. NIST CSF v2.0 function "Identify" (ID.RA) calls for regular vulnerability assessments of your software supply chain, including the code you write.
What the Standards Require
PCI DSS v4.0.1 Requirement 6.2.4: "Bespoke and custom software are reviewed prior to being released to production or to customers" using "manual or automated code-review tools or processes." The standard doesn't specify what tools, but it's clear that whatever you're using needs to actually find injection flaws.
OWASP ASVS v4.0.3 Level 2 (Requirement 5.3.4): All database queries must use parameterized queries or equivalent protection. This is non-negotiable for any application handling sensitive data. The Creative Mail vulnerability violated this requirement outright.
SOC 2 Type II CC6.1: "The entity implements logical access security software, infrastructure, and architectures over protected information assets to protect them from security events to meet the entity's objectives." Finding vulnerabilities before attackers do is part of protecting those assets.
NIST 800-53 Rev 5 SA-11: "Security Testing and Evaluation" requires organizations to "employ static code analysis tools to identify common flaws and document the results." But here's the gap: static tools alone aren't enough. You need something that understands context.
Lessons and Action Items for Your Team
Stop treating AI as a replacement for SAST. It's an augmentation layer. Your pipeline should look like this: SAST identifies potential issues, program slicing extracts context, AI analyzes the slice, human validates and remediates. Intruder's approach works because it uses Joern to narrow the search space before the AI ever sees the code.
Implement program slicing in your code review process. Tools like Joern can extract the data flow for any user input in your codebase. When you're reviewing authentication code, don't read the entire file, look at the slice showing how the password parameter moves from HTTP request to database query. This is how you spot the gaps.
Test your SAST tool against known vulnerabilities. Pull the OWASP Benchmark or Juliet Test Suite and run your scanner. If it's missing 40% of injection flaws, you need a better tool or a complementary approach. Document these tests for your SOC 2 or ISO 27001 audit, it shows you're validating your controls.
Build a vulnerability discovery pipeline, not just a scanning tool. Intruder's system chains multiple tools together. You need the same approach: SAST for pattern matching, dependency scanning for known CVEs, program slicing for context, and AI for pattern recognition humans miss. Each tool covers the gaps in the others.
Set a baseline for third-party plugin security. If you're running WordPress (or any CMS with a plugin ecosystem), you're inheriting risk from code you didn't write. Requirement 6.3.3 in PCI DSS v4.0.1 says you must maintain an inventory of third-party components and track their vulnerabilities. Run your own scans of plugins before you install them, don't wait for the WordPress security team to find issues.
Train your AI models on your own codebase. Generic models miss context-specific patterns. If your application uses a custom ORM or framework, fine-tune the model on examples from your code. This is how you reduce false positives and catch the injection patterns unique to your architecture.
The Creative Mail vulnerability wasn't sophisticated, it was a textbook SQL injection. But it survived code review and standard scanning. That should worry you. AI didn't replace security engineers here; it automated the tedious work of tracing data flows so humans could focus on validation and remediation. That's the model that works.
