CWE-362
Allowed-with-ReviewConcurrent Execution using Shared Resource with Improper Synchronization ('Race Condition')
Abstraction: Class · Status: Draft
The product contains a concurrent code sequence that requires temporary, exclusive access to a shared resource, but a timing window exists in which the shared resource can be modified by another code sequence operating concurrently.
2900 vulnerabilities reference this CWE, most recent first.
GHSA-7M47-393H-XM3Q
Vulnerability from github – Published: 2023-04-18 18:30 – Updated: 2024-04-04 03:32A Race Condition exists in the Qualys Cloud Agent for Windows platform in versions from 3.1.3.34 and before 4.5.3.1. This allows attackers to escalate privileges limited on the local machine during uninstallation of the Qualys Cloud Agent for Windows. Attackers may gain SYSTEM level privileges on that asset to run arbitrary commands.
At the time of this disclosure, versions before 4.0 are classified as End of Life.
{
"affected": [],
"aliases": [
"CVE-2023-28142"
],
"database_specific": {
"cwe_ids": [
"CWE-362"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2023-04-18T16:15:09Z",
"severity": "HIGH"
},
"details": "\nA Race Condition exists in the Qualys Cloud Agent for Windows\nplatform in versions from 3.1.3.34 and before 4.5.3.1. This allows attackers to\nescalate privileges limited on the local machine during uninstallation of the\nQualys Cloud Agent for Windows. Attackers may gain SYSTEM level privileges on\nthat asset to run arbitrary commands.\n\n\n\nAt the time of this disclosure, versions before 4.0 are classified as End\nof Life.\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n",
"id": "GHSA-7m47-393h-xm3q",
"modified": "2024-04-04T03:32:10Z",
"published": "2023-04-18T18:30:28Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2023-28142"
},
{
"type": "WEB",
"url": "https://www.qualys.com/security-advisories"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:L/AC:H/PR:L/UI:R/S:U/C:H/I:H/A:H",
"type": "CVSS_V3"
}
]
}
GHSA-7M55-2HR4-PW78
Vulnerability from github – Published: 2026-04-10 21:00 – Updated: 2026-04-27 16:21Summary
The localLoginHandlers struct in the Juju API server maintains an in-memory map to store discharge tokens following successful local authentication. This map is accessed concurrently from multiple HTTP handler goroutines without any synchronization primitive protecting it. The absence of a mutex or equivalent mechanism means that concurrent reads, writes, and deletes on the map can trigger Go runtime panics and may allow a discharge token to be consumed more than once before deletion completes.
Details
When a user authenticates through the local login flow, a discharge token is generated and stored in a plain map[string]string field named userTokens. The form handler writes to this map when authentication succeeds, and the third-party caveat checker reads from and deletes from the same map when a discharge request arrives. Both code paths execute inside goroutines dispatched by the HTTP server, meaning concurrent requests will access the map simultaneously.
Go's runtime detects concurrent map access and will terminate the process with a fatal error when a write races with another write or read. This makes the API server susceptible to a denial-of-service attack from any authenticated user who can trigger simultaneous discharge requests. Beyond the crash scenario, the read-then-delete sequence in the caveat checker is not atomic. Two goroutines processing the same token concurrently may both pass the existence check before either executes the deletion, allowing a single-use discharge token to be accepted more than once and effectively replaying authentication.
The struct definition that introduces the unsafe field is shown below.
type localLoginHandlers struct {
authCtxt *authContext
userTokens map[string]string
}
The concurrent access originates from the caveat checker calling username, ok := h.userTokens[tokenString] followed by delete(h.userTokens, tokenString) with no lock held, while formHandler concurrently executes h.userTokens[token] = username in a separate goroutine.
PoC
package main
import (
"net/http"
"sync"
)
func main() {
token := "acquired-discharge-token"
endpoint := "https://target-juju-api:17070/local-login/discharge"
var wg sync.WaitGroup
for i := 0; i < 20; i++ {
wg.Add(1)
go func() {
defer wg.Done()
req, _ := http.NewRequest("GET", endpoint+"?token="+token, nil)
http.DefaultClient.Do(req)
}()
}
wg.Wait()
}
Impact
Any authenticated user who obtains a valid discharge token can send a burst of concurrent requests to the discharge endpoint. The most reliable outcome is a Go runtime panic caused by concurrent map access, which terminates the Juju API server process and denies service to all connected clients and agents. Under favorable timing conditions the same token may be accepted by multiple goroutines before deletion, bypassing the single-use enforcement and allowing repeated authentication with a token that should have been invalidated after first use.
{
"affected": [
{
"package": {
"ecosystem": "Go",
"name": "github.com/juju/juju"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"fixed": "0.0.0-20260408003526-d395054dc2c3"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [
"CVE-2026-5774"
],
"database_specific": {
"cwe_ids": [
"CWE-362"
],
"github_reviewed": true,
"github_reviewed_at": "2026-04-10T21:00:35Z",
"nvd_published_at": "2026-04-10T13:16:46Z",
"severity": "MODERATE"
},
"details": "### Summary\n\nThe localLoginHandlers struct in the Juju API server maintains an in-memory map to store discharge tokens following successful local authentication. This map is accessed concurrently from multiple HTTP handler goroutines without any synchronization primitive protecting it. The absence of a mutex or equivalent mechanism means that concurrent reads, writes, and deletes on the map can trigger Go runtime panics and may allow a discharge token to be consumed more than once before deletion completes.\n\n### Details\n\nWhen a user authenticates through the local login flow, a discharge token is generated and stored in a plain `map[string]string` field named userTokens. The form handler writes to this map when authentication succeeds, and the third-party caveat checker reads from and deletes from the same map when a discharge request arrives. Both code paths execute inside goroutines dispatched by the HTTP server, meaning concurrent requests will access the map simultaneously.\n\nGo\u0027s runtime detects concurrent map access and will terminate the process with a fatal error when a write races with another write or read. This makes the API server susceptible to a denial-of-service attack from any authenticated user who can trigger simultaneous discharge requests. Beyond the crash scenario, the read-then-delete sequence in the caveat checker is not atomic. Two goroutines processing the same token concurrently may both pass the existence check before either executes the deletion, allowing a single-use discharge token to be accepted more than once and effectively replaying authentication.\n\nThe struct definition that introduces the unsafe field is shown below.\n\n```go\ntype localLoginHandlers struct {\n authCtxt *authContext\n userTokens map[string]string\n}\n```\n\nThe concurrent access originates from the caveat checker calling `username, ok := h.userTokens[tokenString]` followed by `delete(h.userTokens, tokenString)` with no lock held, while formHandler concurrently executes `h.userTokens[token] = username` in a separate goroutine.\n\n### PoC\n\n```go\npackage main\n\nimport (\n \"net/http\"\n \"sync\"\n)\n\nfunc main() {\n token := \"acquired-discharge-token\"\n endpoint := \"https://target-juju-api:17070/local-login/discharge\"\n\n var wg sync.WaitGroup\n for i := 0; i \u003c 20; i++ {\n wg.Add(1)\n go func() {\n defer wg.Done()\n req, _ := http.NewRequest(\"GET\", endpoint+\"?token=\"+token, nil)\n http.DefaultClient.Do(req)\n }()\n }\n wg.Wait()\n}\n```\n\n### Impact\n\nAny authenticated user who obtains a valid discharge token can send a burst of concurrent requests to the discharge endpoint. The most reliable outcome is a Go runtime panic caused by concurrent map access, which terminates the Juju API server process and denies service to all connected clients and agents. Under favorable timing conditions the same token may be accepted by multiple goroutines before deletion, bypassing the single-use enforcement and allowing repeated authentication with a token that should have been invalidated after first use.",
"id": "GHSA-7m55-2hr4-pw78",
"modified": "2026-04-27T16:21:10Z",
"published": "2026-04-10T21:00:35Z",
"references": [
{
"type": "WEB",
"url": "https://github.com/juju/juju/security/advisories/GHSA-7m55-2hr4-pw78"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-5774"
},
{
"type": "WEB",
"url": "https://github.com/juju/juju/pull/22205"
},
{
"type": "WEB",
"url": "https://github.com/juju/juju/pull/22206"
},
{
"type": "PACKAGE",
"url": "https://github.com/juju/juju"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:H/PR:L/UI:N/S:U/C:L/I:L/A:H",
"type": "CVSS_V3"
},
{
"score": "CVSS:4.0/AV:N/AC:H/AT:P/PR:L/UI:N/VC:L/VI:L/VA:H/SC:N/SI:N/SA:N",
"type": "CVSS_V4"
}
],
"summary": "Juju: In-Memory Token Store for Discharge Tokens Lacks Concurrency Safety and Persistence"
}
GHSA-7MG7-M5C3-3HQJ
Vulnerability from github – Published: 2021-08-25 21:00 – Updated: 2021-08-24 17:47Affected versions of this crate unconditionally implemented Send & Sync for types PinSlab<T> & Unordered<T, S>. This allows sending non-Send types to other threads and concurrently accessing non-Sync types from multiple threads.
This can result in a data race & memory corruption when types that provide internal mutability without synchronization are contained within PinSlab<T> or Unordered<T, S> and accessed concurrently from multiple threads.
The flaw was corrected in commits 92f40b4 & 6a6c367 by adding trait bound T: Send to Send impls for PinSlab<T> & Unordered<T, S> and adding T: Sync to Sync impls for PinSlab<T> & Unordered<T, S>.
{
"affected": [
{
"package": {
"ecosystem": "crates.io",
"name": "unicycle"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"fixed": "0.7.1"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [],
"database_specific": {
"cwe_ids": [
"CWE-362"
],
"github_reviewed": true,
"github_reviewed_at": "2021-08-05T21:14:52Z",
"nvd_published_at": null,
"severity": "MODERATE"
},
"details": "Affected versions of this crate unconditionally implemented `Send` \u0026 `Sync` for types `PinSlab\u003cT\u003e` \u0026 `Unordered\u003cT, S\u003e`. This allows sending non-Send types to other threads and concurrently accessing non-Sync types from multiple threads.\n\nThis can result in a data race \u0026 memory corruption when types that provide internal mutability without synchronization are contained within `PinSlab\u003cT\u003e` or `Unordered\u003cT, S\u003e` and accessed concurrently from multiple threads.\n\nThe flaw was corrected in commits 92f40b4 \u0026 6a6c367 by adding trait bound `T: Send` to `Send` impls for `PinSlab\u003cT\u003e` \u0026 `Unordered\u003cT, S\u003e` and adding `T: Sync` to `Sync` impls for `PinSlab\u003cT\u003e` \u0026 `Unordered\u003cT, S\u003e`.\n",
"id": "GHSA-7mg7-m5c3-3hqj",
"modified": "2021-08-24T17:47:15Z",
"published": "2021-08-25T21:00:39Z",
"references": [
{
"type": "WEB",
"url": "https://github.com/udoprog/unicycle/issues/8"
},
{
"type": "WEB",
"url": "https://github.com/udoprog/unicycle/commit/6a6c367a0c25f86f998fa315ea90c328f685b194"
},
{
"type": "WEB",
"url": "https://github.com/udoprog/unicycle/commit/92f40b4a2c671553dfa96feacff0265206c44ce5"
},
{
"type": "PACKAGE",
"url": "https://github.com/udoprog/unicycle"
},
{
"type": "WEB",
"url": "https://rustsec.org/advisories/RUSTSEC-2020-0116.html"
}
],
"schema_version": "1.4.0",
"severity": [],
"summary": "Data races in unicycle",
"withdrawn": "2021-08-24T17:47:15Z"
}
GHSA-7MHJ-67X6-FH4Q
Vulnerability from github – Published: 2022-05-01 23:39 – Updated: 2025-04-09 03:54Race condition in the directory notification subsystem (dnotify) in Linux kernel 2.6.x before 2.6.24.6, and 2.6.25 before 2.6.25.1, allows local users to cause a denial of service (OOPS) and possibly gain privileges via unspecified vectors.
{
"affected": [],
"aliases": [
"CVE-2008-1375"
],
"database_specific": {
"cwe_ids": [
"CWE-362"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2008-05-02T16:05:00Z",
"severity": "MODERATE"
},
"details": "Race condition in the directory notification subsystem (dnotify) in Linux kernel 2.6.x before 2.6.24.6, and 2.6.25 before 2.6.25.1, allows local users to cause a denial of service (OOPS) and possibly gain privileges via unspecified vectors.",
"id": "GHSA-7mhj-67x6-fh4q",
"modified": "2025-04-09T03:54:14Z",
"published": "2022-05-01T23:39:32Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2008-1375"
},
{
"type": "WEB",
"url": "https://exchange.xforce.ibmcloud.com/vulnerabilities/42131"
},
{
"type": "WEB",
"url": "https://issues.rpath.com/browse/RPL-2501"
},
{
"type": "WEB",
"url": "https://oval.cisecurity.org/repository/search/definition/oval%3Aorg.mitre.oval%3Adef%3A11843"
},
{
"type": "WEB",
"url": "https://usn.ubuntu.com/614-1"
},
{
"type": "WEB",
"url": "https://www.redhat.com/archives/fedora-package-announce/2008-May/msg00232.html"
},
{
"type": "WEB",
"url": "http://lists.opensuse.org/opensuse-security-announce/2008-06/msg00006.html"
},
{
"type": "WEB",
"url": "http://lists.opensuse.org/opensuse-security-announce/2008-07/msg00000.html"
},
{
"type": "WEB",
"url": "http://lists.opensuse.org/opensuse-security-announce/2008-07/msg00002.html"
},
{
"type": "WEB",
"url": "http://lists.vmware.com/pipermail/security-announce/2008/000023.html"
},
{
"type": "WEB",
"url": "http://marc.info/?l=linux-kernel\u0026m=120967963803205\u0026w=2"
},
{
"type": "WEB",
"url": "http://marc.info/?l=linux-kernel\u0026m=120967964303224\u0026w=2"
},
{
"type": "WEB",
"url": "http://secunia.com/advisories/30017"
},
{
"type": "WEB",
"url": "http://secunia.com/advisories/30018"
},
{
"type": "WEB",
"url": "http://secunia.com/advisories/30044"
},
{
"type": "WEB",
"url": "http://secunia.com/advisories/30108"
},
{
"type": "WEB",
"url": "http://secunia.com/advisories/30110"
},
{
"type": "WEB",
"url": "http://secunia.com/advisories/30112"
},
{
"type": "WEB",
"url": "http://secunia.com/advisories/30116"
},
{
"type": "WEB",
"url": "http://secunia.com/advisories/30260"
},
{
"type": "WEB",
"url": "http://secunia.com/advisories/30515"
},
{
"type": "WEB",
"url": "http://secunia.com/advisories/30769"
},
{
"type": "WEB",
"url": "http://secunia.com/advisories/30818"
},
{
"type": "WEB",
"url": "http://secunia.com/advisories/30890"
},
{
"type": "WEB",
"url": "http://secunia.com/advisories/30962"
},
{
"type": "WEB",
"url": "http://secunia.com/advisories/31246"
},
{
"type": "WEB",
"url": "http://wiki.rpath.com/Advisories:rPSA-2008-0157"
},
{
"type": "WEB",
"url": "http://wiki.rpath.com/wiki/Advisories:rPSA-2008-0157"
},
{
"type": "WEB",
"url": "http://www.debian.org/security/2008/dsa-1565"
},
{
"type": "WEB",
"url": "http://www.kernel.org/pub/linux/kernel/v2.4/ChangeLog-2.4.36.4"
},
{
"type": "WEB",
"url": "http://www.kernel.org/pub/linux/kernel/v2.6/ChangeLog-2.6.24.6"
},
{
"type": "WEB",
"url": "http://www.kernel.org/pub/linux/kernel/v2.6/ChangeLog-2.6.25.1"
},
{
"type": "WEB",
"url": "http://www.mandriva.com/security/advisories?name=MDVSA-2008:104"
},
{
"type": "WEB",
"url": "http://www.mandriva.com/security/advisories?name=MDVSA-2008:105"
},
{
"type": "WEB",
"url": "http://www.mandriva.com/security/advisories?name=MDVSA-2008:167"
},
{
"type": "WEB",
"url": "http://www.redhat.com/support/errata/RHSA-2008-0211.html"
},
{
"type": "WEB",
"url": "http://www.redhat.com/support/errata/RHSA-2008-0233.html"
},
{
"type": "WEB",
"url": "http://www.redhat.com/support/errata/RHSA-2008-0237.html"
},
{
"type": "WEB",
"url": "http://www.securityfocus.com/archive/1/491566/100/0/threaded"
},
{
"type": "WEB",
"url": "http://www.securityfocus.com/archive/1/491732/100/0/threaded"
},
{
"type": "WEB",
"url": "http://www.securityfocus.com/bid/29003"
},
{
"type": "WEB",
"url": "http://www.securitytracker.com/id?1019959"
},
{
"type": "WEB",
"url": "http://www.ubuntu.com/usn/usn-618-1"
},
{
"type": "WEB",
"url": "http://www.vupen.com/english/advisories/2008/1406/references"
},
{
"type": "WEB",
"url": "http://www.vupen.com/english/advisories/2008/1452/references"
},
{
"type": "WEB",
"url": "http://www.vupen.com/english/advisories/2008/2222/references"
}
],
"schema_version": "1.4.0",
"severity": []
}
GHSA-7MP4-25J8-HP5Q
Vulnerability from github – Published: 2026-03-11 00:13 – Updated: 2026-03-11 20:33Impact
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:
- Promotion usage limit - the global
usedcounter onPromotionentities - Coupon usage limit - the global
usedcounter onPromotionCouponentities - Coupon per-customer usage limit - the per-customer redemption count on
PromotionCouponentities
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:
- Open an issue in Sylius issues
- Email us at security@sylius.com
{
"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-7MP9-FP3J-G5HQ
Vulnerability from github – Published: 2026-01-13 18:31 – Updated: 2026-01-13 18:31Concurrent execution using shared resource with improper synchronization ('race condition') in Windows SMB Server allows an authorized attacker to elevate privileges over a network.
{
"affected": [],
"aliases": [
"CVE-2026-20934"
],
"database_specific": {
"cwe_ids": [
"CWE-362"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2026-01-13T18:16:20Z",
"severity": "HIGH"
},
"details": "Concurrent execution using shared resource with improper synchronization (\u0027race condition\u0027) in Windows SMB Server allows an authorized attacker to elevate privileges over a network.",
"id": "GHSA-7mp9-fp3j-g5hq",
"modified": "2026-01-13T18:31:10Z",
"published": "2026-01-13T18:31:10Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-20934"
},
{
"type": "WEB",
"url": "https://msrc.microsoft.com/update-guide/vulnerability/CVE-2026-20934"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:H/PR:L/UI:N/S:U/C:H/I:H/A:H",
"type": "CVSS_V3"
}
]
}
GHSA-7P3H-GFR2-RWCV
Vulnerability from github – Published: 2026-02-04 18:30 – Updated: 2026-07-14 15:31In the Linux kernel, the following vulnerability has been resolved:
scsi: core: Wake up the error handler when final completions race against each other
The fragile ordering between marking commands completed or failed so that the error handler only wakes when the last running command completes or times out has race conditions. These race conditions can cause the SCSI layer to fail to wake the error handler, leaving I/O through the SCSI host stuck as the error state cannot advance.
First, there is an memory ordering issue within scsi_dec_host_busy(). The write which clears SCMD_STATE_INFLIGHT may be reordered with reads counting in scsi_host_busy(). While the local CPU will see its own write, reordering can allow other CPUs in scsi_dec_host_busy() or scsi_eh_inc_host_failed() to see a raised busy count, causing no CPU to see a host busy equal to the host_failed count.
This race condition can be prevented with a memory barrier on the error path to force the write to be visible before counting host busy commands.
Second, there is a general ordering issue with scsi_eh_inc_host_failed(). By counting busy commands before incrementing host_failed, it can race with a final command in scsi_dec_host_busy(), such that scsi_dec_host_busy() does not see host_failed incremented but scsi_eh_inc_host_failed() counts busy commands before SCMD_STATE_INFLIGHT is cleared by scsi_dec_host_busy(), resulting in neither waking the error handler task.
This needs the call to scsi_host_busy() to be moved after host_failed is incremented to close the race condition.
{
"affected": [],
"aliases": [
"CVE-2026-23110"
],
"database_specific": {
"cwe_ids": [
"CWE-362"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2026-02-04T17:16:21Z",
"severity": "MODERATE"
},
"details": "In the Linux kernel, the following vulnerability has been resolved:\n\nscsi: core: Wake up the error handler when final completions race against each other\n\nThe fragile ordering between marking commands completed or failed so\nthat the error handler only wakes when the last running command\ncompletes or times out has race conditions. These race conditions can\ncause the SCSI layer to fail to wake the error handler, leaving I/O\nthrough the SCSI host stuck as the error state cannot advance.\n\nFirst, there is an memory ordering issue within scsi_dec_host_busy().\nThe write which clears SCMD_STATE_INFLIGHT may be reordered with reads\ncounting in scsi_host_busy(). While the local CPU will see its own\nwrite, reordering can allow other CPUs in scsi_dec_host_busy() or\nscsi_eh_inc_host_failed() to see a raised busy count, causing no CPU to\nsee a host busy equal to the host_failed count.\n\nThis race condition can be prevented with a memory barrier on the error\npath to force the write to be visible before counting host busy\ncommands.\n\nSecond, there is a general ordering issue with scsi_eh_inc_host_failed(). By\ncounting busy commands before incrementing host_failed, it can race with a\nfinal command in scsi_dec_host_busy(), such that scsi_dec_host_busy() does\nnot see host_failed incremented but scsi_eh_inc_host_failed() counts busy\ncommands before SCMD_STATE_INFLIGHT is cleared by scsi_dec_host_busy(),\nresulting in neither waking the error handler task.\n\nThis needs the call to scsi_host_busy() to be moved after host_failed is\nincremented to close the race condition.",
"id": "GHSA-7p3h-gfr2-rwcv",
"modified": "2026-07-14T15:31:39Z",
"published": "2026-02-04T18:30:44Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-23110"
},
{
"type": "WEB",
"url": "https://cert-portal.siemens.com/productcert/html/ssa-019113.html"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/219f009ebfd1ef3970888ee9eef4c8a06357f862"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/48cbc304c5ea796421f7d10b7798fa581970c080"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/64ae21b9c4f0c7e60cf47a53fa7ab68852079ef0"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/6d9a367be356101963c249ebf10ea10b32886607"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/9fdc6f28d5e81350ab1d2cac8389062bd09e61e1"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/cc872e35c0df80062abc71268d690a2f749e542e"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/fe2f8ad6f0999db3b318359a01ee0108c703a8c3"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:L/AC:H/PR:L/UI:N/S:U/C:N/I:N/A:H",
"type": "CVSS_V3"
}
]
}
GHSA-7P5M-XRH7-769R
Vulnerability from github – Published: 2026-03-16 16:43 – Updated: 2026-03-19 21:11Summary
Assumed repo path is /Users/zwique/Downloads/SandboxJS-0.8.34 (no /Users/zwique/Downloads/SandboxJS found). A global tick state (currentTicks.current) is shared between sandboxes. Timer string handlers are compiled at execution time using that global tick state rather than the scheduling sandbox's tick object. In multi-tenant / concurrent sandbox scenarios, another sandbox can overwrite currentTicks.current between scheduling and execution, causing the timer callback to run under a different sandbox's tick budget and bypass the original sandbox's execution quota/watchdog.
Impact: execution quota bypass → CPU/resource abuse
Details
- Affected project: SandboxJS (owner: nyariv)
- Assumed checked-out version:
SandboxJS-0.8.34at/Users/zwique/Downloads/SandboxJS-0.8.34
Vulnerable code paths
-
/src/eval.ts—sandboxFunctionbindsticksusingticks || currentTicks.current:createFunction(..., ticks || currentTicks.current, { ...context, ... })Relevant lines: 44, 53, 164, 167. -
/src/evaluator.ts//src/executor.ts— global ticks:export const currentTicks = { current: { ticks: BigInt(0) } as Ticks };and_execNoneRecurse(...) { currentTicks.current = ticks; ... }Relevant lines: ~1700, 1712. -
sandboxedSetTimeoutcompiles string handlers at execution time, not at scheduling time, which letscurrentTicks.currentbe the wrong sandbox's ticks when compilation occurs.
Why This Is Vulnerable
currentTicks.currentis global mutable state shared across all sandbox instances.- Timer string handlers are compiled at the moment the timer fires and read
currentTicks.currentat that time. If another sandbox runs between scheduling and execution, it can replacecurrentTicks.current. The scheduled timer's code will be compiled/executed with the other sandbox's tick budget. This allows the original sandbox's execution quota to be bypassed.
Proof of Concept
Run with Node.js; adjust path if needed.
// PoC (run with node); adjust path if needed
import Sandbox from '/Users/zwique/Downloads/SandboxJS-0.8.34/node_modules/@nyariv/sandboxjs/build/Sandbox.js';
const globals = { ...Sandbox.SAFE_GLOBALS, setTimeout, clearTimeout };
const prototypeWhitelist = Sandbox.SAFE_PROTOTYPES;
const sandboxA = new Sandbox({
globals,
prototypeWhitelist,
executionQuota: 50n,
haltOnSandboxError: true,
});
let haltedA = false;
sandboxA.subscribeHalt(() => { haltedA = true; });
const sandboxB = new Sandbox({ globals, prototypeWhitelist });
// Sandbox A schedules a heavy string handler
sandboxA.compile(
'setTimeout("let x=0; for (let i=0;i<200;i++){ x += i } globalThis.doneA = true;", 0);'
)().run();
// Run sandbox B before A's timer fires
sandboxB.compile('1+1')().run();
setTimeout(() => {
console.log({ haltedA, doneA: sandboxA.context.sandboxGlobal.doneA });
}, 50);
Reproduction Steps
-
Place the PoC in
hi.jsand run:node /Users/zwique/Downloads/SandboxJS-0.8.34/hi.js -
Observe output similar to:
{ haltedA: false, doneA: true }This indicates the heavy loop completed and the quota was bypassed. -
Remove the
sandboxB.compile('1+1')().run();line and rerun. Output should now be:{ haltedA: true }This indicates quota enforcement is working correctly.
Impact
- Type: Runtime guard bypass (execution-quota / watchdog bypass)
- Who is impacted: Applications that run multiple SandboxJS instances concurrently in the same process — multi-tenant interpreters, plugin engines, server-side scripting hosts, online code runners.
- Practical impact: Attackers controlling sandboxed code can bypass configured execution quotas/watchdog and perform CPU-intensive loops or long-running computation, enabling resource exhaustion/DoS or denial of service against the host process or other tenants.
- Does not (as tested) lead to: Host object exposure or direct sandbox escape (no
process/requireleakage observed from this primitive alone). Escalation to RCE was attempted and not observed.
{
"affected": [
{
"database_specific": {
"last_known_affected_version_range": "\u003c= 0.8.34"
},
"package": {
"ecosystem": "npm",
"name": "@nyariv/sandboxjs"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"fixed": "0.8.35"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [
"CVE-2026-32723"
],
"database_specific": {
"cwe_ids": [
"CWE-362"
],
"github_reviewed": true,
"github_reviewed_at": "2026-03-16T16:43:05Z",
"nvd_published_at": "2026-03-18T22:16:24Z",
"severity": "MODERATE"
},
"details": "## Summary\n\nAssumed repo path is `/Users/zwique/Downloads/SandboxJS-0.8.34` (no `/Users/zwique/Downloads/SandboxJS` found). A global tick state (`currentTicks.current`) is shared between sandboxes. Timer string handlers are compiled at execution time using that global tick state rather than the scheduling sandbox\u0027s tick object. In multi-tenant / concurrent sandbox scenarios, another sandbox can overwrite `currentTicks.current` between scheduling and execution, causing the timer callback to run under a different sandbox\u0027s tick budget and bypass the original sandbox\u0027s execution quota/watchdog.\n\n**Impact:** execution quota bypass \u2192 CPU/resource abuse \n\n---\n\n## Details\n\n- **Affected project:** SandboxJS (owner: nyariv)\n- **Assumed checked-out version:** `SandboxJS-0.8.34` at `/Users/zwique/Downloads/SandboxJS-0.8.34`\n\n### Vulnerable code paths\n\n- **`/src/eval.ts`** \u2014 `sandboxFunction` binds `ticks` using `ticks || currentTicks.current`:\n ```\n createFunction(..., ticks || currentTicks.current, { ...context, ... })\n ```\n Relevant lines: 44, 53, 164, 167.\n\n- **`/src/evaluator.ts` / `/src/executor.ts`** \u2014 global ticks:\n ```\n export const currentTicks = { current: { ticks: BigInt(0) } as Ticks };\n ```\n and\n ```\n _execNoneRecurse(...) { currentTicks.current = ticks; ... }\n ```\n Relevant lines: ~1700, 1712.\n\n- **`sandboxedSetTimeout`** compiles string handlers at execution time, not at scheduling time, which lets `currentTicks.current` be the wrong sandbox\u0027s ticks when compilation occurs.\n\n---\n\n## Why This Is Vulnerable\n\n- `currentTicks.current` is global mutable state shared across all sandbox instances.\n- Timer string handlers are compiled at the moment the timer fires and read `currentTicks.current` at that time. If another sandbox runs between scheduling and execution, it can replace `currentTicks.current`. The scheduled timer\u0027s code will be compiled/executed with the other sandbox\u0027s tick budget. This allows the original sandbox\u0027s execution quota to be bypassed.\n\n---\n\n## Proof of Concept\n\n\u003e Run with Node.js; adjust path if needed.\n\n```js\n// PoC (run with node); adjust path if needed\nimport Sandbox from \u0027/Users/zwique/Downloads/SandboxJS-0.8.34/node_modules/@nyariv/sandboxjs/build/Sandbox.js\u0027;\n\nconst globals = { ...Sandbox.SAFE_GLOBALS, setTimeout, clearTimeout };\nconst prototypeWhitelist = Sandbox.SAFE_PROTOTYPES;\n\nconst sandboxA = new Sandbox({\n globals,\n prototypeWhitelist,\n executionQuota: 50n,\n haltOnSandboxError: true,\n});\nlet haltedA = false;\nsandboxA.subscribeHalt(() =\u003e { haltedA = true; });\n\nconst sandboxB = new Sandbox({ globals, prototypeWhitelist });\n\n// Sandbox A schedules a heavy string handler\nsandboxA.compile(\n \u0027setTimeout(\"let x=0; for (let i=0;i\u003c200;i++){ x += i } globalThis.doneA = true;\", 0);\u0027\n)().run();\n\n// Run sandbox B before A\u0027s timer fires\nsandboxB.compile(\u00271+1\u0027)().run();\n\nsetTimeout(() =\u003e {\n console.log({ haltedA, doneA: sandboxA.context.sandboxGlobal.doneA });\n}, 50);\n```\n\n### Reproduction Steps\n\n1. Place the PoC in `hi.js` and run:\n ```\n node /Users/zwique/Downloads/SandboxJS-0.8.34/hi.js\n ```\n\n2. Observe output similar to:\n ```\n { haltedA: false, doneA: true }\n ```\n This indicates the heavy loop completed and the quota was bypassed.\n\n3. Remove the `sandboxB.compile(\u00271+1\u0027)().run();` line and rerun. Output should now be:\n ```\n { haltedA: true }\n ```\n This indicates quota enforcement is working correctly.\n\n---\n\n## Impact\n\n- **Type:** Runtime guard bypass (execution-quota / watchdog bypass)\n- **Who is impacted:** Applications that run multiple SandboxJS instances concurrently in the same process \u2014 multi-tenant interpreters, plugin engines, server-side scripting hosts, online code runners.\n- **Practical impact:** Attackers controlling sandboxed code can bypass configured execution quotas/watchdog and perform CPU-intensive loops or long-running computation, enabling resource exhaustion/DoS or denial of service against the host process or other tenants.\n- **Does not (as tested) lead to:** Host object exposure or direct sandbox escape (no `process` / `require` leakage observed from this primitive alone). Escalation to RCE was attempted and not observed.",
"id": "GHSA-7p5m-xrh7-769r",
"modified": "2026-03-19T21:11:10Z",
"published": "2026-03-16T16:43:05Z",
"references": [
{
"type": "WEB",
"url": "https://github.com/nyariv/SandboxJS/security/advisories/GHSA-7p5m-xrh7-769r"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-32723"
},
{
"type": "WEB",
"url": "https://github.com/nyariv/SandboxJS/commit/cc8f20b4928afed5478d5ad3d1737ef2dcfaac29"
},
{
"type": "PACKAGE",
"url": "https://github.com/nyariv/SandboxJS"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:4.0/AV:L/AC:L/AT:N/PR:L/UI:N/VC:N/VI:N/VA:L/SC:N/SI:N/SA:N",
"type": "CVSS_V4"
}
],
"summary": "SandboxJS has an execution-quota bypass (cross-sandbox currentTicks race) in SandboxJS timers"
}
GHSA-7P63-W6X9-6GR7
Vulnerability from github – Published: 2025-11-18 18:32 – Updated: 2026-02-05 15:43In Eclipse Jersey versions 2.45, 3.0.16, 3.1.9 a race condition can cause ignoring of critical SSL configurations - such as mutual authentication, custom key/trust stores, and other security settings. This issue may result in SSLHandshakeException under normal circumstances, but under certain conditions, it could lead to unauthorized trust in insecure servers (see PoC)
{
"affected": [
{
"package": {
"ecosystem": "Maven",
"name": "org.glassfish.jersey.core:jersey-client"
},
"ranges": [
{
"events": [
{
"introduced": "2.45"
},
{
"fixed": "2.46"
}
],
"type": "ECOSYSTEM"
}
],
"versions": [
"2.45"
]
},
{
"package": {
"ecosystem": "Maven",
"name": "org.glassfish.jersey.core:jersey-client"
},
"ranges": [
{
"events": [
{
"introduced": "3.0.16"
},
{
"fixed": "3.0.17"
}
],
"type": "ECOSYSTEM"
}
],
"versions": [
"3.0.16"
]
},
{
"package": {
"ecosystem": "Maven",
"name": "org.glassfish.jersey.core:jersey-client"
},
"ranges": [
{
"events": [
{
"introduced": "3.1.9"
},
{
"fixed": "3.1.10"
}
],
"type": "ECOSYSTEM"
}
],
"versions": [
"3.1.9"
]
}
],
"aliases": [
"CVE-2025-12383"
],
"database_specific": {
"cwe_ids": [
"CWE-296",
"CWE-362"
],
"github_reviewed": true,
"github_reviewed_at": "2025-11-18T20:38:31Z",
"nvd_published_at": "2025-11-18T16:15:42Z",
"severity": "CRITICAL"
},
"details": "In Eclipse Jersey versions 2.45, 3.0.16, 3.1.9 a race condition can cause ignoring of critical SSL configurations - such as mutual authentication, custom key/trust stores, and other security settings. This issue may result in SSLHandshakeException under normal circumstances, but under certain conditions, it could lead to unauthorized trust in insecure servers (see PoC)",
"id": "GHSA-7p63-w6x9-6gr7",
"modified": "2026-02-05T15:43:36Z",
"published": "2025-11-18T18:32:51Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-12383"
},
{
"type": "WEB",
"url": "https://github.com/eclipse-ee4j/jersey/pull/5749"
},
{
"type": "WEB",
"url": "https://github.com/eclipse-ee4j/jersey/pull/5794"
},
{
"type": "WEB",
"url": "https://github.com/eclipse-ee4j/jersey/commit/425bc883d8d623ef8d3c448fafd36729f7741bcb"
},
{
"type": "WEB",
"url": "https://github.com/eclipse-ee4j/jersey/commit/b2c7ba6d388cb9722f39073d7e82aa818fec49d5"
},
{
"type": "WEB",
"url": "https://github.com/dtbaum/jerseyCveCandidate"
},
{
"type": "PACKAGE",
"url": "https://github.com/eclipse-ee4j/jersey"
},
{
"type": "WEB",
"url": "https://github.com/eclipse-ee4j/jersey/releases/tag/2.46"
},
{
"type": "WEB",
"url": "https://github.com/eclipse-ee4j/jersey/releases/tag/3.0.17"
},
{
"type": "WEB",
"url": "https://github.com/eclipse-ee4j/jersey/releases/tag/3.1.10"
},
{
"type": "WEB",
"url": "https://github.com/eclipse-ee4j/jersey/releases/tag/4.0.0-M2"
},
{
"type": "WEB",
"url": "https://gitlab.eclipse.org/security/cve-assignment/-/issues/74"
},
{
"type": "WEB",
"url": "https://gitlab.eclipse.org/security/vulnerability-reports/-/issues/253"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:4.0/AV:N/AC:H/AT:P/PR:N/UI:N/VC:H/VI:H/VA:N/SC:H/SI:H/SA:N",
"type": "CVSS_V4"
}
],
"summary": "Eclipse Jersey has a Race Condition"
}
GHSA-7P72-HG7M-3627
Vulnerability from github – Published: 2026-03-25 15:31 – Updated: 2026-03-25 18:31In N2WS Backup & Recovery before 4.4.0, a two-step attack against the RESTful API results in remote code execution.
{
"affected": [],
"aliases": [
"CVE-2025-32991"
],
"database_specific": {
"cwe_ids": [
"CWE-362"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2026-03-25T15:16:28Z",
"severity": "CRITICAL"
},
"details": "In N2WS Backup \u0026 Recovery before 4.4.0, a two-step attack against the RESTful API results in remote code execution.",
"id": "GHSA-7p72-hg7m-3627",
"modified": "2026-03-25T18:31:46Z",
"published": "2026-03-25T15:31:29Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-32991"
},
{
"type": "WEB",
"url": "https://n2ws.com/blog/security-advisory-update"
},
{
"type": "WEB",
"url": "https://www.n2ws.com"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:C/C:H/I:H/A:H",
"type": "CVSS_V3"
}
]
}
Mitigation
In languages that support it, use synchronization primitives. Only wrap these around critical code to minimize the impact on performance.
Mitigation
Use thread-safe capabilities such as the data access abstraction in Spring.
Mitigation
- Minimize the usage of shared resources in order to remove as much complexity as possible from the control flow and to reduce the likelihood of unexpected conditions occurring.
- Additionally, this will minimize the amount of synchronization necessary and may even help to reduce the likelihood of a denial of service where an attacker may be able to repeatedly trigger a critical section (CWE-400).
Mitigation
When using multithreading and operating on shared variables, only use thread-safe functions.
Mitigation
Use atomic operations on shared variables. Be wary of innocent-looking constructs such as "x++". This may appear atomic at the code layer, but it is actually non-atomic at the instruction layer, since it involves a read, followed by a computation, followed by a write.
Mitigation
Use a mutex if available, but be sure to avoid related weaknesses such as CWE-412.
Mitigation
Avoid double-checked locking (CWE-609) and other implementation errors that arise when trying to avoid the overhead of synchronization.
Mitigation
Disable interrupts or signals over critical parts of the code, but also make sure that the code does not go into a large or infinite loop.
Mitigation
Use the volatile type modifier for critical variables to avoid unexpected compiler optimization or reordering. This does not necessarily solve the synchronization problem, but it can help.
Mitigation MIT-17
Strategy: Environment Hardening
Run your code using the lowest privileges that are required to accomplish the necessary tasks [REF-76]. If possible, create isolated accounts with limited privileges that are only used for a single task. That way, a successful attack will not immediately give the attacker access to the rest of the software or its environment. For example, database applications rarely need to run as the database administrator, especially in day-to-day operations.
CAPEC-26: Leveraging Race Conditions
The adversary targets a race condition occurring when multiple processes access and manipulate the same resource concurrently, and the outcome of the execution depends on the particular order in which the access takes place. The adversary can leverage a race condition by "running the race", modifying the resource and modifying the normal execution flow. For instance, a race condition can occur while accessing a file: the adversary can trick the system by replacing the original file with their version and cause the system to read the malicious 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.