{"id":24847,"date":"2026-06-11T08:00:39","date_gmt":"2026-06-11T01:00:39","guid":{"rendered":"https:\/\/fpt-is.com\/en\/?post_type=goc_nhin_so&p=24847"},"modified":"2026-06-13T10:40:09","modified_gmt":"2026-06-13T03:40:09","slug":"building-a-scalable-wordpress-vulnerability-hunting-framework-with-ai-assisted-analysis","status":"publish","type":"goc_nhin_so","link":"https:\/\/fpt-is.com\/en\/insights\/building-a-scalable-wordpress-vulnerability-hunting-framework-with-ai-assisted-analysis\/","title":{"rendered":"Building a Scalable WordPress Vulnerability Hunting Framework with AI-Assisted Analysis"},"content":{"rendered":"

As the WordPress ecosystem continues to expand with thousands of plugins and themes, manual security reviews alone are no longer sufficient to keep pace with scale and complexity. In this article, B\u00f9i \u0110\u1ee9c T\u00e0i, a cybersecurity specialist at FPT IS, shares how he built a multi-stage framework that combines static analysis, AI-assisted review, and practical verification to support vulnerability discovery at scale.\u00a0<\/span><\/p>\n

Over the past two months I\u2019ve been building out and testing a vulnerability hunting framework for the WordPress ecosystem. I want to be upfront about what it is and isn\u2019t: it\u2019s not a magic box that replaces manual auditing. It\u2019s a system that helps me spend my time better \u2014 scan more targets, kill noise early, hold onto review state across runs, and consistently surface the most promising leads for me to look at myself.<\/span><\/p>\n

At a high level it combines custom static analysis, staged AI review, local verification, and reporting. The same general pattern applies whether I\u2019m looking at plugins or themes, even though each has its own quirks. I think of it less as an \u201cautonomous researcher\u201d and more as something that helps me prioritize and build evidence faster.<\/span><\/p>\n

Why I Built It This Way<\/strong><\/span><\/h2>\n

The WordPress plugin\/theme ecosystem is just too big to review by hand at any real scale. Even if I narrow down to specific vulnerability classes, there\u2019s still a huge amount of code, and a lot of findings that look suspicious at first glance but collapse on closer inspection.<\/span><\/p>\n

Plain SAST isn\u2019t enough on its own \u2014 it\u2019s great at flagging suspicious patterns, but also great at burying you in noise. And throwing an LLM at \u201creview everything\u201d with no structure is both expensive and unreliable. So I built this in stages on purpose.<\/span><\/p>\n

The basic idea: do the cheap, simple rule-based checks first, save the expensive analysis for whatever survives, and keep myself in the loop at the end.<\/span><\/p>\n

The High-Level Flow<\/strong><\/span><\/h2>\n

1. Collection and static scanning<\/strong><\/span><\/h2>\n

It starts with collecting targets and scanning code at scale. For public targets that means continuously pulling down WordPress plugins and themes and running them through a WordPress-focused static analysis pass.<\/span><\/p>\n

The core scanning layer is Semgrep with a set of custom rules tuned for WordPress-specific patterns \u2014 things that actually matter on this attack surface, like request data flowing into dangerous sinks, missing authorization on AJAX\/REST handlers, unsafe deserialization, file inclusion, XSS sinks, and so on.<\/span><\/p>\n

This first pass is meant to be broad. Its job isn\u2019t to say \u201cthis is a vulnerability\u201d \u2014 it\u2019s to say \u201cthis is worth a second look.\u201d<\/span><\/p>\n

\"Building<\/a><\/p>\n

2. Stage 0: Simple rule-based triage<\/strong><\/span><\/h2>\n

After the initial scan, the framework applies some rule-based filtering layer before any deeper review happens. This stage exists for one reason: static analysis is noisy, and there is no value in paying an AI model or a human to re-evaluate obvious junk.<\/span><\/p>\n

This stage handles the boring-but-important cleanup:<\/span><\/p>\n