Exposed WSO2 SOAP Services and Path Traversal: How a File Management Endpoint Led to Unauthenticated Local File Read

• Attack Surface
• Offensive Security
• Red Teaming

Enterprise integration platforms often expose more functionality than security teams expect: legacy SOAP services, service discovery pages, file-handling operations, internal methods, and integration endpoints that may not have been designed for direct internet exposure.

When these components are deployed without strict access control and input validation, a single exposed method can become a direct path to sensitive system files.

In one recent penetration test, Velstadt’s offensive security team identified a high-impact vulnerability in a deployment based on WSO2 services that allowed unauthenticated access to sensitive internal files.

The issue was caused by an exposed SOAP endpoint that did not properly validate user input and did not require authentication, creating a direct entry point into the system. During the initial reconnaissance phase, the team also discovered that the /services endpoint was publicly accessible. This endpoint provided a full listing of available services and methods, effectively exposing the internal attack surface of the application.

Such visibility makes it significantly easier for an attacker to understand how the system works and identify potentially dangerous functionality without prior knowledge or valid access.

This case study explains how an exposed WSO2 SOAP service, weak access control, and insufficient path validation resulted in unauthenticated local file read through path traversal. The engagement is anonymized, and technical details are preserved for educational purposes.

TL;DR — Key Takeaways

• Vulnerability: Unauthenticated path traversal in a WSO2 SOAP-based file management service.
• Impact: An external attacker could read sensitive local files from the underlying operating system.
• Discovery path: A publicly accessible /services endpoint exposed available services and operations, helping identify file-handling functionality.
• Root cause: The service accepted a user-controlled file_name parameter and returned file contents without proper authentication or path validation.
• Sensitive exposure: The team was able to retrieve the system’s .bash_history file, which may contain commands, credentials, tokens, internal paths, and operational details.
• Risk level: High-impact and potentially critical, depending on accessible files, exposed secrets, service privileges, and the surrounding infrastructure.
• Main lesson: File-handling functionality should not be exposed without authentication, authorization, strict input validation, and controls that ensure requested files remain within an approved directory.

Why This Finding Matters

Path traversal vulnerabilities are sometimes underestimated because they may appear less severe than vulnerabilities that immediately result in remote code execution. However, when a vulnerable service can read sensitive local files, the practical impact can be significant.

A local file read issue may expose configuration files, credentials, application secrets, logs, shell history, private keys, source code, deployment paths, or internal system details. This information may help an attacker better understand the environment and identify follow-on attack paths.

In this case, the risk was increased by three conditions:

• the service was reachable over the network;
• the vulnerable file management operation did not require authentication;
• the /services endpoint exposed available services and methods, reducing the effort required to identify sensitive functionality.

Individually, each condition increases exposure. Combined, they created a direct path from external reconnaissance to unauthorized local file access.

Engagement Context

The target environment used WSO2-based services to support enterprise integration and service exposure.

During the assessment, Velstadt focused on externally reachable functionality, exposed service methods, authentication boundaries, and whether available operations could be abused to access local files or sensitive system resources.

The finding demonstrates why integration platforms and SOAP-based services should be reviewed as part of the organization’s external attack surface, not only as backend middleware.

Technical Breakdown

Step 1 — Discovering the Public /services Endpoint

During reconnaissance, the /services endpoint was found to be publicly accessible.

This endpoint provided a listing of deployed services and available methods. From an attacker’s perspective, this type of exposure reduces uncertainty: instead of guessing available operations, the attacker can directly review what the platform exposes.

A public service listing is not always a vulnerability by itself. However, it can become a meaningful risk multiplier when it exposes sensitive operations or when access control is inconsistent.

Step 2 — Identifying File Management Functionality

The vulnerable functionality was part of a file management service that accepted a file name parameter and returned its contents.

This type of feature requires careful security design. Any service that reads files based on user-controlled input should enforce authentication, authorization, strict input validation, and safe file path handling.

In this case, the service accepted a file_name parameter. Because the parameter was not properly sanitized, it was possible to manipulate the requested path using directory traversal sequences.

Step 3 — Exploiting Path Traversal Through SOAP

