Full Disclosure mailing list archives
[0day-rubbish] Lightstreamer Server 7.4.8 Unauthenticated JMX jvmtiAgentLoad native code execution (8.1)
From: disclosure via Fulldisclosure <fulldisclosure () seclists org>
Date: Wed, 23 Sep 2026 04:54:43 +0000
0day Rubbish Research Team is publicly disclosing a vulnerability in Lightstreamer Server 7.4.8 build 3506 (with JMS Extender 2.1.0). Type: unauthenticated JMX inspection console allowing an anonymous caller to invoke any MBean operation, reaching jvmtiAgentLoad on com.sun.management:type=DiagnosticCommand to load and run a native agent library inside the broker JVM (CWE-306, CWE-345, CWE-20, CWE-250, CWE-1188) Scoring. This finding is dual-scored on one documented delivery precondition, and both figures are published rather than a single headline number: - PRIMARY, 8.1 High, CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:H/I:H/A:H. This is the conservative figure for an attacker with network access only: the agent library must be delivered to a filesystem path by means outside this endpoint. - CONDITIONAL, 9.8 Critical, CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H. This is the shipped-default exposure where the precondition is ALREADY satisfied, that is a native shared object is already reachable at a filesystem path the attacker names. Exploitation is then one deterministic HTTP request. The 9.8 figure is conditional, not the primary rating, and is not the headline. Impact: native code execution inside the Lightstreamer JVM as the service process, inheriting that process's full identity. In the verified deployment the process ran as uid=0(root), so the executed commands ran as root; root is not claimed to be a factory-mandated identity, it is whatever account launched the service. The shipping configuration sets <jmxtree_enabled>Y</jmxtree_enabled> and <dashboard><public>Y</public> even though the adjacent comments claim the default is N, and the only remaining check is a Referer header matching the target host, which any HTTP client forges. Authentication: unauthenticated (no credential of any kind). Verification boundary, stated plainly. We verified the MBean-invocation and native-code-execution legs against a research-host deployment reached over loopback (HTTP 200 with "return code: 0", marker files recording uid=0(root), and id/whoami commands chosen by the HTTP client at send time). The native agent library, however, was already present on disk, placed beforehand over an authenticated root session. jvmtiAgentLoad takes a filesystem path and fetches nothing (http:// and file:// were both treated as literal strings), so the fully remote chain including payload delivery is NOT demonstrated by this advisory; what is proven unauthenticated is the request leg, not the delivery leg. Full technical analysis and a reproducible proof-of-concept: https://0day-rubbish.com/blog/lightstreamer-unauth-jmx-jvmti-agentload-rce Project archive (ongoing disclosure series): https://github.com/Exploit-Garbage/0day-Rubbish The vendor has been notified through its published security contact. No vulnerability identifier has been assigned to this finding yet. -- 0day Rubbish Research Team disclosure () 0day-rubbish com https://0day-rubbish.com _______________________________________________ Sent through the Full Disclosure mailing list https://nmap.org/mailman/listinfo/fulldisclosure Web Archives & RSS: https://seclists.org/fulldisclosure/
Current thread:
- [0day-rubbish] Lightstreamer Server 7.4.8 Unauthenticated JMX jvmtiAgentLoad native code execution (8.1) disclosure via Fulldisclosure (Sep 26)
