CyberShell Blog | Middleware: The Overlooked Bridge Into Your Enterprise

CyberShell Research Team

Contributor context

This article was collectively prepared by the CyberShell Research Team, with notable contributions from these members.

Deirdre Hennigar

Technical analysis, subject matter expert

Marco Perretta

Technical analysis,
subject matter expert

Overview

During an external attack-surface review, the CyberShell team validated an issue involving an internet-reachable IBM webMethods Integration Server environment.

The issue was not that this middleware had file, HTTP client, logging, or integration capabilities (those capabilities are normal for an enterprise integration platform). The risk materialized because sensitive built-in services were reachable from the internet and executable without a properly scoped authenticated identity.

What is middleware?

Middleware is the software layer that helps business systems talk to each other. In many enterprises, it sits between ERP, CRM, payment systems, warehouses, SFTP partners, SaaS platforms, customer portals, and internal applications.

IBM webMethods Integration Server is part of the IBM webMethods Integration portfolio which acts as middleware for many organizations worldwide. The platform was historically developed under Software AG webMethods before IBM completed its acquisition of webMethods from Software AG in 2024. In practice, it sits between business systems and helping them exchange data, trigger workflows, transform messages, and connect internal applications with external partners.

That central position is useful for operations and attractive to attackers.

An integration server often knows:

where internal systems live
which service accounts move data
which certificates and keystores are used
how files are named and transferred
which partner endpoints are trusted
which jobs run in production
which logs contain the evidence of those workflows

Exposure snapshot

As a point-in-time example, a Censys search for HTTP body content referencing IBM webMethods returned 22 internet-exposed hosts worldwide, including 2 in Canada.

A sample dataset of publicly-accessible hosts which return 'IBM webMethods' within their http body content. — **Figure 1:** Censys exposure snapshot for IBM webMethods-related HTTP indicators. Counts are point-in-time search results and should be interpreted as public exposure signals, not confirmed vulnerable infrastructure.

This is just one offhanded query for potential targets specific to IBM / AG Software webMethods middleware; a great deal of servers are hardened to omit/obfuscate the fact that a specific software is present.

Example Censys queries:

host.services.endpoints.http.body:"IBM webMethods"
(host.services.port:5555 or host.services.port:5543 or host.services.port:9999 or host.services.port:8585) and host.services.endpoints.http.body:"webMethods"

TLDR Tips

Review and treat exposed middleware as a privileged security boundary.

Access controls

Restrict internet access to specified source IPs.
Remove anonymous/default execution from sensitive services.
Use least-privilege ACLs for built-in file, client, diagnostic, and admin functions.

Containment controls

Deny outbound middleware egress by default.
Treat logs as sensitive data stores.
Rotate keys, passwords, SFTP credentials, and service-account secrets after file-read exposure.

For each internet-reachable integration server, ask:

Can an unauthenticated, default, guest, or broad group execute any sensitive service?
Can the platform read arbitrary filesystem paths or expose server logs?
Can the server initiate HTTP or HTTPS requests to internal networks?
Are SFTP, FTPS, SSH, API, SaaS, or keystore credentials stored locally?
Are local privilege escalation (LPE)-relevant hosts prioritized based on exposure and credential access, not just CVSS?

So what happened?

A file-read service could retrieve local filesystem content and an HTTP client service could make outbound requests from the integration server. Both capabilities are normal in middleware. The problem was that they were reachable from the internet and executable without a properly scoped identity.

An unauthenticated external user could interact with middleware services that should have required a named administrative or designated service account. From there, the platform returned sensitive local files, including operating system metadata, application configuration, user configuration, startup details, and server logs.

The validated exposure created a chain of risk that included the ability to:

read operating system and application configuration files
recover credential material and password-bearing configuration
inspect transaction logs with sensitive business context
use the middleware server to reach internal applications
identify file-transfer workflows connected to third-party services
create a credible path from perimeter exposure to credential exposure, internal reachability, and local privilege escalation (LPE) risk

