Apache Struts CVE-2017-5638 module fails to detect vulnerability on Struts 2.5.10 instance

[08062003]

Description:
The apache_struts_vuln module in Nettacker 0.4.0 fails to detect the Apache Struts CVE-2017-5638 Remote Code Execution vulnerability on a known vulnerable Struts 2.5.10 server setup (http://192.168.29.62:8080/struts2-showcase/fileupload/upload.action).

Despite confirmed manual curl tests proving the vulnerability exists and that the server executes injected commands, Nettacker reports:

text
[+] there are no events exist to create a report! skipping this section.
and no vulnerability detection.

Steps to reproduce:
Set up or point Nettacker scan to http://192.168.29.62:8080/struts2-showcase/fileupload/upload.action.

Run Nettacker scan with command:

text
python3.11 /home/kali/Nettacker/nettacker.py -i http://192.168.29.62:8080/struts2-showcase/fileupload/upload.action -m apache_struts_vuln -d -vvv
Observe that Nettacker fails to detect the vulnerability even though the server is vulnerable.

Confirm manually the vulnerability using curl with OGNL payload in the Content-Type header triggering remote command execution.

Expected behavior:
The module should detect the vulnerability and produce evidence detailing the command execution output or injected header indicators.

A proper report with the vulnerability details should be generated.

Actual behavior:
Nettacker does not detect the vulnerability.

Logs contain the message:

text
[+] there are no events exist to create a report! skipping this section.
No scanned vulnerabilities reported despite the vulnerable server.

Additional information:
Possible cause: multipart payload formatting mismatch or incorrect detection conditions on response.

The multipart request requires strict CRLF line endings and exact boundary matching.

Manual tests confirm the server is vulnerable.

Nettacker payload may require adjustments to send properly formatted multipart bodies (CRLF) and improved response checks (including command output in response body).

Suggested fixes / workarounds:
Update apache_struts_vuln payload to send exact CRLF multipart bodies.

Include body content regex detection for command output (e.g., uid=...) in addition to header detection.

Improve logging or debugging output in Nettacker to inspect raw server responses during scans.

Environment:
Nettacker version: 0.4.0 QUIN

Target OS: Apache Tomcat hosting Struts 2.5.10 Showcase on Debian-based system

Test executed on Kali Linux with Python 3.11

[Rohankaf]

@arkid15r pls assign me that

[securestep9]

Hey @Rohankaf - assigned to you. This was an old module for an old CVE which probably did not get property tested when we migrated from v0.0.2 to v0.0.3

[08062003]

Subject: URGENT: Module Compatibility & Apache Struts 2.5.10 Module for OWASP Nettacker v0.4.0 I urgently require assistance regarding OWASP Nettacker v0.4.0 for a critical project deadline. I have two main requests: Legacy Module Compatibility: Please confirm if older vulnerability modules are compatible and executable within the latest Nettacker v0.4.0 architecture. Apache Struts 2.5.10 Module: I need a functional YAML Vulnerability Module (or confirmation of an existing one) for Nettacker v0.4.0 that can successfully detect known Remote Code Execution (RCE) vulnerabilities in Apache Struts 2.5.10. Providing a sample or the required YAML module is critical for me to meet my project timeline. Your prompt attention and response on this matter are highly appreciated. Thankyou.

…

On Tue, 18 Nov 2025, 04:21 Sam Stepanyan, ***@***.***> wrote: *securestep9* left a comment (OWASP/Nettacker#1170) <#1170 (comment)> Hey @Rohankaf <https://github.com/Rohankaf> - assigned to you. This was an old module for an old CVE which probably did not get property tested when we migrated from v0.0.2 to v0.0.3 — Reply to this email directly, view it on GitHub <#1170 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/BC6BSRPEH7RWCGIEKOG4X3335JGOBAVCNFSM6AAAAACMLZEW4WVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZTKNBUGE4DINBYGQ> . You are receiving this because you authored the thread.Message ID: ***@***.***>

[08062003]

@securestep9 could you please rather tell me which vuln yaml module can be executed successfully?

[Rohankaf]

@securestep9 Hi, I’ve implemented a working apache_struts_vuln module for detecting CVE-2017-5638 (tested standalone and confirmed on a vulnerable Struts 2.5.10 instance).

While preparing the PR, I noticed that the framework attempts to import several database backends (mysql, postgresql, mssql, oracle, sqlite) even when a backend is not enabled. In the current repo structure some of these modules don’t exist, which causes the framework to stop loading modules before reaching mine.

Could you please clarify the expected structure for database backend files so I can align the implementation with Nettacker’s architecture?

Once I get the correct direction, I’ll finalize the integration and update the PR accordingly.

Thanks!

[08062003]

The expected structure for database backend files in OWASP Nettacker is closely tied to its modular and extensible architecture, supporting both SQLite and MySQL databases for result storage and operational data. Backend files and configurations should align with the following key expectations: Database Backend Structure in Nettacker - *Supported Databases*: Nettacker natively supports SQLite (default, local file-based) and MySQL for storing scan results and operational data. The default SQLite database is typically located at .nettacker/data/nettacker.db.github <https://github.com/OWASP/Nettacker> - *Configuration Handling*: Database credentials and configuration settings are not hardcoded. They are typically handled via configuration files, environment variables, or CLI switches. Sensitive configuration data should be protected and excluded from version control systems. cheatsheetseries.owasp+1 <https://cheatsheetseries.owasp.org/cheatsheets/Database_Security_Cheat_Sheet.html> - *Directory Organization*: - Database files are stored under the .nettacker/data/ directory, ensuring separation from application logic and modules.github <https://github.com/OWASP/Nettacker> - The directory structure may include subfolders for results and reports, for example: .nettacker/data/results/ for scan reports. - *Schema Expectations*: - Tables are designed for storing hosts, scan results, vulnerabilities, module logs, and user/session information for the API if running in web mode.github <https://github.com/OWASP/Nettacker> - Schema will have columns for task metadata, target IP, module name (e.g., apache_struts.yaml), timestamps, vulnerability details, and output/report links.nettacker.readthedocs+1 <https://nettacker.readthedocs.io/en/0.4.0/Home/> Alignment with Nettacker’s Modular Architecture - *YAML-Based Modules*: Each scan module, like apache_struts.yaml, defines scan logic and report structure in YAML. Results from such modules are standardized and written to the central database according to the backend schema and JSON/TXT/HTML reporting logic.nettacker.readthedocs+1 <https://nettacker.readthedocs.io/en/latest/Home/> - *Pluggable Backends*: You can switch backend databases via configuration rather than code changes, maintaining separation between logic and storage. - *Safe File Layout*: Credentials, configuration, and database files are ideally placed outside the web root or user-facing directories for security. cheatsheetseries.owasp <https://cheatsheetseries.owasp.org/cheatsheets/Database_Security_Cheat_Sheet.html> Practical Steps for Implementation - Follow the example of the default SQLite database file: .nettacker/data/nettacker.db. - Ensure that any new backend/connector implements Nettacker’s abstraction for ORM or raw SQL operations as used in its main logic. - Reference module outputs against the defined database tables, mapping vulnerability findings to structured fields like type, description, severity, and evidence. - Use environment variables or an external configuration file (YAML, JSON, or .env) for database connection strings if using MySQL.github <https://github.com/OWASP/Nettacker> - Store scan results in per-run or cumulative result tables, with clear foreign key links between scan sessions and discovered vulnerabilities. This modular and secure approach ensures Nettacker components interoperate correctly, and enables easy reporting, auditing, and integration with additional tools or dashboards.

…

On Tue, 18 Nov 2025 at 18:35, rohankaf ***@***.***> wrote: *Rohankaf* left a comment (OWASP/Nettacker#1170) <#1170 (comment)> @securestep9 <https://github.com/securestep9> Hi, I’ve implemented a working apache_struts_vuln module for detecting CVE-2017-5638 <https://github.com/advisories/GHSA-j77q-2qqg-6989> (tested standalone and confirmed on a vulnerable Struts 2.5.10 instance). While preparing the PR, I noticed that the framework attempts to import several database backends (mysql, postgresql, mssql, oracle, sqlite) even when a backend is not enabled. In the current repo structure some of these modules don’t exist, which causes the framework to stop loading modules before reaching mine. Could you please clarify the expected structure for database backend files so I can align the implementation with Nettacker’s architecture? Once I get the correct direction, I’ll finalize the integration and update the PR accordingly. Thanks! — Reply to this email directly, view it on GitHub <#1170 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/BC6BSRPXUEL3NA6YIAE3AAL35MKTBAVCNFSM6AAAAACMLZEW4WVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZTKNBXGU3DSMRYGA> . You are receiving this because you authored the thread.Message ID: ***@***.***>