By sending crafted SOAP requests, the team was able to move outside the intended directory and access files from the underlying operating system.

The vulnerable SOAP endpoint allowed the file path parameter to be modified using traversal patterns such as:

../../../../

By injecting traversal sequences into the file_name parameter, the request could escape the intended application directory and retrieve files from other parts of the server.

This is best described as path traversal leading to local file read.

Although some teams may broadly describe this type of issue as LFI, the confirmed behavior in this case is more accurately classified as path traversal / directory traversal leading to local file read. The engagement confirmed unauthorized access to local files, not local file inclusion, remote file inclusion, or code execution in the application runtime.

Step 4 — Reading Sensitive Local Files

One of the most impactful findings was the ability to retrieve the contents of the system’s .bash_history file.

This file can contain previously executed shell commands. In real environments, shell history may accidentally expose credentials, access tokens, API keys, internal paths, hostnames, database connection strings, deployment commands, administrative scripts, or other operational details.

Access to this information can significantly increase an attacker’s understanding of the environment. Even if the file does not contain active credentials, it may still reveal how systems are administered and which internal components may be worth targeting next.

Severity Classification

The exact severity depends on the environment, the privileges of the service account, the sensitivity of accessible files, and whether exposed data includes valid credentials or secrets.

Severity Factor	Assessment
Attack Vector	Network / Web-accessible SOAP endpoint
Authentication Required	None
User Interaction	None
Attack Complexity	Low once the exposed service and vulnerable parameter are identified
Confirmed Impact	Unauthorized local file read
Potential Impact	Exposure of credentials, tokens, internal paths, configuration files, operational details, and information useful for follow-on attacks
Primary Weakness	Path traversal / directory traversal in an unauthenticated SOAP file management service
Contributing Misconfiguration	Publicly accessible /services listing and exposed SOAP functionality without authentication
Practical Outcome	Local file read
Risk Level	High-impact; potentially critical depending on accessible files, exposed secrets, service privileges, and surrounding infrastructure

This finding should be prioritized for remediation because the affected SOAP functionality was externally reachable, did not require authentication, and allowed unauthorized access to sensitive local files.

Root Cause Analysis

The finding resulted from several control failures occurring together:

1. Public exposure of service discovery
   The /services endpoint was accessible without restriction and exposed available services and methods.
2. Missing authentication on sensitive functionality
   The exposed SOAP file management functionality did not require authentication.
3. Insufficient validation of the file_name parameter
   The service accepted a user-controlled file name parameter and returned file contents without properly sanitizing the input.
4. Lack of safe path enforcement
   Directory traversal sequences allowed the request to move outside the intended directory instead of being constrained to an approved file location.

Technical Remediation Guide

The recommendations below focus on the confirmed weakness: unauthenticated path traversal in exposed WSO2/SOAP file-handling functionality, which allowed unauthorized local file read.

1. Restrict Exposure of Service Discovery and SOAP Endpoints

Public service listings and SOAP methods should be restricted unless there is a clear operational requirement to expose them.

Recommended actions:

• restrict access to /services to trusted networks, authenticated users, or approved service consumers;
• disable public service listing if it is not required;
• review exposed WSO2 services and remove unused or legacy methods;
• ensure internal-only services are not publicly reachable;
• monitor access attempts to service discovery endpoints, especially from unknown sources or unusual user agents.

2. Require Authentication and Authorization for File-Handling Operations

File retrieval functionality should not be available to anonymous users.

Recommended actions:

• enforce authentication on the affected SOAP file management functionality;
• apply authorization checks before returning file contents;
• ensure users or service consumers can access only files they are explicitly allowed to retrieve;
• log successful and failed file access attempts.

3. Implement Safe Path Handling

Simple string filtering is not sufficient for path traversal prevention. A safer implementation should ensure that user-controlled input cannot escape the approved file location.

Recommended actions:

• resolve requested files to canonical absolute paths;
• verify that the resolved path remains inside an approved base directory;
• reject absolute paths;
• reject unexpected paths, traversal sequences, and encoded traversal variants after normalization/canonicalization;
• use allowlists of expected file names or server-side file identifiers where possible;
• avoid passing raw user input directly into file system APIs.

