What Happened
Between late 2024 and early 2025, TrendAI and CHT Security used an AI-driven static analysis system to scan WordPress plugins. This system uncovered over 300 critical zero-day vulnerabilities in just 72 hours. The operation consumed roughly 222 million tokens across 95 tasks, showcasing the power and computational demand of automated vulnerability discovery.
This wasn't a traditional breach—no systems were compromised, and no data was stolen. However, it exposed a systemic issue: the WordPress plugin ecosystem was riddled with exploitable flaws that human researchers had overlooked. The AI found them in three days.
Timeline
Hour 0-72: AI system conducts static analysis on WordPress plugin codebase
- Flags over 300 potential critical vulnerabilities
- Consumes 222 million tokens across 95 tasks
- No human verification during this phase
Post-discovery: Manual verification begins
- Each vulnerability requires 30-60 minutes of human analysis
- Full verification of 300 findings would take 150-300 hours (4-8 weeks for one person)
- Verification bottleneck limits practical use of findings
Ongoing: Disclosure and remediation status remains unknown for most findings
Which Controls Failed or Were Missing
1. Secure Development Lifecycle Requirements
The plugins showed no evidence of systematic security review during development. PCI DSS v4.0.1 Requirement 6.3.2 mandates that custom software be developed securely. For plugins handling payment data or authentication, this is mandatory.
What failed: No indication that plugin developers followed OWASP ASVS v4.0.3 verification requirements or conducted security reviews before release.
2. Third-Party Software Management
Organizations using these plugins did not assess security posture before deployment. PCI DSS v4.0.1 Requirement 6.4.3 requires protection against known attacks, including those in third-party components.
What failed: No systematic process for evaluating plugin security before installation. The WordPress ecosystem treats plugin installation as a trust exercise rather than a risk decision.
3. Vulnerability Management Process
NIST CSF v2.0 function DETECT (DE.CM-8) requires vulnerability scans. The real failure is in the RESPOND function—specifically, the inability to act on vulnerability intelligence at scale.
What failed: The verification bottleneck. Finding 300 vulnerabilities in 72 hours is futile if verification takes 4-8 weeks and months to coordinate disclosure and patches.
4. Supply Chain Risk Assessment
ISO 27001 Annex A.15 requires organizations to address security within supplier agreements. WordPress plugins are supply chain components.
What failed: No formal supplier assessment process for plugin vendors. Most organizations are unaware of their plugins' security review status or disclosure policies.
What the Relevant Standards Require
PCI DSS v4.0.1 Requirement 6.3.2 mandates secure development of bespoke and custom software:
- Security vulnerabilities must be corrected before release
- Code changes must be reviewed by someone other than the author
- Code reviews must ensure adherence to secure coding guidelines
For WordPress plugins processing payment data, security review is a compliance requirement.
OWASP ASVS v4.0.3 Level 2 sets the baseline for applications handling sensitive data:
- V5.3.3: Users must have a method to remove or export their data on demand
- V13.2.3: RESTful web services using cookies must be protected from Cross-Site Request Forgery
- V14.4.3: Security headers must be included in HTTP responses
These requirements align with common WordPress plugin vulnerabilities: authentication bypasses, CSRF flaws, and data exposure issues.
NIST 800-53 Rev 5 SI-2 (Flaw Remediation) requires organizations to:
- Identify and report system flaws
- Correct flaws within time frames based on risk assessment
- Test software updates before installation
The AI discovery scenario challenges this model. Finding 300 vulnerabilities in 72 hours but needing 30-60 minutes to verify each one creates a bottleneck in flaw remediation, not discovery.
Lessons and Action Items for Your Team
1. Rebuild Your Plugin Risk Assessment
Action: Create a three-tier classification for WordPress plugins:
- Tier 1: Plugins handling authentication, authorization, or sensitive data → Require security audit evidence before deployment
- Tier 2: Plugins with network access or file system operations → Require code review or static analysis
- Tier 3: Display-only plugins with no data access → Standard approval process
Document this in your change management procedure to satisfy PCI DSS Requirement 6.5.1 (change control process).
2. Automate Verification Where Possible
Action: Deploy dynamic application security testing (DAST) tools to automatically verify static analysis findings. If your AI or SAST tool flags a SQL injection, your DAST tool should attempt exploitation in a test environment.
This addresses the 30-60 minute manual verification bottleneck. While human review won't be eliminated, false positives can be filtered out automatically.
3. Establish Plugin Vendor Requirements
Action: Before approving any new WordPress plugin, require vendors to provide:
- Date of last security assessment
- Vulnerability disclosure policy with contact information
- Update frequency and support commitment
- Evidence of secure development practices (OWASP ASVS Level 1 minimum)
Add this to your vendor assessment questionnaire for SOC 2 Type II CC9.2 (vendor monitoring).
4. Build Capacity for High-Volume Triage
Action: Train your security team on rapid triage techniques:
- Severity scoring based on exploitability, not just theoretical impact
- Automated exploit generation for common vulnerability classes
- Risk-based prioritization that considers your actual WordPress configuration
The AI vulnerability discovery model is here to stay. Your team needs processes that can handle 300 findings in a week, not a quarter.
5. Implement Compensating Controls
Action: If you can't verify and patch every plugin vulnerability immediately, deploy compensating controls:
- Web Application Firewall (WAF) rules for common WordPress exploits
- Network segmentation to limit WordPress server access
- Enhanced logging and monitoring for plugin-related anomalies
Document these controls for PCI DSS Requirement 6.4.3 compliance (protection of public-facing web applications).
The WordPress plugin incident highlights a future where vulnerability discovery outpaces human verification capacity. Your security program needs to adapt now—not after the next AI system finds 300 more zero-days in your stack.
AI-driven vulnerability discovery
