Vulnerabilities

GitPython before 3.1.60 fails to properly validate the location of the git directory, which lets an attacker impersonate it using tracked files such as gitdir, commondir, and HEAD. An attacker who can get a victim to clone or open a crafted repository can plant a malicious pre-commit hook in the tracked hooks directory. When the victim's code then calls index.commit() on that repository, the hook executes, giving the attacker arbitrary code execution with the privileges of the process running GitPython. Anyone running affected versions in workflows that process untrusted or attacker-influenced repositories — such as CI/CD pipelines, automation, and developer tooling — is affected, while purely local, fully trusted repository use is largely out of scope. No public proof-of-concept is known, the issue is not in CISA KEV, and no in-the-wild exploitation has been reported.

Do: Upgrade GitPython to 3.1.60 or later. As interim mitigation, avoid calling index.commit() or other hook-triggering operations on repositories cloned from untrusted sources, and audit dependency trees and CI images for GitPython versions below 3.1.60. When reviewing untrusted repositories, look for tracked files named gitdir, commondir, or HEAD and unexpected files in a tracked hooks directory.

MISP versions 2.5.45 and earlier accept attacker-controlled email input on the unauthenticated forgot-password reset endpoint without a length bound or format validation, persisting the supplied value twice per request (once in an audit log entry and once in a queued password-reset job) with no rate limiting. An unauthenticated attacker can repeatedly submit oversized or arbitrary values to this and similar pre-auth paths (registrations, failed REST authentication attempts), driving unbounded growth of persistent storage and queued work. The result is high availability impact (CVSS 4.0 8.7, VA:High): resource exhaustion can degrade or disrupt the instance, while confidentiality and integrity are unaffected. Any MISP deployment running 2.5.45 or earlier is affected, particularly instances where the pre-auth reset flow is reachable by untrusted users. No public PoC, no CISA KEV listing, and an EPSS of about 0.3% indicate no known exploitation at this time.

Do: Upgrade MISP to a release newer than 2.5.45, which adds the 1024-byte email length cap, email-format validation before persistent work, a per-source pre-auth request budget with HTTP 429 responses, and a 15-minute cooldown for API-access request emails. Until patched, rate-limit or restrict unauthenticated access to the forgot-password and other pre-auth endpoints at a reverse proxy or WAF, and monitor audit-log and job-queue growth for signs of storage exhaustion. Also verify the API-access request endpoint is POST-only with CSRF protection in the deployed version.

MISP's custom LdapAuthenticate and LinOTPAuthenticate components, which replace CakePHP's FormAuthenticate, failed to replicate its credential validation, allowing empty or non-string values to reach the underlying authentication mechanisms. A remote attacker who knows a valid directory user's email address can submit an empty password, which is passed to ldap_bind(); if the LDAP server accepts unauthenticated binds, the bind succeeds and MISP treats the attacker as that directory user without verifying any password. The flaw also affects the LinOTP path and local fallback: with mixed authentication enabled, an empty password can be checked against a stored MISP password hash, and LDAP-provisioned accounts may have been created with an empty local password that remains usable once the account is no longer resolved through LDAP. Successful exploitation lets an unauthenticated attacker impersonate an existing MISP user — potentially an administrator — gaining access to sensitive threat-intelligence data and the ability to modify or delete it and alter configuration. Only MISP deployments with the LDAP or LinOTP authentication components enabled are affected; no public proof-of-concept or in-the-wild exploitation is known (EPSS 0.5%, not in CISA KEV).

Do: Upgrade MISP to the patched release addressing CVE-2026-85216; the fix enforces valid string credentials, rejects empty passwords where not permitted, and assigns randomly generated local passwords to LDAP-provisioned accounts. As interim mitigations, configure the LDAP directory to reject unauthenticated (empty-password) binds, disable mixed authentication with LinOTP if not needed, and reset the local passwords of LDAP-provisioned MISP accounts — especially privileged ones — in case they hold empty-password hashes. Review authentication logs for successful logins against known directory-user email addresses using empty passwords.

