Advisory Database Sync

Author: advisory-database[bot]

advisories/unreviewed/2025/09/GHSA-23fg-w3cv-jf6w/GHSA-23fg-w3cv-jf6w.json

@@ -1,13 +1,18 @@
 {
   "schema_version": "1.4.0",
   "id": "GHSA-23fg-w3cv-jf6w",
-  "modified": "2025-09-15T15:31:24Z",
+  "modified": "2025-12-02T03:31:33Z",
   "published": "2025-09-15T15:31:23Z",
   "aliases": [
     "CVE-2023-53174"
   ],
   "details": "In the Linux kernel, the following vulnerability has been resolved:\n\nscsi: core: Fix possible memory leak if device_add() fails\n\nIf device_add() returns error, the name allocated by dev_set_name() needs\nbe freed. As the comment of device_add() says, put_device() should be used\nto decrease the reference count in the error path. So fix this by calling\nput_device(), then the name can be freed in kobject_cleanp().",
-  "severity": [],
+  "severity": [
+    {
+      "type": "CVSS_V3",
+      "score": "CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H"
+    }
+  ],
   "affected": [],
   "references": [
     {
@@ -48,8 +53,10 @@
     }
   ],
   "database_specific": {
-    "cwe_ids": [],
-    "severity": null,
+    "cwe_ids": [
+      "CWE-401"
+    ],
+    "severity": "MODERATE",
     "github_reviewed": false,
     "github_reviewed_at": null,
     "nvd_published_at": "2025-09-15T14:15:39Z"

advisories/unreviewed/2025/09/GHSA-2937-wfx7-vxfg/GHSA-2937-wfx7-vxfg.json

@@ -1,13 +1,18 @@
 {
   "schema_version": "1.4.0",
   "id": "GHSA-2937-wfx7-vxfg",
-  "modified": "2025-09-15T15:31:24Z",
+  "modified": "2025-12-02T03:31:35Z",
   "published": "2025-09-15T15:31:24Z",
   "aliases": [
     "CVE-2023-53186"
   ],
   "details": "In the Linux kernel, the following vulnerability has been resolved:\n\nskbuff: Fix a race between coalescing and releasing SKBs\n\nCommit 1effe8ca4e34 (\"skbuff: fix coalescing for page_pool fragment\nrecycling\") allowed coalescing to proceed with non page pool page and page\npool page when @from is cloned, i.e.\n\nto->pp_recycle    --> false\nfrom->pp_recycle  --> true\nskb_cloned(from)  --> true\n\nHowever, it actually requires skb_cloned(@from) to hold true until\ncoalescing finishes in this situation. If the other cloned SKB is\nreleased while the merging is in process, from_shinfo->nr_frags will be\nset to 0 toward the end of the function, causing the increment of frag\npage _refcount to be unexpectedly skipped resulting in inconsistent\nreference counts. Later when SKB(@to) is released, it frees the page\ndirectly even though the page pool page is still in use, leading to\nuse-after-free or double-free errors. So it should be prohibited.\n\nThe double-free error message below prompted us to investigate:\nBUG: Bad page state in process swapper/1  pfn:0e0d1\npage:00000000c6548b28 refcount:-1 mapcount:0 mapping:0000000000000000\nindex:0x2 pfn:0xe0d1\nflags: 0xfffffc0000000(node=0|zone=1|lastcpupid=0x1fffff)\nraw: 000fffffc0000000 0000000000000000 ffffffff00000101 0000000000000000\nraw: 0000000000000002 0000000000000000 ffffffffffffffff 0000000000000000\npage dumped because: nonzero _refcount\n\nCPU: 1 PID: 0 Comm: swapper/1 Tainted: G            E      6.2.0+\nCall Trace:\n <IRQ>\ndump_stack_lvl+0x32/0x50\nbad_page+0x69/0xf0\nfree_pcp_prepare+0x260/0x2f0\nfree_unref_page+0x20/0x1c0\nskb_release_data+0x10b/0x1a0\nnapi_consume_skb+0x56/0x150\nnet_rx_action+0xf0/0x350\n? __napi_schedule+0x79/0x90\n__do_softirq+0xc8/0x2b1\n__irq_exit_rcu+0xb9/0xf0\ncommon_interrupt+0x82/0xa0\n</IRQ>\n<TASK>\nasm_common_interrupt+0x22/0x40\nRIP: 0010:default_idle+0xb/0x20",
-  "severity": [],
+  "severity": [
+    {
+      "type": "CVSS_V3",
+      "score": "CVSS:3.1/AV:L/AC:H/PR:L/UI:N/S:U/C:N/I:N/A:H"
+    }
+  ],
   "affected": [],
   "references": [
     {
@@ -32,8 +37,10 @@
     }
   ],
   "database_specific": {
-    "cwe_ids": [],
-    "severity": null,
+    "cwe_ids": [
+      "CWE-362"
+    ],
+    "severity": "MODERATE",
     "github_reviewed": false,
     "github_reviewed_at": null,
     "nvd_published_at": "2025-09-15T14:15:40Z"

advisories/unreviewed/2025/09/GHSA-4hgc-47xp-7m5f/GHSA-4hgc-47xp-7m5f.json

@@ -1,13 +1,18 @@
 {
   "schema_version": "1.4.0",
   "id": "GHSA-4hgc-47xp-7m5f",
-  "modified": "2025-09-15T15:31:24Z",
+  "modified": "2025-12-02T03:31:35Z",
   "published": "2025-09-15T15:31:24Z",
   "aliases": [
     "CVE-2023-53189"
   ],
   "details": "In the Linux kernel, the following vulnerability has been resolved:\n\nipv6/addrconf: fix a potential refcount underflow for idev\n\nNow in addrconf_mod_rs_timer(), reference idev depends on whether\nrs_timer is not pending. Then modify rs_timer timeout.\n\nThere is a time gap in [1], during which if the pending rs_timer\nbecomes not pending. It will miss to hold idev, but the rs_timer\nis activated. Thus rs_timer callback function addrconf_rs_timer()\nwill be executed and put idev later without holding idev. A refcount\nunderflow issue for idev can be caused by this.\n\n\tif (!timer_pending(&idev->rs_timer))\n\t\tin6_dev_hold(idev);\n\t\t  <--------------[1]\n\tmod_timer(&idev->rs_timer, jiffies + when);\n\nTo fix the issue, hold idev if mod_timer() return 0.",
-  "severity": [],
+  "severity": [
+    {
+      "type": "CVSS_V3",
+      "score": "CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H"
+    }
+  ],
   "affected": [],
   "references": [
     {
@@ -48,8 +53,10 @@
     }
   ],
   "database_specific": {
-    "cwe_ids": [],
-    "severity": null,
+    "cwe_ids": [
+      "CWE-191"
+    ],
+    "severity": "MODERATE",
     "github_reviewed": false,
     "github_reviewed_at": null,
     "nvd_published_at": "2025-09-15T14:15:41Z"

advisories/unreviewed/2025/09/GHSA-4xcf-q92v-qp8c/GHSA-4xcf-q92v-qp8c.json

@@ -1,13 +1,18 @@
 {
   "schema_version": "1.4.0",
   "id": "GHSA-4xcf-q92v-qp8c",
-  "modified": "2025-09-15T15:31:24Z",
+  "modified": "2025-12-02T03:31:35Z",
   "published": "2025-09-15T15:31:24Z",
   "aliases": [
     "CVE-2023-53187"
   ],
   "details": "In the Linux kernel, the following vulnerability has been resolved:\n\nbtrfs: fix use-after-free of new block group that became unused\n\nIf a task creates a new block group and that block group becomes unused\nbefore we finish its creation, at btrfs_create_pending_block_groups(),\nthen when btrfs_mark_bg_unused() is called against the block group, we\nassume that the block group is currently in the list of block groups to\nreclaim, and we move it out of the list of new block groups and into the\nlist of unused block groups. This has two consequences:\n\n1) We move it out of the list of new block groups associated to the\n   current transaction. So the block group creation is not finished and\n   if we attempt to delete the bg because it's unused, we will not find\n   the block group item in the extent tree (or the new block group tree),\n   its device extent items in the device tree etc, resulting in the\n   deletion to fail due to the missing items;\n\n2) We don't increment the reference count on the block group when we\n   move it to the list of unused block groups, because we assumed the\n   block group was on the list of block groups to reclaim, and in that\n   case it already has the correct reference count. However the block\n   group was on the list of new block groups, in which case no extra\n   reference was taken because it's local to the current task. This\n   later results in doing an extra reference count decrement when\n   removing the block group from the unused list, eventually leading the\n   reference count to 0.\n\nThis second case was caught when running generic/297 from fstests, which\nproduced the following assertion failure and stack trace:\n\n  [589.559] assertion failed: refcount_read(&block_group->refs) == 1, in fs/btrfs/block-group.c:4299\n  [589.559] ------------[ cut here ]------------\n  [589.559] kernel BUG at fs/btrfs/block-group.c:4299!\n  [589.560] invalid opcode: 0000 [#1] PREEMPT SMP PTI\n  [589.560] CPU: 8 PID: 2819134 Comm: umount Tainted: G        W          6.4.0-rc6-btrfs-next-134+ #1\n  [589.560] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.16.2-0-gea1b7a073390-prebuilt.qemu.org 04/01/2014\n  [589.560] RIP: 0010:btrfs_free_block_groups+0x449/0x4a0 [btrfs]\n  [589.561] Code: 68 62 da c0 (...)\n  [589.561] RSP: 0018:ffffa55a8c3b3d98 EFLAGS: 00010246\n  [589.561] RAX: 0000000000000058 RBX: ffff8f030d7f2000 RCX: 0000000000000000\n  [589.562] RDX: 0000000000000000 RSI: ffffffff953f0878 RDI: 00000000ffffffff\n  [589.562] RBP: ffff8f030d7f2088 R08: 0000000000000000 R09: ffffa55a8c3b3c50\n  [589.562] R10: 0000000000000001 R11: 0000000000000001 R12: ffff8f05850b4c00\n  [589.562] R13: ffff8f030d7f2090 R14: ffff8f05850b4cd8 R15: dead000000000100\n  [589.563] FS:  00007f497fd2e840(0000) GS:ffff8f09dfc00000(0000) knlGS:0000000000000000\n  [589.563] CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033\n  [589.563] CR2: 00007f497ff8ec10 CR3: 0000000271472006 CR4: 0000000000370ee0\n  [589.563] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000\n  [589.564] DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400\n  [589.564] Call Trace:\n  [589.564]  <TASK>\n  [589.565]  ? __die_body+0x1b/0x60\n  [589.565]  ? die+0x39/0x60\n  [589.565]  ? do_trap+0xeb/0x110\n  [589.565]  ? btrfs_free_block_groups+0x449/0x4a0 [btrfs]\n  [589.566]  ? do_error_trap+0x6a/0x90\n  [589.566]  ? btrfs_free_block_groups+0x449/0x4a0 [btrfs]\n  [589.566]  ? exc_invalid_op+0x4e/0x70\n  [589.566]  ? btrfs_free_block_groups+0x449/0x4a0 [btrfs]\n  [589.567]  ? asm_exc_invalid_op+0x16/0x20\n  [589.567]  ? btrfs_free_block_groups+0x449/0x4a0 [btrfs]\n  [589.567]  ? btrfs_free_block_groups+0x449/0x4a0 [btrfs]\n  [589.567]  close_ctree+0x35d/0x560 [btrfs]\n  [589.568]  ? fsnotify_sb_delete+0x13e/0x1d0\n  [589.568]  ? dispose_list+0x3a/0x50\n  [589.568]  ? evict_inodes+0x151/0x1a0\n  [589.568]  generic_shutdown_super+0x73/0x1a0\n  [589.569]  kill_anon_super+0x14/0x30\n  [589.569]  btrfs_kill_super+0x12/0x20 [btrfs]\n  [589.569]  deactivate_locked\n---truncated---",
-  "severity": [],
+  "severity": [
+    {
+      "type": "CVSS_V3",
+      "score": "CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H"
+    }
+  ],
   "affected": [],
   "references": [
     {
@@ -28,8 +33,10 @@
     }
   ],
   "database_specific": {
-    "cwe_ids": [],
-    "severity": null,
+    "cwe_ids": [
+      "CWE-416"
+    ],
+    "severity": "HIGH",
     "github_reviewed": false,
     "github_reviewed_at": null,
     "nvd_published_at": "2025-09-15T14:15:40Z"

advisories/unreviewed/2025/09/GHSA-5736-9cvg-p77g/GHSA-5736-9cvg-p77g.json

@@ -1,13 +1,18 @@
 {
   "schema_version": "1.4.0",
   "id": "GHSA-5736-9cvg-p77g",
-  "modified": "2025-09-15T15:31:24Z",
+  "modified": "2025-12-02T03:31:34Z",
   "published": "2025-09-15T15:31:24Z",
   "aliases": [
     "CVE-2023-53182"
   ],
   "details": "In the Linux kernel, the following vulnerability has been resolved:\n\nACPICA: Avoid undefined behavior: applying zero offset to null pointer\n\nACPICA commit 770653e3ba67c30a629ca7d12e352d83c2541b1e\n\nBefore this change we see the following UBSAN stack trace in Fuchsia:\n\n  #0    0x000021e4213b3302 in acpi_ds_init_aml_walk(struct acpi_walk_state*, union acpi_parse_object*, struct acpi_namespace_node*, u8*, u32, struct acpi_evaluate_info*, u8) ../../third_party/acpica/source/components/dispatcher/dswstate.c:682 <platform-bus-x86.so>+0x233302\n  #1.2  0x000020d0f660777f in ubsan_get_stack_trace() compiler-rt/lib/ubsan/ubsan_diag.cpp:41 <libclang_rt.asan.so>+0x3d77f\n  #1.1  0x000020d0f660777f in maybe_print_stack_trace() compiler-rt/lib/ubsan/ubsan_diag.cpp:51 <libclang_rt.asan.so>+0x3d77f\n  #1    0x000020d0f660777f in ~scoped_report() compiler-rt/lib/ubsan/ubsan_diag.cpp:387 <libclang_rt.asan.so>+0x3d77f\n  #2    0x000020d0f660b96d in handlepointer_overflow_impl() compiler-rt/lib/ubsan/ubsan_handlers.cpp:809 <libclang_rt.asan.so>+0x4196d\n  #3    0x000020d0f660b50d in compiler-rt/lib/ubsan/ubsan_handlers.cpp:815 <libclang_rt.asan.so>+0x4150d\n  #4    0x000021e4213b3302 in acpi_ds_init_aml_walk(struct acpi_walk_state*, union acpi_parse_object*, struct acpi_namespace_node*, u8*, u32, struct acpi_evaluate_info*, u8) ../../third_party/acpica/source/components/dispatcher/dswstate.c:682 <platform-bus-x86.so>+0x233302\n  #5    0x000021e4213e2369 in acpi_ds_call_control_method(struct acpi_thread_state*, struct acpi_walk_state*, union acpi_parse_object*) ../../third_party/acpica/source/components/dispatcher/dsmethod.c:605 <platform-bus-x86.so>+0x262369\n  #6    0x000021e421437fac in acpi_ps_parse_aml(struct acpi_walk_state*) ../../third_party/acpica/source/components/parser/psparse.c:550 <platform-bus-x86.so>+0x2b7fac\n  #7    0x000021e4214464d2 in acpi_ps_execute_method(struct acpi_evaluate_info*) ../../third_party/acpica/source/components/parser/psxface.c:244 <platform-bus-x86.so>+0x2c64d2\n  #8    0x000021e4213aa052 in acpi_ns_evaluate(struct acpi_evaluate_info*) ../../third_party/acpica/source/components/namespace/nseval.c:250 <platform-bus-x86.so>+0x22a052\n  #9    0x000021e421413dd8 in acpi_ns_init_one_device(acpi_handle, u32, void*, void**) ../../third_party/acpica/source/components/namespace/nsinit.c:735 <platform-bus-x86.so>+0x293dd8\n  #10   0x000021e421429e98 in acpi_ns_walk_namespace(acpi_object_type, acpi_handle, u32, u32, acpi_walk_callback, acpi_walk_callback, void*, void**) ../../third_party/acpica/source/components/namespace/nswalk.c:298 <platform-bus-x86.so>+0x2a9e98\n  #11   0x000021e4214131ac in acpi_ns_initialize_devices(u32) ../../third_party/acpica/source/components/namespace/nsinit.c:268 <platform-bus-x86.so>+0x2931ac\n  #12   0x000021e42147c40d in acpi_initialize_objects(u32) ../../third_party/acpica/source/components/utilities/utxfinit.c:304 <platform-bus-x86.so>+0x2fc40d\n  #13   0x000021e42126d603 in acpi::acpi_impl::initialize_acpi(acpi::acpi_impl*) ../../src/devices/board/lib/acpi/acpi-impl.cc:224 <platform-bus-x86.so>+0xed603\n\nAdd a simple check that avoids incrementing a pointer by zero, but\notherwise behaves as before. Note that our findings are against ACPICA\n20221020, but the same code exists on master.",
-  "severity": [],
+  "severity": [
+    {
+      "type": "CVSS_V3",
+      "score": "CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H"
+    }
+  ],
   "affected": [],
   "references": [
     {
@@ -49,7 +54,7 @@
   ],
   "database_specific": {
     "cwe_ids": [],
-    "severity": null,
+    "severity": "MODERATE",
     "github_reviewed": false,
     "github_reviewed_at": null,
     "nvd_published_at": "2025-09-15T14:15:40Z"

advisories/unreviewed/2025/09/GHSA-5ghm-j624-hfm6/GHSA-5ghm-j624-hfm6.json

@@ -1,13 +1,18 @@
 {
   "schema_version": "1.4.0",
   "id": "GHSA-5ghm-j624-hfm6",
-  "modified": "2025-09-15T15:31:24Z",
+  "modified": "2025-12-02T03:31:36Z",
   "published": "2025-09-15T15:31:24Z",
   "aliases": [
     "CVE-2023-53192"
   ],
   "details": "In the Linux kernel, the following vulnerability has been resolved:\n\nvxlan: Fix nexthop hash size\n\nThe nexthop code expects a 31 bit hash, such as what is returned by\nfib_multipath_hash() and rt6_multipath_hash(). Passing the 32 bit hash\nreturned by skb_get_hash() can lead to problems related to the fact that\n'int hash' is a negative number when the MSB is set.\n\nIn the case of hash threshold nexthop groups, nexthop_select_path_hthr()\nwill disproportionately select the first nexthop group entry. In the case\nof resilient nexthop groups, nexthop_select_path_res() may do an out of\nbounds access in nh_buckets[], for example:\n    hash = -912054133\n    num_nh_buckets = 2\n    bucket_index = 65535\n\nwhich leads to the following panic:\n\nBUG: unable to handle page fault for address: ffffc900025910c8\nPGD 100000067 P4D 100000067 PUD 10026b067 PMD 0\nOops: 0002 [#1] PREEMPT SMP KASAN NOPTI\nCPU: 4 PID: 856 Comm: kworker/4:3 Not tainted 6.5.0-rc2+ #34\nHardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.16.2-debian-1.16.2-1 04/01/2014\nWorkqueue: ipv6_addrconf addrconf_dad_work\nRIP: 0010:nexthop_select_path+0x197/0xbf0\nCode: c1 e4 05 be 08 00 00 00 4c 8b 35 a4 14 7e 01 4e 8d 6c 25 00 4a 8d 7c 25 08 48 01 dd e8 c2 25 15 ff 49 8d 7d 08 e8 39 13 15 ff <4d> 89 75 08 48 89 ef e8 7d 12 15 ff 48 8b 5d 00 e8 14 55 2f 00 85\nRSP: 0018:ffff88810c36f260 EFLAGS: 00010246\nRAX: 0000000000000000 RBX: 00000000002000c0 RCX: ffffffffaf02dd77\nRDX: dffffc0000000000 RSI: 0000000000000008 RDI: ffffc900025910c8\nRBP: ffffc900025910c0 R08: 0000000000000001 R09: fffff520004b2219\nR10: ffffc900025910cf R11: 31392d2068736168 R12: 00000000002000c0\nR13: ffffc900025910c0 R14: 00000000fffef608 R15: ffff88811840e900\nFS:  0000000000000000(0000) GS:ffff8881f7000000(0000) knlGS:0000000000000000\nCS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033\nCR2: ffffc900025910c8 CR3: 0000000129d00000 CR4: 0000000000750ee0\nPKRU: 55555554\nCall Trace:\n <TASK>\n ? __die+0x23/0x70\n ? page_fault_oops+0x1ee/0x5c0\n ? __pfx_is_prefetch.constprop.0+0x10/0x10\n ? __pfx_page_fault_oops+0x10/0x10\n ? search_bpf_extables+0xfe/0x1c0\n ? fixup_exception+0x3b/0x470\n ? exc_page_fault+0xf6/0x110\n ? asm_exc_page_fault+0x26/0x30\n ? nexthop_select_path+0x197/0xbf0\n ? nexthop_select_path+0x197/0xbf0\n ? lock_is_held_type+0xe7/0x140\n vxlan_xmit+0x5b2/0x2340\n ? __lock_acquire+0x92b/0x3370\n ? __pfx_vxlan_xmit+0x10/0x10\n ? __pfx___lock_acquire+0x10/0x10\n ? __pfx_register_lock_class+0x10/0x10\n ? skb_network_protocol+0xce/0x2d0\n ? dev_hard_start_xmit+0xca/0x350\n ? __pfx_vxlan_xmit+0x10/0x10\n dev_hard_start_xmit+0xca/0x350\n __dev_queue_xmit+0x513/0x1e20\n ? __pfx___dev_queue_xmit+0x10/0x10\n ? __pfx_lock_release+0x10/0x10\n ? mark_held_locks+0x44/0x90\n ? skb_push+0x4c/0x80\n ? eth_header+0x81/0xe0\n ? __pfx_eth_header+0x10/0x10\n ? neigh_resolve_output+0x215/0x310\n ? ip6_finish_output2+0x2ba/0xc90\n ip6_finish_output2+0x2ba/0xc90\n ? lock_release+0x236/0x3e0\n ? ip6_mtu+0xbb/0x240\n ? __pfx_ip6_finish_output2+0x10/0x10\n ? find_held_lock+0x83/0xa0\n ? lock_is_held_type+0xe7/0x140\n ip6_finish_output+0x1ee/0x780\n ip6_output+0x138/0x460\n ? __pfx_ip6_output+0x10/0x10\n ? __pfx___lock_acquire+0x10/0x10\n ? __pfx_ip6_finish_output+0x10/0x10\n NF_HOOK.constprop.0+0xc0/0x420\n ? __pfx_NF_HOOK.constprop.0+0x10/0x10\n ? ndisc_send_skb+0x2c0/0x960\n ? __pfx_lock_release+0x10/0x10\n ? __local_bh_enable_ip+0x93/0x110\n ? lock_is_held_type+0xe7/0x140\n ndisc_send_skb+0x4be/0x960\n ? __pfx_ndisc_send_skb+0x10/0x10\n ? mark_held_locks+0x65/0x90\n ? find_held_lock+0x83/0xa0\n ndisc_send_ns+0xb0/0x110\n ? __pfx_ndisc_send_ns+0x10/0x10\n addrconf_dad_work+0x631/0x8e0\n ? lock_acquire+0x180/0x3f0\n ? __pfx_addrconf_dad_work+0x10/0x10\n ? mark_held_locks+0x24/0x90\n process_one_work+0x582/0x9c0\n ? __pfx_process_one_work+0x10/0x10\n ? __pfx_do_raw_spin_lock+0x10/0x10\n ? mark_held_locks+0x24/0x90\n worker_thread+0x93/0x630\n ? __kthread_parkme+0xdc/0x100\n ? __pfx_worker_thread+0x10/0x10\n kthread+0x1a5/0x1e0\n ? __pfx_kthread+0x10/0x10\n ret_from_fork+0x34/0x60\n \n---truncated---",
-  "severity": [],
+  "severity": [
+    {
+      "type": "CVSS_V3",
+      "score": "CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H"
+    }
+  ],
   "affected": [],
   "references": [
     {
@@ -36,8 +41,10 @@
     }
   ],
   "database_specific": {
-    "cwe_ids": [],
-    "severity": null,
+    "cwe_ids": [
+      "CWE-129"
+    ],
+    "severity": "HIGH",
     "github_reviewed": false,
     "github_reviewed_at": null,
     "nvd_published_at": "2025-09-15T14:15:41Z"