Common Weakness Enumeration

CWE-367

Allowed

Time-of-check Time-of-use (TOCTOU) Race Condition

Abstraction: Base · Status: Incomplete

The product checks the state of a resource before using that resource, but the resource's state can change between the check and the use in a way that invalidates the results of the check.

1207 vulnerabilities reference this CWE, most recent first.

GHSA-7F5Q-X8VX-PFRP

Vulnerability from github – Published: 2023-09-13 18:31 – Updated: 2024-04-04 07:39
VLAI
Details

A flaw was found in KVM AMD Secure Encrypted Virtualization (SEV) in the Linux kernel. A KVM guest using SEV-ES or SEV-SNP with multiple vCPUs can trigger a double fetch race condition vulnerability and invoke the VMGEXIT handler recursively. If an attacker manages to call the handler multiple times, they can trigger a stack overflow and cause a denial of service or potentially guest-to-host escape in kernel configurations without stack guard pages (CONFIG_VMAP_STACK).

Show details on source website

{
  "affected": [],
  "aliases": [
    "CVE-2023-4155"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-367"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2023-09-13T17:15:10Z",
    "severity": "MODERATE"
  },
  "details": "A flaw was found in KVM AMD Secure Encrypted Virtualization (SEV) in the Linux kernel. A KVM guest using SEV-ES or SEV-SNP with multiple vCPUs can trigger a double fetch race condition vulnerability and invoke the `VMGEXIT` handler recursively. If an attacker manages to call the handler multiple times, they can trigger a stack overflow and cause a denial of service or potentially guest-to-host escape in kernel configurations without stack guard pages (`CONFIG_VMAP_STACK`).",
  "id": "GHSA-7f5q-x8vx-pfrp",
  "modified": "2024-04-04T07:39:29Z",
  "published": "2023-09-13T18:31:26Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2023-4155"
    },
    {
      "type": "WEB",
      "url": "https://access.redhat.com/security/cve/CVE-2023-4155"
    },
    {
      "type": "WEB",
      "url": "https://bugzilla.redhat.com/show_bug.cgi?id=2213802"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:L/AC:H/PR:H/UI:N/S:C/C:N/I:N/A:H",
      "type": "CVSS_V3"
    }
  ]
}

GHSA-7G9H-H4FM-JQ9P

Vulnerability from github – Published: 2024-03-14 18:30 – Updated: 2024-03-14 18:30
VLAI
Details

Race condition in BIOS firmware for some Intel(R) Processors may allow a privileged user to potentially enable escalation of privilege via local access.

Show details on source website

{
  "affected": [],
  "aliases": [
    "CVE-2023-32282"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-367"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2024-03-14T17:15:50Z",
    "severity": "HIGH"
  },
  "details": "Race condition in BIOS firmware for some Intel(R) Processors may allow a privileged user to potentially enable escalation of privilege via local access.",
  "id": "GHSA-7g9h-h4fm-jq9p",
  "modified": "2024-03-14T18:30:30Z",
  "published": "2024-03-14T18:30:30Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2023-32282"
    },
    {
      "type": "WEB",
      "url": "https://www.intel.com/content/www/us/en/security-center/advisory/intel-sa-00929.html"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:L/AC:H/PR:H/UI:N/S:C/C:N/I:H/A:H",
      "type": "CVSS_V3"
    }
  ]
}

GHSA-7JMR-43QJ-PW47

Vulnerability from github – Published: 2025-02-11 18:31 – Updated: 2025-02-28 02:45
VLAI
Summary
Magento Time-of-check Time-of-use (TOCTOU) Race Condition vulnerability
Details

Adobe Commerce versions 2.4.7-beta1, 2.4.7-p3, 2.4.6-p8, 2.4.5-p10, 2.4.4-p11 and earlier are affected by a Time-of-check Time-of-use (TOCTOU) Race Condition vulnerability that could result in a security feature bypass. An attacker could exploit this race condition to alter a condition after it has been checked but before it is used, potentially bypassing security mechanisms. Exploitation of this issue requires user interaction.

Show details on source website

