Vulnerabilities

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.

CVE-2026-11368 is a use-after-free (CWE-416) in the Bluetooth host ATT layer of the Zephyr RTOS (subsys/bluetooth/host/att.c), where each in-flight ATT TX buffer stores a pointer to its owning channel in a static metadata array (tx_meta_data_storage[]) that is never cleared when the channel is torn down. A remote Bluetooth peer can trigger the bug by disconnecting while an ATT PDU (a notification, indication, or response) is still in flight in the controller TX path; no pairing or user interaction is required to reach the ATT bearer. The deferred buffer-destroy work then dereferences the now-dangling channel pointer, reliably crashing the Bluetooth host (denial of service) and potentially corrupting live memory if the freed channel slab slot has been reused. Any device running Zephyr firmware with the Bluetooth host stack and ATT enabled is affected, a population that includes many Bluetooth Low Energy products built on Zephyr-based vendor SDKs. No in-the-wild exploitation is known (EPSS 0.3%, not in CISA KEV), but a public advisory with a proof-of-concept reference (GHSA-85vg-gwc4-77g7) has been published by the Zephyr Project.

Do: Rebuild and re-flash affected devices with a Zephyr release that includes the fix referenced in GHSA-85vg-gwc4-77g7 (bt_att_released() now clears stale tx_meta_data_storage[] channel references before the slab slot is freed); no fixed version number is given in the available data, so verify the fix commit against the upstream advisory. Check whether your firmware build enables Zephyr's Bluetooth host (CONFIG_BT) with ATT/GATT; if Bluetooth is unused, disable it, and as an interim measure limit BLE peripheral exposure since no pairing or user interaction is needed to trigger the crash.

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.

A flaw was found in SSSD. The sss_nss_protocol_parse_addr() function in the NSS responder does not validate the addrlen field against the remaining packet body size. A local attacker can exploit this via a crafted GETHOSTBYADDR request to the NSS responder socket, causing an out-of-bounds read and process crash, resulting in a denial of service.

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's Bluetooth host performs its pre-send security check against the wrong GATT attribute: when an application passes the Characteristic Declaration (the documented, common idiom) to the notify/indicate APIs, the host checks the declaration's hard-coded read permission instead of the characteristic value's encryption/authentication/LESC requirements. A remote attacker within Bluetooth range connects, optionally without pairing or encryption, and writes the Client Characteristic Configuration descriptor to enable notifications or indications, causing the server to transmit the protected characteristic value over a link that never reached the required security level. The attacker gains read access to GATT characteristic values the application intended to expose only over an encrypted or authenticated link (information disclosure / access-control bypass, CWE-863); there is no memory-safety or availability impact. Any Zephyr-based Bluetooth device whose application restricts notify/indicate characteristic values to security permissions while the CCC descriptor is writable at a lower tier is affected, and the Notify-Multiple path additionally omitted the LE Secure Connections requirement. No in-the-wild exploitation is currently known (EPSS 0.2%, not in CISA KEV); the vendor advisory with a public reference (GHSA-4w3r-v9q9-4462) is available and a fix that resolves the value attribute before the permission check has been added to the host stack.

Do: Upgrade Zephyr to a release containing the fix (value-attribute resolution via bt_gatt_attr_resolve_value() and the full read-encrypt mask, including LESC, on the Notify-Multiple path) — check advisory GHSA-4w3r-v9q9-4462 for patched versions. As interim mitigations, pass the characteristic value attribute (not the Characteristic Declaration) to notify/indicate calls and set the CCC descriptor's permissions to require the same security level so peers must pair/encrypt before subscribing. Audit GATT service definitions for characteristics whose values require BT_GATT_PERM_READ_ENCRYPT/AUTHEN/LESC but whose notifications or indications could be enabled by an unencrypted peer.

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.

nanoid (Nano ID) before 3.3.16 and 5.1.16 contains an infinite loop in the customAlphabet and nanoid functions of its non-secure module (nanoid/non-secure). When these functions are given a negative size, the loop counter is decremented from a negative value and never reaches its termination condition, spinning indefinitely and hanging the calling thread. An application that passes an unvalidated, attacker-controlled negative size to these functions is exposed to a denial-of-service condition.

Dompdf, a widely used PHP library that converts HTML to PDF, is vulnerable to an unauthenticated denial-of-service flaw (CWE-400, uncontrolled resource consumption) affecting versions 3.15 and prior. An attacker supplies HTML containing a single image with extreme dimensions (e.g., 30,000x30,000 pixels), encoded as high-entropy Base64 data and wrapped in specific CSS containers, which bypasses Dompdf's early dimension-validation checks; during rendering, bounding-box and internal buffer calculations then consume unbounded CPU time and memory. The attacker gains the ability to crash the PHP process, completely denying service to PDF generation and potentially to the web application sharing that process. Any application that lets users supply HTML content or URLs that are then converted to PDF with Dompdf is affected; applications that only render internally generated documents are less directly exposed. No in-the-wild exploitation is reported (EPSS 0.7%, not in CISA KEV), but a public security advisory with proof-of-concept details exists and a fix is available in version 3.16.

Do: Upgrade Dompdf to version 3.16 or later, and verify that transitive dependencies (e.g., PHP frameworks or CMS plugins that bundle Dompdf) pull in the fixed release. As interim mitigation, sanitize or restrict user-supplied HTML, cap image dimensions and Base64 image size, and enforce strict per-render PHP memory and execution-time limits. Prioritize auditing any application that converts end-user-provided HTML or URLs to PDF, since those configurations are the directly exploitable ones.

