CVE-2025-48059

PowSyBl Core Contains a Polynomial ReDoS in RegexCriterion

Am I impacted?

Since RegexCriterion are used to define contingencies or limit reductions, you are vulnerable if:

• you allow untrusted users to define contingency lists or limit reductions using this criterion;
• OR you load untrusted contingencies or limit reductions files

AND use them with a network containing untrusted identifiers.

References

powsybl-core v6.7.2

What kind of vulnerability is it? Who is impacted?

This is an advisory for a potential polynomial Regular Expression Denial of Service (ReDoS) vulnerability in the RegexCriterion class. This class compiles and evaluates an unvalidated, user-supplied regular expression against the identifier of an Identifiable object via Pattern.compile(regex).matcher(id).find().

To trigger polynomial ReDoS in RegexCriterion, two attacker-controlled conditions must be met:

• Control over the regex input passed into the constructor:
  • Example: An attacker supplies a malicious pattern such as (.*a){10000}.
• Control or influence over the output of Identifiable.getId():
  • Example: A long string like "aaaa...!" that forces excessive backtracking.

If both conditions are satisfied, a malicious actor can cause significant CPU exhaustion through repeated or recursive filter(...) calls, especially if performed over large network models or filtering operations.
While this class does not handle file or memory data directly, its reliance on untrusted regular expressions and potentially attacker-controlled identifiers makes it vulnerable to polynomial ReDoS under the right conditions. This risk is amplified when the library is used in dynamic or scriptable environments where external users control either criterion construction or network object identifiers.
Although not as dangerous as catastrophic exponential ReDoS, the polynomial pattern still induces significant performance
degradation as input size increases.

A regular expression with worst-case exponential or polynomial matching time is applied to untrusted input, causing excessive CPU use. Typical impact: denial of service when input is crafted to trigger backtracking.

Kodem intelligence

Already deployed Kodem?

com.powsybl:powsybl-iidm-criteria:6.7.2 and higher

1. What is CVE-2025-48059? CVE-2025-48059 is a low-severity inefficient regular expression (ReDoS) vulnerability in com.powsybl:powsybl-iidm-criteria (maven), affecting versions >= 6.3.0, <= 6.7.1. It is fixed in 6.7.2, 6.3.0. A regular expression with worst-case exponential or polynomial matching time is applied to untrusted input, causing excessive CPU use.
2. Which packages are affected by CVE-2025-48059?
   • com.powsybl:powsybl-iidm-criteria (maven) (versions >= 6.3.0, <= 6.7.1)
   • com.powsybl:powsybl-contingency-api (maven) (versions >= 5.0.0, < 6.3.0)
3. Is there a fix for CVE-2025-48059? Yes. CVE-2025-48059 is fixed in 6.7.2, 6.3.0. Upgrade to this version or later.
4. Is CVE-2025-48059 exploitable, and should I be worried? Whether CVE-2025-48059 is exploitable in your environment depends on whether the vulnerable code is present and reachable. A CVSS score is a worst-case rating; it does not account for your specific deployment, configuration, or usage patterns. Kodem, an Intelligent Application Security platform, uses runtime intelligence to show which vulnerabilities actually execute in production, so you can focus on the ones that represent real risk. Get a demo
5. What actually determines whether CVE-2025-48059 is exploitable, and how bad it is? Exploitability and impact are not fixed properties of a CVE. They depend on runtime truth: whether the vulnerable code is present, reachable, and actually executes in your application. A high CVSS score on a dependency that never runs is not the same as real risk. Kodem, an Intelligent Application Security platform, uses runtime intelligence to reveal which vulnerabilities actually execute in production, so teams prioritize the ones that genuinely matter.
6. How do I fix CVE-2025-48059?
   • Upgrade com.powsybl:powsybl-iidm-criteria to 6.7.2 or later
   • Upgrade com.powsybl:powsybl-contingency-api to 6.3.0 or later