Hashicorp

Cross-Site Request Forgery in the Two-factor Authentication (formerly IP Vault) WordPress plugin versions up to and including 2.1 enables unauthenticated remote attackers to manipulate the plugin's firewall rules and 2FA configuration - potentially disabling protection entirely - by inducing an authenticated site administrator to click a crafted link. The vulnerable surface is the `ipv_save_changes` function in `admin-settings.php`, which lacks proper nonce validation. No public exploit has been identified at time of analysis, and EPSS at 0.02% (6th percentile) reflects very low automated exploitation probability, though the downstream security impact of silently disabling 2FA or firewall rules is disproportionate to the raw CVSS score of 4.3.

Improper access control in the entry documentation and attachment features in Devolutions Server allows an authenticated user with vault read access to retrieve the documentation and attachments of sealed entries via a crafted API request. This issue affects : * Devolutions Server 2026.1.6.0 through 2026.1.16.0 * Devolutions Server 2025.3.20.0 and earlier

Authorization bypass in the entry duplication feature in Devolutions Server allows an authenticated user with write access to any vault to copy documentation and attachments from an entry in a vault they cannot access via a crafted save request. This issue affects : * Devolutions Server 2026.1.6.0 through 2026.1.16.0 * Devolutions Server 2025.3.20.0 and earlier

Missing authorization in the vault import feature in Devolutions Server  2026.1.16.0 and earlier allows a low-privileged authenticated user to create new vaults via a crafted import request.

A missing authentication vulnerability exists in the Altium 365 SearchService. A legacy SOAP endpoint exposes search index operations without requiring authentication, session tokens, or any form of identity verification. An unauthenticated network attacker who can reference a target workspace's identifier can interact with that workspace's search index, crossing tenant boundaries. Successful exploitation allows reading a workspace's indexed contents (such as component data, project and folder names, and user metadata) and injecting, modifying, or deleting search index entries. These operations affect the search index only, not the underlying vault data, but they can disclose sensitive workspace information and compromise the integrity and availability of search results. Altium 365 cloud deployments are affected; on-premise Altium Enterprise Server is not affected.

Supply-chain compromise of the npm package @beproduct/nestjs-auth (versions 0.1.2 through 0.1.19) delivered the Mini Shai-Hulud worm payload via a malicious postinstall script, harvesting npm, GitHub, AWS, and HashiCorp Vault credentials from any developer or CI host that ran npm install during a 2h37m publication window on 2026-05-11. Confirmed actively exploited during that window via an attacker-controlled npm publish token; clean version 0.1.20 republishes the original 0.1.1 source tree. CVSS 10.0 reflects the unauthenticated, network-driven supply-chain delivery and scope change into the install environment.

Unauthenticated agent token theft in Coder v2 (self-hosted developer workspace platform) stems from azureidentity.Validate() verifying the PKCS#7 signer's certificate chain but skipping signature verification of the signed content itself. Remote attackers who know a target VM's vmId (a UUIDv4) can forge a PKCS#7 envelope containing a legitimate Azure certificate alongside attacker-controlled content and POST it to the unauthenticated /api/v2/workspaceagents/azure-instance-identity endpoint to receive the victim workspace agent's session token, which then unlocks Git SSH keys, OAuth tokens for GitHub/GitLab/Bitbucket, and workspace secrets. No public exploit identified at time of analysis, but the vulnerability is vendor-confirmed via GHSA-6x44-w3xg-hqqf and a detailed root-cause analysis with attack-path diagram is published.

Server-Side Request Forgery in Tenable Terrascan v1.18.3 and prior allows unauthenticated remote attackers to coerce the server into fetching arbitrary URLs, including file:// URIs that enable local file disclosure. The flaw is triggered when Terrascan runs in server mode and parses uploaded ARM or CloudFormation templates whose templateLink.uri, parametersLink.uri, or AWS::CloudFormation::Stack TemplateURL fields point to attacker-controlled destinations. No public exploit identified at time of analysis, and because Terrascan was archived in August 2023, no patch will ever be released.

