#auth

A new security flaw in SmarterTools SmarterMail email software has come under active exploitation in the wild, two days after the release of a patch. The vulnerability, which currently does not have a CVE identifier, is tracked by watchTowr Labs as WT-2026-0001. It was patched by SmarterTools on January 15, 2026, with Build 9511, following responsible disclosure by the exposure management

Improper validation of specified type of input in M365 Copilot allows an unauthorized attacker to disclose information over a network.

Improper access control in Azure Front Door (AFD) allows an unauthorized attacker to elevate privileges over a network.

Cybersecurity company Arctic Wolf has warned of a "new cluster of automated malicious activity" that involves unauthorized firewall configuration changes on Fortinet FortiGate devices. The activity, it said, commenced on January 15, 2026, adding it shares similarities with a December 2025 campaign in which malicious SSO logins on FortiGate appliances were recorded against the admin account from

Cisco has released fresh patches to address what it described as a "critical" security vulnerability impacting multiple Unified Communications (CM) products and Webex Calling Dedicated Instance that it has been actively exploited as a zero-day in the wild. The vulnerability, CVE-2026-20045 (CVSS score: 8.2), could permit an unauthenticated remote attacker to execute arbitrary commands on the

### Impact _What kind of vulnerability is it? Who is impacted?_ This issue impacts every Soft Serve instance. A critical authentication bypass allows an attacker to impersonate any user (including Admin) by "offering" the victim's public key during the SSH handshake before authenticating with their own valid key. This occurs because the user identity is stored in the session context during the "offer" phase and is not cleared if that specific authentication attempt fails. ### Patches _Has the problem been patched? What versions should users upgrade to?_ Yes, please upgrade to version 0.11.3 as soon as possible. ### Workarounds _Is there a way for users to fix or remediate the vulnerability without upgrading?_ You need to upgrade

### Impact Lodash versions 4.0.0 through 4.17.22 are vulnerable to prototype pollution in the `_.unset` and `_.omit` functions. An attacker can pass crafted paths which cause Lodash to delete methods from global prototypes. The issue permits deletion of properties but does not allow overwriting their original behavior. ### Patches This issue is patched on 4.17.23.

### Impact Unauthenticated denial of service. ### Summary When installing module packages from attacker-controlled sources, `tofu init` may cause high CPU usage when encountering maliciously-crafted `.zip` archives for either provider or module distribution packages. Those who depend on modules or providers served from untrusted third-party servers may experience denial of service due to `tofu init` failing to complete in a timely manner. Other processes running on the same computer as OpenTofu may also have their performance degraded due to the high CPU usage. These vulnerabilities **do not** permit arbitrary code execution or allow disclosure of confidential information. ### Details OpenTofu relies on a third-party implementation of `.zip` archive extraction from the standard library of the Go programming language. The Go project has recently published a minor release (Go 1.25.6) to address a problem of potential excessive CPU usage when accessing files in a maliciously-crafted ...

In affected versions of Triton VM, the verifier failed to correctly sample randomness in the FRI sub-protocol. Malicious provers can exploit this to craft proofs for arbitrary statements that this verifier accepts as valid, undermining soundness. Protocols that rely on proofs and the supplied verifier of the affected versions of Triton VM are completely broken. Protocols implementing their own verifier might be unaffected. The flaw was corrected in commit 3a045d63, where the relevant randomness is sampled correctly.

### Impact Timing side-channel vulnerability in verify_key(). The method applied a random delay only on verification failures, allowing an attacker to statistically distinguish valid from invalid API keys by measuring response latencies. With enough repeated requests, an adversary could infer whether a key_id corresponds to a valid key, potentially accelerating brute-force or enumeration attacks. Affected: all users relying on verify_key() for API key authentication prior to the fix. ### Patches Yes. Users should upgrade to version 1.1.0 (or the version containing this fix). The patch applies a uniform random delay (min_delay to max_delay) to all responses regardless of outcome, eliminating the timing correlation. ### Workarounds - Add an application-level fixed delay or random jitter to all authentication responses (success and failure) before the fix is applied. - Use rate limiting to reduce the feasibility of statistical timing attacks. ### References - CWE-208: Observable Timin...