Ubuntu security wave, Sept 10-16, 2026: nine advisories patch Netty, glibc, PHP, Python, Apache, GNU Guix, Perl, libheif and python-cryptography; 24.04.5 LTS point release ships

cryptography is a package designed to expose cryptographic primitives and recipes to Python developers. In affected versions `Cipher.update_into` would accept Python objects which implement the buffer protocol, but provide only immutable buffers. This would allow immutable objects (such as `bytes`) to be mutated, thus violating fundamental rules of Python and resulting in corrupted output. This now correctly raises an exception. This issue has been present since `update_into` was originally introduced in cryptography 1.8.

KissFFT versions prior to the fix commit 1b083165 contain an integer overflow in kiss_fft_alloc() in kiss_fft.c on platforms where size_t is 32-bit. The nfft parameter is not validated before being used in a size calculation (sizeof(kiss_fft_cpx) * (nfft - 1)), which can wrap to a small value when nfft is large. As a result, malloc() allocates an undersized buffer and the subsequent twiddle-factor initialization loop writes nfft elements, causing a heap buffer overflow. This vulnerability only affects 32-bit architectures.

Perl versions through 5.45.1 have out-of-bounds heap reads and writes during regular expression matching via an undersized superlinear cache in S_regmatch. The regex engine's superlinear cache holds one bit per subject position for each participating WHILEM node, so the bit count is the subject length plus one times the number of nodes. Nothing checks that product for positive overflow of the signed 32-bit count: a 286331153 byte subject matched against a pattern with 15 participating nodes stores the count as 14, leaving a two byte cache. The cache is then indexed from the real match position and node number, so reads go past the end of the allocation, and on failure CACHEsayNO sets a bit past it. A caller that matches an attacker controlled subject of this size against a pattern of this shape can crash the process or corrupt heap memory.

Attacker-provided inputs to bccomp() could lead to an out-of-bounds write with stack and heap corruption in PHP versions from 8.4.* before 8.4.24 and from 8.5.* before 8.5.9.

Perl versions from 5.9.4 before 5.41.9 can produce incorrect regular-expression match results because a stale failure flag in the Aho-Corasick prescan (S_find_byclass) is not cleared when a later transition succeeds, causing the prescan to stop before it records an earlier valid match position. The flaw is triggered by alternation patterns where one candidate position is recorded and a later character then forces a fallback through a fail link that succeeds; for example, 'ABCDE' =~ m/ABCF|BCDE|C/ matches C at offset 2 instead of BCDE, and m/ABCF|BCDE|C(G/) fails to match at all. An attacker who controls input to such a regex can make an access-control, validation, or filtering decision resolve incorrectly, either matching the wrong alternative branch or missing a match entirely, with impact rated low (CVSS 5.3, medium). Any application running an affected Perl interpreter whose security-relevant regexes use alternations is exposed, and because Perl ships by default with virtually all Linux and Unix systems the installed base is enormous even though only specific pattern shapes trigger the bug. No public proof-of-concept is known, the issue is not in CISA KEV, and EPSS puts the 30-day exploitation probability at 0.4%, so no exploitation is currently known.

Do: Upgrade to Perl 5.41.9 or later, or apply vendor backports such as Ubuntu's USN-8736-1 for affected distribution packages. Audit regex-based access-control, validation, and filtering rules that use alternations, and test them against inputs where a later alternative should match after an earlier one fails. No reliable workaround exists because the defect is inside the regex engine itself, so patching is the primary remediation.

The strfmon() and strfmon_l() functions in the GNU C Library (glibc) versions 2.38 through 2.44 can write past the end of a caller-supplied buffer when a monetary conversion uses right-justified width padding. The overflow occurs when the destination buffer is large enough for the padding itself but too small for an internal memmove operation, with the field width or format string potentially attacker-influenced or a fixed susceptible pattern in the calling code. Successful exploitation yields out-of-bounds memory writes in the context of the calling application, plausibly causing crashes (denial of service) or, depending on heap layout, code execution. Any Linux application linked against glibc 2.38–2.44 that calls strfmon/strfmon_l with such patterns is affected, though no network-facing application impact was known at publication. No public proof of concept or in-the-wild exploitation has been reported, and the issue is not on the CISA KEV list.

Do: Apply your distribution's patched glibc packages (e.g., Ubuntu USN-8737-1 / USN-8737-2) or upgrade to a glibc release newer than 2.44, then restart long-running services so they relink against the fixed library. Audit internally developed software for calls to strfmon/strfmon_l with right-justified width padding, especially where monetary format strings or field widths derive from user input, and sanitize or cap those inputs in the interim. Since no network-facing impact is known, prioritize this as routine patching rather than emergency response, but track vendor advisories for newly identified vulnerable applications.

A stack-based buffer overflow (CWE-121) exists in the tdelete function of the GNU C Library versions 2.1 through 2.44, where two rebalancing branches push an entry onto an internal parent-node stack without checking capacity, writing one pointer past the end of an alloca-allocated array. Triggering it requires deleting a node at a depth of exactly 40 (or 40 plus a multiple of 20), which implies a tree of at least a million nodes, meaning an attacker would need to drive a very large number of insertions and deletions through an application that uses tsearch/tdelete. The written value is a pointer into a tree node and is not directly attacker controlled, so the most likely outcome is an application crash (low confidentiality/integrity/availability impact per the CVSS 5.6 rating). No affected application in common Linux distributions has been identified, significantly limiting real-world attack surface. No public proof of concept exists and the flaw is not in the CISA KEV catalog.

