Just published.

python-tuf is a Python reference implementation of The Update Framework (TUF). Prior to 7.0.0, DelegatedRole._is_target_in_pathpattern in tuf/api/_payload.py uses fnmatch.fnmatch, which applies os.path.normcase before matching and makes delegation path authorization case-insensitive on Windows. When a TUF repository has path-based delegations that differ only by case and an attacker-controlled role is visited before the legitimate role, ngclient can accept an attacker-provided target from the wrong delegation for a requested path. Linux and macOS clients are not affected because their path normalization does not change case. This issue is fixed in 7.0.0.

Other OS & kernel Theupdateframework python-tuf

Temporal Server does not bind a workflow-history pagination token to the namespace and workflow named in the request that presents it. GetWorkflowExecutionHistory and GetWorkflowExecutionHistoryReverse authorize the caller against the namespace in the request, then select history from the branch recorded inside the caller-supplied next_page_token. The normal history continuation carries a run identifier, event bounds, a persistence cursor, and a branch token, but no namespace or workflow identity, and it is serialized as unauthenticated protobuf bytes. An authenticated caller holding read permission on one namespace, together with a genuine non-final continuation issued earlier for a workflow in a second namespace, can submit that continuation with a request naming the first namespace and receive the second namespace's workflow history, provided the supplied workflow identifier selects the same History shard as the continuation's branch. No workflow with the supplied identifier needs to exist. Because the token is unauthenticated, a holder can also advance its event range and clear its persistence cursor, which returns history events created after that caller's current credential no longer granted access to the continuation's namespace. Determining exposure is a version question rather than a configuration question: every release listed as affected omits the binding check on the forward history path, and on the reverse history path in releases from 1.16.0, which introduced GetWorkflowExecutionHistoryReverse; no setting in an affected release restores it, and affected releases emit no metric or log for the condition, so their telemetry provides no detection. Fixed releases add the check and, when a page token's branch token is not the requested execution's current branch token, record the counter pagination_token_branch_mismatch tagged with namespace and reason and write a History-service warning log reading "Pagination branch token is not the execution's current branch token" with the fields wf-namespace, wf-id, wf-run-id, reason, wf-branch-token, and wf-request-branch-token. Search History warning logs for that message, or for reason=foreign_branch, which denotes a branch token the requested execution never recorded and is not expected in normal operation; reason=non_current_branch denotes a retained but superseded branch of the same execution and can occur legitimately after conflict resolution or failover. A foreign_branch record does not by itself prove the read was refused, because the counter and log are emitted before the enforcement decision and therefore appear both when the check rejects the request and when history.enablePaginationTokenBranchValidationShadowMode is enabled and the read is served; confirm refusal from the gRPC response, which is InvalidArgument carrying a CurrentBranchChangedFailure detail. The metric and log are tagged with the requesting namespace, not the namespace whose history the token selects, so a foreign_branch alert does not name the exposed namespace. The issue does not provide unauthenticated access, construction of a usable continuation from public workflow identifiers, enumeration of workflows for which the caller holds no continuation, or any modification of workflow state.

Auth & access Server

FFmpeg through 9.0.2 contains a use-after-free vulnerability in libavcodec/nvdec.c because ff_nvdec_start_frame() fails to reset ctx->bitstream after slice errors. Attackers can supply crafted video that abandons a picture before end_frame, causing cuvidDecodePicture() to read freed heap memory, crashing applications or exposing stale heap contents.

Memory safety

FFmpeg through 9.0.2 contains an uninitialized stack memory disclosure vulnerability in old_codec23() of libavcodec/sanm.c that leaks stack bytes into decoded frames. Attackers can supply a crafted LucasArts SMUSH/SANM animation using codec 23 with an inline table to expose decoder process stack memory in output video.

Memory safety

FFmpeg before 8.1.3 and 9.x before 9.0.2 contains a heap out-of-bounds write vulnerability in the APAC decoder in libavcodec/apac.c caused by an unreset bitstream index. Attackers can supply a crafted APAC file whose growing bitstream_index triggers an integer overflow, bypassing the reallocation check so memcpy() corrupts heap memory or crashes the application.

Memory safety

FFmpeg through 9.0.2 contains an uninitialized memory disclosure vulnerability in the CineForm HD decoder that allows attackers to leak heap memory via unzeroed idwt_tmp buffers in libavcodec/cfhd.c. Attackers can supply a crafted CFHD file with an ImageHeight tag exceeding coded band heights, causing uninitialized heap bytes to be filtered into decoded video output.

Memory safety

