#vulnerability

### Impact Calling `setTimer` in Azle versions `0.27.0`, `0.28.0`, and `0.29.0` causes an immediate infinite loop of timers to be executed on the canister, each timer attempting to clean up the global state of the previous timer. The infinite loop will occur with any valid invocation of `setTimer`. ### Patches The problem has been fixed as of Azle version `0.30.0`. ### Workarounds If a canister is caught in this infinite loop after calling `setTimer`, the canister can be upgraded and the timers will all be cleared, thus ending the loop.

# Impact An attacker may be able to exploit this vulnerability to bypass authentication or authorization mechanisms in systems that rely on xml-crypto for verifying signed XML documents. The vulnerability allows an attacker to modify a valid signed XML message in a way that still passes signature verification checks. For example, it could be used to alter critical identity or access control attributes, enabling an attacker to escalate privileges or impersonate another user. # Patches All versions <= 6.0.0 are affected. Please upgrade to version 6.0.1. If you are still using v2.x or v3.x please upgrade to the associated patch version. # Indicators of Compromise When logging XML payloads, check for the following indicators. If the payload includes encrypted elements, ensure you analyze the decrypted version for a complete assessment. (If encryption is not used, analyze the original XML document directly). This applies to various XML-based authentication and authorization flows, such ...

# Impact An attacker may be able to exploit this vulnerability to bypass authentication or authorization mechanisms in systems that rely on xml-crypto for verifying signed XML documents. The vulnerability allows an attacker to modify a valid signed XML message in a way that still passes signature verification checks. For example, it could be used to alter critical identity or access control attributes, enabling an attacker with a valid account to escalate privileges or impersonate another user. # Patches All versions <= 6.0.0 are affected. Please upgrade to version 6.0.1. If you are still using v2.x or v3.x please upgrade to the associated patch version. # Indicators of Compromise When logging XML payloads, check for the following indicators. If the payload includes encrypted elements, ensure you analyze the decrypted version for a complete assessment. (If encryption is not used, analyze the original XML document directly). This applies to various XML-based authentication and autho...

# Duplicate Advisory This advisory has been withdrawn because it is a duplicate of GHSA-6m2c-76ff-6vrf. This link is maintained to preserve external references. # Original Description A maliciously crafted QPY file can potential execute arbitrary-code embedded in the payload without privilege escalation when deserialising QPY formats < 13. A python process calling Qiskit 0.18.0 through 1.4.1's `qiskit.qpy.load()` function could potentially execute any arbitrary Python code embedded in the correct place in the binary file as part of specially constructed payload.

A Privilege Escalation through a Mass Assignment exists in Camaleon CMS When a user wishes to change his password, the 'updated_ajax' method of the UsersController is called. The vulnerability stems from the use of the dangerous permit! method, which allows all parameters to pass through without any filtering.

## Summary An unauthorized attacker can leverage the whitelisted route `/api/v1/attachments` to upload arbitrary files when the `storageType` is set to **local** (default). ## Details When a new request arrives, the system first checks if the URL starts with `/api/v1/`. If it does, the system then verifies whether the URL is included in the whitelist (*whitelistURLs*). If the URL is whitelisted, the request proceeds; otherwise, the system enforces authentication. @ */packages/server/src/index.ts* ```typescript this.app.use(async (req, res, next) => { // Step 1: Check if the req path contains /api/v1 regardless of case if (URL_CASE_INSENSITIVE_REGEX.test(req.path)) { // Step 2: Check if the req path is case sensitive if (URL_CASE_SENSITIVE_REGEX.test(req.path)) { // Step 3: Check if the req path is in the whitelist const isWhitelisted = whitelistURLs.some(...

FBI and CISA warn of Medusa ransomware attacks impacting critical infrastructure. Learn about Medusa’s tactics, prevention tips, and…

February 2025 saw a record 126% surge in ransomware attacks, with Cl0p leading the charge. Hackers exploited file…

### Issue Snowflake discovered and remediated a vulnerability in the Snowflake JDBC driver (“Driver”). When the logging level was set to DEBUG, the Driver would log locally the client-side encryption master key of the target stage during the execution of GET/PUT commands. This key by itself does not grant access to any sensitive data without additional access authorizations, and is not logged server-side by Snowflake. This vulnerability affects Driver versions 3.0.13 through 3.23.0. Snowflake fixed the issue in version 3.23.1. ### Vulnerability Details When the logging level was set to DEBUG, the Driver would locally log the client-side encryption master key of the target stage during the execution of GET/PUT commands. The key was logged in a JSON object under the queryStageMasterKey key. The key by itself does not grant access to any sensitive data. ### Solution Snowflake released version 3.23.1 of the Snowflake JDBC driver, which fixes this issue. We highly recommend users upgrad...

A security vulnerability was discovered in Kubernetes that could allow a user with create pod permission to exploit gitRepo volumes to access local git repositories belonging to other pods on the same node. This CVE only affects Kubernetes clusters that utilize the in-tree gitRepo volume to clone git repositories from other pods within the same node. Since the in-tree gitRepo volume feature has been deprecated and will not receive security updates upstream, any cluster still using this feature remains vulnerable.