What it is: Struts: Unvalidated Action Form (CWE-108) is a weakness where an active Struts Action Form has no corresponding entry in validation.xml, leaving its fields completely unchecked.
Why it matters: Every field on that form reaches application code with zero validation, which is the exact precondition that enables SQL Injection, XSS, and other input-driven attacks downstream.
How to fix it: Add a validation.xml entry defining real field-specific rules for the form, and ensure validate="true" is set on its action mapping.
TL;DR: CWE-108 is a real, active Struts Action Form with no validation.xml entry at all, meaning its fields are completely unchecked; the fix is defining real field-specific validation rules and enabling the Validator on that action.
| Field | Value |
|---|---|
| CWE ID | CWE-108 |
| OWASP Category | Not directly mapped |
| CAPEC | None known |
| Typical Severity | High |
| Affected Technologies | Apache Struts 1.x |
| Detection Difficulty | Easy |
| Last Updated | 2026-07-27 |
What is Struts Unvalidated Action Form?
Struts: Unvalidated Action Form (CWE-108) is a weakness that occurs when an Apache Struts application has an Action Form mapping with no corresponding validation form defined in validation.xml. As defined by the MITRE Corporation under CWE-108, this weakness has no official OWASP Top 10:2025 category mapping and is a direct child of Improper Use of Validation Framework (CWE-1173) and Improper Input Validation (CWE-20).
Quick Summary
Every Action Form should map to a validation form — that’s the whole point of the Struts Validator framework. When one doesn’t, MITRE is blunt about the implication: unchecked input is the root cause of some of the worst and most common software security problems, and Cross-site Scripting, SQL Injection, and process control vulnerabilities all stem from exactly this kind of incomplete or absent input validation.
Jump to: Quick Summary · Struts Unvalidated Action Form Overview · How Struts Unvalidated Action Form Works · Business Impact of Struts Unvalidated Action Form · Struts Unvalidated Action Form Attack Scenario · How to Detect Struts Unvalidated Action Form · How to Fix Struts Unvalidated Action Form · Framework-Specific Fixes for Struts Unvalidated Action Form · How to Ask AI to Check Your Code for Struts Unvalidated Action Form · Struts Unvalidated Action Form Best Practices Checklist · Struts Unvalidated Action Form FAQ · Vulnerabilities Related to Struts Unvalidated Action Form · References · Scan Your Own Site
Struts Unvalidated Action Form Overview
What: An active Struts Action Form mapping has no corresponding entry in validation.xml, so the Struts Validator applies zero checks to its fields.
Why it matters: The form’s field values reach application code completely unchecked, the classic precondition for injection and other input-driven vulnerabilities.
Where it occurs: Struts 1.x applications where new Action Forms were added without a matching validation.xml entry.
Who is affected: Struts 1.x applications with any active Action Form missing a validation entry.
Who is NOT affected: Applications where every active Action Form has a corresponding, complete validation entry with validate="true" set on its action mapping.
How Struts Unvalidated Action Form Works
Root Cause
An Action Form is registered and actively used in an action mapping, but no corresponding entry exists in validation.xml to define field-level validation rules for it.
Attack Flow
- A developer adds a new Action Form and action mapping for a feature, but forgets (or doesn’t know) to add a matching
validation.xmlentry. - The Struts Validator runs no checks against that form’s fields, since no rules exist for it.
- An attacker submits malicious input (SQL syntax, script tags, oversized values) directly into one of the form’s fields.
- The input reaches the Action class and downstream application code completely unchecked, and whatever weakness that code has (SQL Injection, XSS, buffer issues in native code) is now directly reachable.
Prerequisites to Exploit
- An Action Form is actively used by a registered action mapping.
- No corresponding entry exists for that form in
validation.xml. - The Action class or downstream code has an exploitable weakness that basic input validation would otherwise have blocked or reduced.
Vulnerable Code
<!-- struts-config.xml -->
<action path="/promoCode" type="com.example.PromoCodeAction" name="promoCodeForm" validate="true"/>
<!-- validation.xml: no entry at all for "promoCodeForm" -->
<form-validation>
<formset>
<!-- promoCodeForm is missing entirely -->
</formset>
</form-validation>
validate="true" tells Struts to run the Validator, but since no promoCodeForm entry exists in validation.xml, there’s nothing for it to actually check — every field on this form reaches PromoCodeAction completely unvalidated.
Secure Code
<!-- validation.xml: real entry added for promoCodeForm -->
<form-validation>
<formset>
<form name="promoCodeForm">
<field property="code" depends="required,mask">
<arg key="promoCode.code"/>
<var>
<var-name>mask</var-name>
<var-value>^[A-Z0-9]{4,12}$</var-value>
</var>
</field>
</form>
</formset>
</form-validation>
A real validation entry now enforces that code is required and matches a strict alphanumeric pattern, so malformed or malicious input is rejected by the Validator before it ever reaches PromoCodeAction.
Business Impact of Struts Unvalidated Action Form
Confidentiality: Unchecked input reaching application code can enable data exposure via injection vulnerabilities the missing validation would have blocked.
Integrity: Unchecked input can enable data modification via the same class of injection issues.
Availability: In J2EE applications interfacing with native code lacking bounds checking, an input-validation gap here could even enable a buffer overflow in that native layer.
- Direct enabling of downstream injection vulnerabilities (SQL Injection, XSS) that basic field validation would have caught
- Increased attack surface on every field of the unvalidated form, not just one specific parameter
Struts Unvalidated Action Form Attack Scenario
- An attacker discovers a promotional-code redemption form with no apparent length or format restriction on the code field.
- They submit a code value containing SQL injection syntax instead of a real promo code.
- Because no
validation.xmlentry exists for this form, the Struts Validator performs no check at all, and the raw value reaches the Action class. - The Action class passes the value into a database query without additional sanitization, and the SQL injection succeeds.
How to Detect Struts Unvalidated Action Form
Manual Testing
- List every Action Form referenced by an active mapping in
struts-config.xml. - Confirm each one has a corresponding, complete entry in
validation.xml. - Submit malformed or oversized input into a suspected unvalidated form’s fields and observe whether it’s rejected.
Automated Scanners (SAST / DAST)
Static analysis can directly cross-reference active Action Form mappings against validation.xml entries to flag any form with no validation defined, since this is purely a configuration-matching check.
PenScan Detection
PenScan’s scanner engines cross-reference active Struts Action Form mappings against validation.xml entries to flag forms missing validation entirely.
False Positive Guidance
A form that performs equivalent validation manually in its Action class code (rather than via the Struts Validator) may not be exploitable despite lacking a validation.xml entry — confirm whether manual validation actually covers every field before treating this as a real finding.
How to Fix Struts Unvalidated Action Form
- Add a
validation.xmlentry defining real, field-specific rules (required, format, length) for every field on the form. - Ensure
validate="true"is set on the corresponding action mapping so the Validator actually runs. - Audit the whole application for this pattern, not just the one form discovered — it’s often systemic if it happened once.
Framework-Specific Fixes for Struts Unvalidated Action Form
This weakness is specific to Apache Struts 1.x’s separate validation.xml configuration model; modern frameworks (Struts 2, Spring MVC) co-locate validation with the form class via annotations, so this exact configuration-drift pattern doesn’t apply there.
- Struts 1.x: add the missing
validation.xmlentry with real field rules and confirmvalidate="true"on the action mapping, as shown above.
How to Ask AI to Check Your Code for Struts Unvalidated Action Form
Review the following Struts struts-config.xml and validation.xml for potential CWE-108 Unvalidated Action Form issues — confirm every active Action Form has a matching, complete validation.xml entry: [paste config here]
Struts Unvalidated Action Form Best Practices Checklist
✅ Add a validation.xml entry for every active Action Form ✅ Define real, field-specific rules, not a placeholder entry ✅ Confirm validate=”true” is set on the corresponding action mapping ✅ Audit the whole application for this pattern, since it’s often systemic
Struts Unvalidated Action Form FAQ
How does a missing validation form leave an application exposed?
Without a validation.xml entry, the Struts Validator performs no checks on that form’s fields at all, so whatever the field values are, they reach the Action class code completely unchecked — the exact precondition SQL Injection, XSS, and other input-driven attacks need.
How is this different from Struts: Unused Validation Form (CWE-107)?
CWE-108 is an active Action Form with no validation.xml entry at all — a real, currently-exploitable gap; CWE-107 is the opposite case, a validation entry with no active form using it, which is stale but not itself dangerous.
How does the Struts Validator relate to application-level validation code?
The Struts Validator is meant to provide at least a basic, declarative layer of input checking before a request reaches the Action class; some applications also validate manually in code, but relying on that alone without registering the form is fragile and easy to miss during refactors.
How do I detect this in my own application?
List every Action Form referenced by an active mapping in struts-config.xml, and confirm each one has a corresponding entry in validation.xml.
How do I fix this correctly?
Add a validation.xml entry for the form, defining real, field-specific validation rules (required, format, length) for every field, and set validate=”true” on the corresponding action mapping.
How does setting validate=”true” alone not fully fix this?
The validate flag only tells Struts to run the Validator framework for that action; if no validation.xml form entry actually exists for it, there’s still nothing for the Validator to check against, so both pieces are required together.
How can PenScan help find this weakness?
PenScan cross-references active Struts Action Form mappings against validation.xml entries to flag any form with no validation defined at all.
Vulnerabilities Related to Struts Unvalidated Action Form
| CWE | Name | Relationship |
|---|---|---|
| CWE-1173 | Improper Use of Validation Framework | ChildOf |
| CWE-20 | Improper Input Validation | ChildOf |
References
Scan Your Own Site
Manual code review catches what you know to look for. An automated scan catches what you didn’t. Scan your own website using PenScan to find unvalidated Struts forms and other risks before an attacker does.