FFmpeg through 9.0.2 contains a double free vulnerability in libavcodec/cbs_sei.c where cbs_sei_delete_message() leaves a stale extension_data reference that ff_cbs_sei_add_message() reuses. Attackers can supply a crafted H.264 stream with a display orientation SEI message followed by payload extension data, processed by h264_metadata with display_orientation=insert, to corrupt heap memory.

Memory safety

FFmpeg through 9.0.2 contains a heap out-of-bounds read vulnerability in v4l2_buffer_swframe_to_buf() in libavcodec/v4l2_buffers.c that mishandles frames with negative linesize. Attackers can supply bottom-up AVI or PNM/PFM files that are transcoded to a V4L2 M2M encoder, crashing the application or leaking heap memory into encoded output.

Memory safety

FFmpeg through 9.0.2 contains a division by zero vulnerability in dovi_configure_ext() in libavcodec/dovi_rpuenc.c that allows attackers to crash the process via an unvalidated frame rate denominator. Attackers can supply a crafted HEVC or AV1 input with a nonzero frame rate numerator and zero denominator to the dovi_rpu bitstream filter or libx265, libaom, or libsvtav1 encoders, causing denial of service.

Denial of service

FFmpeg through 9.0.2 contains an integer overflow vulnerability in ff_prores_kostya_encode_init() that miscalculates frame_size_upper_bound using 32-bit arithmetic for large frame dimensions. Attackers can supply a high-resolution video transcoded with the prores_ks encoder, causing encode_frame() to write slices past an undersized packet buffer and corrupt heap memory.

Memory safety

FFmpeg through 9.0.2 contains a heap buffer overflow vulnerability in libavcodec/exrenc.c that allows attackers to corrupt heap memory when encode_scanline_rle() processes frames taller than the encoder height. Attackers can supply crafted input whose resolution grows mid-stream, transcoded to OpenEXR with RLE compression, to write pointers past the scanline array and crash the application.

Memory safety

FFmpeg through 9.0.2 contains an out-of-bounds read vulnerability in the SGI encoder's encode_frame() in libavcodec/sgienc.c, where unsigned size variables mis-handle negative linesize frames. Attackers can supply a video whose display matrix triggers autorotate vflip, so transcoding to SGI images reads pixel data far outside the frame and crashes the process.

Memory safety

FFmpeg through 9.0.2 contains a heap buffer overflow vulnerability in libavcodec/lcevcdec.c because LCEVC output picture dimensions are not validated against the allocated frame. Attackers can embed crafted LCEVC enhancement data with differing global configurations in H.264 or HEVC streams to corrupt heap memory in decoding applications.

Memory safety

FFmpeg 9.0 through 9.0.2 built with liblcevc_dec fails to validate LCEVC enhanced output dimensions against max_pixels in libavcodec/decode.c before frame allocation. Attackers can supply crafted H.264, HEVC or VVC streams declaring huge LCEVC resolutions to force oversized get_buffer2() allocations and exhaust memory.

Other

FFmpeg through 9.0.2 contains an uncontrolled resource consumption vulnerability in parse_frame_header() in libavcodec/jpegxl_parser.c that fails to validate TOC entry counts against remaining input. Attackers can supply a crafted JPEG XL frame header with a permuted TOC and huge toc_count, making the parser loop excessively and exhaust CPU.

Other Library

FFmpeg through 9.0.2 contains a memory leak vulnerability in libavcodec/vaapi_decode.c that allows attackers to exhaust memory by supplying streams with slice parse errors. Attackers can craft H.264 or other VAAPI-decoded video where later slices fail to parse on every frame, continuously leaking VA parameter and slice buffers plus driver and heap memory.

Other OS & kernel

FFmpeg through 9.0.2 contains an integer overflow in cbs_vp9_split_fragment() in libavcodec/cbs_vp9.c that wraps the superframe size check on 32-bit builds. Attackers can supply a crafted VP9 packet with a forged superframe index containing near-2^32 frame sizes, causing out-of-bounds reads that crash 32-bit applications.

Memory safety

FFmpeg through 9.0.2 contains a division by zero vulnerability in the VVC decoder because ff_vvc_slice_rpl() fails to validate num_ref_idx_active against built reference list entries. Attackers can supply a crafted VVC bitstream whose excess reference indices yield a zero POC difference in ff_vvc_mv_scale(), crashing the decoding process.

Denial of service

FFmpeg through 9.0.2 contains a use after free vulnerability in libavcodec/mjpegdec.c that allows attackers to trigger freed buffer reads by sending a SOF marker without a preceding SOI. Attackers can supply crafted MJPEG streams causing ff_mjpeg_decode_sof() to pass a stale raw_image_buffer pointer to hwaccel decoders like NVDEC, crashing applications or leaking heap contents.