This is where middleware exposure becomes more than a single misconfiguration. The platform can become a discovery layer for attackers: local configuration, logs, credentials, service identities, partner workflows, and internal application paths can all become visible from one exposed system.

Those files revealed enough to understand the environment:

Configuration

Runtime settings, package paths, file-read protections, transport options, and security controls.

Server logs

Workflow names, errors, request context, and transaction breadcrumbs.

Identity clues

User stores, group mappings, service accounts, privileged naming patterns, and broad execution contexts.

Credential material

Hashes, keys, keystore references, and password-bearing configuration.

Transfer workflows

File movement patterns, partner paths, automation context, and integration package references.

Internal targets

Hostnames, internal URLs, reachable applications, and routing hints.

This is why middleware findings can escalate quickly. A file-read issue on a normal web server may expose application code or configuration, but a file-read issue on an integration server can expose the map of how the business moves data.

Why logs are important

Server logs are not just troubleshooting records.

On integration platforms, logs become a business-process transcript. They may contain workflow names, internal hostnames, usernames, request metadata, partner identifiers, error traces, payment-processing context, file names, transfer status, and partial transaction data.

Even when logs do not contain full secrets, they answer questions like:

Which systems are real production dependencies?
Which workflows move sensitive data?
Which accounts are used for automation?
Which third-party/partner paths are active?
Which errors reveal credentials, certificates, or internal URLs?
Which targets are worth testing next?

Internal reachability exposure

The exposed middleware service also allowed outbound HTTP requests to be initiated by the integration server.

That is important because the request no longer comes from the attacker; it comes from a trusted server already placed near internal business systems.

In the validated chain, the middleware host could reach an internal enterprise application that was not directly exposed to the internet. The risk here was server-side request forgery (SSRF), where an attacker can cause a trusted server to make requests on their behalf.

This did not require credential use or intrusive enumeration. A single low-noise request was enough to prove that the integration server could act as a bridge from the public internet to an internal application surface.

01 External trigger

Public service call

Unauthenticated request
Default execution context
HTTP method and target URL supplied by caller

02 Trusted middleware hop

Server-side HTTP client

Request originates from integration host
Uses middleware network position
Bypasses normal internet-to-internal boundary

03 Internal response

Enterprise application surface

Internal web application banner
Login page or app response
Evidence of reachable non-public system

Where identity and access management enters the picture

Identity and access management (IAM) is impactful in this kind of scenario in several ways.

Execution context

Anonymous or default execution is an identity problem. A production integration service should not treat an unauthenticated internet user as a principal that can invoke sensitive built-in functions.

Broad groups

Names like Everyone, Anonymous, Default, Guests, or broad operator groups should be treated as high-risk when attached to file, HTTP client, diagnostic, deployment, administrative, or package-management capabilities.

Middleware also frequently stores or references service identities. Those accounts may connect to ERP systems, file-transfer services, SaaS platforms, payment processors, monitoring tools, or internal administration layers.

If the middleware host exposes user stores, password hashes, keys, keystore passwords, or workflow credentials, the issue becomes a much larger credential compromise event.

Where local privilege escalation fits

Local privilege escalation (LPE) gets attention here because it can turn a foothold into administrative control.

An attacker who can read sensitive files, recover keys, inspect local users, identify service accounts, or reach internal systems may not have root or administrator access yet — but they may have enough context to exploit a local privilege escalation bug, weak file permission, exposed key, or service-account configuration mistake.

Review question: If this middleware host were abused by an anonymous external user, what would it reveal, where could it connect, and which identities could it expose?

Attack path summary

The risk was not created by one isolated issue. It emerged from the way several exposed capabilities connected together.

The externally reachable middleware service exposed local files. Those files revealed configuration details, identity context, credential material, server logs, and workflow information. The same middleware position also allowed internal HTTP reachability, meaning the server could act as a trusted bridge toward internal application surfaces.

