Path traversal in Prisma Cloud Checkov enables an unauthenticated local attacker to write files to arbitrary locations on the scanning filesystem by persuading a victim to scan attacker-controlled or untrusted infrastructure-as-code content. Exploitation requires user interaction (the victim running Checkov on malicious IaC), and the flaw is not remotely exploitable; impact is limited to file writes on the host performing the scan. No public exploit code or active exploitation has been reported (CISA KEV does not list this CVE), and the practical risk is low, especially for environments that scan only trusted, internally-authored IaC.
Nix releases before 2.35.3 in unsandboxed macOS or FreeBSD deployments permit a local authenticated build user to establish daemon client connections that should be denied, enabling unauthorized interactions with the Nix daemon. The independently assessed CVSS is 4.3 (CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:C/C:N/I:L/A:N), reflecting a local, scope-changed authorization weakness with limited integrity impact and no confidentiality or availability impact. No public exploit identified at time of analysis; the issue is confined to unsandboxed macOS/FreeBSD configurations, and upgrading to 2.35.3 or enabling sandboxing removes the exposure.
Seatbelt sandbox escape on macOS in Nix before 2.35.3 and Lix before 2.95.4 lets a local attacker cause a crafted build to break out of the macOS Seatbelt confinement via a mishandled size threshold, yielding limited integrity impact (C:N/I:L/A:N). There is no public exploit identified at time of analysis and no confirmed active exploitation, and the issue is assessed as low-to-moderate priority because exploitation requires local access on macOS plus the ability to have a build evaluated on the host, such as on multi-user build servers or CI runners processing untrusted derivations. Unauthenticated local access is consistent with the CVSS vector (PR:N).
Type confusion in the Palo Alto Networks GlobalProtect app on Windows lets an authenticated local user with low privileges crash the client and produce a denial-of-service condition (CWE-843; vendor CVSS 4.0 score 4.3; assessed CVSS:3.1 4.3 with AV:L/PR:L/UI:N and availability-only impact). Only the Windows client is affected - GlobalProtect on Linux, macOS, iOS, Android, and Chrome OS is explicitly not vulnerable - so the exposed population is limited to Windows endpoints running GlobalProtect 6.3.0 before 6.3.3-h16, 6.2.0 before 6.2.8-h15, or 6.0.0 before 6.0.15. There is no remote attack surface, no confidentiality or integrity impact, and no privilege escalation or lateral movement, and no public exploit code was identified at time of analysis. Vendor-released patches are available, so this should be treated as a low-to-moderate priority maintenance item rather than an emergency.
WebAuthn two-factor authentication in LDAP Account Manager (LAM) before 9.6 fails to clear the WebAuthn challenge from the PHP session after the authentication response is processed, allowing a signed WebAuthn ceremony state to be replayed rather than consumed once. Exploitation requires an attacker who already holds valid account credentials (the CVSS vector shows PR:L, i.e. authenticated), operates within the same PHP session, and can present a valid authenticator signature, and it only affects non-default installations where WebAuthn 2FA is enabled - this is a low-priority 2FA weakness rather than an anonymous remote compromise. No public exploit code or confirmed active exploitation has been identified at time of analysis.
An out-of-bounds read in the Zephyr RTOS STM32WBA IEEE 802.15.4 driver (drivers/ieee802154/ieee802154_stm32wba.c) lets an attacker within radio range of an STM32WBA-based device copy roughly 128 bytes of adjacent RAM into a network packet delivered to the networking stack. The flaw affects Zephyr 4.3.0 through 4.4.2 in the default production configuration (CONFIG_ASSERT=n), where the only length bound is compiled out; builds with CONFIG_ASSERT=y are not exploitable because the assertion would fire first. Impact is limited to a read-only information disclosure and oversized packet allocation in the RX thread - no code execution and no internet-reachable path - and no public exploit identified at time of analysis, with CVSS scored 4.2 (AV:A/AC:H/PR:N/UI:N).
Local privilege escalation in Nix before 2.35.3 allows a local attacker with access to the user account that installed the multi-user Nix store to gain root privileges by tampering with /nix/store contents, because the installer incorrectly assigned ownership of the store to the invoking user instead of root. The independent assessment rates this as High severity (CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:C/C:H/I:H/A:H), noting that exploitation requires local access to the affected account and that the host must have been provisioned with the vulnerable multi-user installer. No public exploit code is known at this time; a security advisory is available.
Credential leakage in curl 8.21.0 through 8.22.0 allows unauthenticated remote attackers to obtain Negotiate (SPNEGO/Kerberos) authentication tokens when a redirect or cross-origin transition causes the 'Authorization: Negotiate' header to be sent to a foreign origin. The flaw is rated LOW by the curl project and has an assessed CVSS 3.1 score of AV:N/AC:H/PR:N/UI:N/S:U/C:L/I:N/A:N; no public exploit code was identified at time of analysis. Exploitation requires the user to explicitly enable Negotiate authentication (e.g., via --negotiate or CURLAUTH_NEGOTIATE) and for the request flow to reach a foreign origin, limiting impact to token disclosure rather than code execution or service disruption.
Negotiate (Kerberos/SPNEGO) credentials are forwarded to the wrong origin by curl and libcurl 8.21.0 through 8.22.0 when the initially contacted server returns an HTTP redirect to a different host while redirect following is enabled. An attacker who controls or influences either the redirect response or the redirect destination can capture the Negotiate authentication token, resulting in limited confidentiality exposure rather than code execution or data modification. The flaw is rated LOW by the curl project, no public exploit code has been identified at time of analysis, and it was fixed in the curl 8.23.0 release published on 2026-10-14 alongside twenty-three other advisories.
Persisted HSTS state in curl/libcurl can be silently truncated when a previously exported HSTS cache is re-imported, because the import logic drops a longer-lived child entry (for example an includeSubDomains rule) in favor of a shorter-lived parent. Applications that explicitly enable curl's HSTS support via CURLOPT_HSTS or the --hsts option and persist that cache to disk across runs are affected; default curl usage with HSTS off is not. The resulting loss of HSTS enforcement only becomes exploitable if an on-path (man-in-the-middle) attacker is positioned to force a protocol downgrade to plaintext HTTP, so the curl project rates this severity LOW and no public exploit code or KEV/EPSS signal is present in the available data. Remote attackers, no authentication required per the assessed vector (CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:L/I:L/A:N), but attack complexity is high and confidentiality/integrity impact is limited.
A crafted Set-Cookie header returned by a server can abort the loading of curl/libcurl's cookie jar in versions 8.7.0 through 8.22.0, disrupting the client's cookie-persistence routine instead of completing the jar load. The flaw is only reachable when the client is configured to use a persistent cookie jar (the -b/--cookie or -c/--cookie-jar options, or CURLOPT_COOKIEFILE/CURLOPT_COOKIEJAR in libcurl) and the attacker controls or has compromised the server end of the connection, so it is a network-reachable but low-impact integrity issue (CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:L/A:N). The curl project rates this LOW severity as part of its 8.23.0 release, no public exploit code or confirmed active exploitation has been identified at time of analysis, and no EPSS or KEV signal is associated with the CVE.
Persisted HSTS entries held by curl and libcurl can be erased when a malicious or on-path server returns a crafted Strict-Transport-Security response, allowing an attacker to strip previously stored HTTPS-only policy for other hosts. Only builds running up to and including 8.22.0 that have HSTS persistence explicitly enabled (the curl tool's --hsts <file> option, or libcurl with CURLOPT_HSTS pointed at a cache file) are exposed - this is not a default configuration, which is the main limiting factor. The assessed impact is integrity-only (CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:N/I:L/A:N), with no code execution or direct data disclosure; harm is indirect and deferred, since a later connection to a de-pinned host is only downgradable if the attacker can also intercept that subsequent traffic. No public exploit code has been identified at time of analysis and there is no indication of active exploitation. Fixes ship in curl 8.23.0, which resolves this issue alongside twenty-three other CVEs published on the same date.
Cross-origin reuse of a Negotiate-authenticated connection in curl and libcurl (through 8.22.0) allows a connection authenticated to one origin to be reused for a request to a different origin when a single easy handle or connection cache serves multiple hosts. The curl project rates the issue LOW, and the assessed vector CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:L/I:N/A:N shows no privileges required (PR:N) but a high attack complexity, with only a low-confidentiality impact and no integrity or availability effect - there is no memory corruption or code-execution component. Exploitation is conditional on the consuming application being built with Negotiate/SPNEGO (GSSAPI/Kerberos) support and deliberately reusing connections across more than one origin, so it is not a remotely triggerable flaw against a default curl configuration; no public exploit code or CISA KEV entry is identified at time of analysis, and no EPSS score was provided in the available data.
A server-controlled response can erase the contents of a libcurl application's persisted cookie jar in curl/libcurl 8.18.0 through 8.22.0, allowing a malicious, compromised, or impersonated HTTP server to destroy stored cookie state. The flaw only triggers when the application has the cookie engine enabled together with cookie-jar file persistence (the curl tool's -c/--cookie-jar option or the CURLOPT_COOKIEJAR libcurl option); without that configuration the code path is unreachable. Impact is bounded to loss of stored cookie data - an integrity-only concern with no code execution, no credential disclosure, and no further system compromise - and no public exploit code was identified at time of analysis, which is consistent with the LOW severity assigned by the curl project and the AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:L/A:N assessment.
Credential disclosure in curl and libcurl at or below 8.22.0 causes origin host credentials to be sent to a configured HTTP proxy instead of being reserved for the intended origin server. The flaw only manifests when a deployment both routes transfers through an HTTP proxy and supplies credentials intended for the origin host, which is why the curl project rates it LOW severity and why the independent assessment scores it CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:L/I:N/A:N - confidentiality-only impact with high attack complexity and no integrity or availability effect. There is no KEV listing and no public exploit identified at time of analysis, so real-world urgency is driven mainly by whether an environment uses untrusted or shared proxies alongside origin credentials. The fix ships in curl 8.23.0.
CRLF-driven IMAP command injection in curl/libcurl's IMAP APPEND upload path allows an attacker who controls part of the appended message body to smuggle protocol commands into a live IMAP session when CRLF conversion is explicitly enabled (curl --crlf or CURLOPT_CRLF). Affected releases are curl and libcurl up to and including 8.22.0; the fix ships in curl 8.23.0, released alongside the project's quarterly batch of twenty-four advisories. The curl project rates this one LOW severity, the independently assessed vector is CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:N/I:L/A:N (network reachable, no privileges required by the attacker, high attack complexity, limited integrity impact), and no public exploit identified at time of analysis.
Public-key pinning enforcement in curl/libcurl built against the wolfSSL TLS backend can be bypassed, affecting versions up to and including 8.22.0, so a man-in-the-middle attacker can present an alternate server certificate that the opt-in CURLOPT_PINNEDPUBLICKEY (--pinnedpubkey) check should have rejected. The weakness is heavily constrained: the library must be compiled with wolfSSL, the calling application must have explicitly enabled pinning (a non-default hardening feature), and the attacker must already hold a network man-in-the-middle position - the flaw nullifies an existing detection layer rather than creating interception capability. No public exploit code or CISA KEV entry was identified at time of analysis and no EPSS score was supplied, so risk is concentrated in the specific wolfSSL-plus-pinning deployment profile; the issue is fixed in curl 8.23.0.
Credential mixup during TLS connection reuse in curl/libcurl up to and including 8.22.0 can cause an application relying on automatic client-certificate selection to present the wrong client certificate on a pooled connection, exposing a transfer's identity context to the wrong destination or policy. Exploitation is not reachable by an arbitrary external attacker with a single request: it requires a libcurl-based host application that enables automatic client-certificate selection on a TLS backend that supports it and also reuses connections across transfers with differing certificate expectations, which is why the curl project rates it LOW (assessed CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:L/I:N/A:N, base 3.7, confidentiality-only impact). The issue is one of twenty-four advisories published with curl 8.23.0; no public exploit code has been identified and the flaw is not confirmed actively exploited (not in CISA KEV) at time of analysis.
FTP and FTPS transfers performed by curl/libcurl through 8.22.0 can reuse a connection that carries a client certificate configured for an earlier, differently-configured transfer, so a later transfer may present the wrong client certificate to a server. It is a client-side connection-reuse logic error, not a server-triggerable flaw: it requires an application built on libcurl that sets CURLOPT_SSLCERT (or equivalent) for FTP(S) and reuses connections across multiple transfers on the same handle, and the assessed vector is CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:L/I:N/A:N. The curl project rates this LOW, and it is one of twenty-four flaws disclosed alongside curl 8.23.0; no public exploit code has been identified and there is no confirmed active exploitation (CISA KEV) at time of analysis. Practical risk is limited to deployments that mix client-certificate and non-client-certificate FTP(S) transfers on shared handles or shared connection caches.
Local file overwrite in the curl command-line tool (versions 7.20.0 through 8.22.0) occurs when a user runs a transfer with both the -J/--remote-header-name option and --no-clobber, and the connected HTTP server - or a man-in-the-middle on the connection - sends a 103 Early Hints interim response containing a Content-Disposition header. Because the early-hints header is honored for filename selection before the no-clobber protection is applied, an attacker-influenced filename can cause curl to overwrite a local file that --no-clobber was explicitly intended to protect, with impact limited to integrity of that file (no confidentiality or availability effect). The curl project rates this LOW, exploitation requires the victim to actively choose a specific non-default option combination, and no public exploit code or CISA KEV entry is identified at time of analysis; the flaw is fixed in curl 8.23.0.
Transfer-direction confusion in curl and libcurl's TFTP handling lets a malicious or misbehaving TFTP server cause a client to mishandle a read (download) transfer as a write (upload) or vice versa, affecting releases from 7.15.0 through 8.22.0. The curl project rates this LOW severity, and the independent assessment scores it CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:L/I:N/A:N - high attack complexity, unauthenticated per the vector's PR:N, with only limited confidentiality impact and no integrity or availability impact. The fix ships in curl 8.23.0; there is no public exploit identified at time of analysis and no evidence of active exploitation, and because reaching the vulnerable code requires the application to actually perform a tftp:// transfer against an attacker-influenced server, the practical risk is low despite curl's ubiquity.
Password disclosure in curl and libcurl 7.62.0 through 8.22.0 occurs when an application fetches CURLINFO_EFFECTIVE_URL for a transfer whose URL carried embedded userinfo credentials (user:password@host): the effective-URL string returned by libcurl is not scrubbed of the password, so the secret flows into whatever sink the application controls - log files, console/UI output, telemetry, or downstream services. The curl project classifies this as LOW, and our independent assessment agrees (CVSS:3.1/AV:L/AC:H/PR:L/UI:N/S:U/C:L/I:N/A:N), since there is no remote attack vector and exposure is confined to a sink the host application already owns; no public exploit code or confirmed active exploitation was identified at time of analysis. Applications that never embed credentials in URLs, or that never read the CURLINFO_EFFECTIVE_URL field, are not affected.
FTP wildcard downloads in libcurl 7.21.0 through 8.22.0 can misroute transferred file data to the wrong application-supplied write callback, giving limited confidentiality and integrity impact (CVSS 3.1 AV:N/AC:H/PR:N/UI:N/S:U/C:L/I:L/A:N) to unauthenticated remote attackers. The flaw is only reachable when a consuming application explicitly enables CURLOPT_WILDCARDMATCH with a glob-expanded FTP URL - a non-default option used by a small minority of integrations - and when the client fetches multiple matching files from an FTP server whose responses the attacker can influence or control; a default curl/libcurl build that does not use FTP wildcards is not exposed. The curl project rates this as LOW severity, the fix ships in curl/libcurl 8.23.0, and no public exploit has been identified at time of analysis; no EPSS score, KEV listing, or public proof-of-concept is present in the available data.
In curl and libcurl through 8.22.0, libcurl's SSH host-key verification callback (CURLOPT_SSH_KEYFUNCTION) can misreport a server host key that does not match the expected key as merely 'missing' from the known-hosts store, so applications that treat unknown keys more leniently than changed keys may accept an attacker-substituted key. The practical impact is weakened host authentication (limited confidentiality and integrity loss, CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:L/I:L/A:N), and exploitation requires an active man-in-the-middle on the SCP/SFTP path, a configured known-hosts file, and a callback whose policy distinguishes MISSING from MISMATCH. No CVSS vector, EPSS score, or KEV entry accompanies the public data and no public exploit code has been identified at time of analysis; the curl project itself rates this issue LOW, and it is one of twenty-four advisories fixed in the curl 8.23.0 release (only CVE-2026-92392, an HTTP/2 upload use-after-free, is rated HIGH).