A PHP Object Injection vulnerability exists in myPOS Checkout versions up to and including 1.4.5. This vulnerability allows an attacker with high privileges to execute arbitrary code or cause denial of service. The flaw is identified as CWE-502 and has a CVSS 3.1 score of 7.2, indicating high severity.
CVE-2026-112255 is a vulnerability in OpenText Advanced Authentication Server versions 6.4.0.0 through 6.4.3.x, 6.5.0.0 through 6.5.0.x, and 6.6.0.0 through 6.6.1.0. It involves initialization of a resource with insecure default settings that allow excessive allocation. The issue arises from allowing creation or recreation of Unauthenticated Endpoints without proper network restrictions. The recommended fix is to configure the system to disallow creation/recreation of Unauthenticated Endpoints or restrict this capability to trusted networks via a non-empty whitelist. The 6.6.2.0 release includes best practice guidance for secure configuration.
A Missing Authorization vulnerability exists in StylemixThemes MasterStudy LMS up to version 3.7.55. This flaw involves incorrectly configured access control security levels, potentially allowing unauthorized access to certain functionality or data. The vulnerability has a medium severity rating with a CVSS score of 4.3. No public exploits or patches are currently documented.
An uncaught exception vulnerability exists in llama.cpp versions from b2877 up to but not including b11935 in the ggml-rpc server. This flaw allows unauthenticated remote attackers to crash the rpc-server by sending oversized message lengths after the HELLO handshake, causing a denial of service.
A Cross-Site Request Forgery (CSRF) vulnerability exists in the SABBATIC application. This flaw allows an attacker to trick an authenticated user into performing unauthorized actions by clicking a malicious link or loading a crafted page that sends requests to vulnerable endpoints without the user's consent. The vulnerability has a medium severity rating with a CVSS score of 4.8.
oapi-codegen versions from 2.5.0 up to but not including 2.8.1 contain a code injection vulnerability. This flaw allows attackers who control an OpenAPI document to inject arbitrary Go code via a crafted servers[].x-go-name value. The injected code executes when the victim builds and imports the generated package, potentially leading to full compromise of confidentiality, integrity, and availability.
A hard-coded cryptographic key vulnerability has been identified in HBS 3 Hybrid Backup Sync and Hybrid Backup Sync products. This flaw could allow remote attackers to compromise system security. The issue has been fixed in versions 26.4.0.521 and later for both products.
xianyu-auto-reply-fix versions through 2.0.7 have a missing authorization vulnerability in the POST /send-message endpoint. This flaw allows unauthenticated attackers to send messages on behalf of other users by exploiting publicly known default API secrets. Attackers can use a hard-coded api_key along with another user's cookie_id and chosen message parameters to send arbitrary messages from that merchant account.
Crass, a CSS tokenizer, incorrectly handles bad URL tokens when a closing parenthesis follows an escaped backslash, causing it to consume more input than browsers do. This flaw can cause CSS sanitizers that rely on Crass to mistakenly allow malicious CSS declarations, style rules, or at-rules such as @import to pass through. The vulnerability affects CSS sanitizers like Sanitize, Loofah, and rails-html-sanitizer, enabling attackers to smuggle CSS that can be used for UI redress, loading attacker-controlled resources, or CSS-based data exfiltration. The issue does not enable script execution in modern browsers. The vulnerability is fixed in Crass version 1.0.8.
A vulnerability in wasmtime-wasi in Wasmtime versions before 36.0.18, 37.0.0 before 48.0.6, and 49.0.0 before 49.0.3 causes a trailing slash to be re-appended to rename source paths. This behavior leads to the renameat system call on macOS and FreeBSD hosts following directory symbolic links. Consequently, a guest with sandbox write access can rename a relative symlink such as "up/" to move host directories into its sandbox, enabling unauthorized read or write access to those directories.
A deserialization vulnerability in seroval versions prior to 1.6.8 allows attacker-controlled callables to be invoked during deserialization. This occurs because the fromJSON function calls on() on the source of an async iterator without verifying that the source is a legitimate seroval stream. Crafted payloads can exploit this to invoke arbitrary plugin functions during deserialization. The issue is fixed in version 1.6.8 by enforcing instanceof checks on source values.
A race condition vulnerability in filelock versions 3.30.0 through 4.2.0 allows a local unprivileged user to swap a symbolic link at the <path>.filelock directory after an lstat check but before subsequent operations. This can cause the lock user's process to create claim files in an attacker-chosen directory, potentially disrupting other locks by causing stranded claims that lead to denial of service until manually force-broken. The vulnerability requires write access to the directory containing <path>.filelock and is mitigated by patch 4.2.1.
## Summary
When `echo.New()` is used without explicitly setting `Echo#IPExtractor`, the `RealIP()` method falls back to reading the client-supplied `X-Forwarded-For` (or `X-Real-IP`) header without any proxy-origin validation. The default `RateLimiter()` middleware derives its per-client identifier from `ctx.RealIP()`, so an attacker can rotate arbitrary values in the `X-Forwarded-For` header on each request to obtain a fresh rate-limit bucket and bypass IP-based throttling entirely.
## Affected Component
- `context.go` — `(*Context).RealIP()` (lines 186–208), legacy fallback branch (lines 190–200)
- `middleware/rate_limiter.go` — `DefaultRateLimiterConfig.IdentifierExtractor` (lines 46–58); `RateLimiter()` (lines 71–76)
- `echo.go` — `New()` (lines 326–343), `IPExtractor` left `nil` by default
## Description
### `RealIP()` unconditionally trusts `X-Forwarded-For` when `IPExtractor` is unset
`Context.RealIP()` (`context.go:186-208`) first checks `c.echo.IPExtractor`. When this field is `nil` (the default for `echo.New()`), it falls through to legacy behavior and returns the **first IP** from the `X-Forwarded-For` header — the position an attacker has full control over:
```go
// context.go:186-200
func (c *Context) RealIP() string {
if c.echo != nil && c.echo.IPExtractor != nil {
return c.echo.IPExtractor(c.request)
}
// Fall back to legacy behavior
if ip := c.request.Header.Get(HeaderXForwardedFor); ip != "" {
i := strings.IndexAny(ip, ",")
if i > 0 {
xffip := strings.TrimSpace(ip[:i])
xffip = strings.TrimPrefix(xffip, "[")
xffip = strings.TrimSuffix(xffip, "]")
return xffip // ← attacker-controlled first IP
}
return ip
}
if ip := c.request.Header.Get(HeaderXRealIP); ip != "" {
...
return ip // ← also attacker-controlled
}
ra, _, _ := net.SplitHostPort(c.request.RemoteAddr)
return ra
}
```
### Rate limiter default identifier extractor calls `RealIP()` unconditionally
`DefaultRateLimiterConfig` (`rate_limiter.go:46-58`) sets the identifier extractor to `ctx.RealIP()` with no guard for whether a safe `IPExtractor` is configured:
```go
// rate_limiter.go:46-58
var DefaultRateLimiterConfig = RateLimiterConfig{
Skipper: DefaultSkipper,
IdentifierExtractor: func(ctx *echo.Context) (string, error) {
id := ctx.RealIP() // ← reads attacker-controlled header
return id, nil
},
...
}
```
`RateLimiter(store)` (`rate_limiter.go:71-76`) copies `DefaultRateLimiterConfig` directly:
```go
// rate_limiter.go:71-76
func RateLimiter(store RateLimiterStore) echo.MiddlewareFunc {
config := DefaultRateLimiterConfig
config.Store = store
return RateLimiterWithConfig(config)
}
```
The result is that the most common usage pattern — `e.GET("/path", h, middleware.RateLimiter(store))` — produces a rate limiter whose per-client identifier is fully controlled by the requester.
### Framework acknowledges the issue for IP extraction but the rate limiter carries no warning
`ip.go:27` explicitly states the default is insecure:
> "Note: if you don't set `Echo#IPExtractor` explicitly, Echo fallback to legacy behavior, which is not a good choice."
And `ip.go:117-119`:
> "In default behavior, Echo sees all of first XFF header, X-Real-IP header and IP from network layer. As you might already notice, after reading this article, this is not good. Sole reason this is default is just backward compatibility."
The `IPExtractor` mechanism (`ExtractIPDirect()`, `ExtractIPFromXFFHeader()`, `ExtractIPFromRealIPHeader()`) in `ip.go` exists precisely to close this gap. However, the `RateLimiter()` function and `DefaultRateLimiterConfig` have **no corresponding warning** and make no attempt to detect or flag that `IPExtractor` is unset, leaving operators who follow the standard rate limiter example silently exposed.
The test `TestRateLimiterWithConfig_defaultConfig` (`rate_limiter_test.go:181-226`) itself drives the rate limiter by setting `X-Real-IP` directly on the test request — demonstrating that the identifier is freely injectable without comment or mitigation.
### Full execution chain
1. Server starts with `echo.New()` (no `IPExtractor` set) and `e.GET("/limited", h, middleware.RateLimiter(store))`
2. Attacker sends `GET /limited` with header `X-Forwarded-For: 1.2.3.4` — rate bucket for `1.2.3.4` consumed
3. Attacker sends `GET /limited` again with `X-Forwarded-For: 1.2.3.4` — second token consumed; if burst is 1, next request would be 429
4. Attacker sends `GET /limited` with `X-Forwarded-For: 5.6.7.8` — **new bucket created** for `5.6.7.8`, 200 OK returned
5. Attacker repeats step 4 with arbitrary IPs — rate limit never triggers; unlimited requests served
## Proof of Concept
```go
package main
import (
"net/http"
echo "github.com/labstack/echo/v5"
"github.com/labstack/echo/v5/middleware"
)
func main() {
e := echo.New()
## Summary
The Echo proxy middleware (`middleware/proxy.go`) preserves an incoming `X-Real-IP` header verbatim and forwards it to the upstream service when `Echo#IPExtractor` is not configured — which is the default. Because any HTTP client can supply an arbitrary `X-Real-IP` value, an attacker can cause Echo to relay a spoofed client IP address to every upstream service behind the proxy, undermining upstream IP-based access controls, rate limiting, audit logging, and geo-restriction.
## Affected Component
- `middleware/proxy.go` — `ProxyConfig.ToMiddleware()`, header-rewriting block (lines 351–355)
## Description
### The header-preservation condition passes spoofed values to upstream
`ProxyConfig.ToMiddleware()` (`proxy.go:338-405`) prepares forwarding headers before dispatching each request. The `X-Real-IP` rewrite logic at lines 351-355 reads:
```go
// proxy.go:351-355
// Basically it's not good practice to unconditionally pass incoming x-real-ip header to upstream.
// However, for backward compatibility, legacy behavior is preserved unless you configure Echo#IPExtractor.
if req.Header.Get(echo.HeaderXRealIP) == "" || c.Echo().IPExtractor != nil {
req.Header.Set(echo.HeaderXRealIP, c.RealIP())
}
```
The condition is `TRUE` (and therefore overwrites the header with a derived value) only when:
- The header is absent — `req.Header.Get(echo.HeaderXRealIP) == ""`; **or**
- `IPExtractor` is explicitly configured — `c.Echo().IPExtractor != nil`
The condition is `FALSE` — and the header is left **unchanged** — when the request arrives with an `X-Real-IP` header already set **and** `IPExtractor` is `nil`. Because `Echo.New()` leaves `IPExtractor` as `nil`, this is the out-of-the-box behaviour for every application that uses `Proxy()` or `ProxyWithConfig()` without extra configuration.
An attacker who sets `X-Real-IP` to any value causes Echo to forward exactly that value to the upstream, with no modification or validation.
### The comment in the source code confirms intent and the security gap
The inline comment at line 351-352 explicitly states:
> "Basically it's not good practice to unconditionally pass incoming x-real-ip header to upstream. However, for backward compatibility, legacy behavior is preserved unless you configure Echo#IPExtractor."
The framework is aware that the default is insecure and retains it for backward compatibility. No warning appears in the `Proxy()` or `ProxyWithConfig()` documentation, so operators who follow the standard setup example receive a silently insecure proxy configuration.
This is structurally identical to the documented insecurity in `ip.go:27`:
> "Note: if you don't set `Echo#IPExtractor` explicitly, Echo fallback to legacy behavior, which is not a good choice."
### Full execution chain
1. Attacker sends `GET /api/admin` to the Echo proxy with header `X-Real-IP: 203.0.113.1` (a trusted corporate IP)
2. `ToMiddleware()` evaluates the guard at line 353: header is present (`!= ""`), `IPExtractor` is `nil` → condition is `FALSE`
3. `req.Header.Set` is **not** called; the upstream request carries the original, attacker-supplied `X-Real-IP: 203.0.113.1`
4. Upstream service checks `X-Real-IP` against its IP allowlist → finds `203.0.113.1` → grants access
5. Attacker reaches an endpoint that should be restricted to the corporate IP range
Secondary impact path (audit poisoning):
- All upstream log entries, rate-limit counters, and geo-restriction checks are evaluated against `203.0.113.1` rather than the real client IP, rendering audit trails and security analytics unreliable.
## Proof of Concept
```go
package main
import (
"fmt"
"log"
"net/http"
echo "github.com/labstack/echo/v5"
"github.com/labstack/echo/v5/middleware"
)
func main() {
// Upstream server: echoes back the X-Real-IP it received
upstream := http.NewServeMux()
upstream.HandleFunc("/", func(w http.ResponseWriter, r *http.Request) {
fmt.Fprintf(w, "upstream sees X-Real-IP: %s\n", r.Header.Get("X-Real-IP"))
})
go http.ListenAndServe(":9000", upstream)
// Echo proxy — IPExtractor deliberately NOT set (the default)
e := echo.New()
targets := []*middleware.ProxyTarget{{URL: mustParse("http://127.0.0.1:9000")}}
e.Use(middleware.Proxy(middleware.NewRoundRobinBalancer(targets)))
log.Fatal(e.Start(":1323"))
}
```
```bash
# Without spoofed header — upstream sees actual peer address
curl http://127.0.0.1:1323/
# upstream sees X-Real-IP: 127.0.0.1
# With spoofed header — upstream sees attacker-supplied value
curl -H 'X-Real-IP: 198.51.100.77' http://127.0.0.1:1323/
# upstream sees X-Real-IP: 198.51.100.77
```
The attacker-supplied IP `198.51.100.77` arrives at the upstream unchanged.
## Impact
- Upstream IP-based access controls (allowlists, blocklists, geo-restrictions) can be bypassed by supplying the expected IP in `X-Real-IP`
- Upstream rate limiters that key on `X-Real-IP` are bypassable (same class as the Echo rate-limiter fi
CVE-2026-118616 is a code injection vulnerability in the parse_model function of Ultralytics software. It allows remote attackers to execute arbitrary Python code by supplying a crafted string that is not properly validated before execution. Exploitation requires user interaction, such as visiting a malicious webpage or opening a malicious file. The vulnerability has a high severity with a CVSS score of 7.8.
A deserialization of untrusted data vulnerability exists in weDevs Dokan dokan-lite up to version 5.3.1. This flaw allows object injection, potentially leading to high impact on confidentiality, integrity, and availability. The vulnerability is identified as CVE-2026-115590 with a CVSS 3.1 score of 7.2, indicating a high severity. No patch or remediation information is currently provided.
A vulnerability in In Progress® Telerik® Document Processing Libraries prior to version 2026.3.1027 allows unauthenticated attackers to cause uncontrolled recursion, infinite loops, and inefficient resource allocation. This can lead to termination or hanging of the host process when processing crafted PDF documents or document text submitted for summarization or question answering.
Since July 2025, a financially motivated threat actor named CyberDakait has conducted a sophisticated Android malware campaign targeting India's financial services sector. The campaign uses seven distinct Android trojan families distributed via smishing and vishing, impersonating bank representatives to trick victims into installing malicious APKs. These trojans steal banking credentials, credit card details, and intercept SMS messages including OTPs through overlay attacks. Additionally, the malware performs cryptojacking using XMRig. The malicious apps are hosted on GitHub to appear legitimate, with initial droppers delivering the main payload and mining modules. At least 17,960 devices have been compromised with 7.6 million intercepted SMS messages reported.
Axel Download Accelerator versions 2.17.14 and earlier contain a directory traversal vulnerability due to improper URL percent-decoding of the output filename. This allows attackers to craft URLs with encoded sequences that traverse directories, causing the program to write downloaded files to arbitrary filesystem locations relative to the current working directory.
CVE-2026-99211 is a Linux kernel vulnerability involving netlink socket filters. The issue arises because netlink producers may reserve headroom in socket buffers (skbs) without resetting network and MAC headers, allowing filters to read uninitialized data. This can lead to information disclosure through the length of delivered replies. The vulnerability has been resolved by resetting skb headers before applying unicast and multicast filters.