Do: Apply distribution security updates for glibc as they ship (Ubuntu has published USN-8737-1 and USN-8737-2 covering this issue) rather than waiting for a targeted exploit. Audit any in-house or third-party applications that use tsearch/tdelete on attacker-influenced data, and confirm they cannot accumulate trees of a million or more nodes. Because the written value is not attacker controlled, the primary risk is denial of service via crash, so prioritize patching on long-running services that maintain large search trees.

A NULL pointer dereference in the mod_authn_socache in Apache HTTP Server 2.4.66 and earlier allows an unauthenticated remote user to crash a child process in a caching forward proxy configuration. Users are recommended to upgrade to version 2.4.67, which fixes this issue.

The fix for CVE-2026-0672, which rejected control characters in http.cookies.Morsel, was incomplete. The Morsel.update(), |= operator, and unpickling paths were not patched, allowing control characters to bypass input validation. Additionally, BaseCookie.js_output() lacked the output validation applied to BaseCookie.output().

KissFFT before commit 8a8e66e contains an integer overflow vulnerability in the kiss_fftndr_alloc() function in kiss_fftndr.c where the allocation size calculation dimOther*(dimReal+2)*sizeof(kiss_fft_scalar) overflows signed 32-bit integer arithmetic before being widened to size_t, causing malloc() to allocate an undersized buffer. Attackers can trigger heap buffer overflow by providing crafted dimensions that cause the multiplication to exceed INT_MAX, allowing writes beyond the allocated buffer region when kiss_fftndr() processes the data.

libheif, a widely used open-source HEIF/AVIF decoder and encoder, fails to validate that an auxiliary alpha plane's dimensions match the main frame when decoding image sequences: Track_Visual::decode_next_image_sample() passes an inconsistent image downstream, and during re-encoding unc_encoder_component_interleave::encode_tile() allocates its buffer using the primary dimensions while copying each component using its actual plane dimensions, causing an attacker-controlled heap out-of-bounds write (and, with the inverse mismatch, an out-of-bounds read). The flaw is triggered by decoding a crafted image sequence (a 2x2 primary plane with a 256x256 alpha plane is a demonstrated trigger) in a normal decode-and-re-encode workflow, so an attacker gains heap corruption that can crash the application (DoS) and potentially enable memory-corruption exploitation with limited confidentiality, integrity, and availability impact per the CVSS scoring. Any application or system that decodes untrusted HEIF/AVIF image sequences with libheif 1.23.0 or earlier is affected, including Linux distributions that ship the library, as confirmed by Ubuntu security notice USN-8774-1. No public proof-of-concept is known, the flaw is not in CISA KEV, and EPSS estimates only a 0.1% probability of exploitation within 30 days, so no exploitation is currently known.

Do: Upgrade libheif to version 1.23.1, or apply the distro update provided in Ubuntu USN-8774-1 (and equivalent updates in other distributions that package libheif). Until patched, avoid processing untrusted HEIF/AVIF image sequences in tools that decode and re-encode/transcode images with libheif (viewers, thumbnailers, transcoders, ImageMagick/vips-style pipelines that link it). Inventory systems and applications for linked libheif builds to confirm they receive the fixed version.

libheif, a widely used HEIF/AVIF decoder and encoder library, mishandles crafted HEIF sequences that are accepted by heif_context_read_from_memory() but contain no registered sequence tracks. A subsequent call to heif_context_get_track(ctx, 0) reaches HeifContext::get_track() in context.cc, where assert(has_sequence()) executes before normal error handling, so assert-enabled builds abort instead of letting the wrapper in heif_sequences.cc return null; in release builds the track_id-zero path dereferences m_tracks.begin()->second on an empty map, which is undefined behavior and typically crashes the process. An attacker who can supply a malicious HEIF/AVIF file to an application using these documented public APIs can therefore cause a denial of service (CVSS C:N/I:N/A:L, with user interaction required to open the file). Any application, service, or distribution package linking libheif 1.23.0 or earlier and parsing untrusted media through these APIs is affected; Ubuntu has issued USN-8774-1 for its libheif packages. There is no known public PoC, the issue is not in CISA KEV, and EPSS estimates only a ~0.3% chance of exploitation in the next 30 days.

Do: Upgrade libheif to version 1.23.1 or later, and on Ubuntu apply the package updates from USN-8774-1; rebuild statically linked applications against the patched library. Applications using the sequence APIs should additionally validate that a context contains tracks before calling heif_context_get_track(), and treat untrusted HEIF/AVIF inputs (e.g., uploads, thumbnails) as suspect until patched.

cryptography is a package designed to expose cryptographic primitives and recipes to Python developers. From 44.0.0 until 50.0.0, pkcs7_decrypt_der, pkcs7_decrypt_pem, and pkcs7_decrypt_smime reported the outcome of decrypting a RecipientInfo's encryptedKey in several distinguishable ways, one of which disclosed the exact length recovered from the RSA operation. The same distinction was also observable by timing. An application that decrypts attacker-supplied EnvelopedData and reflects the outcome gives the attacker a Bleichenbacher oracle against the content-encryption key. Decryption ran as RSA PKCS#1 v1.5 decrypt of encryptedKey, build an AES cipher from the result, then AES-CBC decrypt and PKCS#7 unpad. Invalid RSA padding, a valid padding with a bad key length, a correct length with a wrong key, and the real key each failed or succeeded differently. Case 1 is reachable only where the linked library lacks implicit rejection: OpenSSL 3.0 and 3.1, LibreSSL, and BoringSSL. Exploitation requires a service that auto-decrypts untrusted EnvelopedData matching the victim certificate and answers adaptively at high volume, such as an S/MIME gateway or mail filter. This issue is fixed in 50.0.0.