VULNARCHIVE

GCVE-1988-2026-0427

[0day-rubbish] Lightstreamer Server 7.4.8 Shipped placeholder JMX/RMI credentials plus MLet remote class loading to root RCE (9.8)

Description (en)

0day Rubbish Research Team is publicly disclosing a vulnerability in
Lightstreamer Server 7.4.8 build 3506 ENTERPRISE (with JMS Extender 2.1.0).

Type: a hard-coded placeholder credential shipped in the distribution
(user_changeme / password_changeme) authenticating a cleartext RMI management
connector on TCP 8888 bound to every interface; because the connector exposes
createMBean, an attacker registers javax.management.loading.MLet and calls
getMBeansFromURL against an origin they control, and the loaded MBean's
constructor runs Runtime.exec (CWE-798, CWE-319)

Scoring. This finding is dual-scored because remote reach depends on the
shipped placeholder being left unchanged. Both figures are published:
- PRIMARY, 9.8 Critical, CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H. This
  applies with the shipped placeholder credential unchanged, which is how the
  distribution archive delivers it (byte-identical to the deployed file, with no
  documented first-login rotation gate).
- CONDITIONAL, 7.2 High, CVSS:3.1/AV:N/AC:L/PR:H/UI:N/S:U/C:H/I:H/A:H. This
  applies where an operator has rotated the credential but createMBean and MLet
  remain exposed: the step then needs a genuinely privileged account.

Impact: arbitrary command execution as the broker process user, which was root
in the tested deployment. Configuration, TLS material and keystores, streamed
application data and any other credential configured in lightstreamer_conf.xml
are all reachable; the payload MBean stays registered for the JVM lifetime as a
persistent command channel.

