Inefficient Regular Expression Complexity Affecting pcs-snmp package, versions *


Severity

Recommended
0.0
medium
0
10

Based on Red Hat Enterprise Linux security rating.

Threat Intelligence

EPSS
0.5% (39th percentile)

Do your applications use this vulnerable package?

In a few clicks we can analyze your entire application and see what components are vulnerable in your application, and suggest you quick fixes.

Test your applications
  • Snyk IDSNYK-RHEL9-PCSSNMP-15857012
  • published31 Mar 2026
  • disclosed26 Mar 2026

Introduced: 26 Mar 2026

CVE-2026-4867  (opens in a new tab)
CWE-1333  (opens in a new tab)

How to fix?

There is no fixed version for RHEL:9 pcs-snmp.

NVD Description

Note: Versions mentioned in the description apply only to the upstream pcs-snmp package and not the pcs-snmp package as distributed by RHEL. See How to fix? for RHEL:9 relevant fixed versions and status.

Impact:

A bad regular expression is generated any time you have three or more parameters within a single segment, separated by something that is not a period (.). For example, /:a-:b-:c or /:a-:b-:c-:d. The backtrack protection added in path-to-regexp@0.1.12 only prevents ambiguity for two parameters. With three or more, the generated lookahead does not block single separator characters, so capture groups overlap and cause catastrophic backtracking.

Patches:

Upgrade to path-to-regexp@0.1.13

Custom regex patterns in route definitions (e.g., /:a-:b([^-/]+)-:c([^-/]+)) are not affected because they override the default capture group.

Workarounds:

All versions can be patched by providing a custom regular expression for parameters after the first in a single segment. As long as the custom regular expression does not match the text before the parameter, you will be safe. For example, change /:a-:b-:c to /:a-:b([^-/]+)-:c([^-/]+).

If paths cannot be rewritten and versions cannot be upgraded, another alternative is to limit the URL length.

CVSS Base Scores

version 3.1