Latest News

A lack of file name validation or verification in the Attachment service of usememos memos v0.25.2 allows attackers to execute a path traversal.

Incorrect access control in the Identity Provider service of usememos memos v0.25.2 allows attackers with low-level privileges to arbitrarily modify or delete registered identity providers, leading to an account takeover or Denial of Service (DoS).

Incorrect access control in usememos memos v0.25.2 allows attackers with low-level privileges to arbitrarily modify or delete attachments made by other users.

Incorrect access control in usememos memos v0.25.2 allows attackers with low-level privileges to arbitrarily delete reactions made to other users' Memos.

Securonix Threat Research details the complex JS#SMUGGLER campaign, a three-step web attack using obfuscated JavaScript and hidden HTA files to install the NetSupport RAT on user Windows desktops, granting hackers full remote control and persistent access.

### Summary An authentication bypass vulnerability exists due to a flaw in the libxml2 canonicalization process, which is used by [xmlseclibs](https://github.com/robrichards/xmlseclibs) during document transformation. This weakness allows an attacker to generate a valid signature once and reuse it indefinitely. In practice, a signature created during a previous interaction - or through a misconfigured authentication flow - can be replayed to bypass authentication checks. ### Details When libxml2’s canonicalization is invoked on an invalid XML input, it may return an empty string rather than a canonicalized node. [xmlseclibs](https://github.com/robrichards/xmlseclibs) then proceeds to compute the DigestValue over this empty string, treating it as if canonicalization succeeded. https://github.com/robrichards/xmlseclibs/blob/f4131320c6dcd460f1b0c67f16f8bf24ce4b5c3e/src/XMLSecurityDSig.php#L296 ### Impact Digest bypass: By crafting input that causes canonicalization to yield an empty st...

## Summary Critical security vulnerabilities exist in both the `UUIDv4()` and `UUID()` functions of the `github.com/gofiber/utils` package. When the system's cryptographic random number generator (`crypto/rand`) fails, both functions silently fall back to returning predictable UUID values, including the zero UUID `"00000000-0000-0000-0000-000000000000"`. This compromises the security of all Fiber applications using these functions for security-critical operations. **Both functions are vulnerable to the same root cause (`crypto/rand` failure):** - `UUIDv4()`: Indirect vulnerability through `uuid.NewRandom()` → `crypto/rand.Read()` → fallback to `UUID()` - `UUID()`: Direct vulnerability through `crypto/rand.Read(uuidSeed[:])` → silent zero UUID return ## Vulnerability Details ### Affected Functions - **Package**: `github.com/gofiber/utils` - **Functions**: `UUIDv4()` and `UUID()` - **Return Type**: `string` (both functions) - **Locations**: `common.go:93-99` (UUIDv4), `common.go:60-8...

### Summary The server trusts all reverse-proxy headers by default, so any remote client can spoof `X-Forwarded-For` to bypass IP-based protections (AllowIPs, API IP whitelist, “localhost-only” checks). All IP-based access control becomes ineffective. ### Details - Gin is created with defaults (`gin.Default()`), which sets `TrustedProxies = 0.0.0.0/0` and uses `X-Forwarded-For`/`X-Real-IP` to compute `ClientIP()`. - IP-based controls rely on `ClientIP()`: - AllowIPs / BindDomain (core/middleware/ip_limit.go, core/utils/security/security.go). - API IP whitelist (core/middleware/api_auth.go). - "localhost-only" checks that depend on `ClientIP()`. - Because no trusted-proxy range is enforced, any client can send `X-Forwarded-For: 127.0.0.1` (or a whitelisted IP) and be treated as coming from that address. ### Impact All IP-based access control is rendered ineffective: remote clients can masquerade as localhost or any whitelisted IP, defeating AllowIPs, API IP whitelists, a...

### Summary A CAPTCHA bypass vulnerability in the 1Panel authentication API allows an unauthenticated attacker to disable CAPTCHA verification by abusing a client-controlled parameter. Because the server previously trusted this value without proper validation, CAPTCHA protections could be bypassed, enabling automated login attempts and significantly increasing the risk of account takeover (ATO). ### Details The /api/login endpoint accepts a boolean field named ignoreCaptcha directly from the client request body: `"ignoreCaptcha": true` The backend implementation uses this value to determine whether CAPTCHA validation should be performed: ``` if !req.IgnoreCaptcha { if errMsg := captcha.VerifyCode(req.CaptchaID, req.Captcha); errMsg != "" { helper.BadAuth(c, errMsg, nil) return } } ``` Because req.IgnoreCaptcha is taken directly from user input—with no server-side validation, no session binding, and no privilege checks—any unauthenticated attacker can fo...

Cybersecurity researchers are calling attention to a new campaign dubbed JS#SMUGGLER that has been observed leveraging compromised websites as a distribution vector for a remote access trojan named NetSupport RAT. The attack chain, analyzed by Securonix, involves three main moving parts: An obfuscated JavaScript loader injected into a website, an HTML Application (HTA) that runs encrypted