π¨ CVE-2026-24014
Apache IoTDB DataNodeβs internal RPC interface for creating Trigger instances uses the uploaded Trigger JAR name to build a file path without sufficient validation. If the internal DataNode RPC port is exposed to an untrusted network, an attacker may use path traversal sequences in the JAR name to write files outside the intended Trigger installation directory. This could allow arbitrary file write with the permissions of the IoTDB process.
This issue affects Apache IoTDB: from 1.3.3 before 2.0.8.
Users are recommended to upgrade to version 2.0.8, which fixes the issue.
π@cveNotify
Apache IoTDB DataNodeβs internal RPC interface for creating Trigger instances uses the uploaded Trigger JAR name to build a file path without sufficient validation. If the internal DataNode RPC port is exposed to an untrusted network, an attacker may use path traversal sequences in the JAR name to write files outside the intended Trigger installation directory. This could allow arbitrary file write with the permissions of the IoTDB process.
This issue affects Apache IoTDB: from 1.3.3 before 2.0.8.
Users are recommended to upgrade to version 2.0.8, which fixes the issue.
π@cveNotify
π¨ CVE-2026-56139
Generation of Error Message Containing Sensitive Information vulnerability in Apache Camel Undertow Component.
The camel-undertow HTTP server consumer exposes a muteException option that controls what is returned to the client when a route processing error occurs. This option defaulted to false, whereas the other Camel HTTP server components (camel-http / camel-jetty / camel-servlet and camel-platform-http) default it to true. With muteException=false, when a request triggers an exception during route processing the consumer writes the full Throwable stack trace into the HTTP response body as text/plain instead of returning an empty body. Any unauthenticated client that can reach the endpoint and cause a processing error - for example by sending a malformed request body, an invalid parameter, or otherwise triggering a route-internal failure - therefore receives a complete Java stack trace. Such a stack trace can disclose sensitive internal information, including credentials embedded in exception messages, internal host names and IP addresses, filesystem paths, dependency and version details, database and class names, and the application's internal structure, which an attacker can use to plan further attacks. In addition, for Rest DSL consumers the muteException option was not honoured at all: the RestUndertowHttpBinding was created with a hard-coded false, so the stack trace was returned even when muteException=true had been configured.
This issue affects Apache Camel: from 4.0.0 before 4.14.8, from 4.15.0 before 4.18.3, from 4.19.0 before 4.21.0.
Users are recommended to upgrade to version 4.21.0, which fixes the issue. If users are on the 4.14.x LTS releases stream, then they are suggested to upgrade to 4.14.8. If users are on the 4.18.x releases stream, then they are suggested to upgrade to 4.18.3. For deployments that cannot upgrade immediately, set muteException=true explicitly on the camel-undertow consumer (for example undertow: http://0.0.0.0:8080/api?muteException=true , or globally via the camel.component.undertow.mute-exception=true property), so that processing errors no longer return the stack trace to the client; note that on affected releases this workaround does not cover Rest DSL consumers, whose binding ignores the option until the fix is applied.
π@cveNotify
Generation of Error Message Containing Sensitive Information vulnerability in Apache Camel Undertow Component.
The camel-undertow HTTP server consumer exposes a muteException option that controls what is returned to the client when a route processing error occurs. This option defaulted to false, whereas the other Camel HTTP server components (camel-http / camel-jetty / camel-servlet and camel-platform-http) default it to true. With muteException=false, when a request triggers an exception during route processing the consumer writes the full Throwable stack trace into the HTTP response body as text/plain instead of returning an empty body. Any unauthenticated client that can reach the endpoint and cause a processing error - for example by sending a malformed request body, an invalid parameter, or otherwise triggering a route-internal failure - therefore receives a complete Java stack trace. Such a stack trace can disclose sensitive internal information, including credentials embedded in exception messages, internal host names and IP addresses, filesystem paths, dependency and version details, database and class names, and the application's internal structure, which an attacker can use to plan further attacks. In addition, for Rest DSL consumers the muteException option was not honoured at all: the RestUndertowHttpBinding was created with a hard-coded false, so the stack trace was returned even when muteException=true had been configured.
This issue affects Apache Camel: from 4.0.0 before 4.14.8, from 4.15.0 before 4.18.3, from 4.19.0 before 4.21.0.
Users are recommended to upgrade to version 4.21.0, which fixes the issue. If users are on the 4.14.x LTS releases stream, then they are suggested to upgrade to 4.14.8. If users are on the 4.18.x releases stream, then they are suggested to upgrade to 4.18.3. For deployments that cannot upgrade immediately, set muteException=true explicitly on the camel-undertow consumer (for example undertow: http://0.0.0.0:8080/api?muteException=true , or globally via the camel.component.undertow.mute-exception=true property), so that processing errors no longer return the stack trace to the client; note that on affected releases this workaround does not cover Rest DSL consumers, whose binding ignores the option until the fix is applied.
π@cveNotify
Apache Camel
Apache Camel Security Advisory - CVE-2026-56139
The camel-undertow HTTP server consumer exposes a muteException option that controls what is returned to the client when a route processing error occurs. This option defaulted to false, whereas the other Camel HTTP server components (camel-http / camel-jettyβ¦
π¨ CVE-2026-43825
Untrusted Java Deserialization in Apache OpenNLP SvmDoccatModel
Versions Affected:
before 3.0.0-M4 (libsvm document categorization module; introduced in
OPENNLP-1808 and only present on the 3.x line)
Description:
SvmDoccatModel.deserialize(InputStream) reads an attacker-controlled
stream with java.io.ObjectInputStream and calls readObject() without an
ObjectInputFilter installed. ObjectInputStream materialises every class
referenced in the stream before the resulting object is cast to
SvmDoccatModel, so the cast that follows readObject() executes only
after the foreign object graph has already been deserialised in full.
If a Java deserialization gadget chain is available on the consumer's
classpath, a crafted payload supplied to
deserialize() executes arbitrary code in the JVM that loads it. Apache
OpenNLP itself does not ship a known gadget chain, so the realistic
risk is to downstream applications that embed the libsvm module
alongside vulnerable transitive dependencies. The method is public and
static, so any caller can pass an untrusted stream to it directly.
The practical impact is remote code execution against processes that
load SvmDoccatModel instances from untrusted or semi-trusted origins.
Mitigation:
3.x users should upgrade to 3.0.0-M4.
Users who cannot upgrade immediately should treat all serialized
SvmDoccatModel streams as untrusted input unless their provenance is
verified, and should avoid invoking SvmDoccatModel.deserialize() on
streams supplied by end users or fetched from third-party sources
without integrity checks.
π@cveNotify
Untrusted Java Deserialization in Apache OpenNLP SvmDoccatModel
Versions Affected:
before 3.0.0-M4 (libsvm document categorization module; introduced in
OPENNLP-1808 and only present on the 3.x line)
Description:
SvmDoccatModel.deserialize(InputStream) reads an attacker-controlled
stream with java.io.ObjectInputStream and calls readObject() without an
ObjectInputFilter installed. ObjectInputStream materialises every class
referenced in the stream before the resulting object is cast to
SvmDoccatModel, so the cast that follows readObject() executes only
after the foreign object graph has already been deserialised in full.
If a Java deserialization gadget chain is available on the consumer's
classpath, a crafted payload supplied to
deserialize() executes arbitrary code in the JVM that loads it. Apache
OpenNLP itself does not ship a known gadget chain, so the realistic
risk is to downstream applications that embed the libsvm module
alongside vulnerable transitive dependencies. The method is public and
static, so any caller can pass an untrusted stream to it directly.
The practical impact is remote code execution against processes that
load SvmDoccatModel instances from untrusted or semi-trusted origins.
Mitigation:
3.x users should upgrade to 3.0.0-M4.
Users who cannot upgrade immediately should treat all serialized
SvmDoccatModel streams as untrusted input unless their provenance is
verified, and should avoid invoking SvmDoccatModel.deserialize() on
streams supplied by end users or fetched from third-party sources
without integrity checks.
π@cveNotify
π¨ CVE-2026-54291
pgjdbc is an open source postgresql JDBC Driver. In releases 42.7.4 through 42.7.11, channelBinding=require connections can be silently downgraded from SCRAM-SHA-256-PLUS with channel binding to plain SCRAM-SHA-256 without it, losing the man-in-the-middle protection the setting is meant to guarantee. An attacker who can intercept the TLS connection can trigger the downgrade with a certificate whose signature algorithm has no tls-server-end-point channel-binding hash, because the bundled com.ongres.scram:scram-client returns an empty byte array instead of failing and pgJDBC ScramAuthenticator checks only that the server advertised a PLUS mechanism, without rejecting the empty binding or checking that the negotiated mechanism uses channel binding. This issue is fixed in version 42.7.12.
π@cveNotify
pgjdbc is an open source postgresql JDBC Driver. In releases 42.7.4 through 42.7.11, channelBinding=require connections can be silently downgraded from SCRAM-SHA-256-PLUS with channel binding to plain SCRAM-SHA-256 without it, losing the man-in-the-middle protection the setting is meant to guarantee. An attacker who can intercept the TLS connection can trigger the downgrade with a certificate whose signature algorithm has no tls-server-end-point channel-binding hash, because the bundled com.ongres.scram:scram-client returns an empty byte array instead of failing and pgJDBC ScramAuthenticator checks only that the server advertised a PLUS mechanism, without rejecting the empty binding or checking that the negotiated mechanism uses channel binding. This issue is fixed in version 42.7.12.
π@cveNotify
GitHub
Release SCRAM Java 3.3 Β· ongres/scram
π Security
Prevent silent downgrade attacks during channel binding negotiation via unsupported certificate algorithms. GHSA-p9jg-fcr6-3mhf
Harden memory security by explicitly zeroing out highly s...
Prevent silent downgrade attacks during channel binding negotiation via unsupported certificate algorithms. GHSA-p9jg-fcr6-3mhf
Harden memory security by explicitly zeroing out highly s...
π¨ CVE-2026-11405
The web server binary /bin/httpd contains a hidden backdoor authentication mechanism in the login() function at 004c88b8.
- The function contains a normal authentication path using MD5/hash-based password verification (prod_encode64/PasswordToMd5/check_rand_key).
- After normal authentication fails, it calls GetValue("sys.rzadmin.password") to read a backdoor password from the device configuration.
- It performs a direct strcmp() comparison (plaintext, not hashed) between the config value and the user-supplied password.
A successful match grants role=2 (admin-level access) and creates a valid session. The rzadmin username is never checked β any username works with the backdoor
π@cveNotify
The web server binary /bin/httpd contains a hidden backdoor authentication mechanism in the login() function at 004c88b8.
- The function contains a normal authentication path using MD5/hash-based password verification (prod_encode64/PasswordToMd5/check_rand_key).
- After normal authentication fails, it calls GetValue("sys.rzadmin.password") to read a backdoor password from the device configuration.
- It performs a direct strcmp() comparison (plaintext, not hashed) between the config value and the user-supplied password.
A successful match grants role=2 (admin-level access) and creates a valid session. The rzadmin username is never checked β any username works with the backdoor
π@cveNotify
cwe.mitre.org
CWE -
CWE-912: Hidden Functionality (4.20)
CWE-912: Hidden Functionality (4.20)
Common Weakness Enumeration (CWE) is a list of software weaknesses.
π¨ CVE-2026-41516
OP-TEE is a Trusted Execution Environment (TEE) designed as companion to a non-secure Linux kernel running on Arm; Cortex-A cores using the TrustZone technology. Starting in version 4.5.0 and prior to version 4.11.0, the RSA PKCS#1 v1.5 decryption implementation in the Hisilicon HPRE crypto driver uses non-constant-time `memcmp()` for label hash verification and has multiple distinguishable error paths. This creates a Bleichenbacher-style padding oracle that allows an attacker to recover RSA PKCS#1 v1.5 plaintext. Version 4.11.0 contains a patch. As a workaround, disable Hisilicon HPRE RSA driver with `CFG_HISILICON_ACC_V3=n`.
π@cveNotify
OP-TEE is a Trusted Execution Environment (TEE) designed as companion to a non-secure Linux kernel running on Arm; Cortex-A cores using the TrustZone technology. Starting in version 4.5.0 and prior to version 4.11.0, the RSA PKCS#1 v1.5 decryption implementation in the Hisilicon HPRE crypto driver uses non-constant-time `memcmp()` for label hash verification and has multiple distinguishable error paths. This creates a Bleichenbacher-style padding oracle that allows an attacker to recover RSA PKCS#1 v1.5 plaintext. Version 4.11.0 contains a patch. As a workaround, disable Hisilicon HPRE RSA driver with `CFG_HISILICON_ACC_V3=n`.
π@cveNotify
GitHub
Hisilicon HPRE PKCS#1 v1.5 Decryption Padding Oracle
# Hisilicon HPRE PKCS#⁠1 v1.5 Decryption Padding Oracle
### Summary
The RSA PKCS#⁠1 v1.5 decryption implementation in the Hisilicon HPRE crypto driver uses non-constant-...
### Summary
The RSA PKCS#⁠1 v1.5 decryption implementation in the Hisilicon HPRE crypto driver uses non-constant-...
π¨ CVE-2026-42546
OP-TEE is a Trusted Execution Environment (TEE) designed as companion to a non-secure Linux kernel running on Arm; Cortex-A cores using the TrustZone technology. Starting in version 3.3.0 and prior to version 4.11.0, a resource leak exists in OP-TEEβs shared memory cleanup logic because the function `cleanup_shm_refs()` in `core/tee/entry_std.c` fails to apply a required bitmask (`OPTEE_MSG_ATTR_TYPE_MASK`) to parameter attributes. When processing non-contiguous memory parameters from a normal-world caller, the system fails to match the attribute type in its internal switch statement and skips the necessary mobj_put() call. This results in a persistent reference leak of `mobj_reg_shm` objects, which remain on internal lists with dangling refcounts. This affects non-FF-A configurations that support non-contiguous, non-secure shared memory. Over time, these accumulated leaks progressively consume the secure-world heap, degrading the system's ability to service trusted application operations and eventually requiring a reboot to recover. Version 4.11.0 contains a patch. No known workarounds are available.
π@cveNotify
OP-TEE is a Trusted Execution Environment (TEE) designed as companion to a non-secure Linux kernel running on Arm; Cortex-A cores using the TrustZone technology. Starting in version 3.3.0 and prior to version 4.11.0, a resource leak exists in OP-TEEβs shared memory cleanup logic because the function `cleanup_shm_refs()` in `core/tee/entry_std.c` fails to apply a required bitmask (`OPTEE_MSG_ATTR_TYPE_MASK`) to parameter attributes. When processing non-contiguous memory parameters from a normal-world caller, the system fails to match the attribute type in its internal switch statement and skips the necessary mobj_put() call. This results in a persistent reference leak of `mobj_reg_shm` objects, which remain on internal lists with dangling refcounts. This affects non-FF-A configurations that support non-contiguous, non-secure shared memory. Over time, these accumulated leaks progressively consume the secure-world heap, degrading the system's ability to service trusted application operations and eventually requiring a reboot to recover. Version 4.11.0 contains a patch. No known workarounds are available.
π@cveNotify
GitHub
Missing OPTEE_MSG_ATTR_TYPE_MASK in cleanup_shm_refs() leaks mobj references
### Summary
A resource leak exists in OP-TEEβs shared memory cleanup logic because the function `cleanup_shm_refs()` in `core/tee/entry_std.c` fails to apply a required bitmask (`OPTEE_MSG_ATTR_T...
A resource leak exists in OP-TEEβs shared memory cleanup logic because the function `cleanup_shm_refs()` in `core/tee/entry_std.c` fails to apply a required bitmask (`OPTEE_MSG_ATTR_T...
π¨ CVE-2026-44362
OP-TEE is a Trusted Execution Environment (TEE) designed as companion to a non-secure Linux kernel running on Arm; Cortex-A cores using the TrustZone technology. Starting in version 3.20.0 and prior to version 4.11.0, a vulnerability in OP-TEEβs subkey rollback protection allows the use of revoked or older subkey versions because the system fails to propagate versioning data during the Trusted Application (TA) loading process. In `core/crypto/signed_hdr.c`, the function `shdr_load_pub_key()` parses subkey headers but does not assign the `subkey_version` to the runtime `shdr_pub_key` structure. As a result, the `key->version` field remains at zero regardless of the version specified in the header. When `ree_fs_ta_open()` in `core/kernel/ree_fs_ta.c` calls `check_update_version()`, it passes this zeroed version to the rollback database. Because the database never receives a non-zero version to record, it never advances, effectively bypassing the rollback check and allowing TAs signed with downgraded subkey chains to load successfully. This impacts OP-TEE mainline configurations that utilize subkey-based signing chains for Trusted Application (TA) authentication. Version 4.11.0 contains a patch. No known workarounds are available.
π@cveNotify
OP-TEE is a Trusted Execution Environment (TEE) designed as companion to a non-secure Linux kernel running on Arm; Cortex-A cores using the TrustZone technology. Starting in version 3.20.0 and prior to version 4.11.0, a vulnerability in OP-TEEβs subkey rollback protection allows the use of revoked or older subkey versions because the system fails to propagate versioning data during the Trusted Application (TA) loading process. In `core/crypto/signed_hdr.c`, the function `shdr_load_pub_key()` parses subkey headers but does not assign the `subkey_version` to the runtime `shdr_pub_key` structure. As a result, the `key->version` field remains at zero regardless of the version specified in the header. When `ree_fs_ta_open()` in `core/kernel/ree_fs_ta.c` calls `check_update_version()`, it passes this zeroed version to the rollback database. Because the database never receives a non-zero version to record, it never advances, effectively bypassing the rollback check and allowing TAs signed with downgraded subkey chains to load successfully. This impacts OP-TEE mainline configurations that utilize subkey-based signing chains for Trusted Application (TA) authentication. Version 4.11.0 contains a patch. No known workarounds are available.
π@cveNotify
GitHub
Subkey rollback protection can be bypassed with older subkey versions
### Summary
A vulnerability in OP-TEEβs subkey rollback protection allows the use of revoked or older subkey versions because the system fails to propagate versioning data during the Trusted Appli...
A vulnerability in OP-TEEβs subkey rollback protection allows the use of revoked or older subkey versions because the system fails to propagate versioning data during the Trusted Appli...
π¨ CVE-2026-55646
vLLM is an inference and serving engine for large language models. From 0.22.0 to 0.23.0, the /v1/audio/transcriptions and /v1/audio/translations routes call request.file.read() to fully materialize an uploaded audio file into memory before vLLM checks the documented VLLM_MAX_AUDIO_CLIP_FILESIZE_MB compressed upload size limit (default 25 MB) later in the speech-to-text preprocessing step, so an API caller who can reach those routes can submit an oversized multipart upload and cause vLLM to allocate memory proportional to the uploaded file size before the request is rejected as too large, creating memory pressure or terminating the process depending on deployment resource limits. This issue is fixed in version 0.24.0.
π@cveNotify
vLLM is an inference and serving engine for large language models. From 0.22.0 to 0.23.0, the /v1/audio/transcriptions and /v1/audio/translations routes call request.file.read() to fully materialize an uploaded audio file into memory before vLLM checks the documented VLLM_MAX_AUDIO_CLIP_FILESIZE_MB compressed upload size limit (default 25 MB) later in the speech-to-text preprocessing step, so an API caller who can reach those routes can submit an oversized multipart upload and cause vLLM to allocate memory proportional to the uploaded file size before the request is rejected as too large, creating memory pressure or terminating the process depending on deployment resource limits. This issue is fixed in version 0.24.0.
π@cveNotify
GitHub
(security) Enforce audio upload size limit before full file materiali⦠· vllm-project/vllm@b997071
β¦zation (#45510)
Signed-off-by: jperezde <jperezde@redhat.com>
Signed-off-by: jperezde <jperezde@redhat.com>
π¨ CVE-2026-58402
Hugo is a static site generator. From 0.60.0 until 0.163.3, Hugo's default code-block renderer wrote the Markdown code-fence language or info-string into the code class="language-β¦" data-lang="β¦" wrapper without HTML escaping. A fence info-string containing a quote and a script payload breaks out of the attribute and injects a live script element. This issue is fixed in 0.163.3.
π@cveNotify
Hugo is a static site generator. From 0.60.0 until 0.163.3, Hugo's default code-block renderer wrote the Markdown code-fence language or info-string into the code class="language-β¦" data-lang="β¦" wrapper without HTML escaping. A fence info-string containing a quote and a script payload breaks out of the attribute and injects a live script element. This issue is fixed in 0.163.3.
π@cveNotify
GitHub
markup/highlight: Escape lang in default code block rendering Β· gohugoio/hugo@ce1a7e0
The worldβs fastest framework for building websites. - markup/highlight: Escape lang in default code block rendering Β· gohugoio/hugo@ce1a7e0
π¨ CVE-2026-58403
Hugo is a static site generator. From v0.123.0 through v0.163.0, Hugo's virtual filesystem is designed so that files under a mount cannot reach outside the mount tree, but a regression caused RootMappingFs.statRoot to call Stat, which follows symlinks, instead of Lstat, so a direct os.ReadFile "somefile" where somefile was a symlink pointing outside the mount would return the target's contents. This effectively let a symlink planted inside a theme or local mount read arbitrary files reachable to the user running hugo. This issue is fixed in v0.163.1.
π@cveNotify
Hugo is a static site generator. From v0.123.0 through v0.163.0, Hugo's virtual filesystem is designed so that files under a mount cannot reach outside the mount tree, but a regression caused RootMappingFs.statRoot to call Stat, which follows symlinks, instead of Lstat, so a direct os.ReadFile "somefile" where somefile was a symlink pointing outside the mount would return the target's contents. This effectively let a symlink planted inside a theme or local mount read arbitrary files reachable to the user running hugo. This issue is fixed in v0.163.1.
π@cveNotify
GitHub
Drop symlinks in os.ReadDir, os.ReadFile, os.Stat and os.FileExists Β· gohugoio/hugo@cf9c8f9
Fixes #15019
π¨ CVE-2026-59089
A flaw was found in GIMP. The PlayStation TIM loader, responsible for handling PlayStation image files, incorrectly calculates the size of the Color Look-Up Table (CLUT) due to an integer overflow. This occurs when multiplying num_colors and num_cluts, both 16-bit unsigned short integers, resulting in a value exceeding the maximum integer limit. An attacker could exploit this by providing a specially crafted image file, leading to undefined behavior and causing the GIMP plug-in to abort, effectively resulting in a denial of service.
π@cveNotify
A flaw was found in GIMP. The PlayStation TIM loader, responsible for handling PlayStation image files, incorrectly calculates the size of the Color Look-Up Table (CLUT) due to an integer overflow. This occurs when multiplying num_colors and num_cluts, both 16-bit unsigned short integers, resulting in a value exceeding the maximum integer limit. An attacker could exploit this by providing a specially crafted image file, leading to undefined behavior and causing the GIMP plug-in to abort, effectively resulting in a denial of service.
π@cveNotify
π¨ CVE-2025-59615
Memory Corruption when invoking device input/output control operations for mapping and unmapping persistent memory buffers due to improper synchronization.
π@cveNotify
Memory Corruption when invoking device input/output control operations for mapping and unmapping persistent memory buffers due to improper synchronization.
π@cveNotify
π¨ CVE-2025-59616
Memory Corruption when processing multiple IOCTL calls with the same buffer file descriptor input due to accessing already freed memory.
π@cveNotify
Memory Corruption when processing multiple IOCTL calls with the same buffer file descriptor input due to accessing already freed memory.
π@cveNotify
π¨ CVE-2026-14468
HashiCorp Terraform Enterprise contained an issue in its version control system (VCS) ingestion of registry modules that did not correctly enforce the intended boundary on packaged module content. This may allow an authenticated user to include files from outside the intended repository content in a module and then download them, potentially exposing sensitive files readable by the ingestion process. This vulnerability, CVE-2026-14468, is fixed in Terraform Enterprise v2.0.4 and v1.2.4.
π@cveNotify
HashiCorp Terraform Enterprise contained an issue in its version control system (VCS) ingestion of registry modules that did not correctly enforce the intended boundary on packaged module content. This may allow an authenticated user to include files from outside the intended repository content in a module and then download them, potentially exposing sensitive files readable by the ingestion process. This vulnerability, CVE-2026-14468, is fixed in Terraform Enterprise v2.0.4 and v1.2.4.
π@cveNotify
HashiCorp Discuss
HCSEC-2026-17 - Terraform Enterprise vulnerable to arbitrary file read
Bulletin ID: HCSEC-2026-17 Affected Products / Versions: Terraform Enterprise v202506-1, v202507-1, and 1.0.0 through 2.0.3; fixed in Terraform Enterprise 2.0.4, 1.2.4. Publication Date: July 6, 2026 Summary HashiCorp Terraform Enterprise contained anβ¦
π¨ CVE-2026-14471
Improper Neutralization of Special Elements in the metrics-service retention policy management component in Amazon mcp-gateway-registry before 1.0.13 might allow an authenticated remote user to execute arbitrary SQL queries via a crafted table_name value that is interpolated into SQL statements in identifier position.
To remediate this issue, users should upgrade to version 1.0.13 or later.
π@cveNotify
Improper Neutralization of Special Elements in the metrics-service retention policy management component in Amazon mcp-gateway-registry before 1.0.13 might allow an authenticated remote user to execute arbitrary SQL queries via a crafted table_name value that is interpolated into SQL statements in identifier position.
To remediate this issue, users should upgrade to version 1.0.13 or later.
π@cveNotify
π¨ CVE-2026-21368
Memory Corruption when parsing jpeg commands due to unaccounted extra writes to the buffer during validation checks.
π@cveNotify
Memory Corruption when parsing jpeg commands due to unaccounted extra writes to the buffer during validation checks.
π@cveNotify
π¨ CVE-2026-21369
Memory Corruption when handling flash commands due to outdated LED count values being used after userspace modification.
π@cveNotify
Memory Corruption when handling flash commands due to outdated LED count values being used after userspace modification.
π@cveNotify
π¨ CVE-2026-21370
Memory Corruption when validating input batch size and buffer plane count exceeds maximum allowed values.
π@cveNotify
Memory Corruption when validating input batch size and buffer plane count exceeds maximum allowed values.
π@cveNotify
π¨ CVE-2026-21379
Memory Corruption when allocating memory with sizes that exceed the maximum allowed value.
π@cveNotify
Memory Corruption when allocating memory with sizes that exceed the maximum allowed value.
π@cveNotify
π¨ CVE-2026-21383
Cryptographic Issue when using a static initialization vector for AES-GCM key wrapping, which requires a unique value for each call to ensure security.
π@cveNotify
Cryptographic Issue when using a static initialization vector for AES-GCM key wrapping, which requires a unique value for each call to ensure security.
π@cveNotify