CVE-2025-64775 & CVE-2025-66675: Understanding and Mitigating the Multipart Request Processing Flaw
The Apache Software Foundation has disclosed two related critical Denial of Service vulnerabilities affecting nearly all versions of the Apache Struts framework. These flaws allow unauthenticated attackers to exhaust server disk space through specially crafted file upload requests, potentially causing complete system unavailability. Organizations running Apache Struts must take immediate action to assess their exposure and implement remediation measures.
Apache Struts 2, one of the most widely deployed Java web application frameworks, has been found vulnerable to a sophisticated Denial of Service attack that exploits improper handling of multipart request processing. The vulnerabilities, tracked as CVE-2025-64775 and CVE-2025-66675, stem from a file leak in the framework’s file upload mechanism that prevents temporary files from being properly deleted after processing.
When attackers send specially crafted multipart requests containing file uploads or large form data, the Apache Struts framework creates temporary files on the server’s disk storage. Due to an incomplete cleanup process in the JakartaMultiPartRequest class, these temporary files are not properly removed, accumulating over time until the server’s disk space is completely exhausted. Once disk space is depleted, affected systems cannot write new data, generate logs, or function properly, resulting in a complete denial of service.
The widespread impact of these vulnerabilities cannot be overstated. With affected versions spanning from Apache Struts 2.0.0 through 6.7.4 and 7.0.0 through 7.0.3, virtually every organization using this popular framework is potentially at risk. Legacy deployments running unsupported versions such as 2.3.x and 2.5.x face particularly acute danger, as these versions no longer receive security patches and represent the most vulnerable segment of the user base.
Understanding CVE-2025-64775 and CVE-2025-66675
These two CVE identifiers represent closely related aspects of the same underlying vulnerability in Apache Struts’ multipart request processing mechanism. CVE-2025-64775 was initially disclosed on December 1, 2025, with CVE-2025-66675 following on December 10, 2025, to address missing affected version information (specifically version 6.7.4).
| Vulnerability Attribute | CVE-2025-64775 | CVE-2025-66675 |
|---|---|---|
| Publication Date | December 1, 2025 | December 10, 2025 |
| CVSS Base Score | 7.5 (High) | 8.2 (High) |
| CVSS Vector | AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H | AV:N/AC:L/PR:N/UI:N/S:U/C:L/I:N/A:H |
| Attack Vector | Network (Remote) | Network (Remote) |
| Attack Complexity | Low | Low |
| Privileges Required | None | None |
| User Interaction | None | None |
| Confidentiality Impact | None | Low |
| Integrity Impact | None | None |
| Availability Impact | High | High |
| Affected Versions | 2.0.0-6.7.0, 7.0.0-7.0.3 | 2.0.0-6.7.4, 7.0.0-7.0.3 |
| Relationship | Initial disclosure | Corrects affected version information |
Why Two CVE Numbers?
CVE-2025-66675 was issued to correct incomplete version information in the original CVE-2025-64775 advisory. Specifically, version 6.7.4 was initially missed in the affected version range. Both CVEs describe the same fundamental vulnerability and require the same remediation actions. Organizations should treat these as a single security issue requiring unified response.
The Root Cause: JakartaMultiPartRequest File Leak
The vulnerability originates in the org.apache.struts2.dispatcher.multipart.JakartaMultiPartRequest class, specifically within its cleanUp() method. This method is responsible for deleting temporary files created during multipart request processing. However, the implementation contained a critical oversight.
| Component | Function | Vulnerability | Impact |
|---|---|---|---|
| JakartaMultiPartRequest | Handles multipart/form-data requests | Incomplete file cleanup in cleanUp() method | Temporary files accumulate on disk |
| Apache Commons FileUpload | Underlying library for file upload processing | Creates temporary files for form fields exceeding size threshold | Multiple temporary files per request |
| cleanUp() Method | Deletes temporary files after processing | Only deleted files from explicit file uploads, not form fields | Regular form field temporary files never deleted |
| processUpload() Method | Parses multipart request data | Triggers temporary file creation without cleanup guarantee | Memory-to-disk spill creates orphaned files |
| Temporary File System | Stores temporary upload files | No automated cleanup mechanism for leaked files | Gradual disk exhaustion over time |
The Apache Commons FileUpload library, which underlies Struts’ multipart processing, creates temporary files not only for explicit file uploads but also for regular form fields when they exceed a configurable size threshold. The flawed cleanUp() method only deleted temporary files associated with actual file uploads, completely neglecting temporary files created for oversized form field data.
// Simplified vulnerable code pattern public void cleanUp() { // Only cleans up file upload temporary files for (FileItem item : fileItems) { if (item.isFormField()) { // BUG: Skips cleanup for form field temporary files continue; } item.delete(); // Only deletes file upload temps } } // Each request potentially leaves behind orphaned temporary files // Repeated requests cause accumulation until disk exhaustion
Attack Mechanics and Exploitation Scenario
Exploiting this vulnerability requires minimal sophistication. An attacker simply needs to send HTTP POST requests with multipart/form-data encoding containing large form field values. The attack sequence unfolds as follows:
| Attack Phase | Attacker Action | System Behavior | Cumulative Impact |
|---|---|---|---|
| 1. Reconnaissance | Identify Struts application with file upload or form processing | Normal application operation | Attack preparation |
| 2. Initial Probing | Send test multipart request with large form fields | Temporary files created and not deleted | First leaked files appear |
| 3. Volume Amplification | Automate requests with varying field sizes and counts | Rapid accumulation of temporary files | Disk space begins depleting |
| 4. Resource Saturation | Maintain sustained request rate | File system fills, write operations start failing | Application performance degradation |
| 5. Denial of Service | Continue until complete disk exhaustion | No disk space for logs, sessions, or data | Complete system unavailability |
| 6. Persistence | Files remain even after attack stops | System cannot recover without manual cleanup | Prolonged outage requiring intervention |
Low Exploitation Barrier
This vulnerability requires no authentication, no special privileges, and no user interaction. Attackers can exploit it remotely using standard HTTP tools like curl, Python scripts, or purpose-built exploitation frameworks. The attack leaves minimal forensic evidence beyond disk space depletion and failed write operations, making attribution and detection challenging without proper monitoring infrastructure.
Impact Assessment and Risk Analysis
Organizational Impact Scenarios
The consequences of successful exploitation extend far beyond simple service disruption. Organizations face multifaceted impacts across operational, financial, and reputational dimensions.
| Impact Category | Immediate Effects | Secondary Consequences | Long-term Implications |
|---|---|---|---|
| Service Availability | Complete application downtime, inability to process transactions | Customer service degradation, transaction failures | User migration to competitors, market share loss |
| Data Integrity | Failed database writes, corrupted transaction logs | Data inconsistency, backup failures | Regulatory compliance violations, audit findings |
| Operational Continuity | Unable to log security events, monitor systems | Blind spots in security monitoring, delayed incident detection | Compromised security posture, vulnerability to cascading attacks |
| Financial Performance | Lost revenue during outage, emergency response costs | SLA breach penalties, customer refunds | Increased insurance premiums, investor confidence erosion |
| Reputation | Negative publicity, customer complaints | Social media backlash, press coverage | Brand damage, customer trust erosion, competitive disadvantage |
| Recovery Effort | Manual file cleanup, disk space recovery | System restoration, security validation | Process improvements, architectural changes |
Industry-Specific Risk Factors
Different sectors face varying levels of exposure and impact severity based on their reliance on Apache Struts and tolerance for service disruption.
| Industry Sector | Apache Struts Usage | Risk Level | Key Concerns |
|---|---|---|---|
| Financial Services | Widespread in legacy banking and payment systems | Critical | Transaction processing failures, regulatory reporting disruption, customer account access issues |
| E-commerce | Common in order management and inventory systems | High | Lost sales during peak periods, shopping cart abandonment, payment processing failures |
| Healthcare | Patient portals, electronic health record systems | Critical | Patient care disruption, medical record unavailability, appointment scheduling failures |
| Government | Citizen service portals, tax filing systems | High | Public service disruption, citizen data access issues, deadline compliance problems |
| Education | Learning management systems, student portals | Moderate | Course access disruption, grade reporting failures, enrollment processing delays |
| Telecommunications | Customer management, billing systems | High | Service provisioning delays, billing failures, customer support disruption |
| Manufacturing | Supply chain management, quality tracking | Moderate | Production scheduling disruption, inventory management failures, supplier coordination issues |
Detection and Identification Strategies
Vulnerability Assessment Methodology
Organizations must rapidly identify whether their infrastructure contains vulnerable Apache Struts installations and assess the exposure level of affected systems.
| Assessment Phase | Actions Required | Tools and Techniques | Expected Deliverables |
|---|---|---|---|
| Inventory Discovery | Identify all Java web applications in environment | CMDB queries, network scanning, application catalogs | Complete list of Java-based web applications |
| Version Detection | Determine Apache Struts version for each application | JAR file analysis, dependency management tools, runtime inspection | Vulnerable vs. non-vulnerable application classification |
| Exposure Analysis | Assess network accessibility and attack surface | Network topology review, firewall rule analysis, endpoint enumeration | Risk-prioritized remediation list |
| Functionality Review | Identify applications with file upload or form processing | Code review, functionality testing, user documentation | Confirmed exploitable instances |
| Criticality Assessment | Evaluate business impact of each vulnerable system | Business impact analysis, dependency mapping, SLA review | Prioritized remediation roadmap |
| Compliance Verification | Check for regulatory or contractual security requirements | Compliance frameworks, audit reports, contract review | Compliance-driven remediation timeline |
# Example version detection commands # Check JAR file for Struts version jar -tf application.war | grep struts2-core unzip -l application.war | grep struts2-core # Maven dependency check mvn dependency:tree | grep struts # Search filesystem for Struts JARs find / -name "struts2-core*.jar" 2>/dev/null # Check running Java processes for Struts ps aux | grep java jps -v | grep struts # Scan web application structure ls -la WEB-INF/lib/ | grep struts
Runtime Monitoring and Anomaly Detection
Even before implementing patches, organizations should deploy monitoring capabilities to detect exploitation attempts and ongoing attacks.
| Monitoring Focus | Key Indicators | Detection Methods | Response Actions |
|---|---|---|---|
| Disk Space Utilization | Rapid disk usage increase, unusual growth patterns | Disk monitoring tools, SNMP alerts, system logs | Automated alerts, capacity investigation, temporary file cleanup |
| Temporary File Count | Abnormal temporary file accumulation in /tmp or upload directories | File system monitoring, inode usage tracking, directory size alerts | Identify file creation patterns, block suspicious IPs |
| Multipart Request Patterns | High volume of POST requests with multipart encoding | Web access logs, WAF analytics, request rate monitoring | Rate limiting, source IP blocking, request throttling |
| Application Error Rates | Increased disk write failures, I/O errors, application exceptions | Application logs, error tracking systems, APM tools | Emergency disk cleanup, service restart procedures |
| System Performance | Degraded I/O performance, slow response times | Performance monitoring, user experience tracking | Performance investigation, resource allocation review |
| Log Generation Failures | Missing log entries, log rotation failures | Log aggregation gaps, syslog monitoring | Emergency storage allocation, log compression |
Remediation and Mitigation Strategies
Immediate Patching Requirements
The Apache Software Foundation has released patched versions that completely resolve the file leak vulnerability. Organizations must prioritize upgrading to these secure versions as the primary remediation strategy.
| Current Version Range | Vulnerability Status | Recommended Action | Target Version |
|---|---|---|---|
| 2.0.0 – 6.7.4 | Vulnerable | Immediate upgrade required | 6.8.0 or later |
| 7.0.0 – 7.0.3 | Vulnerable | Immediate upgrade required | 7.1.1 or later |
| 6.8.0+ | Patched | Maintain current version, apply regular updates | N/A |
| 7.1.1+ | Patched | Maintain current version, apply regular updates | N/A |
| 2.3.x (Legacy) | Vulnerable, unsupported | Emergency migration to supported version | 6.8.0 or 7.1.1 |
| 2.5.x (Legacy) | Vulnerable, unsupported | Emergency migration to supported version | 6.8.0 or 7.1.1 |
Legacy Version Warning
Organizations running legacy Struts versions (2.3.x, 2.5.x) face the highest risk. These versions no longer receive security patches and likely contain numerous additional vulnerabilities beyond CVE-2025-64775 and CVE-2025-66675. Immediate migration to supported versions is not just recommended but critical for organizational security. Legacy versions represent a fundamental security liability that exposes organizations to current and future exploitation.
Phased Remediation Implementation
Organizations unable to implement immediate patching must adopt a phased approach combining short-term mitigations with long-term remediation planning.
| Phase | Timeline | Actions | Success Criteria |
|---|---|---|---|
| Emergency Response (0-24 hours) | Immediate | Deploy WAF rules, implement rate limiting, activate monitoring alerts, establish incident response procedures | Attack detection capability, temporary protection in place |
| Critical System Patching (1-7 days) | Priority | Upgrade internet-facing and business-critical applications to patched versions, test functionality, validate security | Highest-risk systems secured, core business operations protected |
| Standard System Remediation (1-4 weeks) | Scheduled | Upgrade remaining vulnerable applications, coordinate with change management, minimize business disruption | All production systems patched, vulnerability eliminated |
| Development/Test Environment Updates (1-8 weeks) | Planned | Update non-production environments, align with development cycles, update CI/CD pipelines | Complete environment consistency, no reintroduction risk |
| Legacy System Migration (2-6 months) | Strategic | Plan and execute migration from unsupported Struts versions, application modernization, architectural improvements | Elimination of technical debt, supported framework versions |
| Continuous Validation (Ongoing) | Perpetual | Regular vulnerability scanning, version compliance monitoring, security testing, update management | Maintained security posture, rapid new vulnerability response |
Compensating Controls for Delayed Patching
When immediate patching is not feasible due to operational constraints, organizations must implement compensating security controls to reduce exploitation risk.
| Control Type | Implementation | Effectiveness | Limitations |
|---|---|---|---|
| Web Application Firewall Rules | Block or rate-limit large multipart requests, unusual upload patterns | Moderate – Can detect obvious attack patterns | Determined attackers can evade with careful request crafting |
| Request Rate Limiting | Throttle POST requests per IP, session, or user | Moderate – Slows attack progression | Does not prevent attack, only delays exhaustion |
| Disk Quota Management | Implement per-process or per-user disk quotas for temp directories | Low – May limit impact scope | Can cause legitimate functionality issues, doesn’t prevent attack |
| Network Segmentation | Restrict network access to vulnerable applications | High – Reduces attacker surface | May impact business functionality, doesn’t fix vulnerability |
| Temporary File Cleanup Scripts | Scheduled automated cleanup of old temporary files | Low – Treats symptom, not cause | Rapid attacks can overwhelm cleanup, potential data loss |
| Enhanced Monitoring and Alerting | Real-time disk usage monitoring, attack pattern detection | High – Enables rapid response | Reactive rather than preventive, requires skilled response team |
| Geographic IP Blocking | Block connections from high-risk countries or IP ranges | Low – Reduces some threat vectors | Easily bypassed with VPNs, may block legitimate users |
Compensating Controls Are Temporary
While compensating controls provide valuable risk reduction during the remediation window, they should never be considered permanent solutions. These measures reduce but do not eliminate vulnerability. Organizations must maintain pressure on patching initiatives and avoid the dangerous trap of considering compensating controls as sufficient long-term protection. The only complete solution is upgrading to patched Apache Struts versions.
Incident Response and Recovery Procedures
Attack Detection and Confirmation
Organizations suspecting active exploitation must rapidly validate whether an attack is occurring and assess its current impact.
# Emergency disk space assessment df -h du -sh /tmp /var/tmp /upload-directory find /tmp -type f -mtime -1 | wc -l # Identify potential leaked temporary files find /tmp -name "upload_*" -o -name "struts*" -o -name "*.tmp" ls -lah /tmp | grep $(date +%Y-%m-%d) # Check for unusual multipart requests in logs grep -i "multipart" /var/log/apache2/access.log | tail -100 grep -i "Content-Type: multipart" /var/log/httpd/access_log # Monitor real-time disk usage watch -n 5 'df -h | grep -E "Filesystem|/tmp|/var"' # Identify top disk consumers du -sh /tmp/* | sort -hr | head -20 lsof +L1 | grep deleted
Emergency Response Actions
| Response Action | Purpose | Implementation Steps | Considerations |
|---|---|---|---|
| Isolate Affected Systems | Prevent continued exploitation and lateral movement | Block inbound traffic at firewall, disable application access, preserve forensic evidence | May cause business disruption, requires executive authorization |
| Clear Temporary Files | Restore disk space and operational capability | Identify and remove leaked files, preserve samples for analysis, monitor for recurrence | Risk of deleting legitimate files, may require service restart |
| Implement Emergency WAF Rules | Block ongoing attack traffic | Deploy restrictive rules for multipart requests, enable aggressive rate limiting, log all blocked attempts | May impact legitimate users, requires testing |
| Capture Forensic Evidence | Support investigation and potential legal action | Preserve access logs, sample temporary files, document disk usage timeline, capture network traffic | Storage requirements, chain of custody maintenance |
| Notify Stakeholders | Ensure appropriate awareness and coordination | Alert security team, inform business leaders, prepare customer communications | Information sensitivity, regulatory disclosure requirements |
| Emergency Patching | Permanently resolve vulnerability | Deploy patches outside normal change windows, validate functionality, document emergency change | Testing limitations, risk of introducing new issues |
Long-Term Security Enhancement
Process and Architectural Improvements
Organizations should leverage this incident as a catalyst for broader security program enhancements that prevent future similar vulnerabilities.
| Improvement Area | Current Gap | Recommended Enhancement | Expected Benefit |
|---|---|---|---|
| Vulnerability Management | Reactive patching, delayed response to critical issues | Establish formal patch management program with defined SLAs, automated vulnerability scanning | Faster vulnerability identification and remediation |
| Dependency Tracking | Unclear inventory of framework versions and dependencies | Implement software composition analysis tools, maintain automated dependency inventory | Rapid impact assessment for new vulnerabilities |
| Security Testing | Limited pre-deployment security validation | Integrate SAST/DAST into CI/CD pipelines, regular penetration testing | Earlier vulnerability detection, reduced production risk |
| Framework Governance | Uncontrolled framework adoption, version sprawl | Establish approved framework list, version standardization policy | Reduced attack surface, simplified patching |
| Legacy System Management | Unsupported versions in production, unclear migration plans | Define end-of-life policies, mandatory modernization roadmaps | Elimination of unsupportable security liabilities |
| Monitoring Coverage | Limited visibility into application security events | Deploy comprehensive application security monitoring, SIEM integration | Faster attack detection and response |
Building Resilient Security Practices
The Apache Struts vulnerabilities highlight the critical importance of proactive security management. Organizations that maintain current software versions, implement comprehensive monitoring, and respond rapidly to emerging threats significantly reduce their exposure to exploitation. By investing in robust vulnerability management processes, automated security testing, and continuous monitoring, organizations can transform from reactive to proactive security postures, substantially reducing risk across their entire application portfolio.
Conclusion and Key Takeaways
CVE-2025-64775 and CVE-2025-66675 represent serious Denial of Service vulnerabilities affecting one of the most widely deployed Java web application frameworks. The file leak in Apache Struts’ multipart request processing enables unauthenticated attackers to exhaust server disk space through relatively simple exploitation techniques, potentially causing complete system unavailability.
Organizations must treat these vulnerabilities with utmost seriousness and implement remediation measures immediately. The widespread nature of Apache Struts deployment, combined with the low exploitation complexity and high impact of successful attacks, creates a critical risk scenario that demands urgent action.
Successful vulnerability management extends beyond simply applying patches. Organizations should use this incident to assess and enhance their overall security programs, focusing on vulnerability management processes, dependency tracking, security testing integration, and continuous monitoring capabilities. By building comprehensive security practices around these foundational elements, organizations can better protect themselves not only from these specific vulnerabilities but from the inevitable future security challenges that will emerge.
Essential Action Items
- Immediately identify all Apache Struts installations in your environment
- Prioritize patching internet-facing and business-critical applications to versions 6.8.0 or 7.1.1
- Implement enhanced disk usage monitoring and alerting for vulnerable systems
- Deploy compensating controls such as WAF rules and rate limiting until patching is complete
- Establish emergency response procedures for rapid disk space recovery
- Plan migration strategies for legacy unsupported Struts versions
- Conduct post-incident review to identify security program improvements
- Maintain ongoing vulnerability scanning and patch management disciplin
