Published October 21, 2026. Based on public reports available on that date; details may change.
CVE-2026-110899 is a stored cross-site scripting vulnerability in Ninja Forms through version 3.15.5. Update Ninja Forms to 3.15.6 or later, then review stored form submissions and the accounts that can view or manage them.
What happened
The published record describes an input-neutralization problem that allows stored cross-site scripting, also called stored XSS. A crafted form submission can be saved by the plugin and later cause script to execute in the browser of someone who views the affected output.
The important word is "stored." This is not limited to a person clicking a suspicious link in email. The harmful input can remain in the site's form data until a staff member, site editor, or visitor reaches the place where the application displays it. That may be a submissions screen, a form entry view, or a page that publishes submission content.
The CVSS 3.1 score published with the record is 7.1 High. The cited records do not report exploitation in the wild. Treat the update as a normal but prompt maintenance task, especially on sites that accept contact, quote, application, or other public form submissions.
Who is affected
Ninja Forms versions through 3.15.5 are affected. Version 3.15.6 is identified as the solution. Check the version on each site using the plugin, including a staging site if it stores real or copied submissions.
In the dashboard, go to Plugins and find Ninja Forms. The version is displayed in the plugin list. With WP-CLI, run wp plugin list --name=ninja-forms. If it reports 3.15.5 or an earlier release, schedule the update immediately under your established change process.
The public description says a crafted submission can cause script execution in a viewer's browser. That makes the people who review submissions part of the risk picture. Consider everyone who can access the submissions area, including staff using shared administrator accounts. Each person should have an individual WordPress account and only the access required for their work.
How to check your site
Start with the installed version, then examine form data without needlessly exposing staff to questionable content. Do not open suspicious submissions casually in a normal browser, and do not copy unusual form values into a page editor just to see what happens.
- Confirm the Ninja Forms version in Plugins or with
wp plugin list --name=ninja-forms. - Identify which public forms use Ninja Forms and where their submissions are stored or displayed.
- Review recent submissions from the affected period for entries your team cannot account for, using a cautious workflow.
- Review WordPress users who can view submissions or change forms.
- Check whether submitted data is published anywhere on the public site, such as a testimonial, request, or directory workflow.
The goal is to identify suspicious content and affected viewing paths, not to declare every unusual form response malicious. An unexpected string of markup or script-like text is worth preserving and reviewing. If you have server logs, they can provide useful context about submission times and the accounts that later viewed or edited content.
If you observe unknown users, altered site content, redirects, or other signs beyond a form submission, expand the investigation. The checklist in signs a WordPress site has been hacked can help you separate a single suspicious entry from a broader compromise.
What to do now
Update Ninja Forms to 3.15.6 or later. In the dashboard, use Dashboard, Updates, or run wp plugin update ninja-forms if WP-CLI is part of your normal administration process. Confirm the new version in the plugin list after the update.
Before cleaning questionable submissions, preserve the original data and relevant logs if you may need to investigate it. Then remove or correct unsafe entries using a controlled process. Be particularly careful with any workflow that copies submission content into pages, emails, or the WordPress editor.
Review the access to forms and submissions. Remove inactive WordPress users, avoid shared administrator accounts, and give staff the lowest role that lets them complete their work. The WordPress hardening checklist covers these foundational controls alongside updates.
An update fixes the reported vulnerable version, but it does not remove stored content that was submitted before the update. Review existing submissions, especially those collected from open public forms. If you find unknown changes or suspect that a logged-in user viewed a harmful submission, change that user's password and check the account for unauthorized actions.
Keep the form plugin, WordPress core, and other plugins updated on a regular schedule. A maintained backup is useful, but test your restoration path before relying on it for an incident. Our WordPress hardening service can help put a repeatable update and account-control process in place.
When to get help
Get help if you find suspicious form data, cannot identify who has viewed it, or see signs of changes beyond the form plugin. For a suspected compromise, start with WordPress malware removal; for a planned review of forms, accounts, and updates, consider a security audit.