Vulnerability-Lookup

GHSA-442R-3R9F-48CM

Vulnerability from github – Published: 2022-05-24 17:27 – Updated: 2023-02-03 00:30

Details

get_gate_page in mm/gup.c in the Linux kernel 5.7.x and 5.8.x before 5.8.7 allows privilege escalation because of incorrect reference counting (caused by gate page mishandling) of the struct page that backs the vsyscall page. The result is a refcount underflow. This can be triggered by any 64-bit process that can use ptrace() or process_vm_readv(), aka CID-9fa2dd946743.

Severity

7.8 (High)


                  
                    CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H

Show details on source website

JSON

To clipboard

{
  "affected": [],
  "aliases": [
    "CVE-2020-25221"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-672"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2020-09-10T14:15:00Z",
    "severity": "HIGH"
  },
  "details": "get_gate_page in mm/gup.c in the Linux kernel 5.7.x and 5.8.x before 5.8.7 allows privilege escalation because of incorrect reference counting (caused by gate page mishandling) of the struct page that backs the vsyscall page. The result is a refcount underflow. This can be triggered by any 64-bit process that can use ptrace() or process_vm_readv(), aka CID-9fa2dd946743.",
  "id": "GHSA-442r-3r9f-48cm",
  "modified": "2023-02-03T00:30:17Z",
  "published": "2022-05-24T17:27:50Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2020-25221"
    },
    {
      "type": "WEB",
      "url": "https://cdn.kernel.org/pub/linux/kernel/v5.x/ChangeLog-5.8.7"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/linus/8891adc61dce2a8a41fc0c23262b681c3ec4b73a"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/linus/9fa2dd946743ae6f30dc4830da19147bf100a7f2"
    },
    {
      "type": "WEB",
      "url": "https://security.netapp.com/advisory/ntap-20201001-0003"
    },
    {
      "type": "WEB",
      "url": "https://www.openwall.com/lists/oss-security/2020/09/08/4"
    },
    {
      "type": "WEB",
      "url": "http://www.openwall.com/lists/oss-security/2020/09/10/4"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H",
      "type": "CVSS_V3"
    }
  ]
}

GHSA-44M6-Q7G6-5VP6

Vulnerability from github – Published: 2025-01-14 15:30 – Updated: 2025-03-19 18:30

Details

An operation on a resource after expiration or release in Fortinet FortiManager 6.4.12 through 7.4.0 allows an attacker to gain improper access to FortiGate via valid credentials.

Severity

8.1 (High)


                  
                    CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:H/I:H/A:H

Show details on source website

JSON

To clipboard

{
  "affected": [],
  "aliases": [
    "CVE-2024-47571"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-672"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2025-01-14T14:15:32Z",
    "severity": "HIGH"
  },
  "details": "An operation on a resource after expiration or release in Fortinet FortiManager 6.4.12 through 7.4.0 allows an attacker to gain improper access to FortiGate via valid credentials.",
  "id": "GHSA-44m6-q7g6-5vp6",
  "modified": "2025-03-19T18:30:48Z",
  "published": "2025-01-14T15:30:54Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-47571"
    },
    {
      "type": "WEB",
      "url": "https://fortiguard.fortinet.com/psirt/FG-IR-24-239"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:H/I:H/A:H",
      "type": "CVSS_V3"
    }
  ]
}

GHSA-47FV-C4CG-C767

Vulnerability from github – Published: 2024-03-02 00:31 – Updated: 2025-01-09 18:32

Details

In the Linux kernel, the following vulnerability has been resolved:

ipc/mqueue, msg, sem: avoid relying on a stack reference past its expiry

do_mq_timedreceive calls wq_sleep with a stack local address. The sender (do_mq_timedsend) uses this address to later call pipelined_send.

This leads to a very hard to trigger race where a do_mq_timedreceive call might return and leave do_mq_timedsend to rely on an invalid address, causing the following crash:

RIP: 0010:wake_q_add_safe+0x13/0x60 Call Trace: __x64_sys_mq_timedsend+0x2a9/0x490 do_syscall_64+0x80/0x680 entry_SYSCALL_64_after_hwframe+0x44/0xa9 RIP: 0033:0x7f5928e40343

The race occurs as:

do_mq_timedreceive calls wq_sleep with the address of struct ext_wait_queue on function stack (aliased as ewq_addr here) - it holds a valid struct ext_wait_queue * as long as the stack has not been overwritten.
ewq_addr gets added to info->e_wait_q[RECV].list in wq_add, and do_mq_timedsend receives it via wq_get_first_waiter(info, RECV) to call __pipelined_op.
Sender calls __pipelined_op::smp_store_release(&this->state, STATE_READY). Here is where the race window begins. (this is ewq_addr.)
If the receiver wakes up now in do_mq_timedreceive::wq_sleep, it will see state == STATE_READY and break.
do_mq_timedreceive returns, and ewq_addr is no longer guaranteed to be a struct ext_wait_queue * since it was on do_mq_timedreceive's stack. (Although the address may not get overwritten until another function happens to touch it, which means it can persist around for an indefinite time.)
do_mq_timedsend::__pipelined_op() still believes ewq_addr is a struct ext_wait_queue *, and uses it to find a task_struct to pass to the wake_q_add_safe call. In the lucky case where nothing has overwritten ewq_addr yet, ewq_addr->task is the right task_struct. In the unlucky case, __pipelined_op::wake_q_add_safe gets handed a bogus address as the receiver's task_struct causing the crash.

do_mq_timedsend::__pipelined_op() should not dereference this after setting STATE_READY, as the receiver counterpart is now free to return. Change __pipelined_op to call wake_q_add_safe on the receiver's task_struct returned by get_task_struct, instead of dereferencing this which sits on the receiver's stack.

As Manfred pointed out, the race potentially also exists in ipc/msg.c::expunge_all and ipc/sem.c::wake_up_sem_queue_prepare. Fix those in the same way.

Severity

7.0 (High)


                  
                    CVSS:3.1/AV:L/AC:H/PR:L/UI:N/S:U/C:H/I:H/A:H

Show details on source website

JSON

To clipboard