{
  "affected": [
    {
      "package": {
        "ecosystem": "Packagist",
        "name": "magento/community-edition"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "2.4.7-beta1"
            },
            {
              "fixed": "2.4.7-p4"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    },
    {
      "package": {
        "ecosystem": "Packagist",
        "name": "magento/community-edition"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "2.4.6-p1"
            },
            {
              "fixed": "2.4.6-p9"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    },
    {
      "package": {
        "ecosystem": "Packagist",
        "name": "magento/community-edition"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "2.4.5-p1"
            },
            {
              "fixed": "2.4.5-p11"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    },
    {
      "package": {
        "ecosystem": "Packagist",
        "name": "magento/community-edition"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "2.4.4-p12"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    },
    {
      "package": {
        "ecosystem": "Packagist",
        "name": "magento/community-edition"
      },
      "versions": [
        "2.4.7"
      ]
    },
    {
      "package": {
        "ecosystem": "Packagist",
        "name": "magento/community-edition"
      },
      "versions": [
        "2.4.6"
      ]
    },
    {
      "package": {
        "ecosystem": "Packagist",
        "name": "magento/community-edition"
      },
      "versions": [
        "2.4.5"
      ]
    },
    {
      "package": {
        "ecosystem": "Packagist",
        "name": "magento/community-edition"
      },
      "versions": [
        "2.4.4"
      ]
    },
    {
      "package": {
        "ecosystem": "Packagist",
        "name": "magento/community-edition"
      },
      "versions": [
        "2.4.8-beta1"
      ]
    },
    {
      "package": {
        "ecosystem": "Packagist",
        "name": "magento/project-community-edition"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "last_affected": "2.0.2"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2025-24432"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-367"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2025-02-28T02:45:01Z",
    "nvd_published_at": "2025-02-11T18:15:45Z",
    "severity": "LOW"
  },
  "details": "Adobe Commerce versions 2.4.7-beta1, 2.4.7-p3, 2.4.6-p8, 2.4.5-p10, 2.4.4-p11 and earlier are affected by a Time-of-check Time-of-use (TOCTOU) Race Condition vulnerability that could result in a security feature bypass. An attacker could exploit this race condition to alter a condition after it has been checked but before it is used, potentially bypassing security mechanisms. Exploitation of this issue requires user interaction.",
  "id": "GHSA-7jmr-43qj-pw47",
  "modified": "2025-02-28T02:45:02Z",
  "published": "2025-02-11T18:31:42Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2025-24432"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/magento/magento2"
    },
    {
      "type": "WEB",
      "url": "https://helpx.adobe.com/security/products/magento/apsb25-08.html"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:N/I:L/A:N",
      "type": "CVSS_V3"
    }
  ],
  "summary": "Magento Time-of-check Time-of-use (TOCTOU) Race Condition vulnerability"
}

GHSA-7MP4-25J8-HP5Q

Vulnerability from github – Published: 2026-03-11 00:13 – Updated: 2026-03-11 20:33
VLAI
Summary
Sylius has a Promotion Usage Limit Bypass via Race Condition
Details

Impact

A Time-of-Check To Time-of-Use (TOCTOU) race condition was discovered in the promotion usage limit enforcement. The same class of vulnerability affects three independent limits:

  1. Promotion usage limit - the global used counter on Promotion entities
  2. Coupon usage limit - the global used counter on PromotionCoupon entities
  3. Coupon per-customer usage limit - the per-customer redemption count on PromotionCoupon entities

In all three cases, the eligibility check reads the used counter (or order count) from an in-memory Doctrine entity during validation, while the actual usage increment in OrderPromotionsUsageModifier happens later during order completion — with no database-level locking or atomic operations between the two phases.

Because Doctrine flushes an absolute value (SET used = 1) rather than an atomic increment (SET used = used + 1), and because the affected entities lack optimistic locking, concurrent requests all read the same stale usage counts and pass the eligibility checks simultaneously.

An attacker can exploit this by preparing multiple carts with the same limited-use promotion or coupon and firing simultaneous PATCH /api/v2/shop/orders/{token}/complete requests. All requests pass the usage limit checks and complete successfully, allowing a single-use promotion or coupon to be redeemed an arbitrary number of times. The per-customer limit can be bypassed in the same way by a single customer completing multiple orders concurrently. No authentication is required to exploit this vulnerability.

This may lead to direct financial loss through unlimited redemption of limited-use promotions and discount coupons.

Patches

The issue is fixed in versions: 1.9.12, 1.10.16, 1.11.17, 1.12.23, 1.13.15, 1.14.18, 2.0.16, 2.1.12, 2.2.3 and above.

Workarounds

Decoration of the OrderPromotionsUsageModifier service to use atomic operations based on actual database-synchronized values.

The decorated service id in Sylius >=2.0 is sylius.modifier.promotion.order_usage, while <2.0 it's sylius.promotion_usage_modifier; The following instruction uses the latter, but it needs to be changed depending on the Sylius version.

Step 1. Create the decorator service

src/Modifier/AtomicOrderPromotionsUsageModifier.php:

<?php

declare(strict_types=1);

namespace App\Modifier;

use Doctrine\DBAL\Connection;
use Doctrine\ORM\OptimisticLockException;
use Sylius\Component\Core\Model\OrderInterface;
use Sylius\Component\Core\Model\PromotionCouponInterface;
use Sylius\Component\Core\Promotion\Modifier\OrderPromotionsUsageModifierInterface;
use Sylius\Component\Promotion\Model\PromotionInterface;
// use Symfony\Component\DependencyInjection\Attribute\AsDecorator;

// #[AsDecorator(decorates: 'sylius.promotion_usage_modifier')]
final class AtomicOrderPromotionsUsageModifier implements OrderPromotionsUsageModifierInterface
{
    /** @var Connection */
    private $connection;

    public function __construct(Connection $connection)
    {
        $this->connection = $connection;
    }

    public function increment(OrderInterface $order): void
    {
        foreach ($order->getPromotions() as $promotion) {
            $this->incrementPromotionUsage($promotion);
        }

        /** @var PromotionCouponInterface|null $coupon */
        $coupon = $order->getPromotionCoupon();
        if (null === $coupon) {
            return;
        }

        $this->incrementCouponUsage($coupon, $order);
    }

    public function decrement(OrderInterface $order): void
    {
        foreach ($order->getPromotions() as $promotion) {
            $this->decrementPromotionUsage($promotion);
        }

        /** @var PromotionCouponInterface|null $coupon */
        $coupon = $order->getPromotionCoupon();
        if (null === $coupon) {
            return;
        }

        if (OrderInterface::STATE_CANCELLED === $order->getState() && !$coupon->isReusableFromCancelledOrders()) {
            return;
        }

        $this->decrementCouponUsage($coupon);
    }

    private function incrementPromotionUsage(PromotionInterface $promotion): void
    {
        $affected = $this->doExecuteStatement(
            'UPDATE sylius_promotion
             SET used = used + 1
             WHERE id = :id AND (usage_limit IS NULL OR used < usage_limit)',
            ['id' => $promotion->getId()]
        );

        if (0 === $affected) {
            throw new OptimisticLockException(sprintf('Promotion "%s" is no longer applicable.', $promotion->getCode()), $promotion);
        }

        $newUsed = (int) $this->doFetchOne(
            'SELECT used FROM sylius_promotion WHERE id = :id',
            ['id' => $promotion->getId()]
        );

        $promotion->setUsed($newUsed);
    }

    private function decrementPromotionUsage(PromotionInterface $promotion): void
    {
        $this->doExecuteStatement(
            'UPDATE sylius_promotion SET used = GREATEST(used - 1, 0) WHERE id = :id',
            ['id' => $promotion->getId()]
        );

        $newUsed = (int) $this->doFetchOne(
            'SELECT used FROM sylius_promotion WHERE id = :id',
            ['id' => $promotion->getId()]
        );

        $promotion->setUsed($newUsed);
    }

    private function incrementCouponUsage(PromotionCouponInterface $coupon, OrderInterface $order): void
    {
        $row = $this->doFetchAssociative(
            'SELECT used, usage_limit, per_customer_usage_limit FROM sylius_promotion_coupon WHERE id = :id FOR UPDATE',
            ['id' => $coupon->getId()]
        );

        if (false === $row) {
            throw new OptimisticLockException(sprintf('Promotion coupon "%s" is no longer applicable.', $coupon->getCode()), $coupon);
        }

        if (null !== $row['usage_limit'] && (int) $row['used'] >= (int) $row['usage_limit']) {
            throw new OptimisticLockException(sprintf('Promotion coupon "%s" is no longer applicable.', $coupon->getCode()), $coupon);
        }

        if (null !== $row['per_customer_usage_limit']) {
            $this->assertPerCustomerCouponUsageLimitNotReached(
                $coupon,
                $order,
                (int) $row['per_customer_usage_limit']
            );
        }

        $this->doExecuteStatement(
            'UPDATE sylius_promotion_coupon SET used = used + 1 WHERE id = :id',
            ['id' => $coupon->getId()]
        );

        $coupon->setUsed((int) $row['used'] + 1);
    }

    private function assertPerCustomerCouponUsageLimitNotReached(
        PromotionCouponInterface $coupon,
        OrderInterface $order,
        int $perCustomerUsageLimit
    ): void {
        $customer = $order->getCustomer();
        if (null === $customer || null === $customer->getId()) {
            return;
        }

        $sql = 'SELECT o.id FROM sylius_order o
                WHERE o.customer_id = :customerId
                AND o.promotion_coupon_id = :couponId
                AND o.state != :stateCart';
        $params = [
            'customerId' => $customer->getId(),
            'couponId' => $coupon->getId(),
            'stateCart' => OrderInterface::STATE_CART,
        ];

        if ($coupon->isReusableFromCancelledOrders()) {
            $sql .= ' AND o.state != :stateCancelled';
            $params['stateCancelled'] = OrderInterface::STATE_CANCELLED;
        }

        $sql .= ' FOR UPDATE';

        $count = count($this->doFetchAllAssociative($sql, $params));

        if ($count >= $perCustomerUsageLimit) {
            throw new OptimisticLockException(sprintf('Promotion coupon "%s" is no longer applicable.', $coupon->getCode()), $coupon);
        }
    }

    private function decrementCouponUsage(PromotionCouponInterface $coupon): void
    {
        $this->doExecuteStatement(
            'UPDATE sylius_promotion_coupon SET used = GREATEST(used - 1, 0) WHERE id = :id',
            ['id' => $coupon->getId()]
        );

        $newUsed = (int) $this->doFetchOne(
            'SELECT used FROM sylius_promotion_coupon WHERE id = :id',
            ['id' => $coupon->getId()]
        );

        $coupon->setUsed($newUsed);
    }

    /** @return int Number of affected rows */
    private function doExecuteStatement(string $sql, array $params): int
    {
        if (method_exists($this->connection, 'executeStatement')) {
            return $this->connection->executeStatement($sql, $params);
        }

        return $this->connection->executeUpdate($sql, $params);
    }

    /** @return mixed|false */
    private function doFetchOne(string $sql, array $params)
    {
        if (method_exists($this->connection, 'fetchOne')) {
            return $this->connection->fetchOne($sql, $params);
        }

        return $this->connection->fetchColumn($sql, $params);
    }

    /** @return array|false */
    private function doFetchAssociative(string $sql, array $params)
    {
        if (method_exists($this->connection, 'fetchAssociative')) {
            return $this->connection->fetchAssociative($sql, $params);
        }

        return $this->connection->fetchAssoc($sql, $params);
    }

    /** @return array[] */
    private function doFetchAllAssociative(string $sql, array $params): array
    {
        if (method_exists($this->connection, 'fetchAllAssociative')) {
            return $this->connection->fetchAllAssociative($sql, $params);
        }

        return $this->connection->fetchAll($sql, $params);
    }
}

Step 2. Register the service

Option A: If your app uses autowiring and supports the #[AsDecorator] attribute, uncomment it in the class and no further configuration is necessary.

Option B: Manually register the service in config/services.yaml:

services:
    App\Modifier\AtomicOrderPromotionsUsageModifier:
        decorates: 'sylius.promotion_usage_modifier'
        arguments: ['@doctrine.dbal.default_connection']

Step 3. Update exception mapping (optional)

Check if your api_platform configuration maps OptimisticLockException to a code and update it if not:

api_platform:
    ...
    exception_to_status:
        ...
        Doctrine\ORM\OptimisticLockException: 409

Step 4. Clear 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: - Djibril Mounkoro (@whiteov3rflow) - Bartłomiej Nowiński (@bnBart)

For more information

If you have any questions or comments about this advisory:

Show details on source website

{
  "affected": [
    {
      "database_specific": {
        "last_known_affected_version_range": "\u003c= 1.9.11"
      },
      "package": {
        "ecosystem": "Packagist",
        "name": "sylius/sylius"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "1.9.12"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    },
    {
      "database_specific": {
        "last_known_affected_version_range": "\u003c= 1.10.15"
      },
      "package": {
        "ecosystem": "Packagist",
        "name": "sylius/sylius"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "1.10.0"
            },
            {
              "fixed": "1.10.16"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    },
    {
      "database_specific": {
        "last_known_affected_version_range": "\u003c= 1.11.16"
      },
      "package": {
        "ecosystem": "Packagist",
        "name": "sylius/sylius"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "1.11.0"
            },
            {
              "fixed": "1.11.17"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    },
    {
      "database_specific": {
        "last_known_affected_version_range": "\u003c= 1.12.22"
      },
      "package": {
        "ecosystem": "Packagist",
        "name": "sylius/sylius"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "1.12.0"
            },
            {
              "fixed": "1.12.23"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    },
    {
      "database_specific": {
        "last_known_affected_version_range": "\u003c= 1.13.14"
      },
      "package": {
        "ecosystem": "Packagist",
        "name": "sylius/sylius"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "1.13.0"
            },
            {
              "fixed": "1.13.15"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    },
    {
      "database_specific": {
        "last_known_affected_version_range": "\u003c= 1.14.17"
      },
      "package": {
        "ecosystem": "Packagist",
        "name": "sylius/sylius"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "1.14.0"
            },
            {
              "fixed": "1.14.18"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    },
    {
      "database_specific": {
        "last_known_affected_version_range": "\u003c= 2.0.15"
      },
      "package": {
        "ecosystem": "Packagist",
        "name": "sylius/sylius"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "2.0.0"
            },
            {
              "fixed": "2.0.16"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    },
    {
      "database_specific": {
        "last_known_affected_version_range": "\u003c= 2.1.11"
      },
      "package": {
        "ecosystem": "Packagist",
        "name": "sylius/sylius"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "2.1.0"
            },
            {
              "fixed": "2.1.12"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    },
    {
      "database_specific": {
        "last_known_affected_version_range": "\u003c= 2.2.2"
      },
      "package": {
        "ecosystem": "Packagist",
        "name": "sylius/sylius"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "2.2.0"
            },
            {
              "fixed": "2.2.3"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2026-31824"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-362",
      "CWE-367"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2026-03-11T00:13:29Z",
    "nvd_published_at": "2026-03-10T22:16:20Z",
    "severity": "HIGH"
  },
  "details": "### Impact\nA Time-of-Check To Time-of-Use (TOCTOU) race condition was discovered in the promotion usage limit enforcement. The same class of vulnerability affects three independent limits:\n\n1. **Promotion usage limit** - the global `used` counter on `Promotion` entities\n2. **Coupon usage limit** - the global `used` counter on `PromotionCoupon` entities\n3. **Coupon per-customer usage limit** - the per-customer redemption count on `PromotionCoupon` entities\n\nIn all three cases, the eligibility check reads the `used` counter (or order count) from an in-memory Doctrine entity during validation, while the actual usage increment in `OrderPromotionsUsageModifier` happens later during order completion \u2014 with no database-level locking or atomic operations between the two phases.\n\nBecause Doctrine flushes an absolute value (`SET used = 1`) rather than an atomic increment (`SET used = used + 1`), and because the affected entities lack optimistic locking, concurrent requests all read the same stale usage counts and pass the eligibility checks simultaneously.\n\nAn attacker can exploit this by preparing multiple carts with the same limited-use promotion or coupon and firing simultaneous `PATCH /api/v2/shop/orders/{token}/complete` requests. All requests pass the usage limit checks and complete successfully, allowing a single-use promotion or coupon to be redeemed an arbitrary number of times. The per-customer limit can be bypassed in the same way by a single customer completing multiple orders concurrently. No authentication is required to exploit this vulnerability.\n\nThis may lead to direct financial loss through unlimited redemption of limited-use promotions and discount coupons.\n\n### Patches\nThe issue is fixed in versions: 1.9.12, 1.10.16, 1.11.17, 1.12.23, 1.13.15, 1.14.18, 2.0.16, 2.1.12, 2.2.3 and above.\n\n### Workarounds\n\nDecoration of the `OrderPromotionsUsageModifier` service to use atomic operations based on actual database-synchronized values.\n\nThe decorated service id in Sylius \u003e=2.0 is `sylius.modifier.promotion.order_usage`, while \u003c2.0 it\u0027s `sylius.promotion_usage_modifier`; The following instruction uses the latter, but it needs to be changed depending on the Sylius version.\n\n#### Step 1. Create the decorator service\n\n`src/Modifier/AtomicOrderPromotionsUsageModifier.php`:\n\n```php\n\u003c?php\n\ndeclare(strict_types=1);\n\nnamespace App\\Modifier;\n\nuse Doctrine\\DBAL\\Connection;\nuse Doctrine\\ORM\\OptimisticLockException;\nuse Sylius\\Component\\Core\\Model\\OrderInterface;\nuse Sylius\\Component\\Core\\Model\\PromotionCouponInterface;\nuse Sylius\\Component\\Core\\Promotion\\Modifier\\OrderPromotionsUsageModifierInterface;\nuse Sylius\\Component\\Promotion\\Model\\PromotionInterface;\n// use Symfony\\Component\\DependencyInjection\\Attribute\\AsDecorator;\n\n// #[AsDecorator(decorates: \u0027sylius.promotion_usage_modifier\u0027)]\nfinal class AtomicOrderPromotionsUsageModifier implements OrderPromotionsUsageModifierInterface\n{\n    /** @var Connection */\n    private $connection;\n\n    public function __construct(Connection $connection)\n    {\n        $this-\u003econnection = $connection;\n    }\n\n    public function increment(OrderInterface $order): void\n    {\n        foreach ($order-\u003egetPromotions() as $promotion) {\n            $this-\u003eincrementPromotionUsage($promotion);\n        }\n\n        /** @var PromotionCouponInterface|null $coupon */\n        $coupon = $order-\u003egetPromotionCoupon();\n        if (null === $coupon) {\n            return;\n        }\n\n        $this-\u003eincrementCouponUsage($coupon, $order);\n    }\n\n    public function decrement(OrderInterface $order): void\n    {\n        foreach ($order-\u003egetPromotions() as $promotion) {\n            $this-\u003edecrementPromotionUsage($promotion);\n        }\n\n        /** @var PromotionCouponInterface|null $coupon */\n        $coupon = $order-\u003egetPromotionCoupon();\n        if (null === $coupon) {\n            return;\n        }\n\n        if (OrderInterface::STATE_CANCELLED === $order-\u003egetState() \u0026\u0026 !$coupon-\u003eisReusableFromCancelledOrders()) {\n            return;\n        }\n\n        $this-\u003edecrementCouponUsage($coupon);\n    }\n\n    private function incrementPromotionUsage(PromotionInterface $promotion): void\n    {\n        $affected = $this-\u003edoExecuteStatement(\n            \u0027UPDATE sylius_promotion\n             SET used = used + 1\n             WHERE id = :id AND (usage_limit IS NULL OR used \u003c usage_limit)\u0027,\n            [\u0027id\u0027 =\u003e $promotion-\u003egetId()]\n        );\n\n        if (0 === $affected) {\n            throw new OptimisticLockException(sprintf(\u0027Promotion \"%s\" is no longer applicable.\u0027, $promotion-\u003egetCode()), $promotion);\n        }\n\n        $newUsed = (int) $this-\u003edoFetchOne(\n            \u0027SELECT used FROM sylius_promotion WHERE id = :id\u0027,\n            [\u0027id\u0027 =\u003e $promotion-\u003egetId()]\n        );\n\n        $promotion-\u003esetUsed($newUsed);\n    }\n\n    private function decrementPromotionUsage(PromotionInterface $promotion): void\n    {\n        $this-\u003edoExecuteStatement(\n            \u0027UPDATE sylius_promotion SET used = GREATEST(used - 1, 0) WHERE id = :id\u0027,\n            [\u0027id\u0027 =\u003e $promotion-\u003egetId()]\n        );\n\n        $newUsed = (int) $this-\u003edoFetchOne(\n            \u0027SELECT used FROM sylius_promotion WHERE id = :id\u0027,\n            [\u0027id\u0027 =\u003e $promotion-\u003egetId()]\n        );\n\n        $promotion-\u003esetUsed($newUsed);\n    }\n\n    private function incrementCouponUsage(PromotionCouponInterface $coupon, OrderInterface $order): void\n    {\n        $row = $this-\u003edoFetchAssociative(\n            \u0027SELECT used, usage_limit, per_customer_usage_limit FROM sylius_promotion_coupon WHERE id = :id FOR UPDATE\u0027,\n            [\u0027id\u0027 =\u003e $coupon-\u003egetId()]\n        );\n\n        if (false === $row) {\n            throw new OptimisticLockException(sprintf(\u0027Promotion coupon \"%s\" is no longer applicable.\u0027, $coupon-\u003egetCode()), $coupon);\n        }\n\n        if (null !== $row[\u0027usage_limit\u0027] \u0026\u0026 (int) $row[\u0027used\u0027] \u003e= (int) $row[\u0027usage_limit\u0027]) {\n            throw new OptimisticLockException(sprintf(\u0027Promotion coupon \"%s\" is no longer applicable.\u0027, $coupon-\u003egetCode()), $coupon);\n        }\n\n        if (null !== $row[\u0027per_customer_usage_limit\u0027]) {\n            $this-\u003eassertPerCustomerCouponUsageLimitNotReached(\n                $coupon,\n                $order,\n                (int) $row[\u0027per_customer_usage_limit\u0027]\n            );\n        }\n\n        $this-\u003edoExecuteStatement(\n            \u0027UPDATE sylius_promotion_coupon SET used = used + 1 WHERE id = :id\u0027,\n            [\u0027id\u0027 =\u003e $coupon-\u003egetId()]\n        );\n\n        $coupon-\u003esetUsed((int) $row[\u0027used\u0027] + 1);\n    }\n\n    private function assertPerCustomerCouponUsageLimitNotReached(\n        PromotionCouponInterface $coupon,\n        OrderInterface $order,\n        int $perCustomerUsageLimit\n    ): void {\n        $customer = $order-\u003egetCustomer();\n        if (null === $customer || null === $customer-\u003egetId()) {\n            return;\n        }\n\n        $sql = \u0027SELECT o.id FROM sylius_order o\n                WHERE o.customer_id = :customerId\n                AND o.promotion_coupon_id = :couponId\n                AND o.state != :stateCart\u0027;\n        $params = [\n            \u0027customerId\u0027 =\u003e $customer-\u003egetId(),\n            \u0027couponId\u0027 =\u003e $coupon-\u003egetId(),\n            \u0027stateCart\u0027 =\u003e OrderInterface::STATE_CART,\n        ];\n\n        if ($coupon-\u003eisReusableFromCancelledOrders()) {\n            $sql .= \u0027 AND o.state != :stateCancelled\u0027;\n            $params[\u0027stateCancelled\u0027] = OrderInterface::STATE_CANCELLED;\n        }\n\n        $sql .= \u0027 FOR UPDATE\u0027;\n\n        $count = count($this-\u003edoFetchAllAssociative($sql, $params));\n\n        if ($count \u003e= $perCustomerUsageLimit) {\n            throw new OptimisticLockException(sprintf(\u0027Promotion coupon \"%s\" is no longer applicable.\u0027, $coupon-\u003egetCode()), $coupon);\n        }\n    }\n\n    private function decrementCouponUsage(PromotionCouponInterface $coupon): void\n    {\n        $this-\u003edoExecuteStatement(\n            \u0027UPDATE sylius_promotion_coupon SET used = GREATEST(used - 1, 0) WHERE id = :id\u0027,\n            [\u0027id\u0027 =\u003e $coupon-\u003egetId()]\n        );\n\n        $newUsed = (int) $this-\u003edoFetchOne(\n            \u0027SELECT used FROM sylius_promotion_coupon WHERE id = :id\u0027,\n            [\u0027id\u0027 =\u003e $coupon-\u003egetId()]\n        );\n\n        $coupon-\u003esetUsed($newUsed);\n    }\n\n    /** @return int Number of affected rows */\n    private function doExecuteStatement(string $sql, array $params): int\n    {\n        if (method_exists($this-\u003econnection, \u0027executeStatement\u0027)) {\n            return $this-\u003econnection-\u003eexecuteStatement($sql, $params);\n        }\n\n        return $this-\u003econnection-\u003eexecuteUpdate($sql, $params);\n    }\n\n    /** @return mixed|false */\n    private function doFetchOne(string $sql, array $params)\n    {\n        if (method_exists($this-\u003econnection, \u0027fetchOne\u0027)) {\n            return $this-\u003econnection-\u003efetchOne($sql, $params);\n        }\n\n        return $this-\u003econnection-\u003efetchColumn($sql, $params);\n    }\n\n    /** @return array|false */\n    private function doFetchAssociative(string $sql, array $params)\n    {\n        if (method_exists($this-\u003econnection, \u0027fetchAssociative\u0027)) {\n            return $this-\u003econnection-\u003efetchAssociative($sql, $params);\n        }\n\n        return $this-\u003econnection-\u003efetchAssoc($sql, $params);\n    }\n\n    /** @return array[] */\n    private function doFetchAllAssociative(string $sql, array $params): array\n    {\n        if (method_exists($this-\u003econnection, \u0027fetchAllAssociative\u0027)) {\n            return $this-\u003econnection-\u003efetchAllAssociative($sql, $params);\n        }\n\n        return $this-\u003econnection-\u003efetchAll($sql, $params);\n    }\n}\n```\n\n#### Step 2. Register the service\n\n**Option A:** If your app uses autowiring and supports the `#[AsDecorator]` attribute, uncomment it in the class and no further configuration is necessary.\n\n**Option B:** Manually register the service in `config/services.yaml`:\n\n```yaml\nservices:\n    App\\Modifier\\AtomicOrderPromotionsUsageModifier:\n        decorates: \u0027sylius.promotion_usage_modifier\u0027\n        arguments: [\u0027@doctrine.dbal.default_connection\u0027]\n```\n\n#### Step 3. Update exception mapping (optional)\n\nCheck if your `api_platform` configuration maps `OptimisticLockException` to a code and update it if not:\n```yaml\napi_platform:\n    ...\n    exception_to_status:\n        ...\n        Doctrine\\ORM\\OptimisticLockException: 409\n```\n\n#### Step 4. Clear 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- Djibril Mounkoro (@whiteov3rflow)\n- Bart\u0142omiej Nowi\u0144ski (@bnBart)\n\n### For more information\n\nIf you have any questions or comments about this advisory:\n\n- Open an issue in [Sylius issues](https://github.com/Sylius/Sylius/issues)\n- Email us at [security@sylius.com](mailto:security@sylius.com)",
  "id": "GHSA-7mp4-25j8-hp5q",
  "modified": "2026-03-11T20:33:38Z",
  "published": "2026-03-11T00:13:29Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/Sylius/Sylius/security/advisories/GHSA-7mp4-25j8-hp5q"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-31824"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/Sylius/Sylius"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:H/A:L",
      "type": "CVSS_V3"
    }
  ],
  "summary": "Sylius has a Promotion Usage Limit Bypass via Race Condition"
}

GHSA-7MQW-HR29-PJ76

Vulnerability from github – Published: 2026-05-13 18:30 – Updated: 2026-05-13 18:30
VLAI
Details

csync2 uses insecure temporary directories when compiled with C99 or later, allowing for TOCTOU style attacks on the temporary directories.

Show details on source website

{
  "affected": [],
  "aliases": [
    "CVE-2026-41051"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-367"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2026-05-13T13:01:53Z",
    "severity": "MODERATE"
  },
  "details": "csync2 uses insecure temporary directories when compiled with C99 or later, allowing for TOCTOU style attacks on the temporary directories.",
  "id": "GHSA-7mqw-hr29-pj76",
  "modified": "2026-05-13T18:30:52Z",
  "published": "2026-05-13T18:30:52Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-41051"
    },
    {
      "type": "WEB",
      "url": "https://bugzilla.suse.com/show_bug.cgi?id=CVE-2026-41051"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:L/AC:L/PR:L/UI:R/S:U/C:N/I:N/A:H",
      "type": "CVSS_V3"
    },
    {
      "score": "CVSS:4.0/AV:L/AC:L/AT:N/PR:L/UI:P/VC:N/VI:N/VA:H/SC:N/SI:N/SA:N/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-7PMF-JRH8-VG99

Vulnerability from github – Published: 2023-02-15 03:30 – Updated: 2023-02-23 18:31
VLAI
Details

An issue was discovered in Insyde InsydeH2O with kernel 5.1 through 5.5. DMA attacks on the SdMmcDevice buffer used by SMM and non-SMM code could cause TOCTOU race-condition issues that could lead to corruption of SMRAM and escalation of privileges. This attack can be mitigated by using IOMMU protection for the ACPI runtime memory used for the command buffer. This attack can be mitigated by copying the link data to SMRAM before checking it and verifying that all pointers are within the buffer.

Show details on source website

{
  "affected": [],
  "aliases": [
    "CVE-2022-32954"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-367"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2023-02-15T02:15:00Z",
    "severity": "HIGH"
  },
  "details": "An issue was discovered in Insyde InsydeH2O with kernel 5.1 through 5.5. DMA attacks on the SdMmcDevice buffer used by SMM and non-SMM code could cause TOCTOU race-condition issues that could lead to corruption of SMRAM and escalation of privileges. This attack can be mitigated by using IOMMU protection for the ACPI runtime memory used for the command buffer. This attack can be mitigated by copying the link data to SMRAM before checking it and verifying that all pointers are within the buffer.",
  "id": "GHSA-7pmf-jrh8-vg99",
  "modified": "2023-02-23T18:31:05Z",
  "published": "2023-02-15T03:30:46Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2022-32954"
    },
    {
      "type": "WEB",
      "url": "https://www.insyde.com/security-pledge"
    },
    {
      "type": "WEB",
      "url": "https://www.insyde.com/security-pledge/SA-2023014"
    }
  ],
  "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-7PRC-4C75-54X8

Vulnerability from github – Published: 2025-06-16 09:30 – Updated: 2025-06-17 03:31
VLAI
Details

A race condition vulnerability exists in Armoury Crate. This vulnerability arises from a Time-of-check Time-of-use issue, potentially leading to authentication bypass. Refer to the 'Security Update for Armoury Crate App' section on the ASUS Security Advisory for more information.

Show details on source website

{
  "affected": [],
  "aliases": [
    "CVE-2025-3464"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-367"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2025-06-16T09:15:19Z",
    "severity": "HIGH"
  },
  "details": "A race condition vulnerability exists in Armoury Crate. This vulnerability arises from a Time-of-check Time-of-use issue, potentially leading to authentication bypass.\nRefer to the \u0027Security Update for Armoury Crate App\u0027 section on the ASUS Security Advisory for more information.",
  "id": "GHSA-7prc-4c75-54x8",
  "modified": "2025-06-17T03:31:44Z",
  "published": "2025-06-16T09:30:38Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2025-3464"
    },
    {
      "type": "WEB",
      "url": "https://talosintelligence.com/vulnerability_reports/TALOS-2024-2150"
    },
    {
      "type": "WEB",
      "url": "https://talosintelligence.com/vulnerability_reports/TALOS-2025-2150"
    },
    {
      "type": "WEB",
      "url": "https://www.asus.com/content/asus-product-security-advisory"
    },
    {
      "type": "WEB",
      "url": "https://www.talosintelligence.com/vulnerability_reports/TALOS-2025-2150"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:4.0/AV:L/AC:L/AT:N/PR:L/UI:N/VC:L/VI:H/VA:H/SC:L/SI:H/SA:H/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-7QF6-H84J-8FQ4

Vulnerability from github – Published: 2026-03-03 22:21 – Updated: 2026-03-03 22:21
VLAI
Summary
OpenClaw: Microsoft Teams media fetch paths bypass shared SSRF guard model
Details

Impact

Microsoft Teams media handling used mixed fetch paths for Graph metadata/content and attachment auth-retry flows. Some paths bypassed the shared SSRF guard model and created inconsistent host/DNS enforcement across redirect/fetch hops.

Affected Packages / Versions

  • Package: openclaw (npm)
  • Latest published vulnerable version: 2026.2.25
  • Affected range: <= 2026.2.25
  • Planned patched version for next release: 2026.2.26

Technical Details

The Microsoft Teams attachment/media code previously relied on plugin-local fetch behavior in parts of the flow, instead of uniformly using shared guarded fetch logic with pinned DNS + policy checks. This could allow policy drift and SSRF boundary inconsistency between channel/plugin paths.

The fix unifies this path by: - routing Microsoft Teams Graph message/hosted-content/attachment fetches through shared SSRF-guarded fetch paths, - routing auth-scope fallback attachment downloads through the same guarded policy model, - centralizing hostname-suffix allowlist policy helpers in plugin-sdk so channel/plugins use the same allowlist normalization and policy construction behavior.

Fix Commit(s)

  • 57334cd7d85174d5f951de01114fd5801b063564

OpenClaw thanks @tdjackey for reporting.

Show details on source website

{
  "affected": [
    {
      "database_specific": {
        "last_known_affected_version_range": "\u003c= 2026.2.25"
      },
      "package": {
        "ecosystem": "npm",
        "name": "openclaw"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "2026.2.26"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [],
  "database_specific": {
    "cwe_ids": [
      "CWE-367",
      "CWE-918"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2026-03-03T22:21:59Z",
    "nvd_published_at": null,
    "severity": "LOW"
  },
  "details": "## Impact\nMicrosoft Teams media handling used mixed fetch paths for Graph metadata/content and attachment auth-retry flows. Some paths bypassed the shared SSRF guard model and created inconsistent host/DNS enforcement across redirect/fetch hops.\n\n## Affected Packages / Versions\n- Package: `openclaw` (npm)\n- Latest published vulnerable version: `2026.2.25`\n- Affected range: `\u003c= 2026.2.25`\n- Planned patched version for next release: `2026.2.26`\n\n## Technical Details\nThe Microsoft Teams attachment/media code previously relied on plugin-local fetch behavior in parts of the flow, instead of uniformly using shared guarded fetch logic with pinned DNS + policy checks. This could allow policy drift and SSRF boundary inconsistency between channel/plugin paths.\n\nThe fix unifies this path by:\n- routing Microsoft Teams Graph message/hosted-content/attachment fetches through shared SSRF-guarded fetch paths,\n- routing auth-scope fallback attachment downloads through the same guarded policy model,\n- centralizing hostname-suffix allowlist policy helpers in `plugin-sdk` so channel/plugins use the same allowlist normalization and policy construction behavior.\n\n## Fix Commit(s)\n- `57334cd7d85174d5f951de01114fd5801b063564`\n\nOpenClaw thanks @tdjackey for reporting.",
  "id": "GHSA-7qf6-h84j-8fq4",
  "modified": "2026-03-03T22:21:59Z",
  "published": "2026-03-03T22:21:59Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/openclaw/openclaw/security/advisories/GHSA-7qf6-h84j-8fq4"
    },
    {
      "type": "WEB",
      "url": "https://github.com/openclaw/openclaw/commit/57334cd7d85174d5f951de01114fd5801b063564"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/openclaw/openclaw"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:4.0/AV:N/AC:H/AT:P/PR:L/UI:N/VC:N/VI:N/VA:N/SC:L/SI:N/SA:N",
      "type": "CVSS_V4"
    }
  ],
  "summary": "OpenClaw: Microsoft Teams media fetch paths bypass shared SSRF guard model"
}

GHSA-7QMX-3FPX-R45M

Vulnerability from github – Published: 2024-10-09 19:14 – Updated: 2026-06-08 20:00
VLAI
Summary
Wasmtime race condition could lead to WebAssembly control-flow integrity and type safety violations
Details

Impact

Under certain concurrent event orderings, a wasmtime::Engine's internal type registry was susceptible to double-unregistration bugs due to a race condition, leading to panics and potentially type registry corruption. That registry corruption could, following an additional and particular sequence of concurrent events, lead to violations of WebAssembly's control-flow integrity (CFI) and type safety. Users that do not use wasmtime::Engine across multiple threads are not affected. Users that only create new modules across threads over time are additionally not affected.

Reproducing this bug requires creating and dropping multiple type instances (such as wasmtime::FuncType or wasmtime::ArrayType) concurrently on multiple threads, where all types are associated with the same wasmtime::Engine. Wasm guests cannot trigger this bug. See the "References" section below for a list of Wasmtime types-related APIs that are affected.

Wasmtime maintains an internal registry of types within a wasmtime::Engine and an engine is shareable across threads. Types can be created and referenced through creation of a wasmtime::Module, creation of wasmtime::FuncType, or a number of other APIs where the host creates a function (see "References" below). Each of these cases interacts with an engine to deduplicate type information and manage type indices that are used to implement type checks in WebAssembly's call_indirect function, for example. This bug is a race condition in this management where the internal type registry could be corrupted to trigger an assert or contain invalid state.

Wasmtime's internal representation of a type has individual types (e.g. one-per-host-function) maintain a registration count of how many time it's been used. Types additionally have state within an engine behind a read-write lock such as lookup/deduplication information. The race here is a time-of-check versus time-of-use (TOCTOU) bug where one thread atomically decrements a type entry's registration count, observes zero registrations, and then acquires a lock in order to unregister that entry. However, between when this first thread observed the zero-registration count and when it acquires that lock, another thread could perform the following sequence of events: re-register another copy of the type, which deduplicates to that same entry, resurrecting it and incrementing its registration count; then drop the type and decrement its registration count; observe that the registration count is now zero; acquire the type registry lock; and finally unregister the type. Now, when the original thread finally acquires the lock and unregisters the entry, it is the second time this entry has been unregistered.

Thread A Thread B
acquire(type registry lock)
decref(E) --> 0
block_on(type registry lock)
register(E') == incref(E) --> 1
release(type registry lock)
decref(E) --> 0
acquire(type registry lock)
unregister(E)
release(type registry lock)
acquire(type registry lock)
unregister(E)

This double-unregistration could then lead to a WebAssembly CFI violation under the following conditions: a new WebAssembly module X was loaded into the engine before the second, buggy unregistration occurs; X defined a function type F that was allocated in the same type registry slot where the original entry was allocated; the second, buggy unregistration incorrectly unregistered F; another new WebAssembly module Y was loaded into the engine; Y defined a function type G, different from F, but which is also allocated in the same type registry slot; a funcref of type G is created, either by the host or by Wasm; that funcref is passed to a WebAssembly instance of module X; that instance performs a call_indirect to that funcref; the call_indirect's dynamic type check, which preserves CFI, could incorrectly pass in this case, because F and G were assigned the same type registry slot. This would, ultimately, allow calling a function with too many, too few, or wrongly-typed arguments, violating CFI and type safety.

We were not able to reproduce this CFI violation in a vanilla Wasmtime build, although it remains theoretically possible. However, by modifying Wasmtime's source code to make losing the races described above more likely (by disabling certain assertions, inserting panic catches, and adding retry loops in a few places if we did not lose the race) we were able to incorrectly get a funcref to pass a type check that it should have failed, which would allow the CFI violation.

Patches

This bug was originally introduced in Wasmtime 19's development of the WebAssembly GC proposal. This bug affects users who are not using the GC proposal, however, and affects Wasmtime in its default configuration even when the GC proposal is disabled. Wasmtime users using 19.0.0 and after are all affected by this issue. We have released the following Wasmtime versions, all of which have a fix for this bug:

  • 21.0.2
  • 22.0.1
  • 23.0.3
  • 24.0.1
  • 25.0.2

Workarounds

If your application creates and drops Wasmtime types on multiple threads concurrently, there are no known workarounds. Users are encouraged to upgrade to a patched release.

References

The following APIs create or drop types, and therefore are affected by this race condition if performed on multiple threads concurrently and are all associated with the same wasmtime::Engine:

The change which introduced this bug was #7969

Show details on source website

{
  "affected": [
    {
      "package": {
        "ecosystem": "crates.io",
        "name": "wasmtime"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "19.0.0"
            },
            {
              "fixed": "21.0.2"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    },
    {
      "package": {
        "ecosystem": "crates.io",
        "name": "wasmtime"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "22.0.0"
            },
            {
              "fixed": "22.0.1"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    },
    {
      "package": {
        "ecosystem": "crates.io",
        "name": "wasmtime"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "23.0.0"
            },
            {
              "fixed": "23.0.3"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    },
    {
      "package": {
        "ecosystem": "crates.io",
        "name": "wasmtime"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "24.0.0"
            },
            {
              "fixed": "24.0.1"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    },
    {
      "package": {
        "ecosystem": "crates.io",
        "name": "wasmtime"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "25.0.0"
            },
            {
              "fixed": "25.0.2"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2024-47813"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-367"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2024-10-09T19:14:35Z",
    "nvd_published_at": "2024-10-09T18:15:09Z",
    "severity": "LOW"
  },
  "details": "### Impact\n\nUnder certain concurrent event orderings, a `wasmtime::Engine`\u0027s internal type registry was susceptible to double-unregistration bugs due to a race condition, leading to panics and potentially type registry corruption. That registry corruption could, following an additional and particular sequence of concurrent events, lead to violations of WebAssembly\u0027s control-flow integrity (CFI) and type safety. Users that do not use `wasmtime::Engine` across multiple threads are not affected. Users that only create new modules across threads over time are additionally not affected.\n\nReproducing this bug requires creating and dropping multiple type instances (such as `wasmtime::FuncType` or `wasmtime::ArrayType`) concurrently on multiple threads, where all types are associated with the same `wasmtime::Engine`. **Wasm guests cannot trigger this bug.** See the \"References\" section below for a list of Wasmtime types-related APIs that are affected.\n\nWasmtime maintains an internal registry of types within a `wasmtime::Engine` and an engine is shareable across threads. Types can be created and referenced through creation of a `wasmtime::Module`, creation of `wasmtime::FuncType`, or a number of other APIs where the host creates a function (see \"References\" below). Each of these cases interacts with an engine to deduplicate type information and manage type indices that are used to implement type checks in WebAssembly\u0027s `call_indirect` function, for example. This bug is a race condition in this management where the internal type registry could be corrupted to trigger an assert or contain invalid state.\n\nWasmtime\u0027s internal representation of a type has individual types (e.g. one-per-host-function) maintain a registration count of how many time it\u0027s been used. Types additionally have state within an engine behind a read-write lock such as lookup/deduplication information. The race here is a time-of-check versus time-of-use (TOCTOU) bug where one thread atomically decrements a type entry\u0027s registration count, observes zero registrations, and then acquires a lock in order to unregister that entry. However, between when this first thread observed the zero-registration count and when it acquires that lock, another thread could perform the following sequence of events: re-register another copy of the type, which deduplicates to that same entry, resurrecting it and incrementing its registration count; then drop the type and decrement its registration count; observe that the registration count is now zero; acquire the type registry lock; and finally unregister the type. Now, when the original thread finally acquires the lock and unregisters the entry, it is the second time this entry has been unregistered.\n\n| Thread A                          | Thread B                       |\n|-----------------------------------|--------------------------------|\n| `acquire(type registry lock)`     |                                |\n|                                   | `decref(E) --\u003e 0`              |\n|                                   | `block_on(type registry lock)` |\n| `register(E\u0027) == incref(E) --\u003e 1` |                                |\n| `release(type registry lock)`     |                                |\n| `decref(E) --\u003e 0`                 |                                |\n| `acquire(type registry lock)`     |                                |\n| `unregister(E)`                   |                                |\n| `release(type registry lock)`     |                                |\n|                                   | `acquire(type registry lock)`  |\n|                                   | `unregister(E)`          |\n\n\nThis double-unregistration could then lead to a WebAssembly CFI violation under the following conditions: a new WebAssembly module `X` was loaded into the engine before the second, buggy unregistration occurs; `X` defined a function type `F` that was allocated in the same type registry slot where the original entry was allocated; the second, buggy unregistration incorrectly unregistered `F`; another new WebAssembly module `Y` was loaded into the engine; `Y` defined a function type `G`, different from `F`, but which is also allocated in the same type registry slot; a `funcref` of type `G` is created, either by the host or by Wasm; that `funcref` is passed to a WebAssembly instance of module `X`; that instance performs a `call_indirect` to that `funcref`; the `call_indirect`\u0027s dynamic type check, which preserves CFI, could incorrectly pass in this case, because `F` and `G` were assigned the same type registry slot. This would, ultimately, allow calling a function with too many, too few, or wrongly-typed arguments, violating CFI and type safety.\n\nWe were not able to reproduce this CFI violation in a vanilla Wasmtime build, although it remains theoretically possible. However, by modifying Wasmtime\u0027s source code to make losing the races described above more likely (by disabling certain assertions, inserting panic catches, and adding retry loops in a few places if we did *not* lose the race) we were able to incorrectly get a `funcref` to pass a type check that it should have failed, which would allow the CFI violation.\n\n### Patches\n\nThis bug was originally introduced in Wasmtime 19\u0027s development of the WebAssembly GC proposal. This bug affects users who are not using the GC proposal, however, and affects Wasmtime in its default configuration even when the GC proposal is disabled. Wasmtime users using 19.0.0 and after are all affected by this issue. We have released the following Wasmtime versions, all of which have a fix for this bug:\n\n* 21.0.2\n* 22.0.1\n* 23.0.3\n* 24.0.1\n* 25.0.2\n\n### Workarounds\n\nIf your application creates and drops Wasmtime types on multiple threads concurrently, there are no known workarounds. Users are encouraged to upgrade to a patched release. \n\n### References\n\nThe following APIs create or drop types, and therefore are affected by this race condition if performed on multiple threads concurrently and are all associated with the same `wasmtime::Engine`:\n\n* [`wasmtime::FuncType::new`](https://docs.rs/wasmtime/latest/wasmtime/struct.FuncType.html#method.new)\n  * Also reachable from creation of [`wasmtime::Func`](https://docs.rs/wasmtime/latest/wasmtime/struct.Func.html)\n  * Also reachable from [`wasmtime::Linker::func_*`](https://docs.rs/wasmtime/latest/wasmtime/struct.Linker.html#method.func_new)\n* [`wasmtime::ArrayType::new`](https://docs.rs/wasmtime/latest/wasmtime/struct.ArrayType.html#method.new)\n* [`wasmtime::StructType::new`](https://docs.rs/wasmtime/latest/wasmtime/struct.StructType.html#method.new)\n* [`wasmtime::Func::ty`](https://docs.rs/wasmtime/latest/wasmtime/struct.Func.html#method.ty)\n* [`wasmtime::Global::ty`](https://docs.rs/wasmtime/latest/wasmtime/struct.Global.html#method.ty)\n* [`wasmtime::Table::ty`](https://docs.rs/wasmtime/latest/wasmtime/struct.Table.html#method.ty)\n* [`wasmtime::Extern::ty`](https://docs.rs/wasmtime/latest/wasmtime/struct.Extern.html#method.ty)\n* [`wasmtime::Export::ty`](https://docs.rs/wasmtime/latest/wasmtime/struct.Export.html#method.ty)\n* [`wasmtime::UnknownImportError::ty`](https://docs.rs/wasmtime/latest/wasmtime/struct.UnknownImportError.html#method.ty)\n* [`wasmtime::ImportType::ty`](https://docs.rs/wasmtime/latest/wasmtime/struct.ImportType.html#method.ty)\n* [`wasmtime::ExportType::ty`](https://docs.rs/wasmtime/latest/wasmtime/struct.ExportType.html#method.ty)\n* [`wasmtime::Val::ty`](https://docs.rs/wasmtime/latest/wasmtime/struct.Val.html#method.ty)\n* [`wasmtime::Ref::ty`](https://docs.rs/wasmtime/latest/wasmtime/struct.Ref.html#method.ty)\n* [`wasmtime::AnyRef::ty`](https://docs.rs/wasmtime/latest/wasmtime/struct.AnyRef.html#method.ty)\n* [`wasmtime::EqRef::ty`](https://docs.rs/wasmtime/latest/wasmtime/struct.EqRef.html#method.ty)\n* [`wasmtime::ArrayRef::ty`](https://docs.rs/wasmtime/latest/wasmtime/struct.ArrayRef.html#method.ty)\n* [`wasmtime::StructRef::ty`](https://docs.rs/wasmtime/latest/wasmtime/struct.StructRef.html#method.ty)\n* Dropping a [`wasmtime::FuncType`](https://docs.rs/wasmtime/latest/wasmtime/struct.FuncType.html)\n* Dropping a [`wasmtime::ArrayType`](https://docs.rs/wasmtime/latest/wasmtime/struct.ArrayType.html)\n* Dropping a [`wasmtime::StructType`](https://docs.rs/wasmtime/latest/wasmtime/struct.StructType.html)\n* Dropping a [`wasmtime::ExternType`](https://docs.rs/wasmtime/latest/wasmtime/struct.ExternType.html)\n* Dropping a [`wasmtime::GlobalType`](https://docs.rs/wasmtime/latest/wasmtime/struct.GlobalType.html)\n* Dropping a [`wasmtime::TableType`](https://docs.rs/wasmtime/latest/wasmtime/struct.TableType.html)\n* Dropping a [`wasmtime::ValType`](https://docs.rs/wasmtime/latest/wasmtime/struct.ValType.html)\n* Dropping a [`wasmtime::RefType`](https://docs.rs/wasmtime/latest/wasmtime/struct.RefType.html)\n* Dropping a [`wasmtime::HeapType`](https://docs.rs/wasmtime/latest/wasmtime/struct.HeapType.html)\n* Dropping a [`wasmtime::UnknownImportError`](https://docs.rs/wasmtime/latest/wasmtime/struct.UnknownImportError.html)\n* Dropping a [`wasmtime::Linker`](https://docs.rs/wasmtime/latest/wasmtime/struct.Linker.html)\n\nThe change which introduced this bug was [#7969](https://github.com/bytecodealliance/wasmtime/pull/7969)",
  "id": "GHSA-7qmx-3fpx-r45m",
  "modified": "2026-06-08T20:00:15Z",
  "published": "2024-10-09T19:14:35Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/bytecodealliance/wasmtime/security/advisories/GHSA-7qmx-3fpx-r45m"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-47813"
    },
    {
      "type": "WEB",
      "url": "https://github.com/bytecodealliance/wasmtime/pull/7969"
    },
    {
      "type": "WEB",
      "url": "https://github.com/bytecodealliance/wasmtime/commit/0ebe54d05f0e1f6c64b7c8bb48c9e9f6c95cacba"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/bytecodealliance/wasmtime"
    },
    {
      "type": "WEB",
      "url": "https://github.com/pypa/advisory-database/tree/main/vulns/wasmtime/PYSEC-2024-311.yaml"
    },
    {
      "type": "WEB",
      "url": "https://rustsec.org/advisories/RUSTSEC-2024-0439.html"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:L/AC:H/PR:H/UI:R/S:U/C:N/I:L/A:L",
      "type": "CVSS_V3"
    },
    {
      "score": "CVSS:4.0/AV:L/AC:L/AT:P/PR:H/UI:A/VC:N/VI:L/VA:L/SC:N/SI:N/SA:N",
      "type": "CVSS_V4"
    }
  ],
  "summary": "Wasmtime race condition could lead to WebAssembly control-flow integrity and type safety violations"
}

GHSA-7QRF-MVGV-R448

Vulnerability from github – Published: 2024-05-03 03:30 – Updated: 2024-05-03 03:30
VLAI
Details

Parallels Desktop Toolgate Time-Of-Check Time-Of-Use Local Privilege Escalation Vulnerability. This vulnerability allows local attackers to escalate privileges on affected installations of Parallels Desktop. An attacker must first obtain the ability to execute high-privileged code on the target guest system in order to exploit this vulnerability.

The specific flaw exists within the Toolgate component. The issue results from the lack of proper locking when performing operations on an object. An attacker can leverage this vulnerability to escalate privileges and execute arbitrary code in the context of the current user on the host system. Was ZDI-CAN-18964.

Show details on source website

{
  "affected": [],
  "aliases": [
    "CVE-2023-27327"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-367"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2024-05-03T02:15:09Z",
    "severity": "HIGH"
  },
  "details": "Parallels Desktop Toolgate Time-Of-Check Time-Of-Use Local Privilege Escalation Vulnerability. This vulnerability allows local attackers to escalate privileges on affected installations of Parallels Desktop. An attacker must first obtain the ability to execute high-privileged code on the target guest system in order to exploit this vulnerability.\n\nThe specific flaw exists within the Toolgate component. The issue results from the lack of proper locking when performing operations on an object. An attacker can leverage this vulnerability to escalate privileges and execute arbitrary code in the context of the current user on the host system. Was ZDI-CAN-18964.",
  "id": "GHSA-7qrf-mvgv-r448",
  "modified": "2024-05-03T03:30:47Z",
  "published": "2024-05-03T03:30:47Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2023-27327"
    },
    {
      "type": "WEB",
      "url": "https://kb.parallels.com/125013"
    },
    {
      "type": "WEB",
      "url": "https://www.zerodayinitiative.com/advisories/ZDI-23-215"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.0/AV:L/AC:H/PR:H/UI:N/S:C/C:H/I:H/A:H",
      "type": "CVSS_V3"
    }
  ]
}

Mitigation
Implementation

The most basic advice for TOCTOU vulnerabilities is to not perform a check before the use. This does not resolve the underlying issue of the execution of a function on a resource whose state and identity cannot be assured, but it does help to limit the false sense of security given by the check.

Mitigation
Implementation

When the file being altered is owned by the current user and group, set the effective gid and uid to that of the current user and group when executing this statement.

Mitigation
Architecture and Design

Limit the interleaving of operations on files from multiple processes.

Mitigation
Implementation Architecture and Design

If you cannot perform operations atomically and you must share access to the resource between multiple processes or threads, then try to limit the amount of time (CPU cycles) between the check and use of the resource. This will not fix the problem, but it could make it more difficult for an attack to succeed.

Mitigation
Implementation

Recheck the resource after the use call to verify that the action was taken appropriately.

Mitigation
Architecture and Design

Ensure that some environmental locking mechanism can be used to protect resources effectively.

Mitigation
Implementation

Ensure that locking occurs before the check, as opposed to afterwards, such that the resource, as checked, is the same as it is when in use.

CAPEC-27: Leveraging Race Conditions via Symbolic Links

This attack leverages the use of symbolic links (Symlinks) in order to write to sensitive files. An attacker can create a Symlink link to a target file not otherwise accessible to them. When the privileged program tries to create a temporary file with the same name as the Symlink link, it will actually write to the target file pointed to by the attackers' Symlink link. If the attacker can insert malicious content in the temporary file they will be writing to the sensitive file by using the Symlink. The race occurs because the system checks if the temporary file exists, then creates the file. The attacker would typically create the Symlink during the interval between the check and the creation of the temporary file.

CAPEC-29: Leveraging Time-of-Check and Time-of-Use (TOCTOU) Race Conditions

This attack targets a race condition occurring between the time of check (state) for a resource and the time of use of a resource. A typical example is file access. The adversary can leverage a file access race condition by "running the race", meaning that they would modify the resource between the first time the target program accesses the file and the time the target program uses the file. During that period of time, the adversary could replace or modify the file, causing the application to behave unexpectedly.