Suivez en temps réel les dernières failles de sécurité (CVE) identifiées mondialement. Données fournies par le National Vulnerability Database (NVD).
Ces informations proviennent directement du National Vulnerability Database (NVD).
DASEC GROUP vous accompagne dans la remédiation de ces failles.
Race condition in FileAPI in Google Chrome prior to 153.0.8010.36 allowed a remote attacker who had compromised the renderer process to bypass site isolation via a crafted HTML page. (Chromium security severity: Medium)
Incorrect authorization in Navigation in Google Chrome prior to 153.0.8010.36 allowed a remote attacker who had compromised the renderer process to spoof UI elements via a crafted HTML page. (Chromium security severity: Medium)
Missing authorization in Extensions in Google Chrome prior to 153.0.8010.36 allowed a remote attacker to obtain sensitive information via a crafted Chrome extension. (Chromium security severity: Medium)
Buffer overflow in WebRTC in Google Chrome prior to 153.0.8010.36 allowed a remote attacker to potentially execute arbitrary code inside the sandbox via a crafted HTML page. (Chromium security severity: Low)
Missing authorization in ServiceWorker in Google Chrome prior to 153.0.8010.36 allowed a remote attacker who had compromised the renderer process to bypass system access restrictions via a crafted HTML page. (Chromium security severity: Low)
OpenIDC/cjose is a C library implementing the Javascript Object Signing and Encryption (JOSE). In versions 0.6.1 through 0.6.2.5, when cjose encrypts a JWE using an AES-CBC-HMAC content-encryption algorithm (`A128CBC-HS256`, `A192CBC-HS384`, or `A256CBC-HS512`) together with any key-management algorithm that generates a fresh content-encryption key (CEK), the CEK is all zero bytes instead of being randomly generated. The resulting JWE is therefore encrypted and authenticated under a fixed, publicly known key, so anyone who obtains the JWE can recover the plaintext and forge or modify the content. This is fixed in version 0.6.2.6 by `_cjose_jwe_set_cek_aes_cbc()` generating the CEK from `RAND_bytes`. A regression test asserts that the `encrypted_key` differs across two encryptions for each AES-CBC-HMAC variant. Until upgrading, for data encrypted with cjose, three options are available. Use an AES-GCM `enc` (`A128GCM` / `A192GCM` / `A256GCM`) instead of an AES-CBC-HMAC `enc`, use `alg=dir` with a caller-supplied CEK, or avoid using cjose for JWE encryption with the affected algorithm pair. These are mitigations for new ciphertexts only; data already encrypted under the zero key remains compromised and should be re-encrypted (and any secrets it contained rotated).
OpenIDC/cjose is a C library implementing the Javascript Object Signing and Encryption (JOSE). Prior to version 0.6.2.5, cjose's JWE decryption path for the AES Key Wrap key-management algorithms (`alg` = `A128KW`, `A192KW`, `A256KW`) does not validate the length of the attacker-supplied `encrypted_key` (JWE Encrypted Key) before unwrapping it into a fixed-size, heap-allocated Content Encryption Key (CEK) buffer. A remote, unauthenticated attacker who can submit a crafted JWE to an application that decrypts it with an AES-KW symmetric key can trigger an out-of-bounds heap write, corrupting the heap. This leads at minimum to a crash (denial of service) and, depending on the heap layout and allocator, may be leverageable for further memory-corruption impact. `cjose_jwe_import()` / `cjose_jwe_decrypt()` are pre-authentication entry points: they parse and process fully attacker-controlled input. Upgrade to cjose 0.6.2.5 to receive a patch. If upgrading is not immediately possible, reject the AES Key Wrap algorithms (`A128KW`/`A192KW`/`A256KW`) for untrusted JWEs at the application layer.
MCP Kotlin SDK is the Kotlin Multiplatform software development kit for the Model Context Protocol. In versions 0.7.0 through 0.12.0, `ReadBuffer.append` in `kotlin-sdk-core/src/commonMain/kotlin/io/modelcontextprotocol/kotlin/sdk/shared/ReadBuffer.kt` writes every chunk of bytes received from the stdio transport into a `kotlinx.io.Buffer` with no size cap. Frames are extracted from that buffer only when a `\n` (0x0a) byte is observed. A peer that streams bytes without ever sending a newline causes the internal buffer to grow indefinitely until the JVM (or the surrounding host process) is OOM-killed. The leak is amplified by `StdioServerTransport` and `StdioClientTransport`, which both queue raw chunks through a `kotlinx.coroutines.channels.Channel<ByteArray>(Channel.UNLIMITED)` and then call `readBuffer.append(chunk)` without backpressure or size guard. This is a remote-pre-auth denial of service whenever an SDK stdio server's stdin is fed by an untrusted or attacker-controlled producer (for example: a host program that exec's the MCP server as a subprocess and pipes through bytes received from a network peer, or a sidecar wrapper that proxies bytes from an HTTP endpoint to the stdio transport). Version 0.13.0 fixes the issue.
An uncontrolled recursion vulnerability in the Windows SIPA event log parser of Google go-attestation versions up to and including 0.6.1 allows an attacker to cause a denial of service (DoS). The (*WinEvents).readELAMAggregation function recurses for every nested elamAggregation sub-event without enforcing a maximum recursion depth limit, while the size guard is bypassed on recursive execution paths. By submitting a crafted Windows event log containing deeply nested elamAggregation headers, an attacker can exhaust the goroutine call stack, triggering an unrecoverable fatal runtime error (stack overflow) that immediately crashes the verifier application.
A flaw was found in DPDK lib/vhost. Missing length validation before reading command_data in the virtio-net control-queue handler can cause an out-of-bounds read and a host process crash.
Maravel, a PHP framework oriented towards dependency injection, prior to version 10.74.0 has a high-severity Token Replay Vulnerability arising from a structural lifecycle mismatch between stateless token validation engines and high-performance relational caching layers. Any application with low cache memory that causes premature eviction to free up memory and applications running macropay-solutions/maravel-framework that utilize tymon/jwt-auth for API token authentication and blacklist management or any other package that does the same may be affected. This architectural risk might also impact native Laravel applications utilizing cache tags under specific volatile or eviction-capped environments. tymon/jwt-auth automatically probes for cache tag support. If found, it forcefully wraps 14-day token blacklist entries (jti) inside a relational tymon.jwt tag. In environments where the O(1) Atomic Lazy Eviction model is active — either natively inside Maravel-Framework v20.x or manually backported into v10.x via the explicit DI container singletons provided in PR #104 (App\Cache\TaggedCache and App\Cache\TagSet) — a strict global tracking ceiling (Container::TAGGED_CACHE_TTL_CAP_SECONDS) of 7,200 seconds (2 hours) is enforced to secure the system against memory index bloat. This ceiling forcefully truncates the 14-day blacklist lifespan down to a maximum of 2 hours, after which individual tracking keys naturally expire and disappear from the active cache window. Furthermore, because the optimized engine implements a generational version matrix to achieve O(1) flush speeds, any programmatic or manual invocation of a tag flush or reset (e.g., Cache::tags([...])->flush()) instantly bumps the internal atomic master version pointer. This shifts the computed cryptographic composite hash (sha1($this->tags->getNamespace())) for all overlapping components, rendering the entire existing index immediately unreachable. Consequently, through either natural 2-hour expiration or an intervening tag flush execution (like the cache naturally cleaning old values to free up memory), the invalidation state records are entirely wiped out. Because the tokens' physical cryptographic signatures remain structurally valid for up to 14 days, stolen, hijacked, or legitimately logged-out tokens are instantly and silently resurrected across the entire API gateway, leaving the application critically vulnerable to widespread Token Replay Attacks. Because this issue is caused by an upstream architectural assumption within the tymon/jwt-auth package rather than a core defect inside the framework, there is no direct framework version upgrade that can safely bypass this lifecycle collision without breaking business cache recycling bounds. Maravel version 10.74.0 introduced a way to backport the new fixed tagged cache from 20.x into 10.x by resolving TagSet and TaggedCache from DI, which is how this latent architectural lifecycle vulnerability was discovered. Users must apply the decoupled configuration workaround outlined below. As a workaround, make sure that cache memory size does not generate early natural evictions from cache to free up space, deleting blacklisted jwt ids before they expire. Applications must decouple flat authentication vectors from the relational tagging subsystem. This forces token identifiers to write directly to the primary cache keyspace as flat, un-tagged key-value pairs where they securely retain their unclipped 14-day lifecycle.
Sylius is an Open Source eCommerce Framework on Symfony. Starting in version 2.0.0 and prior to version 2.0.18, 2.1.15, and 2.2.6, the `GET /api/v2/shop/payment-requests/{hash}` and `PUT /api/v2/shop/payment-requests/{hash}` endpoints look up the payment request solely by the hash from the URL. No ownership check is performed against the authenticated customer or the underlying order. An attacker who obtains a payment request hash can read the payment request and, through the `payment` IRI in the response, recover the underlying order's `tokenValue` (which itself grants access to the full order, items, addresses, customer email, totals); and/or update the payment request payload (e.g. `target_path`, `after_path`). These fields are used by the front-end controller to redirect the user after the payment, so an attacker can flip them to an attacker-controlled URL and intercept the buyer. The hash is a UUID, so it has to be obtained out-of-band (logs, shared links, referrer headers, a co-located client), but once it is known no other credential is required, neither authentication nor knowledge of the order token. The creation endpoint `POST /api/v2/shop/orders/{tokenValue}/payment-requests` shares the same flaw: it resolves the target order solely from the `tokenValue` in the URL without verifying that the caller owns the order. The issue is fixed in versions 2.0.18, 2.1.15, and 2.2.6. As a workaround, add a query extension that filters the `GET` operation; decorate the `PUT` state provider, guard the `POST` creation endpoint with a command-bus middleware, and wire the services.
Sylius is an Open Source eCommerce Framework on Symfony. Starting in version 2.0.0 and prior to version 2.0.18, 2.1.15, and 2.2.6, an authorization bypass vulnerability exists in the shop account API. The `PATCH /api/v2/shop/account/orders/{tokenValue}/payments/{paymentId}` endpoint, used by an authenticated shop customer to change the payment method of an order that has been placed but not yet paid (state `STATE_NEW`), does not validate that the chosen payment method is enabled for the order's channel. The equivalent checkout endpoint (`PATCH /api/v2/shop/orders/{tokenValue}/payments/{paymentId}`) correctly rejects out-of-channel payment methods with `HTTP 422`; the account endpoint silently accepts them and returns `HTTP 200`. An authenticated customer can therefore assign any globally enabled payment method to their own placed order, including methods that the store operator has explicitly excluded from that channel. The issue is fixed in versions: 2.0.18, 2.1.15, 2.2.6 and above. As a workaround, decorate the `Sylius\Bundle\ApiBundle\Changer\PaymentMethodChangerInterface` service in the application.
Sylius is an Open Source eCommerce Framework on Symfony. Versions 2.0.0 through 2.0.17, 2.1.0 through 2.1.14, and 2.2.0 through 2.2.5 contain an improper workflow enforcement vulnerability in the cart `FormComponent`. When an order is completed while its cart page remains open, the stale LiveComponent does not detect the order’s changed state and continues to permit cart actions, allowing an authenticated customer to modify or permanently delete an already completed order. Versions 2.0.18, 2.1.15, and 2.2.6 contain a patch. As a workaround, deployments can copy the patched `FormComponent` into the application's `src/` directory and override the `sylius_shop.twig.component.cart.form` service definition to use that class.
OPNsense is a FreeBSD based firewall and routing platform. Prior to version 26.1.9 of opnsense/core and version 26.4_20 of BE/opnsense/core, a path traversal vulnerability in the NTP configuration module allows an attacker to overwrite arbitrary files on the system as the root user. By manipulating the GPS or PPS serial port parameter, an attacker with access to the NTP configuration can escape the intended directory and force the system to write user-controlled data to any file on the filesystem. Version 26.1.9 of opnsense/core and version 26.4_20 of BE/opnsense/core patch the issue.