Memory safety

FFmpeg through 9.0.2 contains a heap buffer overflow vulnerability in ff_llvidenc_diff_bytes_rvv() that allows attackers to corrupt heap memory by triggering negative length values in the Huffyuv encoder. Attackers can supply RGB video narrower than 8 or 16 pixels for huffyuv transcoding on RVV-enabled RISC-V builds, causing writes past the encoder's temp buffer.

Memory safety

FFmpeg through 9.0.2 contains an off-by-one heap overflow vulnerability in get_exponent_dynamic() in libavcodec/nellymoserenc.c that allows writing one element past the opt and path allocations. Attackers can supply crafted audio to applications encoding Nellymoser with trellis enabled, causing idx to equal OPT_SIZE and overwrite adjacent heap memory.

Memory safety

A security vulnerability has been detected in iomad up to 4.5.15/5.0.11/5.1.8/5.2.4. Affected by this issue is the function store_temporary_password of the file public/local/iomad/classes/company_user.php of the component Password Field Handler. Such manipulation leads to information disclosure. The attack may be performed from remote. The attack requires a high level of complexity. The exploitation is known to be difficult. The name of the patch is 0d9c0ccaa8a77583f5dd92eb7be7fbbb8cc6ec9b/9c740fd254fd12d56d7be3b85ac5e9fb4f8c03d8/33755cdd551a84be423b1eaf784d405c1988dbad/7fcf9b52c539a67f3e46a8da6b42ab1d1f26295b. It is advisable to implement a patch to correct this issue. This CVE was requested by the vendor.

Disclosure Web app

A vulnerability has been found in mikefarah yq up to 4.53.3. This affects the function Encode of the file pkg/yqlib/encoder_properties.go. Such manipulation leads to escaping of output. It is possible to launch the attack remotely. The pull request to fix this issue awaits acceptance.

Other

SIPSorcery is a WebRTC, SIP, and VoIP library for C# and .NET. Prior to 10.0.14, SctpSackChunk.ParseChunk reads the numGapAckBlocks and numDuplicateTSNs fields from an attacker-controlled SCTP SACK chunk without checking that the corresponding entries fit the declared chunk length. A negotiated WebRTC peer can send a checksum-valid malformed SACK chunk that drives the parser beyond the 262144-byte receive buffer. The resulting IndexOutOfRangeException bypasses the recoverable ApplicationException handler in RTCSctpTransport.DoReceive, causing the generic handler to exit the dedicated receive loop and permanently terminate the SCTP association and all data channels. This issue is fixed in 10.0.14.

Memory safety Library

The GitIdentifiers class in Apache Commons Codec did not reject NUL bytes in tree entry names. Because Git uses a NUL byte to mark the end of each entry name in a tree object, a crafted name could make one tree serialize to the same bytes as a different tree. Two different directory trees could then receive the same Git tree identifier or SWHID. The impact is limited: common file systems do not allow NUL bytes in file names, so trees built by walking a file system are not affected. Only applications that build trees from names supplied by other sources, such as entries of archive formats that permit NUL bytes in names (e.g. ZIP) or names passed directly to the API, are exposed. This issue affects Apache Commons Codec: from 1.22.0 before 1.23.0. Users are recommended to upgrade to version 1.23.0, which fixes the issue.

Other Server

Apache Commons Codec's Blake3 class documented the output of its doFinalize methods as depending on any previously finalized bytes, so that consecutive calls would return different output. In fact, doFinalize does not change the hash state: calling it again without supplying more input returns the same bytes. The key-derivation example in the class Javadoc, shipped since 1.16.0, derives two keys with two consecutive doFinalize calls. Code that follows it gets identical keys, so the separation between the derived keys is lost. The same applies to any application that calls doFinalize more than once on one instance and expects new output each time. This issue affects Apache Commons Codec from 1.16.0 before 1.23.0. Version 1.23.0 corrects the documentation, but the behavior of doFinalize is unchanged. Upgrading alone does not fix affected code. Users should check their applications for repeated doFinalize calls on the same Blake3 instance and derive multiple keys by requesting the combined length in one call and splitting the output, as the updated Javadoc shows.

Other Server

