eMudhra compromised certificates (CVE-2026-91403) and ESP dSeries Workload Automation
search cancel

eMudhra compromised certificates (CVE-2026-91403) and ESP dSeries Workload Automation

book

Article ID: 461194

calendar_today

Updated On:

Products

ESP dSeries Workload Automation

Issue/Introduction

eMudhra Intermediate Certificate Authority (CA) certificates have been compromised. 

The Java Runtime Environment (JRE) bundled with ESP dSeries Workload Automation components trusts the eMudhra (emSign) root CA certificates in its default trust store (cacerts). The JRE also does not block the compromised intermediate CA certificates (CVE-2026-91403). A malicious actor on a compromised network could use a certificate issued from a compromised intermediate CA to impersonate a TLS endpoint. This enables man-in-the-middle attacks on TLS connections that rely on the JRE's default trust store. 

Environment

ESP dSeries Workload Automation Components:

  • ESP dSeries Workload Automation Server 
  • ESP dSeries Workload Automation Web Client 
  • ESP dSeries Workload Automation Web Services 
  • ESP dSeries Workload Automation Desktop Client 
  • ESP dSeries Workload Automation CLI 

Versions Affected: 12.4, 25.0, 25.1, 25.1.01

Cause

eMudhra generated weak private keys for some of its intermediate CA certificates, which allowed the private keys to be recovered. eMudhra revoked the intermediate certificates, and browser and operating system vendors removed or blocked trust in the affected eMudhra root. The issue is tracked for Oracle Java SE and OpenJDK as CVE-2026-91403. 

The JRE bundled with the affected versions trusts the eMudhra roots. Its cacerts trust store contains the following eMudhra root CA certificates, and its jdk.security.caDistrustPolicies setting does not distrust them: 

  • emSign ECC Root CA - G3 
  • emSign Root CA - G1 
  • emSign ECC Root CA - C3 
  • emSign Root CA - C1 

The JRE block list (blocked.certs in Java 17, blacklisted.certs in Java 8) does not contain the compromised intermediate CA certificates.

Resolution

Remove the eMudhra certificates and block the compromised intermediate certificates in each bundled JRE. This makes two changes: 

It removes the four eMudhra root CA certificates from cacerts. 
It adds the SHA-256 fingerprints of the compromised intermediate CA certificates (16 fingerprints) to the JRE block list. The JRE rejects a certificate chain that includes a blocked certificate, even if the issuing root remains trusted. 

JRE file locations

ComponentJRE Folder
Server<Server_install_dir>/jre
Web Client<WebClient_install_dir>/jre
Web Server<WebServices_install_dir>/jre
Desktop Client<Desktop_Client_dir>/jre
CLI<CLI_install_dir>/jre

In each JRE folder, the files are in lib/security: 

  • cacerts: the trust store. 
  • blocked.certs (Java 17) or blacklisted.certs (Java 8): the block list. The script selects the file that exists. 

Notes: 

  • After an upgrade, the installation directory can contain a backup_<timestamp>/jre folder from the previous version. This folder is not used at runtime, but vulnerability scanners might report it. Apply the same procedure to it, or delete the backup folder after the upgrade has been validated. 
  • For High Availability, perform the steps on both the Primary and Standby servers. 
  • For the ESP dSeries Workload Automation Desktop Client on macOS, provide the desktop client path as  <Desktop_Client_dir>/jre/Contents/Home when the script asks for the JRE folder location. 

If you changed the default cacerts password, give your password to the script (-StorePass on Windows, STOREPASS on Linux/UNIX). A password given on the command line can be recorded in the shell or PowerShell history. Remove the history entry afterwards if this is a concern. 

Steps:

  1. Download the jre-emudhra-fix.ps1 (Windows) or jre-emudhra-fix.sh (Linux/UNIX) from the Security Advisory notification located under section titled Attached Remediation Scripts.
    You will be prompted to login to retreive the files. Login using your Broadcom Support portal credentials.
  2. Stop the components that use the JRE: 
    • Windows: stop the services of the Server, REST Server, Web Client and Web Services in the Services console, or with Stop-Service. 
    • Linux/UNIX: stop the Server with <Server_install_dir>/bin/stopServer, and stop the REST Server, Web Client and Web Services processes. 
    • Close all Desktop Client and CLI sessions. 
  3. Save and run the script for your operating system. For the JRE folder that you give it, the script does the following:
    • It checks that cacerts can be opened with the password. If it cannot, the script stops and changes nothing. 
    • It backs up cacerts and the block list in the same folder (cacerts.bak_<date_time> and blocked.certs.bak_<date_time> or blacklisted.certs.bak_<date_time>), and verifies the backups. 
    • It deletes every cacerts entry whose owner is O=eMudhra. The certificate aliases differ between JRE versions, so the script identifies the certificates by owner and deletes them by their exact alias. 
    • It appends the 16 fingerprints to the block list. Fingerprints that are already listed are skipped. The script selects blocked.certs (Java 17) or blacklisted.certs (Java 8), whichever exists. 
    • It verifies the result and stops with an error if an eMudhra certificate remains in cacerts or a fingerprint is missing from the block list. 
  4. The script processes one JRE folder for each run. Run it once for every JRE folder in the table, that is, for every component installed on the computer. To fix another JRE folder, for example a backup_<timestamp>/jre folder, run it for that folder too. The script asks for the JRE folder. If you changed the cacerts password, give it to the script. The script can be run again safely. A repeated run creates new backup files and makes no other changes. 

