Vulnerability-Lookup

CVE-2026-105869 (GCVE-0-2026-105869)

Vulnerability from cvelistv5 – Published: 2026-10-21 17:58 – Updated: 2026-10-21 17:58

Title

Apache Pulsar: MultiRolesTokenAuthorizationProvider uses roles from unverified tokens for HTTP requests that fall back to the anonymous user role

Summary

Apache Pulsar's MultiRolesTokenAuthorizationProvider authorizes a client with all roles listed in a claim of its JSON Web Token (JWT). The provider is intended for use with token authentication, which verifies the token before authorization. The provider did not verify the token itself: it parsed the token's claims with the signature removed and trusted that authentication had already checked it. When authentication and authorization are enabled with a non-empty anonymousUserRole setting, some HTTP requests whose credentials fail authentication are not rejected, but are handled as requests of the anonymous user role. For the broker's HTTP endpoints, such as the admin REST API, this fallback applies to requests that do not name an authentication method and requires strictAuthMethod to be false (the default) where that setting is available. For the WebSocket API, failed credentials can also fall back to the anonymous user role; this path does not enforce strictAuthMethod. The authentication data kept for such a request still contained the request's Authorization header. MultiRolesTokenAuthorizationProvider then read the bearer token from that header without verifying its signature and authorized the request with the roles in the token's role claim. As a result, in deployments that use MultiRolesTokenAuthorizationProvider together with a non-empty anonymousUserRole and that permit this fallback, an unauthenticated client can send an HTTP request, for example to the admin REST API or the WebSocket API, with a forged or unsigned token that lists arbitrary roles, and be authorized with those roles. The impact can include super-user access when the token lists a role configured in superUserRoles, allowing the client to read and change tenants, namespaces, topics, permissions and broker configuration. No valid credentials are required. Deployments are not affected if they use the default authorization provider (PulsarAuthorizationProvider) or another authorization provider, or if anonymousUserRole is not set (the default). Requests that authenticate successfully with a valid token are not affected, because the token that MultiRolesTokenAuthorizationProvider reads is the token that authentication verified. Connections that use the Pulsar binary protocol are not affected by this issue, because the broker does not keep client authentication data for connections that it assigns to the anonymous user role. In fixed versions, MultiRolesTokenAuthorizationProvider obtains roles only from tokens that the configured token authentication provider has verified, using its configured keys and validation settings. Broker HTTP requests that are assigned to the anonymous user role are authorized only as that role, and invalid tokens cannot supply additional roles to WebSocket requests. The broker fails to start if MultiRolesTokenAuthorizationProvider is configured with authorization enabled but without a token authentication provider. This issue affects Apache Pulsar versions from 2.8.1 before 4.0.14 and from 4.1.0 before 4.2.5. - 4.0.x version users should upgrade to at least 4.0.14. - 4.1.x and 4.2.x version users should upgrade to at least 4.2.5. Users operating versions prior to those listed above should upgrade to the aforementioned patched versions or newer versions. The currently supported Apache Pulsar release lines are 4.0.x and 5.0.x. The supported versions schedule is available at https://pulsar.apache.org/contribute/release-policy/. Users who cannot upgrade immediately can remove the anonymousUserRole setting from the broker and WebSocket service configurations, or restrict network access to the HTTP endpoints of these services to trusted clients.

Severity

9.2 (Critical)


                        
                          CVSS:4.0/AV:N/AC:L/AT:P/PR:N/UI:N/VC:H/VI:H/VA:H/SC:N/SI:N/SA:N

CWE

CWE-347 - Improper Verification of Cryptographic Signature

Assigner

apache CNA under the mitre root

CNA scorecard B 76/100 over 1076 records in the last 180 days details

References

2 references

URL	Tags
https://pulsar.apache.org/security/CVE-2026-105869/	vendor-advisory
https://lists.apache.org/thread.html/lf36z1tlcsok…	vendor-advisory

Impacted products

1 product

Vendor	Product	Version	CPE status
Apache Software Foundation	Apache Pulsar	Affected: 2.8.1 , < 4.0.14 (semver) Affected: 4.1.0 , < 4.2.5 (semver)	guessed

Credits

George Chen

Show details on NVD website

JSON

To clipboard

{
  "containers": {
    "cna": {
      "affected": [
        {
          "defaultStatus": "unaffected",
          "product": "Apache Pulsar",
          "vendor": "Apache Software Foundation",
          "versions": [
            {
              "lessThan": "4.0.14",
              "status": "affected",
              "version": "2.8.1",
              "versionType": "semver"
            },
            {
              "lessThan": "4.2.5",
              "status": "affected",
              "version": "4.1.0",
              "versionType": "semver"
            }
          ]
        }
      ],
      "credits": [
        {
          "lang": "en",
          "type": "finder",
          "value": "George Chen"
        }
      ],
      "descriptions": [
        {
          "lang": "en",
          "supportingMedia": [
            {
              "base64": false,
              "type": "text/html",
              "value": "Apache Pulsar\u0027s MultiRolesTokenAuthorizationProvider authorizes a client with all roles listed in a claim of its JSON Web Token (JWT). The provider is intended for use with token authentication, which verifies the token before authorization. The provider did not verify the token itself: it parsed the token\u0027s claims with the signature removed and trusted that authentication had already checked it.\u003cbr\u003e\u003cbr\u003eWhen authentication and authorization are enabled with a non-empty anonymousUserRole setting, some HTTP requests whose credentials fail authentication are not rejected, but are handled as requests of the anonymous user role. For the broker\u0027s HTTP endpoints, such as the admin REST API, this fallback applies to requests that do not name an authentication method and requires strictAuthMethod to be false (the default) where that setting is available. For the WebSocket API, failed credentials can also fall back to the anonymous user role; this path does not enforce strictAuthMethod. The authentication data kept for such a request still contained the request\u0027s Authorization header. MultiRolesTokenAuthorizationProvider then read the bearer token from that header without verifying its signature and authorized the request with the roles in the token\u0027s role claim.\u003cbr\u003e\u003cbr\u003eAs a result, in deployments that use MultiRolesTokenAuthorizationProvider together with a non-empty anonymousUserRole and that permit this fallback, an unauthenticated client can send an HTTP request, for example to the admin REST API or the WebSocket API, with a forged or unsigned token that lists arbitrary roles, and be authorized with those roles. The impact can include super-user access when the token lists a role configured in superUserRoles, allowing the client to read and change tenants, namespaces, topics, permissions and broker configuration. No valid credentials are required.\u003cbr\u003e\u003cbr\u003eDeployments are not affected if they use the default authorization provider (PulsarAuthorizationProvider) or another authorization provider, or if anonymousUserRole is not set (the default). Requests that authenticate successfully with a valid token are not affected, because the token that MultiRolesTokenAuthorizationProvider reads is the token that authentication verified. Connections that use the Pulsar binary protocol are not affected by this issue, because the broker does not keep client authentication data for connections that it assigns to the anonymous user role.\u003cbr\u003e\u003cbr\u003eIn fixed versions, MultiRolesTokenAuthorizationProvider obtains roles only from tokens that the configured token authentication provider has verified, using its configured keys and validation settings. Broker HTTP requests that are assigned to the anonymous user role are authorized only as that role, and invalid tokens cannot supply additional roles to WebSocket requests. The broker fails to start if MultiRolesTokenAuthorizationProvider is configured with authorization enabled but without a token authentication provider.\u003cbr\u003e\u003cbr\u003eThis issue affects Apache Pulsar versions from 2.8.1 before 4.0.14 and from 4.1.0 before 4.2.5.\u003cbr\u003e\u003cbr\u003e- 4.0.x version users should upgrade to at least 4.0.14.\u003cbr\u003e- 4.1.x and 4.2.x version users should upgrade to at least 4.2.5.\u003cbr\u003e\u003cbr\u003eUsers operating versions prior to those listed above should upgrade to the aforementioned patched versions or newer versions.\u003cbr\u003e\u003cbr\u003eThe currently supported Apache Pulsar release lines are 4.0.x and 5.0.x. The supported versions schedule is available at https://pulsar.apache.org/contribute/release-policy/.\u003cbr\u003e\u003cbr\u003eUsers who cannot upgrade immediately can remove the anonymousUserRole setting from the broker and WebSocket service configurations, or restrict network access to the HTTP endpoints of these services to trusted clients."
            }
          ],
          "value": "Apache Pulsar\u0027s MultiRolesTokenAuthorizationProvider authorizes a client with all roles listed in a claim of its JSON Web Token (JWT). The provider is intended for use with token authentication, which verifies the token before authorization. The provider did not verify the token itself: it parsed the token\u0027s claims with the signature removed and trusted that authentication had already checked it.\n\nWhen authentication and authorization are enabled with a non-empty anonymousUserRole setting, some HTTP requests whose credentials fail authentication are not rejected, but are handled as requests of the anonymous user role. For the broker\u0027s HTTP endpoints, such as the admin REST API, this fallback applies to requests that do not name an authentication method and requires strictAuthMethod to be false (the default) where that setting is available. For the WebSocket API, failed credentials can also fall back to the anonymous user role; this path does not enforce strictAuthMethod. The authentication data kept for such a request still contained the request\u0027s Authorization header. MultiRolesTokenAuthorizationProvider then read the bearer token from that header without verifying its signature and authorized the request with the roles in the token\u0027s role claim.\n\nAs a result, in deployments that use MultiRolesTokenAuthorizationProvider together with a non-empty anonymousUserRole and that permit this fallback, an unauthenticated client can send an HTTP request, for example to the admin REST API or the WebSocket API, with a forged or unsigned token that lists arbitrary roles, and be authorized with those roles. The impact can include super-user access when the token lists a role configured in superUserRoles, allowing the client to read and change tenants, namespaces, topics, permissions and broker configuration. No valid credentials are required.\n\nDeployments are not affected if they use the default authorization provider (PulsarAuthorizationProvider) or another authorization provider, or if anonymousUserRole is not set (the default). Requests that authenticate successfully with a valid token are not affected, because the token that MultiRolesTokenAuthorizationProvider reads is the token that authentication verified. Connections that use the Pulsar binary protocol are not affected by this issue, because the broker does not keep client authentication data for connections that it assigns to the anonymous user role.\n\nIn fixed versions, MultiRolesTokenAuthorizationProvider obtains roles only from tokens that the configured token authentication provider has verified, using its configured keys and validation settings. Broker HTTP requests that are assigned to the anonymous user role are authorized only as that role, and invalid tokens cannot supply additional roles to WebSocket requests. The broker fails to start if MultiRolesTokenAuthorizationProvider is configured with authorization enabled but without a token authentication provider.\n\nThis issue affects Apache Pulsar versions from 2.8.1 before 4.0.14 and from 4.1.0 before 4.2.5.\n\n- 4.0.x version users should upgrade to at least 4.0.14.\n- 4.1.x and 4.2.x version users should upgrade to at least 4.2.5.\n\nUsers operating versions prior to those listed above should upgrade to the aforementioned patched versions or newer versions.\n\nThe currently supported Apache Pulsar release lines are 4.0.x and 5.0.x. The supported versions schedule is available at https://pulsar.apache.org/contribute/release-policy/.\n\nUsers who cannot upgrade immediately can remove the anonymousUserRole setting from the broker and WebSocket service configurations, or restrict network access to the HTTP endpoints of these services to trusted clients."
        }
      ],
      "metrics": [
        {
          "cvssV4_0": {
            "Automatable": "NOT_DEFINED",
            "Recovery": "NOT_DEFINED",
            "Safety": "NOT_DEFINED",
            "attackComplexity": "LOW",
            "attackRequirements": "PRESENT",
            "attackVector": "NETWORK",
            "baseScore": 9.2,
            "baseSeverity": "CRITICAL",
            "exploitMaturity": "NOT_DEFINED",
            "privilegesRequired": "NONE",
            "providerUrgency": "NOT_DEFINED",
            "subAvailabilityImpact": "NONE",
            "subConfidentialityImpact": "NONE",
            "subIntegrityImpact": "NONE",
            "userInteraction": "NONE",
            "valueDensity": "NOT_DEFINED",
            "vectorString": "CVSS:4.0/AV:N/AC:L/AT:P/PR:N/UI:N/VC:H/VI:H/VA:H/SC:N/SI:N/SA:N",
            "version": "4.0",
            "vulnAvailabilityImpact": "HIGH",
            "vulnConfidentialityImpact": "HIGH",
            "vulnIntegrityImpact": "HIGH",
            "vulnerabilityResponseEffort": "NOT_DEFINED"
          },
          "format": "CVSS",
          "scenarios": [
            {
              "lang": "en",
              "value": "GENERAL"
            }
          ]
        }
      ],
      "problemTypes": [
        {
          "descriptions": [
            {
              "cweId": "CWE-347",
              "description": "CWE-347 Improper Verification of Cryptographic Signature",
              "lang": "en",
              "type": "CWE"
            }
          ]
        }
      ],
      "providerMetadata": {
        "dateUpdated": "2026-10-21T17:58:54.385Z",
        "orgId": "f0158376-9dc2-43b6-827c-5f631a4d8d09",
        "shortName": "apache"
      },
      "references": [
        {
          "tags": [
            "vendor-advisory"
          ],
          "url": "https://pulsar.apache.org/security/CVE-2026-105869/"
        },
        {
          "tags": [
            "vendor-advisory"
          ],
          "url": "https://lists.apache.org/thread.html/lf36z1tlcsokp4gv97obkdjtt74ngmrw"
        }
      ],
      "source": {
        "discovery": "EXTERNAL"
      },
      "title": "Apache Pulsar: MultiRolesTokenAuthorizationProvider uses roles from unverified tokens for HTTP requests that fall back to the anonymous user role",
      "x_generator": {
        "engine": "Vulnogram 1.0.3"
      }
    }
  },
  "cveMetadata": {
    "assignerOrgId": "f0158376-9dc2-43b6-827c-5f631a4d8d09",
    "assignerShortName": "apache",
    "cveId": "CVE-2026-105869",
    "datePublished": "2026-10-21T17:58:54.385Z",
    "dateReserved": "2026-10-06T00:01:27.497Z",
    "dateUpdated": "2026-10-21T17:58:54.385Z",
    "state": "PUBLISHED"
  },
  "dataType": "CVE_RECORD",
  "dataVersion": "5.2",
  "vulnerability-lookup:meta": {
    "epss": {
      "cve": "CVE-2026-105869",
      "date": "2026-10-27",
      "epss": "0.00303",
      "percentile": "0.22959"
    },
    "nvd": {
      "cve": {
        "affected": [
          {
            "affectedData": [
              {
                "defaultStatus": "unaffected",
                "product": "Apache Pulsar",
                "vendor": "Apache Software Foundation",
                "versions": [
                  {
                    "lessThan": "4.0.14",
                    "status": "affected",
                    "version": "2.8.1",
                    "versionType": "semver"
                  },
                  {
                    "lessThan": "4.2.5",
                    "status": "affected",
                    "version": "4.1.0",
                    "versionType": "semver"
                  }
                ]
              }
            ],
            "source": "security@apache.org"
          }
        ],
        "cveTags": [],
        "descriptions": [
          {
            "lang": "en",
            "value": "Apache Pulsar\u0027s MultiRolesTokenAuthorizationProvider authorizes a client with all roles listed in a claim of its JSON Web Token (JWT). The provider is intended for use with token authentication, which verifies the token before authorization. The provider did not verify the token itself: it parsed the token\u0027s claims with the signature removed and trusted that authentication had already checked it.\n\nWhen authentication and authorization are enabled with a non-empty anonymousUserRole setting, some HTTP requests whose credentials fail authentication are not rejected, but are handled as requests of the anonymous user role. For the broker\u0027s HTTP endpoints, such as the admin REST API, this fallback applies to requests that do not name an authentication method and requires strictAuthMethod to be false (the default) where that setting is available. For the WebSocket API, failed credentials can also fall back to the anonymous user role; this path does not enforce strictAuthMethod. The authentication data kept for such a request still contained the request\u0027s Authorization header. MultiRolesTokenAuthorizationProvider then read the bearer token from that header without verifying its signature and authorized the request with the roles in the token\u0027s role claim.\n\nAs a result, in deployments that use MultiRolesTokenAuthorizationProvider together with a non-empty anonymousUserRole and that permit this fallback, an unauthenticated client can send an HTTP request, for example to the admin REST API or the WebSocket API, with a forged or unsigned token that lists arbitrary roles, and be authorized with those roles. The impact can include super-user access when the token lists a role configured in superUserRoles, allowing the client to read and change tenants, namespaces, topics, permissions and broker configuration. No valid credentials are required.\n\nDeployments are not affected if they use the default authorization provider (PulsarAuthorizationProvider) or another authorization provider, or if anonymousUserRole is not set (the default). Requests that authenticate successfully with a valid token are not affected, because the token that MultiRolesTokenAuthorizationProvider reads is the token that authentication verified. Connections that use the Pulsar binary protocol are not affected by this issue, because the broker does not keep client authentication data for connections that it assigns to the anonymous user role.\n\nIn fixed versions, MultiRolesTokenAuthorizationProvider obtains roles only from tokens that the configured token authentication provider has verified, using its configured keys and validation settings. Broker HTTP requests that are assigned to the anonymous user role are authorized only as that role, and invalid tokens cannot supply additional roles to WebSocket requests. The broker fails to start if MultiRolesTokenAuthorizationProvider is configured with authorization enabled but without a token authentication provider.\n\nThis issue affects Apache Pulsar versions from 2.8.1 before 4.0.14 and from 4.1.0 before 4.2.5.\n\n- 4.0.x version users should upgrade to at least 4.0.14.\n- 4.1.x and 4.2.x version users should upgrade to at least 4.2.5.\n\nUsers operating versions prior to those listed above should upgrade to the aforementioned patched versions or newer versions.\n\nThe currently supported Apache Pulsar release lines are 4.0.x and 5.0.x. The supported versions schedule is available at https://pulsar.apache.org/contribute/release-policy/.\n\nUsers who cannot upgrade immediately can remove the anonymousUserRole setting from the broker and WebSocket service configurations, or restrict network access to the HTTP endpoints of these services to trusted clients."
          },
          {
            "lang": "es",
            "value": "El \u201cMultiRolesTokenAuthorizationProvider\u201d de Apache Pulsar autoriza a un cliente con todos los roles enumerados en una declaraci\u00f3n (claim) de su JSON Web Token (JWT). El proveedor est\u00e1 dise\u00f1ado para usarse con autenticaci\u00f3n de tokens, que verifica el token antes de la autorizaci\u00f3n. El proveedor no verificaba el token en s\u00ed: analizaba las declaraciones (claims) del token con la firma eliminada y confiaba en que la autenticaci\u00f3n ya lo hab\u00eda comprobado.\n\nCuando la autenticaci\u00f3n y la autorizaci\u00f3n est\u00e1n habilitadas con una configuraci\u00f3n \u201canonymousUserRole\u201d no vac\u00eda, algunas solicitudes HTTP cuyas credenciales fallan la autenticaci\u00f3n no son rechazadas, sino que se manejan como solicitudes del rol de usuario an\u00f3nimo. Para los endpoints HTTP del broker, como la API REST de administraci\u00f3n, esta alternativa se aplica a las solicitudes que no especifican un m\u00e9todo de autenticaci\u00f3n y requiere que \u201cstrictAuthMethod\u201d sea \u201cfalse\u201d (el valor predeterminado) donde esa configuraci\u00f3n est\u00e9 disponible. Para la API WebSocket, las credenciales fallidas tambi\u00e9n pueden recurrir al rol de usuario an\u00f3nimo; esta ruta no aplica \u201cstrictAuthMethod\u201d. Los datos de autenticaci\u00f3n conservados para dicha solicitud todav\u00eda conten\u00edan el encabezado \u201cAuthorization\u201d de la solicitud. \u201cMultiRolesTokenAuthorizationProvider\u201d entonces le\u00eda el token de portador de ese encabezado sin verificar su firma y autorizaba la solicitud con los roles en la declaraci\u00f3n (claim) de rol del token.\n\nComo resultado, en implementaciones que utilizan \u201cMultiRolesTokenAuthorizationProvider\u201d junto con un \u201canonymousUserRole\u201d no vac\u00edo y que permiten esta alternativa, un cliente no autenticado puede enviar una solicitud HTTP, por ejemplo a la API REST de administraci\u00f3n o a la API WebSocket, con un token falsificado o sin firmar que enumera roles arbitrarios, y ser autorizado con esos roles. El impacto puede incluir acceso de superusuario cuando el token enumera un rol configurado en \u201csuperUserRoles\u201d, permitiendo al cliente leer y cambiar tenants, namespaces, temas, permisos y la configuraci\u00f3n del broker. No se requieren credenciales v\u00e1lidas.\n\nLas implementaciones no se ven afectadas si utilizan el proveedor de autorizaci\u00f3n predeterminado (\u201cPulsarAuthorizationProvider\u201d) o cualquier otro proveedor de autorizaci\u00f3n, o si \u201canonymousUserRole\u201d no est\u00e1 configurado (el valor predeterminado). Las solicitudes que se autentican correctamente con un token v\u00e1lido no se ven afectadas, porque el token que \u201cMultiRolesTokenAuthorizationProvider\u201d lee es el token que la autenticaci\u00f3n verific\u00f3. Las conexiones que utilizan el protocolo binario de Pulsar no se ven afectadas por este problema, porque el broker no conserva los datos de autenticaci\u00f3n del cliente para las conexiones que asigna al rol de usuario an\u00f3nimo.\n\nEn las versiones corregidas, \u201cMultiRolesTokenAuthorizationProvider\u201d obtiene roles solo de tokens que el proveedor de autenticaci\u00f3n de tokens configurado ha verificado, utilizando sus claves y configuraciones de validaci\u00f3n configuradas. Las solicitudes HTTP del broker que se asignan al rol de usuario an\u00f3nimo se autorizan solo como ese rol, y los tokens inv\u00e1lidos no pueden proporcionar roles adicionales a las solicitudes WebSocket. El broker no se inicia si \u201cMultiRolesTokenAuthorizationProvider\u201d est\u00e1 configurado con la autorizaci\u00f3n habilitada pero sin un proveedor de autenticaci\u00f3n de tokens.\n\nEste problema afecta a las versiones de Apache Pulsar desde la 2.8.1 anteriores a la 4.0.14 y desde la 4.1.0 anteriores a la 4.2.5.\n\n- Los usuarios de la versi\u00f3n 4.0.x deber\u00edan actualizar a al menos la 4.0.14.\n- Los usuarios de las versiones 4.1.x y 4.2.x deber\u00edan actualizar a al menos la 4.2.5.\n\nLos usuarios que operen versiones anteriores a las mencionadas deber\u00edan actualizar a las versiones parcheadas o m\u00e1s recientes.\n\nLas l\u00edneas de lanzamiento de Apache Pulsar actualmente soportadas son la 4.0.x y la 5.0.x. El calendario de versiones soportadas est\u00e1 disponible en https://pulsar.apache.org/contribute/release-policy/.\n\nLos usuarios que no puedan actualizar de inmediato pueden eliminar --TRUNCADO--"
          }
        ],
        "id": "CVE-2026-105869",
        "lastModified": "2026-10-26T10:10:00.140",
        "metrics": {
          "cvssMetricV40": [
            {
              "cvssData": {
                "Automatable": "NOT_DEFINED",
                "Recovery": "NOT_DEFINED",
                "Safety": "NOT_DEFINED",
                "attackComplexity": "LOW",
                "attackRequirements": "PRESENT",
                "attackVector": "NETWORK",
                "availabilityRequirement": "NOT_DEFINED",
                "baseScore": 9.2,
                "baseSeverity": "CRITICAL",
                "confidentialityRequirement": "NOT_DEFINED",
                "exploitMaturity": "NOT_DEFINED",
                "integrityRequirement": "NOT_DEFINED",
                "modifiedAttackComplexity": "NOT_DEFINED",
                "modifiedAttackRequirements": "NOT_DEFINED",
                "modifiedAttackVector": "NOT_DEFINED",
                "modifiedPrivilegesRequired": "NOT_DEFINED",
                "modifiedSubAvailabilityImpact": "NOT_DEFINED",
                "modifiedSubConfidentialityImpact": "NOT_DEFINED",
                "modifiedSubIntegrityImpact": "NOT_DEFINED",
                "modifiedUserInteraction": "NOT_DEFINED",
                "modifiedVulnAvailabilityImpact": "NOT_DEFINED",
                "modifiedVulnConfidentialityImpact": "NOT_DEFINED",
                "modifiedVulnIntegrityImpact": "NOT_DEFINED",
                "privilegesRequired": "NONE",
                "providerUrgency": "NOT_DEFINED",
                "subAvailabilityImpact": "NONE",
                "subConfidentialityImpact": "NONE",
                "subIntegrityImpact": "NONE",
                "userInteraction": "NONE",
                "valueDensity": "NOT_DEFINED",
                "vectorString": "CVSS:4.0/AV:N/AC:L/AT:P/PR:N/UI:N/VC:H/VI:H/VA:H/SC:N/SI:N/SA:N/E:X/CR:X/IR:X/AR:X/MAV:X/MAC:X/MAT:X/MPR:X/MUI:X/MVC:X/MVI:X/MVA:X/MSC:X/MSI:X/MSA:X/S:X/AU:X/R:X/V:X/RE:X/U:X",
                "version": "4.0",
                "vulnAvailabilityImpact": "HIGH",
                "vulnConfidentialityImpact": "HIGH",
                "vulnIntegrityImpact": "HIGH",
                "vulnerabilityResponseEffort": "NOT_DEFINED"
              },
              "source": "security@apache.org",
              "type": "Secondary"
            }
          ]
        },
        "published": "2026-10-21T18:17:22.293",
        "references": [
          {
            "source": "security@apache.org",
            "url": "https://lists.apache.org/thread.html/lf36z1tlcsokp4gv97obkdjtt74ngmrw"
          },
          {
            "source": "security@apache.org",
            "url": "https://pulsar.apache.org/security/CVE-2026-105869/"
          }
        ],
        "sourceIdentifier": "security@apache.org",
        "vulnStatus": "Awaiting Analysis",
        "weaknesses": [
          {
            "description": [
              {
                "lang": "en",
                "value": "CWE-347"
              }
            ],
            "source": "security@apache.org",
            "type": "Primary"
          }
        ]
      }
    }
  }
}

FKIE_CVE-2026-105869

Vulnerability from fkie_nvd - Published: 2026-10-21 18:17 - Updated: 2026-10-26 10:10

Severity

9.2 (Critical) - CVSS:4.0/AV:N/AC:L/AT:P/PR:N/UI:N/VC:H/VI:H/VA:H/SC:N/SI:N/SA:N

Summary

References

	URL	Tags
	security@apache.org	https://lists.apache.org/thread.html/lf36z1tlcsokp4gv97obkdjtt74ngmrw
	security@apache.org	https://pulsar.apache.org/security/CVE-2026-105869/

Impacted products

	Vendor	Product	Version

JSON

To clipboard

{
  "affected": [
    {
      "affectedData": [
        {
          "defaultStatus": "unaffected",
          "product": "Apache Pulsar",
          "vendor": "Apache Software Foundation",
          "versions": [
            {
              "lessThan": "4.0.14",
              "status": "affected",
              "version": "2.8.1",
              "versionType": "semver"
            },
            {
              "lessThan": "4.2.5",
              "status": "affected",
              "version": "4.1.0",
              "versionType": "semver"
            }
          ]
        }
      ],
      "source": "security@apache.org"
    }
  ],
  "cveTags": [],
  "descriptions": [
    {
      "lang": "en",
      "value": "Apache Pulsar\u0027s MultiRolesTokenAuthorizationProvider authorizes a client with all roles listed in a claim of its JSON Web Token (JWT). The provider is intended for use with token authentication, which verifies the token before authorization. The provider did not verify the token itself: it parsed the token\u0027s claims with the signature removed and trusted that authentication had already checked it.\n\nWhen authentication and authorization are enabled with a non-empty anonymousUserRole setting, some HTTP requests whose credentials fail authentication are not rejected, but are handled as requests of the anonymous user role. For the broker\u0027s HTTP endpoints, such as the admin REST API, this fallback applies to requests that do not name an authentication method and requires strictAuthMethod to be false (the default) where that setting is available. For the WebSocket API, failed credentials can also fall back to the anonymous user role; this path does not enforce strictAuthMethod. The authentication data kept for such a request still contained the request\u0027s Authorization header. MultiRolesTokenAuthorizationProvider then read the bearer token from that header without verifying its signature and authorized the request with the roles in the token\u0027s role claim.\n\nAs a result, in deployments that use MultiRolesTokenAuthorizationProvider together with a non-empty anonymousUserRole and that permit this fallback, an unauthenticated client can send an HTTP request, for example to the admin REST API or the WebSocket API, with a forged or unsigned token that lists arbitrary roles, and be authorized with those roles. The impact can include super-user access when the token lists a role configured in superUserRoles, allowing the client to read and change tenants, namespaces, topics, permissions and broker configuration. No valid credentials are required.\n\nDeployments are not affected if they use the default authorization provider (PulsarAuthorizationProvider) or another authorization provider, or if anonymousUserRole is not set (the default). Requests that authenticate successfully with a valid token are not affected, because the token that MultiRolesTokenAuthorizationProvider reads is the token that authentication verified. Connections that use the Pulsar binary protocol are not affected by this issue, because the broker does not keep client authentication data for connections that it assigns to the anonymous user role.\n\nIn fixed versions, MultiRolesTokenAuthorizationProvider obtains roles only from tokens that the configured token authentication provider has verified, using its configured keys and validation settings. Broker HTTP requests that are assigned to the anonymous user role are authorized only as that role, and invalid tokens cannot supply additional roles to WebSocket requests. The broker fails to start if MultiRolesTokenAuthorizationProvider is configured with authorization enabled but without a token authentication provider.\n\nThis issue affects Apache Pulsar versions from 2.8.1 before 4.0.14 and from 4.1.0 before 4.2.5.\n\n- 4.0.x version users should upgrade to at least 4.0.14.\n- 4.1.x and 4.2.x version users should upgrade to at least 4.2.5.\n\nUsers operating versions prior to those listed above should upgrade to the aforementioned patched versions or newer versions.\n\nThe currently supported Apache Pulsar release lines are 4.0.x and 5.0.x. The supported versions schedule is available at https://pulsar.apache.org/contribute/release-policy/.\n\nUsers who cannot upgrade immediately can remove the anonymousUserRole setting from the broker and WebSocket service configurations, or restrict network access to the HTTP endpoints of these services to trusted clients."
    },
    {
      "lang": "es",
      "value": "El \u201cMultiRolesTokenAuthorizationProvider\u201d de Apache Pulsar autoriza a un cliente con todos los roles enumerados en una declaraci\u00f3n (claim) de su JSON Web Token (JWT). El proveedor est\u00e1 dise\u00f1ado para usarse con autenticaci\u00f3n de tokens, que verifica el token antes de la autorizaci\u00f3n. El proveedor no verificaba el token en s\u00ed: analizaba las declaraciones (claims) del token con la firma eliminada y confiaba en que la autenticaci\u00f3n ya lo hab\u00eda comprobado.\n\nCuando la autenticaci\u00f3n y la autorizaci\u00f3n est\u00e1n habilitadas con una configuraci\u00f3n \u201canonymousUserRole\u201d no vac\u00eda, algunas solicitudes HTTP cuyas credenciales fallan la autenticaci\u00f3n no son rechazadas, sino que se manejan como solicitudes del rol de usuario an\u00f3nimo. Para los endpoints HTTP del broker, como la API REST de administraci\u00f3n, esta alternativa se aplica a las solicitudes que no especifican un m\u00e9todo de autenticaci\u00f3n y requiere que \u201cstrictAuthMethod\u201d sea \u201cfalse\u201d (el valor predeterminado) donde esa configuraci\u00f3n est\u00e9 disponible. Para la API WebSocket, las credenciales fallidas tambi\u00e9n pueden recurrir al rol de usuario an\u00f3nimo; esta ruta no aplica \u201cstrictAuthMethod\u201d. Los datos de autenticaci\u00f3n conservados para dicha solicitud todav\u00eda conten\u00edan el encabezado \u201cAuthorization\u201d de la solicitud. \u201cMultiRolesTokenAuthorizationProvider\u201d entonces le\u00eda el token de portador de ese encabezado sin verificar su firma y autorizaba la solicitud con los roles en la declaraci\u00f3n (claim) de rol del token.\n\nComo resultado, en implementaciones que utilizan \u201cMultiRolesTokenAuthorizationProvider\u201d junto con un \u201canonymousUserRole\u201d no vac\u00edo y que permiten esta alternativa, un cliente no autenticado puede enviar una solicitud HTTP, por ejemplo a la API REST de administraci\u00f3n o a la API WebSocket, con un token falsificado o sin firmar que enumera roles arbitrarios, y ser autorizado con esos roles. El impacto puede incluir acceso de superusuario cuando el token enumera un rol configurado en \u201csuperUserRoles\u201d, permitiendo al cliente leer y cambiar tenants, namespaces, temas, permisos y la configuraci\u00f3n del broker. No se requieren credenciales v\u00e1lidas.\n\nLas implementaciones no se ven afectadas si utilizan el proveedor de autorizaci\u00f3n predeterminado (\u201cPulsarAuthorizationProvider\u201d) o cualquier otro proveedor de autorizaci\u00f3n, o si \u201canonymousUserRole\u201d no est\u00e1 configurado (el valor predeterminado). Las solicitudes que se autentican correctamente con un token v\u00e1lido no se ven afectadas, porque el token que \u201cMultiRolesTokenAuthorizationProvider\u201d lee es el token que la autenticaci\u00f3n verific\u00f3. Las conexiones que utilizan el protocolo binario de Pulsar no se ven afectadas por este problema, porque el broker no conserva los datos de autenticaci\u00f3n del cliente para las conexiones que asigna al rol de usuario an\u00f3nimo.\n\nEn las versiones corregidas, \u201cMultiRolesTokenAuthorizationProvider\u201d obtiene roles solo de tokens que el proveedor de autenticaci\u00f3n de tokens configurado ha verificado, utilizando sus claves y configuraciones de validaci\u00f3n configuradas. Las solicitudes HTTP del broker que se asignan al rol de usuario an\u00f3nimo se autorizan solo como ese rol, y los tokens inv\u00e1lidos no pueden proporcionar roles adicionales a las solicitudes WebSocket. El broker no se inicia si \u201cMultiRolesTokenAuthorizationProvider\u201d est\u00e1 configurado con la autorizaci\u00f3n habilitada pero sin un proveedor de autenticaci\u00f3n de tokens.\n\nEste problema afecta a las versiones de Apache Pulsar desde la 2.8.1 anteriores a la 4.0.14 y desde la 4.1.0 anteriores a la 4.2.5.\n\n- Los usuarios de la versi\u00f3n 4.0.x deber\u00edan actualizar a al menos la 4.0.14.\n- Los usuarios de las versiones 4.1.x y 4.2.x deber\u00edan actualizar a al menos la 4.2.5.\n\nLos usuarios que operen versiones anteriores a las mencionadas deber\u00edan actualizar a las versiones parcheadas o m\u00e1s recientes.\n\nLas l\u00edneas de lanzamiento de Apache Pulsar actualmente soportadas son la 4.0.x y la 5.0.x. El calendario de versiones soportadas est\u00e1 disponible en https://pulsar.apache.org/contribute/release-policy/.\n\nLos usuarios que no puedan actualizar de inmediato pueden eliminar --TRUNCADO--"
    }
  ],
  "id": "CVE-2026-105869",
  "lastModified": "2026-10-26T10:10:00.140",
  "metrics": {
    "cvssMetricV40": [
      {
        "cvssData": {
          "Automatable": "NOT_DEFINED",
          "Recovery": "NOT_DEFINED",
          "Safety": "NOT_DEFINED",
          "attackComplexity": "LOW",
          "attackRequirements": "PRESENT",
          "attackVector": "NETWORK",
          "availabilityRequirement": "NOT_DEFINED",
          "baseScore": 9.2,
          "baseSeverity": "CRITICAL",
          "confidentialityRequirement": "NOT_DEFINED",
          "exploitMaturity": "NOT_DEFINED",
          "integrityRequirement": "NOT_DEFINED",
          "modifiedAttackComplexity": "NOT_DEFINED",
          "modifiedAttackRequirements": "NOT_DEFINED",
          "modifiedAttackVector": "NOT_DEFINED",
          "modifiedPrivilegesRequired": "NOT_DEFINED",
          "modifiedSubAvailabilityImpact": "NOT_DEFINED",
          "modifiedSubConfidentialityImpact": "NOT_DEFINED",
          "modifiedSubIntegrityImpact": "NOT_DEFINED",
          "modifiedUserInteraction": "NOT_DEFINED",
          "modifiedVulnAvailabilityImpact": "NOT_DEFINED",
          "modifiedVulnConfidentialityImpact": "NOT_DEFINED",
          "modifiedVulnIntegrityImpact": "NOT_DEFINED",
          "privilegesRequired": "NONE",
          "providerUrgency": "NOT_DEFINED",
          "subAvailabilityImpact": "NONE",
          "subConfidentialityImpact": "NONE",
          "subIntegrityImpact": "NONE",
          "userInteraction": "NONE",
          "valueDensity": "NOT_DEFINED",
          "vectorString": "CVSS:4.0/AV:N/AC:L/AT:P/PR:N/UI:N/VC:H/VI:H/VA:H/SC:N/SI:N/SA:N/E:X/CR:X/IR:X/AR:X/MAV:X/MAC:X/MAT:X/MPR:X/MUI:X/MVC:X/MVI:X/MVA:X/MSC:X/MSI:X/MSA:X/S:X/AU:X/R:X/V:X/RE:X/U:X",
          "version": "4.0",
          "vulnAvailabilityImpact": "HIGH",
          "vulnConfidentialityImpact": "HIGH",
          "vulnIntegrityImpact": "HIGH",
          "vulnerabilityResponseEffort": "NOT_DEFINED"
        },
        "source": "security@apache.org",
        "type": "Secondary"
      }
    ]
  },
  "published": "2026-10-21T18:17:22.293",
  "references": [
    {
      "source": "security@apache.org",
      "url": "https://lists.apache.org/thread.html/lf36z1tlcsokp4gv97obkdjtt74ngmrw"
    },
    {
      "source": "security@apache.org",
      "url": "https://pulsar.apache.org/security/CVE-2026-105869/"
    }
  ],
  "sourceIdentifier": "security@apache.org",
  "vulnStatus": "Awaiting Analysis",
  "weaknesses": [
    {
      "description": [
        {
          "lang": "en",
          "value": "CWE-347"
        }
      ],
      "source": "security@apache.org",
      "type": "Primary"
    }
  ]
}

GHSA-2X72-7FCR-36H8

Vulnerability from github – Published: 2026-10-21 18:33 – Updated: 2026-10-21 18:33

Details

When authentication and authorization are enabled with a non-empty anonymousUserRole setting, some HTTP requests whose credentials fail authentication are not rejected, but are handled as requests of the anonymous user role. For the broker's HTTP endpoints, such as the admin REST API, this fallback applies to requests that do not name an authentication method and requires strictAuthMethod to be false (the default) where that setting is available. For the WebSocket API, failed credentials can also fall back to the anonymous user role; this path does not enforce strictAuthMethod. The authentication data kept for such a request still contained the request's Authorization header. MultiRolesTokenAuthorizationProvider then read the bearer token from that header without verifying its signature and authorized the request with the roles in the token's role claim.

As a result, in deployments that use MultiRolesTokenAuthorizationProvider together with a non-empty anonymousUserRole and that permit this fallback, an unauthenticated client can send an HTTP request, for example to the admin REST API or the WebSocket API, with a forged or unsigned token that lists arbitrary roles, and be authorized with those roles. The impact can include super-user access when the token lists a role configured in superUserRoles, allowing the client to read and change tenants, namespaces, topics, permissions and broker configuration. No valid credentials are required.

Deployments are not affected if they use the default authorization provider (PulsarAuthorizationProvider) or another authorization provider, or if anonymousUserRole is not set (the default). Requests that authenticate successfully with a valid token are not affected, because the token that MultiRolesTokenAuthorizationProvider reads is the token that authentication verified. Connections that use the Pulsar binary protocol are not affected by this issue, because the broker does not keep client authentication data for connections that it assigns to the anonymous user role.

In fixed versions, MultiRolesTokenAuthorizationProvider obtains roles only from tokens that the configured token authentication provider has verified, using its configured keys and validation settings. Broker HTTP requests that are assigned to the anonymous user role are authorized only as that role, and invalid tokens cannot supply additional roles to WebSocket requests. The broker fails to start if MultiRolesTokenAuthorizationProvider is configured with authorization enabled but without a token authentication provider.

This issue affects Apache Pulsar versions from 2.8.1 before 4.0.14 and from 4.1.0 before 4.2.5.

4.0.x version users should upgrade to at least 4.0.14.
4.1.x and 4.2.x version users should upgrade to at least 4.2.5.

Users operating versions prior to those listed above should upgrade to the aforementioned patched versions or newer versions.

The currently supported Apache Pulsar release lines are 4.0.x and 5.0.x. The supported versions schedule is available at https://pulsar.apache.org/contribute/release-policy/.

Users who cannot upgrade immediately can remove the anonymousUserRole setting from the broker and WebSocket service configurations, or restrict network access to the HTTP endpoints of these services to trusted clients.

Severity

9.2 (Critical)


                  
                    CVSS:4.0/AV:N/AC:L/AT:P/PR:N/UI:N/VC:H/VI:H/VA:H/SC:N/SI:N/SA:N

Show details on source website

JSON

To clipboard

{
  "affected": [],
  "aliases": [
    "CVE-2026-105869"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-347"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2026-10-21T18:17:22Z",
    "severity": "CRITICAL"
  },
  "details": "Apache Pulsar\u0027s MultiRolesTokenAuthorizationProvider authorizes a client with all roles listed in a claim of its JSON Web Token (JWT). The provider is intended for use with token authentication, which verifies the token before authorization. The provider did not verify the token itself: it parsed the token\u0027s claims with the signature removed and trusted that authentication had already checked it.\n\nWhen authentication and authorization are enabled with a non-empty anonymousUserRole setting, some HTTP requests whose credentials fail authentication are not rejected, but are handled as requests of the anonymous user role. For the broker\u0027s HTTP endpoints, such as the admin REST API, this fallback applies to requests that do not name an authentication method and requires strictAuthMethod to be false (the default) where that setting is available. For the WebSocket API, failed credentials can also fall back to the anonymous user role; this path does not enforce strictAuthMethod. The authentication data kept for such a request still contained the request\u0027s Authorization header. MultiRolesTokenAuthorizationProvider then read the bearer token from that header without verifying its signature and authorized the request with the roles in the token\u0027s role claim.\n\nAs a result, in deployments that use MultiRolesTokenAuthorizationProvider together with a non-empty anonymousUserRole and that permit this fallback, an unauthenticated client can send an HTTP request, for example to the admin REST API or the WebSocket API, with a forged or unsigned token that lists arbitrary roles, and be authorized with those roles. The impact can include super-user access when the token lists a role configured in superUserRoles, allowing the client to read and change tenants, namespaces, topics, permissions and broker configuration. No valid credentials are required.\n\nDeployments are not affected if they use the default authorization provider (PulsarAuthorizationProvider) or another authorization provider, or if anonymousUserRole is not set (the default). Requests that authenticate successfully with a valid token are not affected, because the token that MultiRolesTokenAuthorizationProvider reads is the token that authentication verified. Connections that use the Pulsar binary protocol are not affected by this issue, because the broker does not keep client authentication data for connections that it assigns to the anonymous user role.\n\nIn fixed versions, MultiRolesTokenAuthorizationProvider obtains roles only from tokens that the configured token authentication provider has verified, using its configured keys and validation settings. Broker HTTP requests that are assigned to the anonymous user role are authorized only as that role, and invalid tokens cannot supply additional roles to WebSocket requests. The broker fails to start if MultiRolesTokenAuthorizationProvider is configured with authorization enabled but without a token authentication provider.\n\nThis issue affects Apache Pulsar versions from 2.8.1 before 4.0.14 and from 4.1.0 before 4.2.5.\n\n- 4.0.x version users should upgrade to at least 4.0.14.\n- 4.1.x and 4.2.x version users should upgrade to at least 4.2.5.\n\nUsers operating versions prior to those listed above should upgrade to the aforementioned patched versions or newer versions.\n\nThe currently supported Apache Pulsar release lines are 4.0.x and 5.0.x. The supported versions schedule is available at https://pulsar.apache.org/contribute/release-policy/.\n\nUsers who cannot upgrade immediately can remove the anonymousUserRole setting from the broker and WebSocket service configurations, or restrict network access to the HTTP endpoints of these services to trusted clients.",
  "id": "GHSA-2x72-7fcr-36h8",
  "modified": "2026-10-21T18:33:29Z",
  "published": "2026-10-21T18:33:29Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-105869"
    },
    {
      "type": "WEB",
      "url": "https://lists.apache.org/thread.html/lf36z1tlcsokp4gv97obkdjtt74ngmrw"
    },
    {
      "type": "WEB",
      "url": "https://pulsar.apache.org/security/CVE-2026-105869"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:4.0/AV:N/AC:L/AT:P/PR:N/UI:N/VC:H/VI:H/VA:H/SC:N/SI:N/SA:N/E:X/CR:X/IR:X/AR:X/MAV:X/MAC:X/MAT:X/MPR:X/MUI:X/MVC:X/MVI:X/MVA:X/MSC:X/MSI:X/MSA:X/S:X/AU:X/R:X/V:X/RE:X/U:X",
      "type": "CVSS_V4"
    }
  ]
}

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.

Vulnerability timeline

Sightings and recorded dates, grouped by day · UTC

Order JSON

Publication & reservation Sightings KEV catalogs Other timestamps

Loading timeline…

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

CVE-2026-105869 (GCVE-0-2026-105869)

FKIE_CVE-2026-105869

GHSA-2X72-7FCR-36H8

Tags

Sightings

Nomenclature

Vulnerability timeline

Related by attack behaviour