In apport before 2.37.0, an improper privilege management vulnerability allows an unprivileged local attacker to gain root privileges on systems where automatic crash reporting is enabled. The automatic crash report processing pipeline runs as root and executes ldd on the attacker-controlled ExecutablePath field of a crash file placed in the world-writable /var/crash directory, causing the dynamic loader to load and execute an attacker-supplied audit module specified by the ELF's DT_AUDIT tag. This allows an attacker to execute arbitrary code with root privileges and fully compromise the affected system.

Auth & access Library Canonical Apport

In apport before 2.37.0, a path traversal vulnerability allows an attacker who can supply a crafted crash report to cause unintended file creation or overwrite outside the intended extraction directory when the report is processed with apport-unpack. The key-name validation added for CVE-2026-77113 does not cover base64-encoded keys skipped by ProblemReport.load(binary=False), and ProblemReport.extract_keys() writes them to a file path built from the key without validation. This allows an attacker to create or overwrite arbitrary files writable by the invoking user, such as .bashrc or .profile, gaining persistence or code execution in that user's context.

Disclosure Canonical Apport

rConfig Core 8.2.3 before 8.2.13 contains an information disclosure vulnerability that allows authenticated users to retrieve cleartext SSH, Telnet, and enable passwords for managed devices through the device-credentials API due to automatic decryption on read and missing authorization checks. Attackers can request GET /api/device-credentials, GET /api/device-credentials/{id}, or the external GET /api/v1/device-credentials endpoint, which authenticates any valid token as the seeded administrator account, to statelessly exfiltrate all stored plaintext device credentials. rConfig Pro is not affected.

Auth & access

FFmpeg through 9.0.2 contains an integer overflow vulnerability in the VVC decoder alloc_frame() function in libavcodec/vvc/refs.c that undersizes the reference picture list allocation on 32-bit builds. Attackers can supply a crafted VVC (H.266) file with a very large number of NAL units per access unit to trigger heap out-of-bounds writes and corrupt memory.

Memory safety

A flaw was found in the deployment-operation family of WildFly Core. Certain handlers, such as upload-deployment-url, lack proper sensitivity classification, allowing an administrator with the restricted "Maintainer" role to read sensitive configuration files. This can lead to the exfiltration of credentials and full administrative control (SuperUser) of the server.

Other Server

FFmpeg through 9.0.2 contains a memory leak vulnerability in ff_mjpeg_decode_sof() in libavcodec/mjpegdec.c, which overwrites the hwaccel_picture_private pointer without freeing it. Attackers can supply crafted MJPEG streams with repeated SOF markers or failing frames to leak hwaccel private data and hardware buffers under VAAPI or NVDEC decoding.

Other

FFmpeg through 9.0.2 contains a denial of service vulnerability in cbs_jpeg_assemble_fragment() that miscounts 0xff stuffing bytes in JPEG scan headers. Attackers can supply a crafted JPEG/MJPEG stream with 0xff in the scan header, triggering an av_assert0 abort when CBS-based bitstream filters process it.

Denial of service

FFmpeg through 9.0.2 contains an integer overflow vulnerability in dng_decode_tiles() that allows attackers to leak uninitialized memory via crafted DNG tile dimensions. Attackers can set TileWidth or TileLength near INT_MAX so the tile loop never runs, outputting a frame exposing uninitialized or stale heap memory.

Memory safety

FFmpeg 9.0 through 9.0.2 contains an integer overflow vulnerability in libavcodec/ffv1enc_vulkan.c that undersizes the float remap GPU buffer for large frames. Attackers can supply large GBRPF32 or GBRAPF32 images or videos that, when transcoded to FFV1 with the Vulkan encoder, trigger out-of-bounds GPU memory writes causing crashes or memory corruption.

Memory safety

FFmpeg 7.1 through 9.0.2 contains an integer overflow in ff_vk_decode_add_slice() in libavcodec/vulkan_decode.c that miscalculates the Vulkan hwaccel bitstream buffer size. Attackers can supply a crafted stream with over 2 GiB of slice data per frame, causing memcpy() to write past a smaller pooled host-mapped buffer.

Memory safety

FFmpeg through 9.0.2 contains a heap buffer overflow in the GIF encoder's gif_image_write_image() in libavcodec/gif.c because shrunk_buf is sized from the first frame's linesize. Attackers can supply PAL8 video whose frame linesize grows mid-stream, causing remap_frame_to_palette() to write past shrunk_buf and corrupt the heap during GIF transcoding.

Memory safety

FFmpeg through 9.0.2 contains a reachable assertion vulnerability in libxevd_receive_frame() in libavcodec/libxevd.c that returns success when an access unit produces no frame. Attackers can supply a crafted EVC file with truncated or picture-less access units to trigger the av_assert0() on frame->private_ref, aborting any decoding application.