Windows: Save the script as jre-emudhra-fix.ps1. Open Windows PowerShell as administrator, change to the folder that contains the file, and run the following command. Enter the JRE folder when the script asks for it. If you changed the cacerts password, add -StorePass "<password>" to the command.

powershell -ExecutionPolicy Bypass -File .\jre-emudhra-fix.ps1

A successful run prints output like the following. The number of trusted certificates differs between JRE versions, but it decreases by 4. The number of existing hashes also differs: 

Backup created: <jre_folder>/lib/security/cacerts.bak_<date_time> 
Backup created: <jre_folder>/lib/security/blocked.certs.bak_<date_time> 
Deleted root: [<certificate alias>]          (four lines) 
Existing hashes: 38  New to add: 16 
Trusted certificates in cacerts: 139 -> 135 
Verified: no eMudhra roots in cacerts; all 16 hashes present; blocked.certs now has 54 hashes 
Done. Restart ... using <jre_folder>. 

Other messages: 

Cannot open ... cacerts. Check the password ... Nothing was changed. The password is wrong. Run the script again with the correct password. 
Not a JRE: need ... The folder is not a JRE folder. Check the path. 
Verification failed: ... One of the checks did not pass. If necessary, roll back (step 5). 
No eMudhra certificates found in cacerts (already removed). and New to add: 0 The JRE was already fixed. 

 

Alternative (manual): Use the keytool in the JRE folder (<jre_folder>/bin/keytool). List the eMudhra aliases and delete each alias exactly as listed. Then append the 16 fingerprints from the script, one per line, to the block list. Keep the existing Algorithm=SHA-256 line and entries. 

keytool -list -keystore <cacerts> -storepass xxxxxx | grep -i emsign   (Windows: findstr /i emsign) 
keytool -delete -alias "<alias>" -keystore <cacerts> -storepass xxxxxxxx

Verify the result for each JRE. The script output must contain the Verified: ... line. To check again later, run the keytool from the JRE folder. The following command must return no output.

  • Linux/UNIX:
    <jre_folder>/bin/keytool -list -keystore <jre_folder>/lib/security/cacerts -storepass xxxxxx | grep -i emsign
  • Windows:
    "<jre_folder>\bin\keytool" -list -keystore "<jre_folder>\lib\security\cacerts" -storepass xxxxxx | findstr /i emsign 

Confirm that the block list contains a fingerprint by searching for the first one. The command must return one match: 

  • Linux/UNIX:
    grep -i 42C4ACCD12C4F595 <jre_folder>/lib/security/<block_list_file>

  • Windows:
    findstr /i 42C4ACCD12C4F595 "<jre_folder>\lib\security\<block_list_file>") 

Start the components that you stopped in step 1. Then log in (for example, to the Web Client  or the Desktop Client) and confirm that the component works normally. 

Rollback (if required): Stop the components. In each JRE folder, copy the oldest cacerts.bak_<date_time> file over cacerts, and copy the oldest block list backup file over the block list. The oldest backups were created by your first run and hold the original files. Start the components. 

Important: 

  • After the certificates are removed, TLS connections to endpoints whose certificates chain to an eMudhra root fail with PKIX path building failed. Such endpoints must obtain replacement certificates from another certificate authority. 
  • A JRE update or product upgrade replaces the jre folder and restores the default cacerts and block list. After any JRE update or upgrade, run the script again for each JRE folder (steps 1 to 5).

Additional Information

  • Operating system trust stores (for example, the Red Hat Enterprise Linux ca-certificates package, CVE-2026-114406) are managed by the operating system vendor and are outside the scope of this article. ESP dSeries Workload Automation components use the bundled JRE's cacerts, not the operating system trust store. 
  • Oracle Security Alert Advisory - CVE-2026-91403
  • To speak with a customer representative or a Support Engineer see Contact Support. Scroll to the bottom of the page and click on the respective region.
Powered by Wolken Software