4. Review Exposed Files and Rotate Affected Secrets

Because the testing team was able to retrieve .bash_history, the organization should verify whether sensitive operational data was exposed. Shell history files may contain executed commands, credentials, tokens, internal paths, and other operational details that can support follow-on attacks.

Recommended actions:

• review retrieved and potentially accessible files for credentials, tokens, keys, and internal details;
• rotate any secrets that may have been exposed;
• remove secrets from shell history and operational scripts;
• review configuration files for hardcoded credentials and migrate them to a dedicated secrets management solution;
• review whether the service account has unnecessary read access to sensitive files.

5. Add Detection and Monitoring

Preventive fixes should be supported by monitoring for similar exploitation attempts. WAF or reverse proxy rules can help detect and block common path traversal payloads as an additional defense layer. However, they should not replace the primary fix: authentication, authorization, and safe path handling in the affected application logic.

Recommended actions:

• monitor for traversal patterns such as ../, encoded path separators, and unusual file names;
• configure WAF or reverse proxy rules to detect and, where appropriate, block common path traversal payloads;
• alert on attempts to access sensitive files such as .bash_history, /etc/passwd, SSH keys, environment files, and application configuration files;
• correlate WSO2 logs with relevant telemetry sources, such as reverse proxy, WAF, EDR, and SIEM logs where available;
• review historical logs to determine whether similar requests occurred before the penetration test.

Remediation Priorities

Priority 1 — Reduce Immediate Exposure

Restrict or temporarily disable access to the vulnerable SOAP endpoint, restrict public access to /services, require authentication for file management operations, review recent logs for suspicious file access attempts, and configure WAF or reverse proxy rules to detect and, where appropriate, block common path traversal payloads as an additional defense layer while the application-level fix is being implemented.

Priority 2 — Fix the Vulnerable Logic

Implement safe path validation, ensure resolved paths remain inside an approved directory, reject traversal payloads and encoded variants after normalization/canonicalization, and replace direct file name input with controlled server-side file identifiers where possible.

Priority 3 — Limit the Impact of Similar Issues

Review file permissions, reduce privileges of the service account, rotate exposed credentials or tokens, remove secrets from shell history and operational scripts, and review configuration files for hardcoded credentials.

Priority 4 — Improve Long-Term Resilience

Review WSO2 hardening configuration, include SOAP services and legacy endpoints in future penetration testing scope, document ownership of exposed services, and improve centralized logging and alerting for suspicious service access.

Frequently Asked Questions (FAQ)

Can authentication alone fix this issue?

No. Authentication reduces exposure, but it does not fix unsafe file handling. If the application still accepts user-controlled file paths without safe validation, an authenticated user may still be able to abuse the same path traversal flaw. The fix should combine authentication, authorization, and safe path validation.

How can developers prevent path traversal in file-handling functionality?

Developers should avoid passing raw user input directly into file system operations. A safer approach is to use server-side file identifiers, allowlists of expected files, canonical path validation, and checks that ensure the resolved file path remains inside an approved directory.

Should service discovery endpoints be disabled completely?

Not always. Some environments may need service discovery for operational reasons. However, service listings should not be publicly accessible by default. Access should be restricted to trusted users, trusted networks, or approved service consumers.

Can a WAF be enough to prevent this type of vulnerability?

No. A WAF or reverse proxy can help detect and block common traversal payloads, but it should be treated as an additional defense layer. The primary fix is secure application logic: authentication, authorization, safe path handling, and least-privilege access.

References and Sources

• OWASP: Path Traversal
• PortSwigger: File path traversal 
• OWASP WSTG: Testing Directory Traversal File Include
• OWASP: Input Validation Cheat Sheet
• NIST SP 800-115: Technical Guide to Information Security Testing and Assessment
• CWE-22: Improper Limitation of a Pathname to a Restricted Directory
• CWE-306: Missing Authentication for Critical Function
• CWE-200: Exposure of Sensitive Information to an Unauthorized Actor
• MITRE ATT&CK: T1083 — File and Directory Discovery
• MITRE ATT&CK: T1552 — Unsecured Credentials