CVE-2026-75892
In osmo-ggsn 1.14.0 an out of bounds write issue was found in the gtp_decode_pdp_ctx() function through the PDP context GSN-Address sub-fiel
CVSS
—
Sin CVSS
EPSS
—
KEV
—
Exploit Today
—
0-100
Publicado: 18 sept 2026 · Última mod.: 18 sept 2026 · CWE-787
Sin historial EPSS suficiente todavía.
In osmo-ggsn 1.14.0 an out of bounds write issue was found in the gtp_decode_pdp_ctx() function through the PDP context GSN-Address sub-field, leading to memory corruption.
CVECVSSEPSSKEVRExplotTítuloVis.
CVE-2026-93894——
———In Vinyl Cache before 9.0,2, workspace buffer overflow vulnerability was found in the .upper() and .lower() string type methods of VCL. This can be used as a remote denial of service (DoS) vector to make the child process segfault or assert, and then restart. Effectively exploiting this vulnerability requires prior knowledge about the VCL in use and the ability to craft a request that contains a string that is long enough to fill the remaining workspace at the call site while staying under the different request size limits (http_req_size, http_req_hdr_len, etc.).8hCVE-2026-617147.8 ALT—
———FluidSynth is a software synthesizer based on the SoundFont 2 specifications. From 2.2.4 until 2.5.6, configuring synth.midi-channels above 16 allows the MIDI player to index _fluid_player_t::channel_isplaying outside its fixed-size heap allocation while tracking active channels. The resulting out-of-bounds reads and writes invoke undefined behavior and may compromise confidentiality, integrity, or availability. No crafted MIDI file is required because the unsafe condition is created by the channel-count configuration itself. Keeping synth.midi-channels at its default value of 16 avoids the vulnerable path. This issue is fixed in version 2.5.6.9hCVE-2026-77396——
———PJSIP is a free and open source multimedia communication library written in C. In 2.17 and earlier, the PJSIP AVI parser in pjmedia/src/pjmedia/avi_player.c uses an input-file video chunk length as the number of bytes copied into a frame buffer whose capacity is derived from the declared media dimensions. A crafted AVI file can therefore cause an attacker-controlled out-of-bounds write past the heap allocation when an application plays the file or pulls its frames. The existing size assertion does not protect production release builds, where assertions are disabled. Typical local playback can crash the process, while applications that accept untrusted AVI sources expose a stronger memory-corruption condition. No fixed version is available as of this review.11hCVE-2026-911423.6 BAJ—
———A flaw was found in Cockpit. An integer overflow vulnerability in the `do_lastlog()` function, specifically in the offset calculation for `lastlog` entries on ILP32 (Integer, Long, Pointer 32-bit) builds, can be exploited. A low-privileged authenticated user with a specially provisioned large User ID (UID) can cause the computed offset to wrap around. This allows the user to perform unauthorized reads and writes to other users' `lastlog` records, potentially disclosing or altering sensitive login accounting information.11hCVE-2026-844447.4 ALT—
———libheif is a HEIF and AVIF file format decoder and encoder. Prior to 1.23.2, when WITH_UNCOMPRESSED_CODEC is enabled, heif_context_add_image_tile() accepts an independently constructed tile whose component-plane dimensions do not match the tile geometry established by the prototype image. ImageItem_uncompressed::add_image_tile() passes that tile directly to unc_encoder::encode_tile(), which lacked the check_component_sizes() gate and sizes its output from the configured tile geometry while copying the tile's actual component-plane dimensions. An oversized component plane can therefore make unc_encoder_component_interleave::encode_tile() copy attacker-controlled data beyond the heap output buffer. This issue is fixed in version 1.23.2.13hCVE-2026-843839.8 CRÍ—
———libheif is a HEIF and AVIF file format decoder and encoder. From 1.22.0 until 1.23.2, a crafted HEIF, HEIC, or AVIF item graph using nested iden and auxl references can make HeifPixelImage::transfer_channel_from_image_as() append duplicate Alpha planes with different bit depths to m_storage. HeifPixelImage::scale_nearest_neighbor() in libheif/image/pixelimage.cc allocates the destination Alpha plane using the first plane's 8-bit depth, then iterates a later 10-bit or 12-bit Alpha component and writes uint16_t samples into the same 8-bit allocation. The output geometry controls the overflow extent and the encoded sample values control the data written, allowing a remote file processed by heif_decode_image() to cause a heap out-of-bounds write. This issue is fixed in version 1.23.2.13h