{
  "affected": [],
  "aliases": [
    "CVE-2021-47069"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-672"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2024-03-01T22:15:46Z",
    "severity": "HIGH"
  },
  "details": "In the Linux kernel, the following vulnerability has been resolved:\n\nipc/mqueue, msg, sem: avoid relying on a stack reference past its expiry\n\ndo_mq_timedreceive calls wq_sleep with a stack local address.  The\nsender (do_mq_timedsend) uses this address to later call pipelined_send.\n\nThis leads to a very hard to trigger race where a do_mq_timedreceive\ncall might return and leave do_mq_timedsend to rely on an invalid\naddress, causing the following crash:\n\n  RIP: 0010:wake_q_add_safe+0x13/0x60\n  Call Trace:\n   __x64_sys_mq_timedsend+0x2a9/0x490\n   do_syscall_64+0x80/0x680\n   entry_SYSCALL_64_after_hwframe+0x44/0xa9\n  RIP: 0033:0x7f5928e40343\n\nThe race occurs as:\n\n1. do_mq_timedreceive calls wq_sleep with the address of `struct\n   ext_wait_queue` on function stack (aliased as `ewq_addr` here) - it\n   holds a valid `struct ext_wait_queue *` as long as the stack has not\n   been overwritten.\n\n2. `ewq_addr` gets added to info-\u003ee_wait_q[RECV].list in wq_add, and\n   do_mq_timedsend receives it via wq_get_first_waiter(info, RECV) to call\n   __pipelined_op.\n\n3. Sender calls __pipelined_op::smp_store_release(\u0026this-\u003estate,\n   STATE_READY).  Here is where the race window begins.  (`this` is\n   `ewq_addr`.)\n\n4. If the receiver wakes up now in do_mq_timedreceive::wq_sleep, it\n   will see `state == STATE_READY` and break.\n\n5. do_mq_timedreceive returns, and `ewq_addr` is no longer guaranteed\n   to be a `struct ext_wait_queue *` since it was on do_mq_timedreceive\u0027s\n   stack.  (Although the address may not get overwritten until another\n   function happens to touch it, which means it can persist around for an\n   indefinite time.)\n\n6. do_mq_timedsend::__pipelined_op() still believes `ewq_addr` is a\n   `struct ext_wait_queue *`, and uses it to find a task_struct to pass to\n   the wake_q_add_safe call.  In the lucky case where nothing has\n   overwritten `ewq_addr` yet, `ewq_addr-\u003etask` is the right task_struct.\n   In the unlucky case, __pipelined_op::wake_q_add_safe gets handed a\n   bogus address as the receiver\u0027s task_struct causing the crash.\n\ndo_mq_timedsend::__pipelined_op() should not dereference `this` after\nsetting STATE_READY, as the receiver counterpart is now free to return.\nChange __pipelined_op to call wake_q_add_safe on the receiver\u0027s\ntask_struct returned by get_task_struct, instead of dereferencing `this`\nwhich sits on the receiver\u0027s stack.\n\nAs Manfred pointed out, the race potentially also exists in\nipc/msg.c::expunge_all and ipc/sem.c::wake_up_sem_queue_prepare.  Fix\nthose in the same way.",
  "id": "GHSA-47fv-c4cg-c767",
  "modified": "2025-01-09T18:32:06Z",
  "published": "2024-03-02T00:31:30Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2021-47069"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/4528c0c323085e645b8765913b4a7fd42cf49b65"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/807fa14536b26803b858da878b643be72952a097"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/a11ddb37bf367e6b5239b95ca759e5389bb46048"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:L/AC:H/PR:L/UI:N/S:U/C:H/I:H/A:H",
      "type": "CVSS_V3"
    }
  ]
}

GHSA-48GG-32Q2-4R6M

Vulnerability from github – Published: 2024-08-25 03:30 – Updated: 2025-10-13 15:12

Summary

Hyperledger Fabric does not verify request has a timestamp within the expected time window

Details

Hyperledger Fabric through 2.5.9 does not verify that a request has a timestamp within the expected time window.

Severity

5.4 (Medium)


                  
                    CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:L/I:L/A:N

5.3 (Medium)


                  
                    CVSS:4.0/AV:N/AC:L/AT:N/PR:L/UI:N/VC:L/VI:L/VA:N/SC:N/SI:N/SA:N

Show details on source website

JSON

To clipboard

{
  "affected": [
    {
      "package": {
        "ecosystem": "Go",
        "name": "github.com/hyperledger/fabric"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "last_affected": "2.5.9"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2024-45244"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-285",
      "CWE-294",
      "CWE-672"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2024-08-26T14:56:07Z",
    "nvd_published_at": "2024-08-25T02:15:03Z",
    "severity": "MODERATE"
  },
  "details": "Hyperledger Fabric through 2.5.9 does not verify that a request has a timestamp within the expected time window.",
  "id": "GHSA-48gg-32q2-4r6m",
  "modified": "2025-10-13T15:12:40Z",
  "published": "2024-08-25T03:30:32Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-45244"
    },
    {
      "type": "WEB",
      "url": "https://github.com/hyperledger/fabric/commit/155457a6624b3c74b22e5729c35c8499bfe952cd"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/hyperledger/fabric"
    },
    {
      "type": "WEB",
      "url": "https://github.com/shanker-sec/HLF_TxTime_spoofing"
    },
    {
      "type": "WEB",
      "url": "https://github.com/shanker-sec/hlf-time-oracle"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:L/I:L/A:N",
      "type": "CVSS_V3"
    },
    {
      "score": "CVSS:4.0/AV:N/AC:L/AT:N/PR:L/UI:N/VC:L/VI:L/VA:N/SC:N/SI:N/SA:N",
      "type": "CVSS_V4"
    }
  ],
  "summary": "Hyperledger Fabric does not verify request has a timestamp within the expected time window"
}

GHSA-4HF6-3X24-C9M8

Vulnerability from github – Published: 2026-03-11 00:35 – Updated: 2026-03-11 20:57

Summary

Parse Server's MFA recovery codes not consumed after use

Details

Impact

When multi-factor authentication (MFA) via TOTP is enabled for a user account, Parse Server generates two single-use recovery codes. These codes are intended as a fallback when the user cannot provide a TOTP token. However, recovery codes are not consumed after use, allowing the same recovery code to be used an unlimited number of times. This defeats the single-use design of recovery codes and weakens the security of MFA-protected accounts.

An attacker who obtains a single recovery code can repeatedly authenticate as the affected user without the code ever being invalidated.

Patches

The fix ensures that each recovery code is removed from the stored recovery code list after a successful login.

Workarounds

There is no known workaround.

References

GitHub security advisory: https://github.com/parse-community/parse-server/security/advisories/GHSA-4hf6-3x24-c9m8
Fix Parse Server 9: https://github.com/parse-community/parse-server/releases/tag/9.6.0-alpha.7
Fix Parse Server 8: https://github.com/parse-community/parse-server/releases/tag/8.6.33

Severity

8.2 (High)


                  
                    CVSS:4.0/AV:N/AC:H/AT:P/PR:N/UI:N/VC:H/VI:N/VA:N/SC:N/SI:N/SA:N

Show details on source website

JSON

To clipboard