Authentication: none beyond the shipped placeholder pair (empty and wrong
credentials were both rejected with SecurityException, so the defect is the
credential's provenance, not a bypassable check).

Verification boundary, stated plainly. We verified the chain end to end over
loopback against a broker unpacked from the distribution archive and started as
root, with the attacker HTTP origin simulated on the same research host: four
runs (three against the jmxrmi platform MBean server, one against the lsjmx
application MBean server), an out-of-band HTTP access log proving a uniquely
named JAR was really fetched rather than cached, runCmd returning uid=0(root)
and a root-owned proof file. Remote cross-network reach is an assessment of the
shipped bind topology (TCP 8888 binds 0.0.0.0 because <listening_interface> is
commented out, with no host firewall rule dropping it), not an observed attack
crossing a network boundary. The one genuine precondition is that the operator
has not replaced the shipped placeholder pair.

This is a distinct defect from the separate unauthenticated jvmtiAgentLoad
primitive we are disclosing in the same product; it reaches code execution via
remote Java class loading rather than a native agent load.

Full technical analysis and a reproducible proof-of-concept:
  https://0day-rubbish.com/blog/lightstreamer-default-creds-jmx-rmi-mlet-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/

References

Raw JSON
{
  "containers": {
    "cna": {
      "affected": [
        {
          "product": "Lightstreamer Server",
          "vendor": "unknown",
          "versions": [
            {
              "status": "affected",
              "version": "unknown"
            }
          ]
        }
      ],
      "credits": [
        {
          "lang": "en",
          "type": "finder",
          "value": "disclosure via Fulldisclosure"
        }
      ],
      "descriptions": [
        {
          "lang": "en",
          "value": "0day Rubbish Research Team is publicly disclosing a vulnerability in\nLightstreamer Server 7.4.8 build 3506 ENTERPRISE (with JMS Extender 2.1.0).\n\nType: a hard-coded placeholder credential shipped in the distribution\n(user_changeme / password_changeme) authenticating a cleartext RMI management\nconnector on TCP 8888 bound to every interface; because the connector exposes\ncreateMBean, an attacker registers javax.management.loading.MLet and calls\ngetMBeansFromURL against an origin they control, and the loaded MBean's\nconstructor runs Runtime.exec (CWE-798, CWE-319)\n\nScoring. This finding is dual-scored because remote reach depends on the\nshipped placeholder being left unchanged. Both figures are published:\n- PRIMARY, 9.8 Critical, CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H. This\n  applies with the shipped placeholder credential unchanged, which is how the\n  distribution archive delivers it (byte-identical to the deployed file, with no\n  documented first-login rotation gate).\n- CONDITIONAL, 7.2 High, CVSS:3.1/AV:N/AC:L/PR:H/UI:N/S:U/C:H/I:H/A:H. This\n  applies where an operator has rotated the credential but createMBean and MLet\n  remain exposed: the step then needs a genuinely privileged account.\n\nImpact: arbitrary command execution as the broker process user, which was root\nin the tested deployment. Configuration, TLS material and keystores, streamed\napplication data and any other credential configured in lightstreamer_conf.xml\nare all reachable; the payload MBean stays registered for the JVM lifetime as a\npersistent command channel.\n\nAuthentication: none beyond the shipped placeholder pair (empty and wrong\ncredentials were both rejected with SecurityException, so the defect is the\ncredential's provenance, not a bypassable check).\n\nVerification boundary, stated plainly. We verified the chain end to end over\nloopback against a broker unpacked from the distribution archive and started as\nroot, with the attacker HTTP origin simulated on the same research host: four\nruns (three against the jmxrmi platform MBean server, one against the lsjmx\napplication MBean server), an out-of-band HTTP access log proving a uniquely\nnamed JAR was really fetched rather than cached, runCmd returning uid=0(root)\nand a root-owned proof file. Remote cross-network reach is an assessment of the\nshipped bind topology (TCP 8888 binds 0.0.0.0 because <listening_interface> is\ncommented out, with no host firewall rule dropping it), not an observed attack\ncrossing a network boundary. The one genuine precondition is that the operator\nhas not replaced the shipped placeholder pair.\n\nThis is a distinct defect from the separate unauthenticated jvmtiAgentLoad\nprimitive we are disclosing in the same product; it reaches code execution via\nremote Java class loading rather than a native agent load.\n\nFull technical analysis and a reproducible proof-of-concept:\n  https://0day-rubbish.com/blog/lightstreamer-default-creds-jmx-rmi-mlet-rce\n\nProject archive (ongoing disclosure series):\n  https://github.com/Exploit-Garbage/0day-Rubbish\n\nThe vendor has been notified through its published security contact. No vulnerability identifier has been assigned to\nthis finding yet.\n\n--\n0day Rubbish Research Team\ndisclosure () 0day-rubbish com\nhttps://0day-rubbish.com\n_______________________________________________\nSent through the Full Disclosure mailing list\nhttps://nmap.org/mailman/listinfo/fulldisclosure\nWeb Archives & RSS: https://seclists.org/fulldisclosure/"
        }
      ],
      "problemTypes": [
        {
          "descriptions": [
            {
              "cweId": "CWE-319",
              "description": "CWE-319",
              "lang": "en",
              "type": "CWE"
            },
            {
              "cweId": "CWE-798",
              "description": "CWE-798",
              "lang": "en",
              "type": "CWE"
            }
          ]
        }
      ],
      "providerMetadata": {
        "dateUpdated": "2026-10-02T04:57:33Z",
        "orgId": "4e2abfbf-4a2a-4b76-a4e0-d77c18ba156c",
        "shortName": "VULNARCHIVE"
      },
      "references": [
        {
          "tags": [
            "technical-description",
            "exploit"
          ],
          "url": "https://vuln.freearchive.org/archive/full-disclosure/2026/Sep/75"
        },
        {
          "tags": [
            "technical-description"
          ],
          "url": "https://seclists.org/fulldisclosure/2026/Sep/75"
        },
        {
          "url": "https://0day-rubbish.com"
        },
        {
          "url": "https://0day-rubbish.com/blog/lightstreamer-default-creds-jmx-rmi-mlet-rce"
        },
        {
          "url": "https://github.com/Exploit-Garbage/0day-Rubbish"
        },
        {
          "url": "https://nmap.org/mailman/listinfo/fulldisclosure"
        },
        {
          "url": "https://seclists.org/fulldisclosure/"
        }
      ],
      "source": {
        "defect": [
          "https://seclists.org/fulldisclosure/2026/Sep/75"
        ],
        "discovery": "EXTERNAL"
      },
      "title": "[0day-rubbish] Lightstreamer Server 7.4.8 Shipped placeholder JMX/RMI credentials plus MLet remote class loading to root RCE (9.8)",
      "x_gcve": [
        {
          "recordType": "advisory",
          "relationships": [],
          "vulnId": "GCVE-1988-2026-0427",
          "x_vulnarchive": {
            "archiveUrl": "https://vuln.freearchive.org/archive/full-disclosure/2026/Sep/75",
            "automated": true,
            "contentSha256": "c0ead204cdcd3e07b31c2b843bc604bf06fdfba1aca02a384eb03f8cef062308",
            "evidenceScore": 11,
            "messageId": "",
            "originalUrl": "https://seclists.org/fulldisclosure/2026/Sep/75",
            "policy": "vulnarchive-1",
            "sourceFormat": "text/html",
            "sourcePublishedAt": "2026-09-23T04:54:28Z"
          }
        }
      ]
    }
  },
  "cveMetadata": {
    "assignerOrgId": "4e2abfbf-4a2a-4b76-a4e0-d77c18ba156c",
    "assignerShortName": "VULNARCHIVE",
    "datePublished": "2026-10-02T04:57:33Z",
    "dateUpdated": "2026-10-02T04:57:33Z",
    "state": "PUBLISHED",
    "vulnId": "GCVE-1988-2026-0427"
  },
  "dataType": "CVE_RECORD",
  "dataVersion": "5.2"
}