Server-Side Request Forgery in Tenable's Terrascan IaC scanner (versions 1.18.3 and prior) lets unauthenticated remote attackers read arbitrary local files and exfiltrate ~/.netrc credentials when the tool runs in server mode. Because Terrascan was archived in August 2023, no vendor patch will ever be released, and the daemon binds to 0.0.0.0 with no authentication by default. No public exploit identified at time of analysis, but the CVSS 4.0 score of 9.2 reflects trivial network-reachable abuse paired with significant confidentiality scope change.

HashiCorp Nomad and Nomad Enterprise prior to 2.0.1 are vulnerable to code execution on the client host through a path traversal attack. This vulnerability (CVE-2026-7474) is fixed in Nomad 2.0.1, 1.11.5 and 1.10.11.

HashiCorp Nomad’s exec2 task driver prior to 0.1.2 is vulnerable to arbitrary file read and write on the client host as the Nomad process user through a symlink attack. This vulnerability (CVE-2026-8052) is fixed in version 0.1.2 of the exec2 task driver.

HashiCorp Nomad and Nomad Enterprise prior to 2.0.1 are vulnerable to arbitrary file read and write on the client host as the Nomad process user through a symlink attack. This vulnerability (CVE-2026-6959) is fixed in Nomad 2.0.1, 1.11.5 and 1.10.11.

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

Credential-harvesting malware compromised 84 versions of 42 TanStack npm packages on 2026-05-11 via chained GitHub Actions exploitation. Attackers combined pull_request_target misconfiguration, Actions cache poisoning, and OIDC token memory extraction to publish malicious code under the legitimate TanStack identity. Installing any affected version executes a 2.3 MB obfuscated payload that exfiltrates AWS/GCP/Kubernetes credentials, npm tokens, GitHub secrets, SSH keys, and HashiCorp Vault tokens over encrypted Session/Oxen messenger infrastructure. The payload propagates by republishing victim-maintained packages with identical injection. Socket.dev and the TanStack team confirmed the incident via GHSA-g7cv-rxg3-hmpx. No EPSS or CISA KEV data available for this recent supply-chain attack. CVSS 9.6 reflects the cross-scope credential theft impact (S:C/C:H/I:H), though exploitation requires user-initiated package installation (UI:R).

Vaultwarden is a Bitwarden-compatible server written in Rust. Prior to 1.35.5, Vaultwarden allows an unconfirmed organization owner to purge the entire organization vault. The organization invite flow uses a two-step process: accepting an invite transitions membership from Invited to Accepted, and a separate confirmation by an existing owner upgrades it to Confirmed. The POST /api/ciphers/purge endpoint uses plain Headers and only checks that the membership type is Owner without verifying that the membership status is Confirmed. An authenticated user who has been invited as an organization owner and has accepted the invite and has not yet been confirmed can call this endpoint to hard-delete all ciphers and attachments in the organization, causing immediate organization-wide data loss. This vulnerability is fixed in 1.35.5.

Vaultwarden is a Bitwarden-compatible server written in Rust. Prior to 1.35.5, Vaultwarden does not enforce that a groups_users.users_organizations_uuid entry belongs to the same organization as groups.groups_uuid, or a collections_groups.collections_uuid entry belongs to the same organization as collections_groups.groups_uuid. Multiple organization group-management endpoints accept arbitrary MembershipId and CollectionId values and persist them directly without verifying org consistency. This lets an attacker who is Admin in Organization A, and only a low-privileged member in Organization B bind their Org B membership UUID into an Org A group, then use that foreign group relationship to gain unauthorized access to Org B vault data. With an accessAll=true Org A group, the attacker can make /api/sync and /api/ciphers enumerate Org B ciphers. Once those unauthorized sync results reveal Org B collection IDs, the attacker can also bind those foreign collection IDs to the Org A group and turn the same flaw into write access over Org B items. This vulnerability is fixed in 1.35.5.