hbs is an Express view engine that wraps Handlebars. Its registerAsyncHelper API bypasses Handlebars' automatic HTML escaping: an async helper returns an opaque placeholder during the first render pass, so the double-brace expression escapes only the placeholder, and after rendering hbs substitutes the placeholder with the raw callback return value without escaping it, across the cached, uncached, and layout render paths. An application that passes attacker-influenced data, for example user-supplied content from a database, into an async helper callback can therefore have arbitrary HTML and JavaScript injected into the server-rendered page, resulting in stored or reflected cross-site scripting. Versions 2.1.0 through 4.2.1 are affected, and the issue is fixed in 4.3.0, which HTML-escapes async helper output. Applications that intentionally emit raw HTML from an async helper can opt in explicitly with hbs.SafeString. Users should upgrade to 4.3.0.

GitPython's GitConfigParser contains a configuration-injection flaw (CWE-88/CWE-94) in its read-then-write round trip: multi-line values parsed from an on-disk config file using git's standard backslash-continuation syntax are decoded into Python strings with embedded newlines, and when the parser later rewrites the file, write_section() serializes them as a bare, unquoted newline-plus-tab continuation that real git parses as separate top-level config lines. The recently added UNSAFE_CONFIG_CHARS_RE safety guard only applies to values passed directly to set()/set_value()/add_value()/add_section(), never to values loaded from disk via _read(), so any unrelated write can turn a dormant value into a live directive such as core.hooksPath = <attacker-controlled path>. An attacker who can plant such a value in a config file that a GitPython-based application later rewrites gains arbitrary code execution, because git will execute the attacker's hook programs with the privileges of the user running GitPython. Developers, CI/CD systems, and pip-packaged tools that embed GitPython and rewrite git config files are affected, with GitPython 3.1.58 at HEAD confirmed vulnerable. No public PoC exists, it is not in CISA KEV, and EPSS assigns only a 0.4% probability of exploitation within 30 days, so no exploitation is currently known.

Do: Monitor GitPython for a patched release beyond 3.1.58/commit 9729ed3b (no fixed version is identified in the available data) and upgrade as soon as one is published. In the interim, avoid letting GitConfigParser rewrite config files that may contain multi-line (backslash-continuation) values, audit managed .git/config and related files for values with embedded newlines or unexpected trailing fragments like hooksPath, and restrict write access to those files to trusted principals.

tor before 0.4.9.9 was prone to an out-of-bounds write when parsing a consensus or detached signature with unexpected signature digest type. Impact is minor for most Tor roles, but potentially major for directory authorities. This is TROVE-2026-019.

libexpat before 2.8.4 lacks handler call depth tracking with custom encoding callbacks. Thus, a use-after-free can occur. NOTE: this is similar to CVE-2026-50219, CVE-2026-56131 and CVE-2026-56412.

GitPython before 3.1.58 contains a flaw (CWE-88) in its check_unsafe_options guard, which is meant to block unsafe git options while allow_unsafe_options is set to its default value of False. The guard can be bypassed by combining a single-character keyword argument with split_single_char_options=False, causing GitPython to emit a joined token that git itself parses as an --upload-pack option. An attacker who can influence the kwargs passed to guarded methods such as clone_from can therefore inject --upload-pack and achieve arbitrary OS command execution, despite the library's default safe configuration. Any Python application, service, or pipeline built on the pip-installed GitPython library that passes attacker-controlled or remotely influenced arguments into its git wrapper methods is affected. A public proof-of-concept reference exists via the project's GitHub security advisory (GHSA-wvpp-8hx9-p66j); there is no evidence of in-the-wild exploitation yet, and EPSS puts 30-day exploitation probability at roughly 0.6%.

