OneUptime is a solution for monitoring and managing online services. Prior to version 10.0.34, the WhatsApp POST webhook handler (/notification/whatsapp/webhook) processes incoming status update events without verifying the Meta/WhatsApp X-Hub-Signature-256 HMAC signature, allowing any unauthenticated attacker to send forged webhook payloads that manipulate notification delivery status records, suppress alerts, and corrupt audit trails. The codebase already implements proper signature verification for Slack webhooks. This issue has been patched in version 10.0.34.
PySpector is a static analysis security testing (SAST) Framework engineered for modern Python development workflows. PySpector versions 0.1.6 and prior are affected by a stored Cross-Site Scripting (XSS) vulnerability in the HTML report generator. When PySpector scans a Python file containing JavaScript payloads (i.e. inside a string passed to eval() ), the flagged code snippet is interpolated into the HTML report without sanitization. Opening the generated report in a browser causes the embedded JavaScript to execute in the browser's local file context. This issue has been patched in version 0.1.7.
Frigate is a network video recorder (NVR) with realtime local object detection for IP cameras. Prior to version 0.16.3, the /ffprobe endpoint accepts arbitrary user-controlled URLs without proper validation, allowing Server-Side Request Forgery (SSRF) attacks. An attacker can use the Frigate server to make HTTP requests to internal network resources, cloud metadata services, or perform port scanning. This issue has been patched in version 0.16.3.
PySpector is a static analysis security testing (SAST) Framework engineered for modern Python development workflows. PySpector versions 0.1.6 and prior are affected by a security validation bypass in the plugin system. The validate_plugin_code() function in plugin_system.py, performs static AST analysis to block dangerous API calls before a plugin is trusted and executed. However, the internal resolve_name() helper only handles ast.Name and ast.Attribute node types, returning None for all others. When a plugin uses indirect function calls via getattr() (such as getattr(os, 'system')) the outer call's func node is of type ast.Call, causing resolve_name() to return None, and the security check to be silently skipped. The plugin incorrectly passes the trust workflow, and executes arbitrary system commands on the user's machine when loaded. This issue has been patched in version 0.1.7.
Cryptomator for Android offers multi-platform transparent client-side encryption for files in the cloud. Prior to version 1.12.3, an integrity check vulnerability allows an attacker tamper with the vault configuration file leading to a man-in-the-middle vulnerability in Hub key loading mechanism. Before this fix, the client trusted endpoints from the vault config without host authenticity checks, which could allow token exfiltration by mixing a legitimate auth endpoint with a malicious API endpoint. Impacted are users unlocking Hub-backed vaults with affected client versions in environments where an attacker can alter the vault.cryptomator file. This issue has been patched in version 1.12.3.
Cryptomator for IOS offers multi-platform transparent client-side encryption for files in the cloud. Prior to version 2.8.3, an integrity check vulnerability allows an attacker tamper with the vault configuration file leading to a man-in-the-middle vulnerability in Hub key loading mechanism. Before this fix, the client trusted endpoints from the vault config without host authenticity checks, which could allow token exfiltration by mixing a legitimate auth endpoint with a malicious API endpoint. Impacted are users unlocking Hub-backed vaults with affected client versions in environments where an attacker can alter the vault.cryptomator file. This issue has been patched in version 2.8.3.
Cryptomator encrypts data being stored on cloud infrastructure. Prior to version 1.19.1, the Hub-based unlock flow explicitly supports hub+http and consumes Hub endpoints from vault metadata without enforcing HTTPS. As a result, a vault configuration can drive OAuth and key-loading traffic over plaintext HTTP or other insecure endpoint combinations. An active network attacker can tamper with or observe this traffic. Even when the vault key is encrypted for the device, bearer tokens and endpoint-level trust decisions are still exposed to downgrade and interception. This issue has been patched in version 1.19.1.
Cryptomator encrypts data being stored on cloud infrastructure. From version 1.6.0 to before version 1.19.1, vault configuration is parsed before its integrity is verified, and the masterkeyfile loader uses the unverified keyId as a filesystem path. The loader resolves keyId.getSchemeSpecificPart() directly against the vault path and immediately calls Files.exists(...). This allows a malicious vault config to supply parent-directory escapes, absolute local paths, or UNC paths (e.g., masterkeyfile://attacker/share/masterkey.cryptomator). On Windows, the UNC variant is especially dangerous because Path.resolve("//attacker/share/...") becomes \\attacker\share\..., so the existence check can trigger outbound SMB access before the user even enters a passphrase. This issue has been patched in version 1.19.1.
Cryptomator encrypts data being stored on cloud infrastructure. Prior to version 1.19.1, an integrity check vulnerability allows an attacker to tamper with the vault configuration file leading to a man-in-the-middle vulnerability in Hub key loading mechanism. Before this fix, the client trusted endpoints from the vault config without host authenticity checks, which could allow token exfiltration by mixing a legitimate auth endpoint with a malicious API endpoint. Impacted are users unlocking Hub-backed vaults with affected client versions in environments where an attacker can alter the vault.cryptomator file. This issue has been patched in version 1.19.1.
A command injection vulnerability has been reported to affect QuNetSwitch. The remote attackers can then exploit the vulnerability to execute arbitrary commands.
We have already fixed the vulnerability in the following version:
QuNetSwitch 2.0.4.0415 and later