CVE-2026-19135: OpenNMS JEXL Measurement Sandbox Bypass

CVE-2026-19135: OpenNMS JEXL Measurement Sandbox Bypass

A JEXL sandbox bypass in the OpenNMS Measurements REST API lets a low-privileged authenticated user load arbitrary Java classes on the server (CVSS 5.4, CWE-470). Upgrade to Horizon 36.0.3, Meridian 2024.3.12, or Meridian 2025.0.9.

2 min read528 words
Contents

TL;DR: CVE-2026-19135 is a JEXL expression sandbox bypass in the OpenNMS Measurements REST API. A low-privileged authenticated user can submit a crafted expression that escapes the sandbox and loads arbitrary Java classes on the server. Patches ship in Horizon 36.0.3 and Meridian 2024.3.12 / 2025.0.9.

What happened

OpenNMS evaluates on-demand measurement requests through a JEXL expression evaluator. JEXL, the Java Expression Language, is meant to run user-supplied expressions inside a restricted context. The restriction is enforced by a sandbox that is supposed to keep expressions from reaching classes outside an allowlist.

That sandbox is incomplete. A low-privileged authenticated user who can reach the Measurements endpoint sends a crafted expression that escapes the sandbox and loads arbitrary Java classes on the server. In practice this lands as CWE-470, unsafe reflection: the server reflects on classes it should never expose to a caller. The impact is a confidentiality and integrity hit, scored CVSS 5.4 (AV:N/AC:L/PR:L/UI:N/S:U/C:L/I:L/A:N). The attacker already needs a valid account, which is why the score stays medium.

The bug is a sandbox escape rather than a direct injection point. JEXL sandbox escapes are a recurring theme in Java applications because the default JEXL sandbox has holes that get papered over with class allowlists. When those allowlists miss a reachable class, an expression can walk into it and do more than a normal expression should.

Who is affected

OpenNMS ships in two forms. Horizon is the free, Apache-licensed community edition. Meridian is the enterprise long-term-support edition that network operations teams pay for. Both are affected.

Affected and fixed versions:

  • OpenNMS Horizon: fixed in 36.0.3
  • OpenNMS Meridian 2024: fixed in 2024.3.12
  • OpenNMS Meridian 2025: fixed in 2025.0.9

OpenNMS is one of the longest-running open-source network monitoring platforms, in use since 2000. Network operations teams at ISPs, telecoms, and large enterprises run it to poll SNMP devices, ingest flow records, feed dashboards, and fire alarms. The Measurements REST API serves the on-demand time-series queries behind many of those dashboards, so a reachable, authenticated user is often part of the normal operator workflow rather than a rare path.

What to do

Upgrade, then restart the OpenNMS services that run the web application:

  • Horizon: upgrade to 36.0.3 or newer
  • Meridian 2024.x: upgrade to 2024.3.12 or newer
  • Meridian 2025.x: upgrade to 2025.0.9 or newer

There is no workaround short of the fixed release. The same patched versions also address a separate alarm API authorization issue disclosed alongside this one (CVE-2026-19182). OpenNMS installs are designed for private networks, but that is a deployment assumption, not a mitigation: any authenticated user who should be limited to read-only could attempt a JEXL escape.

Why it matters

The CVE is not in CISA's Known Exploited Vulnerabilities catalog and has no public exploit yet. The severity is medium because it needs a low-privilege account. What raises the stakes is the class of bug: a sandbox escape that can load arbitrary classes in a Java server that likely sits with credentials to reach the wider network it monitors. Network management systems are high-value targets because they see infrastructure state and often hold service credentials.

References

Continue reading

All posts