Do: Upgrade to GitPython 3.1.58 or later via pip as soon as possible. Audit application code paths where user or remote input flows into kwargs of guarded GitPython methods (e.g., clone_from), and avoid combining split_single_char_options=False with single-character keyword arguments until patched. No in-the-wild exploitation is confirmed, but given the public advisory, prioritize updates for internet-facing services that wrap git operations.

MLflow versions prior to 3.15.0 contain a server-side request forgery flaw (CWE-918) in the unauthenticated POST /api/2.0/mlflow/webhooks/{id}/test endpoint. The webhook URL is validated only for the original request, but delivery follows redirects and re-resolves the hostname without pinning the validated address, letting an attacker redirect server-side requests to internal network services or cloud instance metadata endpoints. Because the endpoint returns response_status and response_body, attackers can read internal service responses and, per public reporting, steal cloud credentials and secrets from metadata services. Any self-hosted MLflow deployment is affected, with internet-exposed servers at the highest risk. Exploitation is confirmed in the wild: CISA added the flaw to its Known Exploited Vulnerabilities catalog on 2026-08-19, and headlines report active attacks stealing cloud credentials; EPSS puts 30-day exploitation probability at 16.4% (97th percentile).

Do: Upgrade to MLflow 3.15.0 or later immediately, prioritizing any MLflow server reachable from the internet. Until patched, restrict network access to MLflow (especially the /api/2.0/mlflow/webhooks/{id}/test endpoint), place it behind authentication or a reverse proxy, and review webhook logs for unexpected test requests and cloud metadata endpoint access; rotate cloud credentials and secrets if compromise indicators are found. Federal agencies must apply vendor mitigations in accordance with CISA BOD 26-04 guidance or discontinue use if mitigations are unavailable.

GitPython versions before 3.1.54 contain an OS command injection flaw (CWE-78) in which the check_unsafe_options guard intended to block dangerous git options can be bypassed by smuggling git options inside single-character kwarg values. An attacker who can influence the option dictionaries passed to commonly used methods — clone_from, fetch, pull, push, ls_remote, iter_commits, blame, or archive — can inject the --upload-pack parameter to execute arbitrary OS commands on the host. Successful exploitation yields remote code execution with the privileges of the Python process running GitPython (CVSS 4.0: 8.7, high). Any Python application, service, or CI/automation tooling built on affected GitPython versions where attacker-controlled data reaches these git option arguments is affected. No confirmed in-the-wild exploitation yet (not in CISA KEV, EPSS ~0.7%), but a public advisory and proof-of-concept reference exist, so weaponization is straightforward.

Do: Upgrade to GitPython 3.1.54 or later. Interim mitigation: audit all code paths that pass user- or attacker-controlled arguments or option dictionaries into clone_from, fetch, pull, push, ls_remote, iter_commits, blame, or archive, and validate that option values (especially short/single-character kwargs) cannot smuggle extra git options such as --upload-pack. Review web applications and automation that invoke git via GitPython to confirm whether untrusted input reaches these parameters.

A flaw was found in SSSD. The extract_authtok_v1() function in the PAM responder does not validate the auth_token_length field against the remaining buffer size before processing. A local attacker can exploit this via a crafted protocol v1 request to the PAM responder socket, causing an out-of-bounds read and process crash, resulting in a denial of service.

An issue was discovered in Django 5.2 before 5.2.17 and 6.0 before 6.0.8. GeoDjango spatial lookups optimistically parse the right-hand-side value as a raster by passing it to the `django.contrib.gis.gdal.GDALRaster` constructor. Any value used in a spatial lookup against a `GeometryField` or `RasterField` reaches this constructor, including untrusted input, for example a spatial-field filter submitted through the Django admin changelist query string by a staff user with view permission. A `dict`, or a `str` holding its JSON representation, is opened in write mode regardless of the constructor's `write=False` default, allowing a file with an attacker-chosen name and contents to be written through a file-backed GDAL driver. Any other `str` is treated as a datasource, allowing an outbound network request through a GDAL virtual filesystem handler. Writing a file to a location later imported by the application can result in remote code execution. Earlier, unsupported Django series (such as 5.1.x, 5.0.x, and 4.2.x) were not evaluated and may also be affected. Django would like to thank Bence Nagy, localhost-detect, and kimchunbok_ for reporting this issue.