The userspace verifier z_vrfy_log_filter_set() for the log_filter_set syscall in subsys/logging/log_mgmt.c performed a signed comparison against the int16_t src_id parameter: src_id < (int16_t)log_src_cnt_get(domain_id). Any negative value for src_id (e.g. -1) trivially satisfied this check and was forwarded into z_impl_log_filter_set, where it propagated to filter_set() and ultimately to get_dynamic_filter(), which uses source_id as an unsigned index into the linker-section array &TYPE_SECTION_START(log_dynamic)[source_id].filters. After implicit conversion through uint32_t, an int16_t -1 becomes 0xFFFFFFFF, indexing log_dynamic far out of bounds and causing the kernel to perform an OOB read and an OOB read-modify-write (LOG_FILTER_SLOT_GET/SET) against memory adjacent to the log_dynamic section. The written value is a constrained 3-bit log level slot within the targeted 32-bit word, but the target address is attacker-chosen (a small negative offset from log_dynamic) and the write occurs in supervisor mode following a syscall from an unprivileged user thread, providing a kernel memory-corruption / privilege-escalation primitive. The defect is reachable on any build with CONFIG_USERSPACE=y and CONFIG_LOG_RUNTIME_FILTERING=y. Present from Zephyr v3.3.0 through v4.4.1. The fix replaces the signed bound check with an unsigned comparison: (uint32_t)src_id < log_src_cnt_get(domain_id), which correctly rejects negative inputs.

In Zephyr's userspace dynamic-objects subsystem, thread_idx_alloc() in kernel/userspace/userspace.c allocated a new thread permission index from the global _thread_idx_map[] bitmap without holding lists_lock. On SMP systems, two user-mode threads invoking the k_object_alloc(K_OBJ_THREAD) syscall concurrently can both observe the same low free bit, perform the same non-atomic RMW to clear it, and return the identical tidx. The two newly created K_OBJ_THREAD objects are then assigned the same thread_id, so the two user threads alias a single bit position in every kernel object's perms[] bitfield: any subsequent grant of access on a kernel object to one thread is implicitly a grant to the other, defeating userspace ACL isolation. A secondary lost-update window between the unlocked &=~BIT() in alloc and the locked |= BIT() in thread_idx_free() can also leak entries from the thread-index pool. The defect is reachable from any user-mode thread via the unrestricted __syscall k_object_alloc and is gated on CONFIG_USERSPACE, CONFIG_DYNAMIC_OBJECTS, and CONFIG_SMP. The flaw was introduced when the per-thread permission index was added in 2018 and is present in every release up to and including v4.4.0. Fixed by holding lists_lock across the bitmap RMW and the permissions clear (and inlining the obj_list traversal that previously took the lock itself).

The Zephyr ext2 file system validates the on-disk superblock in ext2_verify_disk_superblock() (subsys/fs/ext2/ext2_impl.c) before completing a mount. The validator checked the magic number, block size, revision and feature flags, but did not verify that the on-disk fields s_blocks_per_group and s_inodes_per_group are non-zero. Both fields are read directly from the image and are later used as divisors during mount-time initialization. During mount, get_ngroups() divides and modulos s_blocks_count by s_blocks_per_group (reached via ext2_fetch_block_group() from ext2_init_fs()), and get_itable_entry() divides (ino - 1) by s_inodes_per_group when fetching the root inode (both in subsys/fs/ext2/ext2_diskops.c). A superblock with either field set to zero therefore causes an integer division by zero during the mount sequence. An attacker who can present a crafted ext2 image to a device that mounts ext2 — removable media such as an SD card or a USB mass-storage device — can trigger this. On ARMv7-M / ARMv8-M-mainline Cortex-M targets, divide-by-zero trapping is enabled (SCB_CCR_DIV_0_TRP), so the division raises a UsageFault that Zephyr treats as a fatal error, producing a denial of service. The impact is limited to availability; the malformed value is consumed only as a divisor. The fix rejects a zero s_blocks_per_group or s_inodes_per_group in the superblock validator, returning -EINVAL so the mount fails before any block-group or inode I/O occurs.

The Classic (BR/EDR) L2CAP signaling handlers l2cap_br_conf_req() and l2cap_br_conf_rsp() in subsys/bluetooth/host/classic/l2cap_br.c validated the minimum command size against buf->len (the bytes remaining in the whole received PDU) instead of len (the per-command data length from the L2CAP signaling header). Because multiple signaling commands can be packed into one PDU, buf->len may exceed a command's len. An attacker can send a CONF_REQ command with a header length smaller than the configuration-request structure (e.g. 0), followed by another command so that buf->len still satisfies the check. The check then passes incorrectly and opt_len = len - sizeof(*req) underflows the uint16_t to a near-0xFFFF value. The configuration-option loop, which lacks an opt_len-versus-buf->len guard, then walks far past the end of the pooled ACL receive buffer using net_buf pull primitives that perform no runtime bounds check, producing an out-of-bounds read of host memory and, when the out-of-bounds option bytes encode an MTU or flush-timeout option, an out-of-bounds write. The BR/EDR signaling channel is processed before pairing/encryption and an L2CAP channel to an L0 service such as SDP can be opened without pairing, so an unauthenticated peer within radio range that can establish an ACL connection can trigger the flaw, leading to memory corruption and denial of service (host/device crash). The defect is present in released versions including v4.4.0. The fix validates against len instead of buf->len in both handlers.