Authentication bypass in UltraDAG Core blockchain allows remote unauthenticated attackers to drain all pocket-derived sub-addresses on smart accounts, completely bypassing vault delays and daily spending limits. The StateEngine fails to resolve pocket addresses to their parent account during policy enforcement, treating virtual pocket addresses as unrestricted accounts. Confirmed actively exploited (CISA KEV). Vendor-released patch: commit fb6ef59 resolves pocket-to-parent mapping before all policy checks. EPSS data unavailable but attack vector is network-accessible with no complexity (CVSS 4.0 AV:N/AC:L/PR:N), making this a critical priority for any UltraDAG deployment using smart account pockets.

{ auth, err := getHeaderValue("Authorization", headers) if err != nil { return ctx, err } host, err := getHeaderValue("Host", headers) if err != nil { return ctx, err } authFormat := strings.Split(auth, " ") if len(authFormat) != 2 { /* ... */ } if authFormat[0] != "Bearer" { /* ... */ } token, err := a.getTokenForHost(ctx, host) // asks the collector's own identity if err != nil { return ctx, err } if authFormat[1] != token { // string comparison, not JWT validation return ctx, errors.New("unauthorized: invalid token") } return ctx, nil } ``` And `getTokenForHost` at `extension.go:187-206`: ```go options := policy.TokenRequestOptions{ Scopes: []string{ fmt.Sprintf("https://%s/.default", host), // client-supplied Host chooses scope }, } ``` Two independent problems compose here: **1. No JWT validation.** Real Entra ID bearer validation requires verifying the JWT signature against the tenant JWKS and checking `iss`, `aud`, `exp`, `nbf`, plus an algorithm allowlist. The extension does none of this. The "expected" value is a token the server mints from its own credential, not a signature to verify. Any party that already holds a valid token for the collector's identity - a co-tenant pod that shares the managed identity, any peer authenticated with the same service principal, any component that retained an `Authorization:` header - can replay it directly. **2. Attacker-controlled audience.** The scope used to mint the "expected" token comes from the client-supplied `Host` header: `https://<Host>/.default`. The `azcore` credential returns a consistent token per (identity, scope) pair within the cache window, so an attacker can pick any scope the SP has been issued a token for and match it by setting `Host` accordingly. This is the sharper of the two flaws: it means a token leaked from an unrelated Azure integration - ARM, Graph, Key Vault, a different Storage account - authenticates to the collector. The correct primitive is a real JWT validator - e.g. `github.com/coreos/go-oidc/v3` pointed at the tenant's discovery endpoint, with audience and issuer pinned *server-side from configuration*, never derived from request headers. Both variants assume a collector running with `azureauthextension` v0.124.0-v0.150.0, configured with any credential mode and referenced from a receiver's `auth:` block: ```yaml extensions: azure_auth: managed_identity: client_id: ${CLIENT_ID} receivers: otlp: protocols: http: endpoint: 0.0.0.0:4318 auth: authenticator: azure_auth service: extensions: [azure_auth] pipelines: traces: receivers: [otlp] exporters: [debug] ``` The attacker controls a workload that shares the collector's managed identity (common in AKS when multiple pods bind the same UAMI). Both workloads query IMDS for `https://management.azure.com/.default` and receive the same cached token. The attacker replays: ``` POST /v1/traces HTTP/1.1 Host: management.azure.com Authorization: Bearer eyJ... # token minted for management.azure.com Content-Type: application/json {"resourceSpans":[...]} ``` `Authenticate` calls `getTokenForHost(ctx, "management.azure.com")`, receives the identical cached token, and the string comparison passes. The attacker holds a token for the SP issued for a *different* Azure resource - say Key Vault, obtained from an entirely unrelated integration. The collector was never intended to accept Key Vault tokens. The attacker sets `Host` to match: ``` POST /v1/traces HTTP/1.1 Host: vault.azure.net Authorization: Bearer eyJ... # token minted for vault.azure.net Content-Type: application/json {"resourceSpans":[...]} ``` `Authenticate` calls `getTokenForHost(ctx, "vault.azure.net")`. The collector's credential mints (or returns cached) a token for `https://vault.azure.net/.default` - the same token the attacker holds, because both come from the same SP issued for the same scope by the same IdP. Comparison passes. The collector accepts telemetry gated on "proof of identity to Key Vault." In a correct implementation, the JWT's `aud` would be pinned server-side to a value unrelated to `Host`, and Variant B would fail regardless of what the attacker put in the `Host` header. A small Go reproducer can be built around the extension's own test harness: the existing `TestAuthenticate` in `extension_test.go` is effectively a demonstration of the broken behavior - it passes when the client-supplied token equals the server-side token for the given `Host`, which is exactly what an attacker arranges. **Vulnerability class:** Improper Authentication (CWE-287), with contributing CWE-347 (Improper Verification of Cryptographic Signature - no JWT validation), CWE-294 (Authentication Bypass by Capture-replay - tokens replayable for full TTL), and CWE-290 (Authentication Bypass by Spoofing - client `Host` header chooses the expected scope). **Threat model / precondition.** The attacker needs to already hold (or be able to obtain) a valid Azure access token issued to the collector's SP for any scope. In practice this is satisfied by: (a) controlling another workload that binds the same managed identity, (b) compromising any peer authenticated with the same SP, or (c) observing an `Authorization:` header from any prior legitimate request for the SP. This is what drives the 8.1 score - the precondition is non-trivial but is routine in multi-workload Azure environments. **Who is impacted.** Any operator of `opentelemetry-collector-contrib` v0.124.0 through v0.150.0 who configured `azureauthextension` on a receiver's `auth:` block. This applies to both HTTP and gRPC receivers - gRPC receivers surface `:authority` as `Host` through the collector's header handling, so the same exploit path applies there. **Deployments most at risk:** - Multi-workload Azure environments where the collector shares a managed identity with other workloads (any such workload can authenticate as an arbitrary telemetry source). - Deployments that forward `Authorization:` headers through proxies, service meshes, or logging pipelines (one leaked token is enough, and persists for the token TTL - typically several hours for MI tokens, not the 60-minute user-token window). - Multi-tenant environments where different customers' telemetry converges at a collector protected by this extension. **Consequences.** Unauthenticated (from the collector's perspective) ingest of arbitrary traces, metrics, and logs. Downstream effects depend on the collector's exporters and include telemetry-backend poisoning, log injection (masking real attacker activity in SIEMs), metric manipulation to trigger or suppress alerts, cost-amplification against pay-per-datapoint backends, and adversarial traces that corrupt service-graph and incident-triage signals. **Not impacted.** The extension's outbound `extensionauth.HTTPClient` path, used by Azure exporters, is unaffected. Operators who use `azureauthextension` only on exporters can continue doing so. Until a patched release is available, remove `azure_auth` from any receiver `auth:` blocks. For genuine Entra ID JWT validation on OTLP receivers, use `oidcauthextension` pointed at the tenant discovery URL, with audience pinned from configuration: ```yaml extensions: oidc: issuer_url: https://login.microsoftonline.com/<tenant-id>/v2.0 audience: <expected-api-audience> ``` - PR introducing the vulnerable server-side path: [#39178](https://github.com/open-telemetry/opentelemetry-collector-contrib/pull/39178) - Affected versions: v0.124.0 - v0.150.0 Assisted-by: Opus 4.7

Improper access control in the vault documentation feature in Devolutions Server 2026.1.14.0 and earlier allows an authenticated attacker to read documentation content from unauthorized vaults via a crafted API request.

OpenBao's Certificate authentication method with disable_binding=true allows token renewal using any sibling certificate signed by the same CA, rather than requiring the original certificate, enabling attackers with knowledge of a token or accessor to extend dynamic lease lifetimes beyond intended scope. The vulnerability affects OpenBao versions prior to 2.5.3 and requires high privileges and user interaction, resulting in a CVSS 2.0 score with low confidentiality and integrity impact. No public exploit code or active exploitation has been identified.

OpenBao 2.5.2 and earlier fails to properly quote PostgreSQL schema names during role revocation in the PostgreSQL database secrets engine, allowing authenticated high-privilege administrators to execute arbitrary SQL injection as the database management user. The vulnerability affects the credentials management workflow when revoking database roles, potentially compromising database integrity. A vendor-released patch (version 2.5.3) is available.

HashiCorp Vault unauthenticated denial-of-service vulnerability allows remote attackers to block critical administrative operations by monopolizing the single operation slot for root token generation and rekey workflows. Affects all Vault Community and Enterprise versions prior to 2.0.0. No active exploitation confirmed (EPSS 3rd percentile), but attack is trivially automatable per CISA SSVC framework. HashiCorp released patches in Vault Community Edition 2.0.0 and Vault Enterprise 2.0.0.

HashiCorp Vault improperly forwards authentication tokens to backend auth plugins when Authorization header pass-through is configured, allowing authenticated attackers with low privileges to potentially capture Vault tokens through malicious or compromised auth backends. Affects Vault 0.11.2 through 1.x and Vault Enterprise through 1.x, with patches available in versions 2.0.0, 1.21.5, 1.20.10, and 1.19.16. EPSS score of 0.01% suggests minimal widespread exploitation risk, and SSVC framework indicates no active exploitation, non-automatable attack requiring specific configuration, though technical impact is total system compromise if successfully executed.

Server-side request forgery (SSRF) in HashiCorp Vault's PKI engine ACME validation allows unauthenticated remote attackers to send http-01 and tls-alpn-01 challenge requests to local network targets by controlling DNS responses, potentially disclosing sensitive information from internal services. The vulnerability affects Vault Community Edition before 2.0.0 and Vault Enterprise before 1.19.16, 1.20.10, or 1.21.5. HashiCorp has released patched versions; no public exploit code has been identified at the time of analysis.

HashiCorp Vault's KVv2 secrets engine allows authenticated users with glob-based policy access to delete secrets outside their authorization scope, causing denial-of-service across versions 0.10.0 through 1.x. The flaw stems from improper access control (CWE-288) in policy glob evaluation during delete operations. Exploitation requires valid Vault credentials with specific policy patterns but does not permit cross-namespace deletion or secret data exfiltration. Fixed in Vault Community Edition 2.0.0 and Vault Enterprise 2.0.0/1.21.5/1.20.10/1.19.16. No active exploitation confirmed (EPSS 0.01%), but CVSS 8.1 reflects high integrity and availability impact for authenticated attackers.

Cryptomator is an open-source client-side encryption application for cloud storage. Version 1.19.1 contains a logic flaw in CheckHostTrustController.getAuthority() that allows an attacker to bypass the security fix for CVE-2026-32303. The method hardcodes the URI scheme based on port number, causing HTTPS URLs with port 80 to produce the same authority string as HTTP URLs, which defeats both the consistency check and the HTTP block validation. An attacker with write access to a cloud-synced vault.cryptomator file can craft a Hub configuration where apiBaseUrl and authEndpoint use HTTPS with port 80 to pass auto-trust validation, while tokenEndpoint uses plaintext HTTP. The vault is auto-trusted without user prompt, and a network-positioned attacker can intercept the OAuth token exchange to access the Cryptomator Hub API as the victim. This issue has been fixed in version 1.19.2.

Arbitrary file read vulnerability in HashiCorp go-getter library versions up to 1.8.5 enables unauthenticated remote attackers to access sensitive files from the target filesystem through specially crafted git operation URLs. The vulnerability permits confidentiality breach without authentication requirements, affecting network-accessible services utilizing the library for repository cloning or fetching operations. Fixed in version 1.8.6; go-getter/v2 branch unaffected. No public exploit identified at time of analysis.

Unauthenticated remote attackers can trigger complete database overwrites, server-side file reads, and SSRF attacks against Dgraph graph database servers (v24.x, v25.x prior to v25.3.1) via the admin API's restoreTenant mutation. The mutation bypasses all authentication middleware due to missing authorization configuration, allowing attackers to provide arbitrary backup source URLs (including file:// schemes for local filesystem access), S3/MinIO credentials, Vault configuration paths, and encry

Authenticated users in n8n versions prior to 1.123.23 and 2.6.4 can bypass external secrets permission checks to retrieve plaintext secret values from configured vaults by referencing secrets by name in credentials, even without list permissions. This allows unauthorized access to sensitive vault-stored credentials without requiring admin or owner privileges, provided the attacker knows or can guess the target secret name. Public exploit code exists for this vulnerability.

An integrity check vulnerability in Cryptomator for Android prior to version 1.12.3 allows attackers to tamper with the vault configuration file, enabling a man-in-the-middle attack against the Hub key loading mechanism. Attackers who can modify the vault.cryptomator file can mix legitimate authentication endpoints with malicious API endpoints to exfiltrate tokens from users unlocking Hub-backed vaults. With a CVSS score of 7.6 and requiring low attack complexity with user interaction, this vulnerability poses a moderate risk to affected users in environments where vault configuration files can be altered.

A man-in-the-middle vulnerability in Cryptomator for iOS versions prior to 2.8.3 allows attackers who can modify the vault.cryptomator configuration file to intercept authentication tokens by substituting malicious API endpoints while maintaining legitimate authentication endpoints. This affects users unlocking Hub-backed vaults in environments where attackers have write access to vault configuration files. No evidence of active exploitation (not in CISA KEV) has been reported, and patches are available.

Cryptomator versions 1.6.0 through 1.19.0 contain a path traversal vulnerability in vault configuration parsing where the masterkeyfile loader resolves an unverified keyId parameter as a filesystem path before integrity checks are performed. An attacker with the ability to supply a malicious vault configuration can exploit this to trigger arbitrary file existence checks, including UNC paths on Windows that can initiate outbound SMB connections before the user even enters a passphrase, potentially leading to information disclosure about local file structure and network exposure. The vulnerability has been patched in version 1.19.1, and while no active KEV exploitation has been reported, the low attack complexity and the ability to chain this with social engineering (malicious vault sharing) makes it a moderate practical risk.

Cryptomator's Hub-based unlock flow contains a protocol downgrade vulnerability that allows the application to communicate with Hub endpoints over plaintext HTTP instead of enforcing HTTPS. Cryptomator versions prior to 1.19.1 are affected, exposing OAuth bearer tokens, key-loading traffic, and endpoint-level trust decisions to network interception and tampering by active attackers. This is a verified GitHub security advisory with patches available in version 1.19.1, though no EPSS score or KEV listing indicates limited evidence of active exploitation.

Cryptomator versions prior to 1.19.1 contain an integrity check vulnerability that allows attackers to tamper with the vault.cryptomator configuration file, enabling man-in-the-middle attacks during Hub key loading. Attackers can mix legitimate authentication endpoints with malicious API endpoints to exfiltrate access tokens from users unlocking Hub-backed vaults in environments where vault configuration files can be modified. The CVSS score of 7.6 indicates high severity with network attack vector requiring low privileges and user interaction, though no active exploitation (KEV) or public POC has been reported at this time.

An authorization bypass vulnerability exists in the Vault secrets back-end implementation of Canonical's Juju orchestration tool, allowing authenticated unit agents to perform unauthorized updates to secret revisions beyond their intended scope. Juju versions 3.1.6 through 3.6.18 are affected, and attackers with sufficient information can poison any existing secret revision within the Vault secret back-end scope. With a CVSS score of 7.6 (High severity) featuring network attack vector, low complexity, and high integrity impact, this represents a significant security concern for Juju deployments using Vault as their secrets back-end, though no active exploitation (KEV) status or EPSS score was provided in available data.

Insecure password saving enforcement in Devolutions Remote Desktop Manager 2025.3.

A vulnerability was identified in AliasVault App up to 0.25.3 on Android/iOS. This vulnerability affects unknown code of the file shared_prefs/aliasvault.xml of the component Backup Handler. [CVSS 2.5 LOW]

Path traversal vulnerability in atlaszz AI Photo Team Galleryit App version 1.3.8.2 on Android allows authenticated local attackers to manipulate the gallery.photogallery.pictures.vault.album component and access files outside intended directories. The vulnerability requires local access and authenticated user privileges; public exploit code exists. The vendor has not responded to early disclosure notification, leaving the application unpatched.

Terraform state versions can be created by a user with specific but insufficient permissions in a Terraform Enterprise workspace. Rated medium severity (CVSS 4.3), this vulnerability is remotely exploitable, low attack complexity. No vendor patch available.

Vault’s Terraform Provider incorrectly set the default deny_null_bind parameter for the LDAP auth method to false by default, potentially resulting in an insecure configuration. Rated high severity (CVSS 7.4), this vulnerability is remotely exploitable, no authentication required. No vendor patch available.

Atlantis is a self-hosted golang application that listens for Terraform pull request events via webhooks. Rated medium severity (CVSS 6.9), this vulnerability is remotely exploitable, no authentication required, low attack complexity. Public exploit code available and no vendor patch available.

Coder allows organizations to provision remote development environments via Terraform. Rated high severity (CVSS 8.1), this vulnerability is remotely exploitable, low attack complexity. Public exploit code available.

A vulnerability was identified in GalleryVault Gallery Vault App up to 4.5.2 on Android. Rated medium severity (CVSS 4.8), this vulnerability is low attack complexity. Public exploit code available and no vendor patch available.

A malicious user may submit a specially-crafted complex payload that otherwise meets the default request size limit which results in excessive memory and CPU consumption of Vault. Rated high severity (CVSS 7.5), this vulnerability is remotely exploitable, no authentication required, low attack complexity. No vendor patch available.

HashiCorp's go-getter library subdirectory download feature is vulnerable to symlink attacks leading to unauthorized read access beyond the designated directory boundaries. Rated high severity (CVSS 7.5), this vulnerability is remotely exploitable, no authentication required, low attack complexity. No vendor patch available.

An unsafe deserialization vulnerability in Palo Alto Networks Checkov by Prisma® Cloud allows an authenticated user to execute arbitrary code as a non administrative user by scanning a malicious. Rated medium severity (CVSS 4.8), this vulnerability is no authentication required, low attack complexity. No vendor patch available.

Vault and Vault Enterprise’s (“Vault”) ldap auth method may not have correctly enforced MFA if username_as_alias was set to true and a user had multiple CNs that are equal but with leading or. Rated medium severity (CVSS 6.5), this vulnerability is remotely exploitable, low attack complexity. No vendor patch available.

Vault and Vault Enterprise (“Vault”) TLS certificate auth method did not correctly validate client certificates when configured with a non-CA certificate as [+trusted. Rated medium severity (CVSS 6.8), this vulnerability is remotely exploitable, low attack complexity. No vendor patch available.

Vault and Vault Enterprise’s (“Vault”) login MFA rate limits could be bypassed and TOTP tokens could be reused. Rated medium severity (CVSS 5.7), this vulnerability is remotely exploitable, low attack complexity. No vendor patch available.

Vault and Vault Enterprise’s (“Vault”) TOTP Secrets Engine code validation endpoint is susceptible to code reuse within its validity period. Rated medium severity (CVSS 6.5), this vulnerability is remotely exploitable, low attack complexity. No vendor patch available.

A timing side channel in Vault and Vault Enterprise’s (“Vault”) userpass auth method allowed an attacker to distinguish between existing and non-existing users, and potentially enumerate valid. Rated low severity (CVSS 3.7), this vulnerability is remotely exploitable, no authentication required. No vendor patch available.

Vault and Vault Enterprise’s (“Vault”) user lockout feature could be bypassed for Userpass and LDAP authentication methods. Rated medium severity (CVSS 5.3), this vulnerability is remotely exploitable, no authentication required, low attack complexity. No vendor patch available.

{{sys/audit}} may obtain code execution on the underlying host if a plugin directory is set in Vault’s configuration. Rated critical severity (CVSS 9.1), this vulnerability is remotely exploitable, low attack complexity. No vendor patch available.

A privileged Vault operator with write permissions to the root namespace’s identity endpoint could escalate their own or another user’s token privileges to Vault’s root policy. Rated high severity (CVSS 7.2), this vulnerability is remotely exploitable, low attack complexity. No vendor patch available.

Terraform WinDNS Provider allows users to manage their Windows DNS server resources through Terraform. Rated low severity (CVSS 1.1), this vulnerability is low attack complexity. No vendor patch available.

Vault Community, Vault Enterprise (“Vault”) Azure Auth method did not correctly validate the claims in the Azure-issued token, resulting in the potential bypass of the bound_locations parameter on. Rated medium severity (CVSS 6.6), this vulnerability is remotely exploitable. No vendor patch available.

Vault Community and Vault Enterprise Key/Value (kv) Version 2 plugin may unintentionally expose sensitive information in server and audit logs when users submit malformed payloads during secret. Rated medium severity (CVSS 4.5), this vulnerability is remotely exploitable, low attack complexity. No vendor patch available.

Arctera eDiscovery Platform before 10.3.2, when Enterprise Vault Collection Module is used, places a cleartext password on a command line in EVSearcher. Rated medium severity (CVSS 6.0), this vulnerability is low attack complexity. No vendor patch available.

Spring Cloud Config Server may not use Vault token sent by clients using a X-CONFIG-TOKEN header when making requests to Vault. Rated medium severity (CVSS 5.3), this vulnerability is remotely exploitable, no authentication required, low attack complexity. No vendor patch available.

Improper Neutralization of Input During Web Page Generation ('Cross-site Scripting') vulnerability in Vault Group Pty Ltd VaultRE Contact Form 7 allows Stored XSS.0. Rated medium severity (CVSS 5.9), this vulnerability is remotely exploitable, low attack complexity. No vendor patch available.

Exposure of sensitive information in My Personal Credentials password history component in Devolutions Remote Desktop Manager 2024.3.29 and earlier on Windows allows an authenticated user to. Rated medium severity (CVSS 6.5), this vulnerability is remotely exploitable, low attack complexity. No vendor patch available.

An information disclosure vulnerability exists in the Vault API functionality of ClearML Enterprise Server 3.22.5-1533. Rated high severity (CVSS 7.7), this vulnerability is remotely exploitable, low attack complexity. Public exploit code available and no vendor patch available.

PVWA (Password Vault Web Access) in CyberArk Privileged Access Manager Self-Hosted before 14.4 has potentially elevated privileges in LDAP mapping. Rated medium severity (CVSS 4.2), this vulnerability is remotely exploitable. No vendor patch available.

PVWA (Password Vault Web Access) in CyberArk Privileged Access Manager Self-Hosted before 14.4 does not properly address environment issues that can contribute to Host header injection. Rated medium severity (CVSS 4.2), this vulnerability is remotely exploitable, no authentication required. No vendor patch available.

In JetBrains TeamCity before 2024.12.1 reflected XSS was possible on the Vault Connection page. Rated medium severity (CVSS 4.6), this vulnerability is remotely exploitable, low attack complexity. Epss exploitation probability 19.9% and no vendor patch available.

HashiCorp’s go-slug library is vulnerable to a zip-slip style attack when a non-existing user-provided path is extracted from the tar entry. Rated high severity (CVSS 7.5), this vulnerability is remotely exploitable, no authentication required, low attack complexity. No vendor patch available.