SecPod

Learn Search

Search across all Learn content

← Back to Security Research
CVE-2013-5400: Analysis Of Authentication Bypass Vulnerability in IBM Platform Symphony

CVE-2013-5400: Analysis Of Authentication Bypass Vulnerability in IBM Platform Symphony

IBM Platform Symphony Developer Edition is a free software to develop and test High-performance computing (HPC) and Grid Computing SDK, which pool out your technical computing resources to run big data and/or compute-intensive problems. CVE-2013-5400 is an authentication bypass vulnerability in IBM ...

Feb 23, 2014By Shashi Kiran3 min read

IBM Platform Symphony Developer Edition is a free software to develop and test High-performance computing (HPC) and Grid Computing SDK, which pool out your technical computing resources to run big data and/or compute-intensive problems. CVE-2013-5400 is an authentication bypass vulnerability in IBM platform symphony. However, these vulnerabilities can be remediated by using a vulnerability management software.

Screenshot from 2014-02-21 18:27:34
Screenshot from 2014-02-21 18:27:34
login-code
login-code
cred2
cred2

Vulnerability Description:

The “login.jsp” servlet in IBM Platform Symphony Developer Edition (DE) 5.2 and 6.1.x through 6.1.1 has hard coded credentials. It allows remote attackers to bypass authentication and obtain “local environment” access. However, CVE-2013-5400 can be avoided using the right patch management tool.

We tested authentication bypass successfully on IBM Platform Symphony Developer Edition Version 6.1.1

Below is a start-up image of IBM Platform Symphony Developer Edition. When we click on the button “Access Console”, it directly redirects us to the main Symphony Applications page without asking for authentication as done by CVE-2013-5400.

Below image shows up the main IBM Symphony Applications page with an demo application “symping6.1.1” running.

Lets analyse what’s happening in the backend by sniffing the network traffic.Below is the request and response captured, when “Access Console” button is clicked on the startup page.

plaintext
GET /platform/dealUserLogin.do HTTP/1.1

Check out the cookie section “DE_GUIplatform.username=”OG0Q3YUPHWw=”;” “DE_GUIplatform.password=”OG0Q3YUPHWw=”;”

The “/platform/dealUserLogin.do” which actually is an “index.jsp” a servlet page. It sets the username and the password in the cookie and sends it to “login.jsp” servlet page.

Now lets see how “login.jsp” servlet handles the cookie. The servlet “login.jsp” is setting up username variable (userName) and password variable (userPwd) value from the cookie as show in the below picture.

And then it’s assigning variable value “userName” to “userToken”.

plaintext
userToken = userName;

Now let’s check the HTML form part in “login.jsp”

plaintext
<form name=”loginform” method=”post” action=”<%=loginUrl%>”
style=”display: none”>
<input id=”j_username” name=”j_username”
value=”<%=userRole%><%=userToken%>” /> <br /> <input
id=”j_password” name=”j_password” value=”<%=userPwd%>” /> <input
type=”submit” value=”OK” name=”b1? />
</form>

As we can notice from the above code, the servlet is hard-coding username and password values. Therefore, Its creating USERNAME value by making use of “userRole” and “userToken” (which is userName) and PASSWORD value as userPwd. 

plaintext
<input id="j_username" name="j_username" value="<%=userRole%><%=userToken%>" />
<inputid="j_password" name="j_password" value="<%=userPwd%>" />

Next it sends a POST request to “/symgui/j_spring_security_check” as shown below

plaintext
POST /symgui/j_spring_security_check HTTP/1.1
Host: 192.168.1.26:18080
User-Agent: Mozilla/5.0 (X11; Ubuntu; Linux i686; rv:14.0) Gecko/20100101 Firefox/14.0.1
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8
Accept-Language: en-us,en;q=0.5
Accept-Encoding: gzip, deflate
Connection: keep-alive
Referer: http://192.168.1.26:18080/symgui/login.jsp?
Cookie: JSESSIONID=46957C6AF61C9E6A47D5F1DD58FEED75; DE_GUIplatform.username=”OG0Q3YUPHWw=”; DE_GUIplatform.password=”OG0Q3YUPHWw=”; DE_GUIplatform.descookie=”"; DE_GUIplatform.token=testToken; DE_GUIplatform.userrole=1; DE_GUIplatform.logindate=1392991759887; DE_GUIplatform.renewtoken=1392993559887; platform.username=”OG0Q3YUPHWw=”
Content-Type: application/x-www-form-urlencoded
Content-Length: 57

j_username=1%2522OG0Q3YUPHWw%3D&j_password=OG0Q3YUPHWw%3D

Check the POST data,j_username=1%2522OG0Q3YUPHWw%3Dj_password=OG0Q3YUPHWw%3DUrl decoded of it isj_username=1″OG0Q3YUPHWw=j_password=OG0Q3YUPHWw=

After this it redirects to main Symphony Applications area. Then we can access and control to all the available information i.e we can view, run, modify, delete the information.

Below is an image which shows up results after running “symping6.1.1” demo application. Moreover, we can see the authorization and various details in the below picture.

Solution:Vendor has advised the users of IBM Platform Symphony Developer Edition to configure it on local loopback IP address (127.0.0.1) only.

– Shashi Kiran

Featured Posts

Open WHIPSHOT and SLAPSHOT: Citrix NetScaler Zero-Days Exploited to Plant Root Web Shells and Internal Tunnels
WHIPSHOT and SLAPSHOT: Citrix NetScaler Zero-Days Exploited to Plant Root Web Shells and Internal Tunnels

CVE Research

WHIPSHOT and SLAPSHOT: Citrix NetScaler Zero-Days Exploited to Plant Root Web Shells and Internal Tunnels

Oct 1, 2026

Open OpenSSL’s DTLS State Handling Error Opens the Door to Heap Data Exposure
OpenSSL’s DTLS State Handling Error Opens the Door to Heap Data Exposure

CVE Research

OpenSSL’s DTLS State Handling Error Opens the Door to Heap Data Exposure

Oct 1, 2026

Open Patch Analysis & Exploitation Timeline: Critical WSO2 and Adobe Flaws Show 1-Day vs. 133-Day Exploitation Window , September 24, 2026 KEV Additions
Patch Analysis & Exploitation Timeline: Critical WSO2 and Adobe Flaws Show 1-Day vs. 133-Day Exploitation Window , September 24, 2026 KEV Additions

CVE Research

Patch Analysis & Exploitation Timeline: Critical WSO2 and Adobe Flaws Show 1-Day vs. 133-Day Exploitation Window , September 24, 2026 KEV Additions

Two critical vulnerabilities added to CISA KEV on September 24, 2026 reveal sharply different exploitation timelines. CVE-2026-71362 saw publicly documented exploitation roughly one day after Adobe's patch release, while CVE-2026-5430 had a 133-day vendor-remediation-to-observed-exploitation interval.

Oct 1, 2026

Open Patch Analysis & Exploitation Timeline: Same-Week KEV Additions, Year-Apart Patch Dates - Linux Kernel, September 18, 2026
Patch Analysis & Exploitation Timeline: Same-Week KEV Additions, Year-Apart Patch Dates - Linux Kernel, September 18, 2026

CVE Research

Patch Analysis & Exploitation Timeline: Same-Week KEV Additions, Year-Apart Patch Dates - Linux Kernel, September 18, 2026

Three Linux kernel vulnerabilities entered CISA’s KEV catalog on September 18, 2026, although their Linux 6.12 fixes were available 91–386 days earlier. This analysis separates patch availability, CVE publication, and known-exploitation status without treating KEV dates as first-attack dates.

Sep 28, 2026