Zephyr RTOS's hawkBit device management client (subsys/mgmt/hawkbit/hawkbit.c) accumulates the HTTP response body into a heap buffer that reserves no room for a terminating NUL, so when the accumulated body length equals the allocation the terminator is written one byte past the end of the heap object (CWE-122/CWE-787). Since v4.0.0 any response body larger than the 1100-byte initial buffer triggers the out-of-bounds write deterministically, while pre-v4.0.0 builds are affected when the body length exactly equals the current allocation (1100 bytes by default); both cases are remotely reachable because the body length is fully controlled by the update server, and TLS does not protect against a hostile or man-in-the-middle server. An attacker controlling the update-server path gains a fixed one-byte NUL heap corruption that typically causes denial of service (a fault on a subsequent allocation or free), with bounded, allocator-dependent potential for further corruption. Only Zephyr-based devices built with the hawkBit update client enabled and configured against a remote update server are affected. The flaw is documented in a public Zephyr security advisory (GHSA-39h3-7phx-pwhv), but it is not in CISA KEV, has a low 0.3% EPSS (26th percentile), and there is no evidence of in-the-wild exploitation.

Do: Upgrade Zephyr to the patched release identified in the advisory GHSA-39h3-7phx-pwhv, which sizes the buffer to body length plus one and copies with memcpy so the terminator always lands inside the allocation. Until patched, confirm whether your builds actually enable the hawkBit subsystem (builds without it are unaffected) and harden the update-server path with TLS certificate pinning to prevent man-in-the-middle triggers, noting that TLS alone does not protect against a compromised or hostile hawkBit server. Because the impact is denial of service, prioritize devices where availability is critical.

GitPython before 3.1.53 does not properly escape section names when writing git config files, allowing an attacker who controls a submodule name to inject arbitrary configuration directives such as core.sshCommand into the victim's .git/config. The flaw is triggered when an application passes attacker-controlled input to the create_submodule or clone_from operations, and code execution follows when git subsequently performs ssh operations using the injected config. An attacker who successfully exploits this gains remote code execution on the machine running git. Any Python application or tooling that embeds GitPython and feeds untrusted repository or submodule names into these APIs is affected. Exploitation has not been observed in the wild; a public advisory/PoC reference exists and EPSS estimates a low 0.3% probability of exploitation in the next 30 days.

Do: Upgrade to GitPython 3.1.53 or later. Treat repository URLs and submodule names as untrusted input, and avoid passing attacker-controlled names to create_submodule or clone_from; audit existing .git/config files for unexpected core.sshCommand or other injected entries. Where upgrades are delayed, sanitize submodule names and restrict which config keys can be written.

Zephyr RTOS's experimental OCPP 1.6 client contains an out-of-bounds read and a potential one-byte out-of-bounds write in its inbound RPC message parser, caused by a hand-rolled strncpy-based extractor that can leave the 128-byte stack buffer unterminated so a subsequent strchr scans past it. A malicious or compromised OCPP central-system server, or any on-path attacker when OCPP is deployed over unencrypted ws://, can trigger the flaw by sending an RPC frame whose uid or action field is 127+ bytes with no closing quote, or by filling the receive buffer with a maximal-length frame. The primary impact is a remotely triggerable denial of service, since the unbounded scan can fault on an unmapped page and the stray NUL write can corrupt adjacent stack state; confidentiality impact is limited because the over-read bytes are not reflected to the peer. Only Zephyr builds that explicitly enable the experimental OCPP subsystem (CONFIG_OCPP), typically OCPP 1.6 charge-point or charging-infrastructure prototypes, are affected. No exploitation has been reported in the wild: the EPSS probability is low (0.3%), the flaw is not in CISA KEV, and a public reference exists in the Zephyr security advisory GHSA-jgqq-7mjj-w642.