Denial of service

FFmpeg through 9.0.2 contains a heap buffer overflow vulnerability in ff_dxva2_hevc_fill_picture_parameters() that allows attackers to corrupt memory via unbounded non-uniform tile counts. Attackers can supply crafted HEVC bitstreams with many non-uniformly spaced tiles to write controlled 16-bit values past fixed-size DXVA arrays during DXVA2, D3D11VA, or D3D12VA decoding on Windows.

Memory safety OS & kernel

FFmpeg through 9.0.2 contains a resource leak vulnerability in svt_jpegxs_dec_decode() in libsvtjpegxsdec.c that leaks decoder instances when ff_set_dimensions() rejects frame dimensions. Attackers can supply a crafted JPEG XS stream, for example in MPEG-TS, with oversized headers to repeatedly leak decoder threads and buffers, exhausting memory.

Other

FFmpeg through 9.0.2 contains a heap buffer overflow vulnerability in libavcodec/flicvideo.c that allows attackers to write out of bounds because check_pixel_ptr() checks only one bound with negative-stride frames. Attackers can supply a crafted FLIC file whose RLE and delta chunks write pixel data past frame storage, corrupting heap memory to crash applications or possibly execute code.

Memory safety

FFmpeg through 9.0.2 contains a memory leak vulnerability in libavcodec/vdpau.c that allows attackers to exhaust heap memory by aborting pictures before end_frame. Attackers can supply crafted H.264 streams with malformed NAL units that repeatedly abandon pictures, leaking the bitstream_buffers table continuously and causing denial of service.

Denial of service

FFmpeg through 9.0.2 contains an uninitialized memory disclosure vulnerability in ff_jpegls_decode_picture() in libavcodec/jpeglsdec.c, which decodes 16-bit line-interleaved JPEG-LS scans as 8-bit samples. Attackers can supply a crafted single-component JPEG-LS image with the ILV byte set to 1, causing decoded GRAY16 frames to expose leftover heap memory.

Memory safety

FFmpeg before 8.1.3 and 9.x before 9.0.2 contains an out-of-bounds write vulnerability in the VVC decoder's sh_entry_points() function in libavcodec/vvc/ps.c. Attackers can supply a crafted VVC (H.266) bitstream whose SPS/PPS tile and WPP layout produces excess entry points, overflowing entry_point_start_ctu and corrupting decoder memory.

Memory safety

FFmpeg through 9.0.2 contains a division by zero vulnerability in estimate_motion_b() in libavcodec/motion_est.c, caused by frame timestamp distances truncated to 16 bits. Attackers can supply input with timestamp gaps that are multiples of 65536, crashing MPEG-4 Part 2 or MPEG-1/2 B-frame encoding with SIGFPE.

Denial of service

FFmpeg through 9.0.2 contains a heap buffer overflow vulnerability in dvbsub_encode() in libavcodec/dvbsubenc.c that undercounts each CLUT segment header by two bytes. Attackers can supply a file with many bitmap subtitle rectangles that, when transcoded to the dvbsub encoder, writes past the output buffer and corrupts heap memory.

Memory safety

FFmpeg through 9.0.2 contains an integer overflow vulnerability in wavpack_encode_init() in libavcodec/wavpackenc.c that causes an infinite loop when computing block size from sample rate and channel count. Attackers can supply a crafted audio file, such as a WAV header declaring a huge sample rate with many channels, to hang applications transcoding to WavPack.

Memory safety

FFmpeg through 9.0.2 contains a heap overflow vulnerability in libavcodec/qsvenc.c that allows attackers to corrupt memory by reusing an undersized pooled QSVFrame buffer when input dimensions increase. Attackers can supply crafted input whose resolution grows mid-stream, transcoded with Intel Quick Sync encoders without rescaling, to crash the application or corrupt heap memory.

Memory safety

FFmpeg through 9.0.2 contains a memory leak vulnerability in alloc_frame() in libavcodec/vvc/refs.c that leaks SPS and PPS references when frame buffer allocation fails. Attackers can supply a crafted VVC (H.266) stream that repeatedly replaces parameter sets, steadily growing memory use and causing denial of service.

Denial of service

FFmpeg 8.1 through 9.0.2 contains a denial of service vulnerability in libavcodec/dpx.c that leaves dpx->hwaccel_picture_private allocated when Vulkan hwaccel callbacks fail. Attackers can supply crafted DPX images that make start_frame, decode_slice or end_frame fail, triggering an av_assert0 abort on the next frame and terminating the decoding application.

Denial of service