{
  "affected": [
    {
      "package": {
        "ecosystem": "npm",
        "name": "parse-server"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "9.0.0-alpha.1"
            },
            {
              "fixed": "9.6.0-alpha.7"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    },
    {
      "package": {
        "ecosystem": "npm",
        "name": "parse-server"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "8.6.33"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2026-31875"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-672"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2026-03-11T00:35:41Z",
    "nvd_published_at": "2026-03-11T18:16:27Z",
    "severity": "HIGH"
  },
  "details": "### Impact\n\nWhen multi-factor authentication (MFA) via TOTP is enabled for a user account, Parse Server generates two single-use recovery codes. These codes are intended as a fallback when the user cannot provide a TOTP token. However, recovery codes are not consumed after use, allowing the same recovery code to be used an unlimited number of times. This defeats the single-use design of recovery codes and weakens the security of MFA-protected accounts.\n\nAn attacker who obtains a single recovery code can repeatedly authenticate as the affected user without the code ever being invalidated.\n\n### Patches\n\nThe fix ensures that each recovery code is removed from the stored recovery code list after a successful login.\n\n### Workarounds\n\nThere is no known workaround.\n\n### References\n\n- GitHub security advisory: https://github.com/parse-community/parse-server/security/advisories/GHSA-4hf6-3x24-c9m8\n- Fix Parse Server 9: https://github.com/parse-community/parse-server/releases/tag/9.6.0-alpha.7\n- Fix Parse Server 8: https://github.com/parse-community/parse-server/releases/tag/8.6.33",
  "id": "GHSA-4hf6-3x24-c9m8",
  "modified": "2026-03-11T20:57:55Z",
  "published": "2026-03-11T00:35:41Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/parse-community/parse-server/security/advisories/GHSA-4hf6-3x24-c9m8"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-31875"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/parse-community/parse-server"
    },
    {
      "type": "WEB",
      "url": "https://github.com/parse-community/parse-server/releases/tag/8.6.33"
    },
    {
      "type": "WEB",
      "url": "https://github.com/parse-community/parse-server/releases/tag/9.6.0-alpha.7"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:4.0/AV:N/AC:H/AT:P/PR:N/UI:N/VC:H/VI:N/VA:N/SC:N/SI:N/SA:N",
      "type": "CVSS_V4"
    }
  ],
  "summary": "Parse Server\u0027s MFA recovery codes not consumed after use"
}

GHSA-4VC6-7QHX-WXQ5

Vulnerability from github – Published: 2024-12-27 15:31 – Updated: 2025-01-06 15:30

Details

In the Linux kernel, the following vulnerability has been resolved:

virtio_net: correct netdev_tx_reset_queue() invocation point

When virtnet_close is followed by virtnet_open, some TX completions can possibly remain unconsumed, until they are finally processed during the first NAPI poll after the netdev_tx_reset_queue(), resulting in a crash [1]. Commit b96ed2c97c79 ("virtio_net: move netdev_tx_reset_queue() call before RX napi enable") was not sufficient to eliminate all BQL crash cases for virtio-net.

This issue can be reproduced with the latest net-next master by running: while :; do ip l set DEV down; ip l set DEV up; done under heavy network TX load from inside the machine.

netdev_tx_reset_queue() can actually be dropped from virtnet_open path; the device is not stopped in any case. For BQL core part, it's just like traffic nearly ceases to exist for some period. For stall detector added to BQL, even if virtnet_close could somehow lead to some TX completions delayed for long, followed by virtnet_open, we can just take it as stall as mentioned in commit 6025b9135f7a ("net: dqs: add NIC stall detector based on BQL"). Note also that users can still reset stall_max via sysfs.

So, drop netdev_tx_reset_queue() from virtnet_enable_queue_pair(). This eliminates the BQL crashes. As a result, netdev_tx_reset_queue() is now explicitly required in freeze/restore path. This patch adds it to immediately after free_unused_bufs(), following the rule of thumb: netdev_tx_reset_queue() should follow any SKB freeing not followed by netdev_tx_completed_queue(). This seems the most consistent and streamlined approach, and now netdev_tx_reset_queue() runs whenever free_unused_bufs() is done.

[1]: ------------[ cut here ]------------ kernel BUG at lib/dynamic_queue_limits.c:99! Oops: invalid opcode: 0000 [#1] PREEMPT SMP NOPTI CPU: 7 UID: 0 PID: 1598 Comm: ip Tainted: G N 6.12.0net-next_main+ #2 Tainted: [N]=TEST Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), \ BIOS rel-1.16.3-0-ga6ed6b701f0a-prebuilt.qemu.org 04/01/2014 RIP: 0010:dql_completed+0x26b/0x290 Code: b7 c2 49 89 e9 44 89 da 89 c6 4c 89 d7 e8 ed 17 47 00 58 65 ff 0d 4d 27 90 7e 0f 85 fd fe ff ff e8 ea 53 8d ff e9 f3 fe ff ff <0f> 0b 01 d2 44 89 d1 29 d1 ba 00 00 00 00 0f 48 ca e9 28 ff ff ff RSP: 0018:ffffc900002b0d08 EFLAGS: 00010297 RAX: 0000000000000000 RBX: ffff888102398c80 RCX: 0000000080190009 RDX: 0000000000000000 RSI: 000000000000006a RDI: 0000000000000000 RBP: ffff888102398c00 R08: 0000000000000000 R09: 0000000000000000 R10: 00000000000000ca R11: 0000000000015681 R12: 0000000000000001 R13: ffffc900002b0d68 R14: ffff88811115e000 R15: ffff8881107aca40 FS: 00007f41ded69500(0000) GS:ffff888667dc0000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 0000556ccc2dc1a0 CR3: 0000000104fd8003 CR4: 0000000000772ef0 PKRU: 55555554 Call Trace: ? die+0x32/0x80 ? do_trap+0xd9/0x100 ? dql_completed+0x26b/0x290 ? dql_completed+0x26b/0x290 ? do_error_trap+0x6d/0xb0 ? dql_completed+0x26b/0x290 ? exc_invalid_op+0x4c/0x60 ? dql_completed+0x26b/0x290 ? asm_exc_invalid_op+0x16/0x20 ? dql_completed+0x26b/0x290 __free_old_xmit+0xff/0x170 [virtio_net] free_old_xmit+0x54/0xc0 [virtio_net] virtnet_poll+0xf4/0xe30 [virtio_net] ? __update_load_avg_cfs_rq+0x264/0x2d0 ? update_curr+0x35/0x260 ? reweight_entity+0x1be/0x260 __napi_poll.constprop.0+0x28/0x1c0 net_rx_action+0x329/0x420 ? enqueue_hrtimer+0x35/0x90 ? trace_hardirqs_on+0x1d/0x80 ? kvm_sched_clock_read+0xd/0x20 ? sched_clock+0xc/0x30 ? kvm_sched_clock_read+0xd/0x20 ? sched_clock+0xc/0x30 ? sched_clock_cpu+0xd/0x1a0 handle_softirqs+0x138/0x3e0 do_softirq.part.0+0x89/0xc0 __local_bh_enable_ip+0xa7/0xb0 virtnet_open+0xc8/0x310 [virtio_net] __dev_open+0xfa/0x1b0 __dev_change_flags+0x1de/0x250 dev_change_flags+0x22/0x60 do_setlink.isra.0+0x2df/0x10b0 ? rtnetlink_rcv_msg+0x34f/0x3f0 ? netlink_rcv_skb+0x54/0x100 ? netlink_unicas ---truncated---

Severity

5.5 (Medium)


                  
                    CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H

Show details on source website

JSON

To clipboard

{
  "affected": [],
  "aliases": [
    "CVE-2024-56674"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-672"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2024-12-27T15:15:27Z",
    "severity": "MODERATE"
  },
  "details": "In the Linux kernel, the following vulnerability has been resolved:\n\nvirtio_net: correct netdev_tx_reset_queue() invocation point\n\nWhen virtnet_close is followed by virtnet_open, some TX completions can\npossibly remain unconsumed, until they are finally processed during the\nfirst NAPI poll after the netdev_tx_reset_queue(), resulting in a crash\n[1]. Commit b96ed2c97c79 (\"virtio_net: move netdev_tx_reset_queue() call\nbefore RX napi enable\") was not sufficient to eliminate all BQL crash\ncases for virtio-net.\n\nThis issue can be reproduced with the latest net-next master by running:\n`while :; do ip l set DEV down; ip l set DEV up; done` under heavy network\nTX load from inside the machine.\n\nnetdev_tx_reset_queue() can actually be dropped from virtnet_open path;\nthe device is not stopped in any case. For BQL core part, it\u0027s just like\ntraffic nearly ceases to exist for some period. For stall detector added\nto BQL, even if virtnet_close could somehow lead to some TX completions\ndelayed for long, followed by virtnet_open, we can just take it as stall\nas mentioned in commit 6025b9135f7a (\"net: dqs: add NIC stall detector\nbased on BQL\"). Note also that users can still reset stall_max via sysfs.\n\nSo, drop netdev_tx_reset_queue() from virtnet_enable_queue_pair(). This\neliminates the BQL crashes. As a result, netdev_tx_reset_queue() is now\nexplicitly required in freeze/restore path. This patch adds it to\nimmediately after free_unused_bufs(), following the rule of thumb:\nnetdev_tx_reset_queue() should follow any SKB freeing not followed by\nnetdev_tx_completed_queue(). This seems the most consistent and\nstreamlined approach, and now netdev_tx_reset_queue() runs whenever\nfree_unused_bufs() is done.\n\n[1]:\n------------[ cut here ]------------\nkernel BUG at lib/dynamic_queue_limits.c:99!\nOops: invalid opcode: 0000 [#1] PREEMPT SMP NOPTI\nCPU: 7 UID: 0 PID: 1598 Comm: ip Tainted: G    N 6.12.0net-next_main+ #2\nTainted: [N]=TEST\nHardware name: QEMU Standard PC (Q35 + ICH9, 2009), \\\nBIOS rel-1.16.3-0-ga6ed6b701f0a-prebuilt.qemu.org 04/01/2014\nRIP: 0010:dql_completed+0x26b/0x290\nCode: b7 c2 49 89 e9 44 89 da 89 c6 4c 89 d7 e8 ed 17 47 00 58 65 ff 0d\n4d 27 90 7e 0f 85 fd fe ff ff e8 ea 53 8d ff e9 f3 fe ff ff \u003c0f\u003e 0b 01\nd2 44 89 d1 29 d1 ba 00 00 00 00 0f 48 ca e9 28 ff ff ff\nRSP: 0018:ffffc900002b0d08 EFLAGS: 00010297\nRAX: 0000000000000000 RBX: ffff888102398c80 RCX: 0000000080190009\nRDX: 0000000000000000 RSI: 000000000000006a RDI: 0000000000000000\nRBP: ffff888102398c00 R08: 0000000000000000 R09: 0000000000000000\nR10: 00000000000000ca R11: 0000000000015681 R12: 0000000000000001\nR13: ffffc900002b0d68 R14: ffff88811115e000 R15: ffff8881107aca40\nFS:  00007f41ded69500(0000) GS:ffff888667dc0000(0000)\nknlGS:0000000000000000\nCS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033\nCR2: 0000556ccc2dc1a0 CR3: 0000000104fd8003 CR4: 0000000000772ef0\nPKRU: 55555554\nCall Trace:\n \u003cIRQ\u003e\n ? die+0x32/0x80\n ? do_trap+0xd9/0x100\n ? dql_completed+0x26b/0x290\n ? dql_completed+0x26b/0x290\n ? do_error_trap+0x6d/0xb0\n ? dql_completed+0x26b/0x290\n ? exc_invalid_op+0x4c/0x60\n ? dql_completed+0x26b/0x290\n ? asm_exc_invalid_op+0x16/0x20\n ? dql_completed+0x26b/0x290\n __free_old_xmit+0xff/0x170 [virtio_net]\n free_old_xmit+0x54/0xc0 [virtio_net]\n virtnet_poll+0xf4/0xe30 [virtio_net]\n ? __update_load_avg_cfs_rq+0x264/0x2d0\n ? update_curr+0x35/0x260\n ? reweight_entity+0x1be/0x260\n __napi_poll.constprop.0+0x28/0x1c0\n net_rx_action+0x329/0x420\n ? enqueue_hrtimer+0x35/0x90\n ? trace_hardirqs_on+0x1d/0x80\n ? kvm_sched_clock_read+0xd/0x20\n ? sched_clock+0xc/0x30\n ? kvm_sched_clock_read+0xd/0x20\n ? sched_clock+0xc/0x30\n ? sched_clock_cpu+0xd/0x1a0\n handle_softirqs+0x138/0x3e0\n do_softirq.part.0+0x89/0xc0\n \u003c/IRQ\u003e\n \u003cTASK\u003e\n __local_bh_enable_ip+0xa7/0xb0\n virtnet_open+0xc8/0x310 [virtio_net]\n __dev_open+0xfa/0x1b0\n __dev_change_flags+0x1de/0x250\n dev_change_flags+0x22/0x60\n do_setlink.isra.0+0x2df/0x10b0\n ? rtnetlink_rcv_msg+0x34f/0x3f0\n ? netlink_rcv_skb+0x54/0x100\n ? netlink_unicas\n---truncated---",
  "id": "GHSA-4vc6-7qhx-wxq5",
  "modified": "2025-01-06T15:30:59Z",
  "published": "2024-12-27T15:31:56Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-56674"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/3ddccbefebdbe0c4c72a248676e4d39ac66a8e26"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/b4294d4ac61fbb382811a1d64eaf81f446ce2af4"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H",
      "type": "CVSS_V3"
    }
  ]
}