Do: Check Zephyr security advisory GHSA-jgqq-7mjj-w642 for the affected and fixed version ranges and upgrade to a Zephyr release containing the rewritten parser, which uses bounds-respecting json_mixed_arr_parse() and an explicitly NUL-terminated uid copy. If OCPP is not required, disable CONFIG_OCPP; if it is, use wss:// (TLS) with trusted central systems to remove the on-path attack vector. Audit whether any deployed charge-point or charging-infrastructure builds enable the experimental OCPP client and are reachable from untrusted networks.

GitPython 3.1.50 contains a command-injection flaw (CWE-78) in which the library's default unsafe-option gate fails to recognize joined short-option forms such as -u, the short form of --upload-pack=. The flaw is triggered when an application passes attacker-influenced options into Repo.clone_from(..., multi_options=..., allow_unsafe_options=False): the attacker supplies -u with a value of their choosing, bypassing the gate that is supposed to block --upload-pack/-u. During the clone, Git then executes the helper command named by the -u option, giving the attacker arbitrary command execution on the host running GitPython, in the context of the cloning process. Any application built on GitPython 3.1.50 that forwards untrusted, user-controlled clone options is affected; deployments that do not pass attacker-influenced options are not exposed. There is one public proof-of-concept reference (the project's GitHub security advisory GHSA-v396-v7q4-x2qj); the flaw is not in CISA KEV, EPSS is 0.4%, and no in-the-wild exploitation is currently reported.

Do: Upgrade to GitPython 3.1.51 or later, which recognizes joined short-option forms in the unsafe-option gate. Until patched, do not pass attacker-controlled arguments to Repo.clone_from via multi_options, and audit applications that let users supply clone options (including short options like -u) for this pattern.

Zephyr RTOS's Bluetooth host stack contains a use-after-free (CWE-416) in the GATT client's CCC-write response handler, gatt_write_ccc_rsp() in subsys/bluetooth/host/gatt.c, which invokes the application's subscribe() callback after already calling the terminating notify(conn, params, NULL, 0) that — per the documented GATT API — signals the application may free or reuse the bt_gatt_subscribe_params struct. A device within Bluetooth range acting as a GATT server can trigger the faulty ordering simply by answering the CCC write with an ATT Error Response, whose error code flows through att_error_rsp and att_handle_rsp into gatt_write_ccc_rsp; the unsubscribe path is also affected. The result is memory corruption, a crash (denial of service), or potentially attacker-influenced control flow via an indirect call through the freed params->subscribe function pointer. Any Zephyr-based product using the Bluetooth host stack as a GATT client whose application frees or recycles subscription parameters in its notification-termination handler is affected; the affected/fixed version range is not stated in the source data, so users should consult Zephyr advisory GHSA-29xh-jm2m-4qvx. Exploitation has not been reported in the wild (EPSS 0.3%, not in CISA KEV), but a public advisory with a proof-of-concept reference is available.

Do: Update affected Zephyr-based products to a firmware release incorporating the fix from Zephyr advisory GHSA-29xh-jm2m-4qvx, which reorders gatt_write_ccc_rsp so the subscribe() callback runs before the terminating notify(NULL) in both the error and unsubscribe paths. As an interim mitigation, applications can avoid freeing or reusing bt_gatt_subscribe_params in the notify-termination handler, and operators should contact device vendors to confirm their BLE stack includes the patch. Because exploitation requires a connected GATT-server peer within Bluetooth range, restricting connections to trusted peripherals reduces exposure.

Integer wraparound in IVFFlat index build in pgvector before 0.8.6 allows a database user to write data out-of-bounds, which could lead to arbitrary code execution. Only 32-bit systems are affected.