π¨ CVE-2026-84388
A improper restriction of rendered ui layers or frames vulnerability in Fortinet FortiPAM Chrome Extension 8.0 all versions, FortiPAM Chrome Extension 7.4 all versions may allow attacker to information disclosure via remote unauthenticated attack
π@cveNotify
A improper restriction of rendered ui layers or frames vulnerability in Fortinet FortiPAM Chrome Extension 8.0 all versions, FortiPAM Chrome Extension 7.4 all versions may allow attacker to information disclosure via remote unauthenticated attack
π@cveNotify
π¨ CVE-2026-100701
Nodemailer versions 5.0.0 through 10.0.1 use a process-global DNS cache that is keyed only by the DNS host, while each cache entry also stores the caller-specific TLS servername. When two direct TLS/SMTPS transports (secure: true) resolve the same non-IP host with different tls.servername values, the first transport's servername is returned on the cache hit and overwrites the second transport's explicitly configured value, so Nodemailer sends the wrong SNI value and validates the peer certificate against the wrong identity. In multi-tenant services or SNI-routed SMTP gateways, an attacker who can prime the cache can cause a victim transport to connect to the attacker's TLS virtual host and accept the attacker's certificate even with rejectUnauthorized: true, disclosing the victim's SMTP credentials. Fixed in 10.0.2.
π@cveNotify
Nodemailer versions 5.0.0 through 10.0.1 use a process-global DNS cache that is keyed only by the DNS host, while each cache entry also stores the caller-specific TLS servername. When two direct TLS/SMTPS transports (secure: true) resolve the same non-IP host with different tls.servername values, the first transport's servername is returned on the cache hit and overwrites the second transport's explicitly configured value, so Nodemailer sends the wrong SNI value and validates the peer certificate against the wrong identity. In multi-tenant services or SNI-routed SMTP gateways, an attacker who can prime the cache can cause a victim transport to connect to the attacker's TLS virtual host and accept the attacker's certificate even with rejectUnauthorized: true, disclosing the victim's SMTP credentials. Fixed in 10.0.2.
π@cveNotify
GitHub
Process-global DNS cache reuses TLS `servername` across transports, enabling cross-tenant SMTP credential disclosure
### Summary
Nodemailer's process-global DNS cache is keyed only by `host`, but each cache entry also stores the caller-specific TLS `servername`. When two direct SMTPS transports use the sam...
Nodemailer's process-global DNS cache is keyed only by `host`, but each cache entry also stores the caller-specific TLS `servername`. When two direct SMTPS transports use the sam...
π¨ CVE-2026-100702
Nodemailer before 10.0.2 fails to properly flatten deeply nested arrays in recipient fields such as to, cc, and bcc, allowing attackers to cause stack exhaustion. Attackers can supply a deeply nested JSON recipient array that triggers recursive Array.toString() conversion, exhausting the call stack and terminating the Node.js process.
π@cveNotify
Nodemailer before 10.0.2 fails to properly flatten deeply nested arrays in recipient fields such as to, cc, and bcc, allowing attackers to cause stack exhaustion. Attackers can supply a deeply nested JSON recipient array that triggers recursive Array.toString() conversion, exhausting the call stack and terminating the Node.js process.
π@cveNotify
GitHub
Nested structured recipient arrays bypass the parser depth limit and cause stack exhaustion DoS
# Nodemailer: deeply nested recipient arrays cause stack exhaustion denial of service
## Submission metadata
| Field | Value |
|---|---|
| Ecosystem | npm |
| Package | `nodemailer` |
| R...
## Submission metadata
| Field | Value |
|---|---|
| Ecosystem | npm |
| Package | `nodemailer` |
| R...
π¨ CVE-2026-85542
IBM Guardium Data Protection 12.2 is affected by a command injection vulnerability in the GIM bundle import functionality. An authenticated attacker can provide a crafted GIM bundle that causes attacker-controlled arguments to be passed to the tar command, resulting in arbitrary command execution with elevated privileges on the Central Manager.
π@cveNotify
IBM Guardium Data Protection 12.2 is affected by a command injection vulnerability in the GIM bundle import functionality. An authenticated attacker can provide a crafted GIM bundle that causes attacker-controlled arguments to be passed to the tar command, resulting in arbitrary command execution with elevated privileges on the Central Manager.
π@cveNotify
Ibm
Security Bulletin: IBM Guardium Data Protection is affected by multiple vulnerabilities.
IBM Guardium Data Protection has addressed these vulnerabilities in an update.
π¨ CVE-2026-100740
A vulnerability was detected in D-Link DIR-895L A1_102b07. Impacted is the function tunnel_set_params of the file tunnel.c of the component L2TP Control Channel Parser. Performing a manipulation results in out-of-bounds write. The attack may be initiated remotely. The exploit is now public and may be used.
π@cveNotify
A vulnerability was detected in D-Link DIR-895L A1_102b07. Impacted is the function tunnel_set_params of the file tunnel.c of the component L2TP Control Channel Parser. Performing a manipulation results in out-of-bounds write. The attack may be initiated remotely. The exploit is now public and may be used.
π@cveNotify
tzh00203 on Notion
D-Link DIR-895L L2TP Host Name AVP Out-of-Bounds Write | Notion
Vulnerability Title: Out-of-Bounds Write in L2TP / L2TPv6 Host Name AVP Parsing of D-Link DIR-895L
π¨ CVE-2025-71422
Contrast is a Kubernetes runtime for confidential containers. In versions before 1.12.1, the secure persistent volume feature is vulnerable to a malicious host supplying a crafted LUKS2 volume to a pod VM. LUKS2 volume metadata is not authenticated and, with cryptsetup versions prior to 2.8.1, a header specifying the null keyslot encryption algorithm (cipher_null-ecb) is accepted without error. Because the Contrast Initializer assumes a device is protected if `cryptsetup open` succeeds with the secret seed, the guest will open the attacker-supplied volume and write secret data in plaintext, or under a volume key known to the attacker, allowing the host to read confidential data that should have been encrypted. Contrast v1.12.1 ships cryptsetup 2.8.1, which disables null ciphers in keyslots when the passphrase is non-empty; v1.13.0 adds detached-header validation in guest memory and integrity protection for secure persistent storage. Contrast persistent volumes were not integrity protected, so integrity impact is not considered.
π@cveNotify
Contrast is a Kubernetes runtime for confidential containers. In versions before 1.12.1, the secure persistent volume feature is vulnerable to a malicious host supplying a crafted LUKS2 volume to a pod VM. LUKS2 volume metadata is not authenticated and, with cryptsetup versions prior to 2.8.1, a header specifying the null keyslot encryption algorithm (cipher_null-ecb) is accepted without error. Because the Contrast Initializer assumes a device is protected if `cryptsetup open` succeeds with the secret seed, the guest will open the attacker-supplied volume and write secret data in plaintext, or under a volume key known to the attacker, allowing the host to read confidential data that should have been encrypted. Contrast v1.12.1 ships cryptsetup 2.8.1, which disables null ciphers in keyslots when the passphrase is non-empty; v1.13.0 adds detached-header validation in guest memory and integrity protection for secure persistent storage. Contrast persistent volumes were not integrity protected, so integrity impact is not considered.
π@cveNotify
GitHub
Insecure LUKS2 persistent storage partitions may be opened and used
### Summary
A malicious host may provide a crafted LUKS2 volume to a Contrast pod VM that uses the [secure persistent volume](https://docs.edgeless.systems/contrast/howto/encrypted-storage) feat...
A malicious host may provide a crafted LUKS2 volume to a Contrast pod VM that uses the [secure persistent volume](https://docs.edgeless.systems/contrast/howto/encrypted-storage) feat...
π¨ CVE-2025-71423
Edgelesssys Contrast is a confidential-computing runtime for Kubernetes. In versions 1.9.0 before 1.12.2, the initializer logs the full NewMeshCert response β which contains the workload secret β to standard output at INFO level. As a result, workload secrets are exposed to any Kubernetes user with get or list permission on pods/logs. Because workload secrets are used for encrypted storage and Vault integration, those must also be considered compromised. This is a regression of GHSA-h5f8-crrq-4pw8.
π@cveNotify
Edgelesssys Contrast is a confidential-computing runtime for Kubernetes. In versions 1.9.0 before 1.12.2, the initializer logs the full NewMeshCert response β which contains the workload secret β to standard output at INFO level. As a result, workload secrets are exposed to any Kubernetes user with get or list permission on pods/logs. Because workload secrets are used for encrypted storage and Vault integration, those must also be considered compromised. This is a regression of GHSA-h5f8-crrq-4pw8.
π@cveNotify
GitHub
initializer: don't log NewMeshCert response Β· edgelesssys/contrast@5a5512c
Deploy and manage confidential containers on Kubernetes - initializer: don't log NewMeshCert response Β· edgelesssys/contrast@5a5512c
π¨ CVE-2025-71424
Contrast, Edgeless Systems' runtime for confidential containers on Kubernetes, is affected in versions up to and including 1.9.0. The VOLUME directive in a Dockerfile (config.volumes in the OCI image configuration) is only a hint and is not handled specially by Kubernetes, but containerd adds a mount point for it when Kubernetes sets none, requiring the runtime to be able to push arbitrary data to the Kata agent. As a result, on bare-metal Contrast deployments (AKS deployments are not affected) that run an image declaring at least one VOLUME for which no Kubernetes mount exists at that path, the untrusted host can write arbitrary file trees below that mount point inside the confidential container, compromising the integrity of a directory that is typically important to the application's core functionality. Version 1.9.1 fixes the issue by disallowing this configuration in `contrast generate`.
π@cveNotify
Contrast, Edgeless Systems' runtime for confidential containers on Kubernetes, is affected in versions up to and including 1.9.0. The VOLUME directive in a Dockerfile (config.volumes in the OCI image configuration) is only a hint and is not handled specially by Kubernetes, but containerd adds a mount point for it when Kubernetes sets none, requiring the runtime to be able to push arbitrary data to the Kata agent. As a result, on bare-metal Contrast deployments (AKS deployments are not affected) that run an image declaring at least one VOLUME for which no Kubernetes mount exists at that path, the untrusted host can write arbitrary file trees below that mount point inside the confidential container, compromising the integrity of a directory that is typically important to the application's core functionality. Version 1.9.1 fixes the issue by disallowing this configuration in `contrast generate`.
π@cveNotify
GitHub
VOLUME directives without explicit mounts writable by host
### Background
The [`VOLUME`](https://docs.docker.com/reference/dockerfile/#volume) directive in Dockerfiles, or the [`config.volumes`](https://github.com/opencontainers/image-spec/blob/06e6b47e...
The [`VOLUME`](https://docs.docker.com/reference/dockerfile/#volume) directive in Dockerfiles, or the [`config.volumes`](https://github.com/opencontainers/image-spec/blob/06e6b47e...
π¨ CVE-2025-71425
Contrast (Edgeless Systems) before 1.8.1 logs the workload secret to stderr, and thus to Kubernetes logs, when the Contrast initializer is configured with CONTRAST_LOG_LEVEL set to info or debug. Because info is the default, all installations that do not customize the initializer log level are affected. This exposes workload secrets β normally accessible only to the Contrast Coordinator, the initializer, the seedshare owner, and the workload owner β to Kubernetes users with get or list permission on pods/logs and to anyone with read access to the Kubernetes log storage, such as the cloud provider. Deployments that do not use workload secrets are unaffected.
π@cveNotify
Contrast (Edgeless Systems) before 1.8.1 logs the workload secret to stderr, and thus to Kubernetes logs, when the Contrast initializer is configured with CONTRAST_LOG_LEVEL set to info or debug. Because info is the default, all installations that do not customize the initializer log level are affected. This exposes workload secrets β normally accessible only to the Contrast Coordinator, the initializer, the seedshare owner, and the workload owner β to Kubernetes users with get or list permission on pods/logs and to anyone with read access to the Kubernetes log storage, such as the cloud provider. Deployments that do not use workload secrets are unaffected.
π@cveNotify
GitHub
Workload secrets leak to logs on INFO level
### Impact
When the Contrast initializer is configured with a `CONTRAST_LOG_LEVEL` of `info` or `debug`, the workload secret is logged to `stderr` and written to Kubernetes logs.
Since `info...
When the Contrast initializer is configured with a `CONTRAST_LOG_LEVEL` of `info` or `debug`, the workload secret is logged to `stderr` and written to Kubernetes logs.
Since `info...
π¨ CVE-2025-71426
Contrast is a confidential-computing runtime for Kubernetes. In versions before 1.4.1, a recovering Coordinator does not verify the seed supplied by the recovering party. An attacker can therefore stand up a rogue Coordinator whose manifest passes validation but whose secret seed is attacker-controlled. If network traffic is redirected from the legitimate Coordinator to the attacker's Coordinator, a workload owner can be impersonated when they either set a new manifest without comparing the returned root CA certificate against the existing one (the default behavior of the contrast CLI) or verify the Coordinator without comparing the root CA certificate against a trusted reference. Under these conditions the attacker can issue certificates that chain back to the rogue Coordinator's root CA and recover arbitrary workload secrets of workloads deployed after the attack. Secrets of the legitimate Coordinator (seed, workload secrets, CA), workload integrity, and certificates chaining to the mesh CA are not affected.
π@cveNotify
Contrast is a confidential-computing runtime for Kubernetes. In versions before 1.4.1, a recovering Coordinator does not verify the seed supplied by the recovering party. An attacker can therefore stand up a rogue Coordinator whose manifest passes validation but whose secret seed is attacker-controlled. If network traffic is redirected from the legitimate Coordinator to the attacker's Coordinator, a workload owner can be impersonated when they either set a new manifest without comparing the returned root CA certificate against the existing one (the default behavior of the contrast CLI) or verify the Coordinator without comparing the root CA certificate against a trusted reference. Under these conditions the attacker can issue certificates that chain back to the rogue Coordinator's root CA and recover arbitrary workload secrets of workloads deployed after the attack. Secrets of the legitimate Coordinator (seed, workload secrets, CA), workload integrity, and certificates chaining to the mesh CA are not affected.
π@cveNotify
GitHub
Unauthenticated recovery allows Coordinator impersonation
### Impact
Recovering coordinators do not verify the seed provided by the recovering party. This allows an attacker to set up a coordinator with a manifest that passes validation, but with a sec...
Recovering coordinators do not verify the seed provided by the recovering party. This allows an attacker to set up a coordinator with a manifest that passes validation, but with a sec...
π¨ CVE-2026-100721
vm2 before 3.12.2 contains an authorization bypass in the NodeVM external-module resolver. When an embedder configures `require.external` with a custom resolver (and `context: 'host'`), `LegacyResolver.customResolve` in lib/resolver-compat.js records the resolved module directory in `this.externals` as `new RegExp('^' + escapeRegExp(resolvedPath))`, without requiring a path separator or end-of-string boundary. Untrusted guest code can therefore require the allowlisted module (e.g. `foo`) and then require the absolute path of a non-allowlisted sibling whose path merely shares the resolved prefix (e.g. `.../node_modules/foo2/index.js`); the sibling passes `isPathAllowedForModule` and is loaded through `hostRequire`, so its top-level code runs in the host process before the exports are wrapped with `vm.readonly`, resulting in a sandbox escape and arbitrary code execution in the host context.
π@cveNotify
vm2 before 3.12.2 contains an authorization bypass in the NodeVM external-module resolver. When an embedder configures `require.external` with a custom resolver (and `context: 'host'`), `LegacyResolver.customResolve` in lib/resolver-compat.js records the resolved module directory in `this.externals` as `new RegExp('^' + escapeRegExp(resolvedPath))`, without requiring a path separator or end-of-string boundary. Untrusted guest code can therefore require the allowlisted module (e.g. `foo`) and then require the absolute path of a non-allowlisted sibling whose path merely shares the resolved prefix (e.g. `.../node_modules/foo2/index.js`); the sibling passes `isPathAllowedForModule` and is loaded through `hostRequire`, so its top-level code runs in the host process before the exports are wrapped with `vm.readonly`, resulting in a sandbox escape and arbitrary code execution in the host context.
π@cveNotify
GitHub
fix(GHSA-7q3f-wx44-378m): require a path boundary in external module β¦ Β· patriksimek/vm2@6ac3916
β¦prefix check
`LegacyResolver.isPathAllowedForModule` authorized a require originating
inside an allowlisted external module with a raw `path.startsWith(mod.path)`
test. `startsWith` is string con...
`LegacyResolver.isPathAllowedForModule` authorized a require originating
inside an allowlisted external module with a raw `path.startsWith(mod.path)`
test. `startsWith` is string con...
π¨ CVE-2026-100722
vm2 before 3.12.2 does not apply host-side Promise rejection handling in the sandbox-to-host construct trap. In BaseHandler, the apply trap calls markHostPromiseHandled() on the returned value, but the adjacent construct path returns the result of Reflect.construct without the same sanitization. If an embedder exposes a constructable host function whose constructor returns a native rejected Promise, an untrusted script executed via VM.run can invoke it with `new` and ignore the result; the rejected host Promise crosses the bridge unhandled and, under Node's strict unhandled-rejection policy, is promoted to an uncaught exception that terminates the host process.
π@cveNotify
vm2 before 3.12.2 does not apply host-side Promise rejection handling in the sandbox-to-host construct trap. In BaseHandler, the apply trap calls markHostPromiseHandled() on the returned value, but the adjacent construct path returns the result of Reflect.construct without the same sanitization. If an embedder exposes a constructable host function whose constructor returns a native rejected Promise, an untrusted script executed via VM.run can invoke it with `new` and ignore the result; the rejected host Promise crosses the bridge unhandled and, under Node's strict unhandled-rejection policy, is promoted to an uncaught exception that terminates the host process.
π@cveNotify
GitHub
Host Promise rejection from an exposed constructor can terminate the vm2 host process
# Host Promise rejection from an exposed constructor can terminate the vm2 host process
## Summary
An untrusted script run by `VM.run` can construct an embedder-exposed host function that returns...
## Summary
An untrusted script run by `VM.run` can construct an embedder-exposed host function that returns...
π¨ CVE-2026-100723
vm2 before 3.12.2 does not apply its Buffer backing-store ownership invariant (byteOffset === 0 and buffer.byteLength === length) to Buffers returned from host builtin modules. When an application explicitly exposes Node's zlib module through NodeVM's builtin allowlist (require: { builtin: ['zlib'] }), zlib.deflateSync can return a Buffer backed by Node's shared small-buffer pool whose .buffer is the entire pool. Untrusted guest code can construct a full-width view of that ArrayBuffer (Buffer.from(result.buffer, 0, result.buffer.byteLength)) to read and modify bytes belonging to unrelated host buffers, disclosing and corrupting host-realm memory across the sandbox boundary.
π@cveNotify
vm2 before 3.12.2 does not apply its Buffer backing-store ownership invariant (byteOffset === 0 and buffer.byteLength === length) to Buffers returned from host builtin modules. When an application explicitly exposes Node's zlib module through NodeVM's builtin allowlist (require: { builtin: ['zlib'] }), zlib.deflateSync can return a Buffer backed by Node's shared small-buffer pool whose .buffer is the entire pool. Untrusted guest code can construct a full-width view of that ArrayBuffer (Buffer.from(result.buffer, 0, result.buffer.byteLength)) to read and modify bytes belonging to unrelated host buffers, disclosing and corrupting host-realm memory across the sandbox boundary.
π@cveNotify
GitHub
fix(GHSA-fcqc-726x-5wfc): isolate sandbox buffers from Node's shared β¦ Β· patriksimek/vm2@4f2508a
β¦pool
Node serves small Buffer allocations out of one shared backing ArrayBuffer
of Buffer.poolSize bytes, and a pooled buffer's `.buffer` getter returns the
whole pool rather than the buf...
Node serves small Buffer allocations out of one shared backing ArrayBuffer
of Buffer.poolSize bytes, and a pooled buffer's `.buffer` getter returns the
whole pool rather than the buf...
π¨ CVE-2026-100724
http4k (Maven package org.http4k:http4k-core) before 6.49.0.0, 5.42.0.0 and 4.51.0.0 uses substring (Contains) matching on the Host header by default in reverseProxy() and reverseProxyRouting() when dispatching to configured virtual hosts. If these functions are deployed as a public-facing inbound HTTP handler with two or more configured virtual hosts, a remote attacker can supply a Host header that merely contains a configured vhost name (for example Host: admin.evil.com for a vhost configured as "admin") and be routed to that vhost, bypassing routing-based authorization. The intended outbound-dispatch and test-time uses, where the Host value is set by the calling application, are not affected.
π@cveNotify
http4k (Maven package org.http4k:http4k-core) before 6.49.0.0, 5.42.0.0 and 4.51.0.0 uses substring (Contains) matching on the Host header by default in reverseProxy() and reverseProxyRouting() when dispatching to configured virtual hosts. If these functions are deployed as a public-facing inbound HTTP handler with two or more configured virtual hosts, a remote attacker can supply a Host header that merely contains a configured vhost name (for example Host: admin.evil.com for a vhost configured as "admin") and be routed to that vhost, bypassing routing-based authorization. The intended outbound-dispatch and test-time uses, where the Host value is set by the calling application, are not affected.
π@cveNotify
GitHub
Fix 1377: Add optional host matching for reverse proxy routing Β· http4k/http4k@0121b05
The Functional toolkit for Kotlin HTTP applications. http4k provides a simple and uniform way to serve, consume, and test HTTP services. - Fix 1377: Add optional host matching for reverse proxy routing Β· http4k/http4k@0121b05
π¨ CVE-2026-100725
http4k (Maven artifact org.http4k:http4k-core) before 6.48.0.0, 5.42.0.0, and 4.51.0.0 ships a BasicCookieStorage (client-side cookie store used by ClientFilters.Cookies) that does not enforce RFC 6265 scoping rules for the cookie domain, path, and Secure attributes. When a single BasicCookieStorage instance is used to talk to more than one origin or scheme, cookies stored for one origin can be sent to other origins, and cookies marked Secure can be sent over plain HTTP, potentially disclosing session cookies or other sensitive values to unauthorized hosts or network observers. Clients that use a storage instance for a single origin are not affected.
π@cveNotify
http4k (Maven artifact org.http4k:http4k-core) before 6.48.0.0, 5.42.0.0, and 4.51.0.0 ships a BasicCookieStorage (client-side cookie store used by ClientFilters.Cookies) that does not enforce RFC 6265 scoping rules for the cookie domain, path, and Secure attributes. When a single BasicCookieStorage instance is used to talk to more than one origin or scheme, cookies stored for one origin can be sent to other origins, and cookies marked Secure can be sent over plain HTTP, potentially disclosing session cookies or other sensitive values to unauthorized hosts or network observers. Clients that use a storage instance for a single origin are not affected.
π@cveNotify
GitHub
Better cookie storage (#1549) Β· http4k/http4k@6a9b44d
* Introduce RFC6265CookieStorage
* Make Uri non-nullable
* Use new storage as default
* fix test setup
* rename
* rename
* rename
* format
* fix test
* comment
* update tests
* remove re...
* Make Uri non-nullable
* Use new storage as default
* fix test setup
* rename
* rename
* rename
* format
* fix test
* comment
* update tests
* remove re...
π¨ CVE-2026-100744
A flaw has been found in coollabsio Coolify up to 4.1.2. The affected element is an unknown function of the file app/Http/Middleware/CanUpdateResource.php of the component Route-Level Middleware. Executing a manipulation can lead to missing authorization. The attack may be launched remotely. The exploit has been published and may be used. Upgrading to version 4.2.0 is sufficient to fix this issue. This patch is called 39ae16de4248075de8c08f3259114e064b20d52d. It is advisable to upgrade the affected component.
π@cveNotify
A flaw has been found in coollabsio Coolify up to 4.1.2. The affected element is an unknown function of the file app/Http/Middleware/CanUpdateResource.php of the component Route-Level Middleware. Executing a manipulation can lead to missing authorization. The attack may be launched remotely. The exploit has been published and may be used. Upgrading to version 4.2.0 is sufficient to fix this issue. This patch is called 39ae16de4248075de8c08f3259114e064b20d52d. It is advisable to upgrade the affected component.
π@cveNotify
GitHub
GitHub - coollabsio/coolify: An open-source, self-hostable PaaS alternative to Vercel, Heroku & Netlify that lets you easily deployβ¦
An open-source, self-hostable PaaS alternative to Vercel, Heroku & Netlify that lets you easily deploy static sites, databases, full-stack applications and 280+ one-click services on your o...
π¨ CVE-2026-100745
A vulnerability has been found in Edimax BR-6428nC 1.16. The impacted element is an unknown function of the file /goform/formWizSurvey of the component Wireless Wizard Handler. The manipulation of the argument interface1/interface2 leads to stack-based buffer overflow. Remote exploitation of the attack is possible. The exploit has been disclosed to the public and may be used.
π@cveNotify
A vulnerability has been found in Edimax BR-6428nC 1.16. The impacted element is an unknown function of the file /goform/formWizSurvey of the component Wireless Wizard Handler. The manipulation of the argument interface1/interface2 leads to stack-based buffer overflow. Remote exploitation of the attack is possible. The exploit has been disclosed to the public and may be used.
π@cveNotify
tzh00203 on Notion
Edimax BR-6428nC formWizSurvey Interface Stack Overflow | Notion
Vulnerability Title: Stack-Based Buffer Overflow in formWizSurvey via interface1 and interface2 Parameters on Edimax BR-6428nC
π¨ CVE-2026-100833
Contrast (edgelesssys/contrast) versions 1.14.0 before 1.23.1 generate runtime policies that fail to detect all container image substitutions. A bad rebase during a Kata Containers update accidentally introduced an `allow_storage` rule that accepts storage entries using the `image_guest_pull` driver without verifying the image digest. An attacker with access to the Kata agent API β for example, a Kubernetes cluster administrator in Contrast's threat model β can therefore substitute a container image with an exploit payload, provided the substituted image satisfies the remaining policy rules, undermining the confidential container's integrity guarantees.
π@cveNotify
Contrast (edgelesssys/contrast) versions 1.14.0 before 1.23.1 generate runtime policies that fail to detect all container image substitutions. A bad rebase during a Kata Containers update accidentally introduced an `allow_storage` rule that accepts storage entries using the `image_guest_pull` driver without verifying the image digest. An attacker with access to the Kata agent API β for example, a Kubernetes cluster administrator in Contrast's threat model β can therefore substitute a container image with an exploit payload, provided the substituted image satisfies the remaining policy rules, undermining the confidential container's integrity guarantees.
π@cveNotify
GitHub
Generated policies don't detect all image substitutions
### Impact
A bad rebase during a Kata update resulted in the accidental addition of a rule that allows images without checking their digest. This could be used by an attacker with access to the ...
A bad rebase during a Kata update resulted in the accidental addition of a rule that allows images without checking their digest. This could be used by an attacker with access to the ...
π¨ CVE-2026-100834
http4k's Digest authentication module (org.http4k:http4k-security-digest) before versions 6.48.0.0, 5.42.0.0 and 4.51.0.0 defaults the nonceVerifier parameter of ServerFilters.DigestAuth and DigestAuthProvider to { true }, so every nonce is accepted regardless of its value, age, or prior use. Applications relying on this default have no replay protection on Digest authentication: an attacker who can capture a valid 'Authorization: Digest' response (for example by observing network traffic or reading logs) can replay it indefinitely against the same protected resource.
π@cveNotify
http4k's Digest authentication module (org.http4k:http4k-security-digest) before versions 6.48.0.0, 5.42.0.0 and 4.51.0.0 defaults the nonceVerifier parameter of ServerFilters.DigestAuth and DigestAuthProvider to { true }, so every nonce is accepted regardless of its value, age, or prior use. Applications relying on this default have no replay protection on Digest authentication: an attacker who can capture a valid 'Authorization: Digest' response (for example by observing network traffic or reading logs) can replay it indefinitely against the same protected resource.
π@cveNotify
GitHub
[Break] Remove default Nonce verifier option so avoid bad config. Β· http4k/http4k@4f904b4
Fix #1547: Add note to CHANGELOG
Upgrade versions
Upgrade versions
π¨ CVE-2026-100835
Contrast before 1.16.0 is susceptible to remote attestation relay attacks. Contrast accepted any TEE attestation report that verified correctly and contained the expected firmware patch levels and software measurements, regardless of which machine produced it, so attestation was not bound to specific, physically trusted hardware. An attacker who can both intercept network traffic between the CLI and the Coordinator (or between the Coordinator and an attested component) and forge reports or extract secrets from any single TEE machine under their physical control can relay such a report to impersonate a Contrast Coordinator or a Contrast workload, defeating identity verification in Contrast's attested TLS (aTLS).
π@cveNotify
Contrast before 1.16.0 is susceptible to remote attestation relay attacks. Contrast accepted any TEE attestation report that verified correctly and contained the expected firmware patch levels and software measurements, regardless of which machine produced it, so attestation was not bound to specific, physically trusted hardware. An attacker who can both intercept network traffic between the CLI and the Coordinator (or between the Coordinator and an attested component) and forge reports or extract secrets from any single TEE machine under their physical control can relay such a report to impersonate a Contrast Coordinator or a Contrast workload, defeating identity verification in Contrast's attested TLS (aTLS).
π@cveNotify
GitHub
Remote attestation is susceptible to relay attacks
## Impact
An attacker can impersonate a Contrast Coordinator or a Contrast workload under the following conditions:
- The attacker can intercept network traffic between CLI and Coordinator (o...
An attacker can impersonate a Contrast Coordinator or a Contrast workload under the following conditions:
- The attacker can intercept network traffic between CLI and Coordinator (o...
π¨ CVE-2026-100836
Contrast through 1.20.0 contains a panic vulnerability in the transit-engine endpoint's ciphertextContainer.UnmarshalJSON function that fails to validate decoded ciphertext length before slicing. An authenticated workload with a valid mesh certificate can trigger a runtime panic by submitting a short base64-encoded ciphertext, causing log spam and request failures without crashing the process.
π@cveNotify
Contrast through 1.20.0 contains a panic vulnerability in the transit-engine endpoint's ciphertextContainer.UnmarshalJSON function that fails to validate decoded ciphertext length before slicing. An authenticated workload with a valid mesh certificate can trigger a runtime panic by submitting a short base64-encoded ciphertext, causing log spam and request failures without crashing the process.
π@cveNotify
GitHub
Coordinator transit engine `ciphertextContainer.UnmarshalJSON` panics on attacker-controlled short ciphertexts
## Summary
`ciphertextContainer.UnmarshalJSON` decodes the third `:`-separated component of a `vault:vX:base64...` ciphertext and then unconditionally takes a 12-byte prefix slice for the AES-GCM ...
`ciphertextContainer.UnmarshalJSON` decodes the third `:`-separated component of a `vault:vX:base64...` ciphertext and then unconditionally takes a 12-byte prefix slice for the AES-GCM ...