Hacking Websphere


Notes on how I approach HCL (IBM) WebSphere servers.

Hunting for WebSphere servers

IBM WebSphere (now owned by HCL) is a Byzantine beast of a content management system. However, this works in our favor, because there are some unique paths that one can look for to locate WebSphere servers.

The WebSphere Portal and WebSphere Content Manager (WCM) both tend to have URL paths that begin with /wps/.

The Portal tends to be (but isn’t always) pathed as /wps/portal/, whereas WCM is usually pathed as /wps/wcm/.

This means that dorks looking for these path elements are likely to uncover WebSphere servers.

Typical backend login pages

There are multiple ways to authenticate to WebSphere: as a normal user as part of the content in the Portal, or as a user with some manner of possibly elevated privileges in the administrative interfaces. Some of these login paths include:

  1. /wps/portal/home/myloginpage
  2. /wps/portal/home/welcome
  3. /wps/wcm/webinterface/login/login.jsp

Authenticating against any of these may take you into one of the administrative interfaces of WebSphere.

Finding the Friendly Path

WebSphere helpfully provides web content developers with the ability to create “friendly paths” for URLs rather than constantly relying on the complex paths that WebSphere works with by default. Even more helpfully, WebSphere provides a search function on a special page that allows one to search for friendly paths.

While this functionality is interesting in and of itself, the best use of the Friendly Path Disambiguation page is the “Sign Up” button that may be present at the top of the page, next to the “Log In” button. Sometimes, poorly-configured WebSphere servers will simply let you create an administrative account that may then be used to authenticate against one of the above paths.

Sometimes, however, account creation will generate an error message, such as:

EJPSG0015E: Data Backend Problem com.ibm.websphere.wim.exception.WIMApplicationException: CWWIM4508E Virtual member manager failed to write to the '/opt/IBM/WebSphere/wp_profile/config/cells/dmgrCell01/fileRegistry.xml' file: 'CWWIM6009E All updates must be performed at the deployment manager and not at a managed node.'.

You’d think that this means the account creation failed, right?


If you examine the error message closely, it specifically states that the system was unable to write to a file. However, the new account still exists in memory, and will persist until the server is restarted. So, when you see an error like this after attempting to create a new account, you can still successfully authenticate against one of the paths above, or by using the “Log In” button at the top of the Friendly Path Disambiguation page.

Note that it is possible (and, from a defensive perspective, desireable) to disable account creation and eliminate the “Sign Up” button altogether. So it may not always be present.

Here are some paths that may result in reaching a Friendly Path Disambiguation page with a “Sign Up” button:






User Enumeration

You can obtain the attributes for the current user by visiting /wps/contenthandler/um/secure/currentuser/profiles?expandRefs=true

A list of all user attribues can be found here: /wps/contenthandler/um/secure/attributes/users

Users can be enumerated via the PUMA REST module (documented here), via a path that looks something like:


You may, of course, perform a more specific search by using something other than a wildcard for the uid parameter.

Random Notes
  • Always check the globe drop-down menu in the upper right corner, particularly when you change pages. You may find links to other parts of the system that you previously didn’t have access to.
  • The WebSphere version is available at /wps/contenthandler/wcmrest/ProductVersion/
  • A list of all REST endpoints is available at /wps/mycontenthandler/model/service
  • REST documentation can be found here
  • Paths for unauthenticated vs. authenticated content can be distinguished via the prefix “my” in the path. For example, /wps/portal/ is an unauthenticated path, whereas /wps/myportal/ typically requires authentication.
  • OIDs can be accessed directly via a path of the form /wps/contenthandler/?uri=nm:oid:<OID GOES HERE>. Here is a list of several OIDs:
 editLayout : "ibm.portal.Content"
 MainPage: "wps.content.root"
 editPageProperties : "ibm.portal.Page Properties"
 assignRoles : "ibm.portal.Resource Permissions"
 editAppProperties: "ibm.portal.Template and Application Properties"
 editAppLayout: "ibm.portal.Template and Application Layout"
 assignAppRoles: "ibm.portal.Application Roles"
 assignAppMembers: "ibm.portal.Application Membership"
 showAppPolicyStatus: "ibm.portal.Policy Status"
 hiddenPages: "ibm.portal.HiddenPages"

Occasionally, these may require something other than a URI parameter beginning with nm. Some other options are:

HowToRed TeamBug bounty