GHSA-53RQ-74J9-R638

Vulnerability from github – Published: 2022-05-13 01:43 – Updated: 2022-05-13 01:43

Details

In Android for MSM, Firefox OS for MSM, QRD Android, with all Android releases from CAF using the Linux kernel, after a subsystem reset, iwpriv is not giving correct information.

Severity

7.8 (High)


                  
                    CVSS:3.0/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H

Show details on source website

JSON

To clipboard

{
  "affected": [],
  "aliases": [
    "CVE-2017-14895"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-672"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2017-12-05T19:29:00Z",
    "severity": "HIGH"
  },
  "details": "In Android for MSM, Firefox OS for MSM, QRD Android, with all Android releases from CAF using the Linux kernel, after a subsystem reset, iwpriv is not giving correct information.",
  "id": "GHSA-53rq-74j9-r638",
  "modified": "2022-05-13T01:43:31Z",
  "published": "2022-05-13T01:43:31Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2017-14895"
    },
    {
      "type": "WEB",
      "url": "https://source.android.com/security/bulletin/2017-12-01"
    },
    {
      "type": "WEB",
      "url": "http://www.securityfocus.com/bid/102073"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.0/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H",
      "type": "CVSS_V3"
    }
  ]
}

GHSA-5597-7RMH-97Q5