In practical terms, the attack path moved from public exposure to local context, from local context to credential and workflow visibility, and from there toward internal reachability and privilege-escalation risk.

That is what makes middleware exposure so dangerous: it can connect file disclosure, identity exposure, internal access, and trusted partner workflows from one system.

Attack path diagram showing internet-exposed middleware leading to sensitive local context, credentials or internal reach, and local privilege escalation opportunity. — **Figure 2:** Middleware exposure can connect several risk components: public service access, local context disclosure, credential exposure or internal reachability, and local privilege escalation opportunity.

What should we do?

Reduce exposure

External access to middleware should be narrow by default. If a B2B integration platform must be reachable from partners, restrict it to required source IPs, ports, hostnames, and services.

Do not expose administrative, diagnostic, file, proxy, or generic client capabilities on the same public surface.

Lock service execution

Review built-in services that can read or write files, execute commands, make HTTP requests, open sockets, manage packages, view logs, administer users, inspect configuration, or test connectivity.

In IBM webMethods Integration Server environments, pay close attention to file utilities, HTTP client services, package management, diagnostics, and any service mapped to Anonymous, Default, Everybody, guest, public, or broad user groups.

Restrict outbound paths

Middleware often needs to connect to internal and external systems, but it should not have unlimited egress.

Allow only approved destinations required by documented workflows, especially for internal apps, admin interfaces, databases, file transfer, and cloud control planes.

Rotate and reduce

If file reads are accessible through the internet, assume local secrets have been accessed at some point.

Rotate exposed keys, keystore passwords, SFTP credentials, service-account passwords, and application secrets. Remove sensitive values from logs and shell command history.

IBM webMethods Integration Server remediation examples

The exact settings and access-control model will vary by environment, version, and operational requirements, but the following examples show the kinds of controls defenders should review for IBM webMethods Integration Server environments.

Harden server configuration

Review server.cnf settings that affect file access, outbound connectivity, TLS enforcement, and fallback network behaviour.

watt.security.pub.getFile.checkReadAllowed=true
watt.net.ssl.client.hostnameverification=true
watt.net.jsse.client.enabledProtocols=TLSv1.2
watt.net.jsse.server.enabledProtocols=TLSv1.2
watt.net.proxy.fallbackToDirectConnection=false

These settings help reduce arbitrary file-read risk, enforce stronger TLS behaviour, and prevent proxy bypass through direct outbound connections.

Remove anonymous execution

Review users.cnf and confirm how the Default principal is mapped. If Default is associated with Anonymous or Everybody, sensitive services may become executable by unauthenticated or overly broad users.

Remove Anonymous from Default.
Remove Everybody where operations allow.
Replace broad execution contexts with named administrative or service identities.

Internet-reachable users should not inherit execution rights to sensitive middleware services through default or anonymous mappings.

Restrict service access-control lists

Review Integration Server access-control lists (ACLs) for built-in services that can read files, make outbound requests, inspect configuration, manage packages, view logs, or perform diagnostic actions.

Remove Anonymous, Everybody, and Default from sensitive service ACLs.
Restrict pub.client:http and other pub.client:* services to a named admin or service ACL.
Apply the same review to file, diagnostic, admin, package-management, and logging services.

Built-in services should be treated as privileged capabilities, especially when the server is reachable from the internet or trusted partner networks.

Closing thoughts

Middleware is where business trust gets automated.

When configured poorly, it can reveal credentials, internal topology, transaction context, partner workflows, and privileged identities from a single location.

To harden middleware:

restrict inbound access,
remove anonymous execution,
lock down built-in services,
deny outbound access by default,
protect logs as sensitive data,
rotate exposed credentials,
and include middleware hosts in local privilege escalation (LPE)-driven patch prioritization.

Supply chain, identity, and local privilege escalation are often discussed as separate security topics. In real enterprise environments, middleware connects all three.

Middleware: The Overlooked Bridge Into Your Enterprise