CWE-672
Allowed-with-ReviewOperation on a Resource after Expiration or Release
Abstraction: Class · Status: Draft
The product uses, accesses, or otherwise operates on a resource after that resource has been expired, released, or revoked.
141 vulnerabilities reference this CWE, most recent first.
GHSA-4VC6-7QHX-WXQ5
Vulnerability from github – Published: 2024-12-27 15:31 – Updated: 2025-01-06 15:30In 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---
{
"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:43In 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.
{
"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:03Impact
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()callsmanager->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
{
"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:12Summary
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/refreshcall, as that invalidates the session - Access the API with
Authorization: Bearer <token>
Impact
This weakens the security of suspending users.
{
"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:19Impact
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.
{
"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"
}
GHSA-5C8V-93Q6-CJXJ
Vulnerability from github – Published: 2026-08-06 12:31 – Updated: 2026-08-07 00:31In Apache CXF's DefaultEncryptingOAuthDataProvider, revoked access tokens still decrypt successfully, and TokenIntrospectionService reports active:true. The same applies to refresh tokens. This violates the RFC stipulations that 'The authorization server MUST invalidate the token.' and 'introspection of a revoked token MUST return {"active":false}'. Users are recommended to upgrade to versions 4.2.3 or 4.1.8 or 3.6.12, which fix this issue.
{
"affected": [],
"aliases": [
"CVE-2026-68481"
],
"database_specific": {
"cwe_ids": [
"CWE-672"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2026-08-06T12:16:28Z",
"severity": "HIGH"
},
"details": "In Apache CXF\u0027s DefaultEncryptingOAuthDataProvider, revoked access tokens still decrypt successfully, and TokenIntrospectionService reports active:true. The same applies to refresh tokens. This violates the RFC stipulations that \u0027The authorization server MUST invalidate the token.\u0027 and \u0027introspection of a revoked token MUST return {\"active\":false}\u0027. Users are recommended to upgrade to versions 4.2.3 or 4.1.8 or 3.6.12, which fix this issue.",
"id": "GHSA-5c8v-93q6-cjxj",
"modified": "2026-08-07T00:31:10Z",
"published": "2026-08-06T12:31:14Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-68481"
},
{
"type": "WEB",
"url": "https://lists.apache.org/thread/88c0h10yjb2b8201o1km3st71fs2zw2b"
},
{
"type": "WEB",
"url": "http://www.openwall.com/lists/oss-security/2026/08/06/25"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:N/A:N",
"type": "CVSS_V3"
}
]
}
GHSA-5HWQ-PJV4-H4FM
Vulnerability from github – Published: 2026-10-06 21:31 – Updated: 2026-10-07 12:31Use of released resource in Core in Google Chrome prior to 155.0.8059.39 allowed a remote attacker who had compromised the renderer process to potentially obtain cross-origin data via a crafted HTML page. (Chromium security severity: Low)
{
"affected": [],
"aliases": [
"CVE-2026-106339"
],
"database_specific": {
"cwe_ids": [
"CWE-672"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2026-10-06T19:18:02Z",
"severity": "LOW"
},
"details": "Use of released resource in Core in Google Chrome prior to 155.0.8059.39 allowed a remote attacker who had compromised the renderer process to potentially obtain cross-origin data via a crafted HTML page. (Chromium security severity: Low)",
"id": "GHSA-5hwq-pjv4-h4fm",
"modified": "2026-10-07T12:31:54Z",
"published": "2026-10-06T21:31:47Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-106339"
},
{
"type": "WEB",
"url": "https://chromereleases.googleblog.com/2026/10/stable-channel-update-for-desktop_086471744.html"
},
{
"type": "WEB",
"url": "https://issues.chromium.org/issues/553913506"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:H/PR:N/UI:R/S:U/C:L/I:N/A:N",
"type": "CVSS_V3"
}
]
}
GHSA-5R25-M2H9-W299
Vulnerability from github – Published: 2025-10-15 15:30 – Updated: 2025-10-22 21:31When the BIG-IP Advanced WAF and ASM security policy and a server-side HTTP/2 profile are configured on a virtual server, undisclosed traffic can cause the Traffic Management Microkernel (TMM) to terminate. Note: Software versions which have reached End of Technical Support (EoTS) are not evaluated.
{
"affected": [],
"aliases": [
"CVE-2025-55669"
],
"database_specific": {
"cwe_ids": [
"CWE-672"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2025-10-15T14:15:51Z",
"severity": "HIGH"
},
"details": "When the BIG-IP Advanced WAF and ASM security policy and a server-side HTTP/2 profile are configured on a virtual server, undisclosed traffic can cause the Traffic Management Microkernel (TMM) to terminate.\u00a0\u00a0Note: Software versions which have reached End of Technical Support (EoTS) are not evaluated.",
"id": "GHSA-5r25-m2h9-w299",
"modified": "2025-10-22T21:31:18Z",
"published": "2025-10-15T15:30:28Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-55669"
},
{
"type": "WEB",
"url": "https://my.f5.com/manage/s/article/K000150752"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H",
"type": "CVSS_V3"
},
{
"score": "CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:N/VI:N/VA:H/SC:N/SI:N/SA:L/E:X/CR:X/IR:X/AR:X/MAV:X/MAC:X/MAT:X/MPR:X/MUI:X/MVC:X/MVI:X/MVA:X/MSC:X/MSI:X/MSA:X/S:X/AU:X/R:X/V:X/RE:X/U:X",
"type": "CVSS_V4"
}
]
}
GHSA-655H-HG88-5QMF
Vulnerability from github – Published: 2025-08-22 17:34 – Updated: 2025-08-22 17:34The API of xcb::Connection has constructors which allow an arbitrary RawFd to be used as a socket connection. On either failure of these constructors or on the drop of Connection, it closes the associated file descriptor. Thus, a program which uses an OwnedFd (such as a UnixStream) as the file descriptor can close the file descriptor and continue to attempt using it or close an already-closed file descriptor, violating I/O safety.
Starting in version 1.6.0, xcb provides Connection::connect_with_fd and Connection::connect_with_fd_and_extensions as safe alternatives and deprecates the problematic functions.
{
"affected": [
{
"package": {
"ecosystem": "crates.io",
"name": "xcb"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"fixed": "1.6.0"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [],
"database_specific": {
"cwe_ids": [
"CWE-666",
"CWE-672"
],
"github_reviewed": true,
"github_reviewed_at": "2025-08-22T17:34:45Z",
"nvd_published_at": null,
"severity": "LOW"
},
"details": "The API of `xcb::Connection` has constructors which allow an arbitrary `RawFd` to be used as a socket connection. On either failure of these constructors or on the drop of `Connection`, it closes the associated file descriptor. Thus, a program which uses an `OwnedFd` (such as a `UnixStream`) as the file descriptor can close the file descriptor and continue to attempt using it or close an already-closed file descriptor, violating I/O safety.\n\nStarting in version 1.6.0, `xcb` provides `Connection::connect_with_fd` and `Connection::connect_with_fd_and_extensions` as safe alternatives and deprecates the problematic functions.",
"id": "GHSA-655h-hg88-5qmf",
"modified": "2025-08-22T17:34:45Z",
"published": "2025-08-22T17:34:45Z",
"references": [
{
"type": "WEB",
"url": "https://github.com/rust-x-bindings/rust-xcb/issues/167"
},
{
"type": "WEB",
"url": "https://github.com/rust-x-bindings/rust-xcb/issues/282"
},
{
"type": "WEB",
"url": "https://github.com/rust-x-bindings/rust-xcb/pull/283"
},
{
"type": "WEB",
"url": "https://github.com/rustsec/advisory-db/pull/2355"
},
{
"type": "WEB",
"url": "https://github.com/rust-x-bindings/rust-xcb/commit/da830976870c1174e3b33eb0643177be3991c002"
},
{
"type": "PACKAGE",
"url": "https://github.com/rust-x-bindings/rust-xcb"
},
{
"type": "WEB",
"url": "https://rustsec.org/advisories/RUSTSEC-2025-0051.html"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:4.0/AV:N/AC:L/AT:P/PR:N/UI:N/VC:N/VI:L/VA:N/SC:N/SI:N/SA:N/E:U",
"type": "CVSS_V4"
}
],
"summary": "Rust XCB `xcb::Connection::connect_to_fd*` functions violate I/O safety"
}
GHSA-675F-RQ2R-JW82
Vulnerability from github – Published: 2025-01-09 17:23 – Updated: 2025-01-09 18:57Impact
The project's provided HTTP client's local JWK Set cache should do a full replacement when the goroutine refreshes the remote JWK Set. The current behavior is to overwrite or append. This is a security issue for use cases that utilize the provided auto-caching HTTP client and where key removal from a JWK Set is equivalent to revocation.
Example attack scenario:
1. An attacker has stolen the private key for a key published in JWK Set.
2. The publishers of that JWK Set remove that key from the JWK Set.
3. Enough time has passed that the program using the auto-caching HTTP client found in github.com/MicahParks/jwkset v0.5.0-v0.5.21 has elapsed its HTTPClientStorageOptions.RefreshInterval duration, causing a refresh of the remote JWK Set.
4. The attacker is signing content (such as JWTs) with the stolen private key and the system has no other forms of revocation.
Patches
The affected auto-caching HTTP client was added in version v0.5.0 and fixed in v0.6.0. Upgrade to v0.6.0 or later.
Workarounds
The only workaround would be to remove the provided auto-caching HTTP client and replace it with a custom implementation. This involves setting the HTTPClientStorageOptions.RefreshInterval to zero (or not specifying the value). Upgrade to v0.6.0 is advised.
References
Please see the tracking issue on GitHub for additional details: https://github.com/MicahParks/jwkset/issues/40
{
"affected": [
{
"database_specific": {
"last_known_affected_version_range": "\u003c= 0.5.21"
},
"package": {
"ecosystem": "Go",
"name": "github.com/MicahParks/jwkset"
},
"ranges": [
{
"events": [
{
"introduced": "0.5.0"
},
{
"fixed": "0.6.0"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [
"CVE-2025-22149"
],
"database_specific": {
"cwe_ids": [
"CWE-672"
],
"github_reviewed": true,
"github_reviewed_at": "2025-01-09T17:23:43Z",
"nvd_published_at": "2025-01-09T18:15:30Z",
"severity": "LOW"
},
"details": "### Impact\nThe project\u0027s provided HTTP client\u0027s local JWK Set cache should do a full replacement when the goroutine refreshes the remote JWK Set. The current behavior is to overwrite or append. This is a security issue for use cases that utilize the provided auto-caching HTTP client and where key removal from a JWK Set is equivalent to revocation.\n\nExample attack scenario:\n1. An attacker has stolen the private key for a key published in JWK Set.\n2. The publishers of that JWK Set remove that key from the JWK Set.\n3. Enough time has passed that the program using the auto-caching HTTP client found in `github.com/MicahParks/jwkset` v0.5.0-v0.5.21 has elapsed its `HTTPClientStorageOptions.RefreshInterval` duration, causing a refresh of the remote JWK Set.\n4. The attacker is signing content (such as JWTs) with the stolen private key and the system has no other forms of revocation.\n\n### Patches\nThe affected auto-caching HTTP client was added in version `v0.5.0` and fixed in `v0.6.0`. Upgrade to `v0.6.0` or later.\n\n### Workarounds\nThe only workaround would be to remove the provided auto-caching HTTP client and replace it with a custom implementation. This involves setting the `HTTPClientStorageOptions.RefreshInterval` to zero (or not specifying the value). Upgrade to `v0.6.0` is advised.\n\n### References\nPlease see the tracking issue on GitHub for additional details: https://github.com/MicahParks/jwkset/issues/40\n",
"id": "GHSA-675f-rq2r-jw82",
"modified": "2025-01-09T18:57:32Z",
"published": "2025-01-09T17:23:43Z",
"references": [
{
"type": "WEB",
"url": "https://github.com/MicahParks/jwkset/security/advisories/GHSA-675f-rq2r-jw82"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-22149"
},
{
"type": "WEB",
"url": "https://github.com/MicahParks/jwkset/issues/40"
},
{
"type": "WEB",
"url": "https://github.com/MicahParks/jwkset/pull/41"
},
{
"type": "WEB",
"url": "https://github.com/MicahParks/jwkset/commit/01db49a90f7f20c7fb39a699a2f19a7a5f379ed3"
},
{
"type": "PACKAGE",
"url": "https://github.com/MicahParks/jwkset"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:4.0/AV:N/AC:H/AT:P/PR:H/UI:N/VC:N/VI:N/VA:N/SC:N/SI:L/SA:N",
"type": "CVSS_V4"
}
],
"summary": "JWK Set\u0027s HTTP client only overwrites and appends JWK to local cache during refresh"
}
No mitigation information available for this CWE.
No CAPEC attack patterns related to this CWE.