Vulnerability from github – Published: 2026-07-09 21:03 – Updated: 2026-07-09 21:03

Summary

Sylius: Cart FormComponent allows modification or deletion of an already-completed order

Details

Impact

A user opens the cart page in the browser. In the background, the order gets completed, e.g. an admin changes the status, or the user finalizes payment in another tab. The browser still displays the old cart: the LiveComponent is unaware the underlying order state has changed.

If the user then:

clears the cart → clearCart() calls manager->remove() on the completed order: the order is permanently deleted from the database;
removes a product → removeItem() mutates an item on the completed order;
changes quantity → saveCart() overwrites data on the completed order.

In all cases, the customer's order data is irreversibly corrupted or lost, even though the order has already been placed and paid for. The same vector can be triggered deliberately by an authenticated customer (keep the cart page open, complete checkout in another tab, then modify the "cart" to add quantity beyond what was paid for).

Patches

The issue is fixed in versions: 2.0.18, 2.1.15, 2.2.6 and above.

Workarounds

If users cannot update Sylius immediately, they should create a patched copy of the affected class in their application's src/ directory and override the Sylius service definition to use it.

Step 1. Create `src/Twig/Component/Cart/FormComponent.php`

<?php

declare(strict_types=1);

namespace App\Twig\Component\Cart;

use Doctrine\Persistence\ObjectManager;
use Sylius\Bundle\UiBundle\Twig\Component\ResourceFormComponentTrait;
use Sylius\Bundle\UiBundle\Twig\Component\TemplatePropTrait;
use Sylius\Component\Core\Model\OrderInterface;
use Sylius\Component\Core\OrderCheckoutStates;
use Sylius\Component\Core\Repository\OrderRepositoryInterface;
use Sylius\Component\Order\SyliusCartEvents;
use Sylius\Resource\Model\ResourceInterface;
use Symfony\Component\EventDispatcher\EventDispatcherInterface;
use Symfony\Component\EventDispatcher\GenericEvent;
use Symfony\Component\Form\FormFactoryInterface;
use Symfony\UX\LiveComponent\Attribute\LiveAction;
use Symfony\UX\LiveComponent\Attribute\LiveArg;
use Symfony\UX\LiveComponent\Attribute\PreReRender;
use Symfony\UX\LiveComponent\ComponentToolsTrait;

class FormComponent
{
    use ComponentToolsTrait;

    /** @use ResourceFormComponentTrait<OrderInterface> */
    use ResourceFormComponentTrait;

    use TemplatePropTrait;

    public const SYLIUS_SHOP_CART_CHANGED = 'sylius:shop:cart_changed';

    public const SYLIUS_SHOP_CART_CLEARED = 'sylius:shop:cart_cleared';

    public bool $shouldSaveCart = true;

    /** @param OrderRepositoryInterface<OrderInterface> $orderRepository */
    public function __construct(
        OrderRepositoryInterface $orderRepository,
        FormFactoryInterface $formFactory,
        string $resourceClass,
        string $formClass,
        protected readonly ObjectManager $manager,
        protected readonly EventDispatcherInterface $eventDispatcher,
    ) {
        $this->initialize($orderRepository, $formFactory, $resourceClass, $formClass);
    }

    public function hydrateResource(mixed $value): ?ResourceInterface
    {
        if (empty($value)) {
            return $this->createResource();
        }

        /** @var OrderInterface|null $order */
        $order = $this->repository->find($value);

        if (
            !$order instanceof OrderInterface
            || $order->getCheckoutState() === OrderCheckoutStates::STATE_COMPLETED
        ) {
            return $this->createResource();
        }

        return $order;
    }

    #[PreReRender(priority: -100)]
    public function saveCart(): void
    {
        if ($this->shouldSaveCart && $this->resource?->getId() !== null) {
            $form = $this->getForm();
            if ($form->isValid()) {
                $this->eventDispatcher->dispatch(new GenericEvent($form->getData()), SyliusCartEvents::CART_CHANGE);
                $this->manager->flush();
                $this->emit(self::SYLIUS_SHOP_CART_CHANGED, ['cartId' => $this->resource->getId()]);
            }
        }
    }

    #[LiveAction]
    public function removeItem(#[LiveArg] int $index): void
    {
        if ($this->resource?->getId() === null) {
            return;
        }

        $data = $this->formValues['items'];
        unset($data[$index]);
        $this->formValues['items'] = array_values($data);

        $orderItem = $this->resource->getItems()->get($index);
        $this->eventDispatcher->dispatch(new GenericEvent($orderItem), SyliusCartEvents::CART_ITEM_REMOVE);

        $this->manager->persist($this->resource);
        $this->manager->flush();
        $this->manager->refresh($this->resource);

        $this->shouldSaveCart = false;
        $this->submitForm();
        $this->emit(self::SYLIUS_SHOP_CART_CHANGED, ['cartId' => $this->resource->getId()]);
    }

    #[LiveAction]
    public function clearCart(): void
    {
        if ($this->resource?->getId() === null) {
            return;
        }

        $this->formValues['items'] = [];
        $this->eventDispatcher->dispatch(new GenericEvent($this->resource), SyliusCartEvents::CART_CLEAR);
        $this->manager->remove($this->resource);
        $this->manager->flush();

        $this->resource = $this->createResource();
        $this->resetForm();
        $this->isValidated = false;
        $this->validatedFields = [];

        $this->shouldSaveCart = false;
        $this->submitForm();
        $this->emit(self::SYLIUS_SHOP_CART_CLEARED);
    }

    #[LiveAction]
    public function removeCoupon(): void
    {
        $this->formValues['promotionCoupon'] = '';

        $this->submitForm();
    }

    private function getDataModelValue(): string
    {
        return 'debounce(500)|*';
    }
}

Step 2. Override the Sylius service in `config/services.yaml`

Append to the application's config/services.yaml (or a dedicated file loaded by the kernel, e.g. config/packages/sylius_security_cart.yaml):

services:
    sylius_shop.twig.component.cart.form:
        class: App\Twig\Component\Cart\FormComponent
        arguments:
            - '@sylius.repository.order'
            - '@form.factory'
            - '%sylius.model.order.class%'
            - 'Sylius\Bundle\ShopBundle\Form\Type\CartType'
            - '@doctrine.orm.entity_manager'
            - '@event_dispatcher'
        calls:
            - [setLiveResponder, ['@ux.live_component.live_responder']]
        tags:
            - { name: sylius.live_component.shop, key: 'sylius_shop:cart:form' }

This redeclares the existing Sylius service id sylius_shop.twig.component.cart.form so it instantiates the patched class from App\ while preserving every argument, call and tag from the original Sylius XML definition. The cart twig hook keeps resolving to the same Live Component key (sylius_shop:cart:form).

Step 3. Clear the cache

bin/console cache:clear

Reporters

We would like to extend our gratitude to the following individuals for their detailed reporting and responsible disclosure of this vulnerability: - Kévin Gonella (@kgonella) - Sam V.

For more information

If there are any questions or comments about this advisory:

Open an issue in Sylius issues
Send an email to security@sylius.com

Severity

6.5 (Medium)


                  
                    CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:N/I:H/A:N

Show details on source website

JSON

To clipboard

{
  "affected": [
    {
      "package": {
        "ecosystem": "Packagist",
        "name": "sylius/sylius"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "2.0.0"
            },
            {
              "fixed": "2.0.18"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    },
    {
      "package": {
        "ecosystem": "Packagist",
        "name": "sylius/sylius"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "2.1.0"
            },
            {
              "fixed": "2.1.15"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    },
    {
      "package": {
        "ecosystem": "Packagist",
        "name": "sylius/sylius"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "2.2.0"
            },
            {
              "fixed": "2.2.6"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2026-53637"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-672",
      "CWE-841"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2026-07-09T21:03:41Z",
    "nvd_published_at": null,
    "severity": "MODERATE"
  },
  "details": "### Impact\nA user opens the cart page in the browser. In the background, the order gets completed, e.g. an admin changes the status, or the user finalizes payment in another tab. The browser still displays the old cart: the LiveComponent is unaware the underlying order state has changed.\n\nIf the user then:\n\n- **clears the cart** \u2192 `clearCart()` calls `manager-\u003eremove()` on the\n  completed order: the order is permanently **deleted** from the database;\n- **removes a product** \u2192 `removeItem()` mutates an item on the completed\n  order;\n- **changes quantity** \u2192 `saveCart()` overwrites data on the completed order.\n\nIn all cases, the customer\u0027s order data is irreversibly corrupted or lost, even though the order has already been placed and paid for. The same vector can be triggered deliberately by an authenticated customer (keep the cart page open, complete checkout in another tab, then modify the \"cart\" to add quantity beyond what was paid for).\n\n### Patches\nThe issue is fixed in versions: 2.0.18, 2.1.15, 2.2.6 and above.\n\n### Workarounds\nIf users cannot update Sylius immediately, they should create a patched copy of the affected class in their application\u0027s `src/` directory and override the Sylius service definition to use it.\n\n#### Step 1. Create `src/Twig/Component/Cart/FormComponent.php`\n\n```php\n\u003c?php\n\ndeclare(strict_types=1);\n\nnamespace App\\Twig\\Component\\Cart;\n\nuse Doctrine\\Persistence\\ObjectManager;\nuse Sylius\\Bundle\\UiBundle\\Twig\\Component\\ResourceFormComponentTrait;\nuse Sylius\\Bundle\\UiBundle\\Twig\\Component\\TemplatePropTrait;\nuse Sylius\\Component\\Core\\Model\\OrderInterface;\nuse Sylius\\Component\\Core\\OrderCheckoutStates;\nuse Sylius\\Component\\Core\\Repository\\OrderRepositoryInterface;\nuse Sylius\\Component\\Order\\SyliusCartEvents;\nuse Sylius\\Resource\\Model\\ResourceInterface;\nuse Symfony\\Component\\EventDispatcher\\EventDispatcherInterface;\nuse Symfony\\Component\\EventDispatcher\\GenericEvent;\nuse Symfony\\Component\\Form\\FormFactoryInterface;\nuse Symfony\\UX\\LiveComponent\\Attribute\\LiveAction;\nuse Symfony\\UX\\LiveComponent\\Attribute\\LiveArg;\nuse Symfony\\UX\\LiveComponent\\Attribute\\PreReRender;\nuse Symfony\\UX\\LiveComponent\\ComponentToolsTrait;\n\nclass FormComponent\n{\n    use ComponentToolsTrait;\n\n    /** @use ResourceFormComponentTrait\u003cOrderInterface\u003e */\n    use ResourceFormComponentTrait;\n\n    use TemplatePropTrait;\n\n    public const SYLIUS_SHOP_CART_CHANGED = \u0027sylius:shop:cart_changed\u0027;\n\n    public const SYLIUS_SHOP_CART_CLEARED = \u0027sylius:shop:cart_cleared\u0027;\n\n    public bool $shouldSaveCart = true;\n\n    /** @param OrderRepositoryInterface\u003cOrderInterface\u003e $orderRepository */\n    public function __construct(\n        OrderRepositoryInterface $orderRepository,\n        FormFactoryInterface $formFactory,\n        string $resourceClass,\n        string $formClass,\n        protected readonly ObjectManager $manager,\n        protected readonly EventDispatcherInterface $eventDispatcher,\n    ) {\n        $this-\u003einitialize($orderRepository, $formFactory, $resourceClass, $formClass);\n    }\n\n    public function hydrateResource(mixed $value): ?ResourceInterface\n    {\n        if (empty($value)) {\n            return $this-\u003ecreateResource();\n        }\n\n        /** @var OrderInterface|null $order */\n        $order = $this-\u003erepository-\u003efind($value);\n\n        if (\n            !$order instanceof OrderInterface\n            || $order-\u003egetCheckoutState() === OrderCheckoutStates::STATE_COMPLETED\n        ) {\n            return $this-\u003ecreateResource();\n        }\n\n        return $order;\n    }\n\n    #[PreReRender(priority: -100)]\n    public function saveCart(): void\n    {\n        if ($this-\u003eshouldSaveCart \u0026\u0026 $this-\u003eresource?-\u003egetId() !== null) {\n            $form = $this-\u003egetForm();\n            if ($form-\u003eisValid()) {\n                $this-\u003eeventDispatcher-\u003edispatch(new GenericEvent($form-\u003egetData()), SyliusCartEvents::CART_CHANGE);\n                $this-\u003emanager-\u003eflush();\n                $this-\u003eemit(self::SYLIUS_SHOP_CART_CHANGED, [\u0027cartId\u0027 =\u003e $this-\u003eresource-\u003egetId()]);\n            }\n        }\n    }\n\n    #[LiveAction]\n    public function removeItem(#[LiveArg] int $index): void\n    {\n        if ($this-\u003eresource?-\u003egetId() === null) {\n            return;\n        }\n\n        $data = $this-\u003eformValues[\u0027items\u0027];\n        unset($data[$index]);\n        $this-\u003eformValues[\u0027items\u0027] = array_values($data);\n\n        $orderItem = $this-\u003eresource-\u003egetItems()-\u003eget($index);\n        $this-\u003eeventDispatcher-\u003edispatch(new GenericEvent($orderItem), SyliusCartEvents::CART_ITEM_REMOVE);\n\n        $this-\u003emanager-\u003epersist($this-\u003eresource);\n        $this-\u003emanager-\u003eflush();\n        $this-\u003emanager-\u003erefresh($this-\u003eresource);\n\n        $this-\u003eshouldSaveCart = false;\n        $this-\u003esubmitForm();\n        $this-\u003eemit(self::SYLIUS_SHOP_CART_CHANGED, [\u0027cartId\u0027 =\u003e $this-\u003eresource-\u003egetId()]);\n    }\n\n    #[LiveAction]\n    public function clearCart(): void\n    {\n        if ($this-\u003eresource?-\u003egetId() === null) {\n            return;\n        }\n\n        $this-\u003eformValues[\u0027items\u0027] = [];\n        $this-\u003eeventDispatcher-\u003edispatch(new GenericEvent($this-\u003eresource), SyliusCartEvents::CART_CLEAR);\n        $this-\u003emanager-\u003eremove($this-\u003eresource);\n        $this-\u003emanager-\u003eflush();\n\n        $this-\u003eresource = $this-\u003ecreateResource();\n        $this-\u003eresetForm();\n        $this-\u003eisValidated = false;\n        $this-\u003evalidatedFields = [];\n\n        $this-\u003eshouldSaveCart = false;\n        $this-\u003esubmitForm();\n        $this-\u003eemit(self::SYLIUS_SHOP_CART_CLEARED);\n    }\n\n    #[LiveAction]\n    public function removeCoupon(): void\n    {\n        $this-\u003eformValues[\u0027promotionCoupon\u0027] = \u0027\u0027;\n\n        $this-\u003esubmitForm();\n    }\n\n    private function getDataModelValue(): string\n    {\n        return \u0027debounce(500)|*\u0027;\n    }\n}\n```\n\n#### Step 2. Override the Sylius service in `config/services.yaml`\n\nAppend to the application\u0027s `config/services.yaml` (or a dedicated file loaded by the kernel, e.g. `config/packages/sylius_security_cart.yaml`):\n\n```yaml\nservices:\n    sylius_shop.twig.component.cart.form:\n        class: App\\Twig\\Component\\Cart\\FormComponent\n        arguments:\n            - \u0027@sylius.repository.order\u0027\n            - \u0027@form.factory\u0027\n            - \u0027%sylius.model.order.class%\u0027\n            - \u0027Sylius\\Bundle\\ShopBundle\\Form\\Type\\CartType\u0027\n            - \u0027@doctrine.orm.entity_manager\u0027\n            - \u0027@event_dispatcher\u0027\n        calls:\n            - [setLiveResponder, [\u0027@ux.live_component.live_responder\u0027]]\n        tags:\n            - { name: sylius.live_component.shop, key: \u0027sylius_shop:cart:form\u0027 }\n```\n\nThis redeclares the existing Sylius service id `sylius_shop.twig.component.cart.form` so it instantiates the patched class from `App\\` while preserving every argument, call and tag from the original Sylius XML definition. The cart twig hook keeps resolving to the same Live Component key (`sylius_shop:cart:form`).\n\n#### Step 3. Clear the cache\n\n```bash\nbin/console cache:clear\n```\n\n### Reporters\n\nWe would like to extend our gratitude to the following individuals for their detailed reporting and responsible disclosure of this vulnerability:\n- K\u00e9vin Gonella (@kgonella)\n- Sam V.\n\n### For more information\n\nIf there are any questions or comments about this advisory:\n\n- Open an issue in [Sylius issues](https://github.com/Sylius/Sylius/issues?q=sort%3Aupdated-desc+is%3Aissue+is%3Aopen)\n- Send an email to [security@sylius.com](mailto:security@sylius.com)",
  "id": "GHSA-5597-7rmh-97q5",
  "modified": "2026-07-09T21:03:41Z",
  "published": "2026-07-09T21:03:41Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/Sylius/Sylius/security/advisories/GHSA-5597-7rmh-97q5"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/Sylius/Sylius"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:N/I:H/A:N",
      "type": "CVSS_V3"
    }
  ],
  "summary": "Sylius: Cart FormComponent allows modification or deletion of an already-completed order"
}

GHSA-56P6-QW3C-FQ2G

Vulnerability from github – Published: 2025-03-26 18:30 – Updated: 2025-06-09 18:12

Summary

Suspended Directus user can continue to use session token to access API

Details

Summary

Since the user status is not checked when verifying a session token a suspended user can use the token generated in session auth mode to access the API despite their status.

Details

There is a check missing in verifySessionJWT to verify that a user is actually still active and allowed to access the API. Right now one can extract the session token obtained by, e.g. login in to the app while still active and then, after the user has been suspended continue to use that token until it expires.

PoC

Create an active user
Log in with that user and note the session cookie
Suspend the user (and don't trigger an /auth/refresh call, as that invalidates the session
Access the API with Authorization: Bearer <token>

Impact

This weakens the security of suspending users.

Severity

3.5 (Low)


                  
                    CVSS:3.1/AV:N/AC:L/PR:L/UI:R/S:U/C:L/I:N/A:N

Show details on source website

JSON

To clipboard

{
  "affected": [
    {
      "package": {
        "ecosystem": "npm",
        "name": "directus"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "10.10.0"
            },
            {
              "fixed": "11.5.0"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    },
    {
      "package": {
        "ecosystem": "npm",
        "name": "@directus/api"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "18.0.0"
            },
            {
              "fixed": "24.0.1"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    },
    {
      "package": {
        "ecosystem": "npm",
        "name": "@directus/types"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "11.0.7"
            },
            {
              "fixed": "13.0.0"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2025-30351"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-672"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2025-03-26T18:30:43Z",
    "nvd_published_at": "2025-03-26T18:15:26Z",
    "severity": "LOW"
  },
  "details": "### Summary\nSince the user status is not checked when verifying a session token a suspended user can use the token generated in session auth mode to access the API despite their status.\n\n### Details\nThere is a check missing in `verifySessionJWT` to verify that a user is actually still active and allowed to access the API. Right now one can extract the session token obtained by, e.g. login in to the app while still active and then, after the user has been suspended continue to use that token until it expires.\n\n### PoC\n* Create an active user\n* Log in with that user and note the session cookie\n* Suspend the user (and don\u0027t trigger an `/auth/refresh` call, as that invalidates the session\n* Access the API with `Authorization: Bearer \u003ctoken\u003e`\n\n### Impact\nThis weakens the security of suspending users.",
  "id": "GHSA-56p6-qw3c-fq2g",
  "modified": "2025-06-09T18:12:09Z",
  "published": "2025-03-26T18:30:43Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/directus/directus/security/advisories/GHSA-56p6-qw3c-fq2g"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2025-30351"
    },
    {
      "type": "WEB",
      "url": "https://github.com/directus/directus/commit/ef179931c55b50c110feca8404901d5633940771"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/directus/directus"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:L/UI:R/S:U/C:L/I:N/A:N",
      "type": "CVSS_V3"
    }
  ],
  "summary": "Suspended Directus user can continue to use session token to access API"
}

GHSA-57WX-M636-G3G8

Vulnerability from github – Published: 2024-01-19 22:12 – Updated: 2024-03-01 15:19

Summary

Go package github.com/notaryproject/notation configured with permissive trust policies potentially susceptible to rollback attack from compromised registry

Details

Impact

An external actor with control of a compromised container registry can provide outdated versions of OCI artifacts, such as Images. This could lead artifact consumers with relaxed trust policies (such as permissive instead of strict) to potentially use artifacts with signatures that are no longer valid, making them susceptible to any exploits those artifacts may contain.

Mitigation

In Notary Project, an artifact publisher can control the validity period of artifact by specifying signature expiry during the signing process. Using shorter signature validity periods along with processes to periodically resign artifacts, allows artifact producers to ensure that their consumers will only receive up-to-date artifacts. Artifact consumers should correspondingly use a strict or equivalent trust policy that enforces signature expiry. Together these steps enable use of up-to-date artifacts and safeguard against rollback attack in the event of registry compromise. The Notary Project offers various signature validation options such as permissive, audit and skip to support various scenarios. These scenarios includes 1) situations demanding urgent workload deployment, necessitating the bypassing of expired or revoked signatures; 2) auditing of artifacts lacking signatures without interrupting workload; and 3) skipping of verification for specific images that might have undergone validation through alternative mechanisms.

Additionally, the Notary Project supports revocation to ensure the signature freshness. Artifact publishers can sign with short-lived certificates and revoke older certificates when necessary. This revocation serves as a signal to inform artifact consumers that the corresponding unexpired artifact is no longer approved by the publisher. This enables the artifact publisher to control the validity of the signature independently of their ability to manage artifacts in a compromised registry.

Credit

The Notary Project extends its gratitude to Justin Cappos (@JustinCappos) for responsibly disclosing the issue.

_Note: we have updated threat model to include considerations for rollback attack.

Severity

4.0 (Medium)


                  
                    CVSS:3.1/AV:N/AC:H/PR:H/UI:R/S:C/C:N/I:L/A:L

Show details on source website

JSON

To clipboard

{
  "affected": [
    {
      "package": {
        "ecosystem": "Go",
        "name": "github.com/notaryproject/notation"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "last_affected": "1.0.0"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2024-23332"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-672"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2024-01-19T22:12:22Z",
    "nvd_published_at": "2024-01-19T23:15:07Z",
    "severity": "MODERATE"
  },
  "details": "### Impact\nAn external actor with control of a compromised container registry can provide outdated versions of OCI artifacts, such as Images. This could lead artifact consumers with relaxed trust policies (such as `permissive` instead of `strict`) to potentially use artifacts with signatures that are no longer valid, making them susceptible to any exploits those artifacts may contain.\n\n### Mitigation\nIn Notary Project, an artifact publisher can control the validity period of artifact by specifying signature expiry during the signing process. Using shorter signature validity periods along with processes to periodically resign artifacts, allows artifact producers to ensure that their consumers will only receive up-to-date artifacts. Artifact consumers should correspondingly use a `strict` or equivalent trust policy that enforces signature expiry. Together these steps enable use of up-to-date artifacts and safeguard against rollback attack in the event of registry compromise. The Notary Project offers various signature validation options such as `permissive`, `audit` and `skip` to support various scenarios. These scenarios includes 1) situations demanding urgent workload deployment, necessitating the bypassing of expired or revoked signatures; 2) auditing of artifacts lacking signatures without interrupting workload; and 3) skipping of verification for specific images that might have undergone validation through alternative mechanisms.\n\nAdditionally, the Notary Project supports revocation to ensure the signature freshness. Artifact publishers can sign with short-lived certificates and revoke older certificates when necessary. This revocation serves as a signal to inform artifact consumers that the corresponding unexpired artifact is no longer approved by the publisher. This enables the artifact publisher to control the validity of the signature independently of their ability to manage artifacts in a compromised registry.\n\n### Credit\nThe Notary Project extends its gratitude to Justin Cappos (@JustinCappos) for responsibly disclosing the issue.\n\n_**Note:** we have updated [threat model](https://github.com/notaryproject/specifications/blob/main/threatmodels/notation-threatmodel.md) to include considerations for rollback attack.",
  "id": "GHSA-57wx-m636-g3g8",
  "modified": "2024-03-01T15:19:13Z",
  "published": "2024-01-19T22:12:22Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/notaryproject/specifications/security/advisories/GHSA-57wx-m636-g3g8"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-23332"
    },
    {
      "type": "WEB",
      "url": "https://github.com/notaryproject/specifications/commit/cdabdd1042de2999c685fa5d422a785ded9c983a"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/notaryproject/specifications"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:H/PR:H/UI:R/S:C/C:N/I:L/A:L",
      "type": "CVSS_V3"
    }
  ],
  "summary": "Go package github.com/notaryproject/notation configured with permissive trust policies potentially susceptible to rollback attack from compromised registry"
}

CWE-672

Operation on a Resource after Expiration or Release

Impact

Patches

Workarounds

References

Impact

Patches

Workarounds

Step 1. Create src/Twig/Component/Cart/FormComponent.php

Step 2. Override the Sylius service in config/services.yaml

Step 3. Clear the cache

Reporters

For more information

Summary

Details

PoC

Impact

Impact

Mitigation

Credit

Step 1. Create `src/Twig/Component/Cart/FormComponent.php`

Step 2. Override the Sylius service in `config/services.yaml`