Vulnerabilities
All
My stack
Known exploited
Public exploit
Critical (9+)
Likely exploited (EPSS ≥ 50%)
Changed, 24 h
New, 24 h
Sort:
risk
modified
published
CVSS
EPSS
| CVE | CVSS | EPSS | Vendor, product | Description | Modified |
|---|---|---|---|---|---|
| CVE-2025-64766 | 5.3 medium | 0.00% | no CPE yet | NixOS's Onlyoffice is a software suite that offers online and offline tools for document editing, collaboration, and management. In versions from 22.11 to before 25.05 and versions before Unstable 25.11, a hard-coded secret was used in the NixOS module for the OnlyOffice document server to protect its file cache. An attacker with knowledge of an existing revision ID could use this secret to obtain a document. In practice, an arbitrary revision ID should be hard to obtain. The primary impact is likely the access to known documents from users with expired access. This issue was resolved in NixOS unstable version 25.11 and version 25.05. | 18 Oct |
| CVE-2026-110254 | 5.3 medium | 0.00% | no CPE yet | Finsys Dockhand before 1.0.45 contains a server-side request forgery vulnerability in the ipCategory() function in src/lib/server/url-safety.ts, which fails to check NAT64, 6to4, and Teredo IPv6 transition ranges. Authenticated attackers can embed loopback, cloud metadata, or private IPv4 addresses in transition IPv6 literals within notification, backup, template, registry, git, or secret provider URLs to reach internal services. | 14 Oct |
| CVE-2025-11760 | 5.3 medium | 0.00% | no CPE yet | The eRoom – Webinar & Meeting Plugin for Zoom, Google Meet, Microsoft Teams plugin for WordPress is vulnerable to exposure of sensitive information in all versions up to, and including, 1.5.6. This is due to the plugin exposing Zoom SDK secret keys in client-side JavaScript within the meeting view template. This makes it possible for unauthenticated attackers to extract the sdk_secret value, which should remain server-side, compromising the security of the Zoom integration and allowing attackers to generate valid JWT signatures for unauthorized meeting access. | 8 Oct |
| CVE-2026-75805 | 5.3 medium | 0.00% | openssl | Issue summary: A CMP client that requests certificate revocation on the basis of a PKCS#10 CSR may dereference a NULL pointer and terminate abnormally when processing a crafted revocation response. Impact summary: The NULL pointer dereference happens on a read which leads to a crash and a Denial of Service for the affected client application. CWE: CWE-476: NULL-pointer dereference Description: A CMP client revoking a certificate has to tell the server which certificate to revoke, and may do so by supplying a PKCS#10 CSR instead of the certificate itself or its issuer name and serial number. This is 'openssl cmp -cmd rr -csr <file>' on the command line, or OSSL_CMP_exec_RR_ses() with the certificate supplied via OSSL_CMP_CTX_set1_p10CSR() through the API. A CSR does not contain the issuer name and serial number of the certificate, so the client does not send them. A server may optionally name the certificate it revoked in its response, and the client then compares that name against what it sent. Having sent neither an issuer name nor a serial number, it has nothing to compare against, and a server returning a specially crafted name causes the client to read from a NULL pointer and crash. The revocation response is checked for valid message protection before the affected code is reached, so an attacker must be a malicious or compromised CMP server, or a man-in-the-middle in possession of the secret used for message protection. Clients that identify the certificate to be revoked by a certificate or by issuer and serial number rather than by a PKCS#10 CSR are not affected. FIPS impact: no No FIPS modules are affected by this issue, as the CMP protocol implementation is outside the OpenSSL FIPS module boundary. | 8 Oct |
| CVE-2026-115828 | 5.1 medium | — | delinea, secret server | In Secret Server versions earlier than 12.3.1, Secret Server did not always validate the PIN or biometric check when using a FIDO2-compliant device | 22 h ago |
| CVE-2025-43777 | 5.1 medium | 0.00% | liferay, digital_experience_platform, liferay_portal | Liferay Portal 7.4.0 through 7.4.3.132, and Liferay DXP 2025.Q2.0 through 2025.Q2.9, 2025.Q1.0 through 2025.Q1.16, 2024.Q4.0 through 2024.Q4.7, 2024.Q3.0 through 2024.Q3.13, 2024.Q2.0 through 2024.Q2.13 and 2024.Q1.1 through 2024.Q1.19 exposes "Internal Server Error" in the response body when a login attempt is made with a deleted Client Secret. | 18 Oct |
| CVE-2024-8995 | 4.9 medium | 0.00% | wso2, api_control_plane, api_manager, identity_server | Unused authorization codes issued to deleted users are not being properly invalidated or removed from the system. This allows for the persistence of these codes, enabling them to be potentially reused. If an attacker possesses both the authorization code and the associated client credentials (client ID and client secret), they can leverage these unused codes to obtain access tokens on behalf of users who have already been deleted. This may lead to unauthorized access to sensitive resources and services, contingent on the scopes originally authorized for the compromised authorization code. | Tue 27 Oct |
| CVE-2026-57218 | 4.9 medium | 0.00% | broadcom, rabbitmq_server | RabbitMQ is a messaging and streaming broker. Prior to 4.2.6, RabbitMQ AMQP 0-9-1 allows an existing consumer to keep receiving messages after OAuth token expiry or connection.update_secret refresh to reduced scopes because existing consumers are not canceled or reauthorized at delivery time after the channel user state changes. This issue is fixed in version 4.2.6. | Sun 25 Oct |
| CVE-2026-119201 | 4.8 medium | 0.00% | nuxt | Nuxt is an open-source web development framework for Vue.js. From 4.6.0 until 4.6.3, nuxt dev stores a generated appSecret in <buildDir>/app-secret, by default .nuxt/app-secret, within a directory allowed by Vite's server.fs configuration. A client with direct HTTP access to an exposed development server can fetch the file, use deriveSecret() to compute derived secrets such as the default useSession password, and forge session cookies accepted by that development server. The default localhost binding limits remote exposure, cross-origin browser reads are blocked, production builds and development servers with an explicitly configured appSecret are not affected. This issue is fixed in version 4.6.3. | Fri 30 Oct |
| CVE-2026-117472 | 4.3 medium | 0.00% | no CPE yet | Psono Server CE && EE versions 4.0.33 through 7.2.3 compared the request path for the bulk-secret-read endpoint with a hard-coded unprefixed path. In deployments configured with URL_PREFIX, the comparison failed and the POST request was authorized using write scope instead of read scope. An authenticated remote attacker with an unusual read-disabled, write-enabled API key could therefore retrieve encrypted secret data and nonces through the prefixed bulk-secret-read endpoint despite lacking read permission. The default configuration without URL_PREFIX was not affected. | Tue 27 Oct |
| CVE-2026-42282 | 4.3 medium | 0.00% | n8n-mcp | n8n-MCP is an MCP server that provides AI assistants access to n8n node documentation, properties, and operations. Prior to version 2.47.13, when n8n-mcp runs in HTTP transport mode, authenticated MCP tools/call requests had their full arguments and JSON-RPC params written to server logs by the request dispatcher and several sibling code paths before any redaction. When a tool call carries credential material — most notably n8n_manage_credentials.data — the raw values can be persisted in logs. In deployments where logs are collected, forwarded to external systems, or viewable outside the request trust boundary (shared log storage, SIEM pipelines, support/ops access), this can result in disclosure of: bearer tokens and OAuth credentials sent through n8n_manage_credentials, per-tenant API keys and webhook auth headers embedded in tool arguments, arbitrary secret-bearing payloads passed to any MCP tool. The issue requires authentication (AUTH_TOKEN accepted by the server), so unauthenticated callers cannot trigger it; the runtime exposure is also reduced by an existing console-silencing layer in HTTP mode, but that layer is fragile and the values are still constructed and passed into the logger. This issue has been patched in version 2.47.13. | Mon 26 Oct |
| CVE-2026-8407 | 4.3 medium | 0.00% | devolutions, devolutions_server | Missing authorization in the PAM module in Devolutions Server allows an authenticated user with a PAM license but no additional permissions to obtain OTP secret keys and recovery codes via crafted requests to PAM API endpoints. This issue affects the following versions : * Devolutions Server 2026.1.6.0 through 2026.1.11.0 * Devolutions Server 2025.3.16.0 and earlier | Mon 26 Oct |
| CVE-2026-56269 | 4.3 medium | 0.00% | flowiseai, flowise | Flowise before 3.1.0 (npm package flowise, versions 3.0.13 and earlier) uses a weak hardcoded default value 'Secre$t' for the TOKEN_HASH_SECRET environment variable in packages/server/src/enterprise/utils/tempTokenUtils.ts when the variable is not configured. This secret derives the AES-256-CBC key used to encrypt user IDs and workspace IDs in the 'meta' field of JWT tokens. An attacker who knows the default secret can decrypt this metadata to extract internal user and workspace identifiers, and re-encrypt manipulated values such as altered user or workspace IDs. Because the JWT signature is validated separately, decrypting or tampering with this metadata does not by itself grant access, but the disclosure of internal identifiers and possible metadata manipulation could aid privilege escalation or unauthorized data access. | Sun 25 Oct |
| CVE-2026-46700 | 4.3 medium | 0.00% | no CPE yet | Actual is a local-first personal finance tool. Prior to 26.6.0, the GET /secret/:name endpoint in @actual-app/sync-server checks only that the caller has a valid session and does not verify the caller is an admin, while the sibling POST /secret/ handler enforces an admin check in OpenID mode. Any authenticated non-admin BASIC user in OpenID multi-user deployments can probe the secrets store and learn which admin-managed bank-sync integrations have been configured, including simplefin_accessKey, pluggyai_clientSecret, pluggyai_itemIds, and the gocardless secrets. This issue is fixed in version 26.6.0. | Sun 25 Oct |
| CVE-2026-63640 | 4.3 medium | 0.00% | no CPE yet | MagicMirror² is an open source modular smart mirror platform. Prior to 2.37.0, when hideConfigSecrets is enabled, the catch-all socket dispatcher in js/node_helper.js passes every inbound object payload through replaceSecretPlaceholder in js/server_functions.js before invoking socketNotificationReceived. A client connected to a loaded module namespace can submit a SECRET_API_KEY placeholder, causing the server to replace it with the corresponding process environment value. The default weather helper accepts INIT_WEATHER, copies the attacker-controlled instanceId, and returns it in WEATHER_ERROR, providing an echo path for the expanded secret. This reverses the intended one-way redaction boundary and can disclose API tokens, credentials, or service keys stored in SECRET_ variables. This issue is fixed in version 2.37.0. | 22 Oct |
| CVE-2026-55875 | 4.3 medium | 0.00% | no CPE yet | Helium is a free online student planner for classes, homework, grades, and notes. Prior to 2.2.60, any authenticated user can submit an arbitrary URL to POST /feed/externalcalendars/, where helium/feed/services/icalexternalcalendarservice.py uses validate_url to check only URL syntax before passing the value to urllib.request.urlopen, and fetch_ical_conditional periodically refetches the stored URL. The server can therefore issue requests to attacker-selected external or internal hosts, while distinct responses, including an uncaught http.client.RemoteDisconnected condition for non-HTTP services, reveal internal host and port reachability. The supported impact is forced outbound requests and internal service reconnaissance; the advisory does not demonstrate secret retrieval because the relevant ECS credentials path is task-specific and unpredictable. This issue is fixed in version 2.2.60. | 16 Oct |
| CVE-2026-15642 | 3.3 low | 0.00% | devolutions, devolutions_server | Insertion of sensitive information into a file in the Recovery Kit response file generation feature in Devolutions Server 2026.1.22.0, 2026.2.11.0 allows an attacker with access to the generated response file to obtain the Azure Key Vault client secret in cleartext, even when the option to exclude sensitive data is selected. | Sat 24 Oct |
| CVE-2025-56558 | 3.0 low | 0.00% | no CPE yet | The Dyson MQTT server (2022 and possibly later) allows publications and subscriptions by a client that has the correct values of AWS_ACCESS_KEY_ID, AWS_SECRET_ACCESS_KEY, AWS_SESSION_TOKEN, and device serial number, even if a device (such as a Pure Hot+Cool device) has been removed and is not visible in the supported MyDyson app. This could allow an unexpected actor to obtain control and set the room temperature (up to 37 Celsius) if ownership of the device is transferred without wiping the device. NOTE: the Supplier's position is that this is a potential vulnerability that dates back 4 years ago in 2022 and "we are unable to replicate that anymore." Based on the submitted report, in order to leverage this issue, an attacker needs to own a Dyson device with full privileges, sniff for the AWS credentials, and then transfer ownership of that Dyson device to the victim. Even if these steps were successfully accomplished, the attacker only acquires the ability to configure the Dyson device within its safe operating range, and does not acquire the ability to execute code on the device or obtain sensitive information. | 8 Oct |
| CVE-2026-110805 | 2.6 low | 0.00% | devolutions, devolutions_server | Server-side request forgery in PingOne groups endpoint in Devolutions Server 2026.3.8.0 and earlier allows an authenticated low-privileged user to exfiltrate the stored PingOne application secret via an attacker-controlled PingOne configuration in the request parameter. | 23 Oct |
| CVE-2026-62236 | 2.3 low | 0.00% | no CPE yet | grav-plugin-login before 3.8.11 contains a cross-site request forgery (CSRF) vulnerability in the login.regenerate2FASecret frontend task, which regenerates and persists a new TOTP secret for the authenticated session user without any anti-CSRF nonce or Origin/Referer check. Because Grav core dispatches the task from the GET 'task:' URI parameter and the default session cookie is SameSite=Lax, an attacker can lure a logged-in victim to an off-site page that performs a top-level GET navigation, rotating the victim's TOTP secret so their enrolled authenticator no longer matches the server, effectively forcing 2FA re-enrollment. Sites configured with session.samesite: Strict are not affected. | Sat 24 Oct |
| CVE-2025-43792 | 2.3 low | 0.00% | liferay, digital_experience_platform, liferay_portal | Remote staging in Liferay Portal 7.4.0 through 7.4.3.105, and older unsupported versions, and Liferay DXP 2023.Q4.0, 2023.Q3.1 through 2023.Q3.4, 7.4 GA through update 92, 7.3 GA through update 35, and older unsupported versions does not properly obtain the remote address of the live site from the database which, which allows remote authenticated users to exfiltrate data to an attacker controlled server (i.e., a fake “live site”) via the _com_liferay_exportimport_web_portlet_ExportImportPortlet_remoteAddress and _com_liferay_exportimport_web_portlet_ExportImportPortlet_remotePort parameters. To successfully exploit this vulnerability, an attacker must also successfully obtain the staging server’s shared secret and add the attacker controlled server to the staging server’s whitelist. | 18 Oct |
121 of 121 · Previous
Download these 121 as CSV · subscribe to this list.
EPSS scores: 2026-10-30. NVD cursor: 2026-10-29 00:22. The News page shows only notable CVEs (KEV, your stack, new criticals, EPSS over 50%, or active exploitation per SSVC); this table has all of them.