CVE-2025-55113 is a critical access control bypass in BMC Control-M/Agent. When access control lists are enforced and the C router is in use, verification stops at the first NUL byte in the email address of a client certificate, so a crafted certificate can pass. BMC says to upgrade to 9.0.21 or 9.0.22 and set JAVA_AR to Y.
What's affected
- Product: BMC Control-M/Agent for UNIX and Microsoft Windows.
- Condition: the Access Control List is enforced by the agent and the C router is in use.
- Default exposure: the C router is the default in out-of-support agent versions 9.0.18 to 9.0.20 and potentially earlier unsupported versions. In newer versions it is non-default and configurable through the
JAVA_ARsetting. - Fix per BMC: upgrade agents to 9.0.21.xxx or 9.0.22, and make sure
JAVA_ARis set toY. - Also required: implement SSL/TLS on all agents according to BMC's best practice articles.
BMC lists this as one of eleven related CVEs for Control-M/Agent, from CVE-2025-55108 through CVE-2025-55118. BMC says the steps to resolve all of them are the same, and that deviating from the documented steps can leave you exposed. The FAQ also says remote hosts and agentless setups are not affected.
How to check if you're exposed
Take an inventory of Control-M/Agents and their versions using your Control-M/Enterprise Manager reporting. Anything at 9.0.20 or lower is unsupported and needs an upgrade.
For each agent, check:
- The version, against 9.0.21 and 9.0.22.
- The
JAVA_ARparameter, which should beY. - Whether the agent runs in TCP mode or SSL/TLS mode. In the default configuration, agents are in TCP mode. BMC's articles describe the procedures for each case.
BMC says it provides a script to help find which agents are affected, and points to its knowledge base articles for details. Use those articles for exact steps, since procedures vary by version.
What to do now
- Upgrade every Control-M/Agent to version 9.0.21.xxx or 9.0.22 or later, and retire unsupported versions.
- Set the
JAVA_ARparameter toYon each agent. - Implement SSL/TLS on all agents following BMC's articles. If SSL/TLS is already in place, update it to the latest best practice, since the FAQ says you can still be affected if it is not done that way.
- Until you finish, add firewall rules so only authorized Control-M/Server machines can reach each agent's server-to-agent port.
- Record the version, setting and mode of every agent and review the list when BMC issues new notices.
Why it matters
The weakness is improper handling of a NUL byte. Strings in C end at the first zero byte. If one component treats the email address in a certificate as a whole string and another stops reading at the NUL, they can disagree about what the name is. A check done on the shortened version can pass while the full value says something else.
This is a long standing class of certificate validation bug. The practical lesson is that access control based on a certificate field is only as good as the string handling around it. The CVSS vector rates attack complexity high, because the attacker needs a certificate that the trusted authority will issue with such a value, but scope changes and impact is high because job schedulers can run work on many servers. The CVE is not on the CISA KEV list.
The weakness is classed as CWE-158 (Improper Neutralization of Null Byte or NUL Character). Severity in the CVE record: critical, CVSS 9.0 (CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:C/C:H/I:H/A:H).
Quick check
Does the default configuration put me at risk?
BMC says the C router is the default in out-of-support versions 9.0.18 to 9.0.20 and earlier. In newer versions it depends on the JAVA_AR setting, which should be Y.
Is upgrading alone enough?
BMC says no. The documented solution includes setting JAVA_AR to Y and implementing SSL/TLS correctly on all agents.
Sources
- BMC article 000441967 on CVE-2025-55113
- BMC article 000442099 on CVE-2025-55108 through CVE-2025-55118
Last reviewed: 18 October 2026.
