Export limit exceeded: 395610 CVEs match your query. Please refine your search to export 10,000 CVEs or fewer.
Search
Search Results (395610 CVEs found)
| CVE | Vendors | Products | Updated | CVSS v3.1 |
|---|---|---|---|---|
| CVE-2026-92963 | 1 Patriksimek | 1 Vm2 | 2026-09-18 | 5.3 Medium |
| vm2 versions before 3.11.2 fail to properly restrict access to the VM2_INTERNAL_STATE_DO_NOT_USE_OR_PROGRAM_WILL_FAIL global variable. Attackers can access this internal state object through globalThis to retrieve sensitive sandbox internals. | ||||
| CVE-2026-92958 | 1 Patriksimek | 1 Vm2 | 2026-09-18 | 8.5 High |
| vm2 through 3.11.6 contains a builtin-module denylist bypass in NodeVM. When the embedder uses the builtin wildcard together with negative entries (e.g. require: { builtin: ['*', '-fs', '-child_process'] }), negative entries are matched by exact module name in lib/builtin.js, so -fs removes only the builtin named fs and does not remove builtin subpaths such as fs/promises. Sandboxed code can therefore call require('fs/promises') or require('node:fs/promises') and reach the promise-based filesystem API despite fs being denied; node: prefix handling is likewise inconsistent (a -node:fs/promises entry does not block require('fs/promises')). Host file creation and writing were confirmed via fsp.writeFile(), and other fs/promises operations (cp, mkdir, rename, rm, rmdir, truncate, read operations, etc.) are also reachable. This issue is fixed in vm2 3.11.7. | ||||
| CVE-2026-92953 | 1 Patriksimek | 1 Vm2 | 2026-09-18 | 10 Critical |
| vm2 versions from 3.11.0 before 3.11.8 fail to protect host TypedArray and ArrayBuffer prototypes from sandbox mutation. Attackers can use prototype-walking primitives to reach and modify host Uint8Array.prototype, %TypedArray%.prototype, and ArrayBuffer.prototype, causing host-created typed arrays to observe attacker-controlled properties after VM.run() returns. | ||||
| CVE-2026-92948 | 1 Patriksimek | 1 Vm2 | 2026-09-18 | 9.9 Critical |
| vm2 versions >= 3.9.6 and <= 3.11.6 are affected by a NodeVM builtin allowlist bypass that permits a sandbox escape on Node.js 24 and newer when the embedder explicitly allows the node:test builtin (e.g. require: { builtin: ['node:test'] }). On Node.js 24+, module.builtinModules exposes the scheme-only key node:test, which is not covered by vm2's family-based DANGEROUS_BUILTINS protection, so it is stored in the generic host-passthrough loader. Because requireImpl() in lib/setup-node-sandbox.js strips a single 'node:' prefix before the builtin lookup, sandbox code calling require('node:node:test') resolves to the stored node:test key and receives a readonly proxy to the host module. Calls to node:test.run() are forwarded to the host implementation, which spawns a separate Node process for process-isolated test execution and passes through attacker-controlled execArgv values; supplying --eval=<JavaScript> therefore executes arbitrary JavaScript in an unrestricted host Node process outside the NodeVM sandbox. Fixed in vm2 3.11.7. | ||||
| CVE-2026-92942 | 1 Patriksimek | 1 Vm2 | 2026-09-18 | 7.5 High |
| vm2 before 3.11.7 (affected versions <= 3.11.6) does not enforce the VM({ timeout }) option on code executed outside the synchronous VM#run() call. The timeout only wraps the single call to _runScript() via doWithTimeout() in lib/vm.js, and FinalizationRegistry and WeakRef are exposed to sandboxed code unmodified (they are not among the hardened globals in lib/setup-sandbox.js). Sandboxed code can register a FinalizationRegistry cleanup callback against an object and then drop the only strong reference to it; vm.run() returns within the configured timeout, but when the V8 garbage collector later reclaims the object it invokes the sandboxed cleanup callback outside any vm2 timeout accounting. A busy loop in that callback blocks the host event loop for an unbounded period, resulting in denial of service. The time of invocation depends on the garbage collector (e.g. under memory pressure or with --expose-gc). | ||||
| CVE-2026-92937 | 1 Patriksimek | 1 Vm2 | 2026-09-18 | 10 Critical |
| vm2 3.11.6 is vulnerable to a sandbox escape leading to remote code execution in the host Node.js process. The fix for GHSA-m283-3h24-438v is incomplete: the bridge gate at lib/bridge.js:1624 identity-checks only the direct call target when deciding whether to rebuild/sanitise a rejected host Promise value. Registering the rejection handler through Function.prototype.call or .apply indirection (e.g., p.then.call(p, undefined, cb)) makes the intercepted target host Function.prototype.call, so the sanitiser never runs and the raw host error reaches sandbox code with its own properties intact. If an embedder exposes a host-realm Promise to the sandbox (an async host function bridged via the sandbox option, or a NodeVM external module's async method) and that Promise rejects with an Error carrying a non-primitive own property referencing a host object (for example err.detail = process), untrusted code in the sandbox obtains a fully functional proxy to that host object and can execute arbitrary commands with the privileges of the host process (e.g., e.detail.mainModule.require('child_process').execSync(...)). The direct p.then(undefined, cb), bind, and Reflect.apply forms are correctly sanitised. Fixed in vm2 3.11.7. | ||||
| CVE-2026-92921 | 1 Cjbi | 1 Admin3 | 2026-09-18 | 4.9 Medium |
| admin3 through 3.0.0 stores account passwords using single-round MD5 with only the username as salt and no key derivation function. Attackers with database access can recover plaintext passwords through offline dictionary or brute-force attacks due to negligible computational effort. | ||||
| CVE-2026-92916 | 1 Getgrav | 1 Grav | 2026-09-18 | 7.5 High |
| Grav is a flat-file CMS. In Grav 1.7.0 through 1.7.53.2 and 2.0.0 through 2.0.21, when the debugger is enabled (system.debugger.enabled: true, which is not the default), the Clockwork profiler endpoint is exposed without authentication: InitializeProcessor::handleDebuggerRequest() intercepts any path containing /__clockwork/ during bootstrap and passes it to Debugger::debuggerRequest(), which performs no user lookup, IP restriction, or Clockwork authenticator check, and also supports anonymous pagination over the entire stored history. With the shipped censored: false default, each stored record contains raw request cookies (including Grav's session cookie, whose value is the PHP session id, allowing an attacker to resume another user's session, including an authenticated admin's), the full parsed request body (Grav's login form posts data[username]/data[password], so passwords are stored in plaintext because Clockwork's password filter only inspects top-level keys), and the site's entire system and plugin configuration, including operator-saved secrets such as SMTP credentials, third-party API keys, and licence keys. Authorization and X-API-Token headers are stored even when censored: true. On Grav 2.0, setting provider: debugbar does not avoid the issue because Grav forces the Clockwork provider for requests preferring a JSON response. The issue is fixed in 1.7.53.4 and 2.0.22, which restrict /__clockwork/ to server-local requests or requests presenting the new system.debugger.token secret and strip cookies and credential headers from stored records. Workarounds include setting debugger.enabled: false or blocking /__clockwork/ at the web server or CDN. | ||||
| CVE-2026-92708 | 2026-09-18 | 7.5 High | ||
| Svelte devalue is a JavaScript library that serializes values into strings when JSON.stringify isn't sufficient for the job. In versions 5.1.0 through 5.9.2, stringify and uneval functions serialize a typed array by emitting its entire backing ArrayBuffer rather than only the view, so serializing a Node Buffer, whose backing store is a process-wide shared pool, discloses up to 64 KB of unrelated process memory, including bytes from other in-flight requests. In a server-side-rendered framework such as SvelteKit or Nuxt, a public page whose load() returns a small Buffer, or that reads a small file, can therefore ship another user's request body or Authorization header in its HTML without authentication. Because this occurs during serialization, it fires on every such render and is not mitigated by the parse/unflatten prototype-pollution and denial-of-service guards, which only apply when parsing untrusted input. As a workaround, convert Node Buffer objects to Uint8Array before serialization. This issue has been fixed in version 5.9.3. | ||||
| CVE-2026-92701 | 2026-09-18 | 9.1 Critical | ||
| trusted execution environments. In versions up to and including 0.8.2, the intra-handshake attested TLS (aTLS) Intel TDX verification path does not copy the expected current-session freshness value into the TDX quote-body policy before quote validation, so structurally valid TDX QuoteV4 Evidence is accepted without checking that its REPORT_DATA field matches the reportData expected for the current session. A relying party using this path can therefore accept Evidence with a mismatched or reused reportData and release application data after the handshake, enabling session-misbinding to an unintended attestation context. The issue is fixed in version 0.9.0. | ||||
| CVE-2026-92622 | 2026-09-18 | 6.4 Medium | ||
| The Strong Testimonials plugin for WordPress is vulnerable to Stored Cross-Site Scripting via 'lightbox_class' Shortcode Attribute in all versions up to, and including, 3.3.8 due to insufficient input sanitization and output escaping. This makes it possible for authenticated attackers, with contributor-level access and above, to inject arbitrary web scripts in pages that will execute whenever a user accesses an injected page. Exploitation requires that the targeted testimonial view has at least one published testimonial with a featured image and the lightbox wrapper enabled, as the vulnerable code path is only reached when a thumbnail is rendered. | ||||
| CVE-2026-92599 | 1 Hapijs | 1 Joi | 2026-09-18 | 7.5 High |
| joi (npm package `joi`, hapi.js) versions >=17.2.0 <17.13.7 and >=18.0.0 <18.2.6 are vulnerable to regular expression denial of service in the `Joi.string().isoDate()` validation rule. One of the regular expressions the rule applies to the input is unanchored, so a valid ISO date followed by a long run of fractional-second digits causes the regex engine to restart its search from every position in the string, yielding time proportional to the square of the input length (about 1.4 s for 64 KB of digits and about 22 s for 256 KB). A remote attacker who can supply a string to an isoDate validation can stall the application with a single request. Fixed in 17.13.7 and 18.2.6; as a workaround, cap the length of the string before it reaches joi. | ||||
| CVE-2026-92594 | 1 Craftcms | 1 Craft Cms | 2026-09-18 | 7.5 High |
| Craft CMS 5.0.0-RC1 through versions before 5.11.0 incorrectly authorize the GraphQL draftCreator and revisionCreator fields: instead of requiring the user-data scope enforced by Gql::canQueryUsers() (usergroups.*:read), these fields are gated only on the elements.drafts:read / elements.revisions:read scopes, and their resolver returns a raw User element whose email, username, fullName, and addresses fields have no per-field authorization. A client holding only the drafts or revisions scope — including an unauthenticated client when the operator has enabled the public GraphQL schema with those scopes — can therefore harvest the email addresses, usernames, full names, and postal addresses of all draft/revision creators (typically site editors and administrators). The issue is fixed in 5.11.0. | ||||
| CVE-2026-91202 | 1 Redhat | 1 Enterprise Linux | 2026-09-18 | 6.1 Medium |
| A flaw was found in cockpit-files. A low-privileged local user can exploit this vulnerability by crafting a directory containing a symbolic link (symlink) and then using the privileged "Paste as owner" function. This allows for arbitrary file ownership changes outside the intended pasted directory, leading to a compromise of data integrity. In some cases, this could also lead to reduced confidentiality if the new ownership grants unauthorized read access. Exploitation requires user interaction to select a non-original owner during the paste operation. | ||||
| CVE-2026-84241 | 1 Ibm | 1 Guardium Data Protection | 2026-09-18 | 8.1 High |
| IBM Guardium Data Protection 12.2 could allow a remote attacker to bypass security restrictions due to improper authorization. | ||||
| CVE-2026-84239 | 1 Ibm | 1 Guardium Data Protection | 2026-09-18 | 7.6 High |
| IBM Guardium Data Protection 12.2 could allow a remote authenticated attacker to obtain sensitive information due to improper neutralization of special elements used in an SQL command. | ||||
| CVE-2026-84108 | 1 Ibm | 1 Guardium Data Protection | 2026-09-18 | 8.1 High |
| IBM Guardium Data Protection 12.2 could allow a remote attacker to execute arbitrary code due to improper neutralization of input during web page generation. | ||||
| CVE-2026-84105 | 1 Ibm | 1 Guardium Data Protection | 2026-09-18 | 7.7 High |
| IBM Guardium Data Protection 12.2 could allow a remote authenticated attacker to obtain sensitive information due to improper neutralization of special elements used in an SQL command. | ||||
| CVE-2026-84089 | 1 Ibm | 1 Guardium Data Protection | 2026-09-18 | 7.8 High |
| IBM Guardium Data Protection 12.2 could allow a local attacker to gain elevated privileges due to improper privilege management. | ||||
| CVE-2026-84086 | 1 Ibm | 1 Guardium Data Protection | 2026-09-18 | 7.2 High |
| IBM Guardium Data Protection 12.2 could allow a remote authenticated attacker to execute arbitrary code due to improper limitation of a pathname to a restricted directory. | ||||