Search
Find a vulnerability
Search criteria
ⓘ
Use this form to refine search results.
Full-text search supports keyword queries with ranking and filtering.
You can combine vendor, product, and sources to narrow results.
Enable “Apply ordering” to sort by date instead of relevance.
5546 vulnerabilities by apache software foundation
CVE-2026-112381 (GCVE-0-2026-112381)
Vulnerability from cvelistv5 – Published: 2026-10-21 19:20 – Updated: 2026-10-21 19:20
VLAI
EPSS
VEX
Title
Apache Traffic Server: Nullptr dereference in net_write_io on a POST half-close with chunked response
Summary
Apache Traffic Server can crash with a null pointer dereference when a client POST request is torn down via half-close while a chunked origin response is being reparsed from a reentrant write-ready callback, a timing-dependent race introduced by the CVE-2021-32564 flow-control backports.
This issue affects Apache Traffic Server: 9.2.15, 10.1.4, 10.2.0.
Users are recommended to upgrade to version 9.2.16, 10.1.5, or 10.2.1, which fix the issue.
Severity
CWE
- CWE-476 - NULL Pointer Dereference
Assigner
References
1 reference
| URL | Tags |
|---|---|
| https://lists.apache.org/thread/r95dq29ywcd1f4x30… | vendor-advisory |
Impacted products
1 product
| Vendor | Product | Version | |
|---|---|---|---|
| Apache Software Foundation | Apache Traffic Server |
Affected:
9.2.15
(semver)
Affected: 10.1.4 (semver) Affected: 10.2.0 (semver) |
{
"containers": {
"cna": {
"affected": [
{
"defaultStatus": "unaffected",
"product": "Apache Traffic Server",
"vendor": "Apache Software Foundation",
"versions": [
{
"status": "affected",
"version": "9.2.15",
"versionType": "semver"
},
{
"status": "affected",
"version": "10.1.4",
"versionType": "semver"
},
{
"status": "affected",
"version": "10.2.0",
"versionType": "semver"
}
]
}
],
"credits": [
{
"lang": "en",
"type": "reporter",
"value": "Masaori Koshiba"
}
],
"descriptions": [
{
"lang": "en",
"supportingMedia": [
{
"base64": false,
"type": "text/html",
"value": "\u003cp\u003eApache Traffic Server can crash with a null pointer dereference when a client POST request is torn down via half-close while a chunked origin response is being reparsed from a reentrant write-ready callback, a timing-dependent race introduced by the CVE-2021-32564 flow-control backports.\u003c/p\u003e\u003cp\u003eThis issue affects Apache Traffic Server: 9.2.15, 10.1.4, 10.2.0.\u003c/p\u003e\u003cp\u003eUsers are recommended to upgrade to version 9.2.16, 10.1.5, or 10.2.1, which fix the issue.\u003c/p\u003e"
}
],
"value": "Apache Traffic Server can crash with a null pointer dereference when a client POST request is torn down via half-close while a chunked origin response is being reparsed from a reentrant write-ready callback, a timing-dependent race introduced by the CVE-2021-32564 flow-control backports.\n\n\n\nThis issue affects Apache Traffic Server: 9.2.15, 10.1.4, 10.2.0.\n\n\n\nUsers are recommended to upgrade to version 9.2.16, 10.1.5, or 10.2.1, which fix the issue."
}
],
"metrics": [
{
"other": {
"content": {
"text": "moderate"
},
"type": "Textual description of severity"
},
"scenarios": [
{
"lang": "en",
"value": "GENERAL"
}
]
},
{
"cvssV3_1": {
"attackComplexity": "HIGH",
"attackVector": "NETWORK",
"availabilityImpact": "HIGH",
"baseScore": 5.9,
"baseSeverity": "MEDIUM",
"confidentialityImpact": "NONE",
"integrityImpact": "NONE",
"privilegesRequired": "NONE",
"scope": "UNCHANGED",
"userInteraction": "NONE",
"vectorString": "CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:N/I:N/A:H",
"version": "3.1"
},
"format": "CVSS",
"scenarios": [
{
"lang": "en",
"value": "GENERAL"
}
]
},
{
"cvssV4_0": {
"Automatable": "NOT_DEFINED",
"Recovery": "NOT_DEFINED",
"Safety": "NOT_DEFINED",
"attackComplexity": "LOW",
"attackRequirements": "PRESENT",
"attackVector": "NETWORK",
"baseScore": 8.2,
"baseSeverity": "HIGH",
"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:N/VI:N/VA:H/SC:N/SI:N/SA:N",
"version": "4.0",
"vulnAvailabilityImpact": "HIGH",
"vulnConfidentialityImpact": "NONE",
"vulnIntegrityImpact": "NONE",
"vulnerabilityResponseEffort": "NOT_DEFINED"
},
"format": "CVSS",
"scenarios": [
{
"lang": "en",
"value": "GENERAL"
}
]
}
],
"problemTypes": [
{
"descriptions": [
{
"cweId": "CWE-476",
"description": "CWE-476 NULL Pointer Dereference",
"lang": "en",
"type": "CWE"
}
]
}
],
"providerMetadata": {
"dateUpdated": "2026-10-21T19:20:38.885Z",
"orgId": "f0158376-9dc2-43b6-827c-5f631a4d8d09",
"shortName": "apache"
},
"references": [
{
"tags": [
"vendor-advisory"
],
"url": "https://lists.apache.org/thread/r95dq29ywcd1f4x30snxlqmb12z4s4kc"
}
],
"source": {
"discovery": "UNKNOWN"
},
"title": "Apache Traffic Server: Nullptr dereference in net_write_io on a POST half-close with chunked response",
"x_generator": {
"engine": "scripts/cve_render.py"
}
}
},
"cveMetadata": {
"assignerOrgId": "f0158376-9dc2-43b6-827c-5f631a4d8d09",
"assignerShortName": "apache",
"cveId": "CVE-2026-112381",
"datePublished": "2026-10-21T19:20:38.885Z",
"dateReserved": "2026-10-19T16:56:57.385Z",
"dateUpdated": "2026-10-21T19:20:38.885Z",
"state": "PUBLISHED"
},
"dataType": "CVE_RECORD",
"dataVersion": "5.2"
}
CVE-2026-111817 (GCVE-0-2026-111817)
Vulnerability from cvelistv5 – Published: 2026-10-21 19:20 – Updated: 2026-10-21 19:20
VLAI
EPSS
VEX
Title
Apache Traffic Server: Dropping chunked trailers stalls a passthrough transfer until timeout
Summary
Apache Traffic Server can stall a chunked transfer that it passes through with its trailers removed (proxy.config.http.drop_chunked_trailers) until the connection times out, because it waits for the trailer bytes it has already dropped. Trailer dropping is on by default in 10.x. In 8.1.11 and 9.2.x it is off by default, and those versions are affected only if it is enabled.
This issue affects Apache Traffic Server: 8.1.11, from 9.2.5 through 9.2.15, from 10.0.0 through 10.1.4, 10.2.0.
Users are recommended to upgrade to version 10.1.5 or 10.2.1, which fix the issue.
Severity
5.3 (Medium)
CWE
- CWE-400 - Uncontrolled Resource Consumption
Assigner
References
1 reference
| URL | Tags |
|---|---|
| https://lists.apache.org/thread/r95dq29ywcd1f4x30… | vendor-advisory |
Impacted products
1 product
| Vendor | Product | Version | |
|---|---|---|---|
| Apache Software Foundation | Apache Traffic Server |
Affected:
8.1.11
(semver)
Affected: 9.2.5 , ≤ 9.2.15 (semver) Affected: 10.0.0 , ≤ 10.1.4 (semver) Affected: 10.2.0 (semver) |
{
"containers": {
"cna": {
"affected": [
{
"defaultStatus": "unaffected",
"product": "Apache Traffic Server",
"vendor": "Apache Software Foundation",
"versions": [
{
"status": "affected",
"version": "8.1.11",
"versionType": "semver"
},
{
"lessThanOrEqual": "9.2.15",
"status": "affected",
"version": "9.2.5",
"versionType": "semver"
},
{
"lessThanOrEqual": "10.1.4",
"status": "affected",
"version": "10.0.0",
"versionType": "semver"
},
{
"status": "affected",
"version": "10.2.0",
"versionType": "semver"
}
]
}
],
"credits": [
{
"lang": "en",
"type": "reporter",
"value": "Omkhar Arasaratnam"
}
],
"descriptions": [
{
"lang": "en",
"supportingMedia": [
{
"base64": false,
"type": "text/html",
"value": "\u003cp\u003eApache Traffic Server can stall a chunked transfer that it passes through with its trailers removed (proxy.config.http.drop_chunked_trailers) until the connection times out, because it waits for the trailer bytes it has already dropped. Trailer dropping is on by default in 10.x. In 8.1.11 and 9.2.x it is off by default, and those versions are affected only if it is enabled.\u003c/p\u003e\u003cp\u003eThis issue affects Apache Traffic Server: 8.1.11, from 9.2.5 through 9.2.15, from 10.0.0 through 10.1.4, 10.2.0.\u003c/p\u003e\u003cp\u003eUsers are recommended to upgrade to version 10.1.5 or 10.2.1, which fix the issue.\u003c/p\u003e"
}
],
"value": "Apache Traffic Server can stall a chunked transfer that it passes through with its trailers removed (proxy.config.http.drop_chunked_trailers) until the connection times out, because it waits for the trailer bytes it has already dropped. Trailer dropping is on by default in 10.x. In 8.1.11 and 9.2.x it is off by default, and those versions are affected only if it is enabled.\n\n\n\nThis issue affects Apache Traffic Server: 8.1.11, from 9.2.5 through 9.2.15, from 10.0.0 through 10.1.4, 10.2.0.\n\n\n\nUsers are recommended to upgrade to version 10.1.5 or 10.2.1, which fix the issue."
}
],
"metrics": [
{
"other": {
"content": {
"text": "moderate"
},
"type": "Textual description of severity"
},
"scenarios": [
{
"lang": "en",
"value": "GENERAL"
}
]
},
{
"cvssV3_1": {
"attackComplexity": "LOW",
"attackVector": "NETWORK",
"availabilityImpact": "LOW",
"baseScore": 5.3,
"baseSeverity": "MEDIUM",
"confidentialityImpact": "NONE",
"integrityImpact": "NONE",
"privilegesRequired": "NONE",
"scope": "UNCHANGED",
"userInteraction": "NONE",
"vectorString": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:L",
"version": "3.1"
},
"format": "CVSS",
"scenarios": [
{
"lang": "en",
"value": "GENERAL"
}
]
},
{
"cvssV4_0": {
"Automatable": "NOT_DEFINED",
"Recovery": "NOT_DEFINED",
"Safety": "NOT_DEFINED",
"attackComplexity": "LOW",
"attackRequirements": "NONE",
"attackVector": "NETWORK",
"baseScore": 6.9,
"baseSeverity": "MEDIUM",
"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:N/PR:N/UI:N/VC:N/VI:N/VA:L/SC:N/SI:N/SA:N",
"version": "4.0",
"vulnAvailabilityImpact": "LOW",
"vulnConfidentialityImpact": "NONE",
"vulnIntegrityImpact": "NONE",
"vulnerabilityResponseEffort": "NOT_DEFINED"
},
"format": "CVSS",
"scenarios": [
{
"lang": "en",
"value": "GENERAL"
}
]
}
],
"problemTypes": [
{
"descriptions": [
{
"cweId": "CWE-400",
"description": "CWE-400 Uncontrolled Resource Consumption",
"lang": "en",
"type": "CWE"
}
]
}
],
"providerMetadata": {
"dateUpdated": "2026-10-21T19:20:00.515Z",
"orgId": "f0158376-9dc2-43b6-827c-5f631a4d8d09",
"shortName": "apache"
},
"references": [
{
"tags": [
"vendor-advisory"
],
"url": "https://lists.apache.org/thread/r95dq29ywcd1f4x30snxlqmb12z4s4kc"
}
],
"source": {
"discovery": "UNKNOWN"
},
"title": "Apache Traffic Server: Dropping chunked trailers stalls a passthrough transfer until timeout",
"x_generator": {
"engine": "scripts/cve_render.py"
}
}
},
"cveMetadata": {
"assignerOrgId": "f0158376-9dc2-43b6-827c-5f631a4d8d09",
"assignerShortName": "apache",
"cveId": "CVE-2026-111817",
"datePublished": "2026-10-21T19:20:00.515Z",
"dateReserved": "2026-10-16T20:29:16.510Z",
"dateUpdated": "2026-10-21T19:20:00.515Z",
"state": "PUBLISHED"
},
"dataType": "CVE_RECORD",
"dataVersion": "5.2"
}
CVE-2026-111812 (GCVE-0-2026-111812)
Vulnerability from cvelistv5 – Published: 2026-10-21 19:18 – Updated: 2026-10-21 19:18
VLAI
EPSS
VEX
Title
Apache Traffic Server: origin_server_auth signs client-controlled AWS headers under the proxy's IAM credentials
Summary
Apache Traffic Server's origin_server_auth plugin lets a client force signing of attacker-chosen AWS request headers under the proxy's own credentials.
This issue affects Apache Traffic Server: from 8.0.0 through 8.1.11, from 9.0.0 through 9.2.15, from 10.0.0 through 10.1.4, 10.2.0.
Users are recommended to upgrade to version 9.2.16, 10.1.5, or 10.2.1, which fix the issue.
Severity
CWE
- CWE-863 - Incorrect Authorization
Assigner
References
1 reference
| URL | Tags |
|---|---|
| https://lists.apache.org/thread/r95dq29ywcd1f4x30… | vendor-advisory |
Impacted products
1 product
| Vendor | Product | Version | |
|---|---|---|---|
| Apache Software Foundation | Apache Traffic Server |
Affected:
8.0.0 , ≤ 8.1.11
(semver)
Affected: 9.0.0 , ≤ 9.2.15 (semver) Affected: 10.0.0 , ≤ 10.1.4 (semver) Affected: 10.2.0 (semver) |
{
"containers": {
"cna": {
"affected": [
{
"defaultStatus": "unaffected",
"product": "Apache Traffic Server",
"vendor": "Apache Software Foundation",
"versions": [
{
"lessThanOrEqual": "8.1.11",
"status": "affected",
"version": "8.0.0",
"versionType": "semver"
},
{
"lessThanOrEqual": "9.2.15",
"status": "affected",
"version": "9.0.0",
"versionType": "semver"
},
{
"lessThanOrEqual": "10.1.4",
"status": "affected",
"version": "10.0.0",
"versionType": "semver"
},
{
"status": "affected",
"version": "10.2.0",
"versionType": "semver"
}
]
}
],
"credits": [
{
"lang": "en",
"type": "reporter",
"value": "Apache Community"
}
],
"descriptions": [
{
"lang": "en",
"supportingMedia": [
{
"base64": false,
"type": "text/html",
"value": "\u003cp\u003eApache Traffic Server\u0027s origin_server_auth plugin lets a client force signing of attacker-chosen AWS request headers under the proxy\u0027s own credentials.\u003c/p\u003e\u003cp\u003eThis issue affects Apache Traffic Server: from 8.0.0 through 8.1.11, from 9.0.0 through 9.2.15, from 10.0.0 through 10.1.4, 10.2.0.\u003c/p\u003e\u003cp\u003eUsers are recommended to upgrade to version 9.2.16, 10.1.5, or 10.2.1, which fix the issue.\u003c/p\u003e"
}
],
"value": "Apache Traffic Server\u0027s origin_server_auth plugin lets a client force signing of attacker-chosen AWS request headers under the proxy\u0027s own credentials.\n\n\n\nThis issue affects Apache Traffic Server: from 8.0.0 through 8.1.11, from 9.0.0 through 9.2.15, from 10.0.0 through 10.1.4, 10.2.0.\n\n\n\nUsers are recommended to upgrade to version 9.2.16, 10.1.5, or 10.2.1, which fix the issue."
}
],
"metrics": [
{
"other": {
"content": {
"text": "moderate"
},
"type": "Textual description of severity"
},
"scenarios": [
{
"lang": "en",
"value": "GENERAL"
}
]
},
{
"cvssV3_1": {
"attackComplexity": "LOW",
"attackVector": "NETWORK",
"availabilityImpact": "NONE",
"baseScore": 10,
"baseSeverity": "CRITICAL",
"confidentialityImpact": "HIGH",
"integrityImpact": "HIGH",
"privilegesRequired": "NONE",
"scope": "CHANGED",
"userInteraction": "NONE",
"vectorString": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:C/C:H/I:H/A:N",
"version": "3.1"
},
"format": "CVSS",
"scenarios": [
{
"lang": "en",
"value": "GENERAL"
}
]
},
{
"cvssV4_0": {
"Automatable": "NOT_DEFINED",
"Recovery": "NOT_DEFINED",
"Safety": "NOT_DEFINED",
"attackComplexity": "LOW",
"attackRequirements": "PRESENT",
"attackVector": "NETWORK",
"baseScore": 7,
"baseSeverity": "HIGH",
"exploitMaturity": "NOT_DEFINED",
"privilegesRequired": "NONE",
"providerUrgency": "NOT_DEFINED",
"subAvailabilityImpact": "NONE",
"subConfidentialityImpact": "HIGH",
"subIntegrityImpact": "HIGH",
"userInteraction": "NONE",
"valueDensity": "NOT_DEFINED",
"vectorString": "CVSS:4.0/AV:N/AC:L/AT:P/PR:N/UI:N/VC:N/VI:N/VA:N/SC:H/SI:H/SA:N",
"version": "4.0",
"vulnAvailabilityImpact": "NONE",
"vulnConfidentialityImpact": "NONE",
"vulnIntegrityImpact": "NONE",
"vulnerabilityResponseEffort": "NOT_DEFINED"
},
"format": "CVSS",
"scenarios": [
{
"lang": "en",
"value": "GENERAL"
}
]
}
],
"problemTypes": [
{
"descriptions": [
{
"cweId": "CWE-863",
"description": "CWE-863 Incorrect Authorization",
"lang": "en",
"type": "CWE"
}
]
}
],
"providerMetadata": {
"dateUpdated": "2026-10-21T19:18:19.526Z",
"orgId": "f0158376-9dc2-43b6-827c-5f631a4d8d09",
"shortName": "apache"
},
"references": [
{
"tags": [
"vendor-advisory"
],
"url": "https://lists.apache.org/thread/r95dq29ywcd1f4x30snxlqmb12z4s4kc"
}
],
"source": {
"discovery": "UNKNOWN"
},
"title": "Apache Traffic Server: origin_server_auth signs client-controlled AWS headers under the proxy\u0027s IAM credentials",
"x_generator": {
"engine": "scripts/cve_render.py"
}
}
},
"cveMetadata": {
"assignerOrgId": "f0158376-9dc2-43b6-827c-5f631a4d8d09",
"assignerShortName": "apache",
"cveId": "CVE-2026-111812",
"datePublished": "2026-10-21T19:18:19.526Z",
"dateReserved": "2026-10-16T20:22:21.735Z",
"dateUpdated": "2026-10-21T19:18:19.526Z",
"state": "PUBLISHED"
},
"dataType": "CVE_RECORD",
"dataVersion": "5.2"
}
CVE-2026-111811 (GCVE-0-2026-111811)
Vulnerability from cvelistv5 – Published: 2026-10-21 19:17 – Updated: 2026-10-21 19:17
VLAI
EPSS
VEX
Title
Apache Traffic Server: tsmemcache plugin exposes the shared proxy cache over the network with no authentication
Summary
Apache Traffic Server's experimental tsmemcache plugin allows unauthenticated network read, write, and deletion of the shared proxy cache.
This issue affects Apache Traffic Server: from 8.0.0 through 8.1.11, from 9.0.0 through 9.2.15, from 10.0.0 through 10.1.4, 10.2.0.
Users are recommended to upgrade to version 9.2.16, 10.1.5, or 10.2.1, which fix the issue.
Severity
9 (Critical)
CWE
- CWE-306 - Missing Authentication for Critical Function
Assigner
References
1 reference
| URL | Tags |
|---|---|
| https://lists.apache.org/thread/r95dq29ywcd1f4x30… | vendor-advisory |
Impacted products
1 product
| Vendor | Product | Version | |
|---|---|---|---|
| Apache Software Foundation | Apache Traffic Server |
Affected:
8.0.0 , ≤ 8.1.11
(semver)
Affected: 9.0.0 , ≤ 9.2.15 (semver) Affected: 10.0.0 , ≤ 10.1.4 (semver) Affected: 10.2.0 (semver) |
{
"containers": {
"cna": {
"affected": [
{
"defaultStatus": "unaffected",
"product": "Apache Traffic Server",
"vendor": "Apache Software Foundation",
"versions": [
{
"lessThanOrEqual": "8.1.11",
"status": "affected",
"version": "8.0.0",
"versionType": "semver"
},
{
"lessThanOrEqual": "9.2.15",
"status": "affected",
"version": "9.0.0",
"versionType": "semver"
},
{
"lessThanOrEqual": "10.1.4",
"status": "affected",
"version": "10.0.0",
"versionType": "semver"
},
{
"status": "affected",
"version": "10.2.0",
"versionType": "semver"
}
]
}
],
"credits": [
{
"lang": "en",
"type": "reporter",
"value": "Apache Community"
}
],
"descriptions": [
{
"lang": "en",
"supportingMedia": [
{
"base64": false,
"type": "text/html",
"value": "\u003cp\u003eApache Traffic Server\u0027s experimental tsmemcache plugin allows unauthenticated network read, write, and deletion of the shared proxy cache.\u003c/p\u003e\u003cp\u003eThis issue affects Apache Traffic Server: from 8.0.0 through 8.1.11, from 9.0.0 through 9.2.15, from 10.0.0 through 10.1.4, 10.2.0.\u003c/p\u003e\u003cp\u003eUsers are recommended to upgrade to version 9.2.16, 10.1.5, or 10.2.1, which fix the issue.\u003c/p\u003e"
}
],
"value": "Apache Traffic Server\u0027s experimental tsmemcache plugin allows unauthenticated network read, write, and deletion of the shared proxy cache.\n\n\n\nThis issue affects Apache Traffic Server: from 8.0.0 through 8.1.11, from 9.0.0 through 9.2.15, from 10.0.0 through 10.1.4, 10.2.0.\n\n\n\nUsers are recommended to upgrade to version 9.2.16, 10.1.5, or 10.2.1, which fix the issue."
}
],
"metrics": [
{
"other": {
"content": {
"text": "moderate"
},
"type": "Textual description of severity"
},
"scenarios": [
{
"lang": "en",
"value": "GENERAL"
}
]
},
{
"cvssV3_1": {
"attackComplexity": "HIGH",
"attackVector": "NETWORK",
"availabilityImpact": "HIGH",
"baseScore": 9,
"baseSeverity": "CRITICAL",
"confidentialityImpact": "HIGH",
"integrityImpact": "HIGH",
"privilegesRequired": "NONE",
"scope": "CHANGED",
"userInteraction": "NONE",
"vectorString": "CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:C/C:H/I:H/A:H",
"version": "3.1"
},
"format": "CVSS",
"scenarios": [
{
"lang": "en",
"value": "GENERAL"
}
]
},
{
"cvssV4_0": {
"Automatable": "NOT_DEFINED",
"Recovery": "NOT_DEFINED",
"Safety": "NOT_DEFINED",
"attackComplexity": "LOW",
"attackRequirements": "PRESENT",
"attackVector": "NETWORK",
"baseScore": 9.4,
"baseSeverity": "CRITICAL",
"exploitMaturity": "NOT_DEFINED",
"privilegesRequired": "NONE",
"providerUrgency": "NOT_DEFINED",
"subAvailabilityImpact": "HIGH",
"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:H",
"version": "4.0",
"vulnAvailabilityImpact": "HIGH",
"vulnConfidentialityImpact": "HIGH",
"vulnIntegrityImpact": "HIGH",
"vulnerabilityResponseEffort": "NOT_DEFINED"
},
"format": "CVSS",
"scenarios": [
{
"lang": "en",
"value": "GENERAL"
}
]
}
],
"problemTypes": [
{
"descriptions": [
{
"cweId": "CWE-306",
"description": "CWE-306 Missing Authentication for Critical Function",
"lang": "en",
"type": "CWE"
}
]
}
],
"providerMetadata": {
"dateUpdated": "2026-10-21T19:17:32.448Z",
"orgId": "f0158376-9dc2-43b6-827c-5f631a4d8d09",
"shortName": "apache"
},
"references": [
{
"tags": [
"vendor-advisory"
],
"url": "https://lists.apache.org/thread/r95dq29ywcd1f4x30snxlqmb12z4s4kc"
}
],
"source": {
"discovery": "UNKNOWN"
},
"title": "Apache Traffic Server: tsmemcache plugin exposes the shared proxy cache over the network with no authentication",
"x_generator": {
"engine": "scripts/cve_render.py"
}
}
},
"cveMetadata": {
"assignerOrgId": "f0158376-9dc2-43b6-827c-5f631a4d8d09",
"assignerShortName": "apache",
"cveId": "CVE-2026-111811",
"datePublished": "2026-10-21T19:17:32.448Z",
"dateReserved": "2026-10-16T20:21:46.648Z",
"dateUpdated": "2026-10-21T19:17:32.448Z",
"state": "PUBLISHED"
},
"dataType": "CVE_RECORD",
"dataVersion": "5.2"
}
CVE-2026-111809 (GCVE-0-2026-111809)
Vulnerability from cvelistv5 – Published: 2026-10-21 19:16 – Updated: 2026-10-21 19:16
VLAI
EPSS
VEX
Title
Apache Traffic Server: HEAD requests carrying Content-Length or Transfer-Encoding enable request smuggling
Summary
Apache Traffic Server allows request smuggling via HEAD requests that carry Content-Length or Transfer-Encoding.
This issue affects Apache Traffic Server: from 8.0.0 through 8.1.11, from 9.0.0 through 9.2.15, from 10.0.0 through 10.1.4, 10.2.0.
Users are recommended to upgrade to version 9.2.16, 10.1.5, or 10.2.1, which fix the issue.
Severity
9.3 (Critical)
CWE
- CWE-444 - Inconsistent Interpretation of HTTP Requests
Assigner
References
1 reference
| URL | Tags |
|---|---|
| https://lists.apache.org/thread/r95dq29ywcd1f4x30… | vendor-advisory |
Impacted products
1 product
| Vendor | Product | Version | |
|---|---|---|---|
| Apache Software Foundation | Apache Traffic Server |
Affected:
8.0.0 , ≤ 8.1.11
(semver)
Affected: 9.0.0 , ≤ 9.2.15 (semver) Affected: 10.0.0 , ≤ 10.1.4 (semver) Affected: 10.2.0 (semver) |
{
"containers": {
"cna": {
"affected": [
{
"defaultStatus": "unaffected",
"product": "Apache Traffic Server",
"vendor": "Apache Software Foundation",
"versions": [
{
"lessThanOrEqual": "8.1.11",
"status": "affected",
"version": "8.0.0",
"versionType": "semver"
},
{
"lessThanOrEqual": "9.2.15",
"status": "affected",
"version": "9.0.0",
"versionType": "semver"
},
{
"lessThanOrEqual": "10.1.4",
"status": "affected",
"version": "10.0.0",
"versionType": "semver"
},
{
"status": "affected",
"version": "10.2.0",
"versionType": "semver"
}
]
}
],
"credits": [
{
"lang": "en",
"type": "reporter",
"value": "Apache Community"
}
],
"descriptions": [
{
"lang": "en",
"supportingMedia": [
{
"base64": false,
"type": "text/html",
"value": "\u003cp\u003eApache Traffic Server allows request smuggling via HEAD requests that carry Content-Length or Transfer-Encoding.\u003c/p\u003e\u003cp\u003eThis issue affects Apache Traffic Server: from 8.0.0 through 8.1.11, from 9.0.0 through 9.2.15, from 10.0.0 through 10.1.4, 10.2.0.\u003c/p\u003e\u003cp\u003eUsers are recommended to upgrade to version 9.2.16, 10.1.5, or 10.2.1, which fix the issue.\u003c/p\u003e"
}
],
"value": "Apache Traffic Server allows request smuggling via HEAD requests that carry Content-Length or Transfer-Encoding.\n\n\n\nThis issue affects Apache Traffic Server: from 8.0.0 through 8.1.11, from 9.0.0 through 9.2.15, from 10.0.0 through 10.1.4, 10.2.0.\n\n\n\nUsers are recommended to upgrade to version 9.2.16, 10.1.5, or 10.2.1, which fix the issue."
}
],
"metrics": [
{
"other": {
"content": {
"text": "moderate"
},
"type": "Textual description of severity"
},
"scenarios": [
{
"lang": "en",
"value": "GENERAL"
}
]
},
{
"cvssV3_1": {
"attackComplexity": "LOW",
"attackVector": "NETWORK",
"availabilityImpact": "NONE",
"baseScore": 9.3,
"baseSeverity": "CRITICAL",
"confidentialityImpact": "LOW",
"integrityImpact": "HIGH",
"privilegesRequired": "NONE",
"scope": "CHANGED",
"userInteraction": "NONE",
"vectorString": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:C/C:L/I:H/A:N",
"version": "3.1"
},
"format": "CVSS",
"scenarios": [
{
"lang": "en",
"value": "GENERAL"
}
]
},
{
"cvssV4_0": {
"Automatable": "NOT_DEFINED",
"Recovery": "NOT_DEFINED",
"Safety": "NOT_DEFINED",
"attackComplexity": "LOW",
"attackRequirements": "PRESENT",
"attackVector": "NETWORK",
"baseScore": 6.9,
"baseSeverity": "MEDIUM",
"exploitMaturity": "NOT_DEFINED",
"privilegesRequired": "NONE",
"providerUrgency": "NOT_DEFINED",
"subAvailabilityImpact": "NONE",
"subConfidentialityImpact": "LOW",
"subIntegrityImpact": "HIGH",
"userInteraction": "NONE",
"valueDensity": "NOT_DEFINED",
"vectorString": "CVSS:4.0/AV:N/AC:L/AT:P/PR:N/UI:N/VC:N/VI:L/VA:N/SC:L/SI:H/SA:N",
"version": "4.0",
"vulnAvailabilityImpact": "NONE",
"vulnConfidentialityImpact": "NONE",
"vulnIntegrityImpact": "LOW",
"vulnerabilityResponseEffort": "NOT_DEFINED"
},
"format": "CVSS",
"scenarios": [
{
"lang": "en",
"value": "GENERAL"
}
]
}
],
"problemTypes": [
{
"descriptions": [
{
"cweId": "CWE-444",
"description": "CWE-444 Inconsistent Interpretation of HTTP Requests",
"lang": "en",
"type": "CWE"
}
]
}
],
"providerMetadata": {
"dateUpdated": "2026-10-21T19:16:16.439Z",
"orgId": "f0158376-9dc2-43b6-827c-5f631a4d8d09",
"shortName": "apache"
},
"references": [
{
"tags": [
"vendor-advisory"
],
"url": "https://lists.apache.org/thread/r95dq29ywcd1f4x30snxlqmb12z4s4kc"
}
],
"source": {
"discovery": "UNKNOWN"
},
"title": "Apache Traffic Server: HEAD requests carrying Content-Length or Transfer-Encoding enable request smuggling",
"x_generator": {
"engine": "scripts/cve_render.py"
}
}
},
"cveMetadata": {
"assignerOrgId": "f0158376-9dc2-43b6-827c-5f631a4d8d09",
"assignerShortName": "apache",
"cveId": "CVE-2026-111809",
"datePublished": "2026-10-21T19:16:16.439Z",
"dateReserved": "2026-10-16T20:20:22.546Z",
"dateUpdated": "2026-10-21T19:16:16.439Z",
"state": "PUBLISHED"
},
"dataType": "CVE_RECORD",
"dataVersion": "5.2"
}
CVE-2026-111810 (GCVE-0-2026-111810)
Vulnerability from cvelistv5 – Published: 2026-10-21 19:14 – Updated: 2026-10-21 19:14
VLAI
EPSS
VEX
Title
Apache Traffic Server: Unthrottled per-header diagnostic logging enables a log-flood denial of service
Summary
Apache Traffic Server 9.2.15, 10.1.4 and 10.2.0 write one unthrottled diagnostic log line for every internal @ header they strip, so a request carrying many such headers makes the proxy write far more log data than the request contains.
This issue affects Apache Traffic Server: 9.2.15, 10.1.4, 10.2.0.
Users are recommended to upgrade to version 9.2.16, 10.1.5, or 10.2.1, which fix the issue.
Severity
CWE
- CWE-400 - Uncontrolled Resource Consumption
Assigner
References
1 reference
| URL | Tags |
|---|---|
| https://lists.apache.org/thread/r95dq29ywcd1f4x30… | vendor-advisory |
Impacted products
1 product
| Vendor | Product | Version | |
|---|---|---|---|
| Apache Software Foundation | Apache Traffic Server |
Affected:
9.2.15
(semver)
Affected: 10.1.4 (semver) Affected: 10.2.0 (semver) |
{
"containers": {
"cna": {
"affected": [
{
"defaultStatus": "unaffected",
"product": "Apache Traffic Server",
"vendor": "Apache Software Foundation",
"versions": [
{
"status": "affected",
"version": "9.2.15",
"versionType": "semver"
},
{
"status": "affected",
"version": "10.1.4",
"versionType": "semver"
},
{
"status": "affected",
"version": "10.2.0",
"versionType": "semver"
}
]
}
],
"credits": [
{
"lang": "en",
"type": "reporter",
"value": "Apache Community"
}
],
"descriptions": [
{
"lang": "en",
"supportingMedia": [
{
"base64": false,
"type": "text/html",
"value": "\u003cp\u003eApache Traffic Server 9.2.15, 10.1.4 and 10.2.0 write one unthrottled diagnostic log line for every internal @ header they strip, so a request carrying many such headers makes the proxy write far more log data than the request contains.\u003c/p\u003e\u003cp\u003eThis issue affects Apache Traffic Server: 9.2.15, 10.1.4, 10.2.0.\u003c/p\u003e\u003cp\u003eUsers are recommended to upgrade to version 9.2.16, 10.1.5, or 10.2.1, which fix the issue.\u003c/p\u003e"
}
],
"value": "Apache Traffic Server 9.2.15, 10.1.4 and 10.2.0 write one unthrottled diagnostic log line for every internal @ header they strip, so a request carrying many such headers makes the proxy write far more log data than the request contains.\n\n\n\nThis issue affects Apache Traffic Server: 9.2.15, 10.1.4, 10.2.0.\n\n\n\nUsers are recommended to upgrade to version 9.2.16, 10.1.5, or 10.2.1, which fix the issue."
}
],
"metrics": [
{
"other": {
"content": {
"text": "important"
},
"type": "Textual description of severity"
},
"scenarios": [
{
"lang": "en",
"value": "GENERAL"
}
]
},
{
"cvssV3_1": {
"attackComplexity": "LOW",
"attackVector": "NETWORK",
"availabilityImpact": "HIGH",
"baseScore": 7.5,
"baseSeverity": "HIGH",
"confidentialityImpact": "NONE",
"integrityImpact": "NONE",
"privilegesRequired": "NONE",
"scope": "UNCHANGED",
"userInteraction": "NONE",
"vectorString": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H",
"version": "3.1"
},
"format": "CVSS",
"scenarios": [
{
"lang": "en",
"value": "GENERAL"
}
]
},
{
"cvssV4_0": {
"Automatable": "NOT_DEFINED",
"Recovery": "NOT_DEFINED",
"Safety": "NOT_DEFINED",
"attackComplexity": "LOW",
"attackRequirements": "NONE",
"attackVector": "NETWORK",
"baseScore": 8.7,
"baseSeverity": "HIGH",
"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:N/PR:N/UI:N/VC:N/VI:N/VA:H/SC:N/SI:N/SA:N",
"version": "4.0",
"vulnAvailabilityImpact": "HIGH",
"vulnConfidentialityImpact": "NONE",
"vulnIntegrityImpact": "NONE",
"vulnerabilityResponseEffort": "NOT_DEFINED"
},
"format": "CVSS",
"scenarios": [
{
"lang": "en",
"value": "GENERAL"
}
]
}
],
"problemTypes": [
{
"descriptions": [
{
"cweId": "CWE-400",
"description": "CWE-400 Uncontrolled Resource Consumption",
"lang": "en",
"type": "CWE"
}
]
}
],
"providerMetadata": {
"dateUpdated": "2026-10-21T19:14:50.479Z",
"orgId": "f0158376-9dc2-43b6-827c-5f631a4d8d09",
"shortName": "apache"
},
"references": [
{
"tags": [
"vendor-advisory"
],
"url": "https://lists.apache.org/thread/r95dq29ywcd1f4x30snxlqmb12z4s4kc"
}
],
"source": {
"discovery": "UNKNOWN"
},
"title": "Apache Traffic Server: Unthrottled per-header diagnostic logging enables a log-flood denial of service",
"x_generator": {
"engine": "scripts/cve_render.py"
}
}
},
"cveMetadata": {
"assignerOrgId": "f0158376-9dc2-43b6-827c-5f631a4d8d09",
"assignerShortName": "apache",
"cveId": "CVE-2026-111810",
"datePublished": "2026-10-21T19:14:50.479Z",
"dateReserved": "2026-10-16T20:21:06.042Z",
"dateUpdated": "2026-10-21T19:14:50.479Z",
"state": "PUBLISHED"
},
"dataType": "CVE_RECORD",
"dataVersion": "5.2"
}
CVE-2026-111815 (GCVE-0-2026-111815)
Vulnerability from cvelistv5 – Published: 2026-10-21 19:13 – Updated: 2026-10-21 19:13
VLAI
EPSS
VEX
Title
Apache Traffic Server: TLS session ticket resumption bypasses per-SNI verify_client STRICT enforcement
Summary
Apache Traffic Server can resume a TLS session across SNI virtual hosts without re-verifying a client certificate required by the resumed host's verify_client STRICT policy.
This issue affects Apache Traffic Server: from 8.0.0 through 8.1.11, from 9.0.0 through 9.2.15, from 10.0.0 through 10.1.4, 10.2.0.
Users are recommended to upgrade to version 9.2.16, 10.1.5, or 10.2.1, which fix the issue.
Severity
CWE
- CWE-295 - Improper Certificate Validation
Assigner
References
1 reference
| URL | Tags |
|---|---|
| https://lists.apache.org/thread/r95dq29ywcd1f4x30… | vendor-advisory |
Impacted products
1 product
| Vendor | Product | Version | |
|---|---|---|---|
| Apache Software Foundation | Apache Traffic Server |
Affected:
8.0.0 , ≤ 8.1.11
(semver)
Affected: 9.0.0 , ≤ 9.2.15 (semver) Affected: 10.0.0 , ≤ 10.1.4 (semver) Affected: 10.2.0 (semver) |
{
"containers": {
"cna": {
"affected": [
{
"defaultStatus": "unaffected",
"product": "Apache Traffic Server",
"vendor": "Apache Software Foundation",
"versions": [
{
"lessThanOrEqual": "8.1.11",
"status": "affected",
"version": "8.0.0",
"versionType": "semver"
},
{
"lessThanOrEqual": "9.2.15",
"status": "affected",
"version": "9.0.0",
"versionType": "semver"
},
{
"lessThanOrEqual": "10.1.4",
"status": "affected",
"version": "10.0.0",
"versionType": "semver"
},
{
"status": "affected",
"version": "10.2.0",
"versionType": "semver"
}
]
}
],
"credits": [
{
"lang": "en",
"type": "reporter",
"value": "Yonghwa Lee, Xint by Theori"
}
],
"descriptions": [
{
"lang": "en",
"supportingMedia": [
{
"base64": false,
"type": "text/html",
"value": "\u003cp\u003eApache Traffic Server can resume a TLS session across SNI virtual hosts without re-verifying a client certificate required by the resumed host\u0027s verify_client STRICT policy.\u003c/p\u003e\u003cp\u003eThis issue affects Apache Traffic Server: from 8.0.0 through 8.1.11, from 9.0.0 through 9.2.15, from 10.0.0 through 10.1.4, 10.2.0.\u003c/p\u003e\u003cp\u003eUsers are recommended to upgrade to version 9.2.16, 10.1.5, or 10.2.1, which fix the issue.\u003c/p\u003e"
}
],
"value": "Apache Traffic Server can resume a TLS session across SNI virtual hosts without re-verifying a client certificate required by the resumed host\u0027s verify_client STRICT policy.\n\n\n\nThis issue affects Apache Traffic Server: from 8.0.0 through 8.1.11, from 9.0.0 through 9.2.15, from 10.0.0 through 10.1.4, 10.2.0.\n\n\n\nUsers are recommended to upgrade to version 9.2.16, 10.1.5, or 10.2.1, which fix the issue."
}
],
"metrics": [
{
"other": {
"content": {
"text": "important"
},
"type": "Textual description of severity"
},
"scenarios": [
{
"lang": "en",
"value": "GENERAL"
}
]
},
{
"cvssV3_1": {
"attackComplexity": "LOW",
"attackVector": "NETWORK",
"availabilityImpact": "NONE",
"baseScore": 10,
"baseSeverity": "CRITICAL",
"confidentialityImpact": "HIGH",
"integrityImpact": "HIGH",
"privilegesRequired": "NONE",
"scope": "CHANGED",
"userInteraction": "NONE",
"vectorString": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:C/C:H/I:H/A:N",
"version": "3.1"
},
"format": "CVSS",
"scenarios": [
{
"lang": "en",
"value": "GENERAL"
}
]
},
{
"cvssV4_0": {
"Automatable": "NOT_DEFINED",
"Recovery": "NOT_DEFINED",
"Safety": "NOT_DEFINED",
"attackComplexity": "LOW",
"attackRequirements": "NONE",
"attackVector": "NETWORK",
"baseScore": 7.8,
"baseSeverity": "HIGH",
"exploitMaturity": "NOT_DEFINED",
"privilegesRequired": "NONE",
"providerUrgency": "NOT_DEFINED",
"subAvailabilityImpact": "NONE",
"subConfidentialityImpact": "HIGH",
"subIntegrityImpact": "HIGH",
"userInteraction": "NONE",
"valueDensity": "NOT_DEFINED",
"vectorString": "CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:N/VI:N/VA:N/SC:H/SI:H/SA:N",
"version": "4.0",
"vulnAvailabilityImpact": "NONE",
"vulnConfidentialityImpact": "NONE",
"vulnIntegrityImpact": "NONE",
"vulnerabilityResponseEffort": "NOT_DEFINED"
},
"format": "CVSS",
"scenarios": [
{
"lang": "en",
"value": "GENERAL"
}
]
}
],
"problemTypes": [
{
"descriptions": [
{
"cweId": "CWE-295",
"description": "CWE-295 Improper Certificate Validation",
"lang": "en",
"type": "CWE"
}
]
}
],
"providerMetadata": {
"dateUpdated": "2026-10-21T19:13:55.811Z",
"orgId": "f0158376-9dc2-43b6-827c-5f631a4d8d09",
"shortName": "apache"
},
"references": [
{
"tags": [
"vendor-advisory"
],
"url": "https://lists.apache.org/thread/r95dq29ywcd1f4x30snxlqmb12z4s4kc"
}
],
"source": {
"discovery": "UNKNOWN"
},
"title": "Apache Traffic Server: TLS session ticket resumption bypasses per-SNI verify_client STRICT enforcement",
"x_generator": {
"engine": "scripts/cve_render.py"
}
}
},
"cveMetadata": {
"assignerOrgId": "f0158376-9dc2-43b6-827c-5f631a4d8d09",
"assignerShortName": "apache",
"cveId": "CVE-2026-111815",
"datePublished": "2026-10-21T19:13:55.811Z",
"dateReserved": "2026-10-16T20:24:32.607Z",
"dateUpdated": "2026-10-21T19:13:55.811Z",
"state": "PUBLISHED"
},
"dataType": "CVE_RECORD",
"dataVersion": "5.2"
}
CVE-2026-111814 (GCVE-0-2026-111814)
Vulnerability from cvelistv5 – Published: 2026-10-21 19:13 – Updated: 2026-10-21 19:13
VLAI
EPSS
VEX
Title
Apache Traffic Server: Default server_session_sharing.match omits MASK_CERT, allowing pooled mTLS identity confusion at the origin
Summary
Apache Traffic Server's default outbound session-sharing policy can reuse a pooled TLS session authenticated with one client certificate for a transaction configured to present a different one.
This issue affects Apache Traffic Server: from 9.0.0 through 9.2.15, from 10.0.0 through 10.1.4, 10.2.0.
Users are recommended to upgrade to version 9.2.16, 10.1.5, or 10.2.1, which fix the issue.
Severity
CWE
- CWE-295 - Improper Certificate Validation
Assigner
References
1 reference
| URL | Tags |
|---|---|
| https://lists.apache.org/thread/r95dq29ywcd1f4x30… | vendor-advisory |
Impacted products
1 product
| Vendor | Product | Version | |
|---|---|---|---|
| Apache Software Foundation | Apache Traffic Server |
Affected:
9.0.0 , ≤ 9.2.15
(semver)
Affected: 10.0.0 , ≤ 10.1.4 (semver) Affected: 10.2.0 (semver) |
{
"containers": {
"cna": {
"affected": [
{
"defaultStatus": "unaffected",
"product": "Apache Traffic Server",
"vendor": "Apache Software Foundation",
"versions": [
{
"lessThanOrEqual": "9.2.15",
"status": "affected",
"version": "9.0.0",
"versionType": "semver"
},
{
"lessThanOrEqual": "10.1.4",
"status": "affected",
"version": "10.0.0",
"versionType": "semver"
},
{
"status": "affected",
"version": "10.2.0",
"versionType": "semver"
}
]
}
],
"credits": [
{
"lang": "en",
"type": "reporter",
"value": "Craig Taylor"
}
],
"descriptions": [
{
"lang": "en",
"supportingMedia": [
{
"base64": false,
"type": "text/html",
"value": "\u003cp\u003eApache Traffic Server\u0027s default outbound session-sharing policy can reuse a pooled TLS session authenticated with one client certificate for a transaction configured to present a different one.\u003c/p\u003e\u003cp\u003eThis issue affects Apache Traffic Server: from 9.0.0 through 9.2.15, from 10.0.0 through 10.1.4, 10.2.0.\u003c/p\u003e\u003cp\u003eUsers are recommended to upgrade to version 9.2.16, 10.1.5, or 10.2.1, which fix the issue.\u003c/p\u003e"
}
],
"value": "Apache Traffic Server\u0027s default outbound session-sharing policy can reuse a pooled TLS session authenticated with one client certificate for a transaction configured to present a different one.\n\n\n\nThis issue affects Apache Traffic Server: from 9.0.0 through 9.2.15, from 10.0.0 through 10.1.4, 10.2.0.\n\n\n\nUsers are recommended to upgrade to version 9.2.16, 10.1.5, or 10.2.1, which fix the issue."
}
],
"metrics": [
{
"other": {
"content": {
"text": "important"
},
"type": "Textual description of severity"
},
"scenarios": [
{
"lang": "en",
"value": "GENERAL"
}
]
},
{
"cvssV3_1": {
"attackComplexity": "LOW",
"attackVector": "NETWORK",
"availabilityImpact": "NONE",
"baseScore": 10,
"baseSeverity": "CRITICAL",
"confidentialityImpact": "HIGH",
"integrityImpact": "HIGH",
"privilegesRequired": "NONE",
"scope": "CHANGED",
"userInteraction": "NONE",
"vectorString": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:C/C:H/I:H/A:N",
"version": "3.1"
},
"format": "CVSS",
"scenarios": [
{
"lang": "en",
"value": "GENERAL"
}
]
},
{
"cvssV4_0": {
"Automatable": "NOT_DEFINED",
"Recovery": "NOT_DEFINED",
"Safety": "NOT_DEFINED",
"attackComplexity": "LOW",
"attackRequirements": "NONE",
"attackVector": "NETWORK",
"baseScore": 7.8,
"baseSeverity": "HIGH",
"exploitMaturity": "NOT_DEFINED",
"privilegesRequired": "NONE",
"providerUrgency": "NOT_DEFINED",
"subAvailabilityImpact": "NONE",
"subConfidentialityImpact": "HIGH",
"subIntegrityImpact": "HIGH",
"userInteraction": "NONE",
"valueDensity": "NOT_DEFINED",
"vectorString": "CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:N/VI:L/VA:N/SC:H/SI:H/SA:N",
"version": "4.0",
"vulnAvailabilityImpact": "NONE",
"vulnConfidentialityImpact": "NONE",
"vulnIntegrityImpact": "LOW",
"vulnerabilityResponseEffort": "NOT_DEFINED"
},
"format": "CVSS",
"scenarios": [
{
"lang": "en",
"value": "GENERAL"
}
]
}
],
"problemTypes": [
{
"descriptions": [
{
"cweId": "CWE-295",
"description": "CWE-295 Improper Certificate Validation",
"lang": "en",
"type": "CWE"
}
]
}
],
"providerMetadata": {
"dateUpdated": "2026-10-21T19:13:06.888Z",
"orgId": "f0158376-9dc2-43b6-827c-5f631a4d8d09",
"shortName": "apache"
},
"references": [
{
"tags": [
"vendor-advisory"
],
"url": "https://lists.apache.org/thread/r95dq29ywcd1f4x30snxlqmb12z4s4kc"
}
],
"source": {
"discovery": "UNKNOWN"
},
"title": "Apache Traffic Server: Default server_session_sharing.match omits MASK_CERT, allowing pooled mTLS identity confusion at the origin",
"x_generator": {
"engine": "scripts/cve_render.py"
}
}
},
"cveMetadata": {
"assignerOrgId": "f0158376-9dc2-43b6-827c-5f631a4d8d09",
"assignerShortName": "apache",
"cveId": "CVE-2026-111814",
"datePublished": "2026-10-21T19:13:06.888Z",
"dateReserved": "2026-10-16T20:23:50.515Z",
"dateUpdated": "2026-10-21T19:13:06.888Z",
"state": "PUBLISHED"
},
"dataType": "CVE_RECORD",
"dataVersion": "5.2"
}
CVE-2026-111808 (GCVE-0-2026-111808)
Vulnerability from cvelistv5 – Published: 2026-10-21 19:11 – Updated: 2026-10-21 19:11
VLAI
EPSS
VEX
Title
Apache Traffic Server: HTTP/2 DATA frame padding underflow lets a client trigger backend worker-pool exhaustion
Summary
Apache Traffic Server can be used to exhaust an HTTP/1.1 origin's worker pool via a malformed padded HTTP/2 DATA frame.
This issue affects Apache Traffic Server: from 8.0.0 through 8.1.11, from 9.0.0 through 9.2.15, from 10.0.0 through 10.1.4, 10.2.0.
Users are recommended to upgrade to version 9.2.16, 10.1.5, or 10.2.1, which fix the issue.
Severity
CWE
- CWE-191 - Integer Underflow (Wrap or Wraparound)
Assigner
References
1 reference
| URL | Tags |
|---|---|
| https://lists.apache.org/thread/r95dq29ywcd1f4x30… | vendor-advisory |
Impacted products
1 product
| Vendor | Product | Version | |
|---|---|---|---|
| Apache Software Foundation | Apache Traffic Server |
Affected:
8.0.0 , ≤ 8.1.11
(semver)
Affected: 9.0.0 , ≤ 9.2.15 (semver) Affected: 10.0.0 , ≤ 10.1.4 (semver) Affected: 10.2.0 (semver) |
{
"containers": {
"cna": {
"affected": [
{
"defaultStatus": "unaffected",
"product": "Apache Traffic Server",
"vendor": "Apache Software Foundation",
"versions": [
{
"lessThanOrEqual": "8.1.11",
"status": "affected",
"version": "8.0.0",
"versionType": "semver"
},
{
"lessThanOrEqual": "9.2.15",
"status": "affected",
"version": "9.0.0",
"versionType": "semver"
},
{
"lessThanOrEqual": "10.1.4",
"status": "affected",
"version": "10.0.0",
"versionType": "semver"
},
{
"status": "affected",
"version": "10.2.0",
"versionType": "semver"
}
]
}
],
"credits": [
{
"lang": "en",
"type": "reporter",
"value": "Khalilov Moe (LeetProtect)"
},
{
"lang": "en",
"type": "reporter",
"value": "The ASF"
}
],
"descriptions": [
{
"lang": "en",
"supportingMedia": [
{
"base64": false,
"type": "text/html",
"value": "\u003cp\u003eApache Traffic Server can be used to exhaust an HTTP/1.1 origin\u0027s worker pool via a malformed padded HTTP/2 DATA frame.\u003c/p\u003e\u003cp\u003eThis issue affects Apache Traffic Server: from 8.0.0 through 8.1.11, from 9.0.0 through 9.2.15, from 10.0.0 through 10.1.4, 10.2.0.\u003c/p\u003e\u003cp\u003eUsers are recommended to upgrade to version 9.2.16, 10.1.5, or 10.2.1, which fix the issue.\u003c/p\u003e"
}
],
"value": "Apache Traffic Server can be used to exhaust an HTTP/1.1 origin\u0027s worker pool via a malformed padded HTTP/2 DATA frame.\n\n\n\nThis issue affects Apache Traffic Server: from 8.0.0 through 8.1.11, from 9.0.0 through 9.2.15, from 10.0.0 through 10.1.4, 10.2.0.\n\n\n\nUsers are recommended to upgrade to version 9.2.16, 10.1.5, or 10.2.1, which fix the issue."
}
],
"metrics": [
{
"other": {
"content": {
"text": "important"
},
"type": "Textual description of severity"
},
"scenarios": [
{
"lang": "en",
"value": "GENERAL"
}
]
},
{
"cvssV3_1": {
"attackComplexity": "LOW",
"attackVector": "NETWORK",
"availabilityImpact": "HIGH",
"baseScore": 8.6,
"baseSeverity": "HIGH",
"confidentialityImpact": "NONE",
"integrityImpact": "NONE",
"privilegesRequired": "NONE",
"scope": "CHANGED",
"userInteraction": "NONE",
"vectorString": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:C/C:N/I:N/A:H",
"version": "3.1"
},
"format": "CVSS",
"scenarios": [
{
"lang": "en",
"value": "GENERAL"
}
]
},
{
"cvssV4_0": {
"Automatable": "NOT_DEFINED",
"Recovery": "NOT_DEFINED",
"Safety": "NOT_DEFINED",
"attackComplexity": "LOW",
"attackRequirements": "NONE",
"attackVector": "NETWORK",
"baseScore": 7.7,
"baseSeverity": "HIGH",
"exploitMaturity": "NOT_DEFINED",
"privilegesRequired": "NONE",
"providerUrgency": "NOT_DEFINED",
"subAvailabilityImpact": "HIGH",
"subConfidentialityImpact": "NONE",
"subIntegrityImpact": "NONE",
"userInteraction": "NONE",
"valueDensity": "NOT_DEFINED",
"vectorString": "CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:N/VI:N/VA:N/SC:N/SI:N/SA:H",
"version": "4.0",
"vulnAvailabilityImpact": "NONE",
"vulnConfidentialityImpact": "NONE",
"vulnIntegrityImpact": "NONE",
"vulnerabilityResponseEffort": "NOT_DEFINED"
},
"format": "CVSS",
"scenarios": [
{
"lang": "en",
"value": "GENERAL"
}
]
}
],
"problemTypes": [
{
"descriptions": [
{
"cweId": "CWE-191",
"description": "CWE-191 Integer Underflow (Wrap or Wraparound)",
"lang": "en",
"type": "CWE"
}
]
}
],
"providerMetadata": {
"dateUpdated": "2026-10-21T19:11:59.516Z",
"orgId": "f0158376-9dc2-43b6-827c-5f631a4d8d09",
"shortName": "apache"
},
"references": [
{
"tags": [
"vendor-advisory"
],
"url": "https://lists.apache.org/thread/r95dq29ywcd1f4x30snxlqmb12z4s4kc"
}
],
"source": {
"discovery": "UNKNOWN"
},
"title": "Apache Traffic Server: HTTP/2 DATA frame padding underflow lets a client trigger backend worker-pool exhaustion",
"x_generator": {
"engine": "scripts/cve_render.py"
}
}
},
"cveMetadata": {
"assignerOrgId": "f0158376-9dc2-43b6-827c-5f631a4d8d09",
"assignerShortName": "apache",
"cveId": "CVE-2026-111808",
"datePublished": "2026-10-21T19:11:59.516Z",
"dateReserved": "2026-10-16T20:19:38.638Z",
"dateUpdated": "2026-10-21T19:11:59.516Z",
"state": "PUBLISHED"
},
"dataType": "CVE_RECORD",
"dataVersion": "5.2"
}
CVE-2026-111805 (GCVE-0-2026-111805)
Vulnerability from cvelistv5 – Published: 2026-10-21 19:10 – Updated: 2026-10-21 19:10
VLAI
EPSS
VEX
Title
Apache Traffic Server: HTTP/2 Content-Length truncation lets a client trigger backend worker-pool exhaustion
Summary
Apache Traffic Server can be used to exhaust an HTTP/1.1 origin's worker pool via a truncated HTTP/2 Content-Length value.
This issue affects Apache Traffic Server: from 8.0.0 through 8.1.11, from 9.0.0 through 9.2.15, from 10.0.0 through 10.1.4, 10.2.0.
Users are recommended to upgrade to version 9.2.16, 10.1.5, or 10.2.1, which fix the issue.
Severity
CWE
- CWE-400 - Uncontrolled Resource Consumption
Assigner
References
1 reference
| URL | Tags |
|---|---|
| https://lists.apache.org/thread/r95dq29ywcd1f4x30… | vendor-advisory |
Impacted products
1 product
| Vendor | Product | Version | |
|---|---|---|---|
| Apache Software Foundation | Apache Traffic Server |
Affected:
8.0.0 , ≤ 8.1.11
(semver)
Affected: 9.0.0 , ≤ 9.2.15 (semver) Affected: 10.0.0 , ≤ 10.1.4 (semver) Affected: 10.2.0 (semver) |
{
"containers": {
"cna": {
"affected": [
{
"defaultStatus": "unaffected",
"product": "Apache Traffic Server",
"vendor": "Apache Software Foundation",
"versions": [
{
"lessThanOrEqual": "8.1.11",
"status": "affected",
"version": "8.0.0",
"versionType": "semver"
},
{
"lessThanOrEqual": "9.2.15",
"status": "affected",
"version": "9.0.0",
"versionType": "semver"
},
{
"lessThanOrEqual": "10.1.4",
"status": "affected",
"version": "10.0.0",
"versionType": "semver"
},
{
"status": "affected",
"version": "10.2.0",
"versionType": "semver"
}
]
}
],
"credits": [
{
"lang": "en",
"type": "reporter",
"value": "matrix_cain (YakLang)"
},
{
"lang": "en",
"type": "reporter",
"value": "Alieldeen Khaled Ali"
},
{
"lang": "en",
"type": "reporter",
"value": "Jesse Yang"
},
{
"lang": "en",
"type": "reporter",
"value": "Alex Williams (Pellera Technologies)"
},
{
"lang": "en",
"type": "coordinator",
"value": "VulnCheck"
},
{
"lang": "en",
"type": "reporter",
"value": "The ASF"
}
],
"descriptions": [
{
"lang": "en",
"supportingMedia": [
{
"base64": false,
"type": "text/html",
"value": "\u003cp\u003eApache Traffic Server can be used to exhaust an HTTP/1.1 origin\u0027s worker pool via a truncated HTTP/2 Content-Length value.\u003c/p\u003e\u003cp\u003eThis issue affects Apache Traffic Server: from 8.0.0 through 8.1.11, from 9.0.0 through 9.2.15, from 10.0.0 through 10.1.4, 10.2.0.\u003c/p\u003e\u003cp\u003eUsers are recommended to upgrade to version 9.2.16, 10.1.5, or 10.2.1, which fix the issue.\u003c/p\u003e"
}
],
"value": "Apache Traffic Server can be used to exhaust an HTTP/1.1 origin\u0027s worker pool via a truncated HTTP/2 Content-Length value.\n\n\n\nThis issue affects Apache Traffic Server: from 8.0.0 through 8.1.11, from 9.0.0 through 9.2.15, from 10.0.0 through 10.1.4, 10.2.0.\n\n\n\nUsers are recommended to upgrade to version 9.2.16, 10.1.5, or 10.2.1, which fix the issue."
}
],
"metrics": [
{
"other": {
"content": {
"text": "important"
},
"type": "Textual description of severity"
},
"scenarios": [
{
"lang": "en",
"value": "GENERAL"
}
]
},
{
"cvssV3_1": {
"attackComplexity": "LOW",
"attackVector": "NETWORK",
"availabilityImpact": "HIGH",
"baseScore": 8.6,
"baseSeverity": "HIGH",
"confidentialityImpact": "NONE",
"integrityImpact": "NONE",
"privilegesRequired": "NONE",
"scope": "CHANGED",
"userInteraction": "NONE",
"vectorString": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:C/C:N/I:N/A:H",
"version": "3.1"
},
"format": "CVSS",
"scenarios": [
{
"lang": "en",
"value": "GENERAL"
}
]
},
{
"cvssV4_0": {
"Automatable": "NOT_DEFINED",
"Recovery": "NOT_DEFINED",
"Safety": "NOT_DEFINED",
"attackComplexity": "LOW",
"attackRequirements": "NONE",
"attackVector": "NETWORK",
"baseScore": 7.7,
"baseSeverity": "HIGH",
"exploitMaturity": "NOT_DEFINED",
"privilegesRequired": "NONE",
"providerUrgency": "NOT_DEFINED",
"subAvailabilityImpact": "HIGH",
"subConfidentialityImpact": "NONE",
"subIntegrityImpact": "NONE",
"userInteraction": "NONE",
"valueDensity": "NOT_DEFINED",
"vectorString": "CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:N/VI:N/VA:N/SC:N/SI:N/SA:H",
"version": "4.0",
"vulnAvailabilityImpact": "NONE",
"vulnConfidentialityImpact": "NONE",
"vulnIntegrityImpact": "NONE",
"vulnerabilityResponseEffort": "NOT_DEFINED"
},
"format": "CVSS",
"scenarios": [
{
"lang": "en",
"value": "GENERAL"
}
]
}
],
"problemTypes": [
{
"descriptions": [
{
"cweId": "CWE-400",
"description": "CWE-400 Uncontrolled Resource Consumption",
"lang": "en",
"type": "CWE"
}
]
}
],
"providerMetadata": {
"dateUpdated": "2026-10-21T19:10:46.319Z",
"orgId": "f0158376-9dc2-43b6-827c-5f631a4d8d09",
"shortName": "apache"
},
"references": [
{
"tags": [
"vendor-advisory"
],
"url": "https://lists.apache.org/thread/r95dq29ywcd1f4x30snxlqmb12z4s4kc"
}
],
"source": {
"discovery": "UNKNOWN"
},
"title": "Apache Traffic Server: HTTP/2 Content-Length truncation lets a client trigger backend worker-pool exhaustion",
"x_generator": {
"engine": "scripts/cve_render.py"
}
}
},
"cveMetadata": {
"assignerOrgId": "f0158376-9dc2-43b6-827c-5f631a4d8d09",
"assignerShortName": "apache",
"cveId": "CVE-2026-111805",
"datePublished": "2026-10-21T19:10:46.319Z",
"dateReserved": "2026-10-16T20:16:14.017Z",
"dateUpdated": "2026-10-21T19:10:46.319Z",
"state": "PUBLISHED"
},
"dataType": "CVE_RECORD",
"dataVersion": "5.2"
}
CVE-2026-111816 (GCVE-0-2026-111816)
Vulnerability from cvelistv5 – Published: 2026-10-21 18:26 – Updated: 2026-10-21 18:26
VLAI
EPSS
VEX
Title
Apache Traffic Server: A malformed 302 response bypasses parse-error rejection through the Transfer-Encoding: chunked carve-out
Summary
Apache Traffic Server forwarded a malformed 302 response that should have been rejected as a parse error, because the Transfer-Encoding: chunked carve-out bypassed the rejection path. A response that two peers can read differently is then stored and served, allowing cache poisoning and response-framing desync.
This issue affects Apache Traffic Server: from 8.0.0 through 8.1.11, from 9.0.0 through 9.2.15, from 10.0.0 through 10.1.4, 10.2.0.
Users are recommended to upgrade to version 9.2.16, 10.1.5, or 10.2.1, which fix the issue.
Severity
9.3 (Critical)
CWE
- CWE-444 - Inconsistent Interpretation of HTTP Requests
Assigner
References
1 reference
| URL | Tags |
|---|---|
| https://lists.apache.org/thread/r95dq29ywcd1f4x30… | vendor-advisory |
Impacted products
1 product
| Vendor | Product | Version | |
|---|---|---|---|
| Apache Software Foundation | Apache Traffic Server |
Affected:
8.0.0 , ≤ 8.1.11
(semver)
Affected: 9.0.0 , ≤ 9.2.15 (semver) Affected: 10.0.0 , ≤ 10.1.4 (semver) Affected: 10.2.0 (semver) |
{
"containers": {
"cna": {
"affected": [
{
"defaultStatus": "unaffected",
"product": "Apache Traffic Server",
"vendor": "Apache Software Foundation",
"versions": [
{
"lessThanOrEqual": "8.1.11",
"status": "affected",
"version": "8.0.0",
"versionType": "semver"
},
{
"lessThanOrEqual": "9.2.15",
"status": "affected",
"version": "9.0.0",
"versionType": "semver"
},
{
"lessThanOrEqual": "10.1.4",
"status": "affected",
"version": "10.0.0",
"versionType": "semver"
},
{
"status": "affected",
"version": "10.2.0",
"versionType": "semver"
}
]
}
],
"credits": [
{
"lang": "en",
"type": "reporter",
"value": "Apache Community"
},
{
"lang": "en",
"type": "reporter",
"value": "OneZ3r0"
}
],
"descriptions": [
{
"lang": "en",
"supportingMedia": [
{
"base64": false,
"type": "text/html",
"value": "\u003cp\u003eApache Traffic Server forwarded a malformed 302 response that should have been rejected as a parse error, because the Transfer-Encoding: chunked carve-out bypassed the rejection path. A response that two peers can read differently is then stored and served, allowing cache poisoning and response-framing desync.\u003c/p\u003e\u003cp\u003eThis issue affects Apache Traffic Server: from 8.0.0 through 8.1.11, from 9.0.0 through 9.2.15, from 10.0.0 through 10.1.4, 10.2.0.\u003c/p\u003e\u003cp\u003eUsers are recommended to upgrade to version 9.2.16, 10.1.5, or 10.2.1, which fix the issue.\u003c/p\u003e"
}
],
"value": "Apache Traffic Server forwarded a malformed 302 response that should have been rejected as a parse error, because the Transfer-Encoding: chunked carve-out bypassed the rejection path. A response that two peers can read differently is then stored and served, allowing cache poisoning and response-framing desync.\n\n\n\nThis issue affects Apache Traffic Server: from 8.0.0 through 8.1.11, from 9.0.0 through 9.2.15, from 10.0.0 through 10.1.4, 10.2.0.\n\n\n\nUsers are recommended to upgrade to version 9.2.16, 10.1.5, or 10.2.1, which fix the issue."
}
],
"metrics": [
{
"other": {
"content": {
"text": "important"
},
"type": "Textual description of severity"
},
"scenarios": [
{
"lang": "en",
"value": "GENERAL"
}
]
},
{
"cvssV3_1": {
"attackComplexity": "LOW",
"attackVector": "NETWORK",
"availabilityImpact": "NONE",
"baseScore": 9.3,
"baseSeverity": "CRITICAL",
"confidentialityImpact": "LOW",
"integrityImpact": "HIGH",
"privilegesRequired": "NONE",
"scope": "CHANGED",
"userInteraction": "NONE",
"vectorString": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:C/C:L/I:H/A:N",
"version": "3.1"
},
"format": "CVSS",
"scenarios": [
{
"lang": "en",
"value": "GENERAL"
}
]
},
{
"cvssV4_0": {
"Automatable": "NOT_DEFINED",
"Recovery": "NOT_DEFINED",
"Safety": "NOT_DEFINED",
"attackComplexity": "LOW",
"attackRequirements": "NONE",
"attackVector": "NETWORK",
"baseScore": 9.2,
"baseSeverity": "CRITICAL",
"exploitMaturity": "NOT_DEFINED",
"privilegesRequired": "NONE",
"providerUrgency": "NOT_DEFINED",
"subAvailabilityImpact": "NONE",
"subConfidentialityImpact": "LOW",
"subIntegrityImpact": "HIGH",
"userInteraction": "NONE",
"valueDensity": "NOT_DEFINED",
"vectorString": "CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:N/VI:H/VA:N/SC:L/SI:H/SA:N",
"version": "4.0",
"vulnAvailabilityImpact": "NONE",
"vulnConfidentialityImpact": "NONE",
"vulnIntegrityImpact": "HIGH",
"vulnerabilityResponseEffort": "NOT_DEFINED"
},
"format": "CVSS",
"scenarios": [
{
"lang": "en",
"value": "GENERAL"
}
]
}
],
"problemTypes": [
{
"descriptions": [
{
"cweId": "CWE-444",
"description": "CWE-444 Inconsistent Interpretation of HTTP Requests",
"lang": "en",
"type": "CWE"
}
]
}
],
"providerMetadata": {
"dateUpdated": "2026-10-21T18:26:32.566Z",
"orgId": "f0158376-9dc2-43b6-827c-5f631a4d8d09",
"shortName": "apache"
},
"references": [
{
"tags": [
"vendor-advisory"
],
"url": "https://lists.apache.org/thread/r95dq29ywcd1f4x30snxlqmb12z4s4kc"
}
],
"source": {
"discovery": "UNKNOWN"
},
"title": "Apache Traffic Server: A malformed 302 response bypasses parse-error rejection through the Transfer-Encoding: chunked carve-out",
"x_generator": {
"engine": "scripts/cve_render.py"
}
}
},
"cveMetadata": {
"assignerOrgId": "f0158376-9dc2-43b6-827c-5f631a4d8d09",
"assignerShortName": "apache",
"cveId": "CVE-2026-111816",
"datePublished": "2026-10-21T18:26:32.566Z",
"dateReserved": "2026-10-16T20:25:17.923Z",
"dateUpdated": "2026-10-21T18:26:32.566Z",
"state": "PUBLISHED"
},
"dataType": "CVE_RECORD",
"dataVersion": "5.2"
}
CVE-2025-55702 (GCVE-0-2025-55702)
Vulnerability from cvelistv5 – Published: 2026-10-21 18:24 – Updated: 2026-10-21 18:24
VLAI
EPSS
VEX
Title
Apache Traffic Server: An unread Expect: 100-continue request body is framed as a new request
Summary
When a client sends a POST with Expect: 100-continue and the origin answers before reading the body, Apache Traffic Server parses the unread body left on the client connection as the next request. An attacker behind a front-end proxy that shares connections to Traffic Server can use this to smuggle requests past the front end and desynchronize responses for other users.
This issue affects Apache Traffic Server: from 8.0.0 through 8.1.11, from 9.0.0 through 9.2.15, from 10.0.0 through 10.1.4, 10.2.0.
Users are recommended to upgrade to version 9.2.16, 10.1.5, or 10.2.1, which fix the issue.
Severity
CWE
- CWE-444 - Inconsistent Interpretation of HTTP Requests
Assigner
References
1 reference
| URL | Tags |
|---|---|
| https://lists.apache.org/thread/r95dq29ywcd1f4x30… | vendor-advisory |
Impacted products
1 product
| Vendor | Product | Version | |
|---|---|---|---|
| Apache Software Foundation | Apache Traffic Server |
Affected:
8.0.0 , ≤ 8.1.11
(semver)
Affected: 9.0.0 , ≤ 9.2.15 (semver) Affected: 10.0.0 , ≤ 10.1.4 (semver) Affected: 10.2.0 (semver) |
{
"containers": {
"cna": {
"affected": [
{
"defaultStatus": "unaffected",
"product": "Apache Traffic Server",
"vendor": "Apache Software Foundation",
"versions": [
{
"lessThanOrEqual": "8.1.11",
"status": "affected",
"version": "8.0.0",
"versionType": "semver"
},
{
"lessThanOrEqual": "9.2.15",
"status": "affected",
"version": "9.0.0",
"versionType": "semver"
},
{
"lessThanOrEqual": "10.1.4",
"status": "affected",
"version": "10.0.0",
"versionType": "semver"
},
{
"status": "affected",
"version": "10.2.0",
"versionType": "semver"
}
]
}
],
"credits": [
{
"lang": "en",
"type": "reporter",
"value": "Sebastiano Sartor"
}
],
"descriptions": [
{
"lang": "en",
"supportingMedia": [
{
"base64": false,
"type": "text/html",
"value": "\u003cp\u003eWhen a client sends a POST with Expect: 100-continue and the origin answers before reading the body, Apache Traffic Server parses the unread body left on the client connection as the next request. An attacker behind a front-end proxy that shares connections to Traffic Server can use this to smuggle requests past the front end and desynchronize responses for other users.\u003c/p\u003e\u003cp\u003eThis issue affects Apache Traffic Server: from 8.0.0 through 8.1.11, from 9.0.0 through 9.2.15, from 10.0.0 through 10.1.4, 10.2.0.\u003c/p\u003e\u003cp\u003eUsers are recommended to upgrade to version 9.2.16, 10.1.5, or 10.2.1, which fix the issue.\u003c/p\u003e"
}
],
"value": "When a client sends a POST with Expect: 100-continue and the origin answers before reading the body, Apache Traffic Server parses the unread body left on the client connection as the next request. An attacker behind a front-end proxy that shares connections to Traffic Server can use this to smuggle requests past the front end and desynchronize responses for other users.\n\n\n\nThis issue affects Apache Traffic Server: from 8.0.0 through 8.1.11, from 9.0.0 through 9.2.15, from 10.0.0 through 10.1.4, 10.2.0.\n\n\n\nUsers are recommended to upgrade to version 9.2.16, 10.1.5, or 10.2.1, which fix the issue."
}
],
"metrics": [
{
"other": {
"content": {
"text": "important"
},
"type": "Textual description of severity"
},
"scenarios": [
{
"lang": "en",
"value": "GENERAL"
}
]
},
{
"cvssV3_1": {
"attackComplexity": "HIGH",
"attackVector": "NETWORK",
"availabilityImpact": "NONE",
"baseScore": 8.7,
"baseSeverity": "HIGH",
"confidentialityImpact": "HIGH",
"integrityImpact": "HIGH",
"privilegesRequired": "NONE",
"scope": "CHANGED",
"userInteraction": "NONE",
"vectorString": "CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:C/C:H/I:H/A:N",
"version": "3.1"
},
"format": "CVSS",
"scenarios": [
{
"lang": "en",
"value": "GENERAL"
}
]
},
{
"cvssV4_0": {
"Automatable": "NOT_DEFINED",
"Recovery": "NOT_DEFINED",
"Safety": "NOT_DEFINED",
"attackComplexity": "LOW",
"attackRequirements": "PRESENT",
"attackVector": "NETWORK",
"baseScore": 7,
"baseSeverity": "HIGH",
"exploitMaturity": "NOT_DEFINED",
"privilegesRequired": "NONE",
"providerUrgency": "NOT_DEFINED",
"subAvailabilityImpact": "NONE",
"subConfidentialityImpact": "HIGH",
"subIntegrityImpact": "HIGH",
"userInteraction": "NONE",
"valueDensity": "NOT_DEFINED",
"vectorString": "CVSS:4.0/AV:N/AC:L/AT:P/PR:N/UI:N/VC:N/VI:N/VA:N/SC:H/SI:H/SA:N",
"version": "4.0",
"vulnAvailabilityImpact": "NONE",
"vulnConfidentialityImpact": "NONE",
"vulnIntegrityImpact": "NONE",
"vulnerabilityResponseEffort": "NOT_DEFINED"
},
"format": "CVSS",
"scenarios": [
{
"lang": "en",
"value": "GENERAL"
}
]
}
],
"problemTypes": [
{
"descriptions": [
{
"cweId": "CWE-444",
"description": "CWE-444 Inconsistent Interpretation of HTTP Requests",
"lang": "en",
"type": "CWE"
}
]
}
],
"providerMetadata": {
"dateUpdated": "2026-10-21T18:24:21.377Z",
"orgId": "f0158376-9dc2-43b6-827c-5f631a4d8d09",
"shortName": "apache"
},
"references": [
{
"tags": [
"vendor-advisory"
],
"url": "https://lists.apache.org/thread/r95dq29ywcd1f4x30snxlqmb12z4s4kc"
}
],
"source": {
"discovery": "UNKNOWN"
},
"title": "Apache Traffic Server: An unread Expect: 100-continue request body is framed as a new request",
"x_generator": {
"engine": "scripts/cve_render.py"
}
}
},
"cveMetadata": {
"assignerOrgId": "f0158376-9dc2-43b6-827c-5f631a4d8d09",
"assignerShortName": "apache",
"cveId": "CVE-2025-55702",
"datePublished": "2026-10-21T18:24:21.377Z",
"dateReserved": "2025-08-13T22:27:49.065Z",
"dateUpdated": "2026-10-21T18:24:21.377Z",
"state": "PUBLISHED"
},
"dataType": "CVE_RECORD",
"dataVersion": "5.2"
}
CVE-2025-31699 (GCVE-0-2025-31699)
Vulnerability from cvelistv5 – Published: 2026-10-21 18:22 – Updated: 2026-10-21 18:22
VLAI
EPSS
VEX
Title
Apache Traffic Server: Origin connection still owed a request body is reused, enabling request smuggling
Summary
Apache Traffic Server can return an origin connection to the shared pool while the origin is still waiting on a request body the client declared but never fully sent, including when the client used Expect: 100-continue. The origin then reads a later request on that connection as leftover body data, which lets an attacker smuggle requests past ATS access controls, disrupt other users' requests, or poison the cache.
This issue affects Apache Traffic Server: from 8.0.0 through 8.1.11, from 9.0.0 through 9.2.15, from 10.0.0 through 10.1.4, 10.2.0.
Users are recommended to upgrade to version 9.2.16, 10.1.5, or 10.2.1, which fix the issue.
Severity
8.9 (High)
CWE
- CWE-444 - Inconsistent Interpretation of HTTP Requests
Assigner
References
1 reference
| URL | Tags |
|---|---|
| https://lists.apache.org/thread/r95dq29ywcd1f4x30… | vendor-advisory |
Impacted products
1 product
| Vendor | Product | Version | |
|---|---|---|---|
| Apache Software Foundation | Apache Traffic Server |
Affected:
8.0.0 , ≤ 8.1.11
(semver)
Affected: 9.0.0 , ≤ 9.2.15 (semver) Affected: 10.0.0 , ≤ 10.1.4 (semver) Affected: 10.2.0 (semver) |
{
"containers": {
"cna": {
"affected": [
{
"defaultStatus": "unaffected",
"product": "Apache Traffic Server",
"vendor": "Apache Software Foundation",
"versions": [
{
"lessThanOrEqual": "8.1.11",
"status": "affected",
"version": "8.0.0",
"versionType": "semver"
},
{
"lessThanOrEqual": "9.2.15",
"status": "affected",
"version": "9.0.0",
"versionType": "semver"
},
{
"lessThanOrEqual": "10.1.4",
"status": "affected",
"version": "10.0.0",
"versionType": "semver"
},
{
"status": "affected",
"version": "10.2.0",
"versionType": "semver"
}
]
}
],
"credits": [
{
"lang": "en",
"type": "reporter",
"value": "Martin van Kervel Smedshammer"
},
{
"lang": "en",
"type": "reporter",
"value": "Nick Muerdter"
}
],
"descriptions": [
{
"lang": "en",
"supportingMedia": [
{
"base64": false,
"type": "text/html",
"value": "\u003cp\u003eApache Traffic Server can return an origin connection to the shared pool while the origin is still waiting on a request body the client declared but never fully sent, including when the client used Expect: 100-continue. The origin then reads a later request on that connection as leftover body data, which lets an attacker smuggle requests past ATS access controls, disrupt other users\u0027 requests, or poison the cache.\u003c/p\u003e\u003cp\u003eThis issue affects Apache Traffic Server: from 8.0.0 through 8.1.11, from 9.0.0 through 9.2.15, from 10.0.0 through 10.1.4, 10.2.0.\u003c/p\u003e\u003cp\u003eUsers are recommended to upgrade to version 9.2.16, 10.1.5, or 10.2.1, which fix the issue.\u003c/p\u003e"
}
],
"value": "Apache Traffic Server can return an origin connection to the shared pool while the origin is still waiting on a request body the client declared but never fully sent, including when the client used Expect: 100-continue. The origin then reads a later request on that connection as leftover body data, which lets an attacker smuggle requests past ATS access controls, disrupt other users\u0027 requests, or poison the cache.\n\n\n\nThis issue affects Apache Traffic Server: from 8.0.0 through 8.1.11, from 9.0.0 through 9.2.15, from 10.0.0 through 10.1.4, 10.2.0.\n\n\n\nUsers are recommended to upgrade to version 9.2.16, 10.1.5, or 10.2.1, which fix the issue."
}
],
"metrics": [
{
"other": {
"content": {
"text": "important"
},
"type": "Textual description of severity"
},
"scenarios": [
{
"lang": "en",
"value": "GENERAL"
}
]
},
{
"cvssV3_1": {
"attackComplexity": "HIGH",
"attackVector": "NETWORK",
"availabilityImpact": "LOW",
"baseScore": 8.9,
"baseSeverity": "HIGH",
"confidentialityImpact": "HIGH",
"integrityImpact": "HIGH",
"privilegesRequired": "NONE",
"scope": "CHANGED",
"userInteraction": "NONE",
"vectorString": "CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:C/C:H/I:H/A:L",
"version": "3.1"
},
"format": "CVSS",
"scenarios": [
{
"lang": "en",
"value": "GENERAL"
}
]
},
{
"cvssV4_0": {
"Automatable": "NOT_DEFINED",
"Recovery": "NOT_DEFINED",
"Safety": "NOT_DEFINED",
"attackComplexity": "LOW",
"attackRequirements": "PRESENT",
"attackVector": "NETWORK",
"baseScore": 9.1,
"baseSeverity": "CRITICAL",
"exploitMaturity": "NOT_DEFINED",
"privilegesRequired": "NONE",
"providerUrgency": "NOT_DEFINED",
"subAvailabilityImpact": "LOW",
"subConfidentialityImpact": "HIGH",
"subIntegrityImpact": "HIGH",
"userInteraction": "NONE",
"valueDensity": "NOT_DEFINED",
"vectorString": "CVSS:4.0/AV:N/AC:L/AT:P/PR:N/UI:N/VC:L/VI:H/VA:L/SC:H/SI:H/SA:L",
"version": "4.0",
"vulnAvailabilityImpact": "LOW",
"vulnConfidentialityImpact": "LOW",
"vulnIntegrityImpact": "HIGH",
"vulnerabilityResponseEffort": "NOT_DEFINED"
},
"format": "CVSS",
"scenarios": [
{
"lang": "en",
"value": "GENERAL"
}
]
}
],
"problemTypes": [
{
"descriptions": [
{
"cweId": "CWE-444",
"description": "CWE-444 Inconsistent Interpretation of HTTP Requests",
"lang": "en",
"type": "CWE"
}
]
}
],
"providerMetadata": {
"dateUpdated": "2026-10-21T18:22:28.383Z",
"orgId": "f0158376-9dc2-43b6-827c-5f631a4d8d09",
"shortName": "apache"
},
"references": [
{
"tags": [
"vendor-advisory"
],
"url": "https://lists.apache.org/thread/r95dq29ywcd1f4x30snxlqmb12z4s4kc"
}
],
"source": {
"discovery": "UNKNOWN"
},
"title": "Apache Traffic Server: Origin connection still owed a request body is reused, enabling request smuggling",
"x_generator": {
"engine": "scripts/cve_render.py"
}
}
},
"cveMetadata": {
"assignerOrgId": "f0158376-9dc2-43b6-827c-5f631a4d8d09",
"assignerShortName": "apache",
"cveId": "CVE-2025-31699",
"datePublished": "2026-10-21T18:22:28.383Z",
"dateReserved": "2025-04-01T00:04:31.777Z",
"dateUpdated": "2026-10-21T18:22:28.383Z",
"state": "PUBLISHED"
},
"dataType": "CVE_RECORD",
"dataVersion": "5.2"
}
CVE-2026-111804 (GCVE-0-2026-111804)
Vulnerability from cvelistv5 – Published: 2026-10-21 18:21 – Updated: 2026-10-21 18:21
VLAI
EPSS
VEX
Title
Apache Traffic Server: wasm plugin has a use-after-free and forwards unvalidated guest metric IDs
Summary
Apache Traffic Server's experimental wasm plugin has a use-after-free in its transaction-close handler and forwards unvalidated guest-supplied metric IDs to the internal stats API.
This issue affects Apache Traffic Server: from 10.0.0 through 10.1.4, 10.2.0.
Users are recommended to upgrade to version 10.1.5 or 10.2.1, which fix the issue.
Severity
CWE
- CWE-416 - Use After Free
Assigner
References
1 reference
| URL | Tags |
|---|---|
| https://lists.apache.org/thread/r95dq29ywcd1f4x30… | vendor-advisory |
Impacted products
1 product
| Vendor | Product | Version | |
|---|---|---|---|
| Apache Software Foundation | Apache Traffic Server |
Affected:
10.0.0 , ≤ 10.1.4
(semver)
Affected: 10.2.0 (semver) |
{
"containers": {
"cna": {
"affected": [
{
"defaultStatus": "unaffected",
"product": "Apache Traffic Server",
"vendor": "Apache Software Foundation",
"versions": [
{
"lessThanOrEqual": "10.1.4",
"status": "affected",
"version": "10.0.0",
"versionType": "semver"
},
{
"status": "affected",
"version": "10.2.0",
"versionType": "semver"
}
]
}
],
"credits": [
{
"lang": "en",
"type": "reporter",
"value": "Omkhar Arasaratnam"
},
{
"lang": "en",
"type": "reporter",
"value": "Apache Community"
}
],
"descriptions": [
{
"lang": "en",
"supportingMedia": [
{
"base64": false,
"type": "text/html",
"value": "\u003cp\u003eApache Traffic Server\u0027s experimental wasm plugin has a use-after-free in its transaction-close handler and forwards unvalidated guest-supplied metric IDs to the internal stats API.\u003c/p\u003e\u003cp\u003eThis issue affects Apache Traffic Server: from 10.0.0 through 10.1.4, 10.2.0.\u003c/p\u003e\u003cp\u003eUsers are recommended to upgrade to version 10.1.5 or 10.2.1, which fix the issue.\u003c/p\u003e"
}
],
"value": "Apache Traffic Server\u0027s experimental wasm plugin has a use-after-free in its transaction-close handler and forwards unvalidated guest-supplied metric IDs to the internal stats API.\n\n\n\nThis issue affects Apache Traffic Server: from 10.0.0 through 10.1.4, 10.2.0.\n\n\n\nUsers are recommended to upgrade to version 10.1.5 or 10.2.1, which fix the issue."
}
],
"metrics": [
{
"other": {
"content": {
"text": "critical"
},
"type": "Textual description of severity"
},
"scenarios": [
{
"lang": "en",
"value": "GENERAL"
}
]
},
{
"cvssV3_1": {
"attackComplexity": "LOW",
"attackVector": "NETWORK",
"availabilityImpact": "HIGH",
"baseScore": 8.2,
"baseSeverity": "HIGH",
"confidentialityImpact": "NONE",
"integrityImpact": "LOW",
"privilegesRequired": "NONE",
"scope": "UNCHANGED",
"userInteraction": "NONE",
"vectorString": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:L/A:H",
"version": "3.1"
},
"format": "CVSS",
"scenarios": [
{
"lang": "en",
"value": "GENERAL"
}
]
},
{
"cvssV4_0": {
"Automatable": "NOT_DEFINED",
"Recovery": "NOT_DEFINED",
"Safety": "NOT_DEFINED",
"attackComplexity": "LOW",
"attackRequirements": "NONE",
"attackVector": "NETWORK",
"baseScore": 8.8,
"baseSeverity": "HIGH",
"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:N/PR:N/UI:N/VC:N/VI:L/VA:H/SC:N/SI:N/SA:N",
"version": "4.0",
"vulnAvailabilityImpact": "HIGH",
"vulnConfidentialityImpact": "NONE",
"vulnIntegrityImpact": "LOW",
"vulnerabilityResponseEffort": "NOT_DEFINED"
},
"format": "CVSS",
"scenarios": [
{
"lang": "en",
"value": "GENERAL"
}
]
}
],
"problemTypes": [
{
"descriptions": [
{
"cweId": "CWE-416",
"description": "CWE-416 Use After Free",
"lang": "en",
"type": "CWE"
}
]
}
],
"providerMetadata": {
"dateUpdated": "2026-10-21T18:21:32.055Z",
"orgId": "f0158376-9dc2-43b6-827c-5f631a4d8d09",
"shortName": "apache"
},
"references": [
{
"tags": [
"vendor-advisory"
],
"url": "https://lists.apache.org/thread/r95dq29ywcd1f4x30snxlqmb12z4s4kc"
}
],
"source": {
"discovery": "UNKNOWN"
},
"title": "Apache Traffic Server: wasm plugin has a use-after-free and forwards unvalidated guest metric IDs",
"x_generator": {
"engine": "scripts/cve_render.py"
}
}
},
"cveMetadata": {
"assignerOrgId": "f0158376-9dc2-43b6-827c-5f631a4d8d09",
"assignerShortName": "apache",
"cveId": "CVE-2026-111804",
"datePublished": "2026-10-21T18:21:32.055Z",
"dateReserved": "2026-10-16T20:15:36.197Z",
"dateUpdated": "2026-10-21T18:21:32.055Z",
"state": "PUBLISHED"
},
"dataType": "CVE_RECORD",
"dataVersion": "5.2"
}
CVE-2026-111816 (GCVE-0-2026-111816)
Vulnerability from nvd – Published: 2026-10-21 18:26 – Updated: 2026-10-21 18:26
VLAI
EPSS
VEX
Title
Apache Traffic Server: A malformed 302 response bypasses parse-error rejection through the Transfer-Encoding: chunked carve-out
Summary
Apache Traffic Server forwarded a malformed 302 response that should have been rejected as a parse error, because the Transfer-Encoding: chunked carve-out bypassed the rejection path. A response that two peers can read differently is then stored and served, allowing cache poisoning and response-framing desync.
This issue affects Apache Traffic Server: from 8.0.0 through 8.1.11, from 9.0.0 through 9.2.15, from 10.0.0 through 10.1.4, 10.2.0.
Users are recommended to upgrade to version 9.2.16, 10.1.5, or 10.2.1, which fix the issue.
Severity
9.3 (Critical)
CWE
- CWE-444 - Inconsistent Interpretation of HTTP Requests
Assigner
References
1 reference
| URL | Tags |
|---|---|
| https://lists.apache.org/thread/r95dq29ywcd1f4x30… | vendor-advisory |
Impacted products
1 product
| Vendor | Product | Version | |
|---|---|---|---|
| Apache Software Foundation | Apache Traffic Server |
Affected:
8.0.0 , ≤ 8.1.11
(semver)
Affected: 9.0.0 , ≤ 9.2.15 (semver) Affected: 10.0.0 , ≤ 10.1.4 (semver) Affected: 10.2.0 (semver) |
{
"containers": {
"cna": {
"affected": [
{
"defaultStatus": "unaffected",
"product": "Apache Traffic Server",
"vendor": "Apache Software Foundation",
"versions": [
{
"lessThanOrEqual": "8.1.11",
"status": "affected",
"version": "8.0.0",
"versionType": "semver"
},
{
"lessThanOrEqual": "9.2.15",
"status": "affected",
"version": "9.0.0",
"versionType": "semver"
},
{
"lessThanOrEqual": "10.1.4",
"status": "affected",
"version": "10.0.0",
"versionType": "semver"
},
{
"status": "affected",
"version": "10.2.0",
"versionType": "semver"
}
]
}
],
"credits": [
{
"lang": "en",
"type": "reporter",
"value": "Apache Community"
},
{
"lang": "en",
"type": "reporter",
"value": "OneZ3r0"
}
],
"descriptions": [
{
"lang": "en",
"supportingMedia": [
{
"base64": false,
"type": "text/html",
"value": "\u003cp\u003eApache Traffic Server forwarded a malformed 302 response that should have been rejected as a parse error, because the Transfer-Encoding: chunked carve-out bypassed the rejection path. A response that two peers can read differently is then stored and served, allowing cache poisoning and response-framing desync.\u003c/p\u003e\u003cp\u003eThis issue affects Apache Traffic Server: from 8.0.0 through 8.1.11, from 9.0.0 through 9.2.15, from 10.0.0 through 10.1.4, 10.2.0.\u003c/p\u003e\u003cp\u003eUsers are recommended to upgrade to version 9.2.16, 10.1.5, or 10.2.1, which fix the issue.\u003c/p\u003e"
}
],
"value": "Apache Traffic Server forwarded a malformed 302 response that should have been rejected as a parse error, because the Transfer-Encoding: chunked carve-out bypassed the rejection path. A response that two peers can read differently is then stored and served, allowing cache poisoning and response-framing desync.\n\n\n\nThis issue affects Apache Traffic Server: from 8.0.0 through 8.1.11, from 9.0.0 through 9.2.15, from 10.0.0 through 10.1.4, 10.2.0.\n\n\n\nUsers are recommended to upgrade to version 9.2.16, 10.1.5, or 10.2.1, which fix the issue."
}
],
"metrics": [
{
"other": {
"content": {
"text": "important"
},
"type": "Textual description of severity"
},
"scenarios": [
{
"lang": "en",
"value": "GENERAL"
}
]
},
{
"cvssV3_1": {
"attackComplexity": "LOW",
"attackVector": "NETWORK",
"availabilityImpact": "NONE",
"baseScore": 9.3,
"baseSeverity": "CRITICAL",
"confidentialityImpact": "LOW",
"integrityImpact": "HIGH",
"privilegesRequired": "NONE",
"scope": "CHANGED",
"userInteraction": "NONE",
"vectorString": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:C/C:L/I:H/A:N",
"version": "3.1"
},
"format": "CVSS",
"scenarios": [
{
"lang": "en",
"value": "GENERAL"
}
]
},
{
"cvssV4_0": {
"Automatable": "NOT_DEFINED",
"Recovery": "NOT_DEFINED",
"Safety": "NOT_DEFINED",
"attackComplexity": "LOW",
"attackRequirements": "NONE",
"attackVector": "NETWORK",
"baseScore": 9.2,
"baseSeverity": "CRITICAL",
"exploitMaturity": "NOT_DEFINED",
"privilegesRequired": "NONE",
"providerUrgency": "NOT_DEFINED",
"subAvailabilityImpact": "NONE",
"subConfidentialityImpact": "LOW",
"subIntegrityImpact": "HIGH",
"userInteraction": "NONE",
"valueDensity": "NOT_DEFINED",
"vectorString": "CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:N/VI:H/VA:N/SC:L/SI:H/SA:N",
"version": "4.0",
"vulnAvailabilityImpact": "NONE",
"vulnConfidentialityImpact": "NONE",
"vulnIntegrityImpact": "HIGH",
"vulnerabilityResponseEffort": "NOT_DEFINED"
},
"format": "CVSS",
"scenarios": [
{
"lang": "en",
"value": "GENERAL"
}
]
}
],
"problemTypes": [
{
"descriptions": [
{
"cweId": "CWE-444",
"description": "CWE-444 Inconsistent Interpretation of HTTP Requests",
"lang": "en",
"type": "CWE"
}
]
}
],
"providerMetadata": {
"dateUpdated": "2026-10-21T18:26:32.566Z",
"orgId": "f0158376-9dc2-43b6-827c-5f631a4d8d09",
"shortName": "apache"
},
"references": [
{
"tags": [
"vendor-advisory"
],
"url": "https://lists.apache.org/thread/r95dq29ywcd1f4x30snxlqmb12z4s4kc"
}
],
"source": {
"discovery": "UNKNOWN"
},
"title": "Apache Traffic Server: A malformed 302 response bypasses parse-error rejection through the Transfer-Encoding: chunked carve-out",
"x_generator": {
"engine": "scripts/cve_render.py"
}
}
},
"cveMetadata": {
"assignerOrgId": "f0158376-9dc2-43b6-827c-5f631a4d8d09",
"assignerShortName": "apache",
"cveId": "CVE-2026-111816",
"datePublished": "2026-10-21T18:26:32.566Z",
"dateReserved": "2026-10-16T20:25:17.923Z",
"dateUpdated": "2026-10-21T18:26:32.566Z",
"state": "PUBLISHED"
},
"dataType": "CVE_RECORD",
"dataVersion": "5.2"
}
CVE-2026-111813 (GCVE-0-2026-111813)
Vulnerability from nvd – Published: 2026-10-21 18:20 – Updated: 2026-10-21 18:20
VLAI
EPSS
VEX
Title
Apache Traffic Server: magick plugin passes client query strings unfiltered to ImageMagick convert in the default configuration
Summary
Apache Traffic Server's experimental magick plugin lets an unauthenticated client control ImageMagick convert arguments in its default (unsigned) configuration.
This issue affects Apache Traffic Server: from 8.0.1 through 8.1.11, from 9.0.0 through 9.2.15, from 10.0.0 through 10.1.4, 10.2.0.
Users are recommended to upgrade to version 9.2.16, 10.1.5, or 10.2.1, which fix the issue.
Severity
10 (Critical)
CWE
- CWE-88 - Improper Neutralization of Argument Delimiters in a Command ('Argument Injection')
Assigner
References
1 reference
| URL | Tags |
|---|---|
| https://lists.apache.org/thread/r95dq29ywcd1f4x30… | vendor-advisory |
Impacted products
1 product
| Vendor | Product | Version | |
|---|---|---|---|
| Apache Software Foundation | Apache Traffic Server |
Affected:
8.0.1 , ≤ 8.1.11
(semver)
Affected: 9.0.0 , ≤ 9.2.15 (semver) Affected: 10.0.0 , ≤ 10.1.4 (semver) Affected: 10.2.0 (semver) |
{
"containers": {
"cna": {
"affected": [
{
"defaultStatus": "unaffected",
"product": "Apache Traffic Server",
"vendor": "Apache Software Foundation",
"versions": [
{
"lessThanOrEqual": "8.1.11",
"status": "affected",
"version": "8.0.1",
"versionType": "semver"
},
{
"lessThanOrEqual": "9.2.15",
"status": "affected",
"version": "9.0.0",
"versionType": "semver"
},
{
"lessThanOrEqual": "10.1.4",
"status": "affected",
"version": "10.0.0",
"versionType": "semver"
},
{
"status": "affected",
"version": "10.2.0",
"versionType": "semver"
}
]
}
],
"credits": [
{
"lang": "en",
"type": "reporter",
"value": "Apache Community"
},
{
"lang": "en",
"type": "reporter",
"value": "The ASF"
},
{
"lang": "en",
"type": "reporter",
"value": "Abraxas Labs"
}
],
"descriptions": [
{
"lang": "en",
"supportingMedia": [
{
"base64": false,
"type": "text/html",
"value": "\u003cp\u003eApache Traffic Server\u0027s experimental magick plugin lets an unauthenticated client control ImageMagick convert arguments in its default (unsigned) configuration.\u003c/p\u003e\u003cp\u003eThis issue affects Apache Traffic Server: from 8.0.1 through 8.1.11, from 9.0.0 through 9.2.15, from 10.0.0 through 10.1.4, 10.2.0.\u003c/p\u003e\u003cp\u003eUsers are recommended to upgrade to version 9.2.16, 10.1.5, or 10.2.1, which fix the issue.\u003c/p\u003e"
}
],
"value": "Apache Traffic Server\u0027s experimental magick plugin lets an unauthenticated client control ImageMagick convert arguments in its default (unsigned) configuration.\n\n\n\nThis issue affects Apache Traffic Server: from 8.0.1 through 8.1.11, from 9.0.0 through 9.2.15, from 10.0.0 through 10.1.4, 10.2.0.\n\n\n\nUsers are recommended to upgrade to version 9.2.16, 10.1.5, or 10.2.1, which fix the issue."
}
],
"metrics": [
{
"other": {
"content": {
"text": "critical"
},
"type": "Textual description of severity"
},
"scenarios": [
{
"lang": "en",
"value": "GENERAL"
}
]
},
{
"cvssV3_1": {
"attackComplexity": "LOW",
"attackVector": "NETWORK",
"availabilityImpact": "HIGH",
"baseScore": 10,
"baseSeverity": "CRITICAL",
"confidentialityImpact": "HIGH",
"integrityImpact": "HIGH",
"privilegesRequired": "NONE",
"scope": "CHANGED",
"userInteraction": "NONE",
"vectorString": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:C/C:H/I:H/A:H",
"version": "3.1"
},
"format": "CVSS",
"scenarios": [
{
"lang": "en",
"value": "GENERAL"
}
]
},
{
"cvssV4_0": {
"Automatable": "NOT_DEFINED",
"Recovery": "NOT_DEFINED",
"Safety": "NOT_DEFINED",
"attackComplexity": "LOW",
"attackRequirements": "NONE",
"attackVector": "NETWORK",
"baseScore": 10,
"baseSeverity": "CRITICAL",
"exploitMaturity": "NOT_DEFINED",
"privilegesRequired": "NONE",
"providerUrgency": "NOT_DEFINED",
"subAvailabilityImpact": "HIGH",
"subConfidentialityImpact": "HIGH",
"subIntegrityImpact": "HIGH",
"userInteraction": "NONE",
"valueDensity": "NOT_DEFINED",
"vectorString": "CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:H/VI:H/VA:H/SC:H/SI:H/SA:H",
"version": "4.0",
"vulnAvailabilityImpact": "HIGH",
"vulnConfidentialityImpact": "HIGH",
"vulnIntegrityImpact": "HIGH",
"vulnerabilityResponseEffort": "NOT_DEFINED"
},
"format": "CVSS",
"scenarios": [
{
"lang": "en",
"value": "GENERAL"
}
]
}
],
"problemTypes": [
{
"descriptions": [
{
"cweId": "CWE-88",
"description": "CWE-88 Improper Neutralization of Argument Delimiters in a Command (\u0027Argument Injection\u0027)",
"lang": "en",
"type": "CWE"
}
]
}
],
"providerMetadata": {
"dateUpdated": "2026-10-21T18:20:22.104Z",
"orgId": "f0158376-9dc2-43b6-827c-5f631a4d8d09",
"shortName": "apache"
},
"references": [
{
"tags": [
"vendor-advisory"
],
"url": "https://lists.apache.org/thread/r95dq29ywcd1f4x30snxlqmb12z4s4kc"
}
],
"source": {
"discovery": "UNKNOWN"
},
"title": "Apache Traffic Server: magick plugin passes client query strings unfiltered to ImageMagick convert in the default configuration",
"x_generator": {
"engine": "scripts/cve_render.py"
}
}
},
"cveMetadata": {
"assignerOrgId": "f0158376-9dc2-43b6-827c-5f631a4d8d09",
"assignerShortName": "apache",
"cveId": "CVE-2026-111813",
"datePublished": "2026-10-21T18:20:22.104Z",
"dateReserved": "2026-10-16T20:23:12.095Z",
"dateUpdated": "2026-10-21T18:20:22.104Z",
"state": "PUBLISHED"
},
"dataType": "CVE_RECORD",
"dataVersion": "5.2"
}
CVE-2026-111804 (GCVE-0-2026-111804)
Vulnerability from nvd – Published: 2026-10-21 18:21 – Updated: 2026-10-21 18:21
VLAI
EPSS
VEX
Title
Apache Traffic Server: wasm plugin has a use-after-free and forwards unvalidated guest metric IDs
Summary
Apache Traffic Server's experimental wasm plugin has a use-after-free in its transaction-close handler and forwards unvalidated guest-supplied metric IDs to the internal stats API.
This issue affects Apache Traffic Server: from 10.0.0 through 10.1.4, 10.2.0.
Users are recommended to upgrade to version 10.1.5 or 10.2.1, which fix the issue.
Severity
CWE
- CWE-416 - Use After Free
Assigner
References
1 reference
| URL | Tags |
|---|---|
| https://lists.apache.org/thread/r95dq29ywcd1f4x30… | vendor-advisory |
Impacted products
1 product
| Vendor | Product | Version | |
|---|---|---|---|
| Apache Software Foundation | Apache Traffic Server |
Affected:
10.0.0 , ≤ 10.1.4
(semver)
Affected: 10.2.0 (semver) |
{
"containers": {
"cna": {
"affected": [
{
"defaultStatus": "unaffected",
"product": "Apache Traffic Server",
"vendor": "Apache Software Foundation",
"versions": [
{
"lessThanOrEqual": "10.1.4",
"status": "affected",
"version": "10.0.0",
"versionType": "semver"
},
{
"status": "affected",
"version": "10.2.0",
"versionType": "semver"
}
]
}
],
"credits": [
{
"lang": "en",
"type": "reporter",
"value": "Omkhar Arasaratnam"
},
{
"lang": "en",
"type": "reporter",
"value": "Apache Community"
}
],
"descriptions": [
{
"lang": "en",
"supportingMedia": [
{
"base64": false,
"type": "text/html",
"value": "\u003cp\u003eApache Traffic Server\u0027s experimental wasm plugin has a use-after-free in its transaction-close handler and forwards unvalidated guest-supplied metric IDs to the internal stats API.\u003c/p\u003e\u003cp\u003eThis issue affects Apache Traffic Server: from 10.0.0 through 10.1.4, 10.2.0.\u003c/p\u003e\u003cp\u003eUsers are recommended to upgrade to version 10.1.5 or 10.2.1, which fix the issue.\u003c/p\u003e"
}
],
"value": "Apache Traffic Server\u0027s experimental wasm plugin has a use-after-free in its transaction-close handler and forwards unvalidated guest-supplied metric IDs to the internal stats API.\n\n\n\nThis issue affects Apache Traffic Server: from 10.0.0 through 10.1.4, 10.2.0.\n\n\n\nUsers are recommended to upgrade to version 10.1.5 or 10.2.1, which fix the issue."
}
],
"metrics": [
{
"other": {
"content": {
"text": "critical"
},
"type": "Textual description of severity"
},
"scenarios": [
{
"lang": "en",
"value": "GENERAL"
}
]
},
{
"cvssV3_1": {
"attackComplexity": "LOW",
"attackVector": "NETWORK",
"availabilityImpact": "HIGH",
"baseScore": 8.2,
"baseSeverity": "HIGH",
"confidentialityImpact": "NONE",
"integrityImpact": "LOW",
"privilegesRequired": "NONE",
"scope": "UNCHANGED",
"userInteraction": "NONE",
"vectorString": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:L/A:H",
"version": "3.1"
},
"format": "CVSS",
"scenarios": [
{
"lang": "en",
"value": "GENERAL"
}
]
},
{
"cvssV4_0": {
"Automatable": "NOT_DEFINED",
"Recovery": "NOT_DEFINED",
"Safety": "NOT_DEFINED",
"attackComplexity": "LOW",
"attackRequirements": "NONE",
"attackVector": "NETWORK",
"baseScore": 8.8,
"baseSeverity": "HIGH",
"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:N/PR:N/UI:N/VC:N/VI:L/VA:H/SC:N/SI:N/SA:N",
"version": "4.0",
"vulnAvailabilityImpact": "HIGH",
"vulnConfidentialityImpact": "NONE",
"vulnIntegrityImpact": "LOW",
"vulnerabilityResponseEffort": "NOT_DEFINED"
},
"format": "CVSS",
"scenarios": [
{
"lang": "en",
"value": "GENERAL"
}
]
}
],
"problemTypes": [
{
"descriptions": [
{
"cweId": "CWE-416",
"description": "CWE-416 Use After Free",
"lang": "en",
"type": "CWE"
}
]
}
],
"providerMetadata": {
"dateUpdated": "2026-10-21T18:21:32.055Z",
"orgId": "f0158376-9dc2-43b6-827c-5f631a4d8d09",
"shortName": "apache"
},
"references": [
{
"tags": [
"vendor-advisory"
],
"url": "https://lists.apache.org/thread/r95dq29ywcd1f4x30snxlqmb12z4s4kc"
}
],
"source": {
"discovery": "UNKNOWN"
},
"title": "Apache Traffic Server: wasm plugin has a use-after-free and forwards unvalidated guest metric IDs",
"x_generator": {
"engine": "scripts/cve_render.py"
}
}
},
"cveMetadata": {
"assignerOrgId": "f0158376-9dc2-43b6-827c-5f631a4d8d09",
"assignerShortName": "apache",
"cveId": "CVE-2026-111804",
"datePublished": "2026-10-21T18:21:32.055Z",
"dateReserved": "2026-10-16T20:15:36.197Z",
"dateUpdated": "2026-10-21T18:21:32.055Z",
"state": "PUBLISHED"
},
"dataType": "CVE_RECORD",
"dataVersion": "5.2"
}
CVE-2026-105945 (GCVE-0-2026-105945)
Vulnerability from nvd – Published: 2026-10-21 18:18 – Updated: 2026-10-21 18:18
VLAI
EPSS
VEX
Title
Apache Pulsar: Improper Validation of Package Name Components Allows Cross-Tenant Package Access in Filesystem Package Storage
Summary
The Pulsar Packages Management Service can be configured to store packages on the local filesystem of the broker by using the filesystem storage provider. Package names consist of a type, tenant, namespace, name and version. Authorization of package operations is based only on the tenant and namespace, while the storage location of a package is derived from all of these components. The version component of a package name was not validated, so it could contain URL-encoded path separators and parent directory references. The filesystem storage provider resolved such a version to a location belonging to a package in a different tenant or namespace. Because that location is inside the configured storage directory, the containment check that the filesystem storage provider performs in recent releases did not prevent the access.
An authenticated user who has the packages permission on any namespace could use this to download, overwrite or delete packages stored in other tenants or namespaces for which the user has no permission. Packages overwritten or deleted in this way may be used by Pulsar Functions, Sources or Sinks, so the issue can affect the integrity and availability of these components. If authentication is disabled, the operations are available to any client that can reach the broker's admin REST API.
This issue only affects deployments in which package management is enabled with the broker setting enablePackagesManagement and the filesystem storage provider (FileSystemPackagesStorageProvider) is configured with the setting packagesManagementStorageProvider. Package management is disabled by default, and the default storage provider, which stores packages in Apache BookKeeper, is not affected.
This issue affects Apache Pulsar versions from 2.10.0 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/.
Severity
CWE
- CWE-22 - Improper Limitation of a Pathname to a Restricted Directory ('Path Traversal')
Assigner
References
2 references
| URL | Tags |
|---|---|
| https://pulsar.apache.org/security/CVE-2026-105945/ | vendor-advisory |
| https://lists.apache.org/thread.html/o5jt8zrg1qxq… | vendor-advisory |
Impacted products
1 product
| Vendor | Product | Version | |
|---|---|---|---|
| Apache Software Foundation | Apache Pulsar |
Affected:
2.10.0 , < 4.0.14
(semver)
Affected: 4.1.0 , < 4.2.5 (semver) |
{
"containers": {
"cna": {
"affected": [
{
"defaultStatus": "unaffected",
"product": "Apache Pulsar",
"vendor": "Apache Software Foundation",
"versions": [
{
"lessThan": "4.0.14",
"status": "affected",
"version": "2.10.0",
"versionType": "semver"
},
{
"lessThan": "4.2.5",
"status": "affected",
"version": "4.1.0",
"versionType": "semver"
}
]
}
],
"credits": [
{
"lang": "en",
"type": "finder",
"value": "n0mi1k"
},
{
"lang": "en",
"type": "finder",
"value": "GSIeaves"
}
],
"descriptions": [
{
"lang": "en",
"supportingMedia": [
{
"base64": false,
"type": "text/html",
"value": "The Pulsar Packages Management Service can be configured to store packages on the local filesystem of the broker by using the filesystem storage provider. Package names consist of a type, tenant, namespace, name and version. Authorization of package operations is based only on the tenant and namespace, while the storage location of a package is derived from all of these components. The version component of a package name was not validated, so it could contain URL-encoded path separators and parent directory references. The filesystem storage provider resolved such a version to a location belonging to a package in a different tenant or namespace. Because that location is inside the configured storage directory, the containment check that the filesystem storage provider performs in recent releases did not prevent the access.\u003cbr\u003e\u003cbr\u003eAn authenticated user who has the packages permission on any namespace could use this to download, overwrite or delete packages stored in other tenants or namespaces for which the user has no permission. Packages overwritten or deleted in this way may be used by Pulsar Functions, Sources or Sinks, so the issue can affect the integrity and availability of these components. If authentication is disabled, the operations are available to any client that can reach the broker\u0027s admin REST API.\u003cbr\u003e\u003cbr\u003eThis issue only affects deployments in which package management is enabled with the broker setting enablePackagesManagement and the filesystem storage provider (FileSystemPackagesStorageProvider) is configured with the setting packagesManagementStorageProvider. Package management is disabled by default, and the default storage provider, which stores packages in Apache BookKeeper, is not affected.\u003cbr\u003e\u003cbr\u003eThis issue affects Apache Pulsar versions from 2.10.0 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/."
}
],
"value": "The Pulsar Packages Management Service can be configured to store packages on the local filesystem of the broker by using the filesystem storage provider. Package names consist of a type, tenant, namespace, name and version. Authorization of package operations is based only on the tenant and namespace, while the storage location of a package is derived from all of these components. The version component of a package name was not validated, so it could contain URL-encoded path separators and parent directory references. The filesystem storage provider resolved such a version to a location belonging to a package in a different tenant or namespace. Because that location is inside the configured storage directory, the containment check that the filesystem storage provider performs in recent releases did not prevent the access.\n\nAn authenticated user who has the packages permission on any namespace could use this to download, overwrite or delete packages stored in other tenants or namespaces for which the user has no permission. Packages overwritten or deleted in this way may be used by Pulsar Functions, Sources or Sinks, so the issue can affect the integrity and availability of these components. If authentication is disabled, the operations are available to any client that can reach the broker\u0027s admin REST API.\n\nThis issue only affects deployments in which package management is enabled with the broker setting enablePackagesManagement and the filesystem storage provider (FileSystemPackagesStorageProvider) is configured with the setting packagesManagementStorageProvider. Package management is disabled by default, and the default storage provider, which stores packages in Apache BookKeeper, is not affected.\n\nThis issue affects Apache Pulsar versions from 2.10.0 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/."
}
],
"metrics": [
{
"cvssV4_0": {
"Automatable": "NOT_DEFINED",
"Recovery": "NOT_DEFINED",
"Safety": "NOT_DEFINED",
"attackComplexity": "LOW",
"attackRequirements": "PRESENT",
"attackVector": "NETWORK",
"baseScore": 7.7,
"baseSeverity": "HIGH",
"exploitMaturity": "NOT_DEFINED",
"privilegesRequired": "LOW",
"providerUrgency": "NOT_DEFINED",
"subAvailabilityImpact": "LOW",
"subConfidentialityImpact": "NONE",
"subIntegrityImpact": "LOW",
"userInteraction": "NONE",
"valueDensity": "NOT_DEFINED",
"vectorString": "CVSS:4.0/AV:N/AC:L/AT:P/PR:L/UI:N/VC:H/VI:H/VA:H/SC:N/SI:L/SA:L",
"version": "4.0",
"vulnAvailabilityImpact": "HIGH",
"vulnConfidentialityImpact": "HIGH",
"vulnIntegrityImpact": "HIGH",
"vulnerabilityResponseEffort": "NOT_DEFINED"
},
"format": "CVSS",
"scenarios": [
{
"lang": "en",
"value": "GENERAL"
}
]
}
],
"problemTypes": [
{
"descriptions": [
{
"cweId": "CWE-22",
"description": "CWE-22 Improper Limitation of a Pathname to a Restricted Directory (\u0027Path Traversal\u0027)",
"lang": "en",
"type": "CWE"
}
]
}
],
"providerMetadata": {
"dateUpdated": "2026-10-21T18:18:26.687Z",
"orgId": "f0158376-9dc2-43b6-827c-5f631a4d8d09",
"shortName": "apache"
},
"references": [
{
"tags": [
"vendor-advisory"
],
"url": "https://pulsar.apache.org/security/CVE-2026-105945/"
},
{
"tags": [
"vendor-advisory"
],
"url": "https://lists.apache.org/thread.html/o5jt8zrg1qxqdrqlb06jjmj4lzydfm2k"
}
],
"source": {
"discovery": "EXTERNAL"
},
"title": "Apache Pulsar: Improper Validation of Package Name Components Allows Cross-Tenant Package Access in Filesystem Package Storage",
"x_generator": {
"engine": "Vulnogram 1.0.3"
}
}
},
"cveMetadata": {
"assignerOrgId": "f0158376-9dc2-43b6-827c-5f631a4d8d09",
"assignerShortName": "apache",
"cveId": "CVE-2026-105945",
"datePublished": "2026-10-21T18:18:26.687Z",
"dateReserved": "2026-10-06T07:19:45.804Z",
"dateUpdated": "2026-10-21T18:18:26.687Z",
"state": "PUBLISHED"
},
"dataType": "CVE_RECORD",
"dataVersion": "5.2"
}
CVE-2026-105944 (GCVE-0-2026-105944)
Vulnerability from nvd – Published: 2026-10-21 18:17 – Updated: 2026-10-21 22:07
VLAI
EPSS
VEX
Title
Apache Pulsar Manager: Missing authentication and authorization and disclosure of the Pulsar admin credential; end of life
Summary
Apache Pulsar Manager is a web console for administering Apache Pulsar clusters. It has its own user accounts and login, and it can be configured with an HTTP authentication credential, such as a token, that it uses to call the Pulsar admin API on behalf of its users. Pulsar Manager has the following security issues:
- The operation for creating the initial administrator (superuser) account is available without authentication, and it remains available after the instance has been initialized. Anyone who can reach Pulsar Manager can create an additional administrator account at any time and log in with it. This issue affects versions 0.3.0 and later.
- Requests to the Pulsar admin API that Pulsar Manager proxies to the configured Pulsar cluster are not subject to Pulsar Manager's authentication. Version 0.2.0 checks the caller's permissions for some of these requests, but not for all of them. An unauthenticated user can therefore use Pulsar Manager to send requests to the Pulsar admin API, which the cluster processes with the credential configured in Pulsar Manager.
- The destination of a proxied request can be chosen by the requester, and Pulsar Manager attaches its configured Pulsar admin credential to the request. An unauthenticated user can make Pulsar Manager send this credential to a host of the user's choosing, and the credential can then be used directly against the Pulsar cluster.
- In versions 0.3.0 and later, Pulsar Manager does not distinguish between privilege levels of its accounts. Every account, including one created through the first issue, effectively has full administrative privileges in Pulsar Manager.
The impact depends on the version and the deployment. In versions 0.3.0 and later, any user who can reach Pulsar Manager over the network can take full control of Pulsar Manager. In all versions, when Pulsar Manager is configured with an HTTP authentication credential for a Pulsar cluster, any user who can reach Pulsar Manager can perform the Pulsar admin operations that this credential permits and can obtain the credential itself. When Pulsar Manager is configured with the token signing key of a Pulsar cluster, an administrator of Pulsar Manager can create tokens for the cluster.
Apache Pulsar Manager is no longer maintained and is completely unsupported. The Apache Pulsar PMC has retired it. There are no supported versions, and no further releases, fixes or security updates will be made for any version. These issues will not be fixed.
Using Pulsar Manager is not recommended. Users should stop using Pulsar Manager, remove existing deployments, and move to one of the alternatives described in the Administration UI documentation (https://pulsar.apache.org/docs/administration-ui). Users who have exposed Pulsar Manager configured with a Pulsar credential or token signing key should also consider replacing that credential or key.
Until a deployment is removed, users should not expose Pulsar Manager to untrusted networks, and should restrict network access to it to trusted administrators.
Severity
CWE
- CWE-306 - Missing Authentication for Critical Function
Assigner
References
4 references
Impacted products
1 product
| Vendor | Product | Version | |
|---|---|---|---|
| Apache Software Foundation | Apache Pulsar Manager |
Affected:
0.1.0 , ≤ 0.4.0
(semver)
|
{
"containers": {
"adp": [
{
"providerMetadata": {
"dateUpdated": "2026-10-21T22:07:22.765Z",
"orgId": "af854a3a-2127-422b-91ae-364da2661108",
"shortName": "CVE"
},
"references": [
{
"url": "http://www.openwall.com/lists/oss-security/2026/10/21/26"
}
],
"title": "CVE Program Container"
}
],
"cna": {
"affected": [
{
"defaultStatus": "unaffected",
"product": "Apache Pulsar Manager",
"vendor": "Apache Software Foundation",
"versions": [
{
"lessThanOrEqual": "0.4.0",
"status": "affected",
"version": "0.1.0",
"versionType": "semver"
}
]
}
],
"credits": [
{
"lang": "en",
"type": "finder",
"value": "Aleksandar Djordjevic"
},
{
"lang": "en",
"type": "finder",
"value": "Mike Read"
}
],
"descriptions": [
{
"lang": "en",
"supportingMedia": [
{
"base64": false,
"type": "text/html",
"value": "Apache Pulsar Manager is a web console for administering Apache Pulsar clusters. It has its own user accounts and login, and it can be configured with an HTTP authentication credential, such as a token, that it uses to call the Pulsar admin API on behalf of its users. Pulsar Manager has the following security issues:\u003cbr\u003e\u003cbr\u003e- The operation for creating the initial administrator (superuser) account is available without authentication, and it remains available after the instance has been initialized. Anyone who can reach Pulsar Manager can create an additional administrator account at any time and log in with it. This issue affects versions 0.3.0 and later.\u003cbr\u003e- Requests to the Pulsar admin API that Pulsar Manager proxies to the configured Pulsar cluster are not subject to Pulsar Manager\u0027s authentication. Version 0.2.0 checks the caller\u0027s permissions for some of these requests, but not for all of them. An unauthenticated user can therefore use Pulsar Manager to send requests to the Pulsar admin API, which the cluster processes with the credential configured in Pulsar Manager.\u003cbr\u003e- The destination of a proxied request can be chosen by the requester, and Pulsar Manager attaches its configured Pulsar admin credential to the request. An unauthenticated user can make Pulsar Manager send this credential to a host of the user\u0027s choosing, and the credential can then be used directly against the Pulsar cluster.\u003cbr\u003e- In versions 0.3.0 and later, Pulsar Manager does not distinguish between privilege levels of its accounts. Every account, including one created through the first issue, effectively has full administrative privileges in Pulsar Manager.\u003cbr\u003e\u003cbr\u003eThe impact depends on the version and the deployment. In versions 0.3.0 and later, any user who can reach Pulsar Manager over the network can take full control of Pulsar Manager. In all versions, when Pulsar Manager is configured with an HTTP authentication credential for a Pulsar cluster, any user who can reach Pulsar Manager can perform the Pulsar admin operations that this credential permits and can obtain the credential itself. When Pulsar Manager is configured with the token signing key of a Pulsar cluster, an administrator of Pulsar Manager can create tokens for the cluster.\u003cbr\u003e\u003cbr\u003eApache Pulsar Manager is no longer maintained and is completely unsupported. The Apache Pulsar PMC has retired it. There are no supported versions, and no further releases, fixes or security updates will be made for any version. These issues will not be fixed.\u003cbr\u003e\u003cbr\u003eUsing Pulsar Manager is not recommended. Users should stop using Pulsar Manager, remove existing deployments, and move to one of the alternatives described in the Administration UI documentation (https://pulsar.apache.org/docs/administration-ui). Users who have exposed Pulsar Manager configured with a Pulsar credential or token signing key should also consider replacing that credential or key.\u003cbr\u003e\u003cbr\u003eUntil a deployment is removed, users should not expose Pulsar Manager to untrusted networks, and should restrict network access to it to trusted administrators."
}
],
"value": "Apache Pulsar Manager is a web console for administering Apache Pulsar clusters. It has its own user accounts and login, and it can be configured with an HTTP authentication credential, such as a token, that it uses to call the Pulsar admin API on behalf of its users. Pulsar Manager has the following security issues:\n\n- The operation for creating the initial administrator (superuser) account is available without authentication, and it remains available after the instance has been initialized. Anyone who can reach Pulsar Manager can create an additional administrator account at any time and log in with it. This issue affects versions 0.3.0 and later.\n- Requests to the Pulsar admin API that Pulsar Manager proxies to the configured Pulsar cluster are not subject to Pulsar Manager\u0027s authentication. Version 0.2.0 checks the caller\u0027s permissions for some of these requests, but not for all of them. An unauthenticated user can therefore use Pulsar Manager to send requests to the Pulsar admin API, which the cluster processes with the credential configured in Pulsar Manager.\n- The destination of a proxied request can be chosen by the requester, and Pulsar Manager attaches its configured Pulsar admin credential to the request. An unauthenticated user can make Pulsar Manager send this credential to a host of the user\u0027s choosing, and the credential can then be used directly against the Pulsar cluster.\n- In versions 0.3.0 and later, Pulsar Manager does not distinguish between privilege levels of its accounts. Every account, including one created through the first issue, effectively has full administrative privileges in Pulsar Manager.\n\nThe impact depends on the version and the deployment. In versions 0.3.0 and later, any user who can reach Pulsar Manager over the network can take full control of Pulsar Manager. In all versions, when Pulsar Manager is configured with an HTTP authentication credential for a Pulsar cluster, any user who can reach Pulsar Manager can perform the Pulsar admin operations that this credential permits and can obtain the credential itself. When Pulsar Manager is configured with the token signing key of a Pulsar cluster, an administrator of Pulsar Manager can create tokens for the cluster.\n\nApache Pulsar Manager is no longer maintained and is completely unsupported. The Apache Pulsar PMC has retired it. There are no supported versions, and no further releases, fixes or security updates will be made for any version. These issues will not be fixed.\n\nUsing Pulsar Manager is not recommended. Users should stop using Pulsar Manager, remove existing deployments, and move to one of the alternatives described in the Administration UI documentation (https://pulsar.apache.org/docs/administration-ui). Users who have exposed Pulsar Manager configured with a Pulsar credential or token signing key should also consider replacing that credential or key.\n\nUntil a deployment is removed, users should not expose Pulsar Manager to untrusted networks, and should restrict network access to it to trusted administrators."
}
],
"metrics": [
{
"cvssV4_0": {
"Automatable": "NOT_DEFINED",
"Recovery": "NOT_DEFINED",
"Safety": "NOT_DEFINED",
"attackComplexity": "LOW",
"attackRequirements": "NONE",
"attackVector": "NETWORK",
"baseScore": 10,
"baseSeverity": "CRITICAL",
"exploitMaturity": "NOT_DEFINED",
"privilegesRequired": "NONE",
"providerUrgency": "NOT_DEFINED",
"subAvailabilityImpact": "HIGH",
"subConfidentialityImpact": "HIGH",
"subIntegrityImpact": "HIGH",
"userInteraction": "NONE",
"valueDensity": "NOT_DEFINED",
"vectorString": "CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:H/VI:H/VA:H/SC:H/SI:H/SA:H",
"version": "4.0",
"vulnAvailabilityImpact": "HIGH",
"vulnConfidentialityImpact": "HIGH",
"vulnIntegrityImpact": "HIGH",
"vulnerabilityResponseEffort": "NOT_DEFINED"
},
"format": "CVSS",
"scenarios": [
{
"lang": "en",
"value": "GENERAL"
}
]
}
],
"problemTypes": [
{
"descriptions": [
{
"cweId": "CWE-306",
"description": "CWE-306 Missing Authentication for Critical Function",
"lang": "en",
"type": "CWE"
}
]
}
],
"providerMetadata": {
"dateUpdated": "2026-10-21T18:17:37.844Z",
"orgId": "f0158376-9dc2-43b6-827c-5f631a4d8d09",
"shortName": "apache"
},
"references": [
{
"tags": [
"vendor-advisory"
],
"url": "https://pulsar.apache.org/security/CVE-2026-105944/"
},
{
"url": "https://pulsar.apache.org/docs/administration-ui"
},
{
"tags": [
"vendor-advisory"
],
"url": "https://lists.apache.org/thread.html/hol3z7fzhjntwvrv8xqqwx4l4d2jx796"
}
],
"source": {
"discovery": "EXTERNAL"
},
"title": "Apache Pulsar Manager: Missing authentication and authorization and disclosure of the Pulsar admin credential; end of life",
"x_generator": {
"engine": "Vulnogram 1.0.3"
}
}
},
"cveMetadata": {
"assignerOrgId": "f0158376-9dc2-43b6-827c-5f631a4d8d09",
"assignerShortName": "apache",
"cveId": "CVE-2026-105944",
"datePublished": "2026-10-21T18:17:37.844Z",
"dateReserved": "2026-10-06T07:06:42.319Z",
"dateUpdated": "2026-10-21T22:07:22.765Z",
"state": "PUBLISHED"
},
"dataType": "CVE_RECORD",
"dataVersion": "5.2"
}
CVE-2026-105942 (GCVE-0-2026-105942)
Vulnerability from nvd – Published: 2026-10-21 18:14 – Updated: 2026-10-21 18:14
VLAI
EPSS
VEX
Title
Apache Pulsar: Original principal of proxied requests authorized with the proxy's authentication data, allowing privilege escalation
Summary
When a configured proxy role sends a request to the broker on behalf of another user (the original principal), the broker is designed to authorize both the proxy role and the original principal and to allow the request only if both are authorized, so that the original principal cannot exceed its own permissions. Two flaws weakened this check.
First, the original principal was authorized with the proxy's authentication data instead of its own. On the admin REST API of the broker and the functions worker, this applied to every proxied request. On the Pulsar binary protocol, it applied when the proxy did not forward the client's credentials to the broker, which was the default of the Pulsar proxy in the affected versions. Authorization providers that resolve permissions from the role name only, such as the default authorization provider, are not affected by this flaw. The multi-role token authorization provider (MultiRolesTokenAuthorizationProvider), added in Apache Pulsar 2.8.1, resolves roles from the role claim of the token in the authentication data it is given. When a proxy authenticates to the broker with its own token, the original principal was therefore authorized with all roles in the proxy's token. If any of those roles is a superuser or tenant admin role, any user whose requests are forwarded by that proxy can perform operations that need those permissions without holding them. Custom authorization providers that use the authentication data could be affected in a similar way.
Second, independently of the authorization provider, the tenant admin check of a proxied admin REST API request succeeded without checking the original principal when the proxy role was itself an admin role of the tenant. In deployments where a proxy role is a tenant admin, including with the default authorization provider, any user whose requests are forwarded by that proxy could perform tenant administration operations on that tenant. This behavior is present from 2.8.4 in the 2.8.x releases, from 2.9.3 in the 2.9.x releases, and from 2.10.1 onwards.
Deployments that use neither the multi-role token authorization provider nor a custom provider that uses the authentication data are not affected by the first flaw, and with the multi-role token authorization provider, neither are deployments whose proxies do not authenticate to the broker with a token. Deployments in which no proxy role is listed as an admin role of a tenant are not affected by the second flaw. A proxy role that is a superuser but is not listed as a tenant admin does not trigger it, because the tenant admin check of the built-in authorization providers only considers the tenant's admin roles; this can differ for custom authorization providers that treat superusers as tenant admins.
In fixed versions, both the proxy role and the original principal are authorized for each proxied request, and the original principal is authorized only with its own authentication data. With the multi-role token authorization provider, the roles of a forwarded token are used for the original principal only when that token authenticates as the original principal; otherwise only the original principal's role name is used. For tenant admin checks, the proxy role and the original principal must each be a superuser or a tenant admin of the tenant.
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/.
Severity
CWE
- CWE-863 - Incorrect Authorization
Assigner
References
2 references
| URL | Tags |
|---|---|
| https://pulsar.apache.org/security/CVE-2026-105942/ | vendor-advisory |
| https://lists.apache.org/thread.html/4jmsbztr1fww… | vendor-advisory |
Impacted products
1 product
| Vendor | Product | Version | |
|---|---|---|---|
| Apache Software Foundation | Apache Pulsar |
Affected:
2.8.1 , < 4.0.14
(semver)
Affected: 4.1.0 , < 4.2.5 (semver) |
{
"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"
}
]
}
],
"descriptions": [
{
"lang": "en",
"supportingMedia": [
{
"base64": false,
"type": "text/html",
"value": "When a configured proxy role sends a request to the broker on behalf of another user (the original principal), the broker is designed to authorize both the proxy role and the original principal and to allow the request only if both are authorized, so that the original principal cannot exceed its own permissions. Two flaws weakened this check.\u003cbr\u003e\u003cbr\u003eFirst, the original principal was authorized with the proxy\u0027s authentication data instead of its own. On the admin REST API of the broker and the functions worker, this applied to every proxied request. On the Pulsar binary protocol, it applied when the proxy did not forward the client\u0027s credentials to the broker, which was the default of the Pulsar proxy in the affected versions. Authorization providers that resolve permissions from the role name only, such as the default authorization provider, are not affected by this flaw. The multi-role token authorization provider (MultiRolesTokenAuthorizationProvider), added in Apache Pulsar 2.8.1, resolves roles from the role claim of the token in the authentication data it is given. When a proxy authenticates to the broker with its own token, the original principal was therefore authorized with all roles in the proxy\u0027s token. If any of those roles is a superuser or tenant admin role, any user whose requests are forwarded by that proxy can perform operations that need those permissions without holding them. Custom authorization providers that use the authentication data could be affected in a similar way.\u003cbr\u003e\u003cbr\u003eSecond, independently of the authorization provider, the tenant admin check of a proxied admin REST API request succeeded without checking the original principal when the proxy role was itself an admin role of the tenant. In deployments where a proxy role is a tenant admin, including with the default authorization provider, any user whose requests are forwarded by that proxy could perform tenant administration operations on that tenant. This behavior is present from 2.8.4 in the 2.8.x releases, from 2.9.3 in the 2.9.x releases, and from 2.10.1 onwards.\u003cbr\u003e\u003cbr\u003eDeployments that use neither the multi-role token authorization provider nor a custom provider that uses the authentication data are not affected by the first flaw, and with the multi-role token authorization provider, neither are deployments whose proxies do not authenticate to the broker with a token. Deployments in which no proxy role is listed as an admin role of a tenant are not affected by the second flaw. A proxy role that is a superuser but is not listed as a tenant admin does not trigger it, because the tenant admin check of the built-in authorization providers only considers the tenant\u0027s admin roles; this can differ for custom authorization providers that treat superusers as tenant admins.\u003cbr\u003e\u003cbr\u003eIn fixed versions, both the proxy role and the original principal are authorized for each proxied request, and the original principal is authorized only with its own authentication data. With the multi-role token authorization provider, the roles of a forwarded token are used for the original principal only when that token authenticates as the original principal; otherwise only the original principal\u0027s role name is used. For tenant admin checks, the proxy role and the original principal must each be a superuser or a tenant admin of the tenant.\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/."
}
],
"value": "When a configured proxy role sends a request to the broker on behalf of another user (the original principal), the broker is designed to authorize both the proxy role and the original principal and to allow the request only if both are authorized, so that the original principal cannot exceed its own permissions. Two flaws weakened this check.\n\nFirst, the original principal was authorized with the proxy\u0027s authentication data instead of its own. On the admin REST API of the broker and the functions worker, this applied to every proxied request. On the Pulsar binary protocol, it applied when the proxy did not forward the client\u0027s credentials to the broker, which was the default of the Pulsar proxy in the affected versions. Authorization providers that resolve permissions from the role name only, such as the default authorization provider, are not affected by this flaw. The multi-role token authorization provider (MultiRolesTokenAuthorizationProvider), added in Apache Pulsar 2.8.1, resolves roles from the role claim of the token in the authentication data it is given. When a proxy authenticates to the broker with its own token, the original principal was therefore authorized with all roles in the proxy\u0027s token. If any of those roles is a superuser or tenant admin role, any user whose requests are forwarded by that proxy can perform operations that need those permissions without holding them. Custom authorization providers that use the authentication data could be affected in a similar way.\n\nSecond, independently of the authorization provider, the tenant admin check of a proxied admin REST API request succeeded without checking the original principal when the proxy role was itself an admin role of the tenant. In deployments where a proxy role is a tenant admin, including with the default authorization provider, any user whose requests are forwarded by that proxy could perform tenant administration operations on that tenant. This behavior is present from 2.8.4 in the 2.8.x releases, from 2.9.3 in the 2.9.x releases, and from 2.10.1 onwards.\n\nDeployments that use neither the multi-role token authorization provider nor a custom provider that uses the authentication data are not affected by the first flaw, and with the multi-role token authorization provider, neither are deployments whose proxies do not authenticate to the broker with a token. Deployments in which no proxy role is listed as an admin role of a tenant are not affected by the second flaw. A proxy role that is a superuser but is not listed as a tenant admin does not trigger it, because the tenant admin check of the built-in authorization providers only considers the tenant\u0027s admin roles; this can differ for custom authorization providers that treat superusers as tenant admins.\n\nIn fixed versions, both the proxy role and the original principal are authorized for each proxied request, and the original principal is authorized only with its own authentication data. With the multi-role token authorization provider, the roles of a forwarded token are used for the original principal only when that token authenticates as the original principal; otherwise only the original principal\u0027s role name is used. For tenant admin checks, the proxy role and the original principal must each be a superuser or a tenant admin of the tenant.\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/."
}
],
"metrics": [
{
"cvssV4_0": {
"Automatable": "NOT_DEFINED",
"Recovery": "NOT_DEFINED",
"Safety": "NOT_DEFINED",
"attackComplexity": "LOW",
"attackRequirements": "PRESENT",
"attackVector": "NETWORK",
"baseScore": 7.7,
"baseSeverity": "HIGH",
"exploitMaturity": "NOT_DEFINED",
"privilegesRequired": "LOW",
"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:L/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-863",
"description": "CWE-863 Incorrect Authorization",
"lang": "en",
"type": "CWE"
}
]
}
],
"providerMetadata": {
"dateUpdated": "2026-10-21T18:14:35.996Z",
"orgId": "f0158376-9dc2-43b6-827c-5f631a4d8d09",
"shortName": "apache"
},
"references": [
{
"tags": [
"vendor-advisory"
],
"url": "https://pulsar.apache.org/security/CVE-2026-105942/"
},
{
"tags": [
"vendor-advisory"
],
"url": "https://lists.apache.org/thread.html/4jmsbztr1fwws5fmxk36q5326wvjlwx4"
}
],
"source": {
"discovery": "INTERNAL"
},
"title": "Apache Pulsar: Original principal of proxied requests authorized with the proxy\u0027s authentication data, allowing privilege escalation",
"x_generator": {
"engine": "Vulnogram 1.0.3"
}
}
},
"cveMetadata": {
"assignerOrgId": "f0158376-9dc2-43b6-827c-5f631a4d8d09",
"assignerShortName": "apache",
"cveId": "CVE-2026-105942",
"datePublished": "2026-10-21T18:14:35.996Z",
"dateReserved": "2026-10-06T07:05:02.164Z",
"dateUpdated": "2026-10-21T18:14:35.996Z",
"state": "PUBLISHED"
},
"dataType": "CVE_RECORD",
"dataVersion": "5.2"
}
CVE-2026-105938 (GCVE-0-2026-105938)
Vulnerability from nvd – Published: 2026-10-21 18:13 – Updated: 2026-10-21 18:13
VLAI
EPSS
VEX
Title
Apache Pulsar: Subscription authorization policies not enforced by namespace-level backlog and unsubscribe operations and by topic expire-all
Summary
Apache Pulsar namespaces can restrict which roles may use a subscription, either with the Prefix subscription authentication mode, which requires a subscription name to start with the role name, or by granting permission on a subscription to specific roles. Topic-level subscription operations, such as consuming, skipping messages, resetting a cursor or deleting a subscription, apply these subscription policies. Several admin REST API operations that act on subscriptions did not apply them:
- the namespace-level and bundle-level clear backlog operations, both for a named subscription and for all subscriptions;
- the namespace-level and bundle-level unsubscribe operations;
- the topic-level operation that expires messages for all subscriptions of a topic.
With the default authorization provider, the namespace-level operations require only consume permission granted on the namespace, and the expire-all operation requires only consume permission on the topic. As a result, when authentication and authorization are enabled and a namespace uses the Prefix subscription authentication mode or subscription permissions, an authenticated user with such consume permission can clear the backlog of, expire messages of, or delete a subscription that the policies would deny to that user. Tenant admin or superuser access is not required. The clear backlog operations can also be applied to the cursors used for geo-replication, so that messages not yet replicated to a remote cluster are skipped. Deployments that do not configure the Prefix subscription authentication mode or subscription permissions (the defaults) are not affected by this bypass, because consume permission on the namespace or topic already allows these operations there. This impact analysis assumes that Pulsar has been configured with the default authorization provider. For custom authorization providers, the impact could be different.
The impact is on the integrity of subscription state. Clearing or expiring the backlog moves the subscription's cursor forward, so unacknowledged messages are no longer delivered to the subscription's consumers. The unsubscribe operation deletes a subscription that has no connected consumers. Skipped messages can be permanently deleted once no other subscription or the namespace's retention policy keeps them. The issue does not allow reading message contents, changing permissions or policies, or accessing other namespaces, and it does not affect the availability of the broker.
In fixed versions, the namespace-level and bundle-level operations for a named subscription apply the subscription policies to that subscription, and the operations for all subscriptions, when requested by a user who is not a tenant admin or superuser, only act on the subscriptions that the user may access. Clearing the backlog of geo-replication cursors requires tenant admin or superuser access. Topic-level subscription operations apply the subscription policies for all types of authentication data, including that of the anonymous user role.
This issue affects Apache Pulsar versions from 2.8.0 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.
All brokers in a cluster must be upgraded before relying on the namespace-level restrictions, because brokers that have not been upgraded do not apply them when they receive the internal per-bundle requests.
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 reduce exposure by restricting network access to the broker's admin REST API to trusted administrative clients.
Severity
CWE
- CWE-863 - Incorrect Authorization
Assigner
References
2 references
| URL | Tags |
|---|---|
| https://pulsar.apache.org/security/CVE-2026-105938/ | vendor-advisory |
| https://lists.apache.org/thread.html/zhc6wjydybdd… | vendor-advisory |
Impacted products
1 product
| Vendor | Product | Version | |
|---|---|---|---|
| Apache Software Foundation | Apache Pulsar |
Affected:
2.8.0 , < 4.0.14
(semver)
Affected: 4.1.0 , < 4.2.5 (semver) |
{
"containers": {
"cna": {
"affected": [
{
"defaultStatus": "unaffected",
"product": "Apache Pulsar",
"vendor": "Apache Software Foundation",
"versions": [
{
"lessThan": "4.0.14",
"status": "affected",
"version": "2.8.0",
"versionType": "semver"
},
{
"lessThan": "4.2.5",
"status": "affected",
"version": "4.1.0",
"versionType": "semver"
}
]
}
],
"credits": [
{
"lang": "en",
"type": "finder",
"value": "Omar Mousa"
}
],
"descriptions": [
{
"lang": "en",
"supportingMedia": [
{
"base64": false,
"type": "text/html",
"value": "Apache Pulsar namespaces can restrict which roles may use a subscription, either with the Prefix subscription authentication mode, which requires a subscription name to start with the role name, or by granting permission on a subscription to specific roles. Topic-level subscription operations, such as consuming, skipping messages, resetting a cursor or deleting a subscription, apply these subscription policies. Several admin REST API operations that act on subscriptions did not apply them:\u003cbr\u003e\u003cbr\u003e- the namespace-level and bundle-level clear backlog operations, both for a named subscription and for all subscriptions;\u003cbr\u003e- the namespace-level and bundle-level unsubscribe operations;\u003cbr\u003e- the topic-level operation that expires messages for all subscriptions of a topic.\u003cbr\u003e\u003cbr\u003eWith the default authorization provider, the namespace-level operations require only consume permission granted on the namespace, and the expire-all operation requires only consume permission on the topic. As a result, when authentication and authorization are enabled and a namespace uses the Prefix subscription authentication mode or subscription permissions, an authenticated user with such consume permission can clear the backlog of, expire messages of, or delete a subscription that the policies would deny to that user. Tenant admin or superuser access is not required. The clear backlog operations can also be applied to the cursors used for geo-replication, so that messages not yet replicated to a remote cluster are skipped. Deployments that do not configure the Prefix subscription authentication mode or subscription permissions (the defaults) are not affected by this bypass, because consume permission on the namespace or topic already allows these operations there. This impact analysis assumes that Pulsar has been configured with the default authorization provider. For custom authorization providers, the impact could be different.\u003cbr\u003e\u003cbr\u003eThe impact is on the integrity of subscription state. Clearing or expiring the backlog moves the subscription\u0027s cursor forward, so unacknowledged messages are no longer delivered to the subscription\u0027s consumers. The unsubscribe operation deletes a subscription that has no connected consumers. Skipped messages can be permanently deleted once no other subscription or the namespace\u0027s retention policy keeps them. The issue does not allow reading message contents, changing permissions or policies, or accessing other namespaces, and it does not affect the availability of the broker.\u003cbr\u003e\u003cbr\u003eIn fixed versions, the namespace-level and bundle-level operations for a named subscription apply the subscription policies to that subscription, and the operations for all subscriptions, when requested by a user who is not a tenant admin or superuser, only act on the subscriptions that the user may access. Clearing the backlog of geo-replication cursors requires tenant admin or superuser access. Topic-level subscription operations apply the subscription policies for all types of authentication data, including that of the anonymous user role.\u003cbr\u003e\u003cbr\u003eThis issue affects Apache Pulsar versions from 2.8.0 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\u003eAll brokers in a cluster must be upgraded before relying on the namespace-level restrictions, because brokers that have not been upgraded do not apply them when they receive the internal per-bundle requests.\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 reduce exposure by restricting network access to the broker\u0027s admin REST API to trusted administrative clients."
}
],
"value": "Apache Pulsar namespaces can restrict which roles may use a subscription, either with the Prefix subscription authentication mode, which requires a subscription name to start with the role name, or by granting permission on a subscription to specific roles. Topic-level subscription operations, such as consuming, skipping messages, resetting a cursor or deleting a subscription, apply these subscription policies. Several admin REST API operations that act on subscriptions did not apply them:\n\n- the namespace-level and bundle-level clear backlog operations, both for a named subscription and for all subscriptions;\n- the namespace-level and bundle-level unsubscribe operations;\n- the topic-level operation that expires messages for all subscriptions of a topic.\n\nWith the default authorization provider, the namespace-level operations require only consume permission granted on the namespace, and the expire-all operation requires only consume permission on the topic. As a result, when authentication and authorization are enabled and a namespace uses the Prefix subscription authentication mode or subscription permissions, an authenticated user with such consume permission can clear the backlog of, expire messages of, or delete a subscription that the policies would deny to that user. Tenant admin or superuser access is not required. The clear backlog operations can also be applied to the cursors used for geo-replication, so that messages not yet replicated to a remote cluster are skipped. Deployments that do not configure the Prefix subscription authentication mode or subscription permissions (the defaults) are not affected by this bypass, because consume permission on the namespace or topic already allows these operations there. This impact analysis assumes that Pulsar has been configured with the default authorization provider. For custom authorization providers, the impact could be different.\n\nThe impact is on the integrity of subscription state. Clearing or expiring the backlog moves the subscription\u0027s cursor forward, so unacknowledged messages are no longer delivered to the subscription\u0027s consumers. The unsubscribe operation deletes a subscription that has no connected consumers. Skipped messages can be permanently deleted once no other subscription or the namespace\u0027s retention policy keeps them. The issue does not allow reading message contents, changing permissions or policies, or accessing other namespaces, and it does not affect the availability of the broker.\n\nIn fixed versions, the namespace-level and bundle-level operations for a named subscription apply the subscription policies to that subscription, and the operations for all subscriptions, when requested by a user who is not a tenant admin or superuser, only act on the subscriptions that the user may access. Clearing the backlog of geo-replication cursors requires tenant admin or superuser access. Topic-level subscription operations apply the subscription policies for all types of authentication data, including that of the anonymous user role.\n\nThis issue affects Apache Pulsar versions from 2.8.0 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\nAll brokers in a cluster must be upgraded before relying on the namespace-level restrictions, because brokers that have not been upgraded do not apply them when they receive the internal per-bundle requests.\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 reduce exposure by restricting network access to the broker\u0027s admin REST API to trusted administrative clients."
}
],
"metrics": [
{
"cvssV4_0": {
"Automatable": "NOT_DEFINED",
"Recovery": "NOT_DEFINED",
"Safety": "NOT_DEFINED",
"attackComplexity": "LOW",
"attackRequirements": "PRESENT",
"attackVector": "NETWORK",
"baseScore": 2.3,
"baseSeverity": "LOW",
"exploitMaturity": "NOT_DEFINED",
"privilegesRequired": "LOW",
"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:L/UI:N/VC:N/VI:L/VA:N/SC:N/SI:N/SA:N",
"version": "4.0",
"vulnAvailabilityImpact": "NONE",
"vulnConfidentialityImpact": "NONE",
"vulnIntegrityImpact": "LOW",
"vulnerabilityResponseEffort": "NOT_DEFINED"
},
"format": "CVSS",
"scenarios": [
{
"lang": "en",
"value": "GENERAL"
}
]
}
],
"problemTypes": [
{
"descriptions": [
{
"cweId": "CWE-863",
"description": "CWE-863 Incorrect Authorization",
"lang": "en",
"type": "CWE"
}
]
}
],
"providerMetadata": {
"dateUpdated": "2026-10-21T18:13:35.337Z",
"orgId": "f0158376-9dc2-43b6-827c-5f631a4d8d09",
"shortName": "apache"
},
"references": [
{
"tags": [
"vendor-advisory"
],
"url": "https://pulsar.apache.org/security/CVE-2026-105938/"
},
{
"tags": [
"vendor-advisory"
],
"url": "https://lists.apache.org/thread.html/zhc6wjydybdd1msnlcxmmbg8oj0kjmog"
}
],
"source": {
"discovery": "EXTERNAL"
},
"title": "Apache Pulsar: Subscription authorization policies not enforced by namespace-level backlog and unsubscribe operations and by topic expire-all",
"x_generator": {
"engine": "Vulnogram 1.0.3"
}
}
},
"cveMetadata": {
"assignerOrgId": "f0158376-9dc2-43b6-827c-5f631a4d8d09",
"assignerShortName": "apache",
"cveId": "CVE-2026-105938",
"datePublished": "2026-10-21T18:13:35.337Z",
"dateReserved": "2026-10-06T06:46:23.816Z",
"dateUpdated": "2026-10-21T18:13:35.337Z",
"state": "PUBLISHED"
},
"dataType": "CVE_RECORD",
"dataVersion": "5.2"
}
CVE-2026-105937 (GCVE-0-2026-105937)
Vulnerability from nvd – Published: 2026-10-21 18:12 – Updated: 2026-10-21 18:12
VLAI
EPSS
VEX
Title
Apache Pulsar: Missing authorization of the shadow topic source allows cross-tenant message disclosure and deletion of source topic data
Summary
Apache Pulsar shadow topics (PIP-180) are topics that read the stored messages of a source topic from that topic's managed ledger. The source topic is selected by setting the reserved topic property PULSAR.SHADOW_SOURCE. The admin REST API accepts this property when creating a non-partitioned or partitioned topic and when updating the properties of an existing topic. On these paths the broker authorizes the caller only against the topic being created or updated. It does not authorize the caller against the source topic named in the property. The existing authorization for shadow topic configuration (the SHADOW_TOPIC topic policy on the source topic) is applied only to the source-side shadow topics admin API, not to these paths.
As a result, an authenticated user who is allowed to create topics or update topic properties in one tenant can bind a topic in that tenant to a persistent topic in any other tenant. With the default authorization provider, these operations require the tenant admin role for the user's own tenant. The user does not need any permission on the source topic, its namespace or its tenant. This impact analysis assumes that Pulsar has been configured with the default authorization provider. For custom authorization providers, the impact could be different.
The user can then consume from the shadow topic, using only permissions on their own topic, and receive retained messages that were published to the source topic in the other tenant. Exposure is limited to messages that are still retained and readable in the source topic's ledgers; messages protected with client-side end-to-end encryption cannot be decrypted without the encryption keys. A producer on the shadow topic can also register a new schema version under the source topic's schema, subject to the schema compatibility settings; existing schema versions are not replaced.
In addition, the shadow topic's managed ledger applies its own retention, trimming, offloading and deletion to the source topic's ledgers. This can permanently delete the source topic's ledger data from BookKeeper and from tiered storage, regardless of the source topic's own subscriptions and retention policy, including messages that have not yet been acknowledged. Deleting the shadow topic can also delete the source topic's ledgers. This data loss can also affect shadow topics that were configured intentionally by administrators.
This issue affects Apache Pulsar versions from 3.0.0 before 4.0.14 and from 4.1.0 before 4.2.5. Apache Pulsar 2.x releases do not contain the shadow topic implementation.
- 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/.
In the fixed versions, shadow topics are disabled by default and are controlled by the new broker configuration setting enableShadowTopics (default false). While it is disabled, the broker rejects creating shadow topics, setting the PULSAR.SHADOW_SOURCE property, and loading or replicating to existing shadow topics. Deployments that use shadow topics must set enableShadowTopics=true in the broker configuration of all brokers after upgrading; otherwise existing shadow topics will not be loaded. When shadow topics are enabled, binding a shadow topic to a source topic in a different tenant requires the superuser role. The fixed versions also prevent a shadow topic from deleting or trimming the ledgers and offloaded data of its source topic.
Affected versions provide no configuration option to disable shadow topics. Users who cannot upgrade immediately can reduce exposure by granting the tenant admin role only to trusted principals.
Severity
CWE
- CWE-862 - Missing Authorization
Assigner
References
2 references
| URL | Tags |
|---|---|
| https://pulsar.apache.org/security/CVE-2026-105937/ | vendor-advisory |
| https://lists.apache.org/thread.html/80foc311bwn8… | vendor-advisory |
Impacted products
1 product
| Vendor | Product | Version | |
|---|---|---|---|
| Apache Software Foundation | Apache Pulsar |
Affected:
3.0.0 , < 4.0.14
(semver)
Affected: 4.1.0 , < 4.2.5 (semver) |
{
"containers": {
"cna": {
"affected": [
{
"defaultStatus": "unaffected",
"product": "Apache Pulsar",
"vendor": "Apache Software Foundation",
"versions": [
{
"lessThan": "4.0.14",
"status": "affected",
"version": "3.0.0",
"versionType": "semver"
},
{
"lessThan": "4.2.5",
"status": "affected",
"version": "4.1.0",
"versionType": "semver"
}
]
}
],
"credits": [
{
"lang": "en",
"type": "finder",
"value": "Elias Hasas"
},
{
"lang": "en",
"type": "finder",
"value": "Mike Read"
},
{
"lang": "en",
"type": "finder",
"value": "Omar Mousa"
}
],
"descriptions": [
{
"lang": "en",
"supportingMedia": [
{
"base64": false,
"type": "text/html",
"value": "Apache Pulsar shadow topics (PIP-180) are topics that read the stored messages of a source topic from that topic\u0027s managed ledger. The source topic is selected by setting the reserved topic property PULSAR.SHADOW_SOURCE. The admin REST API accepts this property when creating a non-partitioned or partitioned topic and when updating the properties of an existing topic. On these paths the broker authorizes the caller only against the topic being created or updated. It does not authorize the caller against the source topic named in the property. The existing authorization for shadow topic configuration (the SHADOW_TOPIC topic policy on the source topic) is applied only to the source-side shadow topics admin API, not to these paths.\u003cbr\u003e\u003cbr\u003eAs a result, an authenticated user who is allowed to create topics or update topic properties in one tenant can bind a topic in that tenant to a persistent topic in any other tenant. With the default authorization provider, these operations require the tenant admin role for the user\u0027s own tenant. The user does not need any permission on the source topic, its namespace or its tenant. This impact analysis assumes that Pulsar has been configured with the default authorization provider. For custom authorization providers, the impact could be different.\u003cbr\u003e\u003cbr\u003eThe user can then consume from the shadow topic, using only permissions on their own topic, and receive retained messages that were published to the source topic in the other tenant. Exposure is limited to messages that are still retained and readable in the source topic\u0027s ledgers; messages protected with client-side end-to-end encryption cannot be decrypted without the encryption keys. A producer on the shadow topic can also register a new schema version under the source topic\u0027s schema, subject to the schema compatibility settings; existing schema versions are not replaced.\u003cbr\u003e\u003cbr\u003eIn addition, the shadow topic\u0027s managed ledger applies its own retention, trimming, offloading and deletion to the source topic\u0027s ledgers. This can permanently delete the source topic\u0027s ledger data from BookKeeper and from tiered storage, regardless of the source topic\u0027s own subscriptions and retention policy, including messages that have not yet been acknowledged. Deleting the shadow topic can also delete the source topic\u0027s ledgers. This data loss can also affect shadow topics that were configured intentionally by administrators.\u003cbr\u003e\u003cbr\u003eThis issue affects Apache Pulsar versions from 3.0.0 before 4.0.14 and from 4.1.0 before 4.2.5. Apache Pulsar 2.x releases do not contain the shadow topic implementation.\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\u003eIn the fixed versions, shadow topics are disabled by default and are controlled by the new broker configuration setting enableShadowTopics (default false). While it is disabled, the broker rejects creating shadow topics, setting the PULSAR.SHADOW_SOURCE property, and loading or replicating to existing shadow topics. Deployments that use shadow topics must set enableShadowTopics=true in the broker configuration of all brokers after upgrading; otherwise existing shadow topics will not be loaded. When shadow topics are enabled, binding a shadow topic to a source topic in a different tenant requires the superuser role. The fixed versions also prevent a shadow topic from deleting or trimming the ledgers and offloaded data of its source topic.\u003cbr\u003e\u003cbr\u003eAffected versions provide no configuration option to disable shadow topics. Users who cannot upgrade immediately can reduce exposure by granting the tenant admin role only to trusted principals."
}
],
"value": "Apache Pulsar shadow topics (PIP-180) are topics that read the stored messages of a source topic from that topic\u0027s managed ledger. The source topic is selected by setting the reserved topic property PULSAR.SHADOW_SOURCE. The admin REST API accepts this property when creating a non-partitioned or partitioned topic and when updating the properties of an existing topic. On these paths the broker authorizes the caller only against the topic being created or updated. It does not authorize the caller against the source topic named in the property. The existing authorization for shadow topic configuration (the SHADOW_TOPIC topic policy on the source topic) is applied only to the source-side shadow topics admin API, not to these paths.\n\nAs a result, an authenticated user who is allowed to create topics or update topic properties in one tenant can bind a topic in that tenant to a persistent topic in any other tenant. With the default authorization provider, these operations require the tenant admin role for the user\u0027s own tenant. The user does not need any permission on the source topic, its namespace or its tenant. This impact analysis assumes that Pulsar has been configured with the default authorization provider. For custom authorization providers, the impact could be different.\n\nThe user can then consume from the shadow topic, using only permissions on their own topic, and receive retained messages that were published to the source topic in the other tenant. Exposure is limited to messages that are still retained and readable in the source topic\u0027s ledgers; messages protected with client-side end-to-end encryption cannot be decrypted without the encryption keys. A producer on the shadow topic can also register a new schema version under the source topic\u0027s schema, subject to the schema compatibility settings; existing schema versions are not replaced.\n\nIn addition, the shadow topic\u0027s managed ledger applies its own retention, trimming, offloading and deletion to the source topic\u0027s ledgers. This can permanently delete the source topic\u0027s ledger data from BookKeeper and from tiered storage, regardless of the source topic\u0027s own subscriptions and retention policy, including messages that have not yet been acknowledged. Deleting the shadow topic can also delete the source topic\u0027s ledgers. This data loss can also affect shadow topics that were configured intentionally by administrators.\n\nThis issue affects Apache Pulsar versions from 3.0.0 before 4.0.14 and from 4.1.0 before 4.2.5. Apache Pulsar 2.x releases do not contain the shadow topic implementation.\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\nIn the fixed versions, shadow topics are disabled by default and are controlled by the new broker configuration setting enableShadowTopics (default false). While it is disabled, the broker rejects creating shadow topics, setting the PULSAR.SHADOW_SOURCE property, and loading or replicating to existing shadow topics. Deployments that use shadow topics must set enableShadowTopics=true in the broker configuration of all brokers after upgrading; otherwise existing shadow topics will not be loaded. When shadow topics are enabled, binding a shadow topic to a source topic in a different tenant requires the superuser role. The fixed versions also prevent a shadow topic from deleting or trimming the ledgers and offloaded data of its source topic.\n\nAffected versions provide no configuration option to disable shadow topics. Users who cannot upgrade immediately can reduce exposure by granting the tenant admin role only to trusted principals."
}
],
"metrics": [
{
"cvssV4_0": {
"Automatable": "NOT_DEFINED",
"Recovery": "NOT_DEFINED",
"Safety": "NOT_DEFINED",
"attackComplexity": "LOW",
"attackRequirements": "NONE",
"attackVector": "NETWORK",
"baseScore": 8.7,
"baseSeverity": "HIGH",
"exploitMaturity": "NOT_DEFINED",
"privilegesRequired": "LOW",
"providerUrgency": "NOT_DEFINED",
"subAvailabilityImpact": "NONE",
"subConfidentialityImpact": "NONE",
"subIntegrityImpact": "NONE",
"userInteraction": "NONE",
"valueDensity": "NOT_DEFINED",
"vectorString": "CVSS:4.0/AV:N/AC:L/AT:N/PR:L/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-862",
"description": "CWE-862 Missing Authorization",
"lang": "en",
"type": "CWE"
}
]
}
],
"providerMetadata": {
"dateUpdated": "2026-10-21T18:12:51.420Z",
"orgId": "f0158376-9dc2-43b6-827c-5f631a4d8d09",
"shortName": "apache"
},
"references": [
{
"tags": [
"vendor-advisory"
],
"url": "https://pulsar.apache.org/security/CVE-2026-105937/"
},
{
"tags": [
"vendor-advisory"
],
"url": "https://lists.apache.org/thread.html/80foc311bwn839skc1p7fh89pgsrhyoj"
}
],
"source": {
"discovery": "EXTERNAL"
},
"title": "Apache Pulsar: Missing authorization of the shadow topic source allows cross-tenant message disclosure and deletion of source topic data",
"x_generator": {
"engine": "Vulnogram 1.0.3"
}
}
},
"cveMetadata": {
"assignerOrgId": "f0158376-9dc2-43b6-827c-5f631a4d8d09",
"assignerShortName": "apache",
"cveId": "CVE-2026-105937",
"datePublished": "2026-10-21T18:12:51.420Z",
"dateReserved": "2026-10-06T06:45:39.018Z",
"dateUpdated": "2026-10-21T18:12:51.420Z",
"state": "PUBLISHED"
},
"dataType": "CVE_RECORD",
"dataVersion": "5.2"
}
CVE-2026-105936 (GCVE-0-2026-105936)
Vulnerability from nvd – Published: 2026-10-21 18:11 – Updated: 2026-10-21 18:11
VLAI
EPSS
VEX
Title
Apache Pulsar: Functions connectors list endpoint does not apply the super-user check of the worker connectors endpoint
Summary
The Pulsar Functions worker REST API provides two endpoints that return the catalog of Pulsar IO connectors installed on the functions worker: the worker connectors endpoint (/admin/v2/worker/connectors) and the deprecated functions connectors endpoint (/admin/v2/functions/connectors and /admin/v3/functions/connectors). When authorization is enabled, the worker connectors endpoint requires super-user access. The functions connectors endpoint, served both by the functions worker and by a broker running the functions worker, returns the same catalog without this check.
As a result, when authentication and authorization are enabled, any authenticated client can read the connector catalog through the functions connectors endpoint, regardless of the permissions granted to its role and without super-user access. Unauthenticated requests are rejected unless anonymous access is configured with an anonymous user role.
The catalog contains the connector type definitions installed in the functions worker's connectors directory: the connector name, its description, and the source, sink and configuration class names. It does not contain configured source or sink instances, their configuration values or credentials, and an installed connector type does not indicate that a connector is configured or running. The impact is limited to disclosure of this metadata, which can include the names and descriptions of custom connectors installed by the operator. The issue does not allow modifying the catalog or managing connectors. Connector definitions that have a source or sink class are also returned by the built-in sources and sinks endpoints to authenticated clients.
In fixed versions, the functions connectors endpoint applies the same checks as the worker connectors endpoint, so that it requires super-user access when authorization is enabled. Clients that are not super-users can use the built-in sources and sinks endpoints to list the available connector types.
This issue affects Apache Pulsar versions from 2.4.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/.
Severity
CWE
- CWE-862 - Missing Authorization
Assigner
References
2 references
| URL | Tags |
|---|---|
| https://pulsar.apache.org/security/CVE-2026-105936/ | vendor-advisory |
| https://lists.apache.org/thread.html/dn0cg4l3yolw… | vendor-advisory |
Impacted products
1 product
| Vendor | Product | Version | |
|---|---|---|---|
| Apache Software Foundation | Apache Pulsar |
Affected:
2.4.1 , < 4.0.14
(semver)
Affected: 4.1.0 , < 4.2.5 (semver) |
{
"containers": {
"cna": {
"affected": [
{
"defaultStatus": "unaffected",
"product": "Apache Pulsar",
"vendor": "Apache Software Foundation",
"versions": [
{
"lessThan": "4.0.14",
"status": "affected",
"version": "2.4.1",
"versionType": "semver"
},
{
"lessThan": "4.2.5",
"status": "affected",
"version": "4.1.0",
"versionType": "semver"
}
]
}
],
"credits": [
{
"lang": "en",
"type": "finder",
"value": "Mingsheng Lin of Institute of Information Engineering, CAS"
},
{
"lang": "en",
"type": "finder",
"value": "Xingchen Chen of Institute of Information Engineering, CAS"
},
{
"lang": "en",
"type": "finder",
"value": "Qixu Liu of Institute of Information Engineering, CAS"
}
],
"descriptions": [
{
"lang": "en",
"supportingMedia": [
{
"base64": false,
"type": "text/html",
"value": "The Pulsar Functions worker REST API provides two endpoints that return the catalog of Pulsar IO connectors installed on the functions worker: the worker connectors endpoint (/admin/v2/worker/connectors) and the deprecated functions connectors endpoint (/admin/v2/functions/connectors and /admin/v3/functions/connectors). When authorization is enabled, the worker connectors endpoint requires super-user access. The functions connectors endpoint, served both by the functions worker and by a broker running the functions worker, returns the same catalog without this check.\u003cbr\u003e\u003cbr\u003eAs a result, when authentication and authorization are enabled, any authenticated client can read the connector catalog through the functions connectors endpoint, regardless of the permissions granted to its role and without super-user access. Unauthenticated requests are rejected unless anonymous access is configured with an anonymous user role.\u003cbr\u003e\u003cbr\u003eThe catalog contains the connector type definitions installed in the functions worker\u0027s connectors directory: the connector name, its description, and the source, sink and configuration class names. It does not contain configured source or sink instances, their configuration values or credentials, and an installed connector type does not indicate that a connector is configured or running. The impact is limited to disclosure of this metadata, which can include the names and descriptions of custom connectors installed by the operator. The issue does not allow modifying the catalog or managing connectors. Connector definitions that have a source or sink class are also returned by the built-in sources and sinks endpoints to authenticated clients.\u003cbr\u003e\u003cbr\u003eIn fixed versions, the functions connectors endpoint applies the same checks as the worker connectors endpoint, so that it requires super-user access when authorization is enabled. Clients that are not super-users can use the built-in sources and sinks endpoints to list the available connector types.\u003cbr\u003e\u003cbr\u003eThis issue affects Apache Pulsar versions from 2.4.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/."
}
],
"value": "The Pulsar Functions worker REST API provides two endpoints that return the catalog of Pulsar IO connectors installed on the functions worker: the worker connectors endpoint (/admin/v2/worker/connectors) and the deprecated functions connectors endpoint (/admin/v2/functions/connectors and /admin/v3/functions/connectors). When authorization is enabled, the worker connectors endpoint requires super-user access. The functions connectors endpoint, served both by the functions worker and by a broker running the functions worker, returns the same catalog without this check.\n\nAs a result, when authentication and authorization are enabled, any authenticated client can read the connector catalog through the functions connectors endpoint, regardless of the permissions granted to its role and without super-user access. Unauthenticated requests are rejected unless anonymous access is configured with an anonymous user role.\n\nThe catalog contains the connector type definitions installed in the functions worker\u0027s connectors directory: the connector name, its description, and the source, sink and configuration class names. It does not contain configured source or sink instances, their configuration values or credentials, and an installed connector type does not indicate that a connector is configured or running. The impact is limited to disclosure of this metadata, which can include the names and descriptions of custom connectors installed by the operator. The issue does not allow modifying the catalog or managing connectors. Connector definitions that have a source or sink class are also returned by the built-in sources and sinks endpoints to authenticated clients.\n\nIn fixed versions, the functions connectors endpoint applies the same checks as the worker connectors endpoint, so that it requires super-user access when authorization is enabled. Clients that are not super-users can use the built-in sources and sinks endpoints to list the available connector types.\n\nThis issue affects Apache Pulsar versions from 2.4.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/."
}
],
"metrics": [
{
"cvssV4_0": {
"Automatable": "NOT_DEFINED",
"Recovery": "NOT_DEFINED",
"Safety": "NOT_DEFINED",
"attackComplexity": "LOW",
"attackRequirements": "NONE",
"attackVector": "NETWORK",
"baseScore": 5.3,
"baseSeverity": "MEDIUM",
"exploitMaturity": "NOT_DEFINED",
"privilegesRequired": "LOW",
"providerUrgency": "NOT_DEFINED",
"subAvailabilityImpact": "NONE",
"subConfidentialityImpact": "NONE",
"subIntegrityImpact": "NONE",
"userInteraction": "NONE",
"valueDensity": "NOT_DEFINED",
"vectorString": "CVSS:4.0/AV:N/AC:L/AT:N/PR:L/UI:N/VC:L/VI:N/VA:N/SC:N/SI:N/SA:N",
"version": "4.0",
"vulnAvailabilityImpact": "NONE",
"vulnConfidentialityImpact": "LOW",
"vulnIntegrityImpact": "NONE",
"vulnerabilityResponseEffort": "NOT_DEFINED"
},
"format": "CVSS",
"scenarios": [
{
"lang": "en",
"value": "GENERAL"
}
]
}
],
"problemTypes": [
{
"descriptions": [
{
"cweId": "CWE-862",
"description": "CWE-862 Missing Authorization",
"lang": "en",
"type": "CWE"
}
]
}
],
"providerMetadata": {
"dateUpdated": "2026-10-21T18:11:20.520Z",
"orgId": "f0158376-9dc2-43b6-827c-5f631a4d8d09",
"shortName": "apache"
},
"references": [
{
"tags": [
"vendor-advisory"
],
"url": "https://pulsar.apache.org/security/CVE-2026-105936/"
},
{
"tags": [
"vendor-advisory"
],
"url": "https://lists.apache.org/thread.html/dn0cg4l3yolw90f8rjyvv4dl7k340jkz"
}
],
"source": {
"discovery": "EXTERNAL"
},
"title": "Apache Pulsar: Functions connectors list endpoint does not apply the super-user check of the worker connectors endpoint",
"x_generator": {
"engine": "Vulnogram 1.0.3"
}
}
},
"cveMetadata": {
"assignerOrgId": "f0158376-9dc2-43b6-827c-5f631a4d8d09",
"assignerShortName": "apache",
"cveId": "CVE-2026-105936",
"datePublished": "2026-10-21T18:11:20.520Z",
"dateReserved": "2026-10-06T06:44:47.654Z",
"dateUpdated": "2026-10-21T18:11:20.520Z",
"state": "PUBLISHED"
},
"dataType": "CVE_RECORD",
"dataVersion": "5.2"
}
CVE-2026-105935 (GCVE-0-2026-105935)
Vulnerability from nvd – Published: 2026-10-21 18:10 – Updated: 2026-10-21 18:10
VLAI
EPSS
VEX
Title
Apache Pulsar: Function trigger publishes to the input topic without checking the caller's produce permission
Summary
The Pulsar Functions Worker provides a REST API endpoint for triggering a function, which publishes a caller-supplied value to one of the function's configured input topics. The Functions Worker performs this publish with its own broker client, which authenticates with the Worker's configured broker-client credentials rather than the credentials of the API caller.
When authorization is enabled, in Apache Pulsar 2.4.0 and later versions, the trigger endpoint checks only that the caller is authorized to perform function operations in the function's namespace. It does not check that the caller is authorized to produce to the input topic that the message is published to. Versions before 2.4.0 do not perform a caller authorization check for the trigger endpoint at all. Function input topics are not restricted to the function's own tenant or namespace, and registering a function does not require produce permission on its input topics.
As a result, an authenticated user who is authorized to manage functions in a namespace, for example a role granted the functions permission on that namespace, can cause the Functions Worker to publish messages with caller-controlled content to a topic that the user is not authorized to produce to, including topics in other tenants. These messages are published under the identity of the Functions Worker. The issue does not require any function instance to be running or any function code to be executed. It requires that the Functions Worker's broker-client identity is itself authorized to produce to the target topic and, in Apache Pulsar 2.3.0 and later versions, to list the subscriptions of the target topic, as is the case when that identity is a superuser. The impact is on the integrity of the data in the affected topics: consumers of those topics may receive messages from a user who is not permitted to publish them. This concerns the Functions Worker REST API as called by an external, authenticated client; it does not change the security model for function code, which must be fully trusted.
In fixed versions, when authorization is enabled, triggering a function additionally requires the caller to be authorized to produce to the selected input topic before any message is published.
This issue affects Apache Pulsar versions from 2.0.0-rc1-incubating 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 of Apache Pulsar 2.4.0 and later versions with authorization enabled who cannot upgrade immediately can limit the permission to manage functions to trusted roles. Users of versions before 2.4.0 should restrict access to the Functions Worker REST API to trusted callers, because in these versions the trigger endpoint does not check the caller's permission to manage functions.
Severity
CWE
- CWE-862 - Missing Authorization
Assigner
References
2 references
| URL | Tags |
|---|---|
| https://pulsar.apache.org/security/CVE-2026-105935/ | vendor-advisory |
| https://lists.apache.org/thread.html/nrk7hkyzgo44… | vendor-advisory |
Impacted products
1 product
| Vendor | Product | Version | |
|---|---|---|---|
| Apache Software Foundation | Apache Pulsar |
Affected:
2.0.0-rc1-incubating , < 4.0.14
(semver)
Affected: 4.1.0 , < 4.2.5 (semver) |
{
"containers": {
"cna": {
"affected": [
{
"defaultStatus": "unaffected",
"product": "Apache Pulsar",
"vendor": "Apache Software Foundation",
"versions": [
{
"lessThan": "4.0.14",
"status": "affected",
"version": "2.0.0-rc1-incubating",
"versionType": "semver"
},
{
"lessThan": "4.2.5",
"status": "affected",
"version": "4.1.0",
"versionType": "semver"
}
]
}
],
"credits": [
{
"lang": "en",
"type": "finder",
"value": "Omar Mousa"
}
],
"descriptions": [
{
"lang": "en",
"supportingMedia": [
{
"base64": false,
"type": "text/html",
"value": "The Pulsar Functions Worker provides a REST API endpoint for triggering a function, which publishes a caller-supplied value to one of the function\u0027s configured input topics. The Functions Worker performs this publish with its own broker client, which authenticates with the Worker\u0027s configured broker-client credentials rather than the credentials of the API caller.\u003cbr\u003e\u003cbr\u003eWhen authorization is enabled, in Apache Pulsar 2.4.0 and later versions, the trigger endpoint checks only that the caller is authorized to perform function operations in the function\u0027s namespace. It does not check that the caller is authorized to produce to the input topic that the message is published to. Versions before 2.4.0 do not perform a caller authorization check for the trigger endpoint at all. Function input topics are not restricted to the function\u0027s own tenant or namespace, and registering a function does not require produce permission on its input topics.\u003cbr\u003e\u003cbr\u003eAs a result, an authenticated user who is authorized to manage functions in a namespace, for example a role granted the functions permission on that namespace, can cause the Functions Worker to publish messages with caller-controlled content to a topic that the user is not authorized to produce to, including topics in other tenants. These messages are published under the identity of the Functions Worker. The issue does not require any function instance to be running or any function code to be executed. It requires that the Functions Worker\u0027s broker-client identity is itself authorized to produce to the target topic and, in Apache Pulsar 2.3.0 and later versions, to list the subscriptions of the target topic, as is the case when that identity is a superuser. The impact is on the integrity of the data in the affected topics: consumers of those topics may receive messages from a user who is not permitted to publish them. This concerns the Functions Worker REST API as called by an external, authenticated client; it does not change the security model for function code, which must be fully trusted.\u003cbr\u003e\u003cbr\u003eIn fixed versions, when authorization is enabled, triggering a function additionally requires the caller to be authorized to produce to the selected input topic before any message is published.\u003cbr\u003e\u003cbr\u003eThis issue affects Apache Pulsar versions from 2.0.0-rc1-incubating 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 of Apache Pulsar 2.4.0 and later versions with authorization enabled who cannot upgrade immediately can limit the permission to manage functions to trusted roles. Users of versions before 2.4.0 should restrict access to the Functions Worker REST API to trusted callers, because in these versions the trigger endpoint does not check the caller\u0027s permission to manage functions."
}
],
"value": "The Pulsar Functions Worker provides a REST API endpoint for triggering a function, which publishes a caller-supplied value to one of the function\u0027s configured input topics. The Functions Worker performs this publish with its own broker client, which authenticates with the Worker\u0027s configured broker-client credentials rather than the credentials of the API caller.\n\nWhen authorization is enabled, in Apache Pulsar 2.4.0 and later versions, the trigger endpoint checks only that the caller is authorized to perform function operations in the function\u0027s namespace. It does not check that the caller is authorized to produce to the input topic that the message is published to. Versions before 2.4.0 do not perform a caller authorization check for the trigger endpoint at all. Function input topics are not restricted to the function\u0027s own tenant or namespace, and registering a function does not require produce permission on its input topics.\n\nAs a result, an authenticated user who is authorized to manage functions in a namespace, for example a role granted the functions permission on that namespace, can cause the Functions Worker to publish messages with caller-controlled content to a topic that the user is not authorized to produce to, including topics in other tenants. These messages are published under the identity of the Functions Worker. The issue does not require any function instance to be running or any function code to be executed. It requires that the Functions Worker\u0027s broker-client identity is itself authorized to produce to the target topic and, in Apache Pulsar 2.3.0 and later versions, to list the subscriptions of the target topic, as is the case when that identity is a superuser. The impact is on the integrity of the data in the affected topics: consumers of those topics may receive messages from a user who is not permitted to publish them. This concerns the Functions Worker REST API as called by an external, authenticated client; it does not change the security model for function code, which must be fully trusted.\n\nIn fixed versions, when authorization is enabled, triggering a function additionally requires the caller to be authorized to produce to the selected input topic before any message is published.\n\nThis issue affects Apache Pulsar versions from 2.0.0-rc1-incubating 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 of Apache Pulsar 2.4.0 and later versions with authorization enabled who cannot upgrade immediately can limit the permission to manage functions to trusted roles. Users of versions before 2.4.0 should restrict access to the Functions Worker REST API to trusted callers, because in these versions the trigger endpoint does not check the caller\u0027s permission to manage functions."
}
],
"metrics": [
{
"cvssV4_0": {
"Automatable": "NOT_DEFINED",
"Recovery": "NOT_DEFINED",
"Safety": "NOT_DEFINED",
"attackComplexity": "LOW",
"attackRequirements": "PRESENT",
"attackVector": "NETWORK",
"baseScore": 4.9,
"baseSeverity": "MEDIUM",
"exploitMaturity": "NOT_DEFINED",
"privilegesRequired": "LOW",
"providerUrgency": "NOT_DEFINED",
"subAvailabilityImpact": "NONE",
"subConfidentialityImpact": "NONE",
"subIntegrityImpact": "HIGH",
"userInteraction": "NONE",
"valueDensity": "NOT_DEFINED",
"vectorString": "CVSS:4.0/AV:N/AC:L/AT:P/PR:L/UI:N/VC:N/VI:N/VA:N/SC:N/SI:H/SA:N",
"version": "4.0",
"vulnAvailabilityImpact": "NONE",
"vulnConfidentialityImpact": "NONE",
"vulnIntegrityImpact": "NONE",
"vulnerabilityResponseEffort": "NOT_DEFINED"
},
"format": "CVSS",
"scenarios": [
{
"lang": "en",
"value": "GENERAL"
}
]
}
],
"problemTypes": [
{
"descriptions": [
{
"cweId": "CWE-862",
"description": "CWE-862 Missing Authorization",
"lang": "en",
"type": "CWE"
}
]
}
],
"providerMetadata": {
"dateUpdated": "2026-10-21T18:10:24.056Z",
"orgId": "f0158376-9dc2-43b6-827c-5f631a4d8d09",
"shortName": "apache"
},
"references": [
{
"tags": [
"vendor-advisory"
],
"url": "https://pulsar.apache.org/security/CVE-2026-105935/"
},
{
"tags": [
"vendor-advisory"
],
"url": "https://lists.apache.org/thread.html/nrk7hkyzgo447gm58ry6n8ohl8z5j6nl"
}
],
"source": {
"discovery": "EXTERNAL"
},
"title": "Apache Pulsar: Function trigger publishes to the input topic without checking the caller\u0027s produce permission",
"x_generator": {
"engine": "Vulnogram 1.0.3"
}
}
},
"cveMetadata": {
"assignerOrgId": "f0158376-9dc2-43b6-827c-5f631a4d8d09",
"assignerShortName": "apache",
"cveId": "CVE-2026-105935",
"datePublished": "2026-10-21T18:10:24.056Z",
"dateReserved": "2026-10-06T06:43:59.382Z",
"dateUpdated": "2026-10-21T18:10:24.056Z",
"state": "PUBLISHED"
},
"dataType": "CVE_RECORD",
"dataVersion": "5.2"
}
CVE-2026-105934 (GCVE-0-2026-105934)
Vulnerability from nvd – Published: 2026-10-21 18:08 – Updated: 2026-10-21 18:08
VLAI
EPSS
VEX
Title
Apache Pulsar: Missing tenant admin authorization check when truncating a partitioned topic
Summary
The Apache Pulsar broker admin REST API provides a truncate operation for persistent topics (DELETE /admin/v2/persistent/{tenant}/{namespace}/{topic}/truncate). Truncating a topic moves all subscription cursors of the topic to the end of the topic and deletes the topic's inactive ledgers. Truncating a non-partitioned topic, or a single partition addressed by its partition name, correctly requires the tenant admin role or the superuser role. When the operation is requested for the name of a partitioned topic, the broker does not apply this tenant admin check to the caller. Instead, it truncates each partition using the broker's own internal admin client, which authenticates with the broker's configured client credentials rather than the caller's identity. Each per-partition truncate request is still checked for the tenant admin role or the superuser role, but against the broker's internal identity instead of the caller. The partitions are therefore truncated only when the broker's configured client role is a superuser or an admin of the target tenant, which is the usual configuration when authorization is enabled.
As a result, when that condition holds, an authenticated user who is not a tenant admin can truncate any partitioned topic on which the user has lookup permission. Caller authentication and lookup permission alone are not sufficient: if the broker's internal identity lacks tenant admin or superuser authorization for the target tenant, the per-partition requests are rejected. With the default authorization provider, lookup permission is granted by produce or consume permission on the topic or its namespace. A user with no permissions on the topic cannot trigger the issue. This impact analysis assumes that Pulsar has been configured with the default authorization provider. For custom authorization providers, the impact could be different.
Truncating a partitioned topic this way moves the cursors of all subscriptions on every partition to the end of the topic, so any unacknowledged backlog is skipped and is no longer delivered to consumers. It also deletes eligible older ledgers of each partition regardless of the namespace's configured retention policy, so messages stored in those ledgers can be permanently lost. The ledger currently being written is not deleted by the truncate operation. The issue does not allow reading message contents or changing permissions or configuration, and it does not give access to topics on which the user has no lookup permission.
This issue affects Apache Pulsar versions from 2.8.0 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 reduce exposure by restricting network access to the broker's admin REST API (/admin/v2) to trusted administrative clients.
Severity
CWE
- CWE-862 - Missing Authorization
Assigner
References
2 references
| URL | Tags |
|---|---|
| https://pulsar.apache.org/security/CVE-2026-105934/ | vendor-advisory |
| https://lists.apache.org/thread.html/ox0vy41jlb41… | vendor-advisory |
Impacted products
1 product
| Vendor | Product | Version | |
|---|---|---|---|
| Apache Software Foundation | Apache Pulsar |
Affected:
2.8.0 , < 4.0.14
(semver)
Affected: 4.1.0 , < 4.2.5 (semver) |
{
"containers": {
"cna": {
"affected": [
{
"defaultStatus": "unaffected",
"product": "Apache Pulsar",
"vendor": "Apache Software Foundation",
"versions": [
{
"lessThan": "4.0.14",
"status": "affected",
"version": "2.8.0",
"versionType": "semver"
},
{
"lessThan": "4.2.5",
"status": "affected",
"version": "4.1.0",
"versionType": "semver"
}
]
}
],
"credits": [
{
"lang": "en",
"type": "finder",
"value": "Mingsheng Lin of Institute of Information Engineering, CAS"
},
{
"lang": "en",
"type": "finder",
"value": "Xingchen Chen of Institute of Information Engineering, CAS"
},
{
"lang": "en",
"type": "finder",
"value": "Qixu Liu of Institute of Information Engineering, CAS"
}
],
"descriptions": [
{
"lang": "en",
"supportingMedia": [
{
"base64": false,
"type": "text/html",
"value": "The Apache Pulsar broker admin REST API provides a truncate operation for persistent topics (DELETE /admin/v2/persistent/{tenant}/{namespace}/{topic}/truncate). Truncating a topic moves all subscription cursors of the topic to the end of the topic and deletes the topic\u0027s inactive ledgers. Truncating a non-partitioned topic, or a single partition addressed by its partition name, correctly requires the tenant admin role or the superuser role. When the operation is requested for the name of a partitioned topic, the broker does not apply this tenant admin check to the caller. Instead, it truncates each partition using the broker\u0027s own internal admin client, which authenticates with the broker\u0027s configured client credentials rather than the caller\u0027s identity. Each per-partition truncate request is still checked for the tenant admin role or the superuser role, but against the broker\u0027s internal identity instead of the caller. The partitions are therefore truncated only when the broker\u0027s configured client role is a superuser or an admin of the target tenant, which is the usual configuration when authorization is enabled.\u003cbr\u003e\u003cbr\u003eAs a result, when that condition holds, an authenticated user who is not a tenant admin can truncate any partitioned topic on which the user has lookup permission. Caller authentication and lookup permission alone are not sufficient: if the broker\u0027s internal identity lacks tenant admin or superuser authorization for the target tenant, the per-partition requests are rejected. With the default authorization provider, lookup permission is granted by produce or consume permission on the topic or its namespace. A user with no permissions on the topic cannot trigger the issue. This impact analysis assumes that Pulsar has been configured with the default authorization provider. For custom authorization providers, the impact could be different.\u003cbr\u003e\u003cbr\u003eTruncating a partitioned topic this way moves the cursors of all subscriptions on every partition to the end of the topic, so any unacknowledged backlog is skipped and is no longer delivered to consumers. It also deletes eligible older ledgers of each partition regardless of the namespace\u0027s configured retention policy, so messages stored in those ledgers can be permanently lost. The ledger currently being written is not deleted by the truncate operation. The issue does not allow reading message contents or changing permissions or configuration, and it does not give access to topics on which the user has no lookup permission.\u003cbr\u003e\u003cbr\u003eThis issue affects Apache Pulsar versions from 2.8.0 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 reduce exposure by restricting network access to the broker\u0027s admin REST API (/admin/v2) to trusted administrative clients."
}
],
"value": "The Apache Pulsar broker admin REST API provides a truncate operation for persistent topics (DELETE /admin/v2/persistent/{tenant}/{namespace}/{topic}/truncate). Truncating a topic moves all subscription cursors of the topic to the end of the topic and deletes the topic\u0027s inactive ledgers. Truncating a non-partitioned topic, or a single partition addressed by its partition name, correctly requires the tenant admin role or the superuser role. When the operation is requested for the name of a partitioned topic, the broker does not apply this tenant admin check to the caller. Instead, it truncates each partition using the broker\u0027s own internal admin client, which authenticates with the broker\u0027s configured client credentials rather than the caller\u0027s identity. Each per-partition truncate request is still checked for the tenant admin role or the superuser role, but against the broker\u0027s internal identity instead of the caller. The partitions are therefore truncated only when the broker\u0027s configured client role is a superuser or an admin of the target tenant, which is the usual configuration when authorization is enabled.\n\nAs a result, when that condition holds, an authenticated user who is not a tenant admin can truncate any partitioned topic on which the user has lookup permission. Caller authentication and lookup permission alone are not sufficient: if the broker\u0027s internal identity lacks tenant admin or superuser authorization for the target tenant, the per-partition requests are rejected. With the default authorization provider, lookup permission is granted by produce or consume permission on the topic or its namespace. A user with no permissions on the topic cannot trigger the issue. This impact analysis assumes that Pulsar has been configured with the default authorization provider. For custom authorization providers, the impact could be different.\n\nTruncating a partitioned topic this way moves the cursors of all subscriptions on every partition to the end of the topic, so any unacknowledged backlog is skipped and is no longer delivered to consumers. It also deletes eligible older ledgers of each partition regardless of the namespace\u0027s configured retention policy, so messages stored in those ledgers can be permanently lost. The ledger currently being written is not deleted by the truncate operation. The issue does not allow reading message contents or changing permissions or configuration, and it does not give access to topics on which the user has no lookup permission.\n\nThis issue affects Apache Pulsar versions from 2.8.0 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 reduce exposure by restricting network access to the broker\u0027s admin REST API (/admin/v2) to trusted administrative clients."
}
],
"metrics": [
{
"cvssV4_0": {
"Automatable": "NOT_DEFINED",
"Recovery": "NOT_DEFINED",
"Safety": "NOT_DEFINED",
"attackComplexity": "LOW",
"attackRequirements": "NONE",
"attackVector": "NETWORK",
"baseScore": 7.2,
"baseSeverity": "HIGH",
"exploitMaturity": "NOT_DEFINED",
"privilegesRequired": "LOW",
"providerUrgency": "NOT_DEFINED",
"subAvailabilityImpact": "NONE",
"subConfidentialityImpact": "NONE",
"subIntegrityImpact": "NONE",
"userInteraction": "NONE",
"valueDensity": "NOT_DEFINED",
"vectorString": "CVSS:4.0/AV:N/AC:L/AT:N/PR:L/UI:N/VC:N/VI:H/VA:H/SC:N/SI:N/SA:N",
"version": "4.0",
"vulnAvailabilityImpact": "HIGH",
"vulnConfidentialityImpact": "NONE",
"vulnIntegrityImpact": "HIGH",
"vulnerabilityResponseEffort": "NOT_DEFINED"
},
"format": "CVSS",
"scenarios": [
{
"lang": "en",
"value": "GENERAL"
}
]
}
],
"problemTypes": [
{
"descriptions": [
{
"cweId": "CWE-862",
"description": "CWE-862 Missing Authorization",
"lang": "en",
"type": "CWE"
}
]
}
],
"providerMetadata": {
"dateUpdated": "2026-10-21T18:08:43.192Z",
"orgId": "f0158376-9dc2-43b6-827c-5f631a4d8d09",
"shortName": "apache"
},
"references": [
{
"tags": [
"vendor-advisory"
],
"url": "https://pulsar.apache.org/security/CVE-2026-105934/"
},
{
"tags": [
"vendor-advisory"
],
"url": "https://lists.apache.org/thread.html/ox0vy41jlb41y2l04y7b6h2srlyqoj8o"
}
],
"source": {
"discovery": "EXTERNAL"
},
"title": "Apache Pulsar: Missing tenant admin authorization check when truncating a partitioned topic",
"x_generator": {
"engine": "Vulnogram 1.0.3"
}
}
},
"cveMetadata": {
"assignerOrgId": "f0158376-9dc2-43b6-827c-5f631a4d8d09",
"assignerShortName": "apache",
"cveId": "CVE-2026-105934",
"datePublished": "2026-10-21T18:08:43.192Z",
"dateReserved": "2026-10-06T06:42:50.881Z",
"dateUpdated": "2026-10-21T18:08:43.192Z",
"state": "PUBLISHED"
},
"dataType": "CVE_RECORD",
"dataVersion": "5.2"
}
CVE-2026-105933 (GCVE-0-2026-105933)
Vulnerability from nvd – Published: 2026-10-21 18:07 – Updated: 2026-10-21 18:07
VLAI
EPSS
VEX
Title
Apache Pulsar: Namespace encryption requirement not enforced after a failure during topic initialization
Summary
Apache Pulsar allows an administrator to require end-to-end message encryption for all topics in a namespace by setting the encryption_required namespace policy. When this policy is set, the broker rejects messages that are published without encryption.
When the broker loads a persistent topic, it reads the namespace policies and the topic-level policies as part of topic initialization. If a step of this initialization fails, for example because of an error reading from the metadata store, a failure loading the topic-level policies or a failure in a later initialization step, the broker logs a warning, disables the encryption requirement for that topic, and completes the topic load as if it had succeeded. The topic is then served with encryption_required not enforced, even though the namespace policy requires it. Topic-level policies that could not be loaded are also not applied.
While the encryption requirement is not enforced, an authenticated client with permission to produce to the affected topic can publish messages that are not encrypted, and the broker accepts and stores them. This applies both to producers created after the topic was loaded and to producers that were already connected. Messages published with encryption remain encrypted; the issue does not expose the content of encrypted messages or the encryption keys.
The condition is not limited to transient failures. If the cause of the initialization failure persists, the encryption requirement is disabled again each time the topic is loaded, for example after a topic unload, a namespace bundle reassignment or a broker restart. An update to the namespace policies restores enforcement on a loaded topic, but only until the topic is loaded again. Enforcement is reliably restored only once the underlying cause of the failure has been resolved and the topic has been loaded again. The broker logs a warning when the encryption requirement is disabled, but the topic load is reported as successful and the state of the encryption requirement is not shown in the topic statistics.
In fixed versions, a failure during topic initialization causes the topic load to fail so that it can be retried, instead of loading the topic with the encryption requirement disabled.
This issue affects Apache Pulsar versions from 1.22.0-incubating 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 rely on encryption_required and cannot upgrade immediately can monitor the broker logs for warnings containing "isEncryptionRequired will be set to false" (the exact wording of the message differs between releases), resolve the underlying cause of the failure, and then reload the affected topic and confirm that the warning does not recur.
Severity
CWE
- CWE-636 - Not Failing Securely ('Failing Open')
Assigner
References
2 references
| URL | Tags |
|---|---|
| https://pulsar.apache.org/security/CVE-2026-105933/ | vendor-advisory |
| https://lists.apache.org/thread.html/f9xdlh72zf7g… | vendor-advisory |
Impacted products
1 product
| Vendor | Product | Version | |
|---|---|---|---|
| Apache Software Foundation | Apache Pulsar |
Affected:
1.22.0-incubating , < 4.0.14
(semver)
Affected: 4.1.0 , < 4.2.5 (semver) |
{
"containers": {
"cna": {
"affected": [
{
"defaultStatus": "unaffected",
"product": "Apache Pulsar",
"vendor": "Apache Software Foundation",
"versions": [
{
"lessThan": "4.0.14",
"status": "affected",
"version": "1.22.0-incubating",
"versionType": "semver"
},
{
"lessThan": "4.2.5",
"status": "affected",
"version": "4.1.0",
"versionType": "semver"
}
]
}
],
"credits": [
{
"lang": "en",
"type": "finder",
"value": "Sepuri Sai Krishna"
}
],
"descriptions": [
{
"lang": "en",
"supportingMedia": [
{
"base64": false,
"type": "text/html",
"value": "Apache Pulsar allows an administrator to require end-to-end message encryption for all topics in a namespace by setting the encryption_required namespace policy. When this policy is set, the broker rejects messages that are published without encryption.\u003cbr\u003e\u003cbr\u003eWhen the broker loads a persistent topic, it reads the namespace policies and the topic-level policies as part of topic initialization. If a step of this initialization fails, for example because of an error reading from the metadata store, a failure loading the topic-level policies or a failure in a later initialization step, the broker logs a warning, disables the encryption requirement for that topic, and completes the topic load as if it had succeeded. The topic is then served with encryption_required not enforced, even though the namespace policy requires it. Topic-level policies that could not be loaded are also not applied.\u003cbr\u003e\u003cbr\u003eWhile the encryption requirement is not enforced, an authenticated client with permission to produce to the affected topic can publish messages that are not encrypted, and the broker accepts and stores them. This applies both to producers created after the topic was loaded and to producers that were already connected. Messages published with encryption remain encrypted; the issue does not expose the content of encrypted messages or the encryption keys.\u003cbr\u003e\u003cbr\u003eThe condition is not limited to transient failures. If the cause of the initialization failure persists, the encryption requirement is disabled again each time the topic is loaded, for example after a topic unload, a namespace bundle reassignment or a broker restart. An update to the namespace policies restores enforcement on a loaded topic, but only until the topic is loaded again. Enforcement is reliably restored only once the underlying cause of the failure has been resolved and the topic has been loaded again. The broker logs a warning when the encryption requirement is disabled, but the topic load is reported as successful and the state of the encryption requirement is not shown in the topic statistics.\u003cbr\u003e\u003cbr\u003eIn fixed versions, a failure during topic initialization causes the topic load to fail so that it can be retried, instead of loading the topic with the encryption requirement disabled.\u003cbr\u003e\u003cbr\u003eThis issue affects Apache Pulsar versions from 1.22.0-incubating 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 rely on encryption_required and cannot upgrade immediately can monitor the broker logs for warnings containing \"isEncryptionRequired will be set to false\" (the exact wording of the message differs between releases), resolve the underlying cause of the failure, and then reload the affected topic and confirm that the warning does not recur."
}
],
"value": "Apache Pulsar allows an administrator to require end-to-end message encryption for all topics in a namespace by setting the encryption_required namespace policy. When this policy is set, the broker rejects messages that are published without encryption.\n\nWhen the broker loads a persistent topic, it reads the namespace policies and the topic-level policies as part of topic initialization. If a step of this initialization fails, for example because of an error reading from the metadata store, a failure loading the topic-level policies or a failure in a later initialization step, the broker logs a warning, disables the encryption requirement for that topic, and completes the topic load as if it had succeeded. The topic is then served with encryption_required not enforced, even though the namespace policy requires it. Topic-level policies that could not be loaded are also not applied.\n\nWhile the encryption requirement is not enforced, an authenticated client with permission to produce to the affected topic can publish messages that are not encrypted, and the broker accepts and stores them. This applies both to producers created after the topic was loaded and to producers that were already connected. Messages published with encryption remain encrypted; the issue does not expose the content of encrypted messages or the encryption keys.\n\nThe condition is not limited to transient failures. If the cause of the initialization failure persists, the encryption requirement is disabled again each time the topic is loaded, for example after a topic unload, a namespace bundle reassignment or a broker restart. An update to the namespace policies restores enforcement on a loaded topic, but only until the topic is loaded again. Enforcement is reliably restored only once the underlying cause of the failure has been resolved and the topic has been loaded again. The broker logs a warning when the encryption requirement is disabled, but the topic load is reported as successful and the state of the encryption requirement is not shown in the topic statistics.\n\nIn fixed versions, a failure during topic initialization causes the topic load to fail so that it can be retried, instead of loading the topic with the encryption requirement disabled.\n\nThis issue affects Apache Pulsar versions from 1.22.0-incubating 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 rely on encryption_required and cannot upgrade immediately can monitor the broker logs for warnings containing \"isEncryptionRequired will be set to false\" (the exact wording of the message differs between releases), resolve the underlying cause of the failure, and then reload the affected topic and confirm that the warning does not recur."
}
],
"metrics": [
{
"cvssV4_0": {
"Automatable": "NOT_DEFINED",
"Recovery": "NOT_DEFINED",
"Safety": "NOT_DEFINED",
"attackComplexity": "LOW",
"attackRequirements": "PRESENT",
"attackVector": "NETWORK",
"baseScore": 2.3,
"baseSeverity": "LOW",
"exploitMaturity": "NOT_DEFINED",
"privilegesRequired": "LOW",
"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:L/UI:N/VC:N/VI:L/VA:N/SC:N/SI:N/SA:N",
"version": "4.0",
"vulnAvailabilityImpact": "NONE",
"vulnConfidentialityImpact": "NONE",
"vulnIntegrityImpact": "LOW",
"vulnerabilityResponseEffort": "NOT_DEFINED"
},
"format": "CVSS",
"scenarios": [
{
"lang": "en",
"value": "GENERAL"
}
]
}
],
"problemTypes": [
{
"descriptions": [
{
"cweId": "CWE-636",
"description": "CWE-636 Not Failing Securely (\u0027Failing Open\u0027)",
"lang": "en",
"type": "CWE"
}
]
}
],
"providerMetadata": {
"dateUpdated": "2026-10-21T18:07:43.954Z",
"orgId": "f0158376-9dc2-43b6-827c-5f631a4d8d09",
"shortName": "apache"
},
"references": [
{
"tags": [
"vendor-advisory"
],
"url": "https://pulsar.apache.org/security/CVE-2026-105933/"
},
{
"tags": [
"vendor-advisory"
],
"url": "https://lists.apache.org/thread.html/f9xdlh72zf7got2y3vxww5fv4rxvmjbq"
}
],
"source": {
"discovery": "EXTERNAL"
},
"title": "Apache Pulsar: Namespace encryption requirement not enforced after a failure during topic initialization",
"x_generator": {
"engine": "Vulnogram 1.0.3"
}
}
},
"cveMetadata": {
"assignerOrgId": "f0158376-9dc2-43b6-827c-5f631a4d8d09",
"assignerShortName": "apache",
"cveId": "CVE-2026-105933",
"datePublished": "2026-10-21T18:07:43.954Z",
"dateReserved": "2026-10-06T06:41:07.880Z",
"dateUpdated": "2026-10-21T18:07:43.954Z",
"state": "PUBLISHED"
},
"dataType": "CVE_RECORD",
"dataVersion": "5.2"
}
CVE-2026-105932 (GCVE-0-2026-105932)
Vulnerability from nvd – Published: 2026-10-21 18:06 – Updated: 2026-10-21 18:06
VLAI
EPSS
VEX
Title
Apache Pulsar: Missing topic policy authorization on non-persistent topic entry filter endpoints
Summary
The Apache Pulsar broker admin REST API provides endpoints to read, set and remove the topic-level entry filter policy of a topic. For persistent topics these endpoints check that the caller is authorized for the entry filters topic policy operation. The corresponding endpoints for non-persistent topics (/admin/v2/non-persistent/{tenant}/{namespace}/{topic}/entryFilters) do not perform this authorization check. The only authorization check these endpoints perform is an indirect lookup permission check, made while the topic's partition metadata is retrieved; it is present in all affected versions.
As a result, when authentication and authorization are enabled, an authenticated user who has been granted produce or consume permission on a non-persistent topic, or on its namespace, but not permission to manage the topic's policies can read, replace or remove the topic-level entry filter policy of that topic. These operations should be restricted to users with the tenant admin role or the superuser role. This impact analysis assumes that Pulsar has been configured with the default authorization provider. For custom authorization providers, the impact could be slightly different.
The practical impact is limited by two broker configuration requirements, neither of which is met by default:
- Entry filters must have been installed by the operator. Entry filter implementations are loaded only at broker startup from the broker's entry filters directory, which is empty by default. A request can only select among entry filters the operator has already deployed; setting any other filter name is rejected. The issue does not allow a caller to install or load entry filter code or to run arbitrary code in the broker.
- Topic-level entry filter policies must be allowed to override the broker-level configuration (allowOverrideEntryFilters, which is disabled by default). When this setting is disabled, the topic-level entry filter policy has no effect on message dispatch.
In deployments where both conditions are met, an unauthorized user can remove the topic-level entry filter policy of a non-persistent topic, for example one used to restrict which messages are delivered to consumers, or apply a different installed entry filter that withholds messages from subscriptions of that topic. Removing it makes the topic fall back to the namespace-level or broker-level entry filters, which are not removed. A changed policy affects only subscription dispatchers created after the change, for example for new subscriptions or when a subscription is re-created after all of its consumers have disconnected; dispatchers that already exist keep the entry filters they were created with. Because non-persistent topics do not store messages, messages withheld by an entry filter are not delivered. Reading the policy discloses only the names of the configured entry filters. The issue does not allow reading message contents, and entry filters cannot modify message payloads. Persistent topics and namespace-level entry filter policies are not affected. Apache Pulsar versions before 3.3.0 are not affected, because in those versions the entry filters topic policy check is made in code shared by the persistent and non-persistent endpoints.
This issue affects Apache Pulsar versions from 3.3.0 before 4.0.14 and from 4.1.0 before 4.2.5.
- 3.3.x and 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 and have deployed entry filters should keep allowOverrideEntryFilters at its default value of false, so that topic-level entry filter policies do not affect message dispatch.
Severity
CWE
- CWE-862 - Missing Authorization
Assigner
References
2 references
| URL | Tags |
|---|---|
| https://pulsar.apache.org/security/CVE-2026-105932/ | vendor-advisory |
| https://lists.apache.org/thread.html/y30v2pv2gyj3… | vendor-advisory |
Impacted products
1 product
| Vendor | Product | Version | |
|---|---|---|---|
| Apache Software Foundation | Apache Pulsar |
Affected:
3.3.0 , < 4.0.14
(semver)
Affected: 4.1.0 , < 4.2.5 (semver) |
{
"containers": {
"cna": {
"affected": [
{
"defaultStatus": "unaffected",
"product": "Apache Pulsar",
"vendor": "Apache Software Foundation",
"versions": [
{
"lessThan": "4.0.14",
"status": "affected",
"version": "3.3.0",
"versionType": "semver"
},
{
"lessThan": "4.2.5",
"status": "affected",
"version": "4.1.0",
"versionType": "semver"
}
]
}
],
"credits": [
{
"lang": "en",
"type": "finder",
"value": "yangxi739"
},
{
"lang": "en",
"type": "finder",
"value": "n0mi1k"
},
{
"lang": "en",
"type": "finder",
"value": "Mingsheng Lin of Institute of Information Engineering, CAS"
},
{
"lang": "en",
"type": "finder",
"value": "Xingchen Chen of Institute of Information Engineering, CAS"
},
{
"lang": "en",
"type": "finder",
"value": "Qixu Liu of Institute of Information Engineering, CAS"
},
{
"lang": "en",
"type": "finder",
"value": "sec-reex"
}
],
"descriptions": [
{
"lang": "en",
"supportingMedia": [
{
"base64": false,
"type": "text/html",
"value": "The Apache Pulsar broker admin REST API provides endpoints to read, set and remove the topic-level entry filter policy of a topic. For persistent topics these endpoints check that the caller is authorized for the entry filters topic policy operation. The corresponding endpoints for non-persistent topics (/admin/v2/non-persistent/{tenant}/{namespace}/{topic}/entryFilters) do not perform this authorization check. The only authorization check these endpoints perform is an indirect lookup permission check, made while the topic\u0027s partition metadata is retrieved; it is present in all affected versions.\u003cbr\u003e\u003cbr\u003eAs a result, when authentication and authorization are enabled, an authenticated user who has been granted produce or consume permission on a non-persistent topic, or on its namespace, but not permission to manage the topic\u0027s policies can read, replace or remove the topic-level entry filter policy of that topic. These operations should be restricted to users with the tenant admin role or the superuser role. This impact analysis assumes that Pulsar has been configured with the default authorization provider. For custom authorization providers, the impact could be slightly different.\u003cbr\u003e\u003cbr\u003eThe practical impact is limited by two broker configuration requirements, neither of which is met by default:\u003cbr\u003e\u003cbr\u003e- Entry filters must have been installed by the operator. Entry filter implementations are loaded only at broker startup from the broker\u0027s entry filters directory, which is empty by default. A request can only select among entry filters the operator has already deployed; setting any other filter name is rejected. The issue does not allow a caller to install or load entry filter code or to run arbitrary code in the broker.\u003cbr\u003e- Topic-level entry filter policies must be allowed to override the broker-level configuration (allowOverrideEntryFilters, which is disabled by default). When this setting is disabled, the topic-level entry filter policy has no effect on message dispatch.\u003cbr\u003e\u003cbr\u003eIn deployments where both conditions are met, an unauthorized user can remove the topic-level entry filter policy of a non-persistent topic, for example one used to restrict which messages are delivered to consumers, or apply a different installed entry filter that withholds messages from subscriptions of that topic. Removing it makes the topic fall back to the namespace-level or broker-level entry filters, which are not removed. A changed policy affects only subscription dispatchers created after the change, for example for new subscriptions or when a subscription is re-created after all of its consumers have disconnected; dispatchers that already exist keep the entry filters they were created with. Because non-persistent topics do not store messages, messages withheld by an entry filter are not delivered. Reading the policy discloses only the names of the configured entry filters. The issue does not allow reading message contents, and entry filters cannot modify message payloads. Persistent topics and namespace-level entry filter policies are not affected. Apache Pulsar versions before 3.3.0 are not affected, because in those versions the entry filters topic policy check is made in code shared by the persistent and non-persistent endpoints.\u003cbr\u003e\u003cbr\u003eThis issue affects Apache Pulsar versions from 3.3.0 before 4.0.14 and from 4.1.0 before 4.2.5.\u003cbr\u003e\u003cbr\u003e- 3.3.x and 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 and have deployed entry filters should keep allowOverrideEntryFilters at its default value of false, so that topic-level entry filter policies do not affect message dispatch."
}
],
"value": "The Apache Pulsar broker admin REST API provides endpoints to read, set and remove the topic-level entry filter policy of a topic. For persistent topics these endpoints check that the caller is authorized for the entry filters topic policy operation. The corresponding endpoints for non-persistent topics (/admin/v2/non-persistent/{tenant}/{namespace}/{topic}/entryFilters) do not perform this authorization check. The only authorization check these endpoints perform is an indirect lookup permission check, made while the topic\u0027s partition metadata is retrieved; it is present in all affected versions.\n\nAs a result, when authentication and authorization are enabled, an authenticated user who has been granted produce or consume permission on a non-persistent topic, or on its namespace, but not permission to manage the topic\u0027s policies can read, replace or remove the topic-level entry filter policy of that topic. These operations should be restricted to users with the tenant admin role or the superuser role. This impact analysis assumes that Pulsar has been configured with the default authorization provider. For custom authorization providers, the impact could be slightly different.\n\nThe practical impact is limited by two broker configuration requirements, neither of which is met by default:\n\n- Entry filters must have been installed by the operator. Entry filter implementations are loaded only at broker startup from the broker\u0027s entry filters directory, which is empty by default. A request can only select among entry filters the operator has already deployed; setting any other filter name is rejected. The issue does not allow a caller to install or load entry filter code or to run arbitrary code in the broker.\n- Topic-level entry filter policies must be allowed to override the broker-level configuration (allowOverrideEntryFilters, which is disabled by default). When this setting is disabled, the topic-level entry filter policy has no effect on message dispatch.\n\nIn deployments where both conditions are met, an unauthorized user can remove the topic-level entry filter policy of a non-persistent topic, for example one used to restrict which messages are delivered to consumers, or apply a different installed entry filter that withholds messages from subscriptions of that topic. Removing it makes the topic fall back to the namespace-level or broker-level entry filters, which are not removed. A changed policy affects only subscription dispatchers created after the change, for example for new subscriptions or when a subscription is re-created after all of its consumers have disconnected; dispatchers that already exist keep the entry filters they were created with. Because non-persistent topics do not store messages, messages withheld by an entry filter are not delivered. Reading the policy discloses only the names of the configured entry filters. The issue does not allow reading message contents, and entry filters cannot modify message payloads. Persistent topics and namespace-level entry filter policies are not affected. Apache Pulsar versions before 3.3.0 are not affected, because in those versions the entry filters topic policy check is made in code shared by the persistent and non-persistent endpoints.\n\nThis issue affects Apache Pulsar versions from 3.3.0 before 4.0.14 and from 4.1.0 before 4.2.5.\n\n- 3.3.x and 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 and have deployed entry filters should keep allowOverrideEntryFilters at its default value of false, so that topic-level entry filter policies do not affect message dispatch."
}
],
"metrics": [
{
"cvssV4_0": {
"Automatable": "NOT_DEFINED",
"Recovery": "NOT_DEFINED",
"Safety": "NOT_DEFINED",
"attackComplexity": "LOW",
"attackRequirements": "PRESENT",
"attackVector": "NETWORK",
"baseScore": 2.3,
"baseSeverity": "LOW",
"exploitMaturity": "NOT_DEFINED",
"privilegesRequired": "LOW",
"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:L/UI:N/VC:L/VI:L/VA:L/SC:N/SI:N/SA:N",
"version": "4.0",
"vulnAvailabilityImpact": "LOW",
"vulnConfidentialityImpact": "LOW",
"vulnIntegrityImpact": "LOW",
"vulnerabilityResponseEffort": "NOT_DEFINED"
},
"format": "CVSS",
"scenarios": [
{
"lang": "en",
"value": "GENERAL"
}
]
}
],
"problemTypes": [
{
"descriptions": [
{
"cweId": "CWE-862",
"description": "CWE-862 Missing Authorization",
"lang": "en",
"type": "CWE"
}
]
}
],
"providerMetadata": {
"dateUpdated": "2026-10-21T18:06:59.228Z",
"orgId": "f0158376-9dc2-43b6-827c-5f631a4d8d09",
"shortName": "apache"
},
"references": [
{
"tags": [
"vendor-advisory"
],
"url": "https://pulsar.apache.org/security/CVE-2026-105932/"
},
{
"tags": [
"vendor-advisory"
],
"url": "https://lists.apache.org/thread.html/y30v2pv2gyj3kn4p1xxmgzfv73x6v1mo"
}
],
"source": {
"discovery": "EXTERNAL"
},
"title": "Apache Pulsar: Missing topic policy authorization on non-persistent topic entry filter endpoints",
"x_generator": {
"engine": "Vulnogram 1.0.3"
}
}
},
"cveMetadata": {
"assignerOrgId": "f0158376-9dc2-43b6-827c-5f631a4d8d09",
"assignerShortName": "apache",
"cveId": "CVE-2026-105932",
"datePublished": "2026-10-21T18:06:59.228Z",
"dateReserved": "2026-10-06T06:39:58.535Z",
"dateUpdated": "2026-10-21T18:06:59.228Z",
"state": "PUBLISHED"
},
"dataType": "CVE_RECORD",
"dataVersion": "5.2"
}
CVE-2026-105931 (GCVE-0-2026-105931)
Vulnerability from nvd – Published: 2026-10-21 18:02 – Updated: 2026-10-21 18:02
VLAI
EPSS
VEX
Title
Apache Pulsar: Missing authorization on transaction admin endpoints exposes transaction coordinator and transaction statistics of other tenants
Summary
The Apache Pulsar broker exposes a transaction administration REST API under /admin/v3/transactions. When authentication and authorization are enabled, most of the read endpoints of this API verify only that the request is authenticated and that the broker serves the requested topic or transaction coordinator. They do not check whether the caller is permitted to access the tenant, namespace or topic whose data is returned. The endpoints that modify state, which abort a transaction or scale the transaction coordinators, correctly require super-user access and are not affected.
As a result, any authenticated user, including one that has been granted no permissions, can read transaction coordinator and transaction information belonging to other tenants. This includes the list of transaction coordinators with the broker service URLs that serve them, transaction coordinator statistics and internal statistics, transaction metadata including the names of the topics and subscriptions a transaction involves and the principal that opened it, the list of long-running transactions on a transaction coordinator, transaction buffer and pending acknowledgement statistics and internal statistics for any topic and subscription, and whether a given message position of a subscription is currently held in a pending transactional acknowledgement.
The disclosure of transaction metadata and statistics can only occur when transaction support is enabled in the broker (transactionCoordinatorEnabled, which is disabled by default). When transaction support is disabled, these endpoints return no transaction data; the only residual effect is that one endpoint's error response can reveal whether a named topic exists in another tenant.
The impact is limited to disclosure of transaction-related metadata and statistics across tenant boundaries. The issue does not allow reading message contents, modifying or aborting transactions, or changing any configuration.
This issue affects Apache Pulsar versions from 2.8.0 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 and do not use Pulsar transactions should keep transaction support disabled. Where transactions are required, restricting network access to the broker's admin HTTP endpoints to trusted administrative clients reduces the exposure.
Severity
CWE
- CWE-862 - Missing Authorization
Assigner
References
2 references
| URL | Tags |
|---|---|
| https://pulsar.apache.org/security/CVE-2026-105931/ | vendor-advisory |
| https://lists.apache.org/thread.html/82g78kf9q7gm… | vendor-advisory |
Impacted products
1 product
| Vendor | Product | Version | |
|---|---|---|---|
| Apache Software Foundation | Apache Pulsar |
Affected:
2.8.0 , < 4.0.14
(semver)
Affected: 4.1.0 , < 4.2.5 (semver) |
{
"containers": {
"cna": {
"affected": [
{
"defaultStatus": "unaffected",
"product": "Apache Pulsar",
"vendor": "Apache Software Foundation",
"versions": [
{
"lessThan": "4.0.14",
"status": "affected",
"version": "2.8.0",
"versionType": "semver"
},
{
"lessThan": "4.2.5",
"status": "affected",
"version": "4.1.0",
"versionType": "semver"
}
]
}
],
"credits": [
{
"lang": "en",
"type": "finder",
"value": "n0mi1k"
},
{
"lang": "en",
"type": "finder",
"value": "Mingsheng Lin of Institute of Information Engineering, CAS"
},
{
"lang": "en",
"type": "finder",
"value": "Xingchen Chen of Institute of Information Engineering, CAS"
},
{
"lang": "en",
"type": "finder",
"value": "Qixu Liu of Institute of Information Engineering, CAS"
},
{
"lang": "en",
"type": "finder",
"value": "MopMonk-AI"
},
{
"lang": "en",
"type": "finder",
"value": "Wanxin Yin"
}
],
"descriptions": [
{
"lang": "en",
"supportingMedia": [
{
"base64": false,
"type": "text/html",
"value": "The Apache Pulsar broker exposes a transaction administration REST API under /admin/v3/transactions. When authentication and authorization are enabled, most of the read endpoints of this API verify only that the request is authenticated and that the broker serves the requested topic or transaction coordinator. They do not check whether the caller is permitted to access the tenant, namespace or topic whose data is returned. The endpoints that modify state, which abort a transaction or scale the transaction coordinators, correctly require super-user access and are not affected.\u003cbr\u003e\u003cbr\u003eAs a result, any authenticated user, including one that has been granted no permissions, can read transaction coordinator and transaction information belonging to other tenants. This includes the list of transaction coordinators with the broker service URLs that serve them, transaction coordinator statistics and internal statistics, transaction metadata including the names of the topics and subscriptions a transaction involves and the principal that opened it, the list of long-running transactions on a transaction coordinator, transaction buffer and pending acknowledgement statistics and internal statistics for any topic and subscription, and whether a given message position of a subscription is currently held in a pending transactional acknowledgement.\u003cbr\u003e\u003cbr\u003eThe disclosure of transaction metadata and statistics can only occur when transaction support is enabled in the broker (transactionCoordinatorEnabled, which is disabled by default). When transaction support is disabled, these endpoints return no transaction data; the only residual effect is that one endpoint\u0027s error response can reveal whether a named topic exists in another tenant.\u003cbr\u003e\u003cbr\u003eThe impact is limited to disclosure of transaction-related metadata and statistics across tenant boundaries. The issue does not allow reading message contents, modifying or aborting transactions, or changing any configuration.\u003cbr\u003e\u003cbr\u003eThis issue affects Apache Pulsar versions from 2.8.0 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 and do not use Pulsar transactions should keep transaction support disabled. Where transactions are required, restricting network access to the broker\u0027s admin HTTP endpoints to trusted administrative clients reduces the exposure."
}
],
"value": "The Apache Pulsar broker exposes a transaction administration REST API under /admin/v3/transactions. When authentication and authorization are enabled, most of the read endpoints of this API verify only that the request is authenticated and that the broker serves the requested topic or transaction coordinator. They do not check whether the caller is permitted to access the tenant, namespace or topic whose data is returned. The endpoints that modify state, which abort a transaction or scale the transaction coordinators, correctly require super-user access and are not affected.\n\nAs a result, any authenticated user, including one that has been granted no permissions, can read transaction coordinator and transaction information belonging to other tenants. This includes the list of transaction coordinators with the broker service URLs that serve them, transaction coordinator statistics and internal statistics, transaction metadata including the names of the topics and subscriptions a transaction involves and the principal that opened it, the list of long-running transactions on a transaction coordinator, transaction buffer and pending acknowledgement statistics and internal statistics for any topic and subscription, and whether a given message position of a subscription is currently held in a pending transactional acknowledgement.\n\nThe disclosure of transaction metadata and statistics can only occur when transaction support is enabled in the broker (transactionCoordinatorEnabled, which is disabled by default). When transaction support is disabled, these endpoints return no transaction data; the only residual effect is that one endpoint\u0027s error response can reveal whether a named topic exists in another tenant.\n\nThe impact is limited to disclosure of transaction-related metadata and statistics across tenant boundaries. The issue does not allow reading message contents, modifying or aborting transactions, or changing any configuration.\n\nThis issue affects Apache Pulsar versions from 2.8.0 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 and do not use Pulsar transactions should keep transaction support disabled. Where transactions are required, restricting network access to the broker\u0027s admin HTTP endpoints to trusted administrative clients reduces the exposure."
}
],
"metrics": [
{
"cvssV4_0": {
"Automatable": "NOT_DEFINED",
"Recovery": "NOT_DEFINED",
"Safety": "NOT_DEFINED",
"attackComplexity": "LOW",
"attackRequirements": "PRESENT",
"attackVector": "NETWORK",
"baseScore": 2.3,
"baseSeverity": "LOW",
"exploitMaturity": "NOT_DEFINED",
"privilegesRequired": "LOW",
"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:L/UI:N/VC:L/VI:N/VA:N/SC:N/SI:N/SA:N",
"version": "4.0",
"vulnAvailabilityImpact": "NONE",
"vulnConfidentialityImpact": "LOW",
"vulnIntegrityImpact": "NONE",
"vulnerabilityResponseEffort": "NOT_DEFINED"
},
"format": "CVSS",
"scenarios": [
{
"lang": "en",
"value": "GENERAL"
}
]
}
],
"problemTypes": [
{
"descriptions": [
{
"cweId": "CWE-862",
"description": "CWE-862 Missing Authorization",
"lang": "en",
"type": "CWE"
}
]
}
],
"providerMetadata": {
"dateUpdated": "2026-10-21T18:02:31.976Z",
"orgId": "f0158376-9dc2-43b6-827c-5f631a4d8d09",
"shortName": "apache"
},
"references": [
{
"tags": [
"vendor-advisory"
],
"url": "https://pulsar.apache.org/security/CVE-2026-105931/"
},
{
"tags": [
"vendor-advisory"
],
"url": "https://lists.apache.org/thread.html/82g78kf9q7gmf9m8fvsryq78g4chwktz"
}
],
"source": {
"discovery": "EXTERNAL"
},
"title": "Apache Pulsar: Missing authorization on transaction admin endpoints exposes transaction coordinator and transaction statistics of other tenants",
"x_generator": {
"engine": "Vulnogram 1.0.3"
}
}
},
"cveMetadata": {
"assignerOrgId": "f0158376-9dc2-43b6-827c-5f631a4d8d09",
"assignerShortName": "apache",
"cveId": "CVE-2026-105931",
"datePublished": "2026-10-21T18:02:31.976Z",
"dateReserved": "2026-10-06T06:37:10.499Z",
"dateUpdated": "2026-10-21T18:02:31.976Z",
"state": "PUBLISHED"
},
"dataType": "CVE_RECORD",
"dataVersion": "5.2"
}
CVE-2025-55702 (GCVE-0-2025-55702)
Vulnerability from nvd – Published: 2026-10-21 18:24 – Updated: 2026-10-21 18:24
VLAI
EPSS
VEX
Title
Apache Traffic Server: An unread Expect: 100-continue request body is framed as a new request
Summary
When a client sends a POST with Expect: 100-continue and the origin answers before reading the body, Apache Traffic Server parses the unread body left on the client connection as the next request. An attacker behind a front-end proxy that shares connections to Traffic Server can use this to smuggle requests past the front end and desynchronize responses for other users.
This issue affects Apache Traffic Server: from 8.0.0 through 8.1.11, from 9.0.0 through 9.2.15, from 10.0.0 through 10.1.4, 10.2.0.
Users are recommended to upgrade to version 9.2.16, 10.1.5, or 10.2.1, which fix the issue.
Severity
CWE
- CWE-444 - Inconsistent Interpretation of HTTP Requests
Assigner
References
1 reference
| URL | Tags |
|---|---|
| https://lists.apache.org/thread/r95dq29ywcd1f4x30… | vendor-advisory |
Impacted products
1 product
| Vendor | Product | Version | |
|---|---|---|---|
| Apache Software Foundation | Apache Traffic Server |
Affected:
8.0.0 , ≤ 8.1.11
(semver)
Affected: 9.0.0 , ≤ 9.2.15 (semver) Affected: 10.0.0 , ≤ 10.1.4 (semver) Affected: 10.2.0 (semver) |
{
"containers": {
"cna": {
"affected": [
{
"defaultStatus": "unaffected",
"product": "Apache Traffic Server",
"vendor": "Apache Software Foundation",
"versions": [
{
"lessThanOrEqual": "8.1.11",
"status": "affected",
"version": "8.0.0",
"versionType": "semver"
},
{
"lessThanOrEqual": "9.2.15",
"status": "affected",
"version": "9.0.0",
"versionType": "semver"
},
{
"lessThanOrEqual": "10.1.4",
"status": "affected",
"version": "10.0.0",
"versionType": "semver"
},
{
"status": "affected",
"version": "10.2.0",
"versionType": "semver"
}
]
}
],
"credits": [
{
"lang": "en",
"type": "reporter",
"value": "Sebastiano Sartor"
}
],
"descriptions": [
{
"lang": "en",
"supportingMedia": [
{
"base64": false,
"type": "text/html",
"value": "\u003cp\u003eWhen a client sends a POST with Expect: 100-continue and the origin answers before reading the body, Apache Traffic Server parses the unread body left on the client connection as the next request. An attacker behind a front-end proxy that shares connections to Traffic Server can use this to smuggle requests past the front end and desynchronize responses for other users.\u003c/p\u003e\u003cp\u003eThis issue affects Apache Traffic Server: from 8.0.0 through 8.1.11, from 9.0.0 through 9.2.15, from 10.0.0 through 10.1.4, 10.2.0.\u003c/p\u003e\u003cp\u003eUsers are recommended to upgrade to version 9.2.16, 10.1.5, or 10.2.1, which fix the issue.\u003c/p\u003e"
}
],
"value": "When a client sends a POST with Expect: 100-continue and the origin answers before reading the body, Apache Traffic Server parses the unread body left on the client connection as the next request. An attacker behind a front-end proxy that shares connections to Traffic Server can use this to smuggle requests past the front end and desynchronize responses for other users.\n\n\n\nThis issue affects Apache Traffic Server: from 8.0.0 through 8.1.11, from 9.0.0 through 9.2.15, from 10.0.0 through 10.1.4, 10.2.0.\n\n\n\nUsers are recommended to upgrade to version 9.2.16, 10.1.5, or 10.2.1, which fix the issue."
}
],
"metrics": [
{
"other": {
"content": {
"text": "important"
},
"type": "Textual description of severity"
},
"scenarios": [
{
"lang": "en",
"value": "GENERAL"
}
]
},
{
"cvssV3_1": {
"attackComplexity": "HIGH",
"attackVector": "NETWORK",
"availabilityImpact": "NONE",
"baseScore": 8.7,
"baseSeverity": "HIGH",
"confidentialityImpact": "HIGH",
"integrityImpact": "HIGH",
"privilegesRequired": "NONE",
"scope": "CHANGED",
"userInteraction": "NONE",
"vectorString": "CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:C/C:H/I:H/A:N",
"version": "3.1"
},
"format": "CVSS",
"scenarios": [
{
"lang": "en",
"value": "GENERAL"
}
]
},
{
"cvssV4_0": {
"Automatable": "NOT_DEFINED",
"Recovery": "NOT_DEFINED",
"Safety": "NOT_DEFINED",
"attackComplexity": "LOW",
"attackRequirements": "PRESENT",
"attackVector": "NETWORK",
"baseScore": 7,
"baseSeverity": "HIGH",
"exploitMaturity": "NOT_DEFINED",
"privilegesRequired": "NONE",
"providerUrgency": "NOT_DEFINED",
"subAvailabilityImpact": "NONE",
"subConfidentialityImpact": "HIGH",
"subIntegrityImpact": "HIGH",
"userInteraction": "NONE",
"valueDensity": "NOT_DEFINED",
"vectorString": "CVSS:4.0/AV:N/AC:L/AT:P/PR:N/UI:N/VC:N/VI:N/VA:N/SC:H/SI:H/SA:N",
"version": "4.0",
"vulnAvailabilityImpact": "NONE",
"vulnConfidentialityImpact": "NONE",
"vulnIntegrityImpact": "NONE",
"vulnerabilityResponseEffort": "NOT_DEFINED"
},
"format": "CVSS",
"scenarios": [
{
"lang": "en",
"value": "GENERAL"
}
]
}
],
"problemTypes": [
{
"descriptions": [
{
"cweId": "CWE-444",
"description": "CWE-444 Inconsistent Interpretation of HTTP Requests",
"lang": "en",
"type": "CWE"
}
]
}
],
"providerMetadata": {
"dateUpdated": "2026-10-21T18:24:21.377Z",
"orgId": "f0158376-9dc2-43b6-827c-5f631a4d8d09",
"shortName": "apache"
},
"references": [
{
"tags": [
"vendor-advisory"
],
"url": "https://lists.apache.org/thread/r95dq29ywcd1f4x30snxlqmb12z4s4kc"
}
],
"source": {
"discovery": "UNKNOWN"
},
"title": "Apache Traffic Server: An unread Expect: 100-continue request body is framed as a new request",
"x_generator": {
"engine": "scripts/cve_render.py"
}
}
},
"cveMetadata": {
"assignerOrgId": "f0158376-9dc2-43b6-827c-5f631a4d8d09",
"assignerShortName": "apache",
"cveId": "CVE-2025-55702",
"datePublished": "2026-10-21T18:24:21.377Z",
"dateReserved": "2025-08-13T22:27:49.065Z",
"dateUpdated": "2026-10-21T18:24:21.377Z",
"state": "PUBLISHED"
},
"dataType": "CVE_RECORD",
"dataVersion": "5.2"
}
CVE-2025-31699 (GCVE-0-2025-31699)
Vulnerability from nvd – Published: 2026-10-21 18:22 – Updated: 2026-10-21 18:22
VLAI
EPSS
VEX
Title
Apache Traffic Server: Origin connection still owed a request body is reused, enabling request smuggling
Summary
Apache Traffic Server can return an origin connection to the shared pool while the origin is still waiting on a request body the client declared but never fully sent, including when the client used Expect: 100-continue. The origin then reads a later request on that connection as leftover body data, which lets an attacker smuggle requests past ATS access controls, disrupt other users' requests, or poison the cache.
This issue affects Apache Traffic Server: from 8.0.0 through 8.1.11, from 9.0.0 through 9.2.15, from 10.0.0 through 10.1.4, 10.2.0.
Users are recommended to upgrade to version 9.2.16, 10.1.5, or 10.2.1, which fix the issue.
Severity
8.9 (High)
CWE
- CWE-444 - Inconsistent Interpretation of HTTP Requests
Assigner
References
1 reference
| URL | Tags |
|---|---|
| https://lists.apache.org/thread/r95dq29ywcd1f4x30… | vendor-advisory |
Impacted products
1 product
| Vendor | Product | Version | |
|---|---|---|---|
| Apache Software Foundation | Apache Traffic Server |
Affected:
8.0.0 , ≤ 8.1.11
(semver)
Affected: 9.0.0 , ≤ 9.2.15 (semver) Affected: 10.0.0 , ≤ 10.1.4 (semver) Affected: 10.2.0 (semver) |
{
"containers": {
"cna": {
"affected": [
{
"defaultStatus": "unaffected",
"product": "Apache Traffic Server",
"vendor": "Apache Software Foundation",
"versions": [
{
"lessThanOrEqual": "8.1.11",
"status": "affected",
"version": "8.0.0",
"versionType": "semver"
},
{
"lessThanOrEqual": "9.2.15",
"status": "affected",
"version": "9.0.0",
"versionType": "semver"
},
{
"lessThanOrEqual": "10.1.4",
"status": "affected",
"version": "10.0.0",
"versionType": "semver"
},
{
"status": "affected",
"version": "10.2.0",
"versionType": "semver"
}
]
}
],
"credits": [
{
"lang": "en",
"type": "reporter",
"value": "Martin van Kervel Smedshammer"
},
{
"lang": "en",
"type": "reporter",
"value": "Nick Muerdter"
}
],
"descriptions": [
{
"lang": "en",
"supportingMedia": [
{
"base64": false,
"type": "text/html",
"value": "\u003cp\u003eApache Traffic Server can return an origin connection to the shared pool while the origin is still waiting on a request body the client declared but never fully sent, including when the client used Expect: 100-continue. The origin then reads a later request on that connection as leftover body data, which lets an attacker smuggle requests past ATS access controls, disrupt other users\u0027 requests, or poison the cache.\u003c/p\u003e\u003cp\u003eThis issue affects Apache Traffic Server: from 8.0.0 through 8.1.11, from 9.0.0 through 9.2.15, from 10.0.0 through 10.1.4, 10.2.0.\u003c/p\u003e\u003cp\u003eUsers are recommended to upgrade to version 9.2.16, 10.1.5, or 10.2.1, which fix the issue.\u003c/p\u003e"
}
],
"value": "Apache Traffic Server can return an origin connection to the shared pool while the origin is still waiting on a request body the client declared but never fully sent, including when the client used Expect: 100-continue. The origin then reads a later request on that connection as leftover body data, which lets an attacker smuggle requests past ATS access controls, disrupt other users\u0027 requests, or poison the cache.\n\n\n\nThis issue affects Apache Traffic Server: from 8.0.0 through 8.1.11, from 9.0.0 through 9.2.15, from 10.0.0 through 10.1.4, 10.2.0.\n\n\n\nUsers are recommended to upgrade to version 9.2.16, 10.1.5, or 10.2.1, which fix the issue."
}
],
"metrics": [
{
"other": {
"content": {
"text": "important"
},
"type": "Textual description of severity"
},
"scenarios": [
{
"lang": "en",
"value": "GENERAL"
}
]
},
{
"cvssV3_1": {
"attackComplexity": "HIGH",
"attackVector": "NETWORK",
"availabilityImpact": "LOW",
"baseScore": 8.9,
"baseSeverity": "HIGH",
"confidentialityImpact": "HIGH",
"integrityImpact": "HIGH",
"privilegesRequired": "NONE",
"scope": "CHANGED",
"userInteraction": "NONE",
"vectorString": "CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:C/C:H/I:H/A:L",
"version": "3.1"
},
"format": "CVSS",
"scenarios": [
{
"lang": "en",
"value": "GENERAL"
}
]
},
{
"cvssV4_0": {
"Automatable": "NOT_DEFINED",
"Recovery": "NOT_DEFINED",
"Safety": "NOT_DEFINED",
"attackComplexity": "LOW",
"attackRequirements": "PRESENT",
"attackVector": "NETWORK",
"baseScore": 9.1,
"baseSeverity": "CRITICAL",
"exploitMaturity": "NOT_DEFINED",
"privilegesRequired": "NONE",
"providerUrgency": "NOT_DEFINED",
"subAvailabilityImpact": "LOW",
"subConfidentialityImpact": "HIGH",
"subIntegrityImpact": "HIGH",
"userInteraction": "NONE",
"valueDensity": "NOT_DEFINED",
"vectorString": "CVSS:4.0/AV:N/AC:L/AT:P/PR:N/UI:N/VC:L/VI:H/VA:L/SC:H/SI:H/SA:L",
"version": "4.0",
"vulnAvailabilityImpact": "LOW",
"vulnConfidentialityImpact": "LOW",
"vulnIntegrityImpact": "HIGH",
"vulnerabilityResponseEffort": "NOT_DEFINED"
},
"format": "CVSS",
"scenarios": [
{
"lang": "en",
"value": "GENERAL"
}
]
}
],
"problemTypes": [
{
"descriptions": [
{
"cweId": "CWE-444",
"description": "CWE-444 Inconsistent Interpretation of HTTP Requests",
"lang": "en",
"type": "CWE"
}
]
}
],
"providerMetadata": {
"dateUpdated": "2026-10-21T18:22:28.383Z",
"orgId": "f0158376-9dc2-43b6-827c-5f631a4d8d09",
"shortName": "apache"
},
"references": [
{
"tags": [
"vendor-advisory"
],
"url": "https://lists.apache.org/thread/r95dq29ywcd1f4x30snxlqmb12z4s4kc"
}
],
"source": {
"discovery": "UNKNOWN"
},
"title": "Apache Traffic Server: Origin connection still owed a request body is reused, enabling request smuggling",
"x_generator": {
"engine": "scripts/cve_render.py"
}
}
},
"cveMetadata": {
"assignerOrgId": "f0158376-9dc2-43b6-827c-5f631a4d8d09",
"assignerShortName": "apache",
"cveId": "CVE-2025-31699",
"datePublished": "2026-10-21T18:22:28.383Z",
"dateReserved": "2025-04-01T00:04:31.777Z",
"dateUpdated": "2026-10-21T18:22:28.383Z",
"state": "PUBLISHED"
},
"dataType": "CVE_RECORD",
"dataVersion": "5.2"
}