152 lines
10 KiB
JSON
152 lines
10 KiB
JSON
{
|
|
"dataType": "CVE_RECORD",
|
|
"dataVersion": "5.2",
|
|
"cveMetadata": {
|
|
"cveId": "CVE-2026-86147",
|
|
"assignerOrgId": "f0158376-9dc2-43b6-827c-5f631a4d8d09",
|
|
"state": "PUBLISHED",
|
|
"assignerShortName": "apache",
|
|
"dateReserved": "2026-09-05T07:14:26.207Z",
|
|
"datePublished": "2026-10-21T12:16:22.369Z",
|
|
"dateUpdated": "2026-10-30T14:45:54.782Z"
|
|
},
|
|
"containers": {
|
|
"cna": {
|
|
"providerMetadata": {
|
|
"orgId": "f0158376-9dc2-43b6-827c-5f631a4d8d09",
|
|
"shortName": "apache",
|
|
"dateUpdated": "2026-10-21T12:16:22.369Z"
|
|
},
|
|
"title": "Apache bRPC: Arbitrary file creation/truncation via /flags and unbounded profiling duration via /pprof",
|
|
"problemTypes": [
|
|
{
|
|
"descriptions": [
|
|
{
|
|
"description": "CWE-73 External Control of File Name or Path",
|
|
"lang": "en",
|
|
"cweId": "CWE-73",
|
|
"type": "CWE"
|
|
},
|
|
{
|
|
"description": "CWE-400 Uncontrolled Resource Consumption",
|
|
"lang": "en",
|
|
"cweId": "CWE-400",
|
|
"type": "CWE"
|
|
}
|
|
]
|
|
}
|
|
],
|
|
"source": {
|
|
"discovery": "INTERNAL"
|
|
},
|
|
"affected": [
|
|
{
|
|
"vendor": "Apache Software Foundation",
|
|
"product": "Apache bRPC",
|
|
"packageURL": "pkg:github/apache/brpc",
|
|
"versions": [
|
|
{
|
|
"status": "affected",
|
|
"version": "0",
|
|
"lessThan": "1.18.0",
|
|
"versionType": "semver"
|
|
}
|
|
],
|
|
"defaultStatus": "unaffected",
|
|
"collectionURL": "https://github.com",
|
|
"packageName": "apache/brpc"
|
|
}
|
|
],
|
|
"descriptions": [
|
|
{
|
|
"value": "External control of file name or path and uncontrolled resource consumption in Apache bRPC (version < 1.18.0) on all platforms allows remote attackers who can reach the builtin service port to create directories and truncate/overwrite files with the privileges of the server process, or to hold the process-wide CPU/contention profiler for an arbitrarily long time.\n\nRoot Cause:\n1. The builtin /flags service allows gflags carrying a validator to be modified at runtime via ?setvalue=. The bvar/mbvar dump path gflags (bvar_dump_file, bvar_dump_tabs, mbvar_dump_file) were registered with an accept-anything validator whose only purpose was to wake the dumping thread. A remote attacker could therefore repoint the dump path (e.g. GET /flags/bvar_dump_file?setvalue=/victim/dir/target followed by GET /flags/bvar_dump?setvalue=true, or the equivalent for mbvar_dump_file, which is used verbatim without a forced suffix), making the dumping thread recursively create directories and open/truncate files at attacker-chosen locations. Tab names in bvar_dump_tabs were appended to the path without sanitization, allowing '..' to escape the configured directory.\n2. The /pprof builtin service did not clamp the ?seconds= parameter to FLAGS_max_profiling_seconds (a limit that /hotspots enforced). A single request such as ?seconds=2147483647 made the handler sleep for decades while holding the process-wide gperftools CPU profiler or bthread contention profiler, so /hotspots/cpu and /hotspots/contention returned 503 for everyone else during that time.\n\nAffected Scenarios:\nAny Apache bRPC server exposing the builtin services (enabled by default on the same port as normal RPC traffic) to untrusted networks.\n\nHow to Fix:\n(Choose one of the following options)\n1. Upgrade bRPC to version 1.18.0, which fixes this issue.\n2. Apply this patch: https://github.com/apache/brpc/pull/3523 \n\nNote:\nAfter the fix, bvar_dump_file, bvar_dump_tabs and mbvar_dump_file can no longer be modified at runtime through the /flags builtin service. They can still be changed programmatically via google::SetCommandLineOption(), taking effect on the next dump cycle. The profiling duration of /pprof is now capped by the -max_profiling_seconds gflag (default 300 seconds), which can be adjusted by the server owner.",
|
|
"lang": "en",
|
|
"supportingMedia": [
|
|
{
|
|
"type": "text/html",
|
|
"base64": false,
|
|
"value": "External control of file name or path and uncontrolled resource consumption in Apache bRPC (version < 1.18.0) on all platforms allows remote attackers who can reach the builtin service port to create directories and truncate/overwrite files with the privileges of the server process, or to hold the process-wide CPU/contention profiler for an arbitrarily long time.<br><br>Root Cause:<br>1. The builtin /flags service allows gflags carrying a validator to be modified at runtime via ?setvalue=. The bvar/mbvar dump path gflags (bvar_dump_file, bvar_dump_tabs, mbvar_dump_file) were registered with an accept-anything validator whose only purpose was to wake the dumping thread. A remote attacker could therefore repoint the dump path (e.g. GET /flags/bvar_dump_file?setvalue=/victim/dir/target followed by GET /flags/bvar_dump?setvalue=true, or the equivalent for mbvar_dump_file, which is used verbatim without a forced suffix), making the dumping thread recursively create directories and open/truncate files at attacker-chosen locations. Tab names in bvar_dump_tabs were appended to the path without sanitization, allowing '..' to escape the configured directory.<br>2. The /pprof builtin service did not clamp the ?seconds= parameter to FLAGS_max_profiling_seconds (a limit that /hotspots enforced). A single request such as ?seconds=2147483647 made the handler sleep for decades while holding the process-wide gperftools CPU profiler or bthread contention profiler, so /hotspots/cpu and /hotspots/contention returned 503 for everyone else during that time.<br><br>Affected Scenarios:<br>Any Apache bRPC server exposing the builtin services (enabled by default on the same port as normal RPC traffic) to untrusted networks.<br><br>How to Fix:<br>(<span>Choose one of the following options)</span><br>1. Upgrade bRPC to version 1.18.0, which fixes this issue.<br><span>2. Apply this patch: </span><a target=\"_blank\" rel=\"nofollow\" href=\"https://github.com/apache/brpc/pull/3523\">https://github.com/apache/brpc/pull/3523</a><br><br>Note:<br>After the fix, bvar_dump_file, bvar_dump_tabs and mbvar_dump_file can no longer be modified at runtime through the /flags builtin service. They can still be changed programmatically via google::SetCommandLineOption(), taking effect on the next dump cycle. The profiling duration of /pprof is now capped by the -max_profiling_seconds gflag (default 300 seconds), which can be adjusted by the server owner."
|
|
}
|
|
]
|
|
}
|
|
],
|
|
"references": [
|
|
{
|
|
"url": "https://lists.apache.org/thread/2pf15ojj0vr7rtx95677kgtl1mx3gdgb",
|
|
"tags": [
|
|
"vendor-advisory"
|
|
]
|
|
}
|
|
],
|
|
"metrics": [
|
|
{
|
|
"other": {
|
|
"type": "Textual description of severity",
|
|
"content": {
|
|
"text": "moderate"
|
|
}
|
|
},
|
|
"scenarios": [
|
|
{
|
|
"lang": "en",
|
|
"value": "GENERAL"
|
|
}
|
|
]
|
|
}
|
|
],
|
|
"x_generator": {
|
|
"engine": "Vulnogram 0.2.0"
|
|
}
|
|
},
|
|
"adp": [
|
|
{
|
|
"metrics": [
|
|
{
|
|
"cvssV3_1": {
|
|
"scope": "UNCHANGED",
|
|
"version": "3.1",
|
|
"baseScore": 7.5,
|
|
"attackVector": "NETWORK",
|
|
"baseSeverity": "HIGH",
|
|
"vectorString": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H",
|
|
"integrityImpact": "NONE",
|
|
"userInteraction": "NONE",
|
|
"attackComplexity": "LOW",
|
|
"availabilityImpact": "HIGH",
|
|
"privilegesRequired": "NONE",
|
|
"confidentialityImpact": "NONE"
|
|
}
|
|
},
|
|
{
|
|
"other": {
|
|
"type": "ssvc",
|
|
"content": {
|
|
"timestamp": "2026-10-30T14:45:11.531197Z",
|
|
"id": "CVE-2026-86147",
|
|
"options": [
|
|
{
|
|
"Exploitation": "none"
|
|
},
|
|
{
|
|
"Automatable": "yes"
|
|
},
|
|
{
|
|
"Technical Impact": "partial"
|
|
}
|
|
],
|
|
"role": "CISA Coordinator",
|
|
"version": "2.0.3"
|
|
}
|
|
}
|
|
}
|
|
],
|
|
"title": "CISA ADP Vulnrichment",
|
|
"providerMetadata": {
|
|
"orgId": "134c704f-9b21-4f2e-91b3-4a467353bcc0",
|
|
"shortName": "CISA-ADP",
|
|
"dateUpdated": "2026-10-30T14:45:54.782Z"
|
|
}
|
|
}
|
|
]
|
|
}
|
|
} |