August 23 Security Briefing: Fabrik, Mailgun and WS Form Vulnerabilities

Today’s security issues

The August 23 briefing examines three web-extension vulnerabilities. CVE-2026-76604 affects the PHP form element in Fabrik, an application builder for Joomla, and can connect unauthenticated input to server-side code execution. CVE-2026-78003 affects Mailgun for WordPress and lets a public request influence an authenticated request made with the site’s Mailgun API key. CVE-2026-4703 affects WS Form LITE and introduces PHP object injection through form-submission metadata. All three begin with web input, but their escalation conditions and response priorities differ.

The first operational distinction is whether an internet-reachable request directly crosses an execution boundary or needs another condition to turn into impact. Fabrik’s PHP element creates a direct execution concern. Mailgun’s issue converts the WordPress site into a requester that carries API authority, so email routing and password-reset workflows become part of the review. WS Form LITE requires teams to separate deserialization from the presence of a usable POP chain in another installed plugin or theme.

Asset context should drive the queue. Inventory Joomla extensions, WordPress plugins, public forms, active API keys, and related themes before assigning change windows. A severity score is useful for sorting, but exposure, privileges, and service dependencies determine what must be isolated first and how an update should be validated.

Issues at a glance

• Fabrik CVE-2026-76604: an unauthenticated code-execution path through the PHP form element affects releases below 4.7.3.
• Mailgun for WordPress CVE-2026-78003: in versions through 2.2.0, manipulated addresses array keys can redirect authenticated Mailgun API requests and create inbound routes.
• WS Form LITE CVE-2026-4703: in versions through 1.10.80, submitted metadata can trigger PHP object injection; impact grows when another component supplies a usable POP chain.
• Shared priority: identify installations, map exposed functions, apply a safe version, review credentials and integrations, and retest business workflows.

Administrative interfaces can make these products look internal, yet the starting point is a public form or AJAX request. Admin-account hardening alone does not remove that path. Reduce exposed functionality, update according to the official affected-version boundary, and validate both the intended feature and the surrounding logs after the change.

Indicator trends

The three CVE records emphasize products, functions, input locations, and affected versions rather than domains, IP addresses, or file hashes. Detection should therefore begin with configuration and application telemetry. Look for public Fabrik forms tied to PHP elements, Mailgun route changes initiated from the WordPress integration, and unusual WS Form submission metadata or deserialization errors.

Compare normal baselines with change evidence instead of relying on a single string. In Mailgun, review newly created inbound routes, their destinations, and API-key use. In WordPress, align plugin updates with password-reset events and mail-routing changes. In Joomla, correlate form submissions with PHP execution, database-query errors, and web-process file modifications.

Configuration-led detection works best when asset ownership and log locations are already recorded. Track extension name, version, enabled state, and integration credentials as asset attributes, not just the CMS version. That context shortens the time from advisory publication to an exposure decision.

Security incidents

This briefing’s risk assessment focuses on newly published vulnerabilities and their exposure conditions rather than assuming a breach from an installed version. Vulnerability and compromise are different states. Web-request logs, administrative changes, and email-routing history are needed to determine whether a specific environment crossed from exposure into an incident.

Escalation signals differ by product. Unauthorized PHP execution or file changes on a Fabrik server justify preserving web-root and database evidence. Unexpected Mailgun inbound routes, API-key use, or password-reset destinations require an identity and mail-flow review. A WS Form deserialization error should be connected to the site’s other code and follow-on file or data activity before impact is assigned.

New critical CVEs

Fabrik CVE-2026-76604 affects the PHP form element in the Joomla Fabrik extension. The CVE record places releases below 4.7.3 in scope, describes an unauthenticated route, and assigns a CVSS 4.0 score of 10.0. The same publication batch includes CVE-2026-76571 and CVE-2026-76602, which cover unauthenticated SQL injection through the list-filter condition and ORDER BY input. Because Fabrik links forms, lists, and databases, public forms must be evaluated across both code-execution and database-read boundaries.

Check not only the version but also which forms enable the PHP element, whether anonymous visitors can submit them, and what database or file permissions the process holds. Disable or restrict the affected feature until a non-affected vendor package can be applied. Back up form definitions and extension settings first, then regression-test anonymous submissions, administrative editing, and scheduled tasks.

Mailgun for WordPress CVE-2026-78003 is an SSRF issue in versions through 2.2.0. Manipulated addresses array keys can affect API-request construction, allowing an unauthenticated actor to make authenticated requests with the site’s stored Mailgun API key. Creating inbound forwarding routes can expose password-reset messages and create an account-takeover path.

The WordPress.org changelog shows that version 2.2.1 added nonce verification and server-side address validation, with 2.2.2 available afterward. Update affected installations, inspect inbound routes and API logs, and rotate the API key if an unauthorized route or request is found. Review administrative and editor password-reset events over the same period.

WS Form LITE CVE-2026-4703 affects versions through 1.10.80 and allows untrusted PHP objects to enter the deserialization path for form-submission metadata. The record describes a network-accessible, unauthenticated condition with a CVSS 3.1 score of 9.8. WS Form LITE itself does not provide a complete harmful POP chain, but another installed plugin or theme can expand impact to file deletion, data access, or code execution.

That condition should refine the workflow, not delay it. Verify the WS Form LITE version and active forms, update to the latest release, then inventory related plugins and themes. Remove unsupported components and test submission storage, notifications, uploads, and external integrations after the change. Repeated deserialization exceptions in PHP logs deserve follow-up.

KISA advisories

The latest item on KISA’s public security-advisory list is the MLflow update recommendation published on August 21. Korean operations teams can use that list as a complementary asset-check channel and map listed products to vendor guidance. For the three CMS-extension issues in this briefing, use the NVD/CVE records and product repositories as the decision basis, then recheck KISA when the domestic list changes.

Operational notes

1. Collect installation, activation, and version data for Fabrik, Mailgun for WordPress, and WS Form LITE.
2. Map public forms, AJAX actions, mail APIs, and submission storage to their backend privileges.
3. Back up configuration and data, then apply a supported update or disable the affected function through the change process.
4. Review Mailgun API keys and inbound routes alongside administrative password-reset history.
5. Retest submissions, notification mail, uploads, and administrative editing, and preserve the results.

Prioritize exposure and connected authority, not the score alone. A public Fabrik PHP element, a Mailgun AJAX action carrying an API key, and a WS Form installation that can connect to another component’s POP chain create different response orders. Record the owner and exit criteria for every temporary restriction, and restore public access only after the permanent update passes functional checks.

Source 1 — NIST NVD, CVE publication-window query

https://services.nvd.nist.gov/rest/json/cves/2.0/?pubStartDate=2026-08-22T00%3A00%3A00.000&pubEndDate=2026-08-22T22%3A59%3A59.999

Source 2 — WordPress.org, Mailgun for WordPress changelog

https://wordpress.org/plugins/mailgun/

Source 3 — KISA, public security-advisory list

https://www.boho.or.kr/kr/bbs/list.do?bbsId=